[Bug tree-optimization/49657] array subscript warnings when building gcc with -O2

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2011-07-06 
08:05:26 UTC ---
The expmed.c code is broken, not sure about the crtstuff one.

[Bug target/49656] internal compiler error on Mac OS 10.7.0

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2011-07-06 
08:08:57 UTC ---
Works for me on native x86_64.

Also passes.c from 4.6.1 does only have 2052 lines, so your version information
cannot be correct.

[Bug c/49654] Linear search through options in handle_pragma_diagnostic

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.07.06 08:09:42
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-07-06 
08:09:42 UTC ---
Confirmed.

[Bug c/49655] diagnostic pragma accepts non-warning options

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.07.06 08:09:26
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-07-06 
08:09:26 UTC ---
Confirmed.

[Bug c/49653] Undefined reference to inlined function with -O0,-std=c99

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #3 from Richard Guenther  2011-07-06 
08:10:20 UTC ---
.

[Bug middle-end/49628] [4.7 Regression] 447.dealII in SPEC CPU 2006 failed to build

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #10 from Richard Guenther  2011-07-06 
08:11:05 UTC ---
*** Bug 49652 has been marked as a duplicate of this bug. ***

[Bug c/49652] SIGFPE in vector_alignment_reachable_p

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Richard Guenther  2011-07-06 
08:11:05 UTC ---
.

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

[Bug middle-end/49649] [4.7 Regression] FAIL: libgomp.graphite/force-parallel-1.c

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.07.06 08:12:38
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

[Bug tree-optimization/49647] gcc.dg/tree-ssa/20030807-7.c XPASSes everywhere

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.07.06 08:13:20
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-07-06 
08:13:20 UTC ---
Yes.  I suppose a recent change to DOM made this pass.

[Bug tree-optimization/49645] [4.7 regression] g++.dg/tree-ssa/pr8781.C FAILs on Tru64 UNIX

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.07.06 08:21:35
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2011-07-06 
08:21:35 UTC ---
Weird.  I can't see what should be target specific in this test (all relevant
functions are inlined).

Ah, on x86_64 I see that SRA did something, so I see in the .esra dump:

:
  pred = f;
  SR.36_52 = &pred;
  SR.37_51 = SR.36_52;
  MEM[(struct noop_t *)&pred].pred = SR.37_51;
  SR.38_50 = &pred;
  SR.39_48 = SR.38_50;
  MEM[(struct noop_t *)&pred].pred = SR.39_48;
  SR.40_47 = &pred;
  SR.41_45 = SR.40_47;
  MEM[(struct noop_t *)&pred].pred = SR.41_45;
  SR.42_44 = &pred;
  SR.43_42 = SR.42_44;
  MEM[(struct noop_t *)&pred].pred = SR.43_42;
...
  D.2683_15 = D.2693_14->pred;
  D.2691_16 = D.2683_15->pred;
  D.2684_17 = D.2691_16->pred;
  D.2690_18 = D.2684_17->pred;
  D.2685_19 = D.2690_18->pred;
  D.2689_20 = D.2685_19->pred;
  D.2686_21 = D.2689_20->pred;
  D.2688_22 = D.2686_21->pred;
  D.2687_23 = *D.2688_22;
  D.2682_24 = D.2687_23 ();


On the 4.6 branch FRE1 is after final inlining, so maybe there is enough
cleanup there to make it work.

Still FRE should work this out without SRA, so I'm taking this one.

[Bug target/49656] internal compiler error on Mac OS 10.7.0

[andreas at galauner dot de]

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

--- Comment #2 from andreas at galauner dot de 2011-07-06 08:30:52 UTC ---
(In reply to comment #1)
> Also passes.c from 4.6.1 does only have 2052 lines, so your version 
> information
> cannot be correct.

Oh, I'm sorry. You are totally right.
I accidentally used a 4.7 snapshot which, obviously, breaks for me in the same
manner.

Here is the error with a real 4.6.1:
x86_64-elf-gcc -m32 -g -nostdlib -nostdinc -fno-builtin -fno-stack-protector
-std=gnu99 -Wall -Wextra -pedantic -Wshadow -Wpointer-arith -Wcast-align
-Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls
-Wnested-externs -Winline -Wno-long-long -Wstrict-prototypes  -DARCH_X86
-DDEBUG -Iinclude -c src/main.c -o obj/main.o
src/main.c:30:1: internal compiler error: in execute_ipa_pass_list, at
passes.c:1921
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make: *** [obj/main.o] Error 1

Everything else is the same.
I just downloaded 4.6.1, build it and executed it and this is result.

[Bug target/49641] [4.6 Regression] Wrong code for ARMv4T and stmia

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.07.06 08:31:43
 CC||bernds at gcc dot gnu.org
Summary|[ARM] Wrong code for ARMv4T |[4.6 Regression] Wrong code
   |and stmia   |for ARMv4T and stmia
 Ever Confirmed|0   |1

--- Comment #2 from Richard Earnshaw  2011-07-06 
08:31:43 UTC ---
This is the regression caused by the new ldm/stm optimizers that were added for
4.6

[Bug testsuite/49542] [4.7 regression] 2 failures in the vectorization testsuite in 64-bit mode

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.07.06 08:35:19
  Component|tree-optimization   |testsuite
 Ever Confirmed|0   |1

--- Comment #5 from Eric Botcazou  2011-07-06 
08:35:19 UTC ---
Thanks for the diagnosis; I'm going to adjust the testcases.

[Bug c++/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot
   ||gnu.org

--- Comment #12 from Richard Guenther  2011-07-06 
08:38:56 UTC ---
If it happens that the MEM_REF case (supposedly with the adjusted base pointer)
does not work while the non-MEM_REF case works then this looks like a
latent problem in the tailcall code to me.  I see nothing wrong with the
GIMPLE itself.  Eventually we can adjust code-gen for the MEM_REF case to
match that of the pure component-ref one, but that would again just paper
over the issue.

[Bug testsuite/49542] [4.7 regression] 2 failures in the vectorization testsuite in 64-bit mode

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  2011-07-06 
08:46:45 UTC ---
Author: ebotcazou
Date: Wed Jul  6 08:46:41 2011
New Revision: 175905

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175905
Log:
PR testsuite/49542
* gcc.dg/vect/pr33804.c: XFAIL if vect_no_align unconditionally.
* gcc.dg/vect/slp-multitypes-3.c: XFAIL on SPARC unconditionally.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/pr33804.c
trunk/gcc/testsuite/gcc.dg/vect/slp-multitypes-3.c

[Bug c++/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

[kirill.yukhin at intel dot com]

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

--- Comment #13 from Yukhin Kirill  2011-07-06 
08:47:20 UTC ---
I agree, that there is no problem with GIMPLE. As I mentioned we may just
forbid tailcall opt for non-MEMREFS, but I suspect it will lead to significant
perf. degradation. 
BTW, I am to extract simple testcase by now

[Bug testsuite/49542] [4.7 regression] 2 failures in the vectorization testsuite in 64-bit mode

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #7 from Eric Botcazou  2011-07-06 
08:48:59 UTC ---
The vectorizer testsuite is clean again on SPARC.

[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #1 from Eric Botcazou  2011-07-06 
08:52:17 UTC ---
Rainer, any idea to solve this?

[Bug other/49658] New: Typo in gcc/doc/extend.texi

[jaak at ristioja dot ee]

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

   Summary: Typo in gcc/doc/extend.texi
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@ristioja.ee


In gcc/doc/extend.texi, text starting from line 1632:

"Compound literals for scalar types and union types are is
also allowed, but then the compound literal is equivalent
to a cast."

should not contain "are" instead of "are is".

[Bug fortran/49659] New: If-and-condition not obeyed using the g77-compiler (Windows 7, 64-bit).

[alhoweling at yahoo dot de]

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

   Summary: If-and-condition not obeyed using the g77-compiler
(Windows 7, 64-bit).
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: alhowel...@yahoo.de


Compiling and running the following short sourcecode:

***
PROGRAM TEST  
INTEGER A,B,C
LOGICAL M

A=23
B=34
C=55

M=.FALSE.

IF (A.eq.23.AND.B.eq.34.and.C.eq.4.and.M.eqv..FALSE.) THEN
PRINT*, 'yes'
ELSE
PRINT*, 'no'
END IF

END

***
gives the following output:

yes

[Bug other/49658] Typo in gcc/doc/extend.texi

[jaak at ristioja dot ee]

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

--- Comment #1 from Jaak Ristioja  2011-07-06 10:26:24 
UTC ---
Heh sry. I also made a typo. The text SHOULD contain "are" instead of "are is".

PS: The bugzilla might need a "Documentation" component for gcc.

[Bug c++/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

[kirill.yukhin at intel dot com]

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

--- Comment #14 from Yukhin Kirill  2011-07-06 
10:25:01 UTC ---
Created attachment 24700
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24700
Reduced testcase

[Bug other/49658] Typo in gcc/doc/extend.texi

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||documentation
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.07.06 10:29:29
 Ever Confirmed|0   |1

--- Comment #2 from Jonathan Wakely  2011-07-06 
10:29:29 UTC ---
Confirmed, thanks for the report.  You can use the "documentation" keyword for
doc bugs.

[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target|i686|i?86-*-*
  Component|c++ |middle-end

--- Comment #15 from Richard Guenther  2011-07-06 
10:30:26 UTC ---
The testcase reproduces the problem for me on trunk already with
-m32 -O -foptimize-sibling-calls, so it doesn't seem to be IPA SRA related.

[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

[kirill.yukhin at intel dot com]

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

--- Comment #16 from Yukhin Kirill  2011-07-06 
10:35:03 UTC ---
Yes.

This is because expander prepares arguments like this:
...
(insn 6 5 7 2 (parallel [
(set (reg:SI 64)
(plus:SI (reg/f:SI 53 virtual-incoming-args)
(const_int 4 [0x4])))
(clobber (reg:CC 17 flags))
]) 2.cc:103 -1
 (nil))

(insn 7 6 8 2 (set (reg:SI 65)
(mem/c:SI (plus:SI (reg:SI 64)
(const_int 12 [0xc])) [0 MEM[(int &)&t + 12]+0 S4 A32]))
2.cc:103 -1
 (nil))

(insn 8 7 9 2 (set (mem:SI (plus:SI (reg/f:SI 53 virtual-incoming-args)
(const_int 12 [0xc])) [0 S4 A32])
(reg:SI 65)) 2.cc:103 -1
 (nil))
...

So, calls.c/mem_overlaps_already_clobbered_arg_p unable to determine, that data
come from stack, so it returns true and enables tailcall.

[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Guenther  2011-07-06 
10:37:57 UTC ---
I suspect that the tailcalling code does not expect TER to happen when
expanding the call arguments?  With -fno-tree-ter the issue also isn't
appearant.

[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Guenther  2011-07-06 
10:49:24 UTC ---
Hm, the argument setup for the tailcall clobbers the incoming stack argument.
And without TER we do not overlap argument setup with the loads from the
incoming stack argument.

[Bug fortran/49659] If-and-condition not obeyed using the g77-compiler (Windows 7, 64-bit).

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.07.06 11:00:29
Version|unknown |4.6.1
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-07-06 
11:00:29 UTC ---
Confirmed.

   PROGRAM TEST
   INTEGER C
   LOGICAL M
   C=55
   M=.FALSE.
   IF (C.eq.4.and.M.eqv..FALSE.) THEN
   PRINT*, 'yes'
   ELSE
   PRINT*, 'no'
   END IF
   END

has in .original:

  c = 55;
  m = 0;
  if (c != 4 || !m)
{
  {
struct __st_parameter_dt dt_parm.0;

dt_parm.0.common.filename = &"t.f"[1]{lb: 1 sz: 1};
dt_parm.0.common.line = 7;
dt_parm.0.common.flags = 128;
dt_parm.0.common.unit = 6;
_gfortran_st_write (&dt_parm.0);
_gfortran_transfer_character_write (&dt_parm.0, &"yes"[1]{lb: 1 sz: 1},
3);
_gfortran_st_write_done (&dt_parm.0);
  }
}

somehow the condition is inverted but the branches are not exchanged
(it's also bogously inverted).

[Bug fortran/49659] If-and-condition not obeyed using the g77-compiler (Windows 7, 64-bit).

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

--- Comment #2 from Richard Guenther  2011-07-06 
11:03:58 UTC ---
Strangely ifort outputs the same result, so it must be correct (thus,
your program is invalid).  Works with

   IF ((C.eq.4).and.(M.eqv..FALSE.)) THEN

[Bug target/46481] long double should default to 64bit even for aix6.1

[michael.haubenwallner at salomon dot at]

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

--- Comment #2 from Michael Haubenwallner  2011-07-06 11:26:37 UTC ---
Seems this is fixed since gcc-4.6.0 by
http://gcc.gnu.org/viewcvs?view=revision&revision=169981.

[Bug bootstrap/39150] Configure scripts have no 64-Bit Solaris defined (only i386-solaris*).

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-07/msg00327.htm
   ||l
 Resolution|WONTFIX |
   Target Milestone|--- |4.7.0

--- Comment #21 from Rainer Orth  2011-07-06 11:36:56 
UTC ---
Mine, patch posted.

[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

[kirill.yukhin at intel dot com]

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

--- Comment #19 from Yukhin Kirill  2011-07-06 
11:49:34 UTC ---
Created attachment 24701
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24701
Patch to make tailcall check more conservative

Attached patch adds another check for clobbered stack area.
If address comes from a register - we have no idea about destination address.
That means we must act in conservative way - address possibly overlaps with
stack area of interest.

[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

[kirill.yukhin at intel dot com]

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

--- Comment #20 from Yukhin Kirill  2011-07-06 
11:50:51 UTC ---
With patch attached both tescase and 447.dealII passing

[Bug tree-optimization/49647] gcc.dg/tree-ssa/20030807-7.c XPASSes everywhere

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-07/msg00328.htm
   ||l
   Target Milestone|--- |4.7.0

--- Comment #2 from Rainer Orth  2011-07-06 11:53:09 UTC 
---
Patch posted.

[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

[rguenther at suse dot de]

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

--- Comment #21 from rguenther at suse dot de  
2011-07-06 11:53:56 UTC ---
On Wed, 6 Jul 2011, kirill.yukhin at intel dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519
> 
> --- Comment #19 from Yukhin Kirill  
> 2011-07-06 11:49:34 UTC ---
> Created attachment 24701
>   --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24701
> Patch to make tailcall check more conservative
> 
> Attached patch adds another check for clobbered stack area.
> If address comes from a register - we have no idea about destination address.
> That means we must act in conservative way - address possibly overlaps with
> stack area of interest.

That looks reasonable.  Can you bootstrap & test this fix and post it to
gcc-patches?

[Bug tree-optimization/49647] gcc.dg/tree-ssa/20030807-7.c XPASSes everywhere

[ro at gcc dot gnu.org]

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

--- Comment #3 from Rainer Orth  2011-07-06 11:56:49 UTC 
---
Author: ro
Date: Wed Jul  6 11:56:46 2011
New Revision: 175910

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175910
Log:
PR tree-optimization/49647
* gcc.dg/tree-ssa/20030807-7.c: Remove xfail *-*-*.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/20030807-7.c

[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

[kirill.yukhin at intel dot com]

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

--- Comment #22 from Yukhin Kirill  2011-07-06 
11:57:21 UTC ---
(In reply to comment #21)
> On Wed, 6 Jul 2011, kirill.yukhin at intel dot com wrote:
> 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519
> > 
> > --- Comment #19 from Yukhin Kirill  
> > 2011-07-06 11:49:34 UTC ---
> > Created attachment 24701 [details]
> >   --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24701
> > Patch to make tailcall check more conservative
> > 
> > Attached patch adds another check for clobbered stack area.
> > If address comes from a register - we have no idea about destination 
> > address.
> > That means we must act in conservative way - address possibly overlaps with
> > stack area of interest.
> 
> That looks reasonable.  Can you bootstrap & test this fix and post it to
> gcc-patches?

Already in progress :)

[Bug tree-optimization/49647] gcc.dg/tree-ssa/20030807-7.c XPASSes everywhere

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #4 from Rainer Orth  2011-07-06 11:57:59 UTC 
---
Fixed for 4.7.0.

[Bug fortran/49659] If-and-condition not obeyed using the g77-compiler (Windows 7, 64-bit).

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  2011-07-06 
12:01:59 UTC ---
> Strangely ifort outputs the same result, so it must be correct ...

Indeed! The standard says

7.1.3 Precedence of operators

1 There is a precedence among the intrinsic and extension operations
corresponding to the form of expressions speci ed in 7.1.2, which
determines the order in which the operands are combined unless the order is
changed by the use of parentheses.  This precedence order is summarized in
Table 7.2.  

Table 7.2:

Categories of operations and relative precedence

Category of operation   Operators   Precedence

Extension   defined-unary-opHighest
Numeric **  .
Numeric *, /.
Numeric unary +, -  .
Numeric binary +, - .
Character   //  .
Relational  .EQ., .NE., .LT., 
.LE., .GT., .GE.,
==, /=, <, <=, >, 
>=  .
Logical .NOT.   .
Logical .AND.   .
Logical .OR..
Logical .EQV., .NEQV.   .
Extension   defined-binary-op   Lowest

>From this table 'C.eq.4.and.M.eqv..FALSE.' is computed as
'((C.eq.4).and.M).eqv..FALSE)' which is .TRUE..

> (thus, your program is invalid).

The program is not invalid, but the reporter expectation is.

[Bug target/49335] [4.6/4.7 Regression] ARM: Invalid assembler generated while compiling C++ code from 'codeblocks'

[ramana at gcc dot gnu.org]

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

--- Comment #7 from Ramana Radhakrishnan  2011-07-06 
12:38:29 UTC ---
Author: ramana
Date: Wed Jul  6 12:38:26 2011
New Revision: 175911

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


2011-07-06  Ramana Radhakrishnan  

Backport from mainline.
2011-06-24  Ramana Radhakrishnan  

PR target/49335
* config/arm/predicates.md (add_operator): New.
* config/arm/arm.md ("*arith_shiftsi"): Fix for SP reg usage
in Thumb2.


Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/arm/arm.md
branches/gcc-4_6-branch/gcc/config/arm/predicates.md

[Bug target/49335] [4.6/4.7 Regression] ARM: Invalid assembler generated while compiling C++ code from 'codeblocks'

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #8 from Ramana Radhakrishnan  2011-07-06 
12:48:09 UTC ---
Fixed.

[Bug middle-end/47383] ivopts miscompiles Pmode != ptr_mode

[hjl at gcc dot gnu.org]

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

--- Comment #14 from hjl at gcc dot gnu.org  2011-07-06 
13:19:08 UTC ---
Author: hjl
Date: Wed Jul  6 13:19:04 2011
New Revision: 175912

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175912
Log:
Use pointer_mode for address computation.

gcc/

2011-07-06  H.J. Lu  

PR middle-end/47383
* tree-ssa-address.c (addr_for_mem_ref): Use pointer_mode for
address computation and convert to address_mode if needed.

gcc/testsuite/

2011-07-06  H.J. Lu  

PR middle-end/47383
* gcc.dg/pr47383.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/pr47383.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-address.c

[Bug tree-optimization/49645] [4.7 regression] g++.dg/tree-ssa/pr8781.C FAILs on Tru64 UNIX

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2011-07-06 
14:05:57 UTC ---
Author: rguenth
Date: Wed Jul  6 14:05:54 2011
New Revision: 175916

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175916
Log:
2011-07-06  Richard Guenther  

PR tree-optimization/49645
* c-decl.c (finish_decl): Also set DECL_HARD_REGISTER for global
register variables.
* tree-ssa-sccvn.c (vn_reference_op_eq): Disregard differences
in type qualification here ...
(copy_reference_ops_from_ref): ... not here.
(vn_reference_lookup_3): ... or here.
(copy_reference_ops_from_ref): Record decl bases as MEM[&decl].
(vn_reference_lookup): Do the lookup with a valueized ao-ref.

* g++.dg/tree-ssa/pr8781.C: Disable SRA.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/tree-ssa/pr8781.C
trunk/gcc/tree-ssa-sccvn.c

[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-07-06 14:06:59 UTC ---
> --- Comment #1 from Eric Botcazou  2011-07-06 
> 08:52:17 UTC ---
> Rainer, any idea to solve this?

One comment up front: It's best to directly Cc: me in PRs, otherwise I
may easily miss them.

It took me some time to understand why this didn't hit me in my S8
bootstraps, but they run in an S8 branded zone, where the alternate
thread library is copied over the default one, so __tls_get_addr is also
found in /lib/sparcv9/libthread.so.

Trying on our only native S8 machine, I see the same failure.

I think the only solution is to move LIB_THREAD_LDFLAGS_SPEC out of
LIB_SPEC (which is way too late, as you've observed) and into or in
front of LINK_ARCH_SPEC where all the other -L/-R flags are passed.

I'll have a look at this.

Rainer

[Bug fortran/49648] ICE(segfault) with MATMUL and function-result actual argument

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #7 from Mikael Morin  2011-07-06 
14:25:10 UTC ---
Here is a "fix".
The important part I suppose is that one has to apply resolve_symbol on
sym->result. It is the case before the patch, only if the symbol has unknown
type.

diff --git a/resolve.c b/resolve.c
index f484a22..908e72b 100644
--- a/resolve.c
+++ b/resolve.c
@@ -12181,21 +12181,22 @@ resolve_symbol (gfc_symbol *sym)
  in the case that there is no implicit type.  */
   if (!mp_flag)
 gfc_set_default_type (sym, sym->attr.external, NULL);
-  else
-{
-  /* Result may be in another namespace.  */
-  resolve_symbol (sym->result);
+}
+}

-  if (!sym->result->attr.proc_pointer)
-{
-  sym->ts = sym->result->ts;
-  sym->as = gfc_copy_array_spec (sym->result->as);
-  sym->attr.dimension = sym->result->attr.dimension;
-  sym->attr.pointer = sym->result->attr.pointer;
-  sym->attr.allocatable = sym->result->attr.allocatable;
-  sym->attr.contiguous = sym->result->attr.contiguous;
-}
-}
+  if (mp_flag && sym->attr.flavor == FL_PROCEDURE && sym->attr.function)
+{
+  /* Result may be in another namespace.  */
+  resolve_symbol (sym->result);
+
+  if (!sym->result->attr.proc_pointer)
+{
+  sym->ts = sym->result->ts;
+  sym->as = gfc_copy_array_spec (sym->result->as);
+  sym->attr.dimension = sym->result->attr.dimension;
+  sym->attr.pointer = sym->result->attr.pointer;
+  sym->attr.allocatable = sym->result->attr.allocatable;
+  sym->attr.contiguous = sym->result->attr.contiguous;
 }
 }

[Bug target/46622] ARM --target-help headings not translated

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #1 from Joseph S. Myers  2011-07-06 
14:31:35 UTC ---
This was fixed for 4.7 by:

2011-04-08  Joseph Myers  

* config.gcc (arm*-*-*): Add arm/arm-tables.opt to extra_options.
* config/arm/arm-arches.def: New.
* config/arm/arm-opts.h: New.
* config/arm/genopt.sh: New.
* config/arm/arm-tables.opt: New (generated).
* config/arm/arm.c (arm_handle_option, arm_target_help,
TARGET_HANDLE_OPTION, TARGET_HELP, arm_find_cpu): Remove.
(all_architectures): Get most table contents from arm-arches.def.
(arm_option_override): Set arm_selected_arch, arm_selected_cpu and
arm_selected_tune here.
* config/arm/arm.h (enum processor_type): Move to arm-opts.h.
* config/arm/arm.opt (config/arm/arm-opts.h): New HeaderInclude.
(march=, mcpu=, mtune=): Use Enum and Var.
* config/arm/t-arm ($(srcdir)/config/arm/arm-tables.opt): New.
(arm.o): Update dependencies.

[Bug target/49660] New: 64-bit gcc doesn't enable -mv8plus with -m32 on Solaris/SPARC

[ro at gcc dot gnu.org]

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

   Summary: 64-bit gcc doesn't enable -mv8plus with -m32 on
Solaris/SPARC
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: ebotca...@gcc.gnu.org
  Host: sparcv9-sun-solaris2*
Target: sparcv9-sun-solaris2*
 Build: sparcv9-sun-solaris2*


While testing my amd64-*-solaris2 patches in the sparcv9-sun-solaris2
configuration,
I noticed that all Go tests failed to link:

output is:
Undefinedfirst referenced

 symbol  in file

__sync_bool_compare_and_swap_8 
/var/gcc/gcc-4.7.0-20110628/11-gcc-v9/sparcv9-sun-solaris2.11/sparcv8plus/libgo/.libs/libgo.so

__sync_add_and_fetch_8 
/var/gcc/gcc-4.7.0-20110628/11-gcc-v9/sparcv9-sun-solaris2.11/sparcv8plus/libgo/.libs/libgo.so

ld: fatal: symbol referencing errors. No output written to
/var/gcc/gcc-4.7.0-20110628/11-gcc-v9/gcc/testsuite/go/array-1.x

collect2: error: ld returned 1 exit status


The problem can be reduced to the following testcase:

#include 

extern int64_t *val, old, new;

int
cas64 (void)
{
return __sync_bool_compare_and_swap (val, old, new);
}

If compiled with a sparc-sun-solaris2.11 gcc

$ gcc -S sync.c

it contains no calls to __sync_bool_compare_and_swap_8.

If compiled with a sparcv9-sun-solaris2.11 gcc instead

$ gcc -m32 -S sync.c

it does have a call to that function.  Comparing the -fverbose-asm output,
I see that the only difference in enabled options is that -mv8plus is
present in the first configuation, but missing in the second one.  Indeed,
If I add -mv8plus to the second invocation, the call is gone.

Unfortunately, I don't have a good idea where best to fix this.

[Bug target/49660] 64-bit gcc doesn't enable -mv8plus with -m32 on Solaris/SPARC

[sch...@linux-m68k.org]

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

--- Comment #1 from Andreas Schwab  2011-07-06 14:52:04 
UTC ---
I think you want to implement --with-cpu-(32|64) like x86 and powerpc.

[Bug fortran/49648] ICE(segfault) with MATMUL and function-result actual argument

[mikael at gcc dot gnu.org]

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

--- Comment #8 from Mikael Morin  2011-07-06 
15:00:56 UTC ---
(In reply to comment #7)
> Here is a "fix".
It breaks class_20.f03 and extends_4.f03 at least.
There is another attempt below.

(In reply to comment #6)
> Alternatively, one should somehow make sure that also expressions below
> sym->result - in particular: sym->result->as->{lbound,ubound} - get fixed via 
> a
> call to resolve_ref.
That is a better way (than your other suggestions) IMO.


diff --git a/resolve.c b/resolve.c
index f484a22..cbf403c 100644
--- a/resolve.c
+++ b/resolve.c
@@ -12198,6 +12198,8 @@ resolve_symbol (gfc_symbol *sym)
 }
 }
 }
+  else if (mp_flag && sym->attr.flavor == FL_PROCEDURE && sym->attr.function)
+gfc_resolve_array_spec (sym->result->as, false);

   /* Assumed size arrays and assumed shape arrays must be dummy
  arguments.  Array-spec's of implied-shape should have been resolved to

[Bug target/49660] 64-bit gcc doesn't enable -mv8plus with -m32 on Solaris/SPARC

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-07-06 15:01:11 UTC ---
> --- Comment #1 from Andreas Schwab  2011-07-06 
> 14:52:04 UTC ---
> I think you want to implement --with-cpu-(32|64) like x86 and powerpc.

This might be a possible improvement, but this PR is just about
different defaults for no reason that I can see.

Rainer

[Bug tree-optimization/49645] [4.7 regression] g++.dg/tree-ssa/pr8781.C FAILs on Tru64 UNIX

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Richard Guenther  2011-07-06 
15:10:19 UTC ---
Should be fixed now.

[Bug target/49660] 64-bit gcc doesn't enable -mv8plus with -m32 on Solaris/SPARC

[sch...@linux-m68k.org]

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

--- Comment #3 from Andreas Schwab  2011-07-06 15:16:47 
UTC ---
I think the proper handling of this is part of the --with-cpu-(32|64)
framework.

[Bug target/49660] 64-bit gcc doesn't enable -mv8plus with -m32 on Solaris/SPARC

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-07-06 15:24:51 UTC ---
> --- Comment #3 from Andreas Schwab  2011-07-06 
> 15:16:47 UTC ---
> I think the proper handling of this is part of the --with-cpu-(32|64)
> framework.

No idea, I just object to getting V8+ code with as 32-bit default
gcc, but non-V8+ with a 64-bit default gcc.  This is just confusing and
unnecessary.

As I said: I'm uncertain about the proper place to handle this, thus
this PR Cc'ed to the target maintainer, Eric.

Rainer

[Bug target/49660] 64-bit gcc doesn't enable -mv8plus with -m32 on Solaris/SPARC

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.07.06 15:33:38
 AssignedTo|unassigned at gcc dot   |ebotcazou at gcc dot
   |gnu.org |gnu.org
 Ever Confirmed|0   |1

--- Comment #5 from Eric Botcazou  2011-07-06 
15:33:38 UTC ---
Fixing.

[Bug other/49661] New: et-forest.h uses extern "C"

[jsm28 at gcc dot gnu.org]

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

   Summary: et-forest.h uses extern "C"
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: js...@gcc.gnu.org


et-forest.h uses

#ifdef __cplusplus
extern "C" {
#endif /* __cplusplus */

contrary to the normal principle in GCC that when building as C++ the internal
interfaces are C++ ones.  A fix would be almost obvious, but would need testing
with a --enable-build-with-cxx build.

[Bug fortran/49648] ICE(segfault) with MATMUL and function-result actual argument

[burnus at gcc dot gnu.org]

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

--- Comment #9 from Tobias Burnus  2011-07-06 
16:53:32 UTC ---
(In reply to comment #8)
> +  else if (mp_flag && sym->attr.flavor == FL_PROCEDURE && sym->attr.function)
> +gfc_resolve_array_spec (sym->result->as, false);

I think one could add somewhere a condition "if (sym != sym->result)"; and I
was wondering whether also other items like length-type parameters are
effected. (I think, usually character lengths are shared, but I am not sure
whether it also happens here.)

[Bug testsuite/48727] FAIL: g++.dg/opt/devirt2.C scan-assembler-times xyzzy 2

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Target|hppa2.0w-hp-hpux11.11   |hppa2.0w-hp-hpux11.11,
   ||sparc-sun-solaris2*
 CC||ebotcazou at gcc dot
   ||gnu.org, ro at gcc dot
   ||gnu.org
   Host|hppa2.0w-hp-hpux11.11   |hppa2.0w-hp-hpux11.11,
   ||sparc-sun-solaris2*
   Target Milestone|--- |4.7.0
  Build|hppa2.0w-hp-hpux11.11   |hppa2.0w-hp-hpux11.11,
   ||sparc-sun-solaris2*

--- Comment #3 from Rainer Orth  2011-07-06 17:10:22 UTC 
---
This also fails on 32-bit Solaris/SPARC with Sun as, which has:

sethi   %hi(_ZN1S5xyzzyEv), %g1
jmp %g1 + %lo(_ZN1S5xyzzyEv)
sethi   %hi(_ZN1S5xyzzyEv), %g1
jmp %g1 + %lo(_ZN1S5xyzzyEv)

On the other hand, both 64-bit with Sun as and 32-bit with gas have

call_ZN1S5xyzzyEv, 0
call_ZN1S5xyzzyEv, 0

[Bug fortran/49648] ICE(segfault) with MATMUL and function-result actual argument

[mikael at gcc dot gnu.org]

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

--- Comment #10 from Mikael Morin  2011-07-06 
17:28:14 UTC ---
(In reply to comment #9)
> (In reply to comment #8)
> > +  else if (mp_flag && sym->attr.flavor == FL_PROCEDURE && 
> > sym->attr.function)
> > +gfc_resolve_array_spec (sym->result->as, false);
> 
> I think one could add somewhere a condition "if (sym != sym->result)";
This is contained in mp_flag :-)

> and I was wondering whether also other items like length-type parameters are
> effected. (I think, usually character lengths are shared, but I am not sure
> whether it also happens here.)
Well, it's difficult to tell by quickly (or even slowly) browsing through the
function.
I was supposing resolve_symbol would handle all other items in my previous
patch, but it fails unfortunately (for reasons that I have admittedly not
investigated); hence this less ambitious one, which doesn't regress at least. 
For what it's worth the following variant using character lengths doesn't ICE.
I can't tell in the general case though.


module m2
  COMPLEX, SAVE, ALLOCATABLE :: P(:)
contains
  FUNCTION getPhaseMatrix() RESULT(PM)
CHARACTER(len=SIZE(P)) :: PM
PM="foo   "
  END FUNCTION
end module m2

module m
  use m2
contains
   SUBROUTINE gf_generateEmbPot()
  CHARACTER(3) :: sigma2
  sigma2 = TRIM(getPhaseMatrix())
   END SUBROUTINE
end module m

[Bug c/49653] Undefined reference to inlined function with -O0,-std=c99

[gary at intrepid dot com]

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

--- Comment #4 from Gary Funck  2011-07-06 17:29:32 
UTC ---
Thanks Andrew and Johannes for the follow-up.  The difference in between
optimized and non-optimized compilations was surprising to me, but I now
understand that this is the result of the way that GCC handles this
implementation-defined behavior.

[Bug middle-end/47383] ivopts miscompiles Pmode != ptr_mode

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #15 from H.J. Lu  2011-07-06 18:22:46 
UTC ---
Fixed.

[Bug middle-end/49662] New: [4.7 Regression] FAIL: gcc.dg/graphite/interchange-XX.c

[hjl.tools at gmail dot com]

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

   Summary: [4.7 Regression] FAIL:
gcc.dg/graphite/interchange-XX.c
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: rgue...@gcc.gnu.org


On Linux/x86, revision 175916:

http://gcc.gnu.org/ml/gcc-cvs/2011-07/msg00181.html

caused:

FAIL: gcc.dg/graphite/interchange-14.c scan-tree-dump-times graphite "will be
interchanged" 1
FAIL: gcc.dg/graphite/interchange-15.c scan-tree-dump-times graphite "will be
interchanged" 1
FAIL: gcc.dg/graphite/interchange-mvt.c scan-tree-dump-times graphite "will be
interchanged" 1

[Bug other/49658] Typo in gcc/doc/extend.texi

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2011-07-06 
18:40:39 UTC ---
Author: redi
Date: Wed Jul  6 18:40:36 2011
New Revision: 175928

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175928
Log:
2011-07-06  Jonathan Wakely  

PR other/49658
* doc/extend.texi (Compound Literals): Fix typo.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/extend.texi

[Bug other/49658] Typo in gcc/doc/extend.texi

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  2011-07-06 
18:41:36 UTC ---
fixed

[Bug c++/49663] New: [4.7 Regression] [C++0x] ICE in lookup_base

[redi at gcc dot gnu.org]

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

   Summary: [4.7 Regression] [C++0x] ICE in lookup_base
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: ja...@gcc.gnu.org


struct Nosm 
{
int m_R;
};

namespace dx {

struct onc
{
typedef void(*Cb)();

onc(Cb cb);
};

struct grac
{
template static void once();
};

template
struct tonc : onc
{
tonc() : onc(&grac::once) {}

static Derived& get();
};

template void grac::once()
{
tonc::get().h();
}
}

namespace
{
template
struct has_R { };

template
inline void
setR(T* m, has_R* = 0)
{ }

inline void setR(...) { }
}

template
struct Qmi
: dx::tonc >
{
void h()
{
setR(&msg);
}

M msg;
};

Qmi x;


ICE with -std=c++0x, none without, none with 4.6 branch


lookup_base (t=0x0, base=0x76d9e540, access=0, kind_ptr=0x0)
at /home/jwakely/src/gcc/gcc/cp/search.c:204
204  if (!TYPE_P (t))
(gdb) p t
$1 = (tree) 0x0
(gdb) bt 2
#0  lookup_base (t=0x0, base=0x76d9e540, access=0, kind_ptr=0x0)
at /home/jwakely/src/gcc/gcc/cp/search.c:204
#1  0x00605fc9 in check_accessibility_of_qualified_id (
decl=0x76da41c8, object_type=0x0, nested_name_specifier=0x76d9e540)
at /home/jwakely/src/gcc/gcc/cp/semantics.c:1695
(More stack frames follow...)

[Bug fortran/49479] [4.6/4.7 Regression] reshape / optionals / zero sized arrays

[tkoenig at gcc dot gnu.org]

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

--- Comment #8 from Thomas Koenig  2011-07-06 
18:50:50 UTC ---
Author: tkoenig
Date: Wed Jul  6 18:50:46 2011
New Revision: 175929

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175929
Log:
2011-07-06  Thomas Koenig  

Partial backport from trunk:
PR fortran/49479
* runtime/memory.c:  If size is zero, allocate a single byte.
* m4/eoshift1.m4:  Remove double allocation.
* m4/eoshift3.m4:  Likewise.
* generated/eoshift1_4.c:  Regenerated.
* generated/eoshift1_8.c:  Regenerated.
* generated/eoshift1_16.c:  Regenerated.
* generated/eoshift3_4.c:  Regenerated.
* generated/eoshift3_8.c:  Regenerated.
* generated/eoshift3_16.c:  Regenerated.

2011-07-06  Thomas Koenig  

PR fortran/49479
* gfortran.dg/reshape_zerosize_3.f90:  New test case.


Added:
branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/reshape_zerosize_3.f90
Modified:
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
branches/gcc-4_6-branch/libgfortran/ChangeLog
branches/gcc-4_6-branch/libgfortran/generated/eoshift1_16.c
branches/gcc-4_6-branch/libgfortran/generated/eoshift1_4.c
branches/gcc-4_6-branch/libgfortran/generated/eoshift1_8.c
branches/gcc-4_6-branch/libgfortran/generated/eoshift3_16.c
branches/gcc-4_6-branch/libgfortran/generated/eoshift3_4.c
branches/gcc-4_6-branch/libgfortran/generated/eoshift3_8.c
branches/gcc-4_6-branch/libgfortran/m4/eoshift1.m4
branches/gcc-4_6-branch/libgfortran/m4/eoshift3.m4
branches/gcc-4_6-branch/libgfortran/runtime/memory.c

[Bug fortran/49479] [4.6/4.7 Regression] reshape / optionals / zero sized arrays

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #9 from Thomas Koenig  2011-07-06 
18:51:43 UTC ---
Fixed on trunk and 4.6, closing.

[Bug c++/49663] [4.7 Regression] [C++0x] ICE in lookup_base

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |

--- Comment #1 from Jonathan Wakely  2011-07-06 
19:02:57 UTC ---
actually Comeau online rejects this so maybe it isn't valid and should have
been rejected by previous GCCs

line 23: error: no instance of constructor "dx::onc::onc" matches the
  argument list
The argument types that you used are: ()
  tonc() : onc(&grac::once) {}
  ^

Clang ICEs on it http://llvm.org/bugs/show_bug.cgi?id=10219

[Bug c++/49663] [4.7 Regression] [C++0x] ICE in lookup_base

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2011-07-06 
19:11:06 UTC ---
Changing the initializer to:

tonc() : onc((onc::Cb)&grac::once) {}

makes Comeau happy, but still gives an ICE with 4.7 and -std=c++0x

[Bug testsuite/48727] FAIL: g++.dg/opt/devirt2.C scan-assembler-times xyzzy 2

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  2011-07-06 
19:15:49 UTC ---
> This also fails on 32-bit Solaris/SPARC with Sun as, which has:
> 
> sethi   %hi(_ZN1S5xyzzyEv), %g1
> jmp %g1 + %lo(_ZN1S5xyzzyEv)
> sethi   %hi(_ZN1S5xyzzyEv), %g1
> jmp %g1 + %lo(_ZN1S5xyzzyEv)
> 
> On the other hand, both 64-bit with Sun as and 32-bit with gas have
> 
> call_ZN1S5xyzzyEv, 0
> call_ZN1S5xyzzyEv, 0

This is OK, these are the 2 forms of a direct tail call on the SPARC: sethi/jmp
or call, depending on the capability of the assembler (HAVE_AS_RELAX_OPTION).

[Bug c/49653] Undefined reference to inlined function with -O0,-std=c99

[gary at intrepid dot com]

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

--- Comment #5 from Gary Funck  2011-07-06 19:21:26 
UTC ---
Would the following make sense as an enhancement, and still be standards
conforming?

RFE: If compiling in C99 mode at -O0 (optimization disabled), compile functions
declared as "inline" as if they were instead declared "static".

In this way, if a user makes use of inlined functions, but decides to
re-compile his program at -O0 (in C99 mode) he doesn't have to resort to using
work-arounds (such as compiling with -Dinline=static").

[Bug c/49653] Undefined reference to inlined function with -O0,-std=c99

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  2011-07-06 
19:37:00 UTC ---
why not just add this to make the code valid by emitting an extern definition?

extern long trouble(long, long);

[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-07/msg00359.htm
   ||l

--- Comment #23 from H.J. Lu  2011-07-06 19:37:39 
UTC ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00359.html

[Bug middle-end/47383] ivopts miscompiles Pmode != ptr_mode

[hjl at gcc dot gnu.org]

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

--- Comment #16 from hjl at gcc dot gnu.org  2011-07-06 
20:30:13 UTC ---
Author: hjl
Date: Wed Jul  6 20:30:06 2011
New Revision: 175933

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175933
Log:
Use pointer_mode for address computation.

gcc/

2011-07-05  H.J. Lu  

PR middle-end/47383
* tree-ssa-address.c (addr_for_mem_ref): Use pointer_mode for
address computation and convert to address_mode if needed.

gcc/testsuite/

2011-07-05  H.J. Lu  

PR middle-end/47383
* gcc.dg/pr47383.c: New.

Added:
branches/x32/gcc/testsuite/gcc.dg/pr47383.c
Modified:
branches/x32/gcc/ChangeLog.x32
branches/x32/gcc/testsuite/ChangeLog.x32
branches/x32/gcc/tree-ssa-address.c

[Bug target/38342] [4.4/4.5/4.6/4.7 Regression] __attribute__((__progmem__)) not propagated from typedef to data

[westfw at yahoo dot com]

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

--- Comment #12 from Bill Westfield  2011-07-06 
21:18:26 UTC ---
Ah.  So this is the same compiler behavior that results in C++ overloading not
being able to tell the difference between a RAM pointer and a progmem pointer;
the attribute ends up only associated with the variable and not with the types
at all...  Consistency is good, and I think I can see how having too many type
modifiers would end up being dangerous.  Thanks for the explanations!

[Bug c++/49568] [4.7 regression] g++.dg/torture/pr41257-2.C FAILs to link on Tru64 UNIX

[jason at gcc dot gnu.org]

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

--- Comment #10 from Jason Merrill  2011-07-06 
21:22:21 UTC ---
Author: jason
Date: Wed Jul  6 21:22:16 2011
New Revision: 175938

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175938
Log:
PR c++/49568
* method.c (make_thunk, use_thunk): Copy DECL_COMDAT.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/method.c

[Bug c++/49568] [4.7 regression] g++.dg/torture/pr41257-2.C FAILs to link on Tru64 UNIX

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |WAITING
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |

--- Comment #11 from Jason Merrill  2011-07-06 
21:23:33 UTC ---
Should be fixed now.

[Bug c++/49663] [4.7 Regression] [C++0x] ICE in lookup_base

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.07.06 21:57:28
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug lto/49664] New: liblto_plugin.so exports too many symbols

[jsm28 at gcc dot gnu.org]

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

   Summary: liblto_plugin.so exports too many symbols
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: js...@gcc.gnu.org


The dynamic symbol table of liblto_plugin.so contains lots of libiberty symbols
that should not be part of the plugin's interface.  I think the "onload" symbol
is the only one that actually needs to be exported; the rest should be hidden
by an appropriate version script when the plugin is built, if this is supported
on the host.

[Bug other/49665] New: 'defined in discarded section' link failures on cpu2006 benchmarks

[pthaugen at gcc dot gnu.org]

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

   Summary: 'defined in discarded section' link failures on
cpu2006 benchmarks
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pthau...@gcc.gnu.org
CC: amo...@gcc.gnu.org, berg...@gcc.gnu.org
  Host: powerpc64-linux
Target: powerpc64-linux
 Build: powerpc64-linux


450.soplex (-O2) and 471.omnetpp fail to link in 64-bit mode with the same
error.

450.soplex:

`soplex::SPxBasis::~SPxBasis()' referenced in section
`.data.rel.ro._ZTVN6soplex8SPxBasisE[vtable for soplex::SPxBasis]' of
spxbasis.o: defined in discarded section `.group' of spxbasis.o
`soplex::SPxLP::~SPxLP()' referenced in section
`.data.rel.ro._ZTVN6soplex5SPxLPE[vtable for soplex::SPxLP]' of spxlp.o:
defined in discarded section `.group' of spxlp.o
`soplex::LPRowSet::~LPRowSet()' referenced in section `.text' of spxlpfread.o:
defined in discarded section `.group' of spxlpfread.o
`soplex::LPRowSet::~LPRowSet()' referenced in section `.text' of spxlpfread.o:
defined in discarded section `.group' of spxlpfread.o


471.omnetpp:

`cEqdHistogramBase::~cEqdHistogramBase()' referenced in section
`.data.rel.ro._ZTV17cEqdHistogramBase[vtable for cEqdHistogramBase]' of
libs/sim/std/netpack.o: defined in discarded section `.group' of
libs/sim/std/netpack.o

[Bug fortran/48351] [OOP] Realloc on assignment fails if parent component is CLASS

[townsend at astro dot wisc.edu]

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

Rich Townsend  changed:

   What|Removed |Added

 CC||townsend at astro dot
   ||wisc.edu

--- Comment #3 from Rich Townsend  2011-07-07 
02:34:41 UTC ---
(In reply to comment #0)
> http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/b7a36eba5ef7f68b
>  by Nasser M. Abbasi
> 
> In the following program "%u" is allocatable. For
> 
> this%u = u
> 
> the LHS should be allocated, but this only happens if "this" is a TYPE and not
> a CLASS - but that should be completely unrelated to (re)alloc on assignment.
> 
> The program works with ifort 11.1.
> 
> 
> module foo
> implicit none
> type :: foo_t
> !  private
>   DOUBLE PRECISION , ALLOCATABLE :: u(:)
>   contains
> PROCEDURE :: make  ! or procedure, pass, same effect
> end type foo_t
> 
> contains
> subroutine make(this,u)
> implicit none
> CLASS(foo_t) :: this
> DOUBLE PRECISION, intent(in) :: u(:)  ! must be CLASS
> !   allocate(this%u(size(u)))  ! Must allocate now, else crash
> this%u = u
> end subroutine make
> end module foo
> 
> program main2
>  use foo
>  implicit none
>  TYPE(foo_t) :: o
>  DOUBLE PRECISION , ALLOCATABLE :: u(:)
> 
>  u=[1,2,3,4]
>  CALL o%make(u)
>  print *, o%u
> end program main2

I've run into what appears to be this bug with 4.7 (Mac OS 10.6). My sample
code is as follows:

module realloc_lhs_m

  implicit none

  type mytype
 real, allocatable :: a(:)
   contains
 procedure :: set_a
  end type mytype

contains

  subroutine set_a (this, a)
class(mytype), intent(out) :: this
real, intent(in)   :: a(:)
this%a = a
  end subroutine set_a

end module realloc_lhs_m

program realloc_lhs

  use realloc_lhs_m
  implicit none

  real, allocatable :: a(:)
  type(mytype)  :: m

  a = [1.,2.,3.,4.,5.]

  call m%set_a(a)
  print *, m%a

end program realloc_lhs

This can be easily worked around -- but of course should nevertheless be fixed.

cheers,

Rich

[Bug c++/49353] C++ frontend should not declare function EXTERN when it forces them to stay

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  2011-07-07 
02:58:36 UTC ---
Author: jason
Date: Thu Jul  7 02:58:33 2011
New Revision: 175954

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175954
Log:
PR c++/49353
* semantics.c (expand_or_defer_fn_1): Clear DECL_EXTERNAL
on kept inlines.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c

[Bug other/49666] New: passing nested function to inline function causes a trampoline call

[kevin.waugh at gmail dot com]

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

   Summary: passing nested function to inline function causes a
trampoline call
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kevin.wa...@gmail.com


#include 
static inline int identity(int (*f)()) {
  return f();
}

int n = 0;
int f() {
  return n;
}

int main() {
  int m = 0;
  int g() {
return m;
  }
  printf("%d\n", identity(f)); /* inlines all the way */
  printf("%d\n", identity(g)); /* calls g through trampoline */
  printf("%d\n", g()); /* inline's g */
}

[Bug other/49665] 'defined in discarded section' link failures on cpu2006 benchmarks

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.07.07 06:51:19
 CC||amodra at gmail dot com
 AssignedTo|unassigned at gcc dot   |amodra at gmail dot com
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Alan Modra  2011-07-07 06:51:19 
UTC ---
There are some really weird things going on here that make me think this is a
linker bug rather than a gcc bug.  Assigning to myself to save others wasting
time on the PR.