[Bug c++/48069] [4.6 Regression] FAIL: g++.old-deja/g++.pt/spec26.C

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.11 07:17:13
 Ever Confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  2011-03-11 
07:17:13 UTC ---
Confirmed. The ICE is

/opt/gcc/work/gcc/testsuite/g++.old-deja/g++.pt/spec26.C:11:36: internal
compiler error: canonical types differ for identical types const X [] and const
X []

[Bug c++/48069] [4.6 Regression] FAIL: g++.old-deja/g++.pt/spec26.C

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||jason at redhat dot com
   Target Milestone|--- |4.6.0

--- Comment #1 from H.J. Lu  2011-03-11 06:28:49 
UTC ---
It is caused by revision 170853:

http://gcc.gnu.org/ml/gcc-cvs/2011-03/msg00274.html

[Bug c++/48069] New: [4.6 Regression] FAIL: g++.old-deja/g++.pt/spec26.C

[hjl.tools at gmail dot com]

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

   Summary: [4.6 Regression] FAIL: g++.old-deja/g++.pt/spec26.C
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/x86, revision 170853 gave:

FAIL: g++.old-deja/g++.pt/spec26.C (internal compiler error)
FAIL: g++.old-deja/g++.pt/spec26.C (test for excess errors)

Revision 170848 is OK.

[Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #19 from Hans-Peter Nilsson  2011-03-11 
04:42:21 UTC ---
(In reply to comment #18)
> > To be investigated; I'll do my part.

Famous last words... well, it didn't happen yet, but something else happened:

This bug was either fixed or re-covered in the range 170660..170665 and I'd be
very surprised if it wasn't your 170663.  Tracking down the related mailing
list conversations (with DJ regarding m32r) it was apparently a fix intended
for exactly this problem, so thanks. :]  Yay, no regressions since T0.

Did I mention I tried at the previous iteration setting EXIT_IGNORE_STACK to 1
and got massive regressions?  Ripe for a revisit.  Just not now.

As an intended fix was committed, I'm closing this PR.

[Bug target/48068] loongson intrinsics improvement opportunities

[hp at gcc dot gnu.org]

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

--- Comment #3 from Hans-Peter Nilsson  2011-03-11 
02:48:00 UTC ---
Created attachment 23624
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23624
23623: With --target=mips64el-unknown-linux-gnu, result of "./xgcc -W -Wall -O2
-B./ -S -I. -march=loongson2f x.c -o xn32.s"

Similar to the previous attachment but for the N32 ABI.
GCC from "trunk revision 170836".

[Bug target/48068] loongson intrinsics improvement opportunities

[hp at gcc dot gnu.org]

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

--- Comment #2 from Hans-Peter Nilsson  2011-03-11 
02:42:15 UTC ---
Created attachment 23623
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23623
With --target=mipsel-unknown-linux-gnu, result of "./xgcc -W -Wall -O2 -B./ -S
-I. -march=loongson2f x.c -o xo32.s"

With stdint.h in the gcc objdir, run xgcc as in description.

Note the generic-code generated for ior(), the initialization of the
output-only operand for "pshufh" in gag(), and the needless moving between
float/vector and general registers as well as using the general-register-add in
mp() except as mandated by the intrinsic.

[Bug target/48068] loongson intrinsics improvement opportunities

[hp at gcc dot gnu.org]

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

--- Comment #1 from Hans-Peter Nilsson  2011-03-11 
02:33:00 UTC ---
Created attachment 23622
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23622
Trivial stdint.h suitable for showing the problem after "make all-gcc"
standalone

[Bug target/48068] New: loongson intrinsics improvement opportunities

[hp at gcc dot gnu.org]

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

   Summary: loongson intrinsics improvement opportunities
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: h...@gcc.gnu.org
Target: mipsel-unknown-linux-gnu, mips64el-unknown-linux-gnu


Created attachment 23621
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23621
Code showing the three mentioned shortcomings

While writing a Loongson-2E / -2F backend for RAPP,
http://savannah.nongnu.org/projects/rapp/ using gcc52 at the compilefarm I
noticed a few omissions and opportunities for improvements.  I just thought
adding some notes here would be better than nothing.

1. Lack of trivial logical operators on vector types.
There are insns for "or", shifts (the whole vector), xor, orn, and "and" that
can operate directly on the vector registers (the floating point registers),
but there are neither builtins for those operations nor do operations on the
types use the vector registers; attempts generate code that uses regular insns
and general registers.  Looking in the loongson+mips code shows that there's no
support for them.  I had to resort to asms in the port file,
http://git.savannah.gnu.org/cgit/rapp.git/tree/compute/backend/rc_vec_loongson2ef.h
for reference.

2. The pshufh_u and pshufh_s builtins have a spurious unused first operand
(a confusion regarding operand 0 obvious by reading loongson.md).
I understand removing the argument to the intrinsic would break the intrinsics
API, but a corrected intrinsic could be added by a different name or be
requested by a new option, avoiding the extra instructions initializing this
destination-only register caused by specifying it also as an input.

3. Normal scalar operations on 64-bit integers are supported by the ISA
operating on integer contents in the floating-point registers, but lacking
support in the port, except through explicit use through paddd/psubd/pmuluw
intrinsics.  The "clash with mips.md::add3"-type issues can be solved by
merging these into the normal insn patterns and adding alternatives using
constraints that match only when the loongson vector support is enabled. 
(Though I understand maintainer hesitation adding support for everyones
COP2-integer extensions into the regular insns.)

FWIW, I used the ISA documentation at
http://loongson-dev.googlegroups.com/web/Loongson2FUserGuide.pdf

I'll add a few examples.

[Bug tree-optimization/37916] [4.3/4.4/4.5/4.6 Regression] SSA names causing register pressure; unnecessarily many simultaneously "live" names.

[hp at gcc dot gnu.org]

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

--- Comment #20 from Hans-Peter Nilsson  2011-03-11 
01:31:14 UTC ---
(In reply to comment #19)
> Random thought on this PR: With a scheduler description, -fschedule-insns
> -fsched-pressure may help.

That theory should be testable by compiling for e.g. a x86_64 target; see
comment #12, but to answer your question...

> Is there a reason why there is no scheduler description?

Yes.  For a while, there was nothing to schedule.

...except for CPUs in systems a cache, where it helps to schedule to avoid RaW
hazards.
...and then pipelined variants came, with other hazards to schedule (to avoid
bubbles, no mips1-type madness).
...but then, I noticed that scheduling with the "new" scheduler wasn't
supported for CC0 targets.
...which later was either fixed, or just a plain misunderstanding (cf.
m68k/cf.md).
...and when checking the cycle-correct simulator, I found that there weren't
many cycles to schedule away, hence a fair amount of work for no apparent gain,
at least for the intended purpose of insn scheduling.

There you go, the reasons in a nutshell.  And while there's still a possibility
that it's a pragmatic solution (modulo #c12), it doesn't strike me as requiring
a scheduler to be the Right Thing to do for a fix to this problem.
(Though from a general GCC maintenance perspective, automatically defaulting to
a trivial scheduler might be a good idea.)

[Bug libfortran/48047] Incorrect output rounding of double precision numbers

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle  2011-03-11 
00:59:04 UTC ---
I am OK with this simple patch, but will have to run the testsuite to make sure
its all OK on our other testsuite cases. (Not very many at the moment)

[Bug tree-optimization/48067] FMA with no add operand produced by convert_mul_to_fma

[wschmidt at gcc dot gnu.org]

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

--- Comment #1 from William J. Schmidt  2011-03-11 
00:55:30 UTC ---
Created attachment 23620
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23620
Failing subroutine from 191.fma3d

Sorry the subroutine was mangled in the comments.  Here's a clean copy.

[Bug tree-optimization/48067] New: FMA with no add operand produced by convert_mul_to_fma

[wschmidt at gcc dot gnu.org]

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

   Summary: FMA with no add operand produced by convert_mul_to_fma
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wschm...@gcc.gnu.org
CC: rgue...@gcc.gnu.org, berg...@gcc.gnu.org,
pthau...@gcc.gnu.org


There is a latent bug in tree-ssa-math-ops.c: convert_mul_to_fma.  This is
exposed when building SPEC cpu2000 benchmark 191.fma3d for
branches/ibm/gcc-4_5-branch, but does not currently reproduce on mainline or
fsf 4.5.

Prior to the widening_mul pass, the gimple contains the following (stripped of
unrelated statements):

  c12_7 = D.743_5 * cim_6(D);
  d12_8 = -c12_7;
  D.745_11 = c12_7 - d12_8;

The FMA transform produces this:

  D.768_8 = -D.743_5;
  D.767_20 = D.768_8 * cim_6(D) + ;
  D.745_11 = D.743_5 * cim_6(D) + D.767_20;

The second instruction is a ternary op with a null rhs3 operand.  This causes a
segv in the verify_ssa code following this pass.

convert_mul_to_fma has two loops over the immediate uses of mul_result (c12_7
in this case).  In the first loop, if a use is found to be a NEGATE_EXPR, it is
only processed if it has a single immediate use, which must be a PLUS_EXPR or a
MINUS_EXPR.  The second loop assumes this still holds.  Unfortunately, this
case demonstrates that it is possible for the assumption to be violated.

The first pass through the second loop processes the assignment to D.745_11
first, and converts it to an FMA:

  D.767_20 = -d12_8;
  D.745_11 = D.743_5 * cim_6(D) + D.767_20;

Note that this has removed the original use of d12_8 in a MINUS_EXPR, and
replaced it with a new use in a NEGATE_EXPR.  Now the statement

  d12_8 = -c12_7;

no longer satisfies the rule that its single use is in a PLUS_EXPR or a
MINUS_EXPR.  It's now part of a NEGATE_EXPR that can't be converted into an
FMA.

I believe the right thing to do here is probably to check for neguse_stmt still
being either a PLUS_EXPR or a MINUS_EXPR after the call to single_imm_use in
the second loop.  If not, avoid replacing the original use_stmt with
neguse_stmt and just continue to the next use.  But I'll defer to those with
more knowledge of the code.

(As a side note, the first loop over immediate uses manipulates a "negate_p"
local var that doesn't appear to have any effect.  The second loop has its own
copy of negate_p.  Looks like something left over from an earlier design?)

The procedure where the above occurs in 191.fma3d is:

  SUBROUTINE MATERIAL_22_INTEGRATION  
&
 &  ( 
&
 &  STRESS,A,B,Strain_A,Strain_B,Strain_C,Akk,
&
 &  DTnext,Drr,Dss,Drs,MatID  
&
 &  )
  REAL(KIND(0D0)) 
&
 &  STRESS(3),A(2),B(2)
  IF (PAB .GT. 0.0) THEN
C12 = C1*C2 * Cim
D12 = -C12
IF (SMD .EQ. 0.0) THEN
ENDIF
STRESS(3) = STRESS(3) + (Shear * (C12 - D12))
  ENDIF
  IF (Akk .LE. Afc) THEN
  ENDIF
  END

[Bug c++/47952] [trans-mem] undefined reference to transaction clone

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #16 from Richard Henderson  2011-03-10 
23:46:38 UTC ---
Fixed, as far as I can tell.

[Bug c++/47952] [trans-mem] undefined reference to transaction clone

[rth at gcc dot gnu.org]

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

--- Comment #15 from Richard Henderson  2011-03-10 
23:45:53 UTC ---
(In reply to comment #12)
> Should I fill a new PR for this even if I don't have any real testcase?

Yes please.

[Bug c++/47952] [trans-mem] undefined reference to transaction clone

[rth at gcc dot gnu.org]

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

--- Comment #14 from Richard Henderson  2011-03-10 
23:42:10 UTC ---
*** Bug 48021 has been marked as a duplicate of this bug. ***

[Bug c++/48021] [trans-mem] call to an undefined clone

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Richard Henderson  2011-03-10 
23:42:10 UTC ---
I didn't realize that this had been split out of the parent PR
before fixing it there.

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

[Bug fortran/48066] [4.3/4.4/4.5/4.6 Regression] Segfault with SUM of zero-sized array

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Priority|P3  |P4
  Known to work||4.1.2
   Target Milestone|--- |4.4.6
  Known to fail||4.3.4, 4.4.0, 4.5.1, 4.6.0

[Bug fortran/48066] [4.3/4.4/4.5/4.6 Regression] Segfault with SUM of zero-sized array

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  2011-03-10 
23:34:53 UTC ---
For completeness, the submitted asked at c.l.f whether the program is valid;
Richard Maine thinks so. (I concur ;-)

http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/457a5b283c702bbc

[Bug fortran/48066] [4.3/4.4/4.5/4.6 Regression] Segfault with SUM of zero-sized array

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  2011-03-10 
23:19:30 UTC ---
(In reply to comment #2)
> The "Bus error" seems fixed by the patch in
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829#c32.

Well, it does not fix it, it just hides the problem: The patch in PR 43829
moves SUM into the front end - thus, it makes the libgfortran code unreachable
for this test case.

[Bug fortran/48059] [4.6 Regression][OOP] ICE in in gfc_conv_component_ref: character function of extended type

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  2011-03-10 
23:15:40 UTC ---
This is indeed cause by revision 170284 (no ICE at r 170283).

[Bug fortran/48066] [4.3/4.4/4.5/4.6 Regression] Segfault with SUM of zero-sized array

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.10 23:14:27
 CC||mikael at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  2011-03-10 
23:14:27 UTC ---
The "Bus error" seems fixed by the patch in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829#c32.

[Bug ada/37430] [4.4/4.5/4.6 Regression] C974013 gives exception

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 CC||steven at gcc dot gnu.org

--- Comment #7 from Steven Bosscher  2011-03-10 
23:12:25 UTC ---
Does not fail with recent compilers, it would seem:
http://gcc.gnu.org/ml/gcc-testresults/2011-02/msg02364.html

[Bug fortran/48066] [4.3/4.4/4.5/4.6 Regression] Segfault with SUM of zero-sized array

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  2011-03-10 
23:09:15 UTC ---
Valgrind:

==9860== Invalid write of size 8
==9860==at 0x4EAB980: _gfortran_sum_r8 (sum_r8.c:147)
==9860==by 0x400955: MAIN__ (test.f90:3)

>From libgfortran/generated/sum_r8.f90:

  dest = retarray->data;
[...]
if (len <= 0)
  *dest = 0;

which fails if dest == NULL

[Bug c++/47952] [trans-mem] undefined reference to transaction clone

[rth at gcc dot gnu.org]

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

--- Comment #13 from Richard Henderson  2011-03-10 
23:04:11 UTC ---
Author: rth
Date: Thu Mar 10 23:04:05 2011
New Revision: 170854

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170854
Log:
PR 47952
* trans-mem.c (ipa_tm_create_version): Remap extern inline
functions to static inline clones.

Modified:
branches/transactional-memory/gcc/ChangeLog.tm
branches/transactional-memory/gcc/trans-mem.c

[Bug fortran/48066] New: [4.3/4.4/4.5/4.6 Regression] Segfault with SUM of zero-sized array

[burnus at gcc dot gnu.org]

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

   Summary: [4.3/4.4/4.5/4.6 Regression] Segfault with SUM of
zero-sized array
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


Reported on IRC. The following program segfaults with gfortran 4.3 to 4.6 but
works with gfortran 4.1:

program p
  real(8) :: empty(0, 3), square(0)
  square = sum(empty * empty, 2)
  print *, "square=", square
end

[Bug c++/46824] chromium-compile failed because error: no match for ‘operator*’ in

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|dodji at gcc dot gnu.org|
 AssignedTo|unassigned at gcc dot   |dodji at gcc dot gnu.org
   |gnu.org |

[Bug c++/46824] chromium-compile failed because error: no match for ‘operator*’ in

[dodji at gcc dot gnu.org]

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

--- Comment #9 from Dodji Seketeli  2011-03-10 
22:53:42 UTC ---
Yes, I was confused.  This code is valid.

[Bug fortran/48059] [4.6 Regression][OOP] ICE in in gfc_conv_component_ref: character function of extended type

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug c++/48029] [4.5/4.6 Regression] ICE in finish_member_declaration() with --param ggc-min-expand=0 --param ggc-min-heapsize=0

[jason at gcc dot gnu.org]

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

--- Comment #10 from Jason Merrill  2011-03-10 
22:37:27 UTC ---
Author: jason
Date: Thu Mar 10 22:37:22 2011
New Revision: 170853

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170853
Log:
PR c++/48029
* stor-layout.c (layout_type): Don't set structural equality
on arrays of incomplete type.
* tree.c (type_hash_eq): Handle comparing them properly.
* cp/pt.c (iterative_hash_template_arg): Remove special case for
ARRAY_TYPE.

Added:
trunk/gcc/testsuite/g++.dg/template/array22.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/stor-layout.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c

[Bug c++/46824] chromium-compile failed because error: no match for ‘operator*’ in

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  2011-03-10 
22:26:42 UTC ---
(In reply to comment #7)
> It doesn't need to be a pointer to non-class type; a pointer to class is 
> itself
> a non-class type.

Indeed. And the example compiles fine if the type is complete.  I can't find
any wording that says why converting to Incomplete* should not be allowed when
converting to Complete* is ok.  I wondered if DR416 is relevant, but I don't
think it applies, as T1 is Ptr here, which is complete.

[Bug rtl-optimization/33928] [4.3/4.4/4.5/4.6 Regression] 30% performance slowdown in floating-point code caused by r118475

[lucier at math dot purdue.edu]

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

--- Comment #120 from lucier at math dot purdue.edu 2011-03-10 22:00:22 UTC ---
At

http://www.math.purdue.edu/~lucier/bugzilla/15/

I've put a tarfile and instructions that allow one to build Gambit-C in
a way that splits out the FFT code into its own C function, so the
assembly code can be more easily examined.

Brad

[Bug fortran/48059] [4.6 Regression][OOP] ICE in in gfc_conv_component_ref: character function of extended type

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||burnus at gcc dot gnu.org,
   ||matz at suse dot de, pault
   ||at gcc dot gnu.org
  Known to work||4.5.2
   Target Milestone|--- |4.6.0
Summary|[OOP] ICE in in |[4.6 Regression][OOP] ICE
   |gfc_conv_component_ref: |in in
   |character function of   |gfc_conv_component_ref:
   |extended type   |character function of
   ||extended type
  Known to fail||4.6.0

--- Comment #4 from Tobias Burnus  2011-03-10 
21:45:02 UTC ---
Michael, I CCed you because the ICE is in gfc_conv_component_ref, which you
have modified for PR 45586 (Rev. 170284).

That's also in the range of commits (169790:170493), which Dominique has given.

[Bug c++/46824] chromium-compile failed because error: no match for ‘operator*’ in

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  2011-03-10 
21:30:34 UTC ---
It doesn't need to be a pointer to non-class type; a pointer to class is itself
a non-class type.

[Bug c++/46824] chromium-compile failed because error: no match for ‘operator*’ in

[dodji at gcc dot gnu.org]

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

--- Comment #6 from Dodji Seketeli  2011-03-10 
21:20:52 UTC ---
Thank you for reducing this.

Here is what I understand from the reduced test case.

For the expression "*p" the compiler uses overload resolution to
determine which operator "*" to use.  As there is no user provided
operator*() that can take an instance of Ptr in argument, the only
choice left is to consider the built-in operator*() as a viable
candidate for overload resolution.

But then the note in [over.built]/1 says:

because built-in operators take only operands with non-class type, and
operator overload resolution occurs only when an operand expression
originally has class or enumeration type, operator overload resolution
can resolve to a built-in operator only when an operand has a class type
that has a user-defined conversion to a non-class type appropriate for
the operator, or when an operand has an enumeration type that can be
converted to a type appropriate for the operator.

As there is no user-defined conversion operator that would convert Ptr
into a pointer to native type, the built-in operator*() is not a viable
candidate.

Thus I believe the test case is ill-formed and the user-defined
conversion operator that converts Ptr to Incomplete* seems to be of
little use in this case.

So for the built-in operator to be selected, we'd need e.g, a
user-defined conversion operator Ptr::operator int* ().  Otherwise we'd
need a user-defined operator 'something Ptr::operator*()'.

[Bug fortran/48059] [OOP] ICE in in gfc_conv_component_ref: character function of extended type

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #3 from Harald Anlauf  2011-03-10 20:23:56 
UTC ---
(In reply to comment #0)
> The code:

For what it's worth:

ifort 12.0 and PGI 11.1 accept the code,
and xlf 13.1.0.4 warns:

"test.f90", 1513-083 (E) Internal or module function form was not set within
the function.
** a_module   === End of Compilation 1 ===
1501-510  Compilation successful for file test.f90.

[Bug target/42976] Illegal translation for IF operator

[eric.weddington at atmel dot com]

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

Eric Weddington  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Eric Weddington  
2011-03-10 20:21:23 UTC ---
Resolving as invalid.

[Bug target/42976] Illegal translation for IF operator

[avr at gjlay dot de]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||avr at gjlay dot de,
   ||kharpost at rambler dot ru

--- Comment #1 from Georg-Johann Lay  2011-03-10 20:14:46 
UTC ---
There is nothing wrong with the code.

bugif.c is compiled and disassembled as expected.

For the snippets with keybuf.keys, keys.keys there is no source, so presumably
these variables are defined to be 32-bit scalar.

Again, there is nothing wrong with that code. This bug can be marked as
"invalid".

Johann

[Bug lto/48065] LTO: assertion failed in optimize_inline_calls, at tree-inline.c:4246

[d.g.gorbachev at gmail dot com]

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

--- Comment #1 from Dmitry Gorbachev  
2011-03-10 20:00:27 UTC ---
Created attachment 23619
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23619
backtrace

[Bug lto/48065] New: LTO: assertion failed in optimize_inline_calls, at tree-inline.c:4246

[d.g.gorbachev at gmail dot com]

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

   Summary: LTO: assertion failed in optimize_inline_calls, at
tree-inline.c:4246
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d.g.gorbac...@gmail.com


Created attachment 23618
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23618
testcase

In file included from :0:0:
main.c: In function 'main':
main.c:3:5: internal compiler error: in optimize_inline_calls, at
tree-inline.c:4246

[Bug rtl-optimization/33928] [4.3/4.4/4.5/4.6 Regression] 30% performance slowdown in floating-point code caused by r118475

[lucier at math dot purdue.edu]

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

--- Comment #119 from lucier at math dot purdue.edu 2011-03-10 19:55:54 UTC ---
It's nearly impossible to examine the assembly code responsible for the FFT in
the package I set up in the previous comment.  If you want a runtime benchmark
for this PR where you can easily examine the code I'll have to do more work.

[Bug rtl-optimization/48064] New: Optimizer produces suboptimal code for e.g. x = x ^ (x >> 1)

[jasper.neumann at web dot de]

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

   Summary: Optimizer produces suboptimal code for e.g. x = x ^ (x
>> 1)
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jasper.neum...@web.de
Target: windows 32


When I compile the following OPT.CPP with gcc 4.5.2 (mingw) under Windows-32...
===
int test(int x)
{
   x = x ^ (x >> 1);

   int x1=x;
   x = x >> 2;
   x = x ^ x1;

   return x;
}
===

...a call to
gpp -O3 -S OPT.CPP
produces this OPT.s:
===
 .file   "OPT.CPP"
 .text
 .p2align 2,,3
.globl __Z4testi
 .def__Z4testi;  .scl2;  .type   32; .endef
__Z4testi:
LFB0:
 pushl   %ebp
LCFI0:
 movl%esp, %ebp
LCFI1:
 movl8(%ebp), %eax
 movl%eax, %edx
 sarl%edx
 xorl%eax, %edx
 movl%edx, %eax
 sarl$2, %eax
 xorl%edx, %eax
 leave
LCFI2:
 ret
LFE0:
===

The problem I see is that in
 movl%eax, %edx
 sarl%edx
 xorl%eax, %edx

 movl%edx, %eax
 sarl$2, %eax
 xorl%edx, %eax
gcc produces code which presumably costs 6 cycles
(edx and then eax is modified 3 times in a row)
whereas the equivalent statements
 movl%eax, %edx
 sarl%eax
 xorl%eax, %edx

 movl%edx, %eax
 sarl$2, %edx
 xorl%edx, %eax
cost only 4 cycles since the mov and the shift can go in parallel.
I would have expected this at least for explicit form in
   int x1=x;
   x = x >> 2;
   x = x ^ x1;
I found no way to get gcc to output my version.

A speed test reveals that the proposed form only costs about
2/3 of the time on Intel Atom N450 and 3/4 of the time on Intel i7.

Have I missed something?


By the way: If I produce an output in Intel syntax
the statement "sar eax" should be "sar eax,1".
Otherwise some assemblers will complain.

[Bug tree-optimization/44897] -flto + ipa-sra misoptimize sqlite (non-plugin only)

[markus at trippelsdorf dot de]

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

--- Comment #14 from Markus Trippelsdorf  
2011-03-10 19:13:55 UTC ---
And the same with debugging symbols:

Program received signal SIGFPE, Arithmetic exception.
[Switching to process 5046]
0x0086d41c in cgraph_decide_recursive_inlining
(new_edges=0x7fffd750, node=0x765dbb00) at
../../gcc/gcc/ipa-inline.c:906
906   if (curr->count * 100 / node->count < probability)
(gdb) bt
#0  0x0086d41c in cgraph_decide_recursive_inlining
(new_edges=0x7fffd750, node=0x765dbb00) at
../../gcc/gcc/ipa-inline.c:906
#1  cgraph_decide_inlining_of_small_functions () at
../../gcc/gcc/ipa-inline.c:1193
#2  cgraph_decide_inlining () at ../../gcc/gcc/ipa-inline.c:1479
#3  0x006571e9 in execute_one_pass (pass=0x102ee00) at
../../gcc/gcc/passes.c:1556
#4  0x0065787a in execute_ipa_pass_list (pass=0x102ee00) at
../../gcc/gcc/passes.c:1923
#5  0x004c152f in do_whole_program_analysis () at
../../gcc/gcc/lto/lto.c:2350
#6  lto_main () at ../../gcc/gcc/lto/lto.c:2462
#7  0x006e7510 in compile_file () at ../../gcc/gcc/toplev.c:579
#8  do_compile () at ../../gcc/gcc/toplev.c:1900
#9  toplev_main (argc=40, argv=0x11679c0) at ../../gcc/gcc/toplev.c:1963
#10 0x76d28f8d in __libc_start_main () from /lib/libc.so.6
#11 0x004a9979 in _start () at ../sysdeps/x86_64/elf/start.S:113
(gdb)

[Bug tree-optimization/48063] [4.6 Regression] ICE: verify_stmts failed: conversion of register to a different size with -fno-early-inlining

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-03-10 
19:09:49 UTC ---
Created attachment 23617
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23617
gcc46-pr48063.patch

This seems to fix it, but no idea whether it is the right fix.

It seems all other places that check call_stmt_cannot_inline_p also call
tree_can_inline_p though.

[Bug tree-optimization/48063] [4.6 Regression] ICE: verify_stmts failed: conversion of register to a different size with -fno-early-inlining

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2011-03-10 
18:55:08 UTC ---
I think the bug is that with -O -fno-early-inlining tree_can_inline_p
is never called and thus nothing finds out there is argument mismatch.

Honza?

[Bug tree-optimization/48063] [4.6 Regression] ICE: verify_stmts failed: conversion of register to a different size with -fno-early-inlining

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  2011-03-10 
18:50:19 UTC ---
Again caused by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161655
setup_one_parameter has:
  if (value
  && value != error_mark_node
  && !useless_type_conversion_p (TREE_TYPE (p), TREE_TYPE (value)))
{
  if (fold_convertible_p (TREE_TYPE (p), value))
rhs = fold_build1 (NOP_EXPR, TREE_TYPE (p), value);
  else
/* ???  For valid (GIMPLE) programs we should not end up here.
   Still if something has gone wrong and we end up with truly
   mismatched types here, fall back to using a VIEW_CONVERT_EXPR
   to not leak invalid GIMPLE to the following passes.  */
rhs = fold_build1 (VIEW_CONVERT_EXPR, TREE_TYPE (p), value);
}
which obviously can't work when the VCE is invalid.  We really shouldn't be
trying to inline in that case.

[Bug rtl-optimization/33928] [4.3/4.4/4.5/4.6 Regression] 30% performance slowdown in floating-point code caused by r118475

[lucier at math dot purdue.edu]

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

--- Comment #118 from lucier at math dot purdue.edu 2011-03-10 18:50:12 UTC ---
On Fri, 2011-03-04 at 11:59 +, rguenth at gcc dot gnu.org wrote:

> Hm, there doesn't seem to be a runtime testcase attached to this bug, so I
> can't produce numbers for the upcoming 4.6 release.  Brad, can you do so
> if you have time?

At 

http://www.math.purdue.edu/~lucier/bugzilla/14/

is a Readme file and a tarball; I think it should be easy to script a
runtime test for this PR from the instructions in the Readme file.

Later we'll devise a "make bench" for general Gambit benchmarking.

Brad

[Bug c/48062] `shadowed declaration is here' should be a note

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.10 18:44:34
 CC||manu at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  2011-03-10 
18:44:34 UTC ---
This is a one liner that would qualify as obvious and it won't require
copyright assignment. Feel free to submit a patch!

(but it probably requires to adjust testcases, so run the testsuite and look
for new failures)

[Bug tree-optimization/44897] -flto + ipa-sra misoptimize sqlite (non-plugin only)

[markus at trippelsdorf dot de]

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

--- Comment #13 from Markus Trippelsdorf  
2011-03-10 18:39:21 UTC ---
Here's what I got:
(gdb) set follow-fork-mode child
(gdb) run -plugin /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/liblto_plugin.so
-plugin-opt=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccZJwWXj.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lpthread
-plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -flto --eh-frame-hdr -m elf_x86_64 -shared -o
libmozsqlite3.so
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/crtbeginS.o
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/../../.. -z defs -h libmozsqlite3.so
sqlite3.o -lpthread --hash-style=gnu -rpath-link
/var/tmp/mozilla-central/moz-build-dir/dist/bin -rpath-link /usr/lib -ldl -lgcc
--as-needed -lgcc_s --no-as-needed -lpthread -lc -lgcc --as-needed -lgcc_s
--no-as-needed /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/crtendS.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64/crtn.o
Starting program: /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/collect2 -plugin
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/liblto_plugin.so
-plugin-opt=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccZJwWXj.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lpthread
-plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -flto --eh-frame-hdr -m elf_x86_64 -shared -o
libmozsqlite3.so
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/crtbeginS.o
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/../../.. -z defs -h libmozsqlite3.so
sqlite3.o -lpthread --hash-style=gnu -rpath-link
/var/tmp/mozilla-central/moz-build-dir/dist/bin -rpath-link /usr/lib -ldl -lgcc
--as-needed -lgcc_s --no-as-needed -lpthread -lc -lgcc --as-needed -lgcc_s
--no-as-needed /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/crtendS.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64/crtn.o
[New process 16093]
process 16093 is executing new program:
/usr/x86_64-pc-linux-gnu/binutils-bin/2.21.51.0.7/ld
[New process 16102]
process 16102 is executing new program:
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/lto-wrapper
[New process 16103]
process 16103 is executing new program:
/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.0/gcc
[New process 16104]
process 16104 is executing new program:
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/lto1

Program received signal SIGFPE, Arithmetic exception.
[Switching to process 16104]
0x00862ca7 in ?? ()
(gdb) bt
#0  0x00862ca7 in ?? ()
#1  0x0066f176 in execute_one_pass(opt_pass*) ()
#2  0x0066fa52 in execute_ipa_pass_list(opt_pass*) ()
#3  0x004f284e in lto_main() ()
#4  0x006fc247 in toplev_main(int, char**) ()
#5  0x76d28f8d in __libc_start_main () from /lib/libc.so.6
#6  0x004cd9f9 in _start ()
(gdb)

[Bug tree-optimization/48063] New: [4.6 Regression] ICE: verify_stmts failed: conversion of register to a different size with -fno-early-inlining

[zsojka at seznam dot cz]

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

   Summary: [4.6 Regression] ICE: verify_stmts failed: conversion
of register to a different size with
-fno-early-inlining
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
CC: ja...@gcc.gnu.org
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 23616
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23616
preprocessed gcc.c-torture/compile/pr47967.c

Testcase is the same as for PR47967.

Compiler output:
$ gcc gcc.c-torture/compile/pr47967.c -O -fno-early-inlining 
gcc.c-torture/compile/pr47967.c: In function 'foo':
gcc.c-torture/compile/pr47967.c:7:1: error: conversion of register to a
different size
VIEW_CONVERT_EXPR(D.2694_3);

i_2 = VIEW_CONVERT_EXPR(D.2694_3);

gcc.c-torture/compile/pr47967.c:7:1: internal compiler error: verify_stmts
failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

(gdb) bt
#0  error (gmsgid=0x116d6a0 "conversion of register to a different size") at
/mnt/svn/gcc-trunk/gcc/diagnostic.c:747
#1  0x008ea08c in verify_types_in_gimple_reference
(expr=0x75ba1fc0, require_lvalue=0 '\000') at
/mnt/svn/gcc-trunk/gcc/tree-cfg.c:2953
#2  0x008eb01d in verify_gimple_assign_single (stmt=) at /mnt/svn/gcc-trunk/gcc/tree-cfg.c:3755
#3  verify_gimple_assign (stmt=) at
/mnt/svn/gcc-trunk/gcc/tree-cfg.c:3824
#4  verify_types_in_gimple_stmt (stmt=) at
/mnt/svn/gcc-trunk/gcc/tree-cfg.c:3984
#5  0x008f35bf in verify_stmts () at
/mnt/svn/gcc-trunk/gcc/tree-cfg.c:4386
#6  0x00a094cd in verify_ssa (check_modified_stmt=1 '\001') at
/mnt/svn/gcc-trunk/gcc/tree-ssa.c:878
#7  0x007f3e49 in execute_function_todo (data=) at
/mnt/svn/gcc-trunk/gcc/passes.c:1240
#8  0x007f453d in execute_todo (flags=2132516) at
/mnt/svn/gcc-trunk/gcc/passes.c:1271
#9  0x007f68cb in execute_one_ipa_transform_pass () at
/mnt/svn/gcc-trunk/gcc/passes.c:1463
#10 execute_all_ipa_transforms () at /mnt/svn/gcc-trunk/gcc/passes.c:1487
#11 0x00939d2d in tree_rest_of_compilation (fndecl=0x75ba2100) at
/mnt/svn/gcc-trunk/gcc/tree-optimize.c:415
#12 0x00b01e72 in cgraph_expand_function (node=0x75ba5000) at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1576
#13 0x00b045ba in cgraph_expand_all_functions () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1635
#14 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1899
#15 0x00b04b3a in cgraph_finalize_compilation_unit () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1096
#16 0x005097bc in c_write_global_declarations () at
/mnt/svn/gcc-trunk/gcc/c-decl.c:9872
#17 0x008e2cd8 in compile_file (argc=14, argv=0x7fffdb48) at
/mnt/svn/gcc-trunk/gcc/toplev.c:591
#18 do_compile (argc=14, argv=0x7fffdb48) at
/mnt/svn/gcc-trunk/gcc/toplev.c:1900
#19 toplev_main (argc=14, argv=0x7fffdb48) at
/mnt/svn/gcc-trunk/gcc/toplev.c:1963
#20 0x76445bbd in __libc_start_main () from /lib/libc.so.6
#21 0x004f0369 in _start ()

Tested revisions:
r170814 - crash
4.5 r170013 - OK

[Bug debug/48043] [4.6 Regression] pr47201: var-tracking loc_order_check fails for type punning examples

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #9 from Jakub Jelinek  2011-03-10 
18:16:33 UTC ---
Fixed.

[Bug debug/48043] [4.6 Regression] pr47201: var-tracking loc_order_check fails for type punning examples

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  2011-03-10 
18:10:19 UTC ---
Author: jakub
Date: Thu Mar 10 18:10:14 2011
New Revision: 170851

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170851
Log:
PR debug/48043
* config/s390/s390.c (s390_delegitimize_address): Make sure the 
result mode matches original rtl mode.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/s390/s390.c

[Bug c++/46824] chromium-compile failed because error: no match for ‘operator*’ in

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2011-03-10 
18:08:52 UTC ---
really reduced:

class Incomplete;

struct Ptr
{
  operator Incomplete*();
};

int main()
{
  Ptr p;

  *p;
}

[Bug c++/46824] chromium-compile failed because error: no match for ‘operator*’ in

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2011-03-10 
18:04:03 UTC ---
Reduced:

template 
struct scoped_refptr {

  operator T*() const;
};


class EventParameters  { };

class HttpResponseHeaders;


struct NetLogHttpResponseParameter : public EventParameters {

  const HttpResponseHeaders& GetHeaders() const {
return *headers_;
  }


  scoped_refptr headers_;

};


EDG rejects this with the same error. Clang accepts it.

[Bug tree-optimization/47278] [4.3/4.4 Regression] hidden weak function not handled properly

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #5 from John David Anglin  2011-03-10 
17:26:49 UTC ---
I see on 4.5.3 on hppa2.0w-hp-hpux11.11:

FAIL: gcc.dg/torture/pr47278-1.c  -O0  (test for excess errors)
Excess errors:
/mnt/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr47278-2.c:6:1: warning:
visibili
ty attribute not supported in this configuration; ignored

[Bug c++/46824] chromium-compile failed because error: no match for ‘operator*’ in

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||dodji at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  2011-03-10 
17:20:05 UTC ---
This started being rejected with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167250
I'll let Dodji/Jason comment on whether the testcase is valid or not.

[Bug target/46329] ICE on ARM for __attribute__ ((vector_size (8 * sizeof(int)))) operations

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 CC||mgretton at sourceware dot
   ||org

--- Comment #2 from Richard Earnshaw  2011-03-10 
16:59:33 UTC ---
*** Bug 48061 has been marked as a duplicate of this bug. ***

[Bug target/46329] ICE on ARM for __attribute__ ((vector_size (8 * sizeof(int)))) operations

[rearnsha at gcc dot gnu.org]

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

--- Comment #3 from Richard Earnshaw  2011-03-10 
17:00:10 UTC ---
Another test (from the dup).

int __attribute__ ((vector_size (32))) x;
void
foo (void)
{
  x <<= x;
}

[Bug target/48061] Internal compiler error in spill_failure

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Richard Earnshaw  2011-03-10 
16:59:33 UTC ---
Essentially the same problem as 46329.

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

[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #38 from dave at hiauly1 dot hia.nrc.ca 2011-03-10 16:58:38 UTC ---
> While the latter is fixed, I think the _REENTRANT issue isn't. Or is it?
> 
> If it it not fixed, I think we should have (a different) PR open to track that
> issue. Dave, you wrote you were testing a patch for _REENTRANT ...

Correct, I have a patch which I have been testing.  While it seems to
work, there is one issue that I don't particularly like.

`-threads' is a multilib option handled completely by the gcc driver.
It is not passed to the standard option processing, so I wasn't able
to find a way to check for `-threads' in TARGET_OS_CPP_BUILTINS.
Currently, I define  _REENTRANT whenever we define _HPUX_SOURCE in
TARGET_OS_CPP_BUILTINS.  It is also defined by CPP_SPEC when -threads
is specified.  As a result, there are some situations where _REENTRANT
is effectively defined twice.

This could be avoided if _REENTRANT was only defined in CPP_SPEC but
it is difficult to duplicate the option handling in TARGET_OS_CPP_BUILTINS.

Since I haven't seen any actual problems with the current patch, I think
I will commit it tonight.

Dave

[Bug testsuite/48055] FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation, -O2 -flto

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #7 from Uros Bizjak  2011-03-10 16:51:35 
UTC ---
Linker bug, see also [1].

[1] http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00521.html

[Bug c/48062] New: `shadowed declaration is here' should be a note

[d.g.gorbachev at gmail dot com]

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

   Summary: `shadowed declaration is here' should be a note
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d.g.gorbac...@gmail.com


cat > main.c
int i;

int main(void)
{
  int i = 0;
  return i;
}
^D
$ gcc -Wshadow main.c
main.c: In function 'main':
main.c:5:7: warning: declaration of 'i' shadows a global declaration [-Wshadow]
main.c:1:5: warning: shadowed declaration is here [-Wshadow]

[Bug tree-optimization/44897] -flto + ipa-sra misoptimize sqlite (non-plugin only)

[hubicka at ucw dot cz]

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

--- Comment #12 from Jan Hubicka  2011-03-10 16:26:01 
UTC ---
> gcc -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -W -pedantic
> -Wno-long-long -march=native -fpermissive -fno-strict-aliasing -pthread -pipe
> -DNDEBUG -DTRIMMED -Wcoverage-mismatch -freorder-blocks-and-partition -flto 
> -O3
> -fPIC -shared -Wl,-z,defs -Wl,-h,libmozsqlite3.so -o libmozsqlite3.so 
> sqlite3.o
> -lpthread -Wl,-O1,--hash-style=gnu,--as-needed,--no-keep-memory
> -Wl,-rpath-link,/var/tmp/mozilla-central/moz-build-dir/dist/bin
> -Wl,-rpath-link,/usr/lib -ldl
> lto1: internal compiler error: Floating point exception

This should be easy to fix. Having backtrace would save me from some burden
trying to reproduce it ;)

Honza

[Bug tree-optimization/44897] -flto + ipa-sra misoptimize sqlite (non-plugin only)

[markus at trippelsdorf dot de]

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

--- Comment #11 from Markus Trippelsdorf  
2011-03-10 16:07:34 UTC ---
In the Firefox case sqlite3.o gets compiled correctly,
it is libmozsqlite3.so that segfaults when compiled with -flto
and -fprofile-use :

gcc  -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -W -pedantic
-Wno-long-long -march=native -fpermissive -fno-strict-aliasing -pthread -pipe 
-DNDEBUG -DTRIMMED -flto=4 -fwhole-program -fprofile-use -fprofile-correction
-Wcoverage-mismatch -freorder-blocks-and-partition -O3 -fPIC -shared
-Wl,-z,defs -Wl,-h,libmozsqlite3.so -o libmozsqlite3.so  sqlite3.o
-lpthread -Wl,-O1,--hash-style=gnu,--as-needed,--no-keep-memory  -fprofile-use
-Wl,-rpath-link,/var/tmp/mozilla-central/moz-build-dir/dist/bin
-Wl,-rpath-link,/usr/lib   -ldl

This version runs fine (no -flto):

gcc -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -W -pedantic
-Wno-long-long -march=native -fpermissive -fno-strict-aliasing -pthread -pipe
-DNDEBUG -DTRIMMED -Wcoverage-mismatch -freorder-blocks-and-partition
-fwhole-program -fprofile-use -O3 -fPIC -shared -Wl,-z,defs
-Wl,-h,libmozsqlite3.so -o libmozsqlite3.so sqlite3.o -lpthread
-Wl,-O1,--hash-style=gnu,--as-needed,--no-keep-memory
-Wl,-rpath-link,/var/tmp/mozilla-central/moz-build-dir/dist/bin
-Wl,-rpath-link,/usr/lib -ldl

And this one gives an internal compiler error (only -flto , no -fprofile-use):

gcc -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -W -pedantic
-Wno-long-long -march=native -fpermissive -fno-strict-aliasing -pthread -pipe
-DNDEBUG -DTRIMMED -Wcoverage-mismatch -freorder-blocks-and-partition -flto -O3
-fPIC -shared -Wl,-z,defs -Wl,-h,libmozsqlite3.so -o libmozsqlite3.so sqlite3.o
-lpthread -Wl,-O1,--hash-style=gnu,--as-needed,--no-keep-memory
-Wl,-rpath-link,/var/tmp/mozilla-central/moz-build-dir/dist/bin
-Wl,-rpath-link,/usr/lib -ldl
lto1: internal compiler error: Floating point exception
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: /usr/x86_64-pc-linux-gnu/gcc-bin/4.6.0/gcc returned 1 exit status
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/bin/ld:
fatal error: lto-wrapper failed
collect2: ld returned 1 exit status

(All these commands should be run from: 
./mozilla-central/moz-build-dir/db/sqlite3/src
One can copy the resulting libmozsqlite3.so directly into 
/usr/lib/firefox-4.0b13pre and try to start Firefox, to check
if it's OK or not)

[Bug bootstrap/48000] [4.6 Regression] LTO bootstrap failed with bootstrap-profiled

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||y...@momonga-linux.org

--- Comment #9 from Jakub Jelinek  2011-03-10 
15:24:33 UTC ---
*** Bug 48060 has been marked as a duplicate of this bug. ***

[Bug c/48060] internal compiler error: in dfs_enumerate_from, at cfganal.c:1209

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution||DUPLICATE

--- Comment #1 from Jakub Jelinek  2011-03-10 
15:24:33 UTC ---
Already fixed.

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

[Bug fortran/48058] [4.6 Regression] reallocation of array during constructor assignement

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org 2011-03-10 15:24:29 UTC ---
(In reply to comment #2)
> Somehow, I've missed this in ChangeLog. Sorry for the noise

ChangeLog is a horrible place to look at the new features
in gfortran.  It would be better to look on the gfortran
wiki.

http://gcc.gnu.org/wiki/GFortran#news

[Bug c++/47198] [4.5/4.6 Regression] [C++0x] ICE: tree check: expected var_decl or function_decl, have template_decl in check_bases_and_members, at cp/class.c:4654 on invalid code

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  2011-03-10 
15:21:04 UTC ---
Author: jason
Date: Thu Mar 10 15:21:00 2011
New Revision: 170847

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170847
Log:
PR c++/47198
* parser.c (cp_parser_single_declaration): Just return if
cp_parser_parse_and_diagnose_invalid_type_name complained.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/syntax-err1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/parse/error36.C
trunk/gcc/testsuite/g++.old-deja/g++.pt/ctor2.C
trunk/gcc/testsuite/g++.old-deja/g++.pt/typename3.C
trunk/gcc/testsuite/g++.old-deja/g++.pt/typename4.C
trunk/gcc/testsuite/g++.old-deja/g++.pt/typename6.C

[Bug target/48061] Internal compiler error in spill_failure

[mgretton at sourceware dot org]

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

Matthew Gretton-Dann  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #1 from Matthew Gretton-Dann  
2011-03-10 15:06:58 UTC ---
Also occurs with -mfloat-abi=softfp

[Bug target/48061] New: Internal compiler error in spill_failure

[mgretton at sourceware dot org]

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

   Summary: Internal compiler error in spill_failure
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mgret...@sourceware.org
CC: ramana.radhakrish...@arm.com
Target: arm-none-eabi


Created attachment 23615
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23615
Test case for bug

Compiling the attached test case (based on
gcc/testsuite/gcc.dg/torture/pr47975.c) produces an internal compiler error in
spill_failure.

arm-eabi-gcc -O2 -mfloat-abi=hard -mcpu=cortex-a9 -mfpu=neon test.i produces:

test.c: In function 'foo':
test.c:7:1: error: unable to find a register to spill in class 'GENERAL_REGS'
test.c:7:1: error: this is the insn:
(insn 18 5 6 2 (set (reg:OI 154)
(const_int 0 [0])) test.c:6 751 {*neon_movoi}
 (expr_list:REG_EQUAL (const_int 0 [0])
(nil)))
test.c:7:1: internal compiler error: in spill_failure, at reload1.c:2105
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

arm-eabi-gcc -v produces the following output:
Using built-in specs.
COLLECT_GCC=.../bin/arm-eabi-gcc
COLLECT_LTO_WRAPPER=.../bin/../libexec/gcc/arm-eabi/4.6.0/lto-wrapper
Target: arm-eabi
Configured with: .../configure --target=arm-eabi --enable-checking=release
--disable-gdbtk --disable-werror --disable-tui --disable-rda --disable-sid
--disable-utils --disable-lto --with-cpu=cortex-a9 --with-float=softfp
--with-fpu=neon --disable-lto --disable-werror --disable-shared --disable-nls
--disable-threads --disable-tls --enable-checking=yes
--enable-languages=c,c++,fortran --with-newlib
Thread model: single
gcc version 4.6.0 20110309 (experimental) (GCC)

[Bug testsuite/48055] FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation, -O2 -flto

[ubizjak at gmail dot com]

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

--- Comment #6 from Uros Bizjak  2011-03-10 14:39:57 
UTC ---
(In reply to comment #5)
> > No, these are the only definitions for the particular testcase.
> Hmm, in every case it is GNU ld bug - the GNU ld internal ironly section 
> should
> not be leaking
> to user warnings. Please fill in GNU ld PR.

Submitted as binutils PR 12564.

Anyway, should the patch be committed to gcc testsuite, since it doesn't change
the test and avoids the linker bug at the same time?

[1] http://sourceware.org/bugzilla/show_bug.cgi?id=12564

[Bug debug/48043] [4.6 Regression] pr47201: var-tracking loc_order_check fails for type punning examples

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  2011-03-10 
14:37:39 UTC ---
If there isn't a mode mismatch in the instruction stream, then no.
The problem is that because of the delegitimizate address bug adjust_insn
in var-tracking (temporarily) changed the insn into
(set (reg:SF ...) (symbol_ref:SI ...))
(SET_SRC coming from delegitimizing a (mem:SF ...)) and var-tracking not
expecting mode mismatches.
If there is (set (reg:SF ...) (subreg:SF (reg:SI ...))) or something similar,
var-tracking ought to handle it correctly, sorry for the false alarm in #c3, I
wrote it without looking carefully into it.

Thanks for testing the patch, I'll post it to gcc-patches momentarily.

[Bug fortran/48058] [4.6 Regression] reallocation of array during constructor assignement

[xarthisius.kk at gmail dot com]

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

Kacper Kowalik  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Kacper Kowalik  2011-03-10 
14:34:21 UTC ---
Somehow, I've missed this in ChangeLog. Sorry for the noise

[Bug debug/48043] [4.6 Regression] pr47201: var-tracking loc_order_check fails for type punning examples

[krebbel at gcc dot gnu.org]

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

--- Comment #6 from Andreas Krebbel  2011-03-10 
14:27:19 UTC ---
(In reply to comment #5)
> Created attachment 23608 [details]
> gcc46-pr48043.patch
> 
> Fix (tested just with cross on the pr47201.c testcase).  Could you please
> bootstrap/regtestit, it might take a while for me to test it on s390x.

Done. Bootstraps fine on s390 and s390x. No regression. The testcase is fixed
with this.

But your fix only applies if the mode mismatch comes from an address. Wouldn't
it be possible to trigger this situation with a normal value not going through
delegitimize_address?

[Bug c++/47952] [trans-mem] undefined reference to transaction clone

[patrick.marlier at gmail dot com]

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

--- Comment #12 from Patrick Marlier  
2011-03-10 14:19:35 UTC ---
On 03/10/2011 12:01 AM, rth at gcc dot gnu.org wrote:
> I suspect, but have not yet verified, that this is related to
>// Inhibit implicit instantiations for required instantiations,
>// which are defined via explicit instantiations elsewhere.
>// NB: This syntax is a GNU extension.
> #if _GLIBCXX_EXTERN_TEMPLATE>  0
>extern template class basic_string;
>
> in that we're copying the "is extern" bit, which is not true for
> the transactional clone.

I don't know if it is related but I have another bug which may be 
related with template.

In a relaxed transaction, some functions (stl? template?) in a 
transaction doesn't call the clone version (nor call to 
ITM_changeTransactionMode).
You can verify this in the function stepDestroyBuildings 
(_ZL20stepDestroyBuildingsi) in src/Tean.cpp, the function 
_ZNSt4listIP8BuildingSaIS1_EE5beginEv is called directly (not the clone, 
no irrevocable mode) even if in a transaction.

I had a quick look and the clone function exists but seems not be 
replaced (the begin attribute doesn't say irrevocable and no 
changeMode). It seems to happen when one transaction is followed by 
another one (Not sure if it is the cause)

I would like to have a look at it but I will be on vacation next week 
and I have to finish urgent things...

(I have added Aldy as CC since he also has glob2 and it might interest him)

Should I fill a new PR for this even if I don't have any real testcase?

Thanks.
Patrick.

[Bug fortran/48058] [4.6 Regression] reallocation of array during constructor assignement

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||bur...@net-b.de, pault at
   ||gcc dot gnu.org

--- Comment #1 from Dominique d'Humieres  2011-03-10 
14:07:49 UTC ---
> Assigning [...] constructor to allocatable array changes size of that array, 
> if
> size([...]) is not equal to size(array)

As far as I understand "reallocation on assignment, this is the expected
behavior (default that you can override with -fno-realloc-lhs).

There may be a missing error in

[macbook] f90/bug% gfc -fno-realloc-lhs -fcheck=all pr48058.f90
[macbook] f90/bug% a.out
   3
   3

where a length 2 vector is assigned to a length 3 one(?).

[Bug fortran/48059] [OOP] ICE in in gfc_conv_component_ref: character function of extended type

[boschmann at tp1 dot physik.uni-siegen.de]

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

--- Comment #2 from Hans-Werner Boschmann  2011-03-10 14:06:06 UTC ---
I have removed this character function from my project and found the same ICE
message with other, non character-valued functions of extended types. So it
seems to be a more general problem then character-valued functions.

[Bug c/48060] New: internal compiler error: in dfs_enumerate_from, at cfganal.c:1209

[y...@momonga-linux.org]

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

   Summary: internal compiler error: in dfs_enumerate_from, at
cfganal.c:1209
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: y...@momonga-linux.org


gcc 4.6.0 20110305 ICEs with "-O3" when using the following code;




typedef struct  {
  unsigned long status;
} Table;

extern Table* table;
extern void func2(Table *p);

int func(int a)
{
  while (a) {
unsigned long b;
Table *p;

p = &table[b];

if (!p || (p->status & (b))) {
  p = 0;
}
if (p && p->status) {
  func2(p);
}
  }
  return 1;
}

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[mikpe at it dot uu.se]

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

--- Comment #15 from Mikael Pettersson  2011-03-10 
14:03:22 UTC ---
(In reply to comment #14)
> Created attachment 23614 [details]
> patch
> 
> testing appreciated

Thanks, fixes the ICE in 4.5 and 4.4 crosses to m68k-linux.  I'm starting
native 4.6/4.5/4.4 bootstraps and test suite runs today, expect results in 4-5
days.

(I'm running them in parallel on three machines.  A languages=c,c++
checking=release bootstrap+regtest does unfortunately take that long.)

[Bug target/47989] -mrecip causes 482.sphinx3, 464.h264ref and 481.wrf to miscompare

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  2011-03-10 
14:01:25 UTC ---
A similar problem occurs with the polyhedron test aermod.f90 (see pr34702).

> Feeding rcps sequences into call stmts is probably never a very good idea.

Probably the same thing for tests.

> In all cases the Intel compiler simply only uses rcp instructions for
> vectorized loops.

I think this would be a good idea, however the last time I have looked at it
(some time ago!-), gcc was not as good as intel to vectorize rcp.

[Bug fortran/48059] [OOP] ICE in in gfc_conv_component_ref: character function of extended type

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.10 13:54:15
 Ever Confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  2011-03-10 
13:54:15 UTC ---
The ICE appeared between revisions 169790 and 170493.

[Bug fortran/48059] New: [OOP] ICE in in gfc_conv_component_ref: character function of extended type

[boschmann at tp1 dot physik.uni-siegen.de]

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

   Summary: [OOP] ICE in in gfc_conv_component_ref: character
function of extended type
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: boschm...@tp1.physik.uni-siegen.de


The code:
module a_module
  type :: a_type
 integer::length=0
  end type a_type
  type,extends(a_type) :: b_type
  end type b_type
contains
  function a_string(this) result(form)
class(a_type),intent(in)::this
character(max(1,this%length))::form
  end function a_string
  subroutine b_sub(this)
class(b_type),intent(inout),target::this
print *,a_string(this)
  end subroutine b_sub
end module a_module

The ICE message:
a.f90: In Funktion »b_sub«:
a.f90:14:0: interner Compiler-Fehler: in gfc_conv_component_ref, bei
fortran/trans-expr.c:523

Fortran version:
GNU Fortran (GCC) 4.6.0 20110310 (experimental)

I know that the length specification in a_string is a little bit creepy, but it
is valid. I had a discussion with the NAG about this before and they decided to
give a "questionable" warning message but no error message.

It anyway went right until today. I have updated gfortran and got this ICE for
the first time although the code is a few months old now. Unfortunately, I'm
not totally sure when I have done the last update before.

[Bug target/47989] -mrecip causes 482.sphinx3, 464.h264ref and 481.wrf to miscompare

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

Summary|-mrecip causes 482.sphinx3  |-mrecip causes 482.sphinx3,
   |and 464.h264ref to  |464.h264ref and 481.wrf to
   |miscompare  |miscompare

--- Comment #2 from Richard Guenther  2011-03-10 
13:27:22 UTC ---
Same for 481.wrf, hope for dealing with this with taking into account context
of the division vanishes here.  The code is obfuscated with several
levels of array lookup.

In all cases the Intel compiler simply only uses rcp instructions for
vectorized loops.

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Guenther  2011-03-10 
13:10:23 UTC ---
Created attachment 23614
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23614
patch

testing appreciated

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[rguenther at suse dot de]

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

--- Comment #13 from rguenther at suse dot de  
2011-03-10 13:07:16 UTC ---
On Thu, 10 Mar 2011, ebotcazou at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48031
> 
> --- Comment #12 from Eric Botcazou  2011-03-10 
> 13:04:17 UTC ---
> > That would work, too.  You see no problem with a NULL operand 3
> > of array-refs?  If you create an array with a variable lower bound,
> > take its address, convert it to pointer to element type and
> > dereference that, would it expand ok if it does not have the
> > element size set properly?  At least get_inner_reference seems to
> > unconditionally multiply with array_ref_element_size () * index,
> > and array_ref_element_size () does not work for variable-size types
> > if the array-ref doesn't have the gimplified value.
> 
> Isn't gimplification supposed to populate this operand #3?

Ugh, yeah it does - but, do we really rely on this?  Probably yes ...
so setting operand #2 in the folder is not necessary either.

Ok, I'll go with the in_gimple_form check.

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[ebotcazou at gcc dot gnu.org]

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

--- Comment #12 from Eric Botcazou  2011-03-10 
13:04:17 UTC ---
> That would work, too.  You see no problem with a NULL operand 3
> of array-refs?  If you create an array with a variable lower bound,
> take its address, convert it to pointer to element type and
> dereference that, would it expand ok if it does not have the
> element size set properly?  At least get_inner_reference seems to
> unconditionally multiply with array_ref_element_size () * index,
> and array_ref_element_size () does not work for variable-size types
> if the array-ref doesn't have the gimplified value.

Isn't gimplification supposed to populate this operand #3?

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de  
2011-03-10 12:57:59 UTC ---
On Thu, 10 Mar 2011, ebotcazou at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48031
> 
> --- Comment #10 from Eric Botcazou  2011-03-10 
> 12:46:33 UTC ---
> > No it isn't.  But given that fold at this place doesn't even
> > fill in the array-ref element-size slot but provides NULL_TREE
> > it is probably a fix for the better anyway?
> 
> Why not explicitly test in_gimple_form like in other places in the folder?

That would work, too.  You see no problem with a NULL operand 3
of array-refs?  If you create an array with a variable lower bound,
take its address, convert it to pointer to element type and
dereference that, would it expand ok if it does not have the
element size set properly?  At least get_inner_reference seems to
unconditionally multiply with array_ref_element_size () * index,
and array_ref_element_size () does not work for variable-size types
if the array-ref doesn't have the gimplified value.

You can probably come up with an Ada testcase that gets miscompiled?
(C arrays always have a lower bound of zero, thus the index
will be zero thus the multiplication ensures that the garbage
returned by array_ref_element_size is thrown away).

Richard.

[Bug testsuite/48055] FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation, -O2 -flto

[hubicka at ucw dot cz]

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

--- Comment #5 from Jan Hubicka  2011-03-10 12:56:56 UTC 
---
> No, these are the only definitions for the particular testcase.
Hmm, in every case it is GNU ld bug - the GNU ld internal ironly section should
not be leaking
to user warnings. Please fill in GNU ld PR.

Honza

Re: [Bug testsuite/48055] FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation, -O2 -flto

[Jan Hubicka]

> No, these are the only definitions for the particular testcase.
Hmm, in every case it is GNU ld bug - the GNU ld internal ironly section should 
not be leaking
to user warnings. Please fill in GNU ld PR.

Honza

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[hubicka at ucw dot cz]

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

--- Comment #59 from Jan Hubicka  2011-03-10 12:53:58 
UTC ---
> > How do you do this with "make -f client.mk profiledbuild"?
> 
> To answer my own question:
> Just edit ./configure and ./js/src/configure and add
> "-flto=4 -fwhole-program" (or whatever you may prefer)
> to the PROFILE_USE_CFLAGS variable.
> Then you can build Firefox with "make -f client.mk profiledbuild".

I did not know of existence of profiledbuild and thus I did that by hand
where it was easy.
Perhaps Mozilla build mahcinery can be told to add -fno-lto into
-fprofile-generate
run.  Hmm, in fact perhaps GCC chould do that by default. Not sure if it is not
too
late for 4.6 however.
> 
> BTW libmozsqlite3.so still gets miscompiled, but Firefox is 
> now snappy as never before ;-)

yes, there is PR on this, but I have absolutely no idea if it is sqlite or GCC
bug.
Any help is greatly appreciated, sqlite is big blob of magic for me.

[Bug middle-end/48044] [4.6 Regression] ICE in function_and_variable_visibility, at ipa.c:875

[hubicka at ucw dot cz]

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

--- Comment #4 from Jan Hubicka  2011-03-10 12:51:19 UTC 
---
> I wonder if cgraph_remove_unreachable_nodes shouldn't be somehow alias pairs
> aware (can it e.g. call find_aliases_1 again?), or at least for !optimize
> shouldn't it avoid clearing vnode->needed for vnode->force_output?

I guess the second (probably even when optimizing).  The idea of alias pair
handling in current cgraph is to pretend they do not exist and have the code
in visibility pass marking them force_output and thus disabling much of
optimization
around them.

For 4.7 we need to rewrite this in favour of proper symbol table that is quite
some
effort to do ;(

I will look into this today.
Honza

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou  2011-03-10 
12:46:33 UTC ---
> No it isn't.  But given that fold at this place doesn't even
> fill in the array-ref element-size slot but provides NULL_TREE
> it is probably a fix for the better anyway?

Why not explicitly test in_gimple_form like in other places in the folder?

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de  
2011-03-10 12:36:33 UTC ---
On Thu, 10 Mar 2011, ebotcazou at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48031
> 
> --- Comment #8 from Eric Botcazou  2011-03-10 
> 12:34:57 UTC ---
> > It's mixing VLA unaware foldings into the mids of GIMPLE which is the
> > root of the issue though.  The issue is latent on trunk.
> > 
> > Patch for the first (and safe) idea:
> > 
> > Index: gcc/fold-const.c
> > ===
> > --- gcc/fold-const.c(revision 170818)
> > +++ gcc/fold-const.c(working copy)
> > @@ -15554,7 +15560,8 @@ fold_indirect_ref_1 (location_t loc, tre
> > }
> >/* *(foo *)&fooarray => fooarray[0] */
> >else if (TREE_CODE (optype) == ARRAY_TYPE
> > -  && type == TREE_TYPE (optype))
> > +  && type == TREE_TYPE (optype)
> > +  && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST)
> > {
> >   tree type_domain = TYPE_DOMAIN (optype);
> >   tree min_val = size_zero_node;
> > @@ -15633,7 +15640,8 @@ fold_indirect_ref_1 (location_t loc, tre
> > 
> >/* *(foo *)fooarrptr => (*fooarrptr)[0] */
> >if (TREE_CODE (TREE_TYPE (subtype)) == ARRAY_TYPE
> > -  && type == TREE_TYPE (TREE_TYPE (subtype)))
> > +  && type == TREE_TYPE (TREE_TYPE (subtype))
> > +  && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST)
> >  {
> >tree type_domain;
> >tree min_val = size_zero_node;
> > 
> > Eric, can you see any issues with that and Ada?
> 
> If this is limited to the in_gimple_form case, probably none.

No it isn't.  But given that fold at this place doesn't even
fill in the array-ref element-size slot but provides NULL_TREE
it is probably a fix for the better anyway?

Richard.

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  2011-03-10 
12:34:57 UTC ---
> It's mixing VLA unaware foldings into the mids of GIMPLE which is the
> root of the issue though.  The issue is latent on trunk.
> 
> Patch for the first (and safe) idea:
> 
> Index: gcc/fold-const.c
> ===
> --- gcc/fold-const.c(revision 170818)
> +++ gcc/fold-const.c(working copy)
> @@ -15554,7 +15560,8 @@ fold_indirect_ref_1 (location_t loc, tre
> }
>/* *(foo *)&fooarray => fooarray[0] */
>else if (TREE_CODE (optype) == ARRAY_TYPE
> -  && type == TREE_TYPE (optype))
> +  && type == TREE_TYPE (optype)
> +  && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST)
> {
>   tree type_domain = TYPE_DOMAIN (optype);
>   tree min_val = size_zero_node;
> @@ -15633,7 +15640,8 @@ fold_indirect_ref_1 (location_t loc, tre
> 
>/* *(foo *)fooarrptr => (*fooarrptr)[0] */
>if (TREE_CODE (TREE_TYPE (subtype)) == ARRAY_TYPE
> -  && type == TREE_TYPE (TREE_TYPE (subtype)))
> +  && type == TREE_TYPE (TREE_TYPE (subtype))
> +  && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST)
>  {
>tree type_domain;
>tree min_val = size_zero_node;
> 
> Eric, can you see any issues with that and Ada?

If this is limited to the in_gimple_form case, probably none.

[Bug c/43421] strict-aliasing warning from innocent code

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2011-03-10 
12:34:04 UTC ---
The code emitting the warning was removed without replacement.

The code isn't dubious but it shows that GCC 4.4 has bugs (but as we warn
we also tell you at the same time we won't optimize).

[Bug testsuite/48055] FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation, -O2 -flto

[ubizjak at gmail dot com]

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

--- Comment #4 from Uros Bizjak  2011-03-10 12:09:50 
UTC ---
(In reply to comment #3)
> Are there conflicting definitions somewhere?  Then it would indeed be a
> testsuite bug.

No, these are the only definitions for the particular testcase.

[Bug fortran/48058] New: [4.6 Regression] reallocation of array during constructor assignement

[xarthisius.kk at gmail dot com]

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

   Summary: [4.6 Regression] reallocation of array during
constructor assignement
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: xarthisius...@gmail.com


Assigning [...] constructor to allocatable array changes size of that array, if
size([...]) is not equal to size(array)

program ala
   implicit none
   integer, dimension(:), allocatable :: ivec

   allocate(ivec(3));  write(*,*) shape(ivec)
   ivec = [1,2];   write(*,*) shape(ivec) !!

end program ala

Target: x86_64-pc-linux-gnu
Configured with:
/dev/shm/portage/sys-devel/gcc-4.6.0_alpha20110226/work/gcc-4.6-20110226/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.0-alpha20110226
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0-alpha20110226/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0-alpha20110226
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0-alpha20110226/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0-alpha20110226/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0-alpha20110226/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --with-ppl --with-cloog --disable-ppl-version-check
--with-cloog-include=/usr/include/cloog-ppl --enable-lto --enable-nls
--without-included-gettext --with-system-zlib --disable-werror
--enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp
--enable-libgomp --enable-cld
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.6.0-alpha20110226/python
--enable-checking=release --disable-libgcj --enable-languages=c,c++,fortran
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/
--with-pkgversion='Gentoo 4.6.0_alpha20110226'
Thread model: posix
gcc version 4.6.0-alpha20110226 20110226 (experimental) (Gentoo
4.6.0_alpha20110226)

[Bug target/47779] Problem cross-compiling trunk for bfin

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #3 from Bernd Schmidt  2011-03-10 
12:01:57 UTC ---
Maybe ucontext.h should only define these context ifdef __USE_GNU? That's what
i386 and x86_64 appear to do.

[Bug target/46788] unsigned int possible treated as signed in a union/struct

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.03.10 11:59:32
   Target Milestone|--- |4.5.3
 Ever Confirmed|0   |1

--- Comment #4 from Ramana Radhakrishnan  2011-03-10 
11:59:32 UTC ---
Confirmed

[Bug lto/48056] lto throws out needed symbols when linking QtScript

[bero at arklinux dot org]

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

--- Comment #3 from bero at arklinux dot org 2011-03-10 11:48:47 UTC ---
Thanks, works.
Re-filed as WebKit bug
https://bugs.webkit.org/show_bug.cgi?id=56088

[Bug c/43421] strict-aliasing warning from innocent code

[mattiase at acm dot org]

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

Mattias Engdegård  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #1 from Mattias Engdegård  2011-03-10 
11:41:06 UTC ---
Gcc 4.5.2 no longer gives the spurious warning, so apparently this has been
fixed. My thanks to whomever did it.