OpenCores
URL https://opencores.org/ocsvn/openrisc/openrisc/trunk

Subversion Repositories openrisc

[/] [openrisc/] [trunk/] [gnu-old/] [gcc-4.2.2/] [gcc/] [doc/] [implement-c.texi] - Blame information for rev 816

Details | Compare with Previous | View Log

Line No. Rev Author Line
1 38 julius
@c Copyright (C) 2001,2002,2003,2004 Free Software Foundation, Inc.
2
@c This is part of the GCC manual.
3
@c For copying conditions, see the file gcc.texi.
4
 
5
@node C Implementation
6
@chapter C Implementation-defined behavior
7
@cindex implementation-defined behavior, C language
8
 
9
A conforming implementation of ISO C is required to document its
10
choice of behavior in each of the areas that are designated
11
``implementation defined''.  The following lists all such areas,
12
along with the section numbers from the ISO/IEC 9899:1990 and ISO/IEC
13
9899:1999 standards.  Some areas are only implementation-defined in
14
one version of the standard.
15
 
16
Some choices depend on the externally determined ABI for the platform
17
(including standard character encodings) which GCC follows; these are
18
listed as ``determined by ABI'' below.  @xref{Compatibility, , Binary
19
Compatibility}, and @uref{http://gcc.gnu.org/readings.html}.  Some
20
choices are documented in the preprocessor manual.
21
@xref{Implementation-defined behavior, , Implementation-defined
22
behavior, cpp, The C Preprocessor}.  Some choices are made by the
23
library and operating system (or other environment when compiling for
24
a freestanding environment); refer to their documentation for details.
25
 
26
@menu
27
* Translation implementation::
28
* Environment implementation::
29
* Identifiers implementation::
30
* Characters implementation::
31
* Integers implementation::
32
* Floating point implementation::
33
* Arrays and pointers implementation::
34
* Hints implementation::
35
* Structures unions enumerations and bit-fields implementation::
36
* Qualifiers implementation::
37
* Declarators implementation::
38
* Statements implementation::
39
* Preprocessing directives implementation::
40
* Library functions implementation::
41
* Architecture implementation::
42
* Locale-specific behavior implementation::
43
@end menu
44
 
45
@node Translation implementation
46
@section Translation
47
 
48
@itemize @bullet
49
@item
50
@cite{How a diagnostic is identified (C90 3.7, C99 3.10, C90 and C99 5.1.1.3).}
51
 
52
Diagnostics consist of all the output sent to stderr by GCC@.
53
 
54
@item
55
@cite{Whether each nonempty sequence of white-space characters other than
56
new-line is retained or replaced by one space character in translation
57
phase 3 (C90 and C99 5.1.1.2).}
58
 
59
@xref{Implementation-defined behavior, , Implementation-defined
60
behavior, cpp, The C Preprocessor}.
61
 
62
@end itemize
63
 
64
@node Environment implementation
65
@section Environment
66
 
67
The behavior of most of these points are dependent on the implementation
68
of the C library, and are not defined by GCC itself.
69
 
70
@itemize @bullet
71
@item
72
@cite{The mapping between physical source file multibyte characters
73
and the source character set in translation phase 1 (C90 and C99 5.1.1.2).}
74
 
75
@xref{Implementation-defined behavior, , Implementation-defined
76
behavior, cpp, The C Preprocessor}.
77
 
78
@end itemize
79
 
80
@node Identifiers implementation
81
@section Identifiers
82
 
83
@itemize @bullet
84
@item
85
@cite{Which additional multibyte characters may appear in identifiers
86
and their correspondence to universal character names (C99 6.4.2).}
87
 
88
@xref{Implementation-defined behavior, , Implementation-defined
89
behavior, cpp, The C Preprocessor}.
90
 
91
@item
92
@cite{The number of significant initial characters in an identifier
93
(C90 6.1.2, C90 and C99 5.2.4.1, C99 6.4.2).}
94
 
95
For internal names, all characters are significant.  For external names,
96
the number of significant characters are defined by the linker; for
97
almost all targets, all characters are significant.
98
 
99
@item
100
@cite{Whether case distinctions are significant in an identifier with
101
external linkage (C90 6.1.2).}
102
 
103
This is a property of the linker.  C99 requires that case distinctions
104
are always significant in identifiers with external linkage and
105
systems without this property are not supported by GCC@.
106
 
107
@end itemize
108
 
109
@node Characters implementation
110
@section Characters
111
 
112
@itemize @bullet
113
@item
114
@cite{The number of bits in a byte (C90 3.4, C99 3.6).}
115
 
116
Determined by ABI@.
117
 
118
@item
119
@cite{The values of the members of the execution character set (C90
120
and C99 5.2.1).}
121
 
122
Determined by ABI@.
123
 
124
@item
125
@cite{The unique value of the member of the execution character set produced
126
for each of the standard alphabetic escape sequences (C90 and C99 5.2.2).}
127
 
128
Determined by ABI@.
129
 
130
@item
131
@cite{The value of a @code{char} object into which has been stored any
132
character other than a member of the basic execution character set
133
(C90 6.1.2.5, C99 6.2.5).}
134
 
135
Determined by ABI@.
136
 
137
@item
138
@cite{Which of @code{signed char} or @code{unsigned char} has the same
139
range, representation, and behavior as ``plain'' @code{char} (C90
140
6.1.2.5, C90 6.2.1.1, C99 6.2.5, C99 6.3.1.1).}
141
 
142
@opindex fsigned-char
143
@opindex funsigned-char
144
Determined by ABI@.  The options @option{-funsigned-char} and
145
@option{-fsigned-char} change the default.  @xref{C Dialect Options, ,
146
Options Controlling C Dialect}.
147
 
148
@item
149
@cite{The mapping of members of the source character set (in character
150
constants and string literals) to members of the execution character
151
set (C90 6.1.3.4, C99 6.4.4.4, C90 and C99 5.1.1.2).}
152
 
153
Determined by ABI@.
154
 
155
@item
156
@cite{The value of an integer character constant containing more than one
157
character or containing a character or escape sequence that does not map
158
to a single-byte execution character (C90 6.1.3.4, C99 6.4.4.4).}
159
 
160
@xref{Implementation-defined behavior, , Implementation-defined
161
behavior, cpp, The C Preprocessor}.
162
 
163
@item
164
@cite{The value of a wide character constant containing more than one
165
multibyte character, or containing a multibyte character or escape
166
sequence not represented in the extended execution character set (C90
167
6.1.3.4, C99 6.4.4.4).}
168
 
169
@xref{Implementation-defined behavior, , Implementation-defined
170
behavior, cpp, The C Preprocessor}.
171
 
172
@item
173
@cite{The current locale used to convert a wide character constant consisting
174
of a single multibyte character that maps to a member of the extended
175
execution character set into a corresponding wide character code (C90
176
6.1.3.4, C99 6.4.4.4).}
177
 
178
@xref{Implementation-defined behavior, , Implementation-defined
179
behavior, cpp, The C Preprocessor}.
180
 
181
@item
182
@cite{The current locale used to convert a wide string literal into
183
corresponding wide character codes (C90 6.1.4, C99 6.4.5).}
184
 
185
@xref{Implementation-defined behavior, , Implementation-defined
186
behavior, cpp, The C Preprocessor}.
187
 
188
@item
189
@cite{The value of a string literal containing a multibyte character or escape
190
sequence not represented in the execution character set (C90 6.1.4, C99 6.4.5).}
191
 
192
@xref{Implementation-defined behavior, , Implementation-defined
193
behavior, cpp, The C Preprocessor}.
194
@end itemize
195
 
196
@node Integers implementation
197
@section Integers
198
 
199
@itemize @bullet
200
@item
201
@cite{Any extended integer types that exist in the implementation (C99 6.2.5).}
202
 
203
GCC does not support any extended integer types.
204
@c The __mode__ attribute might create types of precisions not
205
@c otherwise supported, but the syntax isn't right for use everywhere
206
@c the standard type names might be used.  Predefined typedefs should
207
@c be used if any extended integer types are to be defined.  The
208
@c __int128_t and __uint128_t typedefs are not extended integer types
209
@c as they are generally longer than the ABI-specified intmax_t.
210
 
211
@item
212
@cite{Whether signed integer types are represented using sign and magnitude,
213
two's complement, or one's complement, and whether the extraordinary value
214
is a trap representation or an ordinary value (C99 6.2.6.2).}
215
 
216
GCC supports only two's complement integer types, and all bit patterns
217
are ordinary values.
218
 
219
@item
220
@cite{The rank of any extended integer type relative to another extended
221
integer type with the same precision (C99 6.3.1.1).}
222
 
223
GCC does not support any extended integer types.
224
@c If it did, there would only be one of each precision and signedness.
225
 
226
@item
227
@cite{The result of, or the signal raised by, converting an integer to a
228
signed integer type when the value cannot be represented in an object of
229
that type (C90 6.2.1.2, C99 6.3.1.3).}
230
 
231
For conversion to a type of width @math{N}, the value is reduced
232
modulo @math{2^N} to be within range of the type; no signal is raised.
233
 
234
@item
235
@cite{The results of some bitwise operations on signed integers (C90
236
6.3, C99 6.5).}
237
 
238
Bitwise operators act on the representation of the value including
239
both the sign and value bits, where the sign bit is considered
240
immediately above the highest-value value bit.  Signed @samp{>>} acts
241
on negative numbers by sign extension.
242
 
243
GCC does not use the latitude given in C99 only to treat certain
244
aspects of signed @samp{<<} as undefined, but this is subject to
245
change.
246
 
247
@item
248
@cite{The sign of the remainder on integer division (C90 6.3.5).}
249
 
250
GCC always follows the C99 requirement that the result of division is
251
truncated towards zero.
252
 
253
@end itemize
254
 
255
@node Floating point implementation
256
@section Floating point
257
 
258
@itemize @bullet
259
@item
260
@cite{The accuracy of the floating-point operations and of the library
261
functions in @code{<math.h>} and @code{<complex.h>} that return floating-point
262
results (C90 and C99 5.2.4.2.2).}
263
 
264
The accuracy is unknown.
265
 
266
@item
267
@cite{The rounding behaviors characterized by non-standard values
268
of @code{FLT_ROUNDS} @gol
269
(C90 and C99 5.2.4.2.2).}
270
 
271
GCC does not use such values.
272
 
273
@item
274
@cite{The evaluation methods characterized by non-standard negative
275
values of @code{FLT_EVAL_METHOD} (C99 5.2.4.2.2).}
276
 
277
GCC does not use such values.
278
 
279
@item
280
@cite{The direction of rounding when an integer is converted to a
281
floating-point number that cannot exactly represent the original
282
value (C90 6.2.1.3, C99 6.3.1.4).}
283
 
284
C99 Annex F is followed.
285
 
286
@item
287
@cite{The direction of rounding when a floating-point number is
288
converted to a narrower floating-point number (C90 6.2.1.4, C99
289
6.3.1.5).}
290
 
291
C99 Annex F is followed.
292
 
293
@item
294
@cite{How the nearest representable value or the larger or smaller
295
representable value immediately adjacent to the nearest representable
296
value is chosen for certain floating constants (C90 6.1.3.1, C99
297
6.4.4.2).}
298
 
299
C99 Annex F is followed.
300
 
301
@item
302
@cite{Whether and how floating expressions are contracted when not
303
disallowed by the @code{FP_CONTRACT} pragma (C99 6.5).}
304
 
305
Expressions are currently only contracted if
306
@option{-funsafe-math-optimizations} or @option{-ffast-math} are used.
307
This is subject to change.
308
 
309
@item
310
@cite{The default state for the @code{FENV_ACCESS} pragma (C99 7.6.1).}
311
 
312
This pragma is not implemented, but the default is to ``off'' unless
313
@option{-frounding-math} is used in which case it is ``on''.
314
 
315
@item
316
@cite{Additional floating-point exceptions, rounding modes, environments,
317
and classifications, and their macro names (C99 7.6, C99 7.12).}
318
 
319
This is dependent on the implementation of the C library, and is not
320
defined by GCC itself.
321
 
322
@item
323
@cite{The default state for the @code{FP_CONTRACT} pragma (C99 7.12.2).}
324
 
325
This pragma is not implemented.  Expressions are currently only
326
contracted if @option{-funsafe-math-optimizations} or
327
@option{-ffast-math} are used.  This is subject to change.
328
 
329
@item
330
@cite{Whether the ``inexact'' floating-point exception can be raised
331
when the rounded result actually does equal the mathematical result
332
in an IEC 60559 conformant implementation (C99 F.9).}
333
 
334
This is dependent on the implementation of the C library, and is not
335
defined by GCC itself.
336
 
337
@item
338
@cite{Whether the ``underflow'' (and ``inexact'') floating-point
339
exception can be raised when a result is tiny but not inexact in an
340
IEC 60559 conformant implementation (C99 F.9).}
341
 
342
This is dependent on the implementation of the C library, and is not
343
defined by GCC itself.
344
 
345
@end itemize
346
 
347
@node Arrays and pointers implementation
348
@section Arrays and pointers
349
 
350
@itemize @bullet
351
@item
352
@cite{The result of converting a pointer to an integer or
353
vice versa (C90 6.3.4, C99 6.3.2.3).}
354
 
355
A cast from pointer to integer discards most-significant bits if the
356
pointer representation is larger than the integer type,
357
sign-extends@footnote{Future versions of GCC may zero-extend, or use
358
a target-defined @code{ptr_extend} pattern.  Do not rely on sign extension.}
359
if the pointer representation is smaller than the integer type, otherwise
360
the bits are unchanged.
361
@c ??? We've always claimed that pointers were unsigned entities.
362
@c Shouldn't we therefore be doing zero-extension?  If so, the bug
363
@c is in convert_to_integer, where we call type_for_size and request
364
@c a signed integral type.  On the other hand, it might be most useful
365
@c for the target if we extend according to POINTERS_EXTEND_UNSIGNED.
366
 
367
A cast from integer to pointer discards most-significant bits if the
368
pointer representation is smaller than the integer type, extends according
369
to the signedness of the integer type if the pointer representation
370
is larger than the integer type, otherwise the bits are unchanged.
371
 
372
When casting from pointer to integer and back again, the resulting
373
pointer must reference the same object as the original pointer, otherwise
374
the behavior is undefined.  That is, one may not use integer arithmetic to
375
avoid the undefined behavior of pointer arithmetic as proscribed in
376
C99 6.5.6/8.
377
 
378
@item
379
@cite{The size of the result of subtracting two pointers to elements
380
of the same array (C90 6.3.6, C99 6.5.6).}
381
 
382
The value is as specified in the standard and the type is determined
383
by the ABI@.
384
 
385
@end itemize
386
 
387
@node Hints implementation
388
@section Hints
389
 
390
@itemize @bullet
391
@item
392
@cite{The extent to which suggestions made by using the @code{register}
393
storage-class specifier are effective (C90 6.5.1, C99 6.7.1).}
394
 
395
The @code{register} specifier affects code generation only in these ways:
396
 
397
@itemize @bullet
398
@item
399
When used as part of the register variable extension, see
400
@ref{Explicit Reg Vars}.
401
 
402
@item
403
When @option{-O0} is in use, the compiler allocates distinct stack
404
memory for all variables that do not have the @code{register}
405
storage-class specifier; if @code{register} is specified, the variable
406
may have a shorter lifespan than the code would indicate and may never
407
be placed in memory.
408
 
409
@item
410
On some rare x86 targets, @code{setjmp} doesn't save the registers in
411
all circumstances.  In those cases, GCC doesn't allocate any variables
412
in registers unless they are marked @code{register}.
413
 
414
@end itemize
415
 
416
@item
417
@cite{The extent to which suggestions made by using the inline function
418
specifier are effective (C99 6.7.4).}
419
 
420
GCC will not inline any functions if the @option{-fno-inline} option is
421
used or if @option{-O0} is used.  Otherwise, GCC may still be unable to
422
inline a function for many reasons; the @option{-Winline} option may be
423
used to determine if a function has not been inlined and why not.
424
 
425
@end itemize
426
 
427
@node Structures unions enumerations and bit-fields implementation
428
@section Structures, unions, enumerations, and bit-fields
429
 
430
@itemize @bullet
431
@item
432
@cite{A member of a union object is accessed using a member of a
433
different type (C90 6.3.2.3).}
434
 
435
The relevant bytes of the representation of the object are treated as
436
an object of the type used for the access.  This may be a trap
437
representation.
438
 
439
@item
440
@cite{Whether a ``plain'' @code{int} bit-field is treated as a
441
@code{signed int} bit-field or as an @code{unsigned int} bit-field
442
(C90 6.5.2, C90 6.5.2.1, C99 6.7.2, C99 6.7.2.1).}
443
 
444
@opindex funsigned-bitfields
445
By default it is treated as @code{signed int} but this may be changed
446
by the @option{-funsigned-bitfields} option.
447
 
448
@item
449
@cite{Allowable bit-field types other than @code{_Bool}, @code{signed int},
450
and @code{unsigned int} (C99 6.7.2.1).}
451
 
452
No other types are permitted in strictly conforming mode.
453
@c Would it be better to restrict the pedwarn for other types to C90
454
@c mode and document the other types for C99 mode?
455
 
456
@item
457
@cite{Whether a bit-field can straddle a storage-unit boundary (C90
458
6.5.2.1, C99 6.7.2.1).}
459
 
460
Determined by ABI@.
461
 
462
@item
463
@cite{The order of allocation of bit-fields within a unit (C90
464
6.5.2.1, C99 6.7.2.1).}
465
 
466
Determined by ABI@.
467
 
468
@item
469
@cite{The alignment of non-bit-field members of structures (C90
470
6.5.2.1, C99 6.7.2.1).}
471
 
472
Determined by ABI@.
473
 
474
@item
475
@cite{The integer type compatible with each enumerated type (C90
476
6.5.2.2, C99 6.7.2.2).}
477
 
478
@opindex fshort-enums
479
Normally, the type is @code{unsigned int} if there are no negative
480
values in the enumeration, otherwise @code{int}.  If
481
@option{-fshort-enums} is specified, then if there are negative values
482
it is the first of @code{signed char}, @code{short} and @code{int}
483
that can represent all the values, otherwise it is the first of
484
@code{unsigned char}, @code{unsigned short} and @code{unsigned int}
485
that can represent all the values.
486
@c On a few unusual targets with 64-bit int, this doesn't agree with
487
@c the code and one of the types accessed via mode attributes (which
488
@c are not currently considered extended integer types) may be used.
489
@c If these types are made extended integer types, it would still be
490
@c the case that -fshort-enums stops the implementation from
491
@c conforming to C90 on those targets.
492
 
493
On some targets, @option{-fshort-enums} is the default; this is
494
determined by the ABI@.
495
 
496
@end itemize
497
 
498
@node Qualifiers implementation
499
@section Qualifiers
500
 
501
@itemize @bullet
502
@item
503
@cite{What constitutes an access to an object that has volatile-qualified
504
type (C90 6.5.3, C99 6.7.3).}
505
 
506
Such an object is normally accessed by pointers and used for accessing
507
hardware.  In most expressions, it is intuitively obvious what is a read
508
and what is a write.  For example
509
 
510
@smallexample
511
volatile int *dst = @var{somevalue};
512
volatile int *src = @var{someothervalue};
513
*dst = *src;
514
@end smallexample
515
 
516
@noindent
517
will cause a read of the volatile object pointed to by @var{src} and store the
518
value into the volatile object pointed to by @var{dst}.  There is no
519
guarantee that these reads and writes are atomic, especially for objects
520
larger than @code{int}.
521
 
522
However, if the volatile storage is not being modified, and the value of
523
the volatile storage is not used, then the situation is less obvious.
524
For example
525
 
526
@smallexample
527
volatile int *src = @var{somevalue};
528
*src;
529
@end smallexample
530
 
531
According to the C standard, such an expression is an rvalue whose type
532
is the unqualified version of its original type, i.e. @code{int}.  Whether
533
GCC interprets this as a read of the volatile object being pointed to or
534
only as a request to evaluate the expression for its side-effects depends
535
on this type.
536
 
537
If it is a scalar type, or on most targets an aggregate type whose only
538
member object is of a scalar type, or a union type whose member objects
539
are of scalar types, the expression is interpreted by GCC as a read of
540
the volatile object; in the other cases, the expression is only evaluated
541
for its side-effects.
542
 
543
@end itemize
544
 
545
@node Declarators implementation
546
@section Declarators
547
 
548
@itemize @bullet
549
@item
550
@cite{The maximum number of declarators that may modify an arithmetic,
551
structure or union type (C90 6.5.4).}
552
 
553
GCC is only limited by available memory.
554
 
555
@end itemize
556
 
557
@node Statements implementation
558
@section Statements
559
 
560
@itemize @bullet
561
@item
562
@cite{The maximum number of @code{case} values in a @code{switch}
563
statement (C90 6.6.4.2).}
564
 
565
GCC is only limited by available memory.
566
 
567
@end itemize
568
 
569
@node Preprocessing directives implementation
570
@section Preprocessing directives
571
 
572
@xref{Implementation-defined behavior, , Implementation-defined
573
behavior, cpp, The C Preprocessor}, for details of these aspects of
574
implementation-defined behavior.
575
 
576
@itemize @bullet
577
@item
578
@cite{How sequences in both forms of header names are mapped to headers
579
or external source file names (C90 6.1.7, C99 6.4.7).}
580
 
581
@item
582
@cite{Whether the value of a character constant in a constant expression
583
that controls conditional inclusion matches the value of the same character
584
constant in the execution character set (C90 6.8.1, C99 6.10.1).}
585
 
586
@item
587
@cite{Whether the value of a single-character character constant in a
588
constant expression that controls conditional inclusion may have a
589
negative value (C90 6.8.1, C99 6.10.1).}
590
 
591
@item
592
@cite{The places that are searched for an included @samp{<>} delimited
593
header, and how the places are specified or the header is
594
identified (C90 6.8.2, C99 6.10.2).}
595
 
596
@item
597
@cite{How the named source file is searched for in an included @samp{""}
598
delimited header (C90 6.8.2, C99 6.10.2).}
599
 
600
@item
601
@cite{The method by which preprocessing tokens (possibly resulting from
602
macro expansion) in a @code{#include} directive are combined into a header
603
name (C90 6.8.2, C99 6.10.2).}
604
 
605
@item
606
@cite{The nesting limit for @code{#include} processing (C90 6.8.2, C99
607
6.10.2).}
608
 
609
@item
610
@cite{Whether the @samp{#} operator inserts a @samp{\} character before
611
the @samp{\} character that begins a universal character name in a
612
character constant or string literal (C99 6.10.3.2).}
613
 
614
@item
615
@cite{The behavior on each recognized non-@code{STDC #pragma}
616
directive (C90 6.8.6, C99 6.10.6).}
617
 
618
@xref{Pragmas, , Pragmas, cpp, The C Preprocessor}, for details of
619
pragmas accepted by GCC on all targets.  @xref{Pragmas, , Pragmas
620
Accepted by GCC}, for details of target-specific pragmas.
621
 
622
@item
623
@cite{The definitions for @code{__DATE__} and @code{__TIME__} when
624
respectively, the date and time of translation are not available (C90
625
6.8.8, C99 6.10.8).}
626
 
627
@end itemize
628
 
629
@node Library functions implementation
630
@section Library functions
631
 
632
The behavior of most of these points are dependent on the implementation
633
of the C library, and are not defined by GCC itself.
634
 
635
@itemize @bullet
636
@item
637
@cite{The null pointer constant to which the macro @code{NULL} expands
638
(C90 7.1.6, C99 7.17).}
639
 
640
In @code{<stddef.h>}, @code{NULL} expands to @code{((void *)0)}.  GCC
641
does not provide the other headers which define @code{NULL} and some
642
library implementations may use other definitions in those headers.
643
 
644
@end itemize
645
 
646
@node Architecture implementation
647
@section Architecture
648
 
649
@itemize @bullet
650
@item
651
@cite{The values or expressions assigned to the macros specified in the
652
headers @code{<float.h>}, @code{<limits.h>}, and @code{<stdint.h>}
653
(C90 and C99 5.2.4.2, C99 7.18.2, C99 7.18.3).}
654
 
655
Determined by ABI@.
656
 
657
@item
658
@cite{The number, order, and encoding of bytes in any object
659
(when not explicitly specified in this International Standard) (C99 6.2.6.1).}
660
 
661
Determined by ABI@.
662
 
663
@item
664
@cite{The value of the result of the @code{sizeof} operator (C90
665
6.3.3.4, C99 6.5.3.4).}
666
 
667
Determined by ABI@.
668
 
669
@end itemize
670
 
671
@node Locale-specific behavior implementation
672
@section Locale-specific behavior
673
 
674
The behavior of these points are dependent on the implementation
675
of the C library, and are not defined by GCC itself.

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.