* [Bug c/16622] [C99] extern inline is handled wrong in C99 mode
[not found] <bug-16622-6528@http.gcc.gnu.org/bugzilla/>
@ 2006-03-24 13:26 ` pinskia at gcc dot gnu dot org
2006-05-04 21:57 ` geoffk at gcc dot gnu dot org
` (9 subsequent siblings)
10 siblings, 0 replies; 21+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-03-24 13:26 UTC (permalink / raw)
To: gcc-bugs
------- Comment #10 from pinskia at gcc dot gnu dot org 2006-03-24 13:26 -------
*** Bug 26841 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |algrant at acm dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16622
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug c/16622] [C99] extern inline is handled wrong in C99 mode
[not found] <bug-16622-6528@http.gcc.gnu.org/bugzilla/>
2006-03-24 13:26 ` [Bug c/16622] [C99] extern inline is handled wrong in C99 mode pinskia at gcc dot gnu dot org
@ 2006-05-04 21:57 ` geoffk at gcc dot gnu dot org
2006-05-09 8:20 ` geoffk at gcc dot gnu dot org
` (8 subsequent siblings)
10 siblings, 0 replies; 21+ messages in thread
From: geoffk at gcc dot gnu dot org @ 2006-05-04 21:57 UTC (permalink / raw)
To: gcc-bugs
------- Comment #11 from geoffk at gcc dot gnu dot org 2006-05-04 21:57 -------
I am working on this (the original reported problem).
--
geoffk at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |geoffk at gcc dot gnu dot
| |org
AssignedTo|unassigned at gcc dot gnu |geoffk at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2005-12-18 00:41:11 |2006-05-04 21:57:20
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16622
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug c/16622] [C99] extern inline is handled wrong in C99 mode
[not found] <bug-16622-6528@http.gcc.gnu.org/bugzilla/>
2006-03-24 13:26 ` [Bug c/16622] [C99] extern inline is handled wrong in C99 mode pinskia at gcc dot gnu dot org
2006-05-04 21:57 ` geoffk at gcc dot gnu dot org
@ 2006-05-09 8:20 ` geoffk at gcc dot gnu dot org
2006-10-16 21:54 ` geoffk at gcc dot gnu dot org
` (7 subsequent siblings)
10 siblings, 0 replies; 21+ messages in thread
From: geoffk at gcc dot gnu dot org @ 2006-05-09 8:20 UTC (permalink / raw)
To: gcc-bugs
------- Comment #12 from geoffk at gcc dot gnu dot org 2006-05-09 08:20 -------
Fix posted as <http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00328.html>.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16622
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug c/16622] [C99] extern inline is handled wrong in C99 mode
[not found] <bug-16622-6528@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2006-05-09 8:20 ` geoffk at gcc dot gnu dot org
@ 2006-10-16 21:54 ` geoffk at gcc dot gnu dot org
2006-11-01 4:47 ` geoffk at gcc dot gnu dot org
` (6 subsequent siblings)
10 siblings, 0 replies; 21+ messages in thread
From: geoffk at gcc dot gnu dot org @ 2006-10-16 21:54 UTC (permalink / raw)
To: gcc-bugs
--
geoffk at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16622
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug c/16622] [C99] extern inline is handled wrong in C99 mode
[not found] <bug-16622-6528@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2006-10-16 21:54 ` geoffk at gcc dot gnu dot org
@ 2006-11-01 4:47 ` geoffk at gcc dot gnu dot org
2006-11-01 4:48 ` geoffk at gcc dot gnu dot org
` (5 subsequent siblings)
10 siblings, 0 replies; 21+ messages in thread
From: geoffk at gcc dot gnu dot org @ 2006-11-01 4:47 UTC (permalink / raw)
To: gcc-bugs
------- Comment #13 from geoffk at gcc dot gnu dot org 2006-11-01 04:47 -------
Subject: Bug 16622
Author: geoffk
Date: Wed Nov 1 04:47:30 2006
New Revision: 118356
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118356
Log:
* c-decl.c (grokdeclarator): Don't set DECL_EXTERNAL on
inline static functions in c99 mode.
PR 16622
* doc/extend.texi (Inline): Update.
* c-tree.h (struct language_function): Remove field 'extern_inline'.
* c-decl.c (current_extern_inline): Delete.
(pop_scope): Adjust test for an undefined nested function.
Add warning about undeclared inline function.
(diagnose_mismatched_decls): Update comments. Disallow overriding
of inline functions in a translation unit in C99. Allow inline
declarations in C99 at any time.
(merge_decls): Boolize variables. Handle C99 'extern inline'
semantics.
(grokdeclarator): Set DECL_EXTERNAL here for functions. Handle
C99 inline semantics.
(start_function): Don't clear current_extern_inline. Don't set
DECL_EXTERNAL.
(c_push_function_context): Don't push current_extern_inline.
(c_pop_function_context): Don't restore current_extern_inline.
PR 11377
* c-typeck.c (build_external_ref): Warn about static variables
used in extern inline functions.
* c-decl.c (start_decl): Warn about static variables declared
in extern inline functions.
Added:
trunk/gcc/testsuite/gcc.dg/inline-13.c
trunk/gcc/testsuite/gcc.dg/inline-14.c
trunk/gcc/testsuite/gcc.dg/inline-15.c
trunk/gcc/testsuite/gcc.dg/inline-16.c
trunk/gcc/testsuite/gcc.dg/inline6.c
trunk/gcc/testsuite/gcc.dg/inline7.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-decl.c
trunk/gcc/c-tree.h
trunk/gcc/c-typeck.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/inline-10.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16622
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug c/16622] [C99] extern inline is handled wrong in C99 mode
[not found] <bug-16622-6528@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2006-11-01 4:47 ` geoffk at gcc dot gnu dot org
@ 2006-11-01 4:48 ` geoffk at gcc dot gnu dot org
2006-11-01 5:07 ` pinskia at gcc dot gnu dot org
` (4 subsequent siblings)
10 siblings, 0 replies; 21+ messages in thread
From: geoffk at gcc dot gnu dot org @ 2006-11-01 4:48 UTC (permalink / raw)
To: gcc-bugs
------- Comment #14 from geoffk at gcc dot gnu dot org 2006-11-01 04:48 -------
Subject: Bug 16622
Author: geoffk
Date: Wed Nov 1 04:48:15 2006
New Revision: 118357
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118357
Log:
* c-decl.c (grokdeclarator): Don't set DECL_EXTERNAL on
inline static functions in c99 mode.
PR 16622
* doc/extend.texi (Inline): Update.
* c-tree.h (struct language_function): Remove field 'extern_inline'.
* c-decl.c (current_extern_inline): Delete.
(pop_scope): Adjust test for an undefined nested function.
Add warning about undeclared inline function.
(diagnose_mismatched_decls): Update comments. Disallow overriding
of inline functions in a translation unit in C99. Allow inline
declarations in C99 at any time.
(merge_decls): Boolize variables. Handle C99 'extern inline'
semantics.
(grokdeclarator): Set DECL_EXTERNAL here for functions. Handle
C99 inline semantics.
(start_function): Don't clear current_extern_inline. Don't set
DECL_EXTERNAL.
(c_push_function_context): Don't push current_extern_inline.
(c_pop_function_context): Don't restore current_extern_inline.
PR 11377
* c-typeck.c (build_external_ref): Warn about static variables
used in extern inline functions.
* c-decl.c (start_decl): Warn about static variables declared
in extern inline functions.
Modified:
trunk/gcc/doc/extend.texi
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16622
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug c/16622] [C99] extern inline is handled wrong in C99 mode
[not found] <bug-16622-6528@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2006-11-01 4:48 ` geoffk at gcc dot gnu dot org
@ 2006-11-01 5:07 ` pinskia at gcc dot gnu dot org
2006-11-01 5:08 ` pinskia at gcc dot gnu dot org
` (3 subsequent siblings)
10 siblings, 0 replies; 21+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-11-01 5:07 UTC (permalink / raw)
To: gcc-bugs
------- Comment #15 from pinskia at gcc dot gnu dot org 2006-11-01 05:07 -------
Why was this applied without a fixincludes for glibc? and a patch to glibc?
Since GCC is the GNU Compiler Collection and glibc is the GNU libc so you need
to also fix glibc at the same time and now you just broke compiling 95% of the
programs that compile with -std=c99.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16622
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug c/16622] [C99] extern inline is handled wrong in C99 mode
[not found] <bug-16622-6528@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2006-11-01 5:07 ` pinskia at gcc dot gnu dot org
@ 2006-11-01 5:08 ` pinskia at gcc dot gnu dot org
2006-11-01 5:38 ` geoffk at gcc dot gnu dot org
` (2 subsequent siblings)
10 siblings, 0 replies; 21+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-11-01 5:08 UTC (permalink / raw)
To: gcc-bugs
------- Comment #16 from pinskia at gcc dot gnu dot org 2006-11-01 05:07 -------
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00331.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16622
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug c/16622] [C99] extern inline is handled wrong in C99 mode
[not found] <bug-16622-6528@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2006-11-01 5:08 ` pinskia at gcc dot gnu dot org
@ 2006-11-01 5:38 ` geoffk at gcc dot gnu dot org
2006-11-30 19:27 ` chaoyingfu at gcc dot gnu dot org
2008-01-11 6:05 ` pinskia at gcc dot gnu dot org
10 siblings, 0 replies; 21+ messages in thread
From: geoffk at gcc dot gnu dot org @ 2006-11-01 5:38 UTC (permalink / raw)
To: gcc-bugs
------- Comment #17 from geoffk at gcc dot gnu dot org 2006-11-01 05:38 -------
This should now be behaving correctly.
--
geoffk at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16622
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug c/16622] [C99] extern inline is handled wrong in C99 mode
[not found] <bug-16622-6528@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2006-11-01 5:38 ` geoffk at gcc dot gnu dot org
@ 2006-11-30 19:27 ` chaoyingfu at gcc dot gnu dot org
2008-01-11 6:05 ` pinskia at gcc dot gnu dot org
10 siblings, 0 replies; 21+ messages in thread
From: chaoyingfu at gcc dot gnu dot org @ 2006-11-30 19:27 UTC (permalink / raw)
To: gcc-bugs
------- Comment #18 from chaoyingfu at gcc dot gnu dot org 2006-11-30 19:25 -------
Subject: Bug 16622
Author: chaoyingfu
Date: Thu Nov 30 19:24:37 2006
New Revision: 119373
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119373
Log:
Merged revisions 118337-118377 via svnmerge from
svn+ssh://chaoyingfu@sources.redhat.com/svn/gcc/trunk
........
r118337 | charlet | 2006-10-31 12:11:46 -0800 (Tue, 31 Oct 2006) | 2 lines
Resync.
........
r118338 | fxcoudert | 2006-10-31 12:15:22 -0800 (Tue, 31 Oct 2006) | 12 lines
PR fortran/29067
* decl.c (gfc_set_constant_character_len): NULL-terminate the
character constant string.
* data.c (create_character_intializer): Likewise.
* expr.c (gfc_simplify_expr): NULL-terminate the substring
character constant.
* primary.c (match_hollerith_constant): NULL-terminate the
character constant string.
* gfortran.dg/pr29067.f: New test.
........
r118339 | fxcoudert | 2006-10-31 12:17:11 -0800 (Tue, 31 Oct 2006) | 2 lines
* ChangeLog: Forgotten ChangeLog entry for previous commit.
........
r118340 | charlet | 2006-10-31 12:43:39 -0800 (Tue, 31 Oct 2006) | 2 lines
Fix typo.
........
r118341 | tkoenig | 2006-10-31 12:58:26 -0800 (Tue, 31 Oct 2006) | 18 lines
2006-10-31 Thomas Koenig <Thomas.Koenig@online.de>
PR libfortran/29627
* libgfortran.h: Add ERROR_SHORT_RECORD
* runtime/error.c (translate_error): Add case
for ERROR_SHORT_RECORD.
* io/transfer.c (read_block_direct): Separate codepaths
for stream and record unformatted I/O. Remove unneeded
tests for standard input, padding and formatted I/O.
If the record is short, read in as much data as possible,
then raise the error.
2006-10-31 Thomas Koenig <Thomas.Koenig@online.de>
PR libfortran/29627
* gfortran.dg/unf_short_record_1.f90: New test.
........
r118343 | sje | 2006-10-31 14:28:18 -0800 (Tue, 31 Oct 2006) | 4 lines
* inclhack.def (hpux11_extern_sendfile): New.
(hpux11_extern_sendpath): New.
* fixincl.x: Regenerate.
........
r118344 | ebotcazou | 2006-10-31 15:29:06 -0800 (Tue, 31 Oct 2006) | 3 lines
* gcc.c-torture/execute/20061031-1.c: New test.
........
r118347 | aldot | 2006-10-31 15:38:58 -0800 (Tue, 31 Oct 2006) | 20 lines
fortran/ChangeLog:
2006-11-01 Bernhard Fischer <aldot@gcc.gnu.org>
PR fortran/29537
* trans-common.c (gfc_trans_common): If the blank common is
in a procedure or program without a name then proc_name is null, so
use
the locus of the common.
(gfc_sym_mangled_common_id): Fix whitespace.
* match.c (gfc_match_common): Emit warning about blank common in
block data.
testsuite/ChangeLog:
2006-11-01 Bernhard Fischer <aldot@gcc.gnu.org>
PR fortran/29537
* gfortran.dg/blockdata_1.f90: Add warning about blank common in
block
data.
* gfortran.dg/blockdata_2.f90: New testcase.
........
r118353 | gccadmin | 2006-10-31 16:17:53 -0800 (Tue, 31 Oct 2006) | 1 line
Daily bump.
........
r118355 | sayle | 2006-10-31 18:56:45 -0800 (Tue, 31 Oct 2006) | 10 lines
PR middle-end/23470
* tree.h (tree_expr_nonnegative_p): Return "bool" instead of "int".
* fold-const.c (tree_expr_nonnegative_p): Likewise. Consider
pow(x,y) and powi(x,y) to be nonnegative if either x is nonnegative
or y is an even integer.
* gcc.dg/pr23470-1.c: New test case.
........
r118356 | geoffk | 2006-10-31 20:47:30 -0800 (Tue, 31 Oct 2006) | 27 lines
* c-decl.c (grokdeclarator): Don't set DECL_EXTERNAL on
inline static functions in c99 mode.
PR 16622
* doc/extend.texi (Inline): Update.
* c-tree.h (struct language_function): Remove field 'extern_inline'.
* c-decl.c (current_extern_inline): Delete.
(pop_scope): Adjust test for an undefined nested function.
Add warning about undeclared inline function.
(diagnose_mismatched_decls): Update comments. Disallow overriding
of inline functions in a translation unit in C99. Allow inline
declarations in C99 at any time.
(merge_decls): Boolize variables. Handle C99 'extern inline'
semantics.
(grokdeclarator): Set DECL_EXTERNAL here for functions. Handle
C99 inline semantics.
(start_function): Don't clear current_extern_inline. Don't set
DECL_EXTERNAL.
(c_push_function_context): Don't push current_extern_inline.
(c_pop_function_context): Don't restore current_extern_inline.
PR 11377
* c-typeck.c (build_external_ref): Warn about static variables
used in extern inline functions.
* c-decl.c (start_decl): Warn about static variables declared
in extern inline functions.
........
r118357 | geoffk | 2006-10-31 20:48:15 -0800 (Tue, 31 Oct 2006) | 27 lines
* c-decl.c (grokdeclarator): Don't set DECL_EXTERNAL on
inline static functions in c99 mode.
PR 16622
* doc/extend.texi (Inline): Update.
* c-tree.h (struct language_function): Remove field 'extern_inline'.
* c-decl.c (current_extern_inline): Delete.
(pop_scope): Adjust test for an undefined nested function.
Add warning about undeclared inline function.
(diagnose_mismatched_decls): Update comments. Disallow overriding
of inline functions in a translation unit in C99. Allow inline
declarations in C99 at any time.
(merge_decls): Boolize variables. Handle C99 'extern inline'
semantics.
(grokdeclarator): Set DECL_EXTERNAL here for functions. Handle
C99 inline semantics.
(start_function): Don't clear current_extern_inline. Don't set
DECL_EXTERNAL.
(c_push_function_context): Don't push current_extern_inline.
(c_pop_function_context): Don't restore current_extern_inline.
PR 11377
* c-typeck.c (build_external_ref): Warn about static variables
used in extern inline functions.
* c-decl.c (start_decl): Warn about static variables declared
in extern inline functions.
........
r118358 | geoffk | 2006-10-31 20:53:33 -0800 (Tue, 31 Oct 2006) | 3 lines
PR 15834
* config/darwin.h (NO_IMPLICIT_EXTERN_C): Define.
........
r118359 | geoffk | 2006-10-31 20:55:19 -0800 (Tue, 31 Oct 2006) | 7 lines
* config/i386/darwin.h (PREFERRED_DEBUGGING_TYPE): Remove.
* config/darwin.h (PREFERRED_DEBUGGING_TYPE): Set to DWARF2_DEBUG.
* config/darwin.h (LINK_COMMAND_SPEC): Don't do weird things with -@.
Call dsymutil when compiling and linking one or more source files
in one step.
........
r118360 | geoffk | 2006-10-31 21:06:12 -0800 (Tue, 31 Oct 2006) | 23 lines
In gcc/:
* coverage.c (coverage_checksum_string): Update comment.
* dwarf2out.c (switch_to_eh_frame_section): Update for removal
of get_file_function_name.
* cgraphunit.c (cgraph_build_static_cdtor): Update for rename
of get_file_function_name_long.
* tree.c (get_file_function_name): Rename from
get_file_function_name_long; improve comment; handle 'I' and 'D'
specially when the target has ctor/dtor support; remove special
handling for 'F'.
(get_file_function_name): Remove.
* tree.h (get_file_function_name): Rename from
get_file_function_name_long.
(get_file_function_name): Remove prototype.
In gcc/cp/:
* name-lookup.c (get_anonymous_namespace_name): New.
(push_namespace_with_attribs): Use get_anonymous_namespace_name.
* decl2.c (start_objects): Update for rename of
get_file_function_name_long.
In gcc/fortran/:
* trans-decl.c (gfc_generate_constructors): Update for removal
of get_file_function_name.
........
r118361 | geoffk | 2006-10-31 21:14:40 -0800 (Tue, 31 Oct 2006) | 49 lines
2006-09-07 Eric Christopher <echristo@apple.com>
Falk Hueffner <falk@debian.org>
* doc/extend.texi (__builtin_bswap32): Document.
(__builtin_bswap64): Ditto.
* doc/libgcc.texi (bswapsi2): Document.
(bswapdi2): Ditto.
* doc/rtl.texi (bswap): Document.
* optabs.c (expand_unop): Don't widen a bswap.
(init_optabs): Init bswap. Set libfuncs explicitly
for bswapsi2 and bswapdi2.
* optabs.h (OTI_bswap): New.
(bswap_optab): Ditto.
* genopinit.c (optabs): Handle bswap_optab.
* tree.h (tree_index): Add TI_UINT32_TYPE and
TI_UINT64_TYPE.
(uint32_type_node): New.
(uint64_type_node): Ditto.
* tree.c (build_common_tree_nodes_2): Initialize
uint32_type_node and uint64_type_node.
* builtins.c (expand_builtin_bswap): New.
(expand_builtin): Call.
(fold_builtin_bswap): New.
(fold_builtin_1): Call.
* fold-const.c (tree_expr_nonnegative_p): Return true
for bswap.
* builtin-types.def (BT_UINT32): New.
(BT_UINT64): Ditto.
(BT_FN_UINT32_UINT32): Ditto.
(BT_FN_UINT64_UINT64): Ditto.
* builtins.def (BUILT_IN_BSWAP32): New.
(BUILT_IN_BSWAP64): Ditto.
* rtl.def (BSWAP): New.
* genattrtab.c (check_attr_value): New.
* libgcc2.c (__bswapSI2): New.
(__bswapDI2): Ditto.
* libgcc2.h (__bswapSI2): Declare.
(__bswapDI2): Ditto.
* mklibgcc.in (lib2funcs): Add _bswapsi2 and _bswapdi2.
* simplify-rtx.c (simplify_const_unary_operation): Return
0 for BSWAP.
* libgcc-std.ver (__bwapsi2): Add.
(__bswapdi2): Ditto.
* reload1.c (eliminate_regs_1): Add bswap.
(elimination_effects): Ditto.
* config/i386/i386.h (x86_bswap): New.
(TARGET_BSWAP): Use.
* config/i386/i386.c (x86_bswap): Set.
........
r118362 | geoffk | 2006-10-31 21:16:14 -0800 (Tue, 31 Oct 2006) | 12 lines
In gcc/:
* toplev.c (compile_file): Call final_write_globals
even if there have been errors.
In gcc/cp/:
* decl2.c (cp_write_global_declarations): Rename from
cp_finish_file.
* cp-lang.c (finish_file): Don't call cp_finish_file.
* cp-tree.h (cp_write_global_declarations): Rename from
cp_finish_file.
* cp-objcp-common.h (LANG_HOOKS_WRITE_GLOBALS): Define to
cp_write_global_declarations.
........
r118363 | geoffk | 2006-10-31 21:17:14 -0800 (Tue, 31 Oct 2006) | 1 line
Add missing genopinit.c change for revision 118361.
........
r118364 | geoffk | 2006-10-31 21:20:05 -0800 (Tue, 31 Oct 2006) | 10 lines
2006-10-31 Eric Christopher <echristo@apple.com>
Falk Hueffner <falk@debian.org>
* gcc.dg/builtin-bswap-1.c: New.
* gcc.dg/builtin-bswap-2.c: New.
* gcc.dg/builtin-bswap-3.c: New.
* gcc.dg/builtin-bswap-4.c: New.
* gcc.dg/builtin-bswap-5.c: New.
* gcc.target/i386/builtin-bswap-1.c: New.
........
r118365 | geoffk | 2006-10-31 21:28:41 -0800 (Tue, 31 Oct 2006) | 28 lines
In gcc/:
PR 23067
* c-decl.c (start_struct): Don't create self-containing
structures.
* config/rs6000/rs6000.c (darwin_rs6000_special_round_type_align):
New.
* config/rs6000/rs6000-protos.h
(darwin_rs6000_special_round_type_align): New.
* config/rs6000/darwin.h (ADJUST_FIELD_ALIGN): Rewrite.
(ROUND_TYPE_ALIGN): Use darwin_rs6000_special_round_type_align.
In gcc/testsuite/:
PR 23067
* gcc.target/powerpc/darwin-abi-3.c: Remove XFAIL.
* gcc.target/powerpc/darwin-abi-6.c: Remove XFAIL.
* gcc.target/powerpc/darwin-abi-7.c: Remove XFAIL.
* gcc.target/powerpc/darwin-abi-8.c: Remove XFAIL.
* gcc.target/powerpc/darwin-abi-9.c: Remove XFAIL.
* gcc.target/powerpc/darwin-abi-10.c: Remove XFAIL.
* gcc.target/powerpc/darwin-abi-11.c: Remove XFAIL.
In libobjc/:
* encoding.c (darwin_rs6000_special_round_type_align): New.
In libffi/:
* src/powerpc/ffi_darwin.c (darwin_adjust_aggregate_sizes): New.
(ffi_prep_cif_machdep): Call darwin_adjust_aggregate_sizes for
Darwin.
* testsuite/libffi.call/nested_struct4.c: Remove Darwin XFAIL.
* testsuite/libffi.call/nested_struct6.c: Remove Darwin XFAIL.
........
r118366 | ghazi | 2006-10-31 21:38:21 -0800 (Tue, 31 Oct 2006) | 7 lines
* builtins.def (gamma, lgamma): Use ATTR_MATHFN_FPROUNDING_STORE.
testsuite:
* gcc.dg/torture/builtin-attr-1.c: Don't test gamma/lgamma.
* gcc.dg/torture/builtin-convert-1.c: Don't test lgamma.
........
r118367 | geoffk | 2006-10-31 21:42:01 -0800 (Tue, 31 Oct 2006) | 1 line
Fix date on ChangeLog entry
........
r118371 | dannysmith | 2006-10-31 22:23:12 -0800 (Tue, 31 Oct 2006) | 22
lines
* target.h (targetm.cxx.use_atexit_for_cxa_atexit): New target
hook.
* target-def.h: (TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT): Define
default.
* config/i386/mingw32.h (TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT):
Override default.
* doc/tm.texi (TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT): Document.
* configure.ac (use_cxa_atexit): As a special case, don't test
for libc definition of __cxa_atexit on mingw32
* configure: Regenerate.
* config.gcc (i[34567]86-pc-mingw32): Default to
enable__cxa_atexit=yes.
cp
* decl.c (get_atexit_node): Reference atexit, not __cxa_exit.
if targetm.cxx.use_atexit_for cxa_atexit.
(start_cleanup_fn): Likewise.
(register_dtor_fn): Likewise.
........
r118372 | pinskia | 2006-10-31 23:28:53 -0800 (Tue, 31 Oct 2006) | 7 lines
2006-10-31 Andrew Pinski <pinskia@gmail.com>
* doc/invoke.texi (-fkeep-inline-functions): Change "GNU C"
to "GNU C89".
........
r118373 | rguenth | 2006-11-01 03:38:06 -0800 (Wed, 01 Nov 2006) | 10 lines
2006-11-01 Richard Guenther <rguenther@suse.de>
* config/i386/i386.c (ix86_expand_rint): Fix issues with
signed zeros.
(ix86_expand_floorceildf_32): Likewise.
(ix86_expand_floorceil): Likewise.
(ix86_expand_trunc): Likewise.
* testsuite/gcc.target/i386/fpprec-1.c: New testcase.
........
r118374 | ebotcazou | 2006-11-01 03:58:18 -0800 (Wed, 01 Nov 2006) | 1 line
Fix asm string.
........
r118377 | ebotcazou | 2006-11-01 04:09:25 -0800 (Wed, 01 Nov 2006) | 3 lines
* gcc.c-torture/execute/20061101-1.c: New test.
........
Modified:
branches/fixed-point/ (props changed)
branches/fixed-point/fixincludes/ChangeLog
branches/fixed-point/fixincludes/fixincl.x
branches/fixed-point/fixincludes/inclhack.def
branches/fixed-point/gcc/ChangeLog
branches/fixed-point/gcc/DATESTAMP
branches/fixed-point/gcc/ada/ChangeLog
branches/fixed-point/gcc/ada/a-rbtgso.ads
branches/fixed-point/gcc/builtin-types.def
branches/fixed-point/gcc/builtins.c
branches/fixed-point/gcc/builtins.def
branches/fixed-point/gcc/c-decl.c
branches/fixed-point/gcc/c-tree.h
branches/fixed-point/gcc/c-typeck.c
branches/fixed-point/gcc/cgraphunit.c
branches/fixed-point/gcc/config.gcc
branches/fixed-point/gcc/config/darwin.h
branches/fixed-point/gcc/config/i386/darwin.h
branches/fixed-point/gcc/config/i386/i386.c
branches/fixed-point/gcc/config/i386/i386.h
branches/fixed-point/gcc/config/i386/mingw32.h
branches/fixed-point/gcc/config/rs6000/darwin.h
branches/fixed-point/gcc/config/rs6000/rs6000-protos.h
branches/fixed-point/gcc/config/rs6000/rs6000.c
branches/fixed-point/gcc/configure
branches/fixed-point/gcc/configure.ac
branches/fixed-point/gcc/coverage.c
branches/fixed-point/gcc/cp/ChangeLog
branches/fixed-point/gcc/cp/cp-lang.c
branches/fixed-point/gcc/cp/cp-objcp-common.h
branches/fixed-point/gcc/cp/cp-tree.h
branches/fixed-point/gcc/cp/decl.c
branches/fixed-point/gcc/cp/decl2.c
branches/fixed-point/gcc/cp/name-lookup.c
branches/fixed-point/gcc/doc/extend.texi
branches/fixed-point/gcc/doc/invoke.texi
branches/fixed-point/gcc/doc/libgcc.texi
branches/fixed-point/gcc/doc/rtl.texi
branches/fixed-point/gcc/doc/tm.texi
branches/fixed-point/gcc/dwarf2out.c
branches/fixed-point/gcc/fold-const.c
branches/fixed-point/gcc/fortran/ChangeLog
branches/fixed-point/gcc/fortran/data.c
branches/fixed-point/gcc/fortran/decl.c
branches/fixed-point/gcc/fortran/expr.c
branches/fixed-point/gcc/fortran/match.c
branches/fixed-point/gcc/fortran/primary.c
branches/fixed-point/gcc/fortran/trans-common.c
branches/fixed-point/gcc/fortran/trans-decl.c
branches/fixed-point/gcc/genattrtab.c
branches/fixed-point/gcc/genopinit.c
branches/fixed-point/gcc/libgcc-std.ver
branches/fixed-point/gcc/libgcc2.c
branches/fixed-point/gcc/libgcc2.h
branches/fixed-point/gcc/mklibgcc.in
branches/fixed-point/gcc/optabs.c
branches/fixed-point/gcc/optabs.h
branches/fixed-point/gcc/reload1.c
branches/fixed-point/gcc/rtl.def
branches/fixed-point/gcc/simplify-rtx.c
branches/fixed-point/gcc/target-def.h
branches/fixed-point/gcc/target.h
branches/fixed-point/gcc/testsuite/ChangeLog
branches/fixed-point/gcc/testsuite/gcc.dg/inline-10.c
branches/fixed-point/gcc/testsuite/gcc.dg/torture/builtin-attr-1.c
branches/fixed-point/gcc/testsuite/gcc.dg/torture/builtin-convert-1.c
branches/fixed-point/gcc/testsuite/gcc.target/powerpc/darwin-abi-10.c
branches/fixed-point/gcc/testsuite/gcc.target/powerpc/darwin-abi-11.c
branches/fixed-point/gcc/testsuite/gcc.target/powerpc/darwin-abi-3.c
branches/fixed-point/gcc/testsuite/gcc.target/powerpc/darwin-abi-6.c
branches/fixed-point/gcc/testsuite/gcc.target/powerpc/darwin-abi-7.c
branches/fixed-point/gcc/testsuite/gcc.target/powerpc/darwin-abi-8.c
branches/fixed-point/gcc/testsuite/gcc.target/powerpc/darwin-abi-9.c
branches/fixed-point/gcc/testsuite/gfortran.dg/blockdata_1.f90
branches/fixed-point/gcc/toplev.c
branches/fixed-point/gcc/tree.c
branches/fixed-point/gcc/tree.h
branches/fixed-point/libffi/ChangeLog
branches/fixed-point/libffi/src/powerpc/ffi_darwin.c
branches/fixed-point/libffi/testsuite/libffi.call/nested_struct4.c
branches/fixed-point/libffi/testsuite/libffi.call/nested_struct6.c
branches/fixed-point/libgfortran/ChangeLog
branches/fixed-point/libgfortran/io/transfer.c
branches/fixed-point/libgfortran/libgfortran.h
branches/fixed-point/libgfortran/runtime/error.c
branches/fixed-point/libobjc/ChangeLog
branches/fixed-point/libobjc/encoding.c
Propchange: branches/fixed-point/
('svnmerge-integrated' modified)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16622
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug c/16622] [C99] extern inline is handled wrong in C99 mode
[not found] <bug-16622-6528@http.gcc.gnu.org/bugzilla/>
` (9 preceding siblings ...)
2006-11-30 19:27 ` chaoyingfu at gcc dot gnu dot org
@ 2008-01-11 6:05 ` pinskia at gcc dot gnu dot org
10 siblings, 0 replies; 21+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2008-01-11 6:05 UTC (permalink / raw)
To: gcc-bugs
------- Comment #18 from pinskia at gcc dot gnu dot org 2008-01-11 04:50 -------
>2 -- What does constraint #3 of section 6.7.4 mean?
It is not fully as 6.7.4/3 is not diagnosed, I filed this as PR 34735.
I guess Geoff forgot about this constraint.
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
BugsThisDependsOn| |34735
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16622
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug c/16622] [C99] extern inline is handled wrong in C99 mode
2004-07-18 22:47 [Bug c/16622] New: " pinskia at gcc dot gnu dot org
@ 2004-07-18 22:55 ` jsm at polyomino dot org dot uk
2004-07-18 22:59 ` pinskia at gcc dot gnu dot org
` (8 subsequent siblings)
9 siblings, 0 replies; 21+ messages in thread
From: jsm at polyomino dot org dot uk @ 2004-07-18 22:55 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From jsm at polyomino dot org dot uk 2004-07-18 22:55 -------
Subject: Re: New: [C99] extern inline is handled wrong in C99
mode
Looks just the same as bugs 10488 and 10489 (closed) to me, they should
probably be marked as duplicates of this or reopened and vice versa.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16622
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug c/16622] [C99] extern inline is handled wrong in C99 mode
2004-07-18 22:47 [Bug c/16622] New: " pinskia at gcc dot gnu dot org
2004-07-18 22:55 ` [Bug c/16622] " jsm at polyomino dot org dot uk
@ 2004-07-18 22:59 ` pinskia at gcc dot gnu dot org
2004-07-18 23:00 ` pinskia at gcc dot gnu dot org
` (7 subsequent siblings)
9 siblings, 0 replies; 21+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-07-18 22:59 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-07-18 22:59 -------
*** Bug 10488 has been marked as a duplicate of this bug. ***
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |david dot moore at intel dot
| |com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16622
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug c/16622] [C99] extern inline is handled wrong in C99 mode
2004-07-18 22:47 [Bug c/16622] New: " pinskia at gcc dot gnu dot org
2004-07-18 22:55 ` [Bug c/16622] " jsm at polyomino dot org dot uk
2004-07-18 22:59 ` pinskia at gcc dot gnu dot org
@ 2004-07-18 23:00 ` pinskia at gcc dot gnu dot org
2004-08-07 0:05 ` hozelda at yahoo dot com
` (6 subsequent siblings)
9 siblings, 0 replies; 21+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-07-18 23:00 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-07-18 23:00 -------
Confirmed based on that other bug and <http://gcc.gnu.org/c99status.html>.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed| |1
Last reconfirmed|0000-00-00 00:00:00 |2004-07-18 23:00:34
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16622
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug c/16622] [C99] extern inline is handled wrong in C99 mode
2004-07-18 22:47 [Bug c/16622] New: " pinskia at gcc dot gnu dot org
` (2 preceding siblings ...)
2004-07-18 23:00 ` pinskia at gcc dot gnu dot org
@ 2004-08-07 0:05 ` hozelda at yahoo dot com
2004-08-07 8:18 ` jsm at polyomino dot org dot uk
` (5 subsequent siblings)
9 siblings, 0 replies; 21+ messages in thread
From: hozelda at yahoo dot com @ 2004-08-07 0:05 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From hozelda at yahoo dot com 2004-08-07 00:05 -------
Outline:
-1 -- Pre-Summary [this and the Summary constitute the Executive Summary]
0 -- Summary
1 -- What is an inline definition?
2 -- What does constraint #3 of section 6.7.4 mean?
3 -- Some other notes about inline.
4 -- Disclaimer
-1 -- Pre-Summary
If bug report #11377 comment #2 is (completely) correct, then that would
appear to explain away this problem completely. But just in case gcc "extern
inline" != c99 "inline" __exactly, I will continue... with what I think C99 says.
I can't test the state of gcc (modern versions) as I should. The information
below would be useful to someone that wanted a second opinion on some
item or other (even if gcc was perfect). It can also be useful to glance over the
examples quickly and maybe read the Summary completely (although there
are some items not found in the Summary).
Maybe later I or someone else can so some testing of some of the trickier
points.
0 -- Summary
Only 2 types of function definitions exist: inline definitions and external
definitions (6.7.4#6 and 6.9#5). This is a partition; any definition of a function
falls into exactly one of these 2 categories.
By 6.9 and 6.9.1, every translation unit has exactly one or zero definition for a
function. This means that the same translation unit cannot have both an inline
and an external def.
File 1:
inline void f() {} //inline definition, external linkage
File 2:
extern inline void f() {} //external definition, external linkage
File 3:
static inline void g() {} //inline definition, internal linkage
File 4:
static h(void);
static inline h() {} //external definition, internal linkage
static H() {} //ditto.
//all of these four files can coexist in a program. [..even if 'g' 'h' and 'H' were 'f']
File 5
//the following 3 function definitions would all violate 6.7.4#3
// inline void f1_bad() {static a;} //violates part a
static x1;
// inline void f2_bad() {extern x1;} //violates part b
// inline void f3_bad() {x1 = 0;} //violates part b
//but the following are OK
extern inline void f() {static a; extern x1; x1=0;} //not inline def
static inline void g() {static a; extern x1; x1=0;} //not external linkage
static h(void);
static inline h() {static a; extern x1; x1=0;} //neither i.d. nor e.l.
There are other detailed examples (of different inline concepts) in the rest of
the post that may be massaged into proper gcc tests if necessary.
1 -- What is an inline definition?
>From sections 6.9 and 6.7.4 of the standard, we can conclude that all function
definitions are either "inline definitions" or otherwise they are "external
definitions." They can be one or the other but not both. [The constraint from
6.7.4#3 applies only to inline definitions (and with external linkage).]
Assuming that an identifier has at least one function definition within the
current translation unit, then there can be only one such definition and...
it is an inline definition if and only if __all of the function declarations at file
scope in that translation unit for that function identifier obey two restrictions.
First, each declaration of that function must contain the 'inline' keyword.
Second, none of the declarations can include the 'extern' keyword. [Notice that
while extern is implicit (according to 6.2.2#5) when no storage class specifier
is present, that implicitness(?) does not violate the second condition.] If either
of the two restrictions is violated, the definition is an external definition.
It is possible for an inline definition to correspond to an identifier with internal
linkage just as it can correspond to an identifier with external linkage (all
function identifiers will have linkage).
Examples:
file 1:
static inline void f() {}
extern int g() {extern f(void); return 0;}
inline void f(void);
file 2:
inline void f() {}
extern int g() {extern f(void); return 0;}
inline void f(void);
file 3:
static inline void f() {}
extern int g() {extern f(void); return 0;}
void f(void);
file 4:
inline void f() {}
extern int g() {extern f(void); return 0;}
extern inline void f(void);
f has an inline definition in files 1 and 2; it has an external definition in files 3
and 4. In all of the files, the definition for f is found in the first line (an empty
body.. for simplicity).
In file 1, we note that the first line makes f have internal linkage. There are
exactly 2 appearances of f at file scope (as is true for files 2,3, and 4) and in
each case 'inline' is used and 'extern' isn't.
In file 2, line 1 causes f to have external linkage. As with file 1, the two
declarations of f at file scope contain 'inline' but not 'extern'.
File 3 has one declaration without inline, so we have an external declaration.
The linkage of f is internal.
File 4 has one declaration with extern. This makes f's definition be external
also, and the linkage is external in this case.
2 -- What does constraint #3 of section 6.7.4 mean?
[#3] An inline definition of a function with external
linkage shall not contain a definition of a modifiable
object with static storage duration, and shall not contain a
reference to an identifier with internal linkage.
OK, from the examples above, there is only one line (out of 9) that would be
relevant to constraint #3. This would be the first line of file 2. It is a definition; it
is an inline definition; and it is one of a function with external linkage. [In this
case, there is no violation (the function is empty).]
Consider a second example [(a nontrivial) inline definition of an identifier with
external linkage.. g]:
//BEGIN File:
int x1=0, x1a;
static int x2=0;
extern int x3;
static int x4;
static int x5;
void f1(void);
static void f2(void);
inline void g() { //inline definition; external linkage.
// some declarations (potential definitions; also watch out for linkage)
extern int x1; //linkage; external linkage; not a definition.
extern int x1a; //linkage; external linkage; not a definition.
extern int x3; //linkage; external linkage; not a definition.
int x10; //no linkage. definition, but auto storage.
int x5; //no linkage. definition, but auto storage.
const static int x12 = 12; //no linkage. definition of constant object w/ static
storage duration.
// static int x11; //illegal. no linkage, but definition of modifiable object with
static storage duration.
// extern int x4; //illegal. internal linkage (though not a definition).
// other uses (no definitions, but linkage is still an issue)
x1=5; //x1: external linkage.
f1(); //f1: external linkage.
x5=5; //x5: external linkage.
// x2=5; //illegal. x2: internal linkage.
// f2(); //illegal. f2: internal linkage.
}
//END File.
In this example, g has an inline definition. Within its body, we look at each
identifier and ask two questions which can be categorized as (a) is this an
object that is being defined? if so... and (b) does the identifier have internal
linkage?
I had some trouble with the wording on the linkage test portion (part b): "and
shall not contain a reference to an identifier with internal linkage."
[First, I'd note that the "shall" in each of the two parts of this constraint means
that if there is a failure of either part then gcc must produce a diagnostic.]
What troubled me was the word "reference." I searched through most of the
standard and there were a number of cases where this word appeared and
was used with its customary English language meaning as in "there was a
reference to the other bug report" or "forward references." In the other cases,
the meaning was the technical meaning as in the definition in 6.2.5#20 of
"referenced type," which relates to (C language) pointers. In yet other cases
(such as this one), the meaning was ambiguous. In the end, I felt that the
intent here was the English meaning. In fact, 6.7.4#8 uses the English
common meaning.
It makes more sense to see it as that. The idea is that an inline definition must
not have any semantic differences than the external definition found in some
other translation unit because for every call within a t-u (translation unit) that
has an inline definition, either the inline or external version can be used
(neither need be "inlined" yet either could be).
By disallowing the programmer to "use" or "access" or "reference" an identifier
with internal linkage, there is one less class of potential problems since the
external definition would never be able to access those values (except as
mentioned in the next paragraph).. values which are retained through function
calls (state).
What if a pointer reference (or ref to ref to ...) to such an identifier is passed to
the function... well, that would be ok because either function would get that
reference. In the other cases where there could be an effect, the identifier
would have to literally appear within the body and that is what I think #3
prohibits (its appearance).
*** [Using this understanding of "reference" ...] Within a function such as 'g'
(inline def/ exte link), gcc would need to verify the linkage of every identifier it
came across no matter how deeply nested (within a declaration or within a
statement). This is right, no?
3 -- Some other notes about inline.
**
With very few exceptions, the following statements are true:
-- there is exactly one external definition for each function (or object, but the
focus on functions is because inline definition only applies to functions) with
external linkage, within an entire program.
-- there can be as little as zero and as many as N-1 inline definitions for a
function identifier of external linkage for a program composed of N translation
units.
**
There is nothing in the std (that I could find) about inline being part of the type
of a function; thus, compatibility and compositeness do not factor in, I don't
think. This also means that gcc should accept an inline function declaration
even after calls to it were already made (earlier in source) based on
non-inlined declarations. Inline is a hint, in any case, and gcc can inline or fail
to inline with or without that hint (external definitions would have to be
created/exported but this would have been done since the earlier
declarations, by assumption, were not inline). In the other case, where inline
appears and then disappears, that should be accepted just as readily except
that a prior potential inline definition would then be known not to be one, so
gcc had better be able to build the function body for export use (ie, gcc cannot
know until the end of the translation unit, whether or not any given function
definition was an inline definition).
**
Related to the above, an "inline function" is defined in 6.7.4#5 but in terms of
"function," which is not defined. The Std defined function type, function call,
etc, but not function. My guess is that this is further evidence that type is not
affected by "inline" and this definition is a general usage, working definition,
whose precise meaning probably doesn't impact any part of the Standard
except trivially. [Am I right? Did I make sense?] ..so as stated before, it should
not matter when inline appears in a declaration, even if earlier declarations
differed. Inline is a property of the function which, unlike type, is independent
of the precise appearance of the declaration in order to determine applicable
rules at that point (i.e., you can't have incompleteness or undefinedness
because of inline only).
[Tests for potential warnings/errors not provide]
**
6.9#5 footnote 136 (which is not normative -- Foreword#6 --> Part 3 ISO/IEC
Directives (?)) may be in conflict with 6.7.4#6 as follows... 6.9#5 allows for
function identifiers with external linkage to appear 0 or 1 time w/in the
program. 6.7.4#6 says that external linkage function identifiers declared with
inline must have definition (inline def or external def, regardless) found within
the translation unit. These are consistent; what is not consistent is that
footnote 136 draws the conclusion that all external linkage identifiers (eg,
external linkage inline function, such as either of the 'f' functions in File 1 or
File 2 of the Summary) that do not appear within any expressions need not
have any definitions (..despite having been declared). This seems to be
contrary to 6.7.4#6... if but in a very, very technical way, that doesn't affect
99.99999% of programs.
**
If the following aren't part of gcc tests (?), they can be added
>> inline int main () {} //should fail (and does): because of 6.7.4#4
>> inline int main (void); //should fail: see previous
>> inline int main (void); //need not fail: for any particular freestanding
environment. i.e., the previous 2 assumed a hosted environment.
>> inline inline void foo() {} //should pass: despite inline repetition.
4 -- Disclaimer
I did not really test the above examples with gcc 3.2.2 (which is what I have). I
would prefer to test once I have a newer gcc, especially since I expect any
number of the tests to fail (I am also not up to speed on interpreting
object/assembly output).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16622
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug c/16622] [C99] extern inline is handled wrong in C99 mode
2004-07-18 22:47 [Bug c/16622] New: " pinskia at gcc dot gnu dot org
` (3 preceding siblings ...)
2004-08-07 0:05 ` hozelda at yahoo dot com
@ 2004-08-07 8:18 ` jsm at polyomino dot org dot uk
2004-08-08 21:51 ` hozelda at yahoo dot com
` (4 subsequent siblings)
9 siblings, 0 replies; 21+ messages in thread
From: jsm at polyomino dot org dot uk @ 2004-08-07 8:18 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From jsm at polyomino dot org dot uk 2004-08-07 08:18 -------
Subject: Re: [C99] extern inline is handled wrong in C99 mode
On Sat, 7 Aug 2004, hozelda at yahoo dot com wrote:
> By 6.9 and 6.9.1, every translation unit has exactly one or zero definition for a
> function. This means that the same translation unit cannot have both an inline
> and an external def.
I don't see how you deduce this. I agree it's the intent, but I see
nothing in the text of the standard that specifically prohibits having
both inline and external definitions in a translation unit, just the
presumption in 6.7.4#6 that there is just one definition of the function
in the TU. I mentioned this in an aside to my pre-DR#2 that I sent to the
gcc list some time ago <http://www.srcf.ucam.org/~jsm28/gcc/pre-dr-2.txt>.
This would also be one of the incompatibilities between C99 and gnu89, as
GCC has allowed both inline and external definitions while the intent of
C99 seems to be not to allow them. Thus, one more potential problem to
fix in glibc should C99 inline be implemented in GCC.
> *** [Using this understanding of "reference" ...] Within a function such as 'g'
> (inline def/ exte link), gcc would need to verify the linkage of every identifier it
> came across no matter how deeply nested (within a declaration or within a
> statement). This is right, no?
Including those inside sizeof. I don't think this is a tricky
interpretative issue. If, in the inline definition, the identifier is
used (in the name space of ordinary identifiers) while the internal
linkage declaration is in scope, or declared as extern while that
declaration is in scope (so linking to the previous internal linkage
declaration), this is a constraint violation. If it is used in another
namespace, or redeclared as an identifier with no linkage, there is no
problem. If it is declared with external linkage in a scope where the
internal linkage declaration is hidden, this is compile-time undefined
behavior and an error is permitted though not required.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16622
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug c/16622] [C99] extern inline is handled wrong in C99 mode
2004-07-18 22:47 [Bug c/16622] New: " pinskia at gcc dot gnu dot org
` (4 preceding siblings ...)
2004-08-07 8:18 ` jsm at polyomino dot org dot uk
@ 2004-08-08 21:51 ` hozelda at yahoo dot com
2004-08-08 22:38 ` jsm at polyomino dot org dot uk
` (3 subsequent siblings)
9 siblings, 0 replies; 21+ messages in thread
From: hozelda at yahoo dot com @ 2004-08-08 21:51 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From hozelda at yahoo dot com 2004-08-08 21:51 -------
(In reply to comment #5)
> Subject: Re: [C99] extern inline is handled wrong in C99 mode
>
> On Sat, 7 Aug 2004, hozelda at yahoo dot com wrote:
>
> > By 6.9 and 6.9.1, every translation unit has exactly one or zero definition for
a
> > function. This means that the same translation unit cannot have both an
inline
> > and an external def.
>
> I don't see how you deduce this. I agree it's the intent, but I see
> nothing in the text of the standard that specifically prohibits having
> both inline and external definitions in a translation unit, just the
> presumption in 6.7.4#6 that there is just one definition of the function
> in the TU. I mentioned this in an aside to my pre-DR#2 that I sent to the
> gcc list some time ago <http://www.srcf.ucam.org/~jsm28/gcc/pre-dr-2.txt>.
>
> This would also be one of the incompatibilities between C99 and gnu89, as
> GCC has allowed both inline and external definitions while the intent of
> C99 seems to be not to allow them. Thus, one more potential problem to
> fix in glibc should C99 inline be implemented in GCC.
>
I was a little sloppy to extend 6.9xxx to inline definitions. [The message posted
was also a learning process for me and I didn't re-evaluate some held
assumptions as much as I should have.]
6.7.4#6 says, "an inline definition ... does not forbid an external definition in
__another__ translation unit."
6.7.4#8 says, "Because cels [which has an inline definition] has external
linkage and is referenced, an external definition has to appear in another
translation unit...."
#6 does not place any requirements; the wording simply seems to suggest that
such a requirement already existed.
#8 doesn't place a requirement either but the wording is as if such a
requirement was in place so that its conclusion can be drawn. I would say that
#8 by itself would mean that inline definitions and external definitions (for same
identifier) cannot co-exhist in the same translation unit (if perhaps in need of
rewording as a rule elsewhere), except that it seems to be an extension of the
#7 Example, which would then not be normative.
My guess is that the intention is to have at most either one ID or else one ED
per t-u. If that was the intention, then there appears to be a defect in the
Standard, as it cannot be derived from any normative portion, at least as I read
6.9/6.9.1 and 6.7.4. If the intention, instead, is to allow >1 ID and possibly an
ED (per t-u), then the Standard seems ok except that the wording (of the
examples #7/#8) should probably eventually be fixed.
Thus I think you are completely right if the above is all that there is to it.
The link you posted is very interesting (well, if one is looking to get to the
bottom of things). I'll spend more time with it later. I do know that I thought
originally that "prototype" was not evolved/defined as well as it should have
been, but eventually I came to just accept certain understandings of it.. I'll revisit
that, I guess, especially since you seem to have pinpointed some precise
items.
> > *** [Using this understanding of "reference" ...] Within a function such as 'g'
> > (inline def/ exte link), gcc would need to verify the linkage of every identifier
it
> > came across no matter how deeply nested (within a declaration or within a
> > statement). This is right, no?
>
> Including those inside sizeof. I don't think this is a tricky
> interpretative issue. If, in the inline definition, the identifier is
> used (in the name space of ordinary identifiers) while the internal
> linkage declaration is in scope, or declared as extern while that
> declaration is in scope (so linking to the previous internal linkage
> declaration), this is a constraint violation. If it is used in another
> namespace, or redeclared as an identifier with no linkage, there is no
> problem. If it is declared with external linkage in a scope where the
> internal linkage declaration is hidden, this is compile-time undefined
> behavior and an error is permitted though not required.
>
>
One person's garbage is another's treasure.. or something like that. Ok, that
paragraph you quoted and a few other things were last minute additions after
about a week of letting the message sit. Since I don't have that much
experience with compiler internals, it just wasn't something I had thought about
before so it seemed like a Eureka momment (I was debating over the meaning
of "reference" so ...) .. it's as if "oh, let's go back and add code (a fix) so that
every single ident is rechecked for ...." Anyway, it was "tricky" for me at that
point in time, and also there probably is nothing there that excludes sizeof or
any other case.
In general, all of these (constant) sizeof rule exceptions are a little annoying in
that they are scattered around when perhaps maybe a new concept should be
introduced (unevaluable expression.. or something like that [(aside) I think the
Java Lang std uses a similar concept and defines a lot of rules for it]).
Especially since in some cases something more general than sizeof is evoked
(with perhaps a footnote mentioning sizeof)... anyway, these are just some
thoughts.
I don't want to comment much more on what I said near the end because I
should be willing to provide specific code first, to make things concrete.
I have an unrelated question.
void *h1=0;
int (*h2)(int)=0, (*h3)(int)=0;
h2=h1; //should not be allowed but gcc 3.2.2 didn't complain
h1=h3; //should not be allowed ....
Is this legit material for a bug report (ie, is the "should not" in the comments
correct)? [I compiled the example with c99 but not with pedantic]
I don't think you can perform the 2 assignments above without a cast (and even
then, guarantees from #6.3.2.3 may be lost (eg, see #7 and #8 as a pattern)).
6.5.16.1#1 is a constraint (and "one of the following shall hold" would not be
satisfied), and I don't think void* is compatible with functype* and I don't think
functype can ever be incomplete.
There may be gaps in the std or maybe not, so unless you readily agree or
disagree, I would need to reread around and come up with specific references.
A quick question: is there a way to receive auto emails of bug reports one has
participated in (by commenting)? I didn't get jsm's comment as an email of any
sort. I checked the pref->email section of my account, but I could not find the
option.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16622
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug c/16622] [C99] extern inline is handled wrong in C99 mode
2004-07-18 22:47 [Bug c/16622] New: " pinskia at gcc dot gnu dot org
` (5 preceding siblings ...)
2004-08-08 21:51 ` hozelda at yahoo dot com
@ 2004-08-08 22:38 ` jsm at polyomino dot org dot uk
2004-08-08 23:42 ` jsm at polyomino dot org dot uk
` (2 subsequent siblings)
9 siblings, 0 replies; 21+ messages in thread
From: jsm at polyomino dot org dot uk @ 2004-08-08 22:38 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From jsm at polyomino dot org dot uk 2004-08-08 22:38 -------
Subject: Re: [C99] extern inline is handled wrong in C99 mode
On Sun, 8 Aug 2004, hozelda at yahoo dot com wrote:
> I have an unrelated question.
> void *h1=0;
> int (*h2)(int)=0, (*h3)(int)=0;
> h2=h1; //should not be allowed but gcc 3.2.2 didn't complain
> h1=h3; //should not be allowed ....
>
> Is this legit material for a bug report (ie, is the "should not" in the comments
> correct)? [I compiled the example with c99 but not with pedantic]
That's bug 11234, fixed in 3.4.0. I really don't recommend using anything
other than CVS mainline for testing conformance points. You should find
mainline significantly better than 3.4 in conformance matters although
there are many bugs and unimplemented features and little user interest in
the finer points of conformance.
> A quick question: is there a way to receive auto emails of bug reports one has
> participated in (by commenting)? I didn't get jsm's comment as an email of any
> sort. I checked the pref->email section of my account, but I could not find the
> option.
Add yourself to the CC list of the bug reports of interest. You don't
need to comment on them to do so.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16622
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug c/16622] [C99] extern inline is handled wrong in C99 mode
2004-07-18 22:47 [Bug c/16622] New: " pinskia at gcc dot gnu dot org
` (6 preceding siblings ...)
2004-08-08 22:38 ` jsm at polyomino dot org dot uk
@ 2004-08-08 23:42 ` jsm at polyomino dot org dot uk
2004-08-11 21:05 ` jsm28 at gcc dot gnu dot org
2004-09-11 22:53 ` jsm28 at gcc dot gnu dot org
9 siblings, 0 replies; 21+ messages in thread
From: jsm at polyomino dot org dot uk @ 2004-08-08 23:42 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From jsm at polyomino dot org dot uk 2004-08-08 23:42 -------
Subject: Re: [C99] extern inline is handled wrong in C99 mode
On Sun, 8 Aug 2004, hozelda at yahoo dot com wrote:
> In general, all of these (constant) sizeof rule exceptions are a little annoying in
> that they are scattered around when perhaps maybe a new concept should be
> introduced (unevaluable expression.. or something like that [(aside) I think the
With regard to this as a general point about clarifying the concepts of
the standard (and nothing much to do with the subject of this bug report),
there are many areas where the explanations given by the C standards in
English are perhaps not the best or clearest possible way of explaining
the concepts and defining the language. In some places, it may make sense
to introduce new concepts, or formalisms, to explain things (sequence
points have been an example where several competing formalisms have been
produced). In turn, while formalisms make things more precise and help
ascertain answers to subtle cases, they can rather reduce the audience who
can understand the standard. Have you read Norrish's thesis
<http://www.cl.cam.ac.uk/TechReports/UCAM-CL-TR-453.pdf> (imperfectly
formalising some aspects of a subset of C90)? Note in particular the
comment in chapter 4:
This ... tells us nothing about the quality of our semantics with
respect to the original specification .... Better would be to have the
specification of the semantics inspected by another individual who was
both familiar with the fine details of the ISO standard, and the
techniques of operational semantics. Unfortunately, such people are
hard to find, which is rather an indictment of the divergence between
theory and practice in computer science.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16622
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug c/16622] [C99] extern inline is handled wrong in C99 mode
2004-07-18 22:47 [Bug c/16622] New: " pinskia at gcc dot gnu dot org
` (7 preceding siblings ...)
2004-08-08 23:42 ` jsm at polyomino dot org dot uk
@ 2004-08-11 21:05 ` jsm28 at gcc dot gnu dot org
2004-09-11 22:53 ` jsm28 at gcc dot gnu dot org
9 siblings, 0 replies; 21+ messages in thread
From: jsm28 at gcc dot gnu dot org @ 2004-08-11 21:05 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
OtherBugsDependingO| |16989
nThis| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16622
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug c/16622] [C99] extern inline is handled wrong in C99 mode
2004-07-18 22:47 [Bug c/16622] New: " pinskia at gcc dot gnu dot org
` (8 preceding siblings ...)
2004-08-11 21:05 ` jsm28 at gcc dot gnu dot org
@ 2004-09-11 22:53 ` jsm28 at gcc dot gnu dot org
9 siblings, 0 replies; 21+ messages in thread
From: jsm28 at gcc dot gnu dot org @ 2004-09-11 22:53 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From jsm28 at gcc dot gnu dot org 2004-09-11 22:53 -------
Specific minor C99 inline points not implemented:
The diagnostic for inline main should be a pedwarn, not a warning,
but should only apply when flag_hosted.
Duplicate inline is OK in C99.
A declaration with both typedef and inline should receive an error,
as a typedef isn't an identifier for a function.
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |jsm28 at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16622
^ permalink raw reply [flat|nested] 21+ messages in thread