date:20131012

[Bug libgomp/58691] OpenMP 4: Surprising results with OMP_PLACES=

2013-10-12 Thread burnus at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58691

--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #1)
 Looks reasonable, bind-var default value is indeed implementation defined and
 setting it to true by default if OMP_PLACES or GOMP_CPU_AFFINITY has been
 parsed into places list is reasonable.  So, how does this look like?

Looks good to me.

(Note that that will turn an explicit OMP_PROC_BIND=false into true, which
looks odd - even if I regard it as unlikely that someone wants to have no
proc-binding while setting OMP_PLACES or GOMP_CPU_AFFINITY:

OMP_PLACES='FALSE' OMP_PLACES='{0:4}' OMP_DISPLAY_ENV=verbose ./a.out 21
|grep -E 'OMP_PLACES|OMP_PROC_'
  OMP_PROC_BIND = 'TRUE'
  OMP_PLACES = '{0:4}'

)


In addition, some patch like the following could be used. Side remark:
OMP_PLACES= is not yet documented in libgomp.texi.

--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -1272,3 +1272,4 @@ Specifies whether threads may be moved between
processors. If set to
 @code{TRUE}, OpenMP theads should not be moved, if set to @code{FALSE}
-they may be moved. If undefined, threads may move between processors.
+they may be moved. If undefined, threads may move between processors,
+unless @code{OMP_PLACES} or @code{GOMP_CPU_AFFINITY} is set.

[Bug libgomp/58691] OpenMP 4: Surprising results with OMP_PLACES=

2013-10-12 Thread jakub at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58691

--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #2)
 (Note that that will turn an explicit OMP_PROC_BIND=false into true, which
 looks odd - even if I regard it as unlikely that someone wants to have no
 proc-binding while setting OMP_PLACES or GOMP_CPU_AFFINITY:
 
 OMP_PLACES='FALSE' OMP_PLACES='{0:4}' OMP_DISPLAY_ENV=verbose ./a.out 21
 |grep -E 'OMP_PLACES|OMP_PROC_'
   OMP_PROC_BIND = 'TRUE'
   OMP_PLACES = '{0:4}'

That command line doesn't set explicit OMP_PROC_BIND=false, it sets OMP_PLACES
twice, first time to invalid value, but the latter wins.
If you try
OMP_PROC_BIND='FALSE' OMP_PLACES='{0,4}' OMP_DISPLAY_ENV=verbose ./a.out 21
|grep -E 'OMP_PLACES|OMP_PROC_'
you'll see it will print
  OMP_PROC_BIND = 'FALSE'
  OMP_PLACES = ''

I'll go ahead and commit the patch.

 In addition, some patch like the following could be used. Side remark:
 OMP_PLACES= is not yet documented in libgomp.texi.
 
 --- a/libgomp/libgomp.texi
 +++ b/libgomp/libgomp.texi
 @@ -1272,3 +1272,4 @@ Specifies whether threads may be moved between
 processors. If set to
  @code{TRUE}, OpenMP theads should not be moved, if set to @code{FALSE}
 -they may be moved. If undefined, threads may move between processors.
 +they may be moved. If undefined, threads may move between processors,
 +unless @code{OMP_PLACES} or @code{GOMP_CPU_AFFINITY} is set.

libgomp.texi needs much more updates for OpenMP 4.0, didn't have time for that
yet (if you have spare cycles, any help with that would be appreciated).
Just saying this when not even mentioning the SPREAD, CLOSE, MASTER (and that
in that case it can be a comma separated list) does not move us much further
though.

[Bug libgomp/58691] OpenMP 4: Surprising results with OMP_PLACES=

2013-10-12 Thread jakub at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58691

--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Sat Oct 12 07:52:15 2013
New Revision: 203479

URL: http://gcc.gnu.org/viewcvs?rev=203479root=gccview=rev
Log:
PR libgomp/58691
* config/linux/proc.c (gomp_cpuset_popcount): Add unused attribute
to check variable.
(gomp_init_num_threads): Move i variable declaration into
#ifdef CPU_ALLOC_SIZE block.
* config/linux/affinity.c (gomp_affinity_init_level): Test
gomp_places_list_len == 0 rather than gomp_places_list == 0
when checking for topology reading error.
* team.c (gomp_team_start): Don't handle bind == omp_proc_bind_false.
* env.c (parse_affinity): Add ignore argument, if true, don't populate
gomp_places_list, only parse env var and always return false.
(parse_places_var): Likewise.  Don't check gomp_global_icv.bind_var.
(initialize_env): Always parse OMP_PLACES and GOMP_CPU_AFFINITY env
vars, default to OMP_PROC_BIND=true if OMP_PROC_BIND wasn't specified
and either of these variables were parsed correctly into a places
list.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/config/linux/affinity.c
trunk/libgomp/config/linux/proc.c
trunk/libgomp/env.c
trunk/libgomp/team.c

[Bug tree-optimization/58696] wrong code at -O3 on x86_64-linux-gnu

2013-10-12 Thread mikpelinux at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58696

--- Comment #1 from Mikael Pettersson mikpelinux at gmail dot com ---
Broke with r203061, works again with r203463, likely dup of PR58640.

[Bug c++/40365] g++ template expansion bug

2013-10-12 Thread oleg_dolomanov at hotmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40365

--- Comment #7 from Oleg Dolomanov oleg_dolomanov at hotmail dot com ---
Sorry guys, it really was the hardware: I wish you could see (I have a
picture!), but it was one of the memory chips (one along the 16 on the OCZ 2Gb
PC2 6400 5-5-5-18!) falling off - it did take me long time to track this
down... And any other things too... So you can discard this for sure.

o

[Bug c++/58055] [meta-bug] RVO / NRVO improvements

2013-10-12 Thread ebotcazou at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58055

Eric Botcazou ebotcazou at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org ---
 We currently only apply the NRVO when there is a single variable at the
 topmost level of the function body such that all return statements are of
 this variable. It seems like a wider characterization of the valid cases
 would be when we have an automatic variable whose natural lifetime (from the
 declaration to the end of the scope) includes returns only of this variable.

You can go farther if the return operation overwrites entirely the anonymous
return object and for example allow returning literals, but I don't know if
this is a realistic case in C++; we allow that in Ada.

 That may be easiest to detect in the front-end. Later, the scope would be
 the try block in a try-finally right after a constructor call? In SSA it is
 even less obvious. For return statements, we need to look for a call to a
 copy constructor before a return statement, again more complicated than in
 the FE.

Yes, it's definitely easier to use scoping information in the FE.

 However, actually performing the optimization in the FE is not trivial.  We
 want to remove the calls to the destructor of the variable, but not all,
 only those associated to a return.

In Ada we have little choice but to perform it in the FE, at least for things
like unconstrained array types, because the semantics is lost in the ME.

[Bug tree-optimization/58697] [4.8 Regression] wrong code (segfaults) at -O3

2013-10-12 Thread jakub at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58697

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-10-12
 CC||amacleod at redhat dot com,
   ||hubicka at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
   Target Milestone|--- |4.8.2
Summary|wrong code (segfaults) at   |[4.8 Regression] wrong code
   |-O3 |(segfaults) at -O3
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
Started with r192219, ended with r203317.  The latter is weird, I thought
Andrew's patches are just reshuffling of stuff, not changing compiler behavior.
In any case, between r203316 and r203317, pre-unswitch dump the IL is the same,
unswitching is the first changed dump.

[Bug c++/58055] [meta-bug] RVO / NRVO improvements

2013-10-12 Thread glisse at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58055

--- Comment #4 from Marc Glisse glisse at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #3)
 You can go farther if the return operation overwrites entirely the anonymous
 return object and for example allow returning literals, but I don't know if
 this is a realistic case in C++; we allow that in Ada.

If we build a local object in the return location and later decide to return
another object instead, we need to call the destructor before we overwrite it,
and we end up having to decide if shuffling the function calls that way is
legal (probably hard). That may be ok when the destructor does nothing (the
literals you mention?), but my main interest in this optimization in C++ is
cases where the copy constructor and the destructor are non-trivial.

Is there a clever way to chose which literal variables to put in the return
location when there are several candidates (this might require profile
information)? I am also wondering if this version restricted to trivial types
couldn't be done in the middle-end tree-nrv.c.

 In Ada we have little choice but to perform it in the FE, at least for
 things like unconstrained array types, because the semantics is lost in the
 ME.

I was considering a mechanism to tell the middle-end about that semantic, but
it does indeed seem simpler to do everything in the front-end.

[Bug target/58699] New: ARM: emit PLDW instruction for prefetch with write intent

2013-10-12 Thread mans at mansr dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58699

Bug ID: 58699
   Summary: ARM: emit PLDW instruction for prefetch with write
intent
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mans at mansr dot com

Created attachment 30991
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30991action=edit
Emit PLDW instruction for prefetch with write intent

__builtin_prefetch(addr, 1) should result in a PLDW instruction on targets with
the multiprocessing extension.

[Bug target/58690] internal compiler error: in copy_to_mode_reg, at explow.c:641

2013-10-12 Thread hjl at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58690

--- Comment #2 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org ---
Author: hjl
Date: Sat Oct 12 14:55:28 2013
New Revision: 203486

URL: http://gcc.gnu.org/viewcvs?rev=203486root=gccview=rev
Log:
Truncate x32 DImode TLS address to a SImode register

gcc/

PR target/58690
* config/i386/i386.c (ix86_copy_addr_to_reg): New function.
(ix86_expand_movmem): Replace copy_addr_to_reg with
ix86_copy_addr_to_reg.
(ix86_expand_setmem): Likewise.

gcc/testsuite/

PR target/58690
* gcc.target/i386/pr58690.c: New test

Added:
trunk/gcc/testsuite/gcc.target/i386/pr58690.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/55436] g++ compiles invalid code with child class of nested class in template class

2013-10-12 Thread paolo.carlini at oracle dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55436

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 CC|conradsand.arma at gmail dot com   |

--- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com ---
Yes, it's redundant, you get all the messages by default being the bug
submitter

[Bug target/58641] [4.9 Regression] FAIL: gcc.target/i386/pr49002-2.c scan-assembler vmovapd[\t ]%ymm[0-9]+,[^,]

2013-10-12 Thread dominiq at lps dot ens.fr

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58641

Dominique d'Humieres dominiq at lps dot ens.fr changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr ---
According to http://gcc.gnu.org/ml/gcc-regression/2013-10/msg00041.html this
has been fixed by revision 203387.

[Bug testsuite/58645] FAIL: gnat.dg/specs/linker_alias.ads (test for errors, line 6)

2013-10-12 Thread dominiq at lps dot ens.fr

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58645

--- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr ---
 Sure, but you can just skip the testcase like on Darwin.

It is not! I was about to open a PR for it:

On x86_64-apple-darwin(10|12) gnat.dg/specs/linker_section.ads fails, starting
between revisions 203285 (OK) and 203395:

output is:
linker_section.ads:10:38: pragma Linker_Section applies only to objects and
types
gnatmake: /opt/gcc/work/gcc/testsuite/gnat.dg/specs/linker_section.ads
compilation error

Executing on host: /opt/gcc/build_w/gcc/gnatclean -c -q -n linker_section  
(timeout = 300)
spawn /opt/gcc/build_w/gcc/gnatclean -c -q -n linker_section
FAIL: gnat.dg/specs/linker_section.ads  (test for errors, line 6)
PASS: gnat.dg/specs/linker_section.ads  (test for errors, line 10)
PASS: gnat.dg/specs/linker_section.ads (test for excess errors)

[Bug tree-optimization/55912] missing optimization of x/x and x/std::abs(x)

2013-10-12 Thread glisse at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55912

--- Comment #3 from Marc Glisse glisse at gcc dot gnu.org ---
(In reply to Richard Biener from comment #2)
 Most of the math builtin folding needs to be re-done at GIMPLE level based
 on SSA form.  Convenient places are either tree-ssa-forwprop.c or
 tree-ssa-math-opts.c (sincos pass which also does power series expansion
 now).

tree-ssa-reassoc.c seems like a natural place to optimize x*a/x, since it
already handles x+a-x.

[Bug testsuite/58645] FAIL: gnat.dg/specs/linker_alias.ads (test for errors, line 6)

2013-10-12 Thread charlet at adacore dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58645

--- Comment #3 from charlet at adacore dot com charlet at adacore dot com ---
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58645
 
 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr ---
  Sure, but you can just skip the testcase like on Darwin.
 
 It is not! I was about to open a PR for it:

Actually the new output is as expected since types are now accepted (in
addition to objects), I just forgot to update the test after changes
made this week, now done.

This won't make a difference for this PR though, since the issue is unrelated
to this week's changes.

Arno

Re: [Bug testsuite/58645] FAIL: gnat.dg/specs/linker_alias.ads (test for errors, line 6)

2013-10-12 Thread Arnaud Charlet

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58645
 
 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr ---
  Sure, but you can just skip the testcase like on Darwin.
 
 It is not! I was about to open a PR for it:

Actually the new output is as expected since types are now accepted (in
addition to objects), I just forgot to update the test after changes
made this week, now done.

This won't make a difference for this PR though, since the issue is unrelated
to this week's changes.

Arno

[Bug testsuite/57605] colors break note pruning in the testsuite

2013-10-12 Thread glisse at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57605

Marc Glisse glisse at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Marc Glisse glisse at gcc dot gnu.org ---
Fixed by Jakub's patch, I assume.

[Bug c++/57572] vector operators don't participate in overload resolution

2013-10-12 Thread glisse at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57572

--- Comment #1 from Marc Glisse glisse at gcc dot gnu.org ---
Created attachment 30992
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30992action=edit
vector-only patch

I have had this lying around for a while. IIRC it seemed to work, but it
doesn't handle the mixed vector-scalar operations (and maybe it was missing
other things as well).

[Bug tree-optimization/58698] Spurious may be used unitialized warning when compiling with -Os

2013-10-12 Thread pinskia at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58698

Andrew Pinski pinskia at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||diagnostic
  Component|c   |tree-optimization
  Known to fail||4.7.0, 4.8.1

--- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org ---
It happens with 4.7.0 also.

[Bug c/52794] gcc.dg/tree-prof/pr52027.c fails on x86_64/i386-apple-darwin*

2013-10-12 Thread dominiq at lps dot ens.fr

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52794

Dominique d'Humieres dominiq at lps dot ens.fr changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-10-12
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Confirmed.

[Bug tree-optimization/46507] std::get and devirtualization on non-automatic variables

2013-10-12 Thread glisse at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46507

Marc Glisse glisse at gcc dot gnu.org changed:

   What|Removed |Added

Summary|std::tuple missed   |std::get and
   |optimization|devirtualization on
   ||non-automatic variables

--- Comment #5 from Marc Glisse glisse at gcc dot gnu.org ---
I just read this comment in ipa-prop.c: only for automatically allocated
objects but at the moment we devirtualize only these. And indeed, if we define
an automatic variable of type A and call arg_tuple_test on it (and that call is
inlined), then the call to f is devirtualized. So this is a known limitation of
the current devirtualization code. I don't think there is anything we can do at
the library level.

[Bug c/52795] FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE on {x86_64,i386}-apple-darwin{10,11} at -m64

2013-10-12 Thread dominiq at lps dot ens.fr

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52795

Dominique d'Humieres dominiq at lps dot ens.fr changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-10-12
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Confirmed on darwin12 for 4.7, 4.8 and trunk (r203489) only with -m64. In
addition I see

FAIL: gcc.dg/tree-prof/pr45354.c compilation,  -fprofile-use -D_PROFILE_USE
FAIL: gcc.dg/tree-prof/pr50907.c compilation,  -fprofile-use -D_PROFILE_USE

and

FAIL: g++.dg/tree-prof/pr57451.C compilation,  -fprofile-use

[Bug target/51244] [SH] Inefficient conditional branch and code around T bit

2013-10-12 Thread olegendo at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244

--- Comment #70 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Sat Oct 12 20:47:22 2013
New Revision: 203492

URL: http://gcc.gnu.org/viewcvs?rev=203492root=gccview=rev
Log:
PR target/51244
* config/sh/sh_treg_combine.cc: New SH specific RTL pass.
* config.gcc (SH extra_objs): Add sh_ifcvt.o.
* config/sh/t-sh (sh_treg_combine.o): New entry.
* config/sh/sh.c (sh_fixed_condition_code_regs): New function that
implements the target hook TARGET_FIXED_CONDITION_CODE_REGS.
(register_sh_passes): New function.  Register sh_treg_combine pass.
(sh_option_override): Invoke it.
(sh_canonicalize_comparison): Handle op0_preserve_value.
* sh.md (*cbranch_t): Do not try to optimize missed test and branch
opportunities.  Canonicalize branch condition.
(nott): Allow only if pseudos can be created for non-SH2A.

PR target/51244
* gcc.dg/torture/p51244-21.c: New.
* gcc.target/sh/pr51244-20.c: New.
* gcc.target/sh/pr51244-20-sh2a.c: New.


Added:
trunk/gcc/config/sh/sh_treg_combine.cc
trunk/gcc/testsuite/gcc.dg/torture/pr51244-21.c
trunk/gcc/testsuite/gcc.target/sh/pr51244-20-sh2a.c
trunk/gcc/testsuite/gcc.target/sh/pr51244-20.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.gcc
trunk/gcc/config/sh/sh.c
trunk/gcc/config/sh/sh.md
trunk/gcc/config/sh/t-sh
trunk/gcc/testsuite/ChangeLog

[Bug c++/58700] New: [4.8/4.9 Regression] ICE declaring static bit-field

2013-10-12 Thread reichelt at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58700

Bug ID: 58700
   Summary: [4.8/4.9 Regression] ICE declaring static bit-field
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org

The following invalid code snippet triggers an ICE since GCC 4.8.0:

=
struct A
{
  static int : 4;
};
=

bug.cc:3:16: internal compiler error: Segmentation fault
   static int : 4;
^
0xb15dff crash_signal
../../gcc/gcc/toplev.c:335
0x5831a7 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../gcc/gcc/cp/decl.c:10642
0x617fcd grokbitfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
tree_node*)
../../gcc/gcc/cp/decl2.c:1043
0x660ba6 cp_parser_member_declaration
../../gcc/gcc/cp/parser.c:20031
0x6402c7 cp_parser_member_specification_opt
../../gcc/gcc/cp/parser.c:19726
0x6402c7 cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:18970
0x6402c7 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:19197
0x6402c7 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:14144
0x65924f cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:11389
0x65fd89 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:10979
0x643860 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:10928
0x66aaae cp_parser_declaration
../../gcc/gcc/cp/parser.c:10825
0x6697ca cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10711
0x66b0e6 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:3989
0x66b0e6 c_parse_file()
../../gcc/gcc/cp/parser.c:30962
0x787f73 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1046
Please submit a full bug report, [etc.]

GCC 4.7.x issued a suitable error message instead:

bug.cc:3:16: error: static member 'anonymous' cannot be a bit-field

[Bug c++/58700] [4.8/4.9 Regression] ICE declaring static bit-field

2013-10-12 Thread reichelt at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58700

Volker Reichelt reichelt at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
  Known to work||4.7.0
   Target Milestone|--- |4.8.2
  Known to fail||4.8.0, 4.9.0

[Bug c++/58701] New: [4.9 Regression] [c++11] ICE initializing member of static union

2013-10-12 Thread reichelt at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58701

Bug ID: 58701
   Summary: [4.9 Regression] [c++11] ICE initializing member of
static union
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org

The following valid code snippet (compiled with -std=c++11) triggers an ICE
on trunk (since at least 4.9.0 20130920):

===
static union
{
  union
  {
int i = 0;
  };
};
===

bug.cc: In constructor 'constexpranonymous union::constructor()':
bug.cc:2:1: internal compiler error: tree check: accessed operand 2 of
indirect_ref with 1 operands in build_anon_member_initialization, at
cp/semantics.c:7404
 {
 ^
0xd201a7 tree_operand_check_failed(int, tree_node const*, char const*, int,
char const*)
../../gcc/gcc/tree.c:9499
0x6d2677 tree_operand_check
../../gcc/gcc/tree.h:3109
0x6d2677 build_anon_member_initialization
../../gcc/gcc/cp/semantics.c:7404
0x6d2677 build_data_member_initialization
../../gcc/gcc/cp/semantics.c:7533
0x6d338d build_constexpr_constructor_member_initializers
../../gcc/gcc/cp/semantics.c:7652
0x6d338d massage_constexpr_body
../../gcc/gcc/cp/semantics.c:7752
0x6da9a3 register_constexpr_fundef(tree_node*, tree_node*)
../../gcc/gcc/cp/semantics.c:7856
0x56ea38 maybe_save_function_definition
../../gcc/gcc/cp/decl.c:13823
0x56ea38 finish_function(int)
../../gcc/gcc/cp/decl.c:13944
0x6acc19 synthesize_method(tree_node*)
../../gcc/gcc/cp/method.c:809
0x61e379 mark_used(tree_node*, int)
../../gcc/gcc/cp/decl2.c:4778
0x54d0b6 build_over_call
../../gcc/gcc/cp/call.c:7116
0x548eae build_new_method_call_1
../../gcc/gcc/cp/call.c:7813
0x548eae build_new_method_call(tree_node*, tree_node*, vectree_node*, va_gc,
vl_embed**, tree_node*, int, tree_node**, int)
../../gcc/gcc/cp/call.c:7883
0x549e22 build_special_member_call(tree_node*, tree_node*, vectree_node*,
va_gc, vl_embed**, tree_node*, int, int)
../../gcc/gcc/cp/call.c:7440
0x69eba7 expand_default_init
../../gcc/gcc/cp/init.c:1668
0x69eba7 expand_aggr_init_1
../../gcc/gcc/cp/init.c:1769
0x6a1779 build_aggr_init(tree_node*, tree_node*, int, int)
../../gcc/gcc/cp/init.c:1520
0x55e005 build_aggr_init_full_exprs
../../gcc/gcc/cp/decl.c:5552
0x55e005 check_initializer
../../gcc/gcc/cp/decl.c:5687
Please submit a full bug report, [etc.]

[Bug c++/58701] [4.9 Regression] [c++11] ICE initializing member of static union

2013-10-12 Thread reichelt at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58701

Volker Reichelt reichelt at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||4.7.0, 4.8.0
   Target Milestone|--- |4.9.0
  Known to fail||4.9.0

[Bug c++/58702] New: [4.9 Regression] ICE with undeclared variable in OpenMP reduction clause

2013-10-12 Thread reichelt at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58702

Bug ID: 58702
   Summary: [4.9 Regression] ICE with undeclared variable in
OpenMP reduction clause
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org

The following invalid code snippet (compiled with -fopenmp) triggers an ICE
on trunk:

=
void foo()
{
  x;
#pragma omp parallel for reduction(+:x)
  for (int i = 0; i  10; ++i) ;
}
=

bug.cc: In function 'void foo()':
bug.cc:3:3: error: 'x' was not declared in this scope
   x;
   ^
bug.cc:4:40: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in finish_omp_reduction_clause, at
cp/semantics.c:4966
 #pragma omp parallel for reduction(+:x)
^
0xd14f79 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/gcc/tree.c:9351
0x6df624 tree_class_check
../../gcc/gcc/tree.h:2797
0x6df624 finish_omp_reduction_clause
../../gcc/gcc/cp/semantics.c:4966
0x6df624 finish_omp_clauses(tree_node*)
../../gcc/gcc/cp/semantics.c:5709
0x634b1e cp_omp_split_clauses
../../gcc/gcc/cp/parser.c:28967
0x66873e cp_parser_omp_for
../../gcc/gcc/cp/parser.c:29079
0x668c4b cp_parser_omp_parallel
../../gcc/gcc/cp/parser.c:29259
0x63f221 cp_parser_omp_construct
../../gcc/gcc/cp/parser.c:30380
0x63f221 cp_parser_pragma
../../gcc/gcc/cp/parser.c:30885
0x64555c cp_parser_statement
../../gcc/gcc/cp/parser.c:9297
0x646342 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:9604
0x646486 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:9558
0x659b0b cp_parser_function_body
../../gcc/gcc/cp/parser.c:18401
0x659b0b cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:18437
0x65df0f cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:22444
0x65ece2 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:22365
0x65ece2 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16412
0x65ff2f cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11047
0x643860 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:10928
0x66aaae cp_parser_declaration
../../gcc/gcc/cp/parser.c:10825
Please submit a full bug report, [etc.]

The regression was introduced between 2013-10-09 and 2013-10-11.

[Bug c++/58702] [4.9 Regression] ICE with undeclared variable in OpenMP reduction clause

2013-10-12 Thread reichelt at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58702

Volker Reichelt reichelt at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code, openmp
  Known to work||4.8.0
   Target Milestone|--- |4.9.0
  Known to fail||4.9.0

[Bug c++/58703] New: [4.9 Regression] ICE with invalid types in OpenMP declare reduction clause

2013-10-12 Thread reichelt at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58703

Bug ID: 58703
   Summary: [4.9 Regression] ICE with invalid types in OpenMP
declare reduction clause
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org

The following invalid code snippet (compiled with -fopenmp) triggers an ICE
on trunk:


#pragma omp declare reduction (+ : char[] : omp_out += omp_in)
#pragma omp declare reduction (+ : char() : omp_out += omp_in)


bug.cc:1:36: error: function or array type 'char []' in '#pragma omp declare
reduction'
 #pragma omp declare reduction (+ : char[] : omp_out += omp_in)
^
bug.cc:2:36: error: function or array type 'char()' in '#pragma omp declare
reduction'
 #pragma omp declare reduction (+ : char() : omp_out += omp_in)
^
bug.cc:2:63: internal compiler error: in cp_parser_translation_unit, at
cp/parser.c:4019
 #pragma omp declare reduction (+ : char() : omp_out += omp_in)
   ^
0x66b3b0 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4018
0x66b3b0 c_parse_file()
../../gcc/gcc/cp/parser.c:30962
0x787f73 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1046
Please submit a full bug report, [etc.]

[Bug testsuite/58645] FAIL: gnat.dg/specs/linker_alias.ads (test for errors, line 6)

2013-10-12 Thread ebotcazou at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58645

--- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org ---
 It is not! I was about to open a PR for it:
 
 On x86_64-apple-darwin(10|12) gnat.dg/specs/linker_section.ads fails,

It is, you're confusing 2 different tests here.

[Bug c++/58703] [4.9 Regression] ICE with invalid types in OpenMP declare reduction clause

2013-10-12 Thread reichelt at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58703

Volker Reichelt reichelt at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
   Target Milestone|--- |4.9.0
  Known to fail||4.9.0

[Bug c++/58704] New: [c++11] ICE initializing array member of template class

2013-10-12 Thread reichelt at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58704

Bug ID: 58704
   Summary: [c++11] ICE initializing array member of template
class
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org

The following valid code snippet (compiled with -std=c++11) triggers an ICE
since GCC 4.7.0 (when non-static data member initializers were introduced):

=
struct A {};

templatetypename struct B
{
  A a[1] = {};
};

Bint b;
=

bug.cc: In constructor 'constexpr Bint::B()':
bug.cc:3:27: internal compiler error: tree check: expected tree that contains
'common' structure, have 'constructor' in perform_member_init, at cp/init.c:665
 templatetypename struct B
   ^
0xd159c7 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../gcc/gcc/tree.c:9472
0x6a3e2d contains_struct_check
../../gcc/gcc/tree.h:2788
0x6a3e2d perform_member_init
../../gcc/gcc/cp/init.c:665
0x6a3e2d emit_mem_initializers(tree_node*)
../../gcc/gcc/cp/init.c:1096
0x6acfae synthesize_method(tree_node*)
../../gcc/gcc/cp/method.c:796
0x61e379 mark_used(tree_node*, int)
../../gcc/gcc/cp/decl2.c:4778
0x54d0b6 build_over_call
../../gcc/gcc/cp/call.c:7116
0x548eae build_new_method_call_1
../../gcc/gcc/cp/call.c:7813
0x548eae build_new_method_call(tree_node*, tree_node*, vectree_node*, va_gc,
vl_embed**, tree_node*, int, tree_node**, int)
../../gcc/gcc/cp/call.c:7883
0x549e22 build_special_member_call(tree_node*, tree_node*, vectree_node*,
va_gc, vl_embed**, tree_node*, int, int)
../../gcc/gcc/cp/call.c:7440
0x69eba7 expand_default_init
../../gcc/gcc/cp/init.c:1668
0x69eba7 expand_aggr_init_1
../../gcc/gcc/cp/init.c:1769
0x6a1779 build_aggr_init(tree_node*, tree_node*, int, int)
../../gcc/gcc/cp/init.c:1520
0x55e005 build_aggr_init_full_exprs
../../gcc/gcc/cp/decl.c:5552
0x55e005 check_initializer
../../gcc/gcc/cp/decl.c:5687
0x570ccc cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/gcc/cp/decl.c:6356
0x65e7e7 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16633
0x65ff2f cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11047
0x643860 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:10928
0x66aaae cp_parser_declaration
../../gcc/gcc/cp/parser.c:10825
Please submit a full bug report, [etc.]

[Bug target/51244] [SH] Inefficient conditional branch and code around T bit

2013-10-12 Thread olegendo at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244

--- Comment #71 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #70)
 Author: olegendo
 Date: Sat Oct 12 20:47:22 2013
 New Revision: 203492
 

The issue raised in comment #59 has been fixed on 4.9.
There are some open issues though, which I will try to address in follow up
patches:

* The helper functions in sh_treg_combine.cc should go into a separate .h + .cc
file.  This would allow re-using them in other places and eliminate the similar
function 'sh_find_set_of_reg' in sh.c

* The RTL pass does the treg combine only when there is a conditional branch. 
It should also handle conditional move insns (-mpretend-cmove).

* The function 'try_combine_comparisons' in sh_reg_combine.cc always introduces
reg-reg copies.  In some cases (DImode comparisons in particular), these
reg-reg moves don't get eliminated afterwards before register allocation.  The
function should check whether creating new pseudos can be avoided by re-using
existing regs.


The sh_treg_combine RTL pass could probably be backported to 4.8 but seems too
intrusive.  Instead something like the patch in comment #64 should do, where
instead of checking for 'no_labels_between_p' it would probably be better to
check if the basic block with the conditional branch has only one predecessor.

[Bug c++/58705] [4.7/4.8/4.9 Regression] [c++11] ICE with invalid initializer for _Complex variable

2013-10-12 Thread reichelt at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58705

Volker Reichelt reichelt at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
  Known to work||4.6.0
   Target Milestone|--- |4.7.4
  Known to fail||4.7.0, 4.8.0, 4.9.0

[Bug c++/58705] New: [4.7/4.8/4.9 Regression] [c++11] ICE with invalid initializer for _Complex variable

2013-10-12 Thread reichelt at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58705

Bug ID: 58705
   Summary: [4.7/4.8/4.9 Regression] [c++11] ICE with invalid
initializer for _Complex variable
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org

The following invalid code snippet (compiled with -std=c++11) triggers an ICE
since GCC 4.7.0:

===
_Complex float f = {{}};
===

bug.cc:1:23: internal compiler error: Segmentation fault
 _Complex float f = {{}};
   ^
0xb15dff crash_signal
../../gcc/gcc/toplev.c:335
0x5e6d15 vecconstructor_elt_d, va_gc, vl_embed::operator[](unsigned int)
../../gcc/gcc/vec.h:827
0x5e6d15 check_narrowing(tree_node*, tree_node*)
../../gcc/gcc/cp/typeck2.c:836
0x55e437 check_initializer
../../gcc/gcc/cp/decl.c:5669
0x570ccc cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/gcc/cp/decl.c:6356
0x65e7e7 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16633
0x65ff2f cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11047
0x643860 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:10928
0x66aaae cp_parser_declaration
../../gcc/gcc/cp/parser.c:10825
0x6697ca cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10711
0x66b0e6 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:3989
0x66b0e6 c_parse_file()
../../gcc/gcc/cp/parser.c:30962
0x787f73 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1046
Please submit a full bug report, [etc.]

[Bug c++/58706] New: ICE with lambda in OpenMP for-loop

2013-10-12 Thread reichelt at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58706

Bug ID: 58706
   Summary: ICE with lambda in OpenMP for-loop
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org

The following valid code snippet (compiled with -std=c++11 -fopenmp) triggers
an ICE since GCC 4.5.0 (when lambdas were introduced):

===
templatetypename T void foo()
{
#pragma omp for
  for (T i = [](){ return 0; }(); i  10; ++i)
;
}

void bar()
{
  fooint();
}
===

bug.cc: In instantiation of 'void foo() [with T = int]':
bug.cc:10:12:   required from here
bug.cc:3:9: internal compiler error: Segmentation fault
 #pragma omp for
 ^
0xb15dff crash_signal
../../gcc/gcc/toplev.c:335
0x6cabd2 contains_struct_check
../../gcc/gcc/tree.h:2787
0x6cabd2 finish_omp_for(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node*, tree_node*)
../../gcc/gcc/cp/semantics.c:6321
0x5aae3d tsubst_expr
../../gcc/gcc/cp/pt.c:13596
0x5a9db7 tsubst_expr
../../gcc/gcc/cp/pt.c:13384
0x5a6d69 instantiate_decl(tree_node*, int, bool)
../../gcc/gcc/cp/pt.c:19603
0x5e4c6f instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:19715
0x6204c6 cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4121
Please submit a full bug report, [etc.]

[Bug c++/58707] New: [C++11] A greater-than operator in square brackets should not end a template argument list

2013-10-12 Thread tuomas.tynkkynen at iki dot fi

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58707

Bug ID: 58707
   Summary: [C++11] A greater-than operator in square brackets
should not end a template argument list
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tuomas.tynkkynen at iki dot fi

Created attachment 30993
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30993action=edit
The failing code snippet

The following code snippet does not compile on latest GCC trunk:

templateint i class TC { };
constexpr int foo[] = { 42, };
TCfoo[0  1] bar;

Actual result:

tmtynkky@e42-7:/tmp$ /dos/gcc-trunk/bin/gcc -xc++ -std=c++11 -pedantic -c -o
/dev/null bracket.cpp 
bracket.cpp:3:10: error: template argument 1 is invalid
 TCfoo[0  1] bar;
  ^
bracket.cpp:3:12: error: expected unqualified-id before numeric constant
 TCfoo[0  1] bar;
^

The '' seems to get parsed as the ending delimiter of the template argument
list, even though it shouldn't since it is nested inside a pair of square
brackets. Clang++ 3.3 correctly accepts this snippet.

(originally discussed on
http://forum.cppgm.org/question/2286/inside-square-brackets-terminates-a-template-argument-list/)

Version information:

gcc version 4.9.0 20131011 (experimental) [trunk revision 203401] (GCC) 
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk-source/gcc/configure --enable
languages=c,c++,fortran --enable-checking=release --disable-libmudflap
--disable libstdcxx-pch --enable-libgomp --enable-lto --enable-gold
--with-plugin ld=/usr/bin/gold --with-cloog-include=/usr/include-cloog
--with-cloog lib=/usr/lib64 --prefix=/usr/local/gcc-trunk

[Bug libstdc++/58338] Add noexcept to functions with a narrow contract

2013-10-12 Thread bredelin at ucla dot edu

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58338

bredelin at ucla dot edu changed:

   What|Removed |Added

 CC||bredelin at ucla dot edu

--- Comment #10 from bredelin at ucla dot edu ---
It seems that these changes (see Sep 17th) also made the default constructor
explicit.  While this does follow the standard, it is the subject of this
defect report:

http://cplusplus.github.io/LWG/lwg-active.html#2193

Was this change intentional?

[Bug c++/58708] New: string literal operator templates broken

2013-10-12 Thread mustrumr97 at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58708

Bug ID: 58708
   Summary: string literal operator templates broken
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mustrumr97 at gmail dot com

The character type should be unqualified (char32_t instead of const char32_t).
Wide character types are broken.

U

[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1

2013-10-12 Thread dominiq at lps dot ens.fr

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438

Dominique d'Humieres dominiq at lps dot ens.fr changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-10-12
 Ever confirmed|0   |1

--- Comment #20 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Still present at revision 203491 and the patch in comment #14 does not help.

[Bug libstdc++/58605] atomicT::atomic() disobeys [atomics.types.operations.req]p4 for types with user-defined default constructors

2013-10-12 Thread daniel.kruegler at googlemail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58605

--- Comment #4 from Daniel Krügler daniel.kruegler at googlemail dot com ---
(In reply to Daniel Krügler from comment #3)
A new library has been opened:

http://cplusplus.github.io/LWG/lwg-active.html#2334

[Bug c++/58709] New: [c++11] Bogus? int vs. scoped enum printf warning when -fabi-version = 6

2013-10-12 Thread ppluzhnikov at google dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58709

Bug ID: 58709
   Summary: [c++11] Bogus? int vs. scoped enum printf warning when
-fabi-version = 6
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppluzhnikov at google dot com

Test:

#include stdio.h

enum class Foo {
  FOO
};

int main()
{
  printf(%d\n, Foo::FOO);
}

Using g++ (GCC) 4.9.0 20131005 (experimental):

$ g++ -c -std=c++11 -Wformat t.cc
$

$ g++ -c -std=c++11 -Wformat t.cc -fabi-version=6

t.cc:9:26: warning: format ‘%d’ expects argument of type ‘int’, but argument 2
has type ‘Foo’ [-Wformat=]
   printf(%d\n, Foo::FOO);
  ^

From gcc/common.opt:

; 6: The version of the ABI that doesn't promote scoped enums to int and ...

This seems like a bug -- even though the scoped enum is not promoted to an int,
printf warning doesn't seem appropriate here either.

[Bug c++/58709] [c++11] Bogus? int vs. scoped enum printf warning when -fabi-version = 6

2013-10-12 Thread pinskia at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58709

--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org ---
I think the warning is correct as it is not promoted to int in the function
call.  This is the same reason why bitfields warn when passing them for printf
too.

[Bug c++/58709] [c++11] Bogus? int vs. scoped enum printf warning when -fabi-version = 6

2013-10-12 Thread ppluzhnikov at google dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58709

--- Comment #2 from Paul Pluzhnikov ppluzhnikov at google dot com ---
(In reply to Andrew Pinski from comment #1)
 I think the warning is correct as it is not promoted to int in the function
 call.

How is it passed then?

I see:

movl$0, 4(%esp)
movl$.LC0, (%esp)
callprintf

on ix86, and

movl$0, %esi
movl$.LC0, %edi
callprintf

on x86_64. Looks like an int to me.

[Bug c++/58701] [4.9 Regression] [c++11] ICE initializing member of static union

2013-10-12 Thread paolo.carlini at oracle dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58701

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-10-13
 CC||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com ---
This is the relevant change: r199455. CC-ing Jason.

[Bug c++/58700] [4.8/4.9 Regression] ICE declaring static bit-field

2013-10-12 Thread paolo.carlini at oracle dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58700

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-10-13
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
 Ever confirmed|0   |1

--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com ---
Mine.

[Bug libstdc++/58710] New: HAVE_GETIPINFO is incorrectly set on Mac OS X 10.4

2013-10-12 Thread misty at brew dot sh

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58710

Bug ID: 58710
   Summary: HAVE_GETIPINFO is incorrectly set on Mac OS X 10.4
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: misty at brew dot sh

_Unwind_GetIPInfo isn't available on Mac OS X 10.4 and older. GCC checks for
this specific case in several places to ensure it isn't used inappropriately,
but there seem to be a few issues that cause it to be used anyway. See #56811
for an example of this.

When checking for whether to use the system unwind, configure scripts
specifically check for Darwin 8 and older (see, for example, libbacktrace's
configure at L11629-11648); when Darwin 8 is encountered it explicitly sets
have_unwind_getipinfo to 0 to ensure it won't be used. However, the same
configure script also later does an independent check to see if
_Unwind_GetIPInfo is available, and this is erroneously reporting that it's
available. As a result several libraries, like libbacktrace, try to use
_UnwindGetIPInfo and the build fails at the link stage.

When I took a look at the config.log, it seems it's compiling using `-c`, so
the linker is inhibited:

configure:11652: checking for _Unwind_GetIPInfo
configure:11667: /usr/local/bin/gcc-4.4 -c -g
-Werror-implicit-function-declaration  conftest.c 5
configure:11667: $? = 0
configure:11674: result: yes

However, the specific problem on OS X 10.4 is that _Unwind_GetIPInfo isn't
exported - and so the test would only fail if the linker was invoked.

I've noticed that a few sections of GCC, such as raise-gcc.c, appear to expect
that they'll get an incorrect configure value and redefine it themselves:

#ifdef __APPLE__
/* On MacOS X, versions older than 10.5 don't export _Unwind_GetIPInfo.  */
#undef HAVE_GETIPINFO
#if __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ = 1050
#define HAVE_GETIPINFO 1
#endif
#endif

However, this isn't done consistently, which is why other places (like
_Unwind_GetIPInfo) still try to use it.

[Bug middle-end/58711] New: Missing uninitialized warning in loop condition (when compiling without optimization)

2013-10-12 Thread mimomorin at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58711

Bug ID: 58711
   Summary: Missing uninitialized warning in loop condition
(when compiling without optimization)
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mimomorin at gmail dot com

In the following code, `cond` is uninitialized in `while (cond)`. However, 
the uninitialized warning (i.e. variable 'cond' is uninitialized when used
here) 
does not emit when compiling without optimization.
(If we compile it with optimization option, the warning is properly emitted.)
Tested on gcc 4.4-4.8, 4.9 (trunk).

int main(int argc, char* argv[])
{
int cond;

// Missing uninitialized warning
while (cond != 0) {
// `(void)` is used to avoid unused-value warning
(void)cond;
}

return 0;
}

Clang has the same issue, but it's fixed recently.
( http://llvm.org/bugs/show_bug.cgi?id=16054 )

49 matches

Mail list logo