[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454 --- Comment #32 from Ilya Enkovich --- (In reply to Uroš Bizjak from comment #31) > Maybe we can use HJ's patch from Comment #27 and communicate converted_insns > flag from convert_scalars_to_vector to ix86_finalize_stack_realign_flags? > The

[Bug c++/69515] New: partial specialization of variable templates is broken

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69515 Bug ID: 69515 Summary: partial specialization of variable templates is broken Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug lto/68881] [6 Regression] UNRESOLVED/FAIL: gcc.dg/lto/attr-weakref-1 -O2 -flto

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68881 --- Comment #14 from H.J. Lu --- (In reply to Jakub Jelinek from comment #13) > While GCC can do that, what if weakref is used in the source and the > definition is provided by user in inline asm? The assembly manual says: 7.102 '.weakref

[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454 --- Comment #33 from H.J. Lu --- (In reply to Ilya Enkovich from comment #32) > (In reply to Uroš Bizjak from comment #31) > > Maybe we can use HJ's patch from Comment #27 and communicate converted_insns > > flag from convert_scalars_to_vector

[Bug libstdc++/69295] [6 Regression] New special math function failures

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69295 --- Comment #10 from Jakub Jelinek --- Does -ffloat-store help on ppc64 though? I believe that target doesn't have excess precision... Perhaps fma is used somewhere (can you objdump -dr check_value.exe | grep madd ?)? No idea if it is possible

[Bug libstdc++/69295] [6 Regression] New special math function failures

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69295 --- Comment #11 from Jonathan Wakely --- (In reply to Jakub Jelinek from comment #10) > Does -ffloat-store help on ppc64 though? I believe that target doesn't have > excess precision... Perhaps fma is used somewhere (can you objdump -dr >

[Bug rtl-optimization/68730] [6 Regression] wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68730 --- Comment #14 from Bernd Schmidt --- It does look like an issue with lra-remat...

[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454 --- Comment #27 from H.J. Lu --- (In reply to Ilya Enkovich from comment #26) > (In reply to H.J. Lu from comment #25) > > Please add -mpreferred-stack-boundary=2 to your tests. Otherwise, > > you just remove a nop. > > Here is a test which

[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454 --- Comment #28 from Jakub Jelinek --- (In reply to H.J. Lu from comment #27) > (In reply to Ilya Enkovich from comment #26) > > (In reply to H.J. Lu from comment #25) > > > Please add -mpreferred-stack-boundary=2 to your tests. Otherwise, > >

[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454 --- Comment #29 from H.J. Lu --- (In reply to Jakub Jelinek from comment #28) > > Which will likely penalize even code where the stv pass wouldn't do anything. In normal case it is a nop since the incoming stack is 128-bit aligned. > Isn't it

[Bug rtl-optimization/69052] [6 Regression] Performance regression after r229402.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69052 --- Comment #10 from Ilya Enkovich --- (In reply to amker from comment #9) > I know little about x86, is it because of generation of non-canonical rtl > expression after this change? > > Another question for this case is: Is it because operand

[Bug c++/69494] Optimizer eliminates assignment to volatile subobject

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69494 --- Comment #2 from Lukas --- I was wrong about what part of the standard defines the behavior for volatile access. Paragraph 8 of [intro.execution] specifies that access to volatile objects is observable behavior. Access is defined in

[Bug lto/68881] [6 Regression] UNRESOLVED/FAIL: gcc.dg/lto/attr-weakref-1 -O2 -flto

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68881 --- Comment #13 from Jakub Jelinek --- While GCC can do that, what if weakref is used in the source and the definition is provided by user in inline asm?

[Bug target/69245] [6 Regression] ICE in extract_insn, at recog.c:2286 on arm-linux-gnueabihf

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69245 --- Comment #14 from chrbr at gcc dot gnu.org --- Author: chrbr Date: Wed Jan 27 13:03:45 2016 New Revision: 232872 URL: https://gcc.gnu.org/viewcvs?rev=232872=gcc=rev Log: 2016-01-20 Christian Bruel PR

[Bug c/69429] gcc create sparse exec/libs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69429 --- Comment #4 from joakim.tjernlund at transmode dot se --- (In reply to Jakub Jelinek from comment #3) > Because most of the powerpc distros now use 64KB page size instead of 4KB, > so having only 4KB common page size means security protection

[Bug fortran/69514] New: ICE with nested array constructor

0x61d029 match_mult_operand gcc/fortran/matchexp.c:267 $ gfortran --version GNU Fortran (GCC) 6.0.0 20160127 (experimental)

[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454 --- Comment #31 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #28) > Which will likely penalize even code where the stv pass wouldn't do anything. > Isn't it better to just disable the stv pass if the stack isn't aligned > enough

[Bug c/69429] gcc create sparse exec/libs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69429 --- Comment #5 from Jakub Jelinek --- Of course even for ppc32. The ppc64 kernel supports ppc32 binaries.

[Bug rtl-optimization/69052] [6 Regression] Performance regression after r229402.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69052 --- Comment #11 from amker at gcc dot gnu.org --- (In reply to Ilya Enkovich from comment #10) > (In reply to amker from comment #9) > > I know little about x86, is it because of generation of non-canonical rtl > > expression after this change? >

[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454 --- Comment #30 from H.J. Lu --- Try this one: diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index a03a515..c82883e 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -3588,16 +3588,6 @@ convert_scalars_to_vector

[Bug target/69245] [6 Regression] ICE in extract_insn, at recog.c:2286 on arm-linux-gnueabihf

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69245 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug tree-optimization/69355] [5 Regression] Wrong results with -O1 optimization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69355 --- Comment #21 from Martin Jambor --- Author: jamborm Date: Wed Jan 27 14:51:17 2016 New Revision: 232877 URL: https://gcc.gnu.org/viewcvs?rev=232877=gcc=rev Log: [PR 69355] Correct hole detection when total_scalarization fails 2016-01-27

[Bug tree-optimization/69166] [4.9/5/6 Regression] ICE in get_initial_def_for_reduction, at tree-vect-loop.c:4188

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69166 --- Comment #8 from Richard Biener --- Author: rguenth Date: Wed Jan 27 14:54:03 2016 New Revision: 232878 URL: https://gcc.gnu.org/viewcvs?rev=232878=gcc=rev Log: 2016-01-27 Richard Biener PR

[Bug tree-optimization/69166] [4.9/5 Regression] ICE in get_initial_def_for_reduction, at tree-vect-loop.c:4188

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69166 Richard Biener changed: What|Removed |Added Known to work||6.0 Summary|[4.9/5/6

[Bug target/68662] [6 regression] FAIL: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o link, -O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68662 --- Comment #8 from Peter Bergner --- (In reply to Jakub Jelinek from comment #7) > seems to ICE due to endless recursion with -O2 -m32 (every force_reg causes > another force_reg, at least in x86_64-linux -> powerpc64-linux cross). I see a

[Bug fortran/69268] [5 Regression] Sourced allocation calls function twice

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69268 vehre at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING

[Bug fortran/69495] unused-label warning does not tell which flag triggered it

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69495 --- Comment #3 from janus at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #2) > I think there must be a lot more cases of this: Yes, those should be taken care of as well. I'll try to do that. I guess practically all

[Bug fortran/69495] unused-label warning does not tell which flag triggered it

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69495 --- Comment #4 from janus at gcc dot gnu.org --- Btw, I noticed another loosely related issue concerning misspellings of the warning flags: $ gfortran -Wunused-labels test.f90 gfortran: error: unrecognized command line option ‘-Wunused-labels’

[Bug libstdc++/69295] [6 Regression] New special math function failures

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69295 --- Comment #12 from Jonathan Wakely --- Author: redi Date: Wed Jan 27 15:09:38 2016 New Revision: 232879 URL: https://gcc.gnu.org/viewcvs?rev=232879=gcc=rev Log: Set FP options for failing special functions tests PR libstdc++/69295

[Bug libstdc++/69295] [6 Regression] New special math function failures

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69295 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug fortran/69495] unused-label warning does not tell which flag triggered it

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69495 --- Comment #5 from Manuel López-Ibáñez --- (In reply to janus from comment #4) > This seems very inconsistent: All three calls involve an invalid flag, but > the diagnostics is very different for each of them (it's particularly bad > that the

[Bug fortran/69485] oddity with -Wtabs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69485 --- Comment #5 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #4) > Confirmed from 4.8 up to trunk (6.0) for fixed-form. > > After converting the include file to free-form I get So you're saying the problem

[Bug fortran/69495] unused-label warning does not tell which flag triggered it

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69495 --- Comment #6 from Manuel López-Ibáñez --- (In reply to janus from comment #3) > I guess practically all occurrences of "gfc_warning (0, ..." need to be > transformed, or are there cases where the zero is legitimate? Most warnings don't have a

<    1   2   3