[Bug c++/59297] [4.7 Regression] ICE: openmp atomic with indirect LHS

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Known to work||4.8.3, 4.9.0
Summary|[4.7/4.8/4.9 Regression]|[4.7 Regression] ICE:
   |ICE: openmp atomic with |openmp atomic with indirect
   |indirect LHS|LHS
  Known to fail||4.7.3, 4.8.2

--- Comment #6 from Jakub Jelinek  ---
Fixed for 4.8.3+ so far.

[Bug middle-end/59327] [4.9 Regression] warning in expand_used_vars

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Jakub Jelinek  ---
Fixed.

[Bug c/59280] [4.8/4.9 Regression] ICE with attribute((constructor(invalid)))

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Jakub Jelinek  ---
Fixed.

[Bug middle-end/59336] New: definition in block 317 does not dominate use in block 316

[Joost.VandeVondele at mat dot ethz.ch]

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

Bug ID: 59336
   Summary: definition in block 317 does not dominate use in block
316
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Joost.VandeVondele at mat dot ethz.ch

During an LTO build of CP2K, the following internal error happens with gcc
trunk:

make.out14-/data/vjoost/gnu/cp2k/cp2k/makefiles/../src/mc_ge_moves.F: In
function 'mc_ge_swap_move':
make.out14-/data/vjoost/gnu/cp2k/cp2k/makefiles/../src/mc_ge_moves.F:452:0:
error: definition in block 317 does not dominate use in block 316
make.out14-   SUBROUTINE mc_ge_swap_move(mc_par,force_env,bias_env,moves,&
make.out14- ^
make.out14-for SSA_NAME: vect_cst_.6470_7306 in statement:
make.out14-vect__5004.6467_1300 = vect_cst_.6470_7306 - vect_cst_.6473_6797;
make.out14-/data/vjoost/gnu/cp2k/cp2k/makefiles/../src/mc_ge_moves.F:452:0:
internal compiler error: verify_ssa failed
make.out14-0xaad07c verify_ssa(bool)
make.out14-../../gcc/gcc/tree-ssa.c:1096
make.out14-0x8448ae execute_function_todo
make.out14-../../gcc/gcc/passes.c:1844
make.out14-0x844f2b execute_todo
make.out14-../../gcc/gcc/passes.c:1877
make.out14-Please submit a full bug report,
make.out14-with preprocessed source if appropriate.
make.out14-Please include the complete backtrace with any bug report.
make.out14-See  for instructions.
make.out14-make[3]: *** [/tmp/cc6S2X6S.ltrans24.ltrans.o] Error 1

any suggestion on how to turn this into a testcase ?

[Bug c/59280] [4.8/4.9 Regression] ICE with attribute((constructor(invalid)))

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 29 07:43:48 2013
New Revision: 205511

URL: http://gcc.gnu.org/viewcvs?rev=205511&root=gcc&view=rev
Log:
PR c/59280
* c-common.c (get_priority): If TREE_VALUE (args) is IDENTIFIER_NODE,
goto invalid.  If it is error_mark_node, don't issue further
diagnostics.
testsuite/
* c-c++-common/pr59280.c: New test.

Added:
branches/gcc-4_8-branch/gcc/testsuite/c-c++-common/pr59280.c
Modified:
branches/gcc-4_8-branch/gcc/c-family/ChangeLog
branches/gcc-4_8-branch/gcc/c-family/c-common.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug c/59280] [4.8/4.9 Regression] ICE with attribute((constructor(invalid)))

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 29 07:42:23 2013
New Revision: 205510

URL: http://gcc.gnu.org/viewcvs?rev=205510&root=gcc&view=rev
Log:
PR c/59280
* c-common.c (get_priority): If TREE_VALUE (args) is IDENTIFIER_NODE,
goto invalid.  If it is error_mark_node, don't issue further
diagnostics.
testsuite/
* c-c++-common/pr59280.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/pr59280.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/testsuite/ChangeLog

[Bug lto/59332] Segmentation fault in inline_summary with LTO + attribute optimize

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Dmitry Gorbachev from comment #1)
> In view of LTO shortcomings / bugs, I think that switching LTO *off* on a
> per-function basis can be useful.
> 
> Perhaps it should be marked as 'enhancement'...

Can you expand on those shortcomings/bugs?

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[mtewoodbury at gmail dot com]

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

--- Comment #21 from Max TenEyck Woodbury  ---
(In reply to Joseph S. Myers from comment #20)
> Suspending pending a DR since I think the present code is correct and while
> the standard is ambiguous I think the interpretation here strains the
> wording of the standard.  I'd proposed to close this if a DR (or other WG14
> document) isn't under consideration at the Parma meeting of WG14.

A 'DR' is not necessary and is unlikely to be submitted.  The ambiguity
referred 
to is in the expansion of macros, not in the processing of directives.  

The elaborate description of the different forms of the '#line' (and other) 
directives makes it clear that  expansion is not to take place until 
after the  for the directive has been seen.  

Accepted usage is for '#line __LINE__' to leave the line numbering unchanged.  
Any other interpretation would require some form of expression evaluation in 
order to leave line numbering unchanged; a possibility that has been rejected.

[Bug lto/59332] Segmentation fault in inline_summary with LTO + attribute optimize

[d.g.gorbachev at gmail dot com]

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

--- Comment #1 from Dmitry Gorbachev  ---
In view of LTO shortcomings / bugs, I think that switching LTO *off* on a
per-function basis can be useful.

Perhaps it should be marked as 'enhancement'...

[Bug plugins/59335] Plugin doesn't build on trunk

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
These are two different issues.  The x86 one is a target specific issue and the
arm one is a generic issue.

That is what it should be doing for x86 should be something like arm does:
t-arm:TM_H += $(srcdir)/config/arm/arm-cores.def

[Bug plugins/59335] New: Plugin doesn't build on trunk

[joey.ye at arm dot com]

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

Bug ID: 59335
   Summary: Plugin doesn't build on trunk
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: plugins
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joey.ye at arm dot com

trunk 205454 breaks plugin on x86_64 and arm. When gcc is built and installed,
using it to build any plugin with

g++ -fPIC -g -O2 -shared -I `g++ -print-file-name=plugin`/include

will result as:

install/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/plugin/include/config/i386/i386-opts.h:37:24:
fatal error: stringop.def: No such file or directory
 #include "stringop.def"

install/lib/gcc/arm-none-eabi/4.9.0/plugin/include/builtins.def:881:29: fatal
error: chkp-builtins.def: No such file or directory

It looks that some header files needed for plugins are not installed correctly.
Plugins in testsuite pass as they use headers from GCC source tree.

[Bug regression/59320] ftree-vrp breaks simple loops

[astra at ionic dot at]

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

David Kaufmann  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #11 from David Kaufmann  ---
(In reply to Joost VandeVondele from comment #10)
> no weird behavior of vrp. given the size of dash_list (2) it correctly
> establishes the range on the value, i.e. that il must be either 0 or 1 (any
> other value would trigger out-of-bounds, which can't happen in a valid C
> program). All the rest is a consequence of this. So, the bug is in the C
> program, not the compiler.
Okay, I tried to apply a temporary fix in the Code and the bug went away.

I just don't understand how it can happen, that if there is a imminent
out-of-range happening somewhere in the loop and therefor il only may have the
value 0 or 1 it compiles it to code, which then stops checking the condition
and therefor running the loop until it gets out-of-bounds.

What surprises me is that a printf on "il < nd = (il

[Bug c/57574] -std=c99 inline function incorrectly has external linkage with prior static declaration

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.0

--- Comment #2 from Joseph S. Myers  ---
Fixed for 4.9.

[Bug c/57574] -std=c99 inline function incorrectly has external linkage with prior static declaration

[jsm28 at gcc dot gnu.org]

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

--- Comment #1 from Joseph S. Myers  ---
Author: jsm28
Date: Fri Nov 29 01:30:42 2013
New Revision: 205506

URL: http://gcc.gnu.org/viewcvs?rev=205506&root=gcc&view=rev
Log:
PR c/57574
c:
* c-decl.c (merge_decls): Clear DECL_EXTERNAL for a definition of
an inline function following a static declaration.

testsuite:
* gcc.dg/inline-35.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/inline-35.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug target/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC

[joseph at codesourcery dot com]

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

--- Comment #8 from joseph at codesourcery dot com  ---
It fails everywhere that (a) supports floating-point exceptions, (b) has 
not had the target hook added and (c) supports pthreads ((c) is a 
requirement for the test to run - the feature in question still won't work 
properly if (a) and (b) apply but pthreads aren't supported, it's just 
that the test won't run in that case).

[Bug ipa/58721] [4.9 Regression] The subroutine perdida is no longer inlined in fatigue.f90

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> After apllying this fix routine is inlined.

I have applied the following patch

--- ../_clean/gcc/ipa-inline.c2013-11-22 17:27:28.0 +0100
+++ gcc/ipa-inline.c2013-11-28 21:45:29.0 +0100
@@ -762,7 +762,7 @@ check_callers (struct cgraph_node *node,
  {
if (!can_inline_edge_p (e, true))
  return true;
-   if (!has_hot_call && cgraph_maybe_hot_edge_p (e))
+   if (!(*(bool*)has_hot_call) && cgraph_maybe_hot_edge_p (e))
  *(bool *)has_hot_call = true;
  }
   return false;

on top of revision 205497. However I do not see any improvement.

[Bug c++/59297] [4.7/4.8/4.9 Regression] ICE: openmp atomic with indirect LHS

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Nov 28 22:56:35 2013
New Revision: 205501

URL: http://gcc.gnu.org/viewcvs?rev=205501&root=gcc&view=rev
Log:
PR c++/59297
* semantics.c (finish_omp_atomic): Call finish_expr_stmt
rather than add_stmt.

* g++.dg/gomp/pr59297.C: New test.

Added:
branches/gcc-4_8-branch/gcc/testsuite/g++.dg/gomp/pr59297.C
Modified:
branches/gcc-4_8-branch/gcc/cp/ChangeLog
branches/gcc-4_8-branch/gcc/cp/semantics.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug c++/59297] [4.7/4.8/4.9 Regression] ICE: openmp atomic with indirect LHS

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Thu Nov 28 22:53:50 2013
New Revision: 205500

URL: http://gcc.gnu.org/viewcvs?rev=205500&root=gcc&view=rev
Log:
PR c++/59297
* semantics.c (finish_omp_atomic): Call finish_expr_stmt
rather than add_stmt.

* g++.dg/gomp/pr59297.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/gomp/pr59297.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|UNCONFIRMED |SUSPENDED
   Last reconfirmed||2013-11-28
 Ever confirmed|0   |1

--- Comment #20 from Joseph S. Myers  ---
Suspending pending a DR since I think the present code is correct and while the
standard is ambiguous I think the interpretation here strains the wording of
the standard.  I'd proposed to close this if a DR (or other WG14 document)
isn't under consideration at the Parma meeting of WG14.

[Bug target/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Target|sparc*-sun-solaris2.*,  |sparc*-sun-solaris2.*
   |arm-none-linux-gnueabihf|

--- Comment #7 from Eric Botcazou  ---
FWIW it also fails on PowerPC/Linux and IA-64/Linux, so I presume that it fails
everywhere except for 2 platforms?

[Bug middle-end/59327] [4.9 Regression] warning in expand_used_vars

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Nov 28 22:52:40 2013
New Revision: 205499

URL: http://gcc.gnu.org/viewcvs?rev=205499&root=gcc&view=rev
Log:
PR middle-end/59327
* cfgexpand.c (expand_used_vars): Avoid warning on 32-bit
HWI hosts.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c

[Bug tree-optimization/59334] [4.9 Regression] r205486 caused many failures

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-11-28
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
Some of failures are timeout.

[Bug target/57293] [4.8/4.9 Regression] not needed frame pointers on IA-32 (performance regression?)

[vmakarov at gcc dot gnu.org]

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

--- Comment #9 from Vladimir Makarov  ---
Author: vmakarov
Date: Thu Nov 28 21:45:21 2013
New Revision: 205498

URL: http://gcc.gnu.org/viewcvs?rev=205498&root=gcc&view=rev
Log:
2013-11-28  Vladimir Makarov  

PR target/57293
* ira.h (ira_setup_eliminable_regset): Remove parameter.
* ira.c (ira_setup_eliminable_regset): Ditto.  Add
SUPPORTS_STACK_ALIGNMENT for crtl->stack_realign_needed.
Don't call lra_init_elimination.
(ira): Call ira_setup_eliminable_regset without arguments.
* loop-invariant.c (calculate_loop_reg_pressure): Remove argument
from ira_setup_eliminable_regset call.
* gcse.c (calculate_bb_reg_pressure): Ditto.
* haifa-sched.c (sched_init): Ditto.
* lra.h (lra_init_elimination): Remove the prototype.
* lra-int.h (lra_insn_recog_data): New member sp_offset.  Move
used_insn_alternative upper.
(lra_eliminate_regs_1): Add one more parameter.
(lra-eliminate): Ditto.
* lra.c (lra_invalidate_insn_data): Set sp_offset.
(setup_sp_offset): New.
(lra_process_new_insns): Call setup_sp_offset.
(lra): Add argument to lra_eliminate calls.
* lra-constraints.c (get_equiv_substitution): Rename to get_equiv.
(get_equiv_with_elimination): New.
(process_addr_reg): Call get_equiv_with_elimination instead of
get_equiv_substitution.
(equiv_address_substitution): Ditto.
(loc_equivalence_change_p): Ditto.
(loc_equivalence_callback, lra_constraints): Ditto.
(curr_insn_transform): Ditto.  Print the sp offset
(process_alt_operands): Prevent stack pointer reloads.
(lra_constraints): Remove one argument from lra_eliminate call.
Move it up.  Mark used hard regs bfore it.  Use
get_equiv_with_elimination instead of get_equiv_substitution.
* lra-eliminations.c (lra_eliminate_regs_1): Add parameter and
assert for param values combination.  Use sp offset.  Add argument
to lra_eliminate_regs_1 calls.
(lra_eliminate_regs): Add argument to lra_eliminate_regs_1 call.
(curr_sp_change): New static var.
(mark_not_eliminable): Add parameter.  Update curr_sp_change.
Don't prevent elimination to sp if we can calculate its change.
Pass the argument to mark_not_eliminable calls.
(eliminate_regs_in_insn): Add a parameter.  Use sp offset.  Add
argument to lra_eliminate_regs_1 call.
(update_reg_eliminate): Move calculation of hard regs for spill
lower.  Switch off lra_in_progress temporarily to generate regs
involved into elimination.
(lra_init_elimination): Rename to init_elimination.  Make it
static.  Set up insn sp offset, check the offsets at the end of
BBs.
(process_insn_for_elimination): Add parameter.  Pass its value to
eliminate_regs_in_insn.
(lra_eliminate): : Add parameter.  Pass its value to
process_insn_for_elimination.  Add assert for param values
combination.  Call init_elimination.  Don't update offsets in
equivalence substitutions.
* lra-spills.c (assign_mem_slot): Don't call lra_eliminate_regs_1
for created stack slot.
(remove_pseudos): Call lra_eliminate_regs_1 before changing memory
onto stack slot.

2013-11-28  Vladimir Makarov  

PR target/57293
* gcc.target/i386/pr57293.c: New.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr57293.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gcse.c
trunk/gcc/haifa-sched.c
trunk/gcc/ira.c
trunk/gcc/ira.h
trunk/gcc/loop-invariant.c
trunk/gcc/lra-constraints.c
trunk/gcc/lra-eliminations.c
trunk/gcc/lra-int.h
trunk/gcc/lra-spills.c
trunk/gcc/lra.c
trunk/gcc/lra.h
trunk/gcc/testsuite/ChangeLog

[Bug ipa/58721] [4.9 Regression] The subroutine perdida is no longer inlined in fatigue.f90

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-11-28
 CC||hjl.tools at gmail dot com
 Ever confirmed|0   |1

--- Comment #2 from H.J. Lu  ---
(In reply to Yuri Rumyantsev from comment #1)
> We found the cause of performance degradation - bug was introduced by
> r202567, namely in callback function "check_callers":
> 
> was
> 
> if (!has_hot_call && cgraph_maybe_hot_edge_p (e))
> 
> must be
> 
> if (!(*(bool*)has_hot_call) && cgraph_maybe_hot_edge_p (e))
> 
> After apllying this fix routine is inlined.

It looks obvious.  Please submit a patch.  Thanks.

[Bug tree-optimization/59334] New: [4.9 Regression] r205486 caused many failures

[hjl.tools at gmail dot com]

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

Bug ID: 59334
   Summary: [4.9 Regression] r205486 caused many failures
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: rguenth at gcc dot gnu.org

On Linux/x86, r205486 caused:

FAIL: 22_locale/locale/cons/12438.cc execution test
FAIL: gcc.dg/tree-ssa/alias-25.c scan-tree-dump-not optimized "= 42"
FAIL: g++.dg/asan/deep-stack-uaf-1.C  -O1  output pattern test, is , should
match ERROR: AddressSanitizer:? heap-use-after-free on address.*(
FAIL: g++.dg/asan/deep-stack-uaf-1.C  -O2  output pattern test, is , should
match ERROR: AddressSanitizer:? heap-use-after-free on address.*(
FAIL: g++.dg/asan/deep-stack-uaf-1.C  -O3 -fomit-frame-pointer  output pattern
test, is , should match ERROR: AddressSanitizer:? heap-use-after-free on
address.*(
FAIL: g++.dg/asan/deep-stack-uaf-1.C  -O3 -g  output pattern test, is , should
match ERROR: AddressSanitizer:? heap-use-after-free on address.*(
FAIL: g++.dg/asan/deep-stack-uaf-1.C  -Os  output pattern test, is , should
match ERROR: AddressSanitizer:? heap-use-after-free on address.*(
FAIL: gfortran.dg/array_constructor_33.f90  -O  (test for excess errors)

[Bug regression/59320] ftree-vrp breaks simple loops

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #10 from Joost VandeVondele  
---
(In reply to David Kaufmann from comment #9)
> (In reply to Joost VandeVondele from comment #7)
> > (In reply to David Kaufmann from comment #5)
> > > Created attachment 31320 [details]
> > > preprocessor output
> > > the buggy function is on line 18136, but it does not seem to have been
> > > changed.
> > 
> > static unsigned char dash_list[16][2]
> > static int ndash_dot = 4;
> > nd=ndash_dot;
> > for (il =0; il > dash_list[op][il] = ...
> > }
> > so clearly il 
> i am not sure, that probably is another bug. (as dash_list[op]-size is only
> two, but dash_list[op][0], dash_list[op][1] and dash_list[op][3] get set.)

no weird behavior of vrp. given the size of dash_list (2) it correctly
establishes the range on the value, i.e. that il must be either 0 or 1 (any
other value would trigger out-of-bounds, which can't happen in a valid C
program). All the rest is a consequence of this. So, the bug is in the C
program, not the compiler.

[Bug regression/59320] ftree-vrp breaks simple loops

[astra at ionic dot at]

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

--- Comment #9 from David Kaufmann  ---
(In reply to Joost VandeVondele from comment #7)
> (In reply to David Kaufmann from comment #5)
> > Created attachment 31320 [details]
> > preprocessor output
> > the buggy function is on line 18136, but it does not seem to have been
> > changed.
> 
> static unsigned char dash_list[16][2]
> static int ndash_dot = 4;
> nd=ndash_dot;
> for (il =0; il dash_list[op][il] = ...
> }
> so clearly il

[Bug regression/59320] ftree-vrp breaks simple loops

[astra at ionic dot at]

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

--- Comment #8 from David Kaufmann  ---
Created attachment 31323
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31323&action=edit
gdb "backtrace full" when segfaulting

backtrace from gdb when opening xfig with provided testcase.

[Bug regression/59320] ftree-vrp breaks simple loops

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #7 from Joost VandeVondele  
---
(In reply to David Kaufmann from comment #5)
> Created attachment 31320 [details]
> preprocessor output
> the buggy function is on line 18136, but it does not seem to have been
> changed.

static unsigned char dash_list[16][2]
static int ndash_dot = 4;
nd=ndash_dot;
for (il =0; il

[Bug regression/59320] ftree-vrp breaks simple loops

[astra at ionic dot at]

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

--- Comment #6 from David Kaufmann  ---
(In reply to Richard Biener from comment #4)
> Please attach a testcase or at least preprocessed source of w_drawprim.c.
a testcase is the first attachment to this bug with either xfig version 3.2.5b
or 3.2.5c.
debian and fedora have currently version 3.2.5b in their repository.

i could reproduce the error in fedora-f18.x86_64 and fedora-f19.x86_64.

currently i do not have another system which has been updated recently and is
configured for compiling, maybe i'll find one in the next few days.

any input is welcome.

[Bug target/56788] _mm_frcz_sd and _mm_frcz_ss ignore their second argument

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #18 from Uroš Bizjak  ---
Fixed everywhere.

[Bug target/56788] _mm_frcz_sd and _mm_frcz_ss ignore their second argument

[uros at gcc dot gnu.org]

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

--- Comment #17 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Nov 28 18:14:23 2013
New Revision: 205497

URL: http://gcc.gnu.org/viewcvs?rev=205497&root=gcc&view=rev
Log:
Backport from mainline
2013-11-23  Uros Bizjak  

PR target/56788
* config/i386/i386.c (bdesc_multi_arg) :
Declare as MULTI_ARG_1_SF instruction.
: Decleare as MULTI_ARG_1_DF instruction.
* config/i386/sse.md (*xop_vmfrcz2): Rename
from *xop_vmfrcz_.
* config/i386/xopintrin.h (_mm_frcz_ss): Use __builtin_ia32_movss
to merge scalar result with __A.
(_mm_frcz_sd): Use __builtin_ia32_movsd to merge scalar
result with __A.

testsuite/ChangeLog:

Backport from mainline
2013-11-27  Uros Bizjak  
Ganesh Gopalasubramanian  

PR target/56788
* gcc.target/i386/xop-frczX.c: New test.


Added:
branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/xop-frczX.c
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/config/i386/i386.c
branches/gcc-4_7-branch/gcc/config/i386/sse.md
branches/gcc-4_7-branch/gcc/config/i386/xopintrin.h
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug middle-end/59208] [4.9 Regression] ice in initialize_flags_in_bb

[hubicka at gcc dot gnu.org]

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

--- Comment #7 from Jan Hubicka  ---
Created attachment 31322
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31322&action=edit
Proposed fix I am testing

Hi,
the problem here is that update_stmt is called with cfun being set to NULL.  It
uses ssa_operands_active (cfun) call that return false.
This patch makes us to set cfun correctly when updating the function body. 

It may be interesting to investigate why some testcases fails on PPC and not on
x86 - they may be cases where we missed devirtualization during early
optimization but for whatever reason we now handle it during IPA

Honza

[Bug sanitizer/59333] New: ICE with long long and -m32 -fsanitize=undefined

[mpolacek at gcc dot gnu.org]

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

Bug ID: 59333
   Summary: ICE with long long and -m32 -fsanitize=undefined
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

long long int
foo (long long int i, long long int j)
{
  return i * j;
}

$ ./cc1 -quiet -fsanitize=undefined x.c -m32
x.c: In function ‘foo’:
x.c:4:3: internal compiler error: in expand_expr_addr_expr_1, at expr.c:7672
   return i * j;
   ^
0x72fc9c expand_expr_addr_expr_1
/home/marek/src/gcc/gcc/expr.c:7672
0x7239f1 expand_expr_addr_expr
/home/marek/src/gcc/gcc/expr.c:7756
0x7239f1 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**)
/home/marek/src/gcc/gcc/expr.c:10508
0x63b788 expand_expr
/home/marek/src/gcc/gcc/expr.h:453
0x63b788 store_one_arg
/home/marek/src/gcc/gcc/calls.c:4513
0x640c70 expand_call(tree_node*, rtx_def*, int)
/home/marek/src/gcc/gcc/calls.c:3052
0x62803c expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/home/marek/src/gcc/gcc/builtins.c:6904
0x723912 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**)
/home/marek/src/gcc/gcc/expr.c:10283
0x811544 expand_normal
/home/marek/src/gcc/gcc/expr.h:459
0x811544 ubsan_expand_si_overflow_mul_check(gimple_statement_base*)
/home/marek/src/gcc/gcc/internal-fn.c:421
0x6543f7 expand_call_stmt
/home/marek/src/gcc/gcc/cfgexpand.c:2185
0x6543f7 expand_gimple_stmt_1
/home/marek/src/gcc/gcc/cfgexpand.c:3164
0x6543f7 expand_gimple_stmt
/home/marek/src/gcc/gcc/cfgexpand.c:3316
0x655b63 expand_gimple_basic_block
/home/marek/src/gcc/gcc/cfgexpand.c:5156
0x657496 gimple_expand_cfg
/home/marek/src/gcc/gcc/cfgexpand.c:5722
0x657496 execute
/home/marek/src/gcc/gcc/cfgexpand.c:5942

[Bug sanitizer/59333] ICE with long long and -m32 -fsanitize=undefined

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-11-28
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1

[Bug ipa/59226] [4.9 Regression] ICE: in record_target_from_binfo, at ipa-devirt.c:661

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from Jan Hubicka  ---
Mine; another manifestation of the virtual inheritance representation problem.

[Bug c/59280] [4.8/4.9 Regression] ICE with attribute((constructor(invalid)))

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-11-28
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 31321
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31321&action=edit
gcc49-pr59280.patch

Untested fix.

[Bug regression/59320] ftree-vrp breaks simple loops

[astra at ionic dot at]

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

--- Comment #5 from David Kaufmann  ---
Created attachment 31320
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31320&action=edit
preprocessor output

i hope this is the proper preprocessed source, i generated it with the "-E"
parameter.

the whole command was:
"gcc -E -O2 -fno-strength-reduce -fno-strict-aliasing -I/usr/include/X11
-I/usr/include -I/usr/include/X11 -I. -I/usr/include -Dlinux -D__amd64__
-D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE
-D_SVID_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DFUNCPROTO=15
-DNARROWPROTO -DUSE_XPM -DXAW3D -DXAW3D1_5E -DUSE_JPEG -DNEWARROWTYPES
w_drawprim.c -o w_drawprim.i"

the buggy function is on line 18136, but it does not seem to have been changed.

[Bug tree-optimization/58253] IPA-SRA creates calls with different arguments that the callee accepts

[jamborm at gcc dot gnu.org]

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

--- Comment #1 from Martin Jambor  ---
I do not quite understand why the port needs to look at alignments of
scalars passed by value at all but I assume there is a reason.

When it comes to the IPA-SRA created formal parameter and actual
argument in the pr52402.c testcase, the following happens.  The
decision in which register pair the parameter is passed is made in
epiphany_function_arg_boundary.  This is reached in two different
ways:

1. When compiling foo.isra.0, indirectly from call to
   targetm.calls.function_incoming_arg at function.c:2440.  The type
   is the type of the PARM_DECL which is aligned to 8 bits.

2. When expanding the call in main, indirectly from call to
   targetm.calls.function_arg.  The type passed is the type of the
   actual argument, which is an anonymous SSA name which has the
   natural alignment of the node which is 64.

Thus, epiphany_function_arg_boundary erroneously comes to two
different conclusions.  Assuming there is nothing wrong with the
above, we can fix the problem in IPA-SRA by the patch below which sets
the type of the PARM_DECL to natural mode alignment (bootstrapped and
tested and tested on x86_64-linux, the same on ppc64 is underway).
But again, I am not really sure what the semantics of alignment of
scalar PARM_DECL is.  Nevertheless, can you please check if the patch
indeed fixes the bug?  If so, I'll post it to the mailing list for
review/further discussion.  Thanks.


2013-11-28  Martin Jambor  

PR ipa/58253
* ipa-prop.c (ipa_modify_formal_parameters): Create decls of
non-BLKmode in their naturally aligned type.

diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
index 6bdb0df..a26b11a 100644
--- a/gcc/ipa-prop.c
+++ b/gcc/ipa-prop.c
@@ -3443,7 +3443,15 @@ ipa_modify_formal_parameters (tree fndecl,
ipa_parm_adjustment_vec adjustments)
   if (adj->by_ref)
 ptype = build_pointer_type (adj->type);
   else
-ptype = adj->type;
+{
+  ptype = adj->type;
+  if (TYPE_MODE (ptype) != BLKmode)
+{
+  unsigned malign = GET_MODE_ALIGNMENT (TYPE_MODE (ptype));
+  if (TYPE_ALIGN (ptype) < malign)
+ptype = build_aligned_type (ptype, malign);
+}
+}

   if (care_for_types)
 new_arg_types = tree_cons (NULL_TREE, ptype, new_arg_types);

[Bug c++/59297] [4.7/4.8/4.9 Regression] ICE: openmp atomic with indirect LHS

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Created attachment 31319
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31319&action=edit
gcc49-pr59297.patch

Untested fix.

[Bug target/56788] _mm_frcz_sd and _mm_frcz_ss ignore their second argument

[uros at gcc dot gnu.org]

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

--- Comment #16 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Nov 28 16:48:44 2013
New Revision: 205495

URL: http://gcc.gnu.org/viewcvs?rev=205495&root=gcc&view=rev
Log:
Backport from mainline
2013-11-23  Uros Bizjak  

PR target/56788
* config/i386/i386.c (bdesc_multi_arg) :
Declare as MULTI_ARG_1_SF instruction.
: Decleare as MULTI_ARG_1_DF instruction.
* config/i386/sse.md (*xop_vmfrcz2): Rename
from *xop_vmfrcz_.
* config/i386/xopintrin.h (_mm_frcz_ss): Use __builtin_ia32_movss
to merge scalar result with __A.
(_mm_frcz_sd): Use __builtin_ia32_movsd to merge scalar
result with __A.

testsuite/ChangeLog:

Backport from mainline
2013-11-27  Uros Bizjak  
Ganesh Gopalasubramanian  

PR target/56788
* gcc.target/i386/xop-frczX.c: New test.


Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/xop-frczX.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/config/i386/i386.c
branches/gcc-4_8-branch/gcc/config/i386/sse.md
branches/gcc-4_8-branch/gcc/config/i386/xopintrin.h
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug lto/59332] New: Segmentation fault in inline_summary with LTO + attribute optimize

[d.g.gorbachev at gmail dot com]

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

Bug ID: 59332
   Summary: Segmentation fault in inline_summary with LTO +
attribute optimize
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: d.g.gorbachev at gmail dot com

$ echo '__attribute__((optimize("no-lto"))) void foo(void) { }' > 1.c
$ gcc -S -flto 1.c
1.c:1:1: internal compiler error: Segmentation fault
 __attribute__((optimize("no-lto"))) void foo(void) { }
 ^
0x86dfff0 crash_signal
../../gcc-4.9/gcc/toplev.c:336
0x85230d4 vec::operator[](unsigned int)
../../gcc-4.9/gcc/vec.h:718
0x85230d4 inline_summary
../../gcc-4.9/gcc/ipa-inline.h:242
0x85230d4 inline_write_summary()
../../gcc-4.9/gcc/ipa-inline-analysis.c:4079
0x86172ee ipa_write_summaries_2
../../gcc-4.9/gcc/passes.c:2310
0x86173a4 ipa_write_summaries_1
../../gcc-4.9/gcc/passes.c:2340
0x8618148 ipa_write_summaries()
../../gcc-4.9/gcc/passes.c:2399
0x82f22a0 ipa_passes
../../gcc-4.9/gcc/cgraphunit.c:2030
0x82f31b4 compile()
../../gcc-4.9/gcc/cgraphunit.c:2126
0x82f3519 finalize_compilation_unit()
../../gcc-4.9/gcc/cgraphunit.c:2280
0x8143690 c_write_global_declarations()
../../gcc-4.9/gcc/c/c-decl.c:10388

GCC 4.9.0 20131124. Also fails with GCC 4.7, 4.8.

[Bug plugins/59214] [4.9 Regression] Many plugin test failures

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.0

--- Comment #2 from H.J. Lu  ---
Fixed as of revision 205478:

http://gcc.gnu.org/ml/gcc-testresults/2013-11/msg02108.html

[Bug c/59309] FAIL: c-c++-common/cilk-plus/CK/spawnee_inline.c -g -fcilkplus (test for excess errors)

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-11-28
  Component|middle-end  |c
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1

--- Comment #3 from H.J. Lu  ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03673.html

[Bug debug/59323] [4.9 Regression] Int. comp. error: in add_AT_specification, at dwarf2out.c:4026

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Thu Nov 28 15:22:55 2013
New Revision: 205487

URL: http://gcc.gnu.org/viewcvs?rev=205487&root=gcc&view=rev
Log:
2013-11-28  Richard Biener  

PR lto/59323
* gcc.dg/lto/pr59323-2_0.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/lto/pr59323-2_0.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/59273] [4.9 Regression] ICE in expand_expr_real_2, at expr.c:9188 on alpha

[ubizjak at gmail dot com]

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

--- Comment #7 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #6)
> Fixed.

I can confirm the fix on native alpha bootstrap [1].

[1] http://gcc.gnu.org/ml/gcc-testresults/2013-11/msg02115.html

[Bug middle-end/59330] [4.7/4.8 Regression] Crash in is_gimple_reg_type

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||4.9.0
Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression] Crash
   |Crash in is_gimple_reg_type |in is_gimple_reg_type
  Known to fail|4.9.0   |

--- Comment #4 from Richard Biener  ---
Fixed on trunk sofar.

[Bug middle-end/59330] [4.7/4.8/4.9 Regression] Crash in is_gimple_reg_type

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Thu Nov 28 14:52:44 2013
New Revision: 205486

URL: http://gcc.gnu.org/viewcvs?rev=205486&root=gcc&view=rev
Log:
2013-11-28  Richard Biener  

PR tree-optimization/59330
* tree-ssa-dce.c (eliminate_unnecessary_stmts): Simplify
and fix delayed marking of free calls not necessary.

* gcc.dg/torture/pr59330.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr59330.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-dce.c

[Bug sanitizer/59331] ubsan gives extra warnings with vla.

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-11-28
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Mine.

[Bug ipa/58721] [4.9 Regression] The subroutine perdida is no longer inlined in fatigue.f90

[ysrumyan at gmail dot com]

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

Yuri Rumyantsev  changed:

   What|Removed |Added

 CC||ysrumyan at gmail dot com

--- Comment #1 from Yuri Rumyantsev  ---
We found the cause of performance degradation - bug was introduced by r202567,
namely in callback function "check_callers":

was

if (!has_hot_call && cgraph_maybe_hot_edge_p (e))

must be

if (!(*(bool*)has_hot_call) && cgraph_maybe_hot_edge_p (e))

After apllying this fix routine is inlined.

[Bug middle-end/59327] [4.9 Regression] warning in expand_used_vars

[amylaar at gcc dot gnu.org]

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

--- Comment #4 from Jorn Wolfgang Rennecke  ---
(In reply to Jakub Jelinek from comment #3)
> Created attachment 31318 [details]
> gcc49-pr59327.patch
> 
> Untested fix.

This allows arc-elf and arc-epiphany configureed with --enable-werror-always
to build on i686-pc-linux.gnu.

[Bug sanitizer/59331] New: ubsan gives extra warnings with vla.

[larsbj at gullik dot net]

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

Bug ID: 59331
   Summary: ubsan gives extra warnings with vla.
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: larsbj at gullik dot net
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

g++ (GCC) 4.9.0 20131128 (experimental)
Copyright (C) 2013 Free Software Foundation, Inc.
r205479

This snippet:

-
void foo(int i)
{
char a[i];
(void)a;
}
-

Compiled with: g++ -c -std=gnu++11 -Wall -fsanitize=undefined

gives this warning:

In function ‘void foo(int)’:
3:13: warning: value computed is not used [-Wunused-value]

If -fsanitize=undefined is removed, no warning is given.

[Bug lto/59326] FAIL: gcc.dg/vect/vect-simd-clone-*.c

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
(In reply to Jakub Jelinek from comment #4)
> But then it won't handle the !node->definition cloning (it isn't actually
> cloning in that case, just creating another DECL_EXTERNAL FUNCTION_DECL with
> adjusted arguments).  So it really needs to be FOR_EACH_FUNCTION, but
> perhaps can avoid the cgraph_function_with_gimple_body_p/cgraph_get_body
> stuff if !node->definition.

Plus the DECL_ATTRIBUTES are there even without cgraph_get_body, right?
If yes, then the two new functions should go into expand_simd_clones after we
see whether we want to clone it at all, so perhaps best into simd_clone_create
's node->definition case right before cgraph_function_versioning.

[Bug lto/59326] FAIL: gcc.dg/vect/vect-simd-clone-*.c

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #3)
> Fix for that:
> 
> Index: gcc/omp-low.c
> ===
> --- gcc/omp-low.c   (revision 205484)
> +++ gcc/omp-low.c   (working copy)
> @@ -11734,8 +11734,13 @@ static unsigned int
>  ipa_omp_simd_clone (void)
>  {
>struct cgraph_node *node;
> -  FOR_EACH_FUNCTION (node)
> -expand_simd_clones (node);
> +  FOR_EACH_DEFINED_FUNCTION (node)
> +{
> +  if (!cgraph_function_with_gimple_body_p (node))
> +   continue;
> +  cgraph_get_body (node);
> +  expand_simd_clones (node);
> +}
>return 0;
>  }
> 
> 
> and now it magically works.

But then it won't handle the !node->definition cloning (it isn't actually
cloning in that case, just creating another DECL_EXTERNAL FUNCTION_DECL with
adjusted arguments).  So it really needs to be FOR_EACH_FUNCTION, but perhaps
can avoid the cgraph_function_with_gimple_body_p/cgraph_get_body stuff if
!node->definition.

[Bug c++/43734] cerr related segmentation fault

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #11 from Rolf Eike Beer  ---
>> I don't have the least idea what's going on here, and cannot debug
>> issues on Linux/SPARC since I don't have access to that platform.
>
> Sadly I can't give you direct access to my machine, but I'm willing to 
> assist on any debugging needed. Meanwhile a second user was able to 
> reproduce the issue on an independent system. We are hanging around in 
> #gentoo-sparc on Freenode in case you want to join us.

I don't have time to assist in an extensive remote debugging session,
sorry.

Rainer

[Bug lto/59326] FAIL: gcc.dg/vect/vect-simd-clone-*.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-11-28
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Fix for that:

Index: gcc/omp-low.c
===
--- gcc/omp-low.c   (revision 205484)
+++ gcc/omp-low.c   (working copy)
@@ -11734,8 +11734,13 @@ static unsigned int
 ipa_omp_simd_clone (void)
 {
   struct cgraph_node *node;
-  FOR_EACH_FUNCTION (node)
-expand_simd_clones (node);
+  FOR_EACH_DEFINED_FUNCTION (node)
+{
+  if (!cgraph_function_with_gimple_body_p (node))
+   continue;
+  cgraph_get_body (node);
+  expand_simd_clones (node);
+}
   return 0;
 }


and now it magically works.

[Bug lto/59326] FAIL: gcc.dg/vect/vect-simd-clone-*.c

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Hmm.  So apart from missing support for OMP_CLAUSE in hash_tree and more
important
in compare_tree_sccs_1 (all OMP_CLAUSE trees are currently considered equal
and thus merged).

The issue with the IPA cloning pass not running is that -fopenmp and
-fopenmp-simd are not LTO language frontend options and thus not handed
down to WPA or LTRANS stage.  Thus checking flag_openmp or flag_openmp_simd
(or probably flag_enable_cilkplus) in the IPA pass gate function will not
work (it's never set).

You either need to make those flags work for LTO or by other means
compute whether to execute the pass.  Hacks:

Index: gcc/omp-low.c
===
--- gcc/omp-low.c   (revision 205484)
+++ gcc/omp-low.c   (working copy)
@@ -11765,7 +11765,7 @@ public:

   /* opt_pass methods: */
   bool gate () { return flag_openmp || flag_openmp_simd
-   || flag_enable_cilkplus; }
+   || flag_enable_cilkplus || flag_ltrans; }
   unsigned int execute () { return ipa_omp_simd_clone (); }
 };

Index: gcc/lto/lto.c
===
--- gcc/lto/lto.c   (revision 205484)
+++ gcc/lto/lto.c   (working copy)
@@ -1402,6 +1410,11 @@ compare_tree_sccs_1 (tree t1, tree t2, t
   TREE_STRING_LENGTH (t1)) != 0)
   return false;

+  /* Do not merge OMP_CLAUSE trees.
+ ???  No technical reason not to, just implement proper compare.  */
+  if (code == OMP_CLAUSE)
+return false;
+
 #undef compare_values


with those I get

lto1: internal compiler error: Segmentation fault
0xaed293 crash_signal
  /space/rguenther/src/svn/trunk/gcc/toplev.c:336
0xb6a4d4 copy_forbidden
  /space/rguenther/src/svn/trunk/gcc/tree-inline.c:3261
0xb6edcd tree_versionable_function_p(tree_node*)
  /space/rguenther/src/svn/trunk/gcc/tree-inline.c:5100
0x6ce38e cgraph_function_versioning(cgraph_node*, vec, vec*, bitmap_head_def*, bool,
bitmap_head_def*, basic_block_def*, char const*)
  /space/rguenther/src/svn/trunk/gcc/cgraphclones.c:848
0x9cae4f simd_clone_create
  /space/rguenther/src/svn/trunk/gcc/omp-low.c:10916
0x9ce798 expand_simd_clones
  /space/rguenther/src/svn/trunk/gcc/omp-low.c:11698
0x9ce92c ipa_omp_simd_clone
  /space/rguenther/src/svn/trunk/gcc/omp-low.c:11738
0x9ce9d0 execute
  /space/rguenther/src/svn/trunk/gcc/omp-low.c:11769

appearantly that's the cgraph_get_body stuff Honza mentioned.

[Bug c++/43734] cerr related segmentation fault

[e...@sf-mail.de]

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

--- Comment #11 from Rolf Eike Beer  ---
> I don't have the least idea what's going on here, and cannot debug
> issues on Linux/SPARC since I don't have access to that platform.

Sadly I can't give you direct access to my machine, but I'm willing to 
assist on any debugging needed. Meanwhile a second user was able to 
reproduce the issue on an independent system. We are hanging around in 
#gentoo-sparc on Freenode in case you want to join us.

[Bug c++/43734] cerr related segmentation fault

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #8 from Rolf Eike Beer  ---
> I get the same problem using gcc 4.5, 4.7, and 4.8 on a Sun Fire V240 running
> Gentoo. Even if the compiler says "Gentoo" it is built with use flag 
> "vanilla",
> i.e. without any Gentoo patches.
>
> The test code is simply:
>
> #include 
>
> int main(void) {
> std::cerr << "test";
> return 0;
> }
>
> Which will output "test" and then segfault. I can reproduce this at will and
> can give you further information (traces, asm, poking with gdb, whatever), 
> just
> ask. I have tried it with both binutils 2.23.1 and .2, the result is the same:

Works just fine for me with mainline g++ on sparc-sun-solaris2.11
configured with gas/gld 2.23.2.

I don't have the least idea what's going on here, and cannot debug
issues on Linux/SPARC since I don't have access to that platform.

Rainer

[Bug libstdc++/59325] Provide a way to disable deprecated warnings

[andysem at mail dot ru]

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

--- Comment #4 from andysem at mail dot ru ---
(In reply to Jonathan Wakely from comment #3)
> Doing this before any other includes will work:
> 
> #include 
> #undef _GLIBCXX_DEPRECATED
> #define _GLIBCXX_DEPRECATED
> 
> I'm not convinced we want to support this officially.

Yes, I'm doing something like that now, although I also have to detect that
we're using libstdc++. And I also have no easy way to add that code in every
.cpp file I have in my project, so I have to resort to -include command line
argument for gcc. That, in turn brings additional complications of detecting
which files need that tweak (i.e. C++ files) and which don't (i.e. C files). I
just think that all these hoops could be avoided if libstdc++ was a little more
friendly in this regard. After all, there's no harm in using e.g. auto_ptr in
C++11 code, it surely won't disappear from STL any time soon, so the warning is
a bit overreactive anyway.

[Bug libstdc++/59325] Provide a way to disable deprecated warnings

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Doing this before any other includes will work:

#include 
#undef _GLIBCXX_DEPRECATED
#define _GLIBCXX_DEPRECATED

I'm not convinced we want to support this officially.

[Bug middle-end/59257] usan/*san: Dpcumentation oddness of -fsanitize= / -fsanitize=shift

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-11-28
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1

--- Comment #3 from Marek Polacek  ---
We have a patch and are waiting for a review.  Thanks Tobias and Manuel.
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03082.html

[Bug sanitizer/59106] Failure to link against static libasan

[y.gribov at samsung dot com]

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

Yury Gribov  changed:

   What|Removed |Added

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

--- Comment #20 from Yury Gribov  ---
All issues fixed, closing the bug.

[Bug sanitizer/59106] Failure to link against static libasan

[ygribov at gcc dot gnu.org]

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

--- Comment #19 from ygribov at gcc dot gnu.org ---
Author: ygribov
Date: Thu Nov 28 12:20:23 2013
New Revision: 205482

URL: http://gcc.gnu.org/viewcvs?rev=205482&root=gcc&view=rev
Log:
2013-11-28  Jakub Jelinek  
Yury Gribov  

PR sanitizer/59106
* ubsan/Makefile.am (AM_CXXFLAGS): Disable -frtti for files that
don't need it.
* ubsan/Makefile.in: Regenerated.

Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/ubsan/Makefile.am
trunk/libsanitizer/ubsan/Makefile.in

[Bug debug/54694] [4.7/4.8/4.9 Regression] internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2387

[hjl.tools at gmail dot com]

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

--- Comment #11 from H.J. Lu  ---
I won't call it exactly a regression since -mavx is a new
option and -march=native adds -mavx implicitly.

[Bug tree-optimization/59322] [4.9 Regression] ICE with segfault on valid code at -O1, -O2, and -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Started with r205279.

[Bug debug/54694] [4.7/4.8/4.9 Regression] internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2387

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Last reconfirmed|2013-11-28 00:00:00 |2012-09-25 0:00
 CC||hjl.tools at gmail dot com

--- Comment #10 from H.J. Lu  ---
"ebp" is a frame pointer and used by GCC internally.
It shouldn't be marked as fixed.  If

register struct CPUX86State *env asm ("ebp");

has to be used, -mno-avx is a reasonable workaround.

[Bug c++/33799] Return value's destructor not executed when a local variable's destructor throws

[temporal at gmail dot com]

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

--- Comment #7 from Kenton Varda  ---
> It's now 2013 so the sensible thing to do is not return by value
> if your destructor can throw.

That actually sounds like a pretty difficult rule to follow, unless you either
ban throwing destructors altogether or ban returning by value altogether.

The don't-throw-from-destructors rule is, of course, popular, but not
universally agreed upon.  I don't think this bug is the right place to debate
it (maybe try http://goo.gl/haB5nm), but I would hope that GCC wouldn't refuse
to fix a bug simply because they disagree with the coding style that triggers
that bug.

> FWIW Clang also behaves the same as G++ and Intel,

Yes, I noticed, and Clang has also had a bug filed against them which has
languished for years.  Nevertheless, the behavior is wrong.

> and of course calls std::terminate() in C++11 mode.

Unless the destructor has noexcept(false).

[Bug tree-optimization/59299] We do not sink loads

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-11-28
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug debug/59323] [4.9 Regression] Int. comp. error: in add_AT_specification, at dwarf2out.c:4026

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Fixed.

[Bug debug/59323] [4.9 Regression] Int. comp. error: in add_AT_specification, at dwarf2out.c:4026

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Thu Nov 28 12:09:10 2013
New Revision: 205481

URL: http://gcc.gnu.org/viewcvs?rev=205481&root=gcc&view=rev
Log:
2013-11-28  Richard Biener  

PR lto/59323
* lto-streamer-out.c (tree_is_indexable): TYPE_DECLs and
CONST_DECLs in function context are not indexable.

* gcc.dg/lto/pr59323_0.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/lto/pr59323_0.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-streamer-out.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/54694] [4.7/4.8/4.9 Regression] internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2387

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 Status|WAITING |NEW
   Last reconfirmed|2012-09-25 00:00:00 |2013-11-28
 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch
  Component|preprocessor|debug
  Known to work||4.4.7
Summary|internal compiler error: in |[4.7/4.8/4.9 Regression]
   |dwarf2out_frame_debug_expr, |internal compiler error: in
   |at dwarf2out.c:2387 |dwarf2out_frame_debug_expr,
   ||at dwarf2out.c:2387
  Known to fail||4.7.0, 4.8.0, 4.9.0

--- Comment #9 from Joost VandeVondele  
---
works with a gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) fails with trunk.

seems like a debug rather than preprocessor problem.

[Bug c++/59271] [4.9 Regression] a.C:16:21: internal compiler error: in strip_typedefs, at cp/tree.c:1315

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Even more reduced testcase:
void
foo (int n)
{
  int a[n];
  [&a] (auto m)
{
  for (auto i : a)
m += i;
  return m;
};
}

[Bug target/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  ---
> Btw, for the release I consider this a testsuite bug (the test should be
> disabled/skipped for archs not supporting the feature).

Yes, but only immediately before the release, as that's a good reminder.

[Bug middle-end/59327] [4.9 Regression] warning in expand_used_vars

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Created attachment 31318
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31318&action=edit
gcc49-pr59327.patch

Untested fix.

[Bug middle-end/59330] [4.7/4.8/4.9 Regression] Crash in is_gimple_reg_type

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Last reconfirmed|2013-11-28 00:00:00 |
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #2 from Richard Biener  ---
(gdb) call debug_tree (arg)
 def_stmt 

version 1 in-free-list>

from cddce.  I'll have a look.

[Bug middle-end/59330] [4.7/4.8/4.9 Regression] Crash in is_gimple_reg_type

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-11-28
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |4.7.4
Summary|Crash in is_gimple_reg_type |[4.7/4.8/4.9 Regression]
   ||Crash in is_gimple_reg_type
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

With 4.8:
i.c: In function ‘main’:
i.c:15:1: internal compiler error: Segmentation fault
 }
 ^
0x7e0a8f crash_signal
/home/marek/src/gcc/gcc/toplev.c:332
0x8ecb9b useless_type_conversion_p(tree_node*, tree_node*)
/home/marek/src/gcc/gcc/tree-ssa.c:1198
0x8ed37d types_compatible_p(tree_node*, tree_node*)
/home/marek/src/gcc/gcc/tree-ssa.c:1421
0x68f4d4 gimple_check_call_args
/home/marek/src/gcc/gcc/gimple-low.c:242
0x68f4d4 gimple_check_call_matching_types(gimple_statement_d*, tree_node*)
/home/marek/src/gcc/gcc/gimple-low.c:288
0x59efa4 cgraph_create_edge_1
/home/marek/src/gcc/gcc/cgraph.c:818
0x59fa7d cgraph_create_edge(cgraph_node*, cgraph_node*, gimple_statement_d*,
long, int)
/home/marek/src/gcc/gcc/cgraph.c:838
0x5a32a9 rebuild_cgraph_edges()
/home/marek/src/gcc/gcc/cgraphbuild.c:434

[Bug preprocessor/54694] internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2387

[octoploid at yandex dot com]

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

--- Comment #8 from Markus Trippelsdorf  ---
Ping.
All supported gcc versions are affected. Can someone
please have a look?

[Bug middle-end/59327] [4.9 Regression] warning in expand_used_vars

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-11-28
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |4.9.0
Summary|warning in expand_used_vars |[4.9 Regression] warning in
   ||expand_used_vars
 Ever confirmed|0   |1

[Bug libstdc++/59325] Provide a way to disable deprecated warnings

[andysem at mail dot ru]

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

--- Comment #2 from andysem at mail dot ru ---
(In reply to Jonathan Wakely from comment #1)
> You can use a #pragma to disable -Wdeprecated locally

But the legacy C++ is used in the library, which code I'd like to avoid
changing.

[Bug middle-end/59327] warning in expand_used_vars

[amylaar at gcc dot gnu.org]

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

--- Comment #2 from Jorn Wolfgang Rennecke  ---
sz is HOST_WIDE_INT, ASAN_RED_ZONE_SIZE is an int literal, and data.asan_alignb
is an unsigned int.

With 32 bit int and HOST_WIDE_INT, this results in a 32 bit signed/unsigned
comparison.

When building a target with need_64bit_hwint (according to config.gcc),
on a host with 32 bit int, the right hand side of the comparison gets
sign extended to HOST_WIDE_INT, thus the warning will not show up when
testing such a combination / bootstrapping such a host/target.

[Bug tree-optimization/59014] [4.7 Regression] wrong code at -Os and above on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2
  Known to work||4.8.3, 4.9.0
Summary|[4.7/4.8/4.9 Regression]|[4.7 Regression] wrong code
   |wrong code at -Os and above |at -Os and above on
   |on x86_64-linux-gnu |x86_64-linux-gnu
  Known to fail||4.8.2

[Bug c++/59315] [4.9 regression] g++.dg/warn/Wunused-3.C FAILs on Solaris

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug target/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #5 from Richard Biener  ---
Btw, for the release I consider this a testsuite bug (the test should be
disabled/skipped for archs not supporting the feature).

[Bug rtl-optimization/59317] [4.9 Regression] [LRA,MIPS] ICE: in check_rtl, at lra.c (insn does not satisfy constraints)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||mips16
   Target Milestone|--- |4.9.0

[Bug debug/59319] gcc does not emit DW_AT_friend or DW_TAG_friend

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-11-28
 Ever confirmed|0   |1
   Severity|normal  |enhancement

[Bug regression/59320] ftree-vrp breaks simple loops

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2013-11-28
 Ever confirmed|0   |1

--- Comment #4 from Richard Biener  ---
Please attach a testcase or at least preprocessed source of w_drawprim.c.

[Bug driver/59321] -fuse-ld does not have effect on -print-prog-name

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Richard Biener  ---
(In reply to H.J. Lu from comment #1)
> -print-prog-name=foobar gives the path name of program, foobar.
> which isn't necessarily used by the GCC driver:
> 
> [hjl@gnu-6 gcc-4.6.3-x32]$ ./bin/gcc -print-prog-name=as  
> as
> [hjl@gnu-6 gcc-4.6.3-x32]$ ./bin/gcc -print-prog-name=foobar
> foobar

This is only the result if a full path cannot be determined.

> gcc -print-prog-name=as
/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/bin/as


> Should we consider -print-prog-name=ld as special case?

Not really, -print-prog-name prints the command gcc uses if it were
to use that command.  It won't use 'ld' but 'ld.gold' with -fuse-ld=gold
so -print-prog-name=ld is simply not the correct way to determine which
linker GCC ultimately would use.

Thus you'd want a -print-linker-name.

[Bug middle-end/59327] warning in expand_used_vars

[amylaar at gcc dot gnu.org]

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

--- Comment #1 from Jorn Wolfgang Rennecke  ---
The warning also happens when using g++ (GCC) 4.9.0 20131128 (experimental),
and when building gcc for target epiphany-elf.

[Bug c++/59312] Incorrect warning "defaulted move assignment for ... calls a non-trivial move assignment operator for virtual base ..."

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Alexander Khovansky from comment #0)
> — any direct or indirect virtual base class.

I'm looking at N3290, but was looking for a bullet starting with that text. Now
I see it's at the very end of the last bullet, sorry.

In any case, that isn't in the current draft, it was removed by
http://open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1402 and G++
implements that resolution.

[Bug tree-optimization/59322] [4.9 Regression] ICE with segfault on valid code at -O1, -O2, and -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug lto/59326] FAIL: gcc.dg/vect/vect-simd-clone-*.c

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 31317
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31317&action=edit
gcc49-pr59326.patch

Untested LTO streaming of OMP_CLAUSEs.

[Bug middle-end/59330] New: Crash in is_gimple_reg_type

[d.g.gorbachev at gmail dot com]

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

Bug ID: 59330
   Summary: Crash in is_gimple_reg_type
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: d.g.gorbachev at gmail dot com

=== 8< ===
void free(void *p)
{
}

void *foo(void)
{
  return 0;
}

int main(void)
{
  void *p = foo();
  free(p);
  return 0;
}
=== >8 ===

$ gcc -O 1.c
1.c: In function 'main':
1.c:15:1: internal compiler error: Segmentation fault
 }
 ^
0x86dfff0 crash_signal
../../gcc-4.9/gcc/toplev.c:336
0x871992f is_gimple_reg_type
../../gcc-4.9/gcc/gimple-expr.h:74
0x871992f verify_gimple_call
../../gcc-4.9/gcc/tree-cfg.c:3190
0x871ac23 verify_gimple_stmt
../../gcc-4.9/gcc/tree-cfg.c:4306
0x8721a9a verify_gimple_in_cfg(function*)
../../gcc-4.9/gcc/tree-cfg.c:4765
0x86158d5 execute_function_todo
../../gcc-4.9/gcc/passes.c:1843
0x8615a5b do_per_function
../../gcc-4.9/gcc/passes.c:1573
0x8615bee execute_todo
../../gcc-4.9/gcc/passes.c:1877
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/59322] [4.9 Regression] ICE with segfault on valid code at -O1, -O2, and -O3 on x86_64-linux-gnu

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-11-28
 CC||law at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
  Known to work||4.8.2
   Target Milestone|--- |4.9.0
Summary|ICE with segfault on valid  |[4.9 Regression] ICE with
   |code at -O1, -O2, and -O3   |segfault on valid code at
   |on x86_64-linux-gnu |-O1, -O2, and -O3 on
   ||x86_64-linux-gnu
 Ever confirmed|0   |1
  Known to fail||4.9.0

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/33799] Return value's destructor not executed when a local variable's destructor throws

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
It's now 2013 so the sensible thing to do is not return by value if your
destructor can throw.

FWIW Clang also behaves the same as G++ and Intel, and of course calls
std::terminate() in C++11 mode.

[Bug c++/59329] New: Using `assert(...)` is not allowed in constexpr functions

[vittorio.romeo at outlook dot com]

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

Bug ID: 59329
   Summary: Using `assert(...)` is not allowed in constexpr
functions
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vittorio.romeo at outlook dot com

inline constexpr int exampleFunction(int min, int max)
{
assert(min <= max);
return min + max;
}

The above function fails to compile, because of the `assert(min <= max)`. 

g++ reports that a constexpr function may only be composed of a simple return
statement.

clang++ compiles the function successfully.



Is it possible to lift this restriction?

[Bug libstdc++/59325] Provide a way to disable deprecated warnings

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
You can use a #pragma to disable -Wdeprecated locally

[Bug lto/59326] FAIL: gcc.dg/vect/vect-simd-clone-*.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Component|c   |lto
   Target Milestone|--- |4.9.0

[Bug c++/59312] Incorrect warning "defaulted move assignment for ... calls a non-trivial move assignment operator for virtual base ..."

[alexander.o.khovansky at yandex dot com]

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

--- Comment #2 from Alexander Khovansky  ---
Jonathan Wakely,
I am looking at working draft N3337
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf), which has
only editorial changes
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3338.html) since
released standard (N3291).
If you have pre-release draft N3242, paragraphs 20 and 23 are numbered 21 and
24.

[Bug c++/59328] New: Template cast operator ambiguity in a delete expression

[maxime.van.noppen at gmail dot com]

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

Bug ID: 59328
   Summary: Template cast operator ambiguity in a delete
expression
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: maxime.van.noppen at gmail dot com

The following code fails to compile with gcc whereas it works on Clang, Visual
Studio and ICC.

The version of gcc I tested: 4.4.7, 4.5.3, 4.6.4, 4.7.3, 4.8.1, 4.9.0 20130909

Code snippet:

template
struct Ptr
{
  template
  operator U*() const;

  operator const T*() const;
};

void foo()
{
  Ptr ptr;
  delete ptr;
}

Errors:

error: default type conversion can't deduce template argument for
‘template Ptr::operator U*() const [with U = U; T = int]’
error: type ‘struct Ptr’ argument given to ‘delete’, expected pointer

My understanding is that the compiler shouldn't consider the templated cast
operator and that there shouldn't be an ambiguity here. This is what the other
compilers mentioned above do.

This is somewhat similar to the bug 58119 and I can confirm that the bug was
fixed on 4.9.0 20130909 but this code still fails on that version.