[Bug middle-end/56589] Array bounds violation is very end-user unfriendly

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #2 from Jakub Jelinek  2013-03-11 
08:27:09 UTC ---

PR53265 is for the warning.

[Bug fortran/55362] [4.6/4.7 Regression] ICE with size() on character pointer

[burnus at gcc dot gnu.org]

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



--- Comment #12 from Tobias Burnus  2013-03-11 
08:30:42 UTC ---

(In reply to comment #11)

> r196583 seems to break 4_6 branch bootstrap with [...]



I believe that this has been fixed by Rev. 196584 (comment 10), which happened

45 minutes after Rev. 196583.

[Bug tree-optimization/56522] [4.8 Regression] Bytemark ASSIGNMENT 9% / 11% slower

[rguenth at gcc dot gnu.org]

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



--- Comment #14 from Richard Biener  2013-03-11 
08:45:04 UTC ---

(In reply to comment #13)

> There is almost no difference with reduced test case. Assignment in nbench can

> be tested with:

> ./nbench -cCOM.DAT

> 

> where file COM.DAT has content:

> 

> ALLSTATS=F

> DONUMSORT=F

> DOSTRINGSORT=F

> DOBITFIELD=F

> DOEMF=F

> DOFOUR=F

> DOASSIGN=T

> DOIDEA=F

> DOHUFF=F

> DONNET=F

> DOLU=F

> 

> Which CPU have you tested?



processor   : 7

vendor_id   : GenuineIntel

cpu family  : 6

model   : 30

model name  : Intel(R) Core(TM) CPU860  @ 2.80GHz

stepping: 5



note that there were _zero_ assembly differences with/without the patch

apart from using different register numbers and one single switched

bb order.

[Bug middle-end/56589] Array bounds violation is very end-user unfriendly

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #3 from Manuel López-Ibáñez  2013-03-11 
09:22:07 UTC ---
(In reply to comment #1)
> From the changes page:
> GCC now uses a more aggressive analysis to derive an upper bound for the 
> number
> of iterations of loops using constraints imposed by language standards. This
> may cause non-conforming programs to no longer work as expected, such as SPEC
> CPU 2006 464.h264ref and 416.gamess. A new option,
> -fno-aggressive-loop-optimizations, was added to disable this aggressive
> analysis.
> --- CUT --

Maybe the default should be -fno-aggressive-loop-optimizations, and only enable
it for -Ofast (or not even yet until there is a more or less reliable warning
in place). Does the benefit of such a potential optimization of real code
outweighs the frustration and breakage that will certainly ensue?

[Bug libstdc++/56557] [4.8 Regression] Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #5 from Jakub Jelinek  2013-03-11 
09:27:10 UTC ---

If I change:

--- cp/class.c(revision 196593)

+++ cp/class.c(working copy)

@@ -8364,7 +8364,7 @@ build_ctor_vtbl_group (tree binfo, tree

  targets that don't support hidden visibility, this tells

  can_refer_decl_in_current_unit_p not to assume that it's safe to

  access from a different compilation unit (bz 54314).  */

-  DECL_VISIBILITY (vtbl) = VISIBILITY_HIDDEN;

+  DECL_VISIBILITY (vtbl) = VISIBILITY_DEFAULT;

   DECL_VISIBILITY_SPECIFIED (vtbl) = true;



   v = NULL;

(remember, gimple-fold.c still uses the nonsensical DECL_VISIBILITY_SPECIFIED

test rather than actually looking what the visibility is) and link against

older

libstdc++ (one before r195550 fix), the testcase links, but contains lots of

bogus

SHN_UNDEF symbols (using ld.bfd 2.22.52.0.1), including the _ZTC* symbols that

will fail to link against latest 4.8.0 libstdc++ (or 4.7.x libstdc++), because

they aren't exported.

I'd say that the only needed SHN_UNDEF symbols in the dynamic table are the

symbols that are actually used in the relocations.

If I link without -flto, the relocs are:

00600dc0  00040006 R_X86_64_GLOB_DAT  

__gmon_start__ + 0

00600de0  00070007 R_X86_64_JUMP_SLOT 

__libc_start_main + 0

00600de8  000c0007 R_X86_64_JUMP_SLOT 

_ZNSt13basic_fstreamIcSt11char_traitsIcEED1Ev + 0

00600df0  000e0007 R_X86_64_JUMP_SLOT 

_ZNSt13basic_fstreamIcSt11char_traitsIcEEC1Ev + 0

00600df8  00120007 R_X86_64_JUMP_SLOT 00400820

__gxx_personality_v0 + 0

00600e00  00130007 R_X86_64_JUMP_SLOT 

_Unwind_Resume + 0

and SHN_UNDEF symbols in the binary beyond those are just:

 1: 00600e08 0 NOTYPE  WEAK   DEFAULT   24 data_start

 5:  0 NOTYPE  WEAK   DEFAULT  UND _Jv_RegisterClasses

 8:  0 NOTYPE  WEAK   DEFAULT  UND

_ITM_deregisterTMCloneTable

10:  0 NOTYPE  WEAK   DEFAULT  UND

_ITM_registerTMCloneTable

But with -flto there are 96 SHN_UNDEF symbols in the binary.  That looks like

liblto_plugin.so bug to me, the symbols are there just in the symbol tables,

but aren't actually used for anything.

[Bug libstdc++/56557] [4.8 Regression] Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options

[jakub at gcc dot gnu.org]

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



--- Comment #6 from Jakub Jelinek  2013-03-11 
09:36:24 UTC ---

BTW, even stock cc1plus (i.e. no the above class.c change) against latest 4.8.0

libstdc++ shows the myriads of useless SHN_UNDEF symbols with -flto alone (and

not -rdynamic), just the _ZTC* symbols aren't included in that case.

[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2

[steven at gcc dot gnu.org]

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



--- Comment #45 from Steven Bosscher  2013-03-11 
09:40:18 UTC ---

Patches posted:



* Restrict GIMPLE loop invariant code motion of loop-invariant loads and

stores to loops with fewer memory references than a certain maximum that

is controlled with --param loops-max-datarefs-for-datadeps" from the

command line.

http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00380.html



* Do not create new pseudo-registers for load-after-store transformations

in RTL dead store elimination.  This reduces the memory foot print after

DSE by ~2 percent, and avoids the compile time and memory usage explosion

in combine because it gets presented fewer single-def/single-use register

moves that are really just register copies.

http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00379.html



* Make gcse.c respect -fno-gcse-lm. For the RTL PRE problem, this means

compile time is reasonable with -fno-gcse-lm.

A follow-up patch will implement some mechanism to disable load motion

automatically on extreme test cases like the one from this PR.

http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00386.html





The remaining compile time bottlenecks are:



- RTL dead store limination in its analysis phase.  This is mostly time

spent in dependence tests in alias analysis for instructions in a single

basic block, so it's only a problem for test cases where there is a huge

number of loads and stores in each basic block. I don't think it is worth

speeding up DSE for such extreme cases. 



- Post-reload CSE because it is in the worst-case quadratic in the number 

of instructions in a basic block.  In most practical cases, post-reload 

CSE scales linearly with the number of instructions in a basic block, but

with a large constant bound. It looks up and down through the instruction

chain to see if a reg is not  clobbered between a use and a def.  Because

it only has to do so with  hard registers  the typical bound is closer to

"number of insns in basic block" * "number of hard registers".  This is

fine, I am not going to try and improve this.

[Bug middle-end/56589] Array bounds violation is very end-user unfriendly

[jakub at gcc dot gnu.org]

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



--- Comment #4 from Jakub Jelinek  2013-03-11 
09:45:07 UTC ---

Of course there is benefit, one performance benefit for properly written code,

and also people will very quickly fix up their broken code, as has been done

already for numerous packages that has been affected by this.

[Bug middle-end/56589] Array bounds violation is very end-user unfriendly

[jakub at gcc dot gnu.org]

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



--- Comment #5 from Jakub Jelinek  2013-03-11 
09:51:44 UTC ---

Also, note that gcc 4.8 isn't the first version to actually use undefined

behavior in computation of the number of iterations, just gcc 4.8 now uses the

number of loop iteration information in more places than 4.7 used it.

[Bug libstdc++/56557] [4.8 Regression] Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options

[jakub at gcc dot gnu.org]

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



--- Comment #7 from Jakub Jelinek  2013-03-11 
10:05:39 UTC ---

Note that this behavior (tons of undesirable SHN_UNDEF symbols in binaries

linked with -flto) seems to be specific to ld.bfd, with gold the #c0 testcase

links just fine, and the SHN_UNDEF symbols are the expected ones.  I've also

tried latest CVS binutils (both gold and ld.bfd) and the behavior is the same,

gold works here, ld.bfd broken.

So perhaps this is a binutils bug instead?

[Bug testsuite/54119] FAIL: gcc.dg/tree-ssa/vector-4.c scan-tree-dump-times gimple "VEC_PERM_EXPR ;" 1

[rguenth at gcc dot gnu.org]

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



--- Comment #6 from Richard Biener  2013-03-11 
10:12:36 UTC ---

(In reply to comment #5)

> Fixed.



-/* { dg-final { scan-tree-dump-times "VEC_PERM_EXPR ;" 1

"gimple"} } */

+/* { dg-final { scan-tree-dump-times "VEC_PERM_EXPR ;" 1

"gimple" { xfail { hppa*-*-* && { ! lp64 } } } } } */



I wonder if we should have a more descriptive target specifier, like

'target-callee-copies' instead ...

[Bug middle-end/56589] Array bounds violation is very end-user unfriendly

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||DUPLICATE



--- Comment #6 from Richard Biener  2013-03-11 
10:14:18 UTC ---

Let's mark it as a dup of the diagnostic issue.



*** This bug has been marked as a duplicate of bug 53265 ***

[Bug tree-optimization/53265] Warn when undefined behavior implies smaller iteration count

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 CC||ppluzhnikov at google dot

   ||com



--- Comment #4 from Richard Biener  2013-03-11 
10:14:18 UTC ---

*** Bug 56589 has been marked as a duplicate of this bug. ***

[Bug fortran/56581] seg fault

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|WAITING |RESOLVED

 Resolution||INVALID



--- Comment #6 from Richard Biener  2013-03-11 
10:17:47 UTC ---

Thus all fine.

[Bug tree-optimization/56580] Internal compiler error when trying to compile a sequence of NOPs inside a loop

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-03-11

 CC||andi-gcc at firstfloor dot

   ||org, hubicka at gcc dot

   ||gnu.org

  Component|c   |tree-optimization

 Ever Confirmed|0   |1



--- Comment #2 from Richard Biener  2013-03-11 
10:22:17 UTC ---

Andi has a patch for this IIRC.  But instead of



  /* Watch overflow that might result from insane profiles.  */

  if (time > MAX_TIME * INLINE_TIME_SCALE)

time = MAX_TIME * INLINE_TIME_SCALE;

  gcc_assert (time >= 0);



we should "deal" with the overflow, not ICE on it.  Like by doing



  if (time < 0

  || time > MAX_TIME * INLINE_TIME_SCALE)

time = MAX_TIME * INLINE_TIME_SCALE;

[Bug lto/56578] Testcase behaves differently when compiled with LTO

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2013-03-11

 Ever Confirmed|0   |1



--- Comment #1 from Richard Biener  2013-03-11 
10:30:13 UTC ---

Hmm, it works for me both with 4.7 and trunk.  And



rguenther@murzim:/tmp> gcc-nm-4.7 a.o

 T malloc

rguenther@murzim:/tmp> gcc-nm-4.8 a.o

 T malloc



I'm using GNU ld 2.23.1.  Even with gold 2.23.1 it works for me

(that is, 'make' prints three times OK).  glibc 2.14.1, x86_64-linux.



Can you elaborate on your configuration?

[Bug tree-optimization/56577] wrong code for aliased union on gcc 4.7 only

[rguenth at gcc dot gnu.org]

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



--- Comment #3 from Richard Biener  2013-03-11 
10:32:17 UTC ---

(In reply to comment #2)

> You cannot use union to avoid aliasing rules for normal accesses.



Though some people may read the C standard as allowing this (even just

creating a union type of int and long makes all accesses to int and long

alias).  ISTR some defect reports for this as well.



That said, GCC certainly interprets the C standard and implements it

like Jakub and Andrew said (and we won't change that).  Use

-fno-strict-aliasing

if you are not happy with that.

[Bug middle-end/56574] False possibly uninitialized variable warning

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Keywords||diagnostic, wrong-code

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-03-11

 Ever Confirmed|0   |1



--- Comment #5 from Richard Biener  2013-03-11 
10:43:45 UTC ---

ISO C99 6.5.13 says that 'value' is not evaluated when !flag is false.  But

clearly we are not considering the "side-effect" of using an uninitialized

variable when deciding to output straight-line code sequences.



Affected are at least gimple SSA if-combine and eventually fold and

gimplification (I didn't check them).



Ok, for this testcase it is fold that ends up producing a TRUTH_AND_EXPR.



For SSA if-combine we should only linearize the code if all inner block

SSA (or memory - ugh) uses in



  if (...)

   {

 

 if (...)

  {

...



have a dominating definition.

[Bug middle-end/56574] False possibly uninitialized variable warning

[rguenth at gcc dot gnu.org]

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



--- Comment #6 from Richard Biener  2013-03-11 
10:45:08 UTC ---

Note that the 'wrong-code' bits should not be observable but with runtime

simulation tools.

[Bug rtl-optimization/56339] [4.8 Regression]: Suboptimal register allocation

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Priority|P3  |P1

 CC||hjl at gcc dot gnu.org,

   ||uros at gcc dot gnu.org



--- Comment #10 from Richard Biener  2013-03-11 
10:46:16 UTC ---

Thus CCing the offending people.

[Bug fortran/56581] Segfault when reading source file which starts with a byte-order mark (-cpp works)

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 Status|RESOLVED|UNCONFIRMED

 Resolution|INVALID |

Summary|seg fault   |Segfault when reading

   ||source file which starts

   ||with a byte-order mark

   ||(-cpp works)

 Ever Confirmed|1   |0



--- Comment #7 from Tobias Burnus  2013-03-11 
10:51:32 UTC ---

For completeness, the first line of the attachment starts with (od -x):



000 bbef 43bf 2020 2020 2020 2020 2020 2020



EF BB BF  is the byte-order mark. (Followed by "C" and " ".)





It works if one uses "-cpp" as, seemingly, libcpp supports this. I think we

should consider supporting those BOM.

[Bug target/56470] [4.7/4.8 Regression] ICE output_operand: invalid shift operand

[rearnsha at gcc dot gnu.org]

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



--- Comment #7 from Richard Earnshaw  2013-03-11 
11:48:45 UTC ---

Author: rearnsha

Date: Mon Mar 11 11:48:34 2013

New Revision: 196595



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196595

Log:

PR target/56470

* arm.c (shift_op): Validate RTL pattern on the fly.

(arm_print_operand, case 'S'): Don't use shift_operator to validate

the RTL.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/config/arm/arm.c

[Bug rtl-optimization/56339] [4.8 Regression]: Suboptimal register allocation

[ubizjak at gmail dot com]

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



Uros Bizjak  changed:



   What|Removed |Added



 CC|uros at gcc dot gnu.org |



--- Comment #11 from Uros Bizjak  2013-03-11 11:49:03 
UTC ---

(In reply to comment #10)

> Thus CCing the offending people.



One of the offending people is the reporter.

[Bug target/56546] Using the divide operator on unsigned int produces incorrect code on AVR

[gjl at gcc dot gnu.org]

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



Georg-Johann Lay  changed:



   What|Removed |Added



 Status|WAITING |RESOLVED

 Resolution||INVALID



--- Comment #3 from Georg-Johann Lay  2013-03-11 
11:50:02 UTC ---

(In reply to comment #2)

> (In reply to comment #1)

>> Is this an unpatched avr-gcc?

> 

> In fact I discovered the issue on a toolchain built with Gentoo's crossdev

> tool. They are using a good number of patches but these are not the source of

> the problem. After digging a little deeper I discovered that the problem comes

> from the build options they use. After a good number of builds on an unpatched

> gcc-4.7.2 I've been able to determine that the --disable-multilib option they

> use is the source of the issue.



--disable-multilib completely messes up the tools, thus closing this PR as

INVALID.



> Building with

> 

> ../configure [...]



Notice that configuring in the source tree is strongly discouraged / not

supported. Read the configuring GCC documentation again.



If you are using AVR-LibC, you may also want to configure with

--with-avrlibc=yes and use AVR-LibC that implements

http://savannah.nongnu.org/bugs/?35407

[Bug bootstrap/56593] New: LTO profiledbootstrap fails for Ada

[rguenth at gcc dot gnu.org]

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



 Bug #: 56593

   Summary: LTO profiledbootstrap fails for Ada

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Keywords: lto

  Severity: normal

  Priority: P3

 Component: bootstrap

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: rgue...@gcc.gnu.org

Target: x86_64-*-*





A --enable-languages=ada --with-build-config=bootstrap-lto --disable-werror

config fails to profiledbootstrap on x86_64-linux with



lto1: internal compiler error: in output_die, at dwarf2out.c:8476

0x7090f3 output_die

/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:8476

0x7081d3 output_die

/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:8555

0x7081d3 output_die

/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:8555

0x7081d3 output_die

/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:8555

0x70defb output_comp_unit

/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:8633

0x7389f3 dwarf2out_finish

/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:23618

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.

make[4]: *** [/tmp/ccp7d0pC.ltrans27.ltrans.o] Error 1



/tmp/cc4REUuf.s: Assembler messages:

/tmp/cc4REUuf.s:323380: Error: symbol `.Ldebug_info0' is already defined

make[4]: *** [/tmp/ccp7d0pC.ltrans29.ltrans.o] Error 1

lto-wrapper: make returned 2 exit status

/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld:

lto-wrapper failed

collect2: error: ld returned 1 exit status

make[3]: *** [gnat1] Error 1

[Bug rtl-optimization/56339] [4.8 Regression]: Suboptimal register allocation

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



   Priority|P1  |P2



--- Comment #12 from Jakub Jelinek  2013-03-11 
11:57:57 UTC ---

I don't think this is P1.

When looking at the dumps, right after expansion the 4.7 expanded code actually

looks much worse compared to the 4.8 expanded one (4.7 goes through memory,

while 4.8 through subregs), in *.ud-dce it is pretty much comparable, though

4.7 has one extra move:

2 r62:DF=xmm0:DF

  REG_DEAD: xmm0:DF

6 r64:DF=xmm2:DF

  REG_DEAD: xmm2:DF

   21 r66:DF=r62:DF

  REG_DEAD: r62:DF

7 NOTE_INSN_FUNCTION_BEG

   10 r65:DF=r64:DF+r66:DF

  REG_DEAD: r66:DF

  REG_DEAD: r64:DF

   15 xmm0:DF=r65:DF

  REG_DEAD: r65:DF

   18 use xmm0:DF

in 4.7 vs.

2: r64:DF=xmm0:DF

  REG_DEAD xmm0:DF

8: r66:DF=xmm2:DF

  REG_DEAD xmm2:DF

9: NOTE_INSN_FUNCTION_BEG

   12: r67:DF=r66:DF+r64:DF

  REG_DEAD r66:DF

  REG_DEAD r64:DF

   17: xmm0:DF=r67:DF

  REG_DEAD r67:DF

   20: use xmm0:DF

in 4.8.  The combiner change is what matters for the later behavior of regmove,

RA and reload/LRA, but unfortunately that is an ICE fix that can't be reverted,

we really must avoid to propagating hard registers too early, otherwise RA

needs to just give up.

So, in 4.7 we end up with r65:DF=xmm2:DF+r62:DF after combine, while 4.8 still

uses pseudos.  Which is the reason why regmove sets that into the optimal for

this testcase r65:DF=xmm2:DF+r65:DF, because it has no other choice (the

operand was already a hard reg), while in 4.8 it has a choice (sees two

different pseudos, and chooses in this case the wrong one).  I'm afraid there

is no easy fix, so IMHO this needs to be postponed for 4.9.

[Bug bootstrap/56593] LTO profiledbootstrap fails for Ada

[rguenth at gcc dot gnu.org]

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



--- Comment #1 from Richard Biener  2013-03-11 
13:15:35 UTC ---

Non-profiled LTO bootstrap works with Ada.

[Bug fortran/56594] New: Invalid read of size 1 for gfortran.dg/realloc_on_assign_5.f03

[dominiq at lps dot ens.fr]

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



 Bug #: 56594

   Summary: Invalid read of size 1 for

gfortran.dg/realloc_on_assign_5.f03

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: domi...@lps.ens.fr





Running gfortran.dg/realloc_on_assign_5.f03 under valgrind gives



==32678== Invalid read of size 1

==32678==at 0x7FE007D4: ???

==32678==by 0x10DA6: MAIN__ (realloc_on_assign_5.f03:15)

==32678==by 0x10E60: main (realloc_on_assign_5.f03:18)

==32678==  Address 0x100449541 is 0 bytes after a block of size 1 alloc'd

==32678==at 0x100012891: realloc (vg_replace_malloc.c:635)

==32678==by 0x10D71: MAIN__ (realloc_on_assign_5.f03:15)

==32678==by 0x10E60: main (realloc_on_assign_5.f03:18)

==32678== 



Program aborted. Backtrace:

#0  0x10001fe42

#1  0x1000201b2

#2  0x1000f1618

#3  0x10dfc

#4  0x10e60

==32678== 

==32678== Process terminating with default action of signal 6 (SIGABRT)

==32678==at 0x1001DA0B6: __kill (in /usr/lib/libSystem.B.dylib)

==32678==by 0x100020198: _gfortrani_sys_abort (in

/opt/gcc/gcc4.8w/lib/libgfortran.3.dylib)

==32678==by 0x10E60: main (realloc_on_assign_5.f03:18)

==32678== 

==32678== HEAP SUMMARY:

==32678== in use at exit: 3,822 bytes in 18 blocks

==32678==   total heap usage: 21 allocs, 3 frees, 3,953 bytes allocated

==32678== 

==32678== LEAK SUMMARY:

==32678==definitely lost: 0 bytes in 0 blocks

==32678==indirectly lost: 0 bytes in 0 blocks

==32678==  possibly lost: 0 bytes in 0 blocks

==32678==still reachable: 3,734 bytes in 17 blocks

==32678== suppressed: 88 bytes in 1 blocks

==32678== Rerun with --leak-check=full to see details of leaked memory

==32678== 

==32678== For counts of detected and suppressed errors, rerun with: -v

==32678== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Abort



The test also aborts at run time when compiled with -fsanitize=address.



Reduced test



program main

  implicit none

  character(:), allocatable :: a, b

  a = 'ax'

  a = a(2:2)

end program main



There is no error if "a = a(2:2)" is replaced with "a = 'x'".

[Bug tree-optimization/56595] New: Tree-ssa-pre can create loop carried dependencies which prevent loop vectorization.

[ysrumyan at gmail dot com]

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



 Bug #: 56595

   Summary: Tree-ssa-pre can create loop carried dependencies

which prevent loop vectorization.

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: tree-optimization

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: ysrum...@gmail.com





In some cases pre can create loop carried dependencies spanning multiple

iterations aka scalar replacement. This deficiency can be illustrated with

attached test-case. After pre for stmt



DO I = 0,I2

   T1 = 0.5D0 * (U1(I,J,K)+ U1(I+1,J,K))



pre creates loop carried dependence:



  :

...

  pretmp_690 = MEM[(real(kind=8)[0:] *)pretmp_675][pretmp_689];

...

  :

  # i_1 = PHI <0(172), i_437(175)>

  # prephitmp_691 = PHI 





Note that in this particular test-case we have arrays with unknown stride1. If

we have arrays with stride1 == 1 such transformation does not happen as for the

following simple test-case which is successfully vectorized:



subroutine bar(a,b,c,d,n, m)

integer n, m

real*8 a(n,*), b(n,*), c(n,*), d(n,*)

do j=1,m

do i=1,m

x1 = 0.5 * (a(i,j) + a(i+1,j))

x2 = 0.5 * (b(i,j) + b(i+1,j))

x3 = 0.5 * (c(i,j) + c(i+1,j))

d(i,j) = (x1 + x2 + x3) / 3.0

enddo

enddo

end

[Bug tree-optimization/56595] Tree-ssa-pre can create loop carried dependencies which prevent loop vectorization.

[ysrumyan at gmail dot com]

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



--- Comment #1 from Yuri Rumyantsev  2013-03-11 
13:38:25 UTC ---

Created attachment 29636

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29636

testcase



This test must be compiled with the following options for x86:



-ffree-line-length-none -m64 -Ofast -march=core-avx-i -mavx

[Bug fortran/56596] New: Invalid read of size 4 gfortran.dg/class_array_7.f03

[dominiq at lps dot ens.fr]

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



 Bug #: 56596

   Summary: Invalid read of size 4 gfortran.dg/class_array_7.f03

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: domi...@lps.ens.fr





Running gfortran.dg/class_array_7.f03 under valgrind gives



==54979== Invalid read of size 4

==54979==at 0x11731: __realloc_MOD_assign (class_array_7.f03:25)

==54979==by 0x11629: __realloc_MOD_reallocate (class_array_7.f03:33)

==54979==by 0x119D8: MAIN__ (class_array_7.f03:55)

==54979==by 0x11B7D: main (class_array_7.f03:49)

==54979==  Address 0x10044a408 is 0 bytes after a block of size 40 alloc'd

==54979==at 0x100013679: malloc (vg_replace_malloc.c:266)

==54979==by 0x117E0: MAIN__ (class_array_7.f03:53)

==54979==by 0x11B7D: main (class_array_7.f03:49)

==54979== 

==54979== 

==54979== HEAP SUMMARY:

==54979== in use at exit: 88 bytes in 1 blocks

==54979==   total heap usage: 25 allocs, 24 frees, 7,061 bytes allocated

==54979== 

==54979== LEAK SUMMARY:

==54979==definitely lost: 0 bytes in 0 blocks

==54979==indirectly lost: 0 bytes in 0 blocks

==54979==  possibly lost: 0 bytes in 0 blocks

==54979==still reachable: 0 bytes in 0 blocks

==54979== suppressed: 88 bytes in 1 blocks

==54979== 

==54979== For counts of detected and suppressed errors, rerun with: -v

==54979== ERROR SUMMARY: 5 errors from 1 contexts (suppressed: 0 from 0)



The test also aborts if it is compiled with -fsanitize=address.



Reduced test



module realloc

  implicit none



  type :: base_type

 integer :: i

  contains

procedure :: assign

generic :: assignment(=) => assign   ! define generic assignment

  end type base_type



  type, extends(base_type) :: extended_type

 integer :: j

  end type extended_type



contains



  elemental subroutine assign (a, b)

class(base_type), intent(out) :: a

class(base_type), intent(in) :: b

a%i = b%i

  end subroutine assign



  subroutine reallocate (a)

class(extended_type), dimension(:), allocatable :: tmp

class(base_type), dimension(:), allocatable, intent(inout) :: a

allocate (extended_type :: tmp (size (a))) ! how to alloc b with same type

as a ?

tmp = a ! polymorphic l.h.s.

call move_alloc (from=tmp, to=a)

  end subroutine reallocate



end module realloc



program main

  use realloc

  implicit none

  class(base_type), dimension(:), allocatable :: a



  allocate (extended_type :: a(10))

  call reallocate (a)

end program main

[Bug libstdc++/56557] [4.8 Regression] Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options

[hubicka at ucw dot cz]

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



--- Comment #8 from Jan Hubicka  2013-03-11 13:58:07 UTC 
---

Yes, I agree it is GNU LD bug.

There is also GCC problem: this particular symbol should not appear in the LTO

symtab. It appears because we see the refernece, but the reference itself comes

from external var initializer and ought to be ignored.  I will fix this

problem.



Honza

[Bug tree-optimization/53265] Warn when undefined behavior implies smaller iteration count

[rguenth at gcc dot gnu.org]

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



--- Comment #5 from Richard Biener  2013-03-11 
14:14:06 UTC ---

The following avoids the "miscompile" in these obvious cases:



Index: gcc/tree-ssa-loop-niter.c

===

--- gcc/tree-ssa-loop-niter.c   (revision 196594)

+++ gcc/tree-ssa-loop-niter.c   (working copy)

@@ -3345,6 +3345,18 @@ estimate_numbers_of_iterations_loop (str

   bound = gcov_type_to_double_int (nit);

   record_niter_bound (loop, bound, true, false);

 }

+

+  /* If we know the exact number of iterations of this loop avoid all the

+ work below and most importantly do not break code with undefined

+ behavior by recording smaller maximum number of iterations.  */

+  niter = number_of_latch_executions (loop);

+  if (TREE_CODE (niter) == INTEGER_CST)

+{

+  if (loop->any_upper_bound

+ && loop->nb_iterations_upper_bound.ucmp

+  (tree_to_double_int (niter)) < 0)

+   loop->nb_iterations_upper_bound = tree_to_double_int (niter);

+}

 }



 /* Sets NIT to the estimated number of executions of the latch of the

[Bug tree-optimization/53265] Warn when undefined behavior implies smaller iteration count

[rguenth at gcc dot gnu.org]

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



--- Comment #6 from Richard Biener  2013-03-11 
14:16:20 UTC ---

To warn,

1) add a flag to struct loop whether we warned for the loop already

2) in both discover_iteration_bound_by_body_walk and

maybe_lower_iteration_bound

   warn if you run into an estimate we end up using and that lowers the

   max iterations below the value returned by number_of_latch_executions ().

[Bug tree-optimization/53265] Warn when undefined behavior implies smaller iteration count

[rguenth at gcc dot gnu.org]

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



--- Comment #7 from Richard Biener  2013-03-11 
14:17:28 UTC ---

When warnings are disabled the whole function can be skipped and

both estimate and bound be initialized by the result from

number_of_latch_executions (if that returns a constant).

[Bug tree-optimization/56595] Tree-ssa-pre can create loop carried dependencies which prevent loop vectorization.

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-03-11

 Blocks||53947

 Ever Confirmed|0   |1



--- Comment #2 from Richard Biener  2013-03-11 
14:25:02 UTC ---

Confirmed (and known).  See inhibit_phi_insertion in PRE.



I bet you find some duplicate in the list of missed-vectorization bugs.



Loop store-motion can result in similar issues.



Note that an issue with limiting things even further is that PRE is limited

even when the resulting loop is _not_ vectorized.  Which is of course bad.



So the best solution is to teach the vectorizer to handle this kind of

dependency (after all user code can be written in that way from the start).

[Bug target/56470] [4.7 Regression] ICE output_operand: invalid shift operand

[rearnsha at gcc dot gnu.org]

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



Richard Earnshaw  changed:



   What|Removed |Added



Summary|[4.7/4.8 Regression] ICE|[4.7 Regression] ICE

   |output_operand: invalid |output_operand: invalid

   |shift operand   |shift operand



--- Comment #8 from Richard Earnshaw  2013-03-11 
14:38:14 UTC ---

Fixed on trunk.  Testing back-port to 4.7.

[Bug rtl-optimization/55611] Operand swapping for commutative operators

[glisse at gcc dot gnu.org]

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



--- Comment #2 from Marc Glisse  2013-03-11 14:44:09 
UTC ---

The fortran test that fails is equivalent to the following (use -Ofast -g,

surprisingly it only fails in var tracking)



float f(double*a,double*b){

  double x=a[0]*b[0];

  x+=a[1]*b[1];

  x+=a[2]*b[2];

  x+=a[3]*b[3];

  return x;

}



This happens because of an infinite loop between simplify_associative_operation

and simplify_gen_binary (and a few others) which keeps shuffling the additions

around to try and canonicalize the expression. Some well placed tests whether

GET_CODE(*)==code could probably help, although I am a bit surprised that it

fails so seldom, and only in var-tracking.



I didn't investigate the problem with the reverse order, as stage3 failures (in

middle-end code) are hard to debug...

[Bug target/54407] FAIL: 30_threads/condition_variable/54185.cc execution test program timed out on powerpc-apple-darwin9 and x86_64-apple-darwin10

[howarth at nitro dot med.uc.edu]

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



--- Comment #18 from Jack Howarth  2013-03-11 
14:51:01 UTC ---

(In reply to comment #17)

> Jack,

> 

> I see at http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00331.html that you

> have tested a fix for this PR. I have tested that it skips the test on

> powerpc-apple-darwin9 and x86_64-apple-darwin10. Have you submitted it?



I posted this patch back in Oct as...



http://gcc.gnu.org/ml/libstdc++/2012-10/msg00111.html



Mike wanted a comment about an associated radar which doesn't exist. As far as

I know this bug was fixed in the pthread rewrites for darwin11 and later.

[Bug rtl-optimization/55611] Operand swapping for commutative operators

[glisse at gcc dot gnu.org]

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



--- Comment #3 from Marc Glisse  2013-03-11 15:14:46 
UTC ---

(In reply to comment #1)

> I also tried the reverse order (just swap x and y in the GET_CODE comparison).

> It got a crazy process during stage3 compiling tree-ssa-address.c (I killed it

> at 40GB).



Seems to be the same problem, at least the call stack looks the same, with IOR

instead of PLUS.

[Bug tree-optimization/53265] Warn when undefined behavior implies smaller iteration count

[jakub at gcc dot gnu.org]

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



--- Comment #8 from Jakub Jelinek  2013-03-11 
15:49:00 UTC ---

Created attachment 29637

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29637

gcc48-pr53265.patch



Untested patch.  Not sure about the warning wording, plus no idea how to call

the warning option (-Wnum-loop-iterations, -Wundefined-behavior-in-loop,

something else?), whether to enable it by default, or just for -Wall.

A bigger issue is that I see multiple warnings for the same stmts, despite the

guard in loop structure, because apparently the same loop is represented by

different loop structures during the optimizations.

[Bug tree-optimization/53265] Warn when undefined behavior implies smaller iteration count

[rguenth at gcc dot gnu.org]

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



--- Comment #9 from Richard Biener  2013-03-11 
15:58:41 UTC ---

(In reply to comment #8)

> Created attachment 29637 [details]

> gcc48-pr53265.patch

> 

> Untested patch.  Not sure about the warning wording, plus no idea how to call

> the warning option (-Wnum-loop-iterations, -Wundefined-behavior-in-loop,

> something else?), whether to enable it by default, or just for -Wall.

> A bigger issue is that I see multiple warnings for the same stmts, despite the

> guard in loop structure, because apparently the same loop is represented by

> different loop structures during the optimizations.



Yeah, before the tree loop optimization pipeline loops are not preserved ...

(easy to change, apart from code missing to inline a loop tree).



Eventually use gimple_no_warning on the stmt?  Supposedly not very reliable

either.



I think with your patch you also fail to warn for bounds discovered by

discover_iteration_bound_by_body_walk or maybe_lower_iteration_bound.

That said, I'd expected you warn from within record_niter_bound.  Btw,

after number_of_latch_executions () its return value is cached in

loop->nb_iterations, no need to pass around another value.

[Bug tree-optimization/53265] Warn when undefined behavior implies smaller iteration count

[amonakov at gcc dot gnu.org]

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



--- Comment #10 from Alexander Monakov  2013-03-11 
16:15:36 UTC ---

(In reply to comment #8)

> Not sure about the warning wording



What about (... "iteration %E invokes undefined behavior", max)?



> plus no idea how to call the warning option (-Wnum-loop-iterations, 

> -Wundefined-behavior-in-loop, something else?)



Can it be -Waggressive-loop-optimizations to follow existing pairs of

-{W,fno-}strict-{aliasing,overflow} for the recently added

-fno-aggressive-loop-optimizations?

[Bug c++/56567] [4.8 Regression] ICE with lambda return type deduction and braced-init-list

[jason at gcc dot gnu.org]

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



--- Comment #6 from Jason Merrill  2013-03-11 
16:22:28 UTC ---

Author: jason

Date: Mon Mar 11 16:22:16 2013

New Revision: 196600



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196600

Log:

PR c++/56567

* typeck.c (check_return_expr): Disallow returning init list here.

* semantics.c (apply_deduced_return_type): Not here.



Modified:

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/semantics.c

trunk/gcc/cp/typeck.c

trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-initlist3.C

[Bug c++/56346] FAIL: g++.dg/tls/thread_local3.C -std=gnu++11 (test for excess errors)

[jason at gcc dot gnu.org]

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



--- Comment #4 from Jason Merrill  2013-03-11 
16:33:18 UTC ---

Created attachment 29638

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29638

tentative patch



__cxa_thread_atexit is in libstdc++; the default implementation doesn't do

anything with the dso_handle parm, so I think it makes sense to just pass NULL

on targets without __cxa_atexit.  Does this patch fix the failure for you?

[Bug tree-optimization/53265] Warn when undefined behavior implies smaller iteration count

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #11 from Manuel López-Ibáñez  2013-03-11 
16:42:00 UTC ---
(In reply to comment #8)
> Untested patch.  Not sure about the warning wording, plus no idea how to call
> the warning option (-Wnum-loop-iterations, -Wundefined-behavior-in-loop,
> something else?), whether to enable it by default, or just for -Wall.

If the rate of false positives is expected to be low, then I would suggest
enabled by default, otherwise, I would say Wall.

[Bug tree-optimization/53265] Warn when undefined behavior implies smaller iteration count

[manu at gcc dot gnu.org]

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

--- Comment #12 from Manuel López-Ibáñez  2013-03-11 
16:49:25 UTC ---
(In reply to comment #10)
> (In reply to comment #8)
> > Not sure about the warning wording
> 
> What about (... "iteration %E invokes undefined behavior", max)?
> 
> > plus no idea how to call the warning option (-Wnum-loop-iterations, 
> > -Wundefined-behavior-in-loop, something else?)
> 
> Can it be -Waggressive-loop-optimizations to follow existing pairs of
> -{W,fno-}strict-{aliasing,overflow} for the recently added
> -fno-aggressive-loop-optimizations?

I think these two are very good suggestions. Thanks, Alexander.

And if this gets implemented for 4.8, I think it will make the new loop
optimizations much safer to use and, hence, much more useful.

[Bug c++/56597] New: unaligned local variable used by implicit sse instructions

[kruglinski at gmail dot com]

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



 Bug #: 56597

   Summary: unaligned local variable used by implicit sse

instructions

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: kruglin...@gmail.com





I belive that i found an issue in gcc 4.7.2



this afternoon I was compile the google angleproject - a gles2 implementation

on d3d9.



this project require SSE2 support to compiled, so I enable it with

"-march=nocona -O3" to get this work done, finally I got the Dlls.



but when I try to run a test program compiled by VC++ that use the Dlls

compiled by gcc, it always crashed by "Access Violation".



after some analyses, I located the crashed point is a function at

"src\libGLESv2\ProgramBinary.cpp" line 2681 named "bool

ProgramBinary::validateSamplers(InfoLog *infoLog)"



there are some statement in it:



bool ProgramBinary::validateSamplers(InfoLog *infoLog)

{

// if any two active samplers in a program are of different types, but

refer to the same

// texture image unit, and this is the current program, then

ValidateProgram will fail, and

// DrawArrays and DrawElements will issue the INVALID_OPERATION error.



const unsigned int maxCombinedTextureImageUnits =

getContext()->getMaximumCombinedTextureImageUnits();



TextureType textureUnitType[MAX_COMBINED_TEXTURE_IMAGE_UNITS_VTF];



//TextureType is an enum

//MAX_COMBINED_TEXTURE_IMAGE_UNITS_VTF==20

//comment by jjwang



for (unsigned int i = 0; i < MAX_COMBINED_TEXTURE_IMAGE_UNITS_VTF; ++i)

{

textureUnitType[i] = TEXTURE_UNKNOWN;

}

...

}



gcc generate six sse2 "movdqa" instructions to unrolling the loop, great works!

but the textureUnitType is not aligned by 32 bytes, so It crashed!



movdqa  xmm0,xmmword ptr ds:[67B4A7D0h]

movdqa  xmmword ptr [esp+10h],xmm0;<=crashed here

movdqa  xmmword ptr [esp+20h],xmm0

movdqa  xmmword ptr [esp+30h],xmm0

movdqa  xmmword ptr [esp+40h],xmm0

movdqa  xmmword ptr [esp+50h],xmm0



then I made some changes and it works perfectly!



__attribute__((aligned(32))) TextureType

textureUnitType[MAX_COMBINED_TEXTURE_IMAGE_UNITS_VTF];



the implicit issue like this are very hard to understand for someone never know

sse2 and just want to use the Dlls project. I belive that align the "local

variable" that used by 



implicit sse instructions is compiler's work not human's, so think about it

please!



sorry my poor english, thanks!



03-11-2003 jjwang

[Bug tree-optimization/53265] Warn when undefined behavior implies smaller iteration count

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



  Attachment #29637|0   |1

is obsolete||



--- Comment #13 from Jakub Jelinek  2013-03-11 
17:10:30 UTC ---

Created attachment 29639

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29639

gcc48-pr53265.patch



Updated version of the patch.  Haven't added docs yet.  The reason for not

warning in discover_iteration_bound_by_body_walk etc. is that I'd say the

undefined behavior warning would then be misleading, those don't detect

undefined behavior, but something else, right?  Can you think of a testcase

where we'd decrease number of iterations in those routines when it has

constant number_of_latch_iterations?

Also, with the estimate_numbers_of_loop_iterations_loop second hunk I'm not

really sure about the warning name - after all, when we warn, we actually don't

aggressively optimize anything, we aggressively optimize only when we actually

don't warn and can't easily warn.

[Bug c++/56597] unaligned local variable used by implicit sse instructions

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #1 from Jakub Jelinek  2013-03-11 
17:36:40 UTC ---

If the failure is on reading from the stack pointer, then it must be that some

caller misaligns the stack.  You have mentioned what target you're using, so it

is hard to guess what is faulty.  E.g. on i?86-linux stack must be 16-byte

aligned, if it isn't, you're violating the ABI (but gcc has some options where

you can ask it to realign the stack dynamically, or assume smaller alignment

etc.).

[Bug fortran/55362] [4.6/4.7 Regression] ICE with size() on character pointer

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #13 from Dominique d'Humieres  
2013-03-11 17:42:56 UTC ---

I have regstrapped 4.6.4 at revision 196596 configured with



--prefix=/opt/gcc/gcc4.6p --enable-languages=c,c++,lto,fortran

--with-gmp=/opt/mp --with-system-zlib --enable-lto



without unexpected failure for gfortran. Closing as fixed. Paul, thanks for the

fix.

[Bug rtl-optimization/56598] New: Optimizer can't invert conditional when inlining a bool function

[msharov at users dot sourceforge.net]

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



 Bug #: 56598

   Summary: Optimizer can't invert conditional when inlining a

bool function

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: minor

  Priority: P3

 Component: rtl-optimization

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: msha...@users.sourceforge.net





Created attachment 29640

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29640

Simple test case and its asm



When a bool macro like #define X(i) (i==3) is replaced with a static inline

bool function, the optimizer sometimes generates tangled control flow. With

code blocks ABCD the jumps go A->C->B->D. If the macro is used, the compiler

can invert the conditional and emit ACBD with two fewer jmps. In the attached

test case, func1 has .L3-.L4 block that is jumped into, out of, and over.

Swapping the .L2-.L3 and .L3-.L4 blocks would produce the simpler control flow

in func2. The test case is compiled with -Os, on x86_64. -O2 and -O3 also

produce the same behavior, but require a larger test case to avoid path

unrolling. C++ compiler must be used. The same test case compiled as C produces

identical func1 and func2.

[Bug c/56599] New: very confusing compiler diagnostics (for stupid bug on my part)

[davecat49 at gmail dot com]

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



 Bug #: 56599

   Summary: very confusing compiler diagnostics (for stupid bug on

my part)

Classification: Unclassified

   Product: gcc

   Version: 4.5.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: daveca...@gmail.com

[Bug libstdc++/56557] [4.8 Regression] Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options

[hubicka at gcc dot gnu.org]

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



--- Comment #9 from Jan Hubicka  2013-03-11 
18:10:57 UTC ---

I am testing the following that should prevent references from external vtables

to land in LTO symbol table.



Index: lto-streamer-out.c

===

--- lto-streamer-out.c  (revision 196596)

+++ lto-streamer-out.c  (working copy)

@@ -1265,17 +1265,36 @@ bool

 output_symbol_p (symtab_node node)

 {

   struct cgraph_node *cnode;

-  struct ipa_ref *ref;

-

   if (!symtab_real_symbol_p (node))

 return false;

   /* We keep external functions in symtab for sake of inlining

  and devirtualization.  We do not want to see them in symbol table as

- references.  */

+ references unless they are really used.  */

   cnode = dyn_cast  (node);

-  if (cnode && DECL_EXTERNAL (cnode->symbol.decl))

-return (cnode->callers

-   || ipa_ref_list_referring_iterate (&cnode->symbol.ref_list, 0,

ref));

+  if (cnode && DECL_EXTERNAL (cnode->symbol.decl)

+  && cnode->callers)

+return true;

+

+ /* Ignore all referrences from external vars initializers - they are not

really

+part of the compilation unit until they are used by folding.  Some

symbols,

+like referneces to external construction vtables can not be referred to at

all.

+We decide this at can_refer_decl_in_current_unit_p */

+ if (DECL_EXTERNAL (node->symbol.decl))

+{

+  int i;

+  struct ipa_ref *ref;

+  for (i = 0; ipa_ref_list_referring_iterate (&node->symbol.ref_list,

+ i, ref); i++)

+   {

+ if (ref->use == IPA_REF_ALIAS)

+   continue;

+  if (is_a  (ref->referring))

+   return true;

+ if (!DECL_EXTERNAL (ref->referring->symbol.decl))

+   return true;

+   }

+  return false;

+}

   return true;

 }

[Bug c/56599] very confusing compiler diagnostics (for stupid bug on my part)

[pinskia at gcc dot gnu.org]

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



--- Comment #1 from Andrew Pinski  2013-03-11 
18:11:17 UTC ---

No info in bug.

[Bug libstdc++/56557] [4.8 Regression] Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options

[jakub at gcc dot gnu.org]

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



--- Comment #10 from Jakub Jelinek  2013-03-11 
18:21:19 UTC ---

(In reply to comment #9)

Sorry for nitpicking ;) :



> + /* Ignore all referrences from external vars initializers - they are not

> really



references



> +part of the compilation unit until they are used by folding.  Some

> symbols,

> +like referneces to external construction vtables can not be referred to 
> at



references



> all.

> +We decide this at can_refer_decl_in_current_unit_p */



Dot + space missing.

[Bug target/54083] FAIL: gcc.dg/torture/pr53922.c on *-apple-darwin*

[dominiq at lps dot ens.fr]

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



--- Comment #16 from Dominique d'Humieres  
2013-03-11 18:22:34 UTC ---

(In reply to comment #15)

> > Would this be needed for darwin8 as well?

>

> I don't recall the status of D8,  

> .. I suspect that, in this case, it is as per D9 (if you have a build around,

> you could confirm this).



I don't have the test suite setup for d8, but the test executes when compiled

with



gcc-fsf-4.7 -Wl,-undefined,dynamic_lookup -Wl,-flat_namespace pr53922.c



[pbook] dominiq/tempo% gcc-fsf-4.7 -v

Using built-in specs.

COLLECT_GCC=gcc-fsf-4.7

COLLECT_LTO_WRAPPER=/sw/lib/gcc4.7/libexec/gcc/powerpc-apple-darwin8.11.0/4.7.2/lto-wrapper

Target: powerpc-apple-darwin8.11.0

Configured with: ../gcc-4.7.2/configure --prefix=/sw AS=odas AS_FOR_TARGET=odas

NM_FOR_TARGET=odnm LD_FOR_TARGET=odld AR_FOR_TARGET=odar LIPO_FOR_TARGET=odlipo

OBJDUMP_FOR_TARGET=odobjdump RANLIB_FOR_TARGET=odranlib

STRIP_FOR_TARGET=odstrip --prefix=/sw/lib/gcc4.7 --mandir=/sw/share/man

--infodir=/sw/lib/gcc4.7/info

--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw

--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw

--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib

--program-suffix=-fsf-4.7 --enable-cloog-backend=isl --with-dwarf2

--disable-libjava-multilib --disable-libquadmath

Thread model: posix

gcc version 4.7.2 (GCC) 



but does not if -Wl,-flat_namespace is omitted. So I guess the answer is yes.

[Bug translation/56591] Missing space

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-03-11

 CC||avr at gjlay dot de

 Ever Confirmed|0   |1

[Bug c/56599] very confusing compiler diagnostics (for stupid bug on my part)

[davecat49 at gmail dot com]

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



--- Comment #2 from Dave  2013-03-11 18:32:51 UTC 
---

Created attachment 29641

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29641

preprocesser output for first program

[Bug c/56599] very confusing compiler diagnostics (for stupid bug on my part)

[davecat49 at gmail dot com]

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



--- Comment #3 from Dave  2013-03-11 18:34:05 UTC 
---

Created attachment 29642

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29642

preprocesser output for second program

[Bug c/56599] very confusing compiler diagnostics (for stupid bug on my part)

[davecat49 at gmail dot com]

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



--- Comment #4 from Dave  2013-03-11 18:42:41 UTC 
---

It looks as though it threw away everything I'd typed in when I added an

attachment, & then submitted the empty report. 



gcc produced extremely confusing error messages, referencing perfectly valid

line:columns, or (under debugging) referencing location in previously #included

header file.  The bug would have been easily recognized if anything had

indicated the correct location, but the messages weren't especially

descriptive.



Instead of pasting them in, I'll try attaching the programs as well, this time.

 See the .c versions & the error messages in the .txt files.  I guess I'm

supposed to post this, then attach?  I'll try it that way.

[Bug c/56599] very confusing compiler diagnostics (for stupid bug on my part)

[davecat49 at gmail dot com]

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



--- Comment #5 from Dave  2013-03-11 18:44:44 UTC 
---

Created attachment 29643

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29643

first offending program



The compiler error output is as follows:

dlt8.c:7:22: error: expected ',' or ';' before numeric constant

[Bug target/56591] Missing space

[gjl at gcc dot gnu.org]

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



Georg-Johann Lay  changed:



   What|Removed |Added



 Target||avr

   Priority|P3  |P4

 Status|NEW |WAITING

 CC||gjl at gcc dot gnu.org

  Component|translation |target



--- Comment #1 from Georg-Johann Lay  2013-03-11 
18:45:08 UTC ---

Please supply informations and test case following the bug reporting

instructions

http://gcc.gnu.org/bugs/#report

[Bug c/56599] very confusing compiler diagnostics (for stupid bug on my part)

[davecat49 at gmail dot com]

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



--- Comment #6 from Dave  2013-03-11 18:46:35 UTC 
---

Created attachment 29644

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29644

second offending program



Compiler error output for this one puts the error in stdio.h:



In file included from dlt9.c:2:0:

f:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/stdio.h:641:21:

error: expected ',' or ';' before numeric constant

[Bug target/56591] Missing space

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



 Status|WAITING |NEW



--- Comment #2 from Andrew Pinski  2013-03-11 
18:47:27 UTC ---

There is an obvious space missing:

output_operand_lossage ("Unsupported code '%c'for fixed-point:",

code);

[Bug c/56599] very confusing compiler diagnostics (for stupid bug on my part)

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  2013-03-11 
18:49:38 UTC ---
Works on the trunk on x86_64-linux-gnu just fine:
dlt8.c:4:25: error: expected ‘,’ or ‘;’ before numeric constant
 #define  SAMPLELONGLONG 123456789012345
 ^
dlt8.c:10:90: note: in expansion of macro ‘SAMPLELONGLONG’
"Here we have some user info, wherein we stupidly try to include a numeric
constant " SAMPLELONGLONG;
   
  ^
apinski@apinskidesktop:~/Downloads$ ~/gcc-228/bin/gcc dlt9.c
dlt9.c:4:25: error: expected ‘,’ or ‘;’ before numeric constant
 #define  SAMPLELONGLONG 123456789012345
 ^
dlt9.c:10:90: note: in expansion of macro ‘SAMPLELONGLONG’
"Here we have some user info, wherein we stupidly try to include a numeric
constant " SAMPLELONGLONG;
   
  ^

[Bug c/56599] very confusing compiler diagnostics (for stupid bug on my part)

[dave at firstcomp dot biz]

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



--- Comment #8 from dave at firstcomp dot biz 2013-03-11 18:51:12 UTC ---

On Mon, Mar 11, 2013 at 2:11 PM, pinskia at gcc dot gnu.org

 wrote:

>

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

>

> --- Comment #1 from Andrew Pinski  2013-03-11 
> 18:11:17 UTC ---

> No info in bug.

>

> --

> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email

> --- You are receiving this mail because: ---

> You reported the bug.



I entered a complete description, then tried attaching the

preprocessor output.  It apparently threw away what I'd entered at

that point.  I've re-entered parts of it & attached more stuff.  I

guess I don't see how to attach without submitting?



-- Dave

[Bug c/56599] very confusing compiler diagnostics (for stupid bug on my part)

[dave at firstcomp dot biz]

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

--- Comment #9 from dave at firstcomp dot biz 2013-03-11 18:54:10 UTC ---
As shown in other attachments, for me it generated references to other
lines (many lines away in the big program I tried to reduce this to),
& if I removed all earlier lines referencing a location in stdio.h !

-- Dave

On Mon, Mar 11, 2013 at 2:49 PM, pinskia at gcc dot gnu.org
 wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56599
>
> --- Comment #7 from Andrew Pinski  2013-03-11 
> 18:49:38 UTC ---
> Works on the trunk on x86_64-linux-gnu just fine:
> dlt8.c:4:25: error: expected ‘,’ or ‘;’ before numeric constant
>  #define  SAMPLELONGLONG 123456789012345
>  ^
> dlt8.c:10:90: note: in expansion of macro ‘SAMPLELONGLONG’
> "Here we have some user info, wherein we stupidly try to include a numeric
> constant " SAMPLELONGLONG;
>
>   ^
> apinski@apinskidesktop:~/Downloads$ ~/gcc-228/bin/gcc dlt9.c
> dlt9.c:4:25: error: expected ‘,’ or ‘;’ before numeric constant
>  #define  SAMPLELONGLONG 123456789012345
>  ^
> dlt9.c:10:90: note: in expansion of macro ‘SAMPLELONGLONG’
> "Here we have some user info, wherein we stupidly try to include a numeric
> constant " SAMPLELONGLONG;
>
>   ^
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You reported the bug.

[Bug target/56591] Missing space

[gjl at gcc dot gnu.org]

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



--- Comment #3 from Georg-Johann Lay  2013-03-11 
18:57:35 UTC ---

Author: gjl

Date: Mon Mar 11 18:57:27 2013

New Revision: 196604



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196604

Log:

PR target/56591

* config/avr/avr.c (avr_print_operand): Add space after '%c' in

output_operand_lossage message.







Modified:

trunk/gcc/ChangeLog

trunk/gcc/config/avr/avr.c

[Bug c/56599] very confusing compiler diagnostics (for stupid bug on my part)

[dave at firstcomp dot biz]

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



--- Comment #10 from dave at firstcomp dot biz 2013-03-11 18:58:00 UTC ---

I forgot to add when I reentered stuff.  This was from MinGW running

on Windows XP, but got same error messages on a Linux machine (sent it

to someone to check).  gcc --version shows this:

gcc (GCC) 4.5.2

I don't know how to tell what options the gcc was built with; I did

see that your "what we need listed that, but trying to figure it out I

came up with nothing.



-- Dave

[Bug target/56591] Missing space

[gjl at gcc dot gnu.org]

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



Georg-Johann Lay  changed:



   What|Removed |Added



   Keywords||diagnostic

   Priority|P4  |P5

 Status|NEW |RESOLVED

 Resolution||FIXED

   Target Milestone|--- |4.8.0

   Severity|normal  |trivial



--- Comment #4 from Georg-Johann Lay  2013-03-11 
19:01:27 UTC ---

Fixed.

[Bug target/56560] [4.6/4.7 regression] vzeroupper clobbers argument with AVX

[hjl.tools at gmail dot com]

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



--- Comment #6 from H.J. Lu  2013-03-11 19:34:29 
UTC ---

Created attachment 29645

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29645

A patch



This patch adds expand_args to track library calls to

expend arguments.  We add vzeroupper when expand_args == 1,

which indicates we are expanding the actual function.

[Bug target/40797] [4.6/4.7/4.8 Regression] ICE in df_refs_verify, at df-scan.c:4361

[olegendo at gcc dot gnu.org]

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



Oleg Endo  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||WORKSFORME



--- Comment #15 from Oleg Endo  2013-03-11 
19:50:49 UTC ---

(In reply to comment #12)

> (In reply to comment #11)

> > I've tried current 4.6/4.7/4.8 with --enable-checking=df on sh4-linux

> > and found that the ice has gone for both original and reduced test cases.

> > I'd like to close this PR unless new test case pops up.

> 

> I'd like to add a test case to the test suite for this PR first, if that's OK.



Done.

[Bug target/13423] sh-elf: V4SFmode passed in integer registers

[olegendo at gcc dot gnu.org]

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



--- Comment #4 from Oleg Endo  2013-03-11 19:56:20 
UTC ---

(In reply to comment #3)

> 

> ideally, this would be something like (no insn scheduling applied):

> 

> fmov.s  @r4+,fr0

> fmov.s  @r4+,fr1

> fmov.s  @r4+,fr2

> fmov.s  @r4+,fr3

> 

> fmov.s  @r5+,fr4

> fmov.s  @r5+,fr5

> fmov.s  @r5+,fr6

> fmov.s  @r5+,fr7

> 

> faddfr4,fr0

> faddfr5,fr1

> faddfr6,fr2

> faddfr7,fr3

> 

> fmov.s  fr3,@-r4

> fmov.s  fr2,@-r4

> fmov.s  fr1,@-r4

> fmov.s  fr0,@-r4



Which would probably require a working address mode selection optimization

pass, see PR 56590.



As for the ABI issue when passing vectors by value, I've created PR 56592 that

describes a proposed new vector ABI for SH.

[Bug target/49880] SuperH: ICE when -m4 is used with -mdiv=call-div1

[olegendo at gcc dot gnu.org]

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



Oleg Endo  changed:



   What|Removed |Added



 CC||olegendo at gcc dot gnu.org



--- Comment #3 from Oleg Endo  2013-03-11 20:29:57 
UTC ---

(In reply to comment #1)

> I've confirmed that trunk and all released compilers fail with

> -m4 -mdiv=call-div1.  I'm testing the patch below.

> 

> * config/sh/sh.md (udivsi3_i1): Enable for TARGET_DIVIDE_CALL_DIV1.

> (divsi3_i1): Likewise.

> 

> --- ORIG/trunk/gcc/config/sh/sh.md2011-07-20 09:27:11.0 +0900

> +++ trunk/gcc/config/sh/sh.md2011-07-28 06:49:41.0 +0900

> @@ -1609,7 +1609,7 @@

> (clobber (reg:SI PR_REG))

> (clobber (reg:SI R4_REG))

> (use (match_operand:SI 1 "arith_reg_operand" "r"))]

> -  "TARGET_SH1 && ! TARGET_SH4"

> +  "TARGET_SH1 && (! TARGET_SH4 || TARGET_DIVIDE_CALL_DIV1)"

>"jsr@%1%#"

>[(set_attr "type" "sfunc")

> (set_attr "needs_delay_slot" "yes")])

> @@ -1815,7 +1815,7 @@

> (clobber (reg:SI R2_REG))

> (clobber (reg:SI R3_REG))

> (use (match_operand:SI 1 "arith_reg_operand" "r"))]

> -  "TARGET_SH1 && ! TARGET_SH4"

> +  "TARGET_SH1 && (! TARGET_SH4 || TARGET_DIVIDE_CALL_DIV1)"

>"jsr@%1%#"

>[(set_attr "type" "sfunc")

> (set_attr "needs_delay_slot" "yes")])



I think the conditions



"TARGET_SH1 && (! TARGET_SH4 || TARGET_DIVIDE_CALL_DIV1)"



can be simplified to



"TARGET_SH1 && TARGET_DIVIDE_CALL_DIV1"



in this case.  The division strategy is selected in sh_option_override, which

already does all the checks, so there should be no need to check for

TARGET_SH4.

Seeing the "! TARGET_SH4" in the conditions is a bit confusing, because

-mdiv=call-div1 is available on all SH variants except SHmedia.



I've tried the simplified conditions and it works as expected.

I'll submit a patch that also adds a some test cases for for -mdiv option.

[Bug c++/56039] ICE in iterative_hash_template_arg, at cp/pt.c:1606

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



   Keywords|ice-on-valid-code   |ice-on-invalid-code

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-03-11

 CC||jason at gcc dot gnu.org

 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org

   |gnu.org |

 Ever Confirmed|0   |1



--- Comment #9 from Jason Merrill  2013-03-11 
20:35:36 UTC ---

(In reply to comment #2)

> (In reply to comment #1)

> re: 5.19 p2 b8

> 

> 5.19 p2 (before the referenced bullet list) reads:

> ..., but subexpressions of logical AND (5.14), logical OR (5.15) and

> conditional (5.16) operations that are not evaluated are not considered...



Looks like a defect in the wording.  The intent is that a lambda body must not

appear in SFINAE context.

[Bug bootstrap/53728] [4.6 regression] Bootstrap comparison failure (gcc/varasm.o differs) with CFLAGS="-O2 -march=pentium3"

[ubizjak at gmail dot com]

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



--- Comment #5 from Uros Bizjak  2013-03-11 21:11:00 
UTC ---

Created attachment 29646

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29646

Preprocessed source of the file that miscompares during bootstrap



This is a compare-debug failure with -O2 -march=pentium3



~/gcc-build-46/prev-gcc/xgcc -B ~/gcc-build-46/prev-gcc -O2 -march=pentium3

-fcompare-debug varasm.i 

xgcc: error: varasm.i: -fcompare-debug failure (length)



Where gcc was configured with:



CC="gcc -m32" ~/gcc-svn/branches/gcc-4_6-branch/configure

--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --with-arch=i686

--enable-languages=c

[Bug bootstrap/53728] [4.6 regression] Bootstrap comparison failure (gcc/varasm.o differs) with CFLAGS="-O2 -march=pentium3"

[ubizjak at gmail dot com]

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



Uros Bizjak  changed:



   What|Removed |Added



 Status|WAITING |NEW



--- Comment #6 from Uros Bizjak  2013-03-11 21:31:26 
UTC ---

(In reply to comment #5)



> This is a compare-debug failure with -O2 -march=pentium3



Also fails on gcc-4_6 x86_64 with -O2 -m32 -march=pentium3



~/gcc-build-46/prev-gcc/xgcc -B ~/gcc-build-46/prev-gcc

-O2 -march=pentium3 -fcompare-debug -m32 varasm.i 

xgcc: error: varasm.i: -fcompare-debug failure (length)



xgcc (GCC) 4.6.4 20130311 (prerelease) [gcc-4_6-branch revision 196601]

[Bug c++/56567] [4.8 Regression] ICE with lambda return type deduction and braced-init-list

[potswa at mac dot com]

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



--- Comment #7 from David Krauss  2013-03-11 22:42:46 
UTC ---

Created attachment 29647

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29647

alternative fix



Yes. However, the above fix doesn't catch all instances of doing so; for

example



[]() -> std::initializer_list< int >{ return { 1, 2 }; }



Worse, one case still results in ICE



[]() { return std::initializer_list< int >{ 1, 2 }; }



Here's an improved fix. It doesn't attempt to catch runtime UB. I think that

should be another warning diagnostic, which can also flag such attempted

workarounds as reference return types



[]() -> std::initializer_list< int > && { return { 1, 2 }; }



Users are likely to try fiddling after we flag their initial attempt, so we

might as well be as broad as possible. However, a specialization of std::min

can return a valid std::initializer_list< T > const & :



struct s {

friend bool operator < ( s lhs, s rhs ) { return false; }



friend bool operator < ( std::initializer_list< s > lhs,

 std::initializer_list< s > rhs )

{ return std::lexicographical_compare( lhs.begin(), lhs.end(),

   rhs.begin(), rhs.end() ); }

};



std::min( std::initializer_list< std::initializer_list< s > >

 { { s(), s(), s() }, { s(), s() } } );

[Bug bootstrap/53728] [4.6 regression] Bootstrap comparison failure (gcc/varasm.o differs) with CFLAGS="-O2 -march=pentium3"

[ubizjak at gmail dot com]

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



--- Comment #7 from Uros Bizjak  2013-03-11 22:43:38 
UTC ---

Testcase:



--cut here--

extern int global_options;

extern unsigned char *mode_size;



extern int printf (const char *, ...);



void mergeable_constant_section (int mode, unsigned long long align)

{

  unsigned int modesize = mode_size[mode] * 8;



  if (global_options && modesize <= align && (align & (align - 1)) == 0)

{

  unsigned int flags;



  printf ("%d", (int) (align / 8));

  flags = align / 8;

  printf ("%u", (unsigned int) flags);

}

}

--cut here--



$ ~/gcc-build-46/gcc/xgcc -B ~/gcc-build-46/gcc -O2 -m32 -march=pentium3 \

-fcompare-debug pr53728.c

xgcc: error: pr53728.c: -fcompare-debug failure (length)

[Bug c++/56567] [4.8 Regression] ICE with lambda return type deduction and braced-init-list

[potswa at mac dot com]

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



--- Comment #8 from David Krauss  2013-03-11 22:51:12 
UTC ---

Oops, I didn't see the preceding comment & checkin before submitting that.

Maybe that's a better place to check, but we might keep the extra test cases.

Make sure that the remaining ICE is gone.

[Bug rtl-optimization/53728] [4.6 regression] Bootstrap comparison failure (gcc/varasm.o differs) with CFLAGS="-O2 -march=pentium3"

[ubizjak at gmail dot com]

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



Uros Bizjak  changed:



   What|Removed |Added



 CC||vmakarov at gcc dot gnu.org

  Component|bootstrap   |rtl-optimization



--- Comment #8 from Uros Bizjak  2013-03-11 23:13:52 
UTC ---

The difference indeed starts with IRA.



Non-debug compile declares following registers as ever live:



;;  regs ever live  0[ax] 1[dx] 2[cx] 3[bx] 7[sp] 17[flags]



where debug compile declares:



;;  regs ever live  0[ax] 1[dx] 2[cx] 3[bx] 4[si] 7[sp] 17[flags]



There is additional [si] register in the later compilation.



Re-categorized as generic RTL-optimization problem and added CC.

[Bug c/56599] very confusing compiler diagnostics (for stupid bug on my part)

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #11 from Manuel López-Ibáñez  2013-03-11 
23:15:16 UTC ---
Dave, this bug seems to be fixed in the about to be released GCC 4.8.0

[Bug c/56599] very confusing compiler diagnostics (for stupid bug on my part)

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

  Known to work||4.8.0

 Resolution||FIXED



--- Comment #12 from Paolo Carlini  2013-03-11 
23:44:13 UTC ---

Closing as fixed in mainline then.

[Bug lto/56578] Testcase behaves differently when compiled with LTO

[d.g.gorbachev at gmail dot com]

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



--- Comment #2 from Dmitry Gorbachev  
2013-03-12 00:46:13 UTC ---

GCC 4.8.0, 4.7.3, 4.6.4; build = host = target = i686-pc-linux-gnu; configured

with "--enable-languages=c,c++ --enable-version-specific-runtime-libs

--disable-nls --disable-shared"; glibc 2.17; recent binutils (GNU ld and gold).



> that is, 'make' prints three times OK



The 4th time (prog3) it prints "FAIL" for me -- free() is from main.c, but

malloc() is from glibc.

[Bug libstdc++/56557] [4.8 Regression] Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options

[hubicka at gcc dot gnu.org]

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



--- Comment #11 from Jan Hubicka  2013-03-12 
00:58:48 UTC ---

BTW, one thing i do not understand is why the construction vtables are not

static when they can not be used across .o boundary?