Bug 44426 - [4.4/4.5/4.6 Regression] gcc 4.5.0 requires c9x compiler to build
Summary: [4.4/4.5/4.6 Regression] gcc 4.5.0 requires c9x compiler to build
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 4.5.0
: P2 normal
Target Milestone: 4.4.5
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-05 14:24 UTC by Jay
Modified: 2010-06-21 17:20 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2010-06-05 14:54:40


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jay 2010-06-05 14:24:11 UTC
Surprising. I'll try 4.4.

cc -c  -g -DIN_GCC    -DHAVE_CONFIG_H -I. -I. -I/home/jayk/src/gcc-4.5.0/gcc -I/home/jayk/src/gcc-4.5.0/gcc/. -I/home/jayk/src/gcc-4.5.0/gcc/../include -I/home/jayk/src/gcc-4.5.0/gcc/../libcpp/include -I/home/jayk/include  -I/home/jayk/src/gcc-4.5.0/gcc/../libdecnumber -I/home/jayk/src/gcc-4.5.0/gcc/../libdecnumber/dpd -I../libdecnumber     /home/jayk/src/gcc-4.5.0/gcc/tree-mudflap.c -o tree-mudflap.o
cc: Warning: /home/jayk/src/gcc-4.5.0/gcc/tree.h, line 4943: Formal parameter isn't an identifier. (badformalparm)
#define build_call_expr(...)\
------------------------^
cc: Warning: /home/jayk/src/gcc-4.5.0/gcc/tree-mudflap.c, line 1262: Too many actual parameters in macro call. (toomanyactls)
  call_stmt = build_call_expr (mf_register_fndecl, 4,
-------------------------------^
cc: Warning: /home/jayk/src/gcc-4.5.0/gcc/tree-mudflap.c, line 1324: Too many actual parameters in macro call. (toomanyactls)
    tree call2_stmt = build_call_expr (mf_init_fndecl, 0);
---------------------------------------^
cc: Warning: /home/jayk/src/gcc-4.5.0/gcc/tree-mudflap.c, line 1332: Too many actual parameters in macro call. (toomanyactls)
      tree call_stmt = build_call_expr (mf_set_options_fndecl, 1, arg);
----------------------------------------^
cc: Error: /home/jayk/src/gcc-4.5.0/gcc/tree-mudflap.c, line 1262: In this statement, "__VA_ARGS__" is not declared. (undeclared)
  call_stmt = build_call_expr (mf_register_fndecl, 4,
--------------^
cc: Error: /home/jayk/src/gcc-4.5.0/gcc/tree-mudflap.c, line 1262: In this statement, "build_call_expr_loc" expects 3 arguments, but 2 are supplied. (toofewargs)
  call_stmt = build_call_expr (mf_register_fndecl, 4,
--------------^
cc: Error: /home/jayk/src/gcc-4.5.0/gcc/tree-mudflap.c, line 1324: In the initializer for call2_stmt, "__VA_ARGS__" is not declared. (undeclared)
    tree call2_stmt = build_call_expr (mf_init_fndecl, 0);
----------------------^
cc: Error: /home/jayk/src/gcc-4.5.0/gcc/tree-mudflap.c, line 1324: In the initializer for call2_stmt, "build_call_expr_loc" expects 3 arguments, but 2 are supplied. (toofewargs)
    tree call2_stmt = build_call_expr (mf_init_fndecl, 0);
----------------------^
cc: Error: /home/jayk/src/gcc-4.5.0/gcc/tree-mudflap.c, line 1332: In the initializer for call_stmt, "__VA_ARGS__" is not declared. (undeclared)
      tree call_stmt = build_call_expr (mf_set_options_fndecl, 1, arg);
-----------------------^
cc: Error: /home/jayk/src/gcc-4.5.0/gcc/tree-mudflap.c, line 1332: In the initializer for call_stmt, "build_call_expr_loc" expects 3 arguments, but 2 are supplied. (toofewargs)
      tree call_stmt = build_call_expr (mf_set_options_fndecl, 1, arg);
-----------------------^
make[3]: *** [tree-mudflap.o] Error 1


#define build_call_expr(...)\
   build_call_expr_loc (UNKNOWN_LOCATION, __VA_ARGS__)
Comment 1 Joseph S. Myers 2010-06-05 14:54:40 UTC
Appears to have been introduced by r149722.

r149722 | manu | 2009-07-16 22:29:52 +0000 (Thu, 16 Jul 2009) | 60 lines

2009-07-17  Aldy Hernandez  <aldyh@redhat.com>
            Manuel López-Ibáñez  <manu@gcc.gnu.org>

        PR 40435 
        * tree-complex.c, tree-loop-distribution.c,
        tree.c, tree.h, builtins.c, fold-const.c, omp-low.c,
        cgraphunit.c, tree-ssa-ccp.c, tree-ssa-dom.c,
        gimple-low.c, expr.c, tree-ssa-ifcombine.c, c-decl.c,
        stor-layout.c, tree-if-conv.c, c-typeck.c,
        gimplify.c, calls.c, tree-sra.c, tree-mudflap.c,
        tree-ssa-copy.c, tree-ssa-forwprop.c, c-convert.c, c-omp.c,
        varasm.c, tree-inline.c, c-common.c,
        c-common.h, gimple.c, tree-switch-conversion.c, gimple.h,
        tree-cfg.c, c-parser.c, convert.c: Add location
        argument to fold_{unary,binary,ternary}, fold_build[123],
        build_call_expr, build_size_arg, build_fold_addr_expr,
        build_call_array, non_lvalue, size_diffop,
        fold_build1_initializer, fold_build2_initializer,
        fold_build3_initializer, fold_build_call_array,
        fold_build_call_array_initializer, fold_single_bit_test,
        omit_one_operand, omit_two_operands, invert_truthvalue,
        fold_truth_not_expr, build_fold_indirect_ref, fold_indirect_ref,
        combine_comparisons, fold_builtin_*, fold_call_expr,
        build_range_check, maybe_fold_offset_to_address, round_up,
        round_down.
[...]
Comment 2 Jay 2010-06-05 15:13:47 UTC
similar with 4.4.4. I'll try 4.3. Eventually I might build but I never know the minimal set of files to get for sysroot.. :(

--------^
cc: Error: /home/jayk/src/gcc-4.4.4/gcc/sel-sched-dump.c, line 258: In the initializer for __j, "__VA_ARGS__" is not declared. (undeclared)
    sel_print ("prio:%d;", EXPR_PRIORITY (expr));
----^

bash-4.1$ grep sel_print  /home/jayk/src/gcc-4.4.4/gcc/*h              
/home/jayk/src/gcc-4.4.4/gcc/sel-sched-dump.h:#define sel_print_to_dot(...)                           \
/home/jayk/src/gcc-4.4.4/gcc/sel-sched-dump.h:#define sel_print(...)		\
/home/jayk/src/gcc-4.4.4/gcc/sel-sched-dump.h:      sel_print_to_dot (__VA_ARGS__);                   \
/home/jayk/src/gcc-4.4.4/gcc/sel-sched-dump.h:extern const char * sel_print_insn (const_rtx, int);
/home/jayk/src/gcc-4.4.4/gcc/sel-sched-dump.h:extern void sel_print_rtl (rtx x);
Comment 3 Manuel López-Ibáñez 2010-06-05 15:50:58 UTC
Do you mean we should not use VA_ARGS in GCC? Then, what? static inline? Is this warned by -pedantic? Shouldn't it?
Comment 4 joseph@codesourcery.com 2010-06-05 17:36:56 UTC
Subject: Re:  [4.5/4.6 Regression] gcc 4.5.0 requires
 c9x compiler to build

On Sat, 5 Jun 2010, manu at gcc dot gnu dot org wrote:

> Do you mean we should not use VA_ARGS in GCC? Then, what? static inline? Is
> this warned by -pedantic? Shouldn't it?

Variadic macros are not standard C90 or C++98 and should only be used 
*conditionally* if the compiler being used to build GCC supports them.  
Otherwise you need to define a function - which in practice won't be 
inline (inline variadic functions, passing on their variable arguments to 
another variadic function, require GNU extensions that are much more 
recent than variadic macros).

I think

#if GCC_VERSION >= 3000 || __STDC_VERSION__ >= 199901L

is a suitable condition for support of variadic macros.

Because these macros may be used *conditionally*, GCC is built with 
-Wno-variadic-macros.

For the cases that are inserting UNKNOWN_LOCATION, I'd suggest just 
changing all the call sites of the macro to pass UNKNOWN_LOCATION 
explicitly, and removing the macro.  That should deal with build_call_expr 
and with build_call_nofold in builtins.c.

For the cases in sel-sched-dump.h I'd suggest just using normal variadic 
functions that use interfaces such as vfprintf and vasprintf, and not 
macros at all.

Comment 5 Joseph S. Myers 2010-06-05 17:40:02 UTC
build_call_nofold in builtins.c introduced by:

r152236 | matz | 2009-09-28 12:54:23 +0000 (Mon, 28 Sep 2009) | 54 lines

        * builtins.c (interclass_mathfn_icode): New helper.
[...]

Variadic macros in sel-sched-dump.h introduced when that header was added:

r139854 | abel | 2008-09-01 08:57:00 +0000 (Mon, 01 Sep 2008) | 405 lines

2008-08-31  Andrey Belevantsev  <abel@ispras.ru>
        Dmitry Melnik  <dm@ispras.ru>
        Dmitry Zhurikhin  <zhur@ispras.ru>
        Alexander Monakov  <amonakov@ispras.ru>
        Maxim Kuvyrkov  <maxim@codesourcery.com>

        * sel-sched.h, sel-sched-dump.h, sel-sched-ir.h, sel-sched.c,
        sel-sched-dump.c, sel-sched-ir.c: New files.
[...]
Comment 6 Manuel López-Ibáñez 2010-06-05 19:04:58 UTC
(In reply to comment #4)
> Subject: Re:  [4.5/4.6 Regression] gcc 4.5.0 requires
>  c9x compiler to build
> 
> On Sat, 5 Jun 2010, manu at gcc dot gnu dot org wrote:
> 
> > Do you mean we should not use VA_ARGS in GCC? Then, what? static inline? Is
> > this warned by -pedantic? Shouldn't it?
> 
> Variadic macros are not standard C90 or C++98 and should only be used 
> *conditionally* if the compiler being used to build GCC supports them.  

Why add a conditional definition if an alternative without VA_ARGS is needed? Using VA_ARGS+alternative does not seem to give any benefits.

> I think
> 
> #if GCC_VERSION >= 3000 || __STDC_VERSION__ >= 199901L
> 
> is a suitable condition for support of variadic macros.
> 
> Because these macros may be used *conditionally*, GCC is built with 
> -Wno-variadic-macros.

I don't see the benefit on using them conditionally. I would rather not use them at all than have to fix something afterwards.

> For the cases that are inserting UNKNOWN_LOCATION, I'd suggest just 
> changing all the call sites of the macro to pass UNKNOWN_LOCATION 
> explicitly, and removing the macro.  That should deal with build_call_expr 
> and with build_call_nofold in builtins.c.

OK for me but this was done on purpose. So I won't even try to fix this until the corresponding maintainer pre-approves such patch.
 
Comment 7 Richard Biener 2010-06-05 19:10:24 UTC
(In reply to comment #6)
> (In reply to comment #4)
> > Subject: Re:  [4.5/4.6 Regression] gcc 4.5.0 requires
> >  c9x compiler to build
> > 
> > On Sat, 5 Jun 2010, manu at gcc dot gnu dot org wrote:
> > 
> > > Do you mean we should not use VA_ARGS in GCC? Then, what? static inline? Is
> > > this warned by -pedantic? Shouldn't it?
> > 
> > Variadic macros are not standard C90 or C++98 and should only be used 
> > *conditionally* if the compiler being used to build GCC supports them.  
> 
> Why add a conditional definition if an alternative without VA_ARGS is needed?
> Using VA_ARGS+alternative does not seem to give any benefits.
> 
> > I think
> > 
> > #if GCC_VERSION >= 3000 || __STDC_VERSION__ >= 199901L
> > 
> > is a suitable condition for support of variadic macros.
> > 
> > Because these macros may be used *conditionally*, GCC is built with 
> > -Wno-variadic-macros.
> 
> I don't see the benefit on using them conditionally. I would rather not use
> them at all than have to fix something afterwards.
> 
> > For the cases that are inserting UNKNOWN_LOCATION, I'd suggest just 
> > changing all the call sites of the macro to pass UNKNOWN_LOCATION 
> > explicitly, and removing the macro.  That should deal with build_call_expr 
> > and with build_call_nofold in builtins.c.
> 
> OK for me but this was done on purpose. So I won't even try to fix this until
> the corresponding maintainer pre-approves such patch.

Please instead make a static inline variadic alternative instead (so we
still use variadic macros if available).
Comment 8 Manuel López-Ibáñez 2010-06-05 19:39:40 UTC
(In reply to comment #7)
> > 
> > > For the cases that are inserting UNKNOWN_LOCATION, I'd suggest just 
> > > changing all the call sites of the macro to pass UNKNOWN_LOCATION 
> > > explicitly, and removing the macro.  That should deal with build_call_expr 
> > > and with build_call_nofold in builtins.c.
> > 
> > OK for me but this was done on purpose. So I won't even try to fix this until
> > the corresponding maintainer pre-approves such patch.
> 
> Please instead make a static inline variadic alternative instead (so we
> still use variadic macros if available).
> 

You'll have to be more specific. What is the alternative in the above case when no variadic stuff can be used? If the alternative is to change all call sites, then we do not need variadic stuff.
Comment 9 joseph@codesourcery.com 2010-06-05 21:33:27 UTC
Subject: Re:  [4.4/4.5/4.6 Regression] gcc 4.5.0 requires
 c9x compiler to build

On Sat, 5 Jun 2010, manu at gcc dot gnu dot org wrote:

> 
> 
> ------- Comment #6 from manu at gcc dot gnu dot org  2010-06-05 19:04 -------
> (In reply to comment #4)
> > Subject: Re:  [4.5/4.6 Regression] gcc 4.5.0 requires
> >  c9x compiler to build
> > 
> > On Sat, 5 Jun 2010, manu at gcc dot gnu dot org wrote:
> > 
> > > Do you mean we should not use VA_ARGS in GCC? Then, what? static inline? Is
> > > this warned by -pedantic? Shouldn't it?
> > 
> > Variadic macros are not standard C90 or C++98 and should only be used 
> > *conditionally* if the compiler being used to build GCC supports them.  
> 
> Why add a conditional definition if an alternative without VA_ARGS is needed?
> Using VA_ARGS+alternative does not seem to give any benefits.

At least in some cases for which variadic macros have been used, I suppose 
they result in a faster compiler than the alternative - for example, they 
were used when transitioning from variadic "build" to separate 
(non-variadic, so faster) buildN functions.  There may be less use for 
conditional uses in the present cases.

You can't readily use an inline function to replace the present uses of 
variadic macros; __builtin_va_arg_pack (a GNU extension) would be needed 
for a straightforward conversion.

Comment 10 Jakub Jelinek 2010-06-14 08:54:51 UTC
In sel_print* case I wonder why it is defined as macros at all, it surely bloats sel-sched* a lot for something that isn't enabled by default (verbose dumps).
Comment 11 Jakub Jelinek 2010-06-14 10:20:34 UTC
Patch for sel_print posted: http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01400.html
Comment 12 Jakub Jelinek 2010-06-14 15:54:04 UTC
Subject: Bug 44426

Author: jakub
Date: Mon Jun 14 15:53:38 2010
New Revision: 160754

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160754
Log:
	PR bootstrap/44426
	* tree.h (build_call_expr): Don't define as vararg macro, instead
	add a prototype.
	* builtins.c (build_call_nofold): Remove.
	(expand_builtin_int_roundingfn, expand_builtin_pow,
	expand_builtin_mempcpy_args, expand_builtin_stpcpy,
	expand_builtin_memset_args, expand_builtin_strcmp,
	expand_builtin_strncmp, expand_builtin_memory_chk): Use
	build_call_nofold_loc instead of build_call_nofold.
	(build_call_expr): New function.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/builtins.c
    trunk/gcc/tree.h

Comment 13 Jakub Jelinek 2010-06-14 16:01:02 UTC
Subject: Bug 44426

Author: jakub
Date: Mon Jun 14 16:00:39 2010
New Revision: 160755

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160755
Log:
	PR bootstrap/44426
	* tree.h (build_call_expr): Don't define as vararg macro, instead
	add a prototype.
	* builtins.c (build_call_nofold): Remove.
	(expand_builtin_int_roundingfn, expand_builtin_pow,
	expand_builtin_mempcpy_args, expand_builtin_stpcpy,
	expand_builtin_memset_args, expand_builtin_strcmp,
	expand_builtin_strncmp, expand_builtin_memory_chk): Use
	build_call_nofold_loc instead of build_call_nofold.
	(build_call_expr): New function.

Modified:
    branches/gcc-4_5-branch/gcc/ChangeLog
    branches/gcc-4_5-branch/gcc/builtins.c
    branches/gcc-4_5-branch/gcc/tree.h

Comment 14 Jakub Jelinek 2010-06-21 16:27:00 UTC
Subject: Bug 44426

Author: jakub
Date: Mon Jun 21 16:26:25 2010
New Revision: 161092

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161092
Log:
	PR bootstrap/44426
	* sel-sched-dump.h (sel_prepare_string_for_dot_label): Remove
	prototype.
	(sel_print_to_dot): Remove macro.
	(sel_print): Likewise.  New prototype.
	* sel-sched-dump.c (sel_prepare_string_for_dot_label): Make static.
	(sel_print): New function.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/sel-sched-dump.c
    trunk/gcc/sel-sched-dump.h

Comment 15 Jakub Jelinek 2010-06-21 17:07:08 UTC
Subject: Bug 44426

Author: jakub
Date: Mon Jun 21 17:06:48 2010
New Revision: 161100

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161100
Log:
	PR bootstrap/44426
	* sel-sched-dump.h (sel_prepare_string_for_dot_label): Remove
	prototype.
	(sel_print_to_dot): Remove macro.
	(sel_print): Likewise.  New prototype.
	* sel-sched-dump.c (sel_prepare_string_for_dot_label): Make static.
	(sel_print): New function.

Modified:
    branches/gcc-4_5-branch/gcc/ChangeLog
    branches/gcc-4_5-branch/gcc/sel-sched-dump.c
    branches/gcc-4_5-branch/gcc/sel-sched-dump.h

Comment 16 Jakub Jelinek 2010-06-21 17:11:24 UTC
Subject: Bug 44426

Author: jakub
Date: Mon Jun 21 17:10:02 2010
New Revision: 161102

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161102
Log:
	PR bootstrap/44426
	* sel-sched-dump.h (sel_prepare_string_for_dot_label): Remove
	prototype.
	(sel_print_to_dot): Remove macro.
	(sel_print): Likewise.  New prototype.
	* sel-sched-dump.c (sel_prepare_string_for_dot_label): Make static.
	(sel_print): New function.

Modified:
    branches/gcc-4_4-branch/gcc/ChangeLog
    branches/gcc-4_4-branch/gcc/sel-sched-dump.c
    branches/gcc-4_4-branch/gcc/sel-sched-dump.h

Comment 17 Jakub Jelinek 2010-06-21 17:20:03 UTC
Should be fixed now.