[Bug tree-optimization/27460] Does not vectorize statements with mixed type COND_EXPRs

[vincenzo.innocente at cern dot ch]

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

--- Comment #3 from vincenzo Innocente  
2011-06-23 07:00:11 UTC ---
is not that the fix in PR49483 will help also in this case?
Please let me know if this is considered a bug that will be eventually fixed or
a feature to be added to any sort of documentation or tutorial  about
"vectorization with gcc"

[Bug fortran/40737] Pointer references sometimes fail to define "span" symbols

[kenneth.hoste at elis dot ugent.be]

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

Kenneth Hoste  changed:

   What|Removed |Added

 CC||kenneth.hoste at elis dot
   ||ugent.be

--- Comment #14 from Kenneth Hoste  
2011-06-23 07:36:41 UTC ---
Seems like this issue is still present in the GCC 4.6 branch, at least in GCC
4.6.0 and a checkout on 20110617 of the 4.6 branch.

I can confirm that patching the tera_tf source as suggested by David fixes the
issue, but the runtime still fails: the benchmark seems stuck in an infinite
loop or something when compiled with "-Ofast -march=native -mtune=native
-floop-strip-mine -floop-interchange -floop-block" at least. Not sure if the
failing runtime is caused by this issue though.

Is the patch that has been proposed insufficient?

Any of you know whether anyone has been able to build whole of SPEC MPI2007
using (a recent) GCC?

[Bug middle-end/49512] [4.7 Regression] FAIL: gcc.dg/tree-ssa/asm-1.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  2011-06-23 
08:13:04 UTC ---
Wrong guess.  I bet 63 happens to be matched also inside of the
questionable
;; Function f (f, funcdef_no=0, decl_uid=1589, cgraph_uid=0)
line somewhere.
I think this testcase just should use -fdump-tree-optimized-nouid instead
of -fdump-tree-optimized, will test that.

[Bug testsuite/49512] [4.7 Regression] FAIL: gcc.dg/tree-ssa/asm-1.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.06.23 08:21:19
  Component|middle-end  |testsuite
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

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

--- Comment #15 from Mikael Pettersson  2011-06-23 
08:36:33 UTC ---
Status update: I have a nice stable gcc-4.1.2 with gnat that has bootstrapped
itself through approx 10 generations natively on m68k-linux, and the final
working patch kit is quite small.

I forward-ported the 4.1.2 patch kit to 4.4.6, added one tweak (don't set
DECL_IS_MALLOC on malloc_decl since it doesn't return a pointer type with the
kit), but that failed near the end of stage2 with the same assertion as in #c8.

So I now intend to go back a do full bootstraps also with the intermediate 4.2
and 4.3 releases.  That in turn will require some digging to locate whatever
m68k-specific patches I'll need for those releases.

[Bug c++/49508] [4.7 Regression] Bogus "control reaches end of non-void function" warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  2011-06-23 
08:44:03 UTC ---
Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149750.
(and is definitely emitted by g++ 4.6 too).
I wonder if this warning shouldn't be disabled when any errors have been
emitted already.

[Bug c++/49508] Bogus "control reaches end of non-void function" warning

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|[4.7 Regression] Bogus  |Bogus "control reaches end
   |"control reaches end of |of non-void function"
   |non-void function" warning  |warning

--- Comment #2 from Paolo Carlini  2011-06-23 
09:01:47 UTC ---
Indeed, I did something wrong with the shell variables, sorry, I'm removing the
regression marker. Still rather annoying anyway.

[Bug target/48126] arm_output_sync_loop: misplaced memory barrier, missing clrex / dummy strex

[marcus.shawcroft at arm dot com]

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

--- Comment #7 from Marcus Shawcroft  
2011-06-23 09:32:59 UTC ---
(In reply to comment #5)
> Michael:
> I think I agree with you on the need for the barrier in the branch out case;
> gcc's info page (section 6.49 'Built-in functions for atomic memory access')
> state:

I agree. The DMB needs to be included in the branch out case in order to comply
with the "full barrier" requirement.

/Marcus

[Bug c++/49507] [4.6/4.7 Regression] ICE because of defaulted template destructor

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.23 09:50:47
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |4.6.1
Summary|ICE because of defaulted|[4.6/4.7 Regression] ICE
   |template destructor |because of defaulted
   ||template destructor
 Ever Confirmed|0   |1

--- Comment #1 from Jakub Jelinek  2011-06-23 
09:50:47 UTC ---
Indeed, a regression from 4.6.0, caused by PR47544 fix
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174071
on the trunk and
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174159
on 4.6 branch.

#0  0x006f972a in initialize_vtbl_ptrs (addr=0x0) at
../../gcc/cp/init.c:120
#1  0x0051f017 in begin_destructor_body () at ../../gcc/cp/decl.c:13001
#2  0x005201f5 in begin_function_body () at ../../gcc/cp/decl.c:13090
#3  0x00716b58 in synthesize_method (fndecl=0x71a1be00) at
../../gcc/cp/method.c:741
#4  0x005c8d63 in instantiate_decl (d=0x71a1be00, defer_ok=0,
expl_inst_class_mem_p=0 '\000') at ../../gcc/cp/pt.c:17738
#5  0x005c9b94 in instantiate_pending_templates (retries=1) at
../../gcc/cp/pt.c:17884
#6  0x00647e2c in cp_write_global_declarations () at
../../gcc/cp/decl2.c:3719

ICEs because current_class_ptr is NULL.  Jason, as this is a regression from
4.6.0, it might be desirable to fix it for 4.6.1 instead of deferring for
4.6.2.

[Bug middle-end/35561] Promote written once local aggregates to static

[joseph at codesourcery dot com]

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

--- Comment #8 from joseph at codesourcery dot com  2011-06-23 10:32:28 UTC ---
See bug 38615 for the case when converting an object to static is not 
valid.

[Bug c++/49514] New: Crashes on valid use of constexpr constructor

[schaub.johannes at googlemail dot com]

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

   Summary: Crashes on valid use of constexpr constructor
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: schaub.johan...@googlemail.com


GCC crashes on this code:

/// snip
struct Vector4D {
  constexpr Vector4D(double x=0, double y=0, double z=0, double t=0)
:components{x, y, z, t}, 
x(components[0]), y(components[1]), z(components[2]), t(components[3]) 
{ }

  double components[4];
  double &x, &y, &z, &t;
};

Vector4D a{1, 2, 3};
/// snap

Error:

main1.cpp:11:19:   in constexpr expansion of ‘a.Vector4D::Vector4D(1.0e+0,
2.0e+0, 3.0e+0, 0.0)’
main1.cpp:11:19: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c++/44625] [4.3/4.4/4.5/4.6/4.7 Regression] ICE after error: anonymous struct not inside named type

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com

--- Comment #6 from Paolo Carlini  2011-06-23 
11:01:01 UTC ---
On it (again ;)

[Bug target/49515] New: [4.7 Regression] gcc.dg/torture/tls/thr-init-2.c -O2 -fpic execution test failure

[ubizjak at gmail dot com]

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

   Summary: [4.7 Regression] gcc.dg/torture/tls/thr-init-2.c  -O2
-fpic  execution test failure
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ubiz...@gmail.com
CC: r...@gcc.gnu.org
Target: alpha-linux-gnu


gcc.dg/torture/tls/thr-init-2.c  -O2  -fpic testcase fails on
alphaev68-pc-linux-gnu due to clobbering of $16 register.

The problematic function in the testcase compiles to (-O2 -fpic):

$test_code..ng:
ldq $27,__tls_get_addr($29)!literal!1
lda $30,-16($30)
stq $26,0($30)
stq $9,8($30)
.prologue 1
mov $16,$9
lda $16,fstat($29)!tlsldm!1
jsr $26,($27),__tls_get_addr!lituse_tlsldm!1
ldah $29,0($26)!gpdisp!3
ldah $1,fstat($0)!dtprelhi
ldq $26,0($30)
lda $29,0($29)!gpdisp!3
>>> ldl $16,fstat($1)   !dtprello
>>> addl $16,$9,$16
ldq $9,8($30)
addl $31,$16,$0
>>> stl $16,fstat($1)   !dtprello
lda $30,16($30)
ret $31,($26),1

$ ./a.out
a=2 fstat=33554434
Aborted

The difference to working code from gcc-4.4.5 is:

@@ -26,17 +26,18 @@
 ldah $1,fstat($0)!dtprelhi
 ldq $26,0($30)
 lda $29,0($29)!gpdisp!3
-ldl $0,fstat($1)!dtprello
-addl $0,$9,$0
+ldl $16,fstat($1)!dtprello
+addl $16,$9,$16
 ldq $9,8($30)
-stl $0,fstat($1)!dtprello
+addl $31,$16,$0
+stl $16,fstat($1)!dtprello
 lda $30,16($30)
 ret $31,($26),1

Please note that $0 is used instead (extra addl is just a move from $16 to $0).

Does !dtprello relocation need live $16 register? The relevant patterns in
alpha.md do not model that dependancy.

[Bug middle-end/49373] [4.7 Regression] Many testcase failures

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||xfail
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.23 11:40:14
 Ever Confirmed|0   |1

--- Comment #11 from Richard Guenther  2011-06-23 
11:40:14 UTC ---
Now XFAILed (parts).

[Bug testsuite/49503] Incorrect stack alignment, produced by inline assembler in tests gcc.target/i386/cleanup-1.c and gcc.target/i386/cleanup-2.c

[michael.v.zolotukhin at gmail dot com]

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

--- Comment #4 from Michael Zolotukhin  
2011-06-23 11:42:03 UTC ---
Created attachment 24584
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24584
Test showing that cleanup-* tests are not quite correct.

[Bug c++/49510] bitshift warnings

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.23 11:42:52
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-06-23 
11:42:52 UTC ---
Confirmed.

[Bug testsuite/49503] Incorrect stack alignment, produced by inline assembler in tests gcc.target/i386/cleanup-1.c and gcc.target/i386/cleanup-2.c

[michael.v.zolotukhin at gmail dot com]

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

--- Comment #5 from Michael Zolotukhin  
2011-06-23 11:44:17 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > (In reply to comment #0)
> > > > 
> > > > As _L_mutex_lock is a function, GCC generates a prologue and epilogue 
> > > > for it -
> > > > in prologue stack alignment is performed (according to ABI64, stack 
> > > > should be
> > > > aligned to 128-bit).
> > > 
> > > I didn't see any prologue and epilogue for _L_mutex_lock. Do you have
> > > a run-time testcase to show the problem?
> > 
> > I don't have run-time test for this fail, but here is a way to see the 
> > problem:
> > 
> 
> It is very easy to check if stack alignment is correct at run-time.
> Please see how it is done in testcases under gcc.dg/torture/stackalign.

Please find the testcase attached.
It passes on 32 bits and fails on 64 bits (4.7.0 and 4.5.1(RedHat) GCC was
checked).

[Bug middle-end/49373] [4.7 Regression] Many testcase failures

[hp at gcc dot gnu.org]

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

--- Comment #12 from Hans-Peter Nilsson  2011-06-23 
11:52:22 UTC ---
IIUC that's the remaining fail being xfailed; the others are fully covered by
the earlier commits.

[Bug tree-optimization/49513] PRE inhibits if-conversion and vectorization

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||missed-optimization
   Last reconfirmed||2011.06.23 11:55:09
 CC||rguenth at gcc dot gnu.org
 Ever Confirmed|0   |1
Summary|introducing a product   |PRE inhibits if-conversion
   |inhibit vectorization   |and vectorization

--- Comment #1 from Richard Guenther  2011-06-23 
11:55:09 UTC ---
That is because PRE decided to optimize the first iteration where it knows
that z == 0 and thus z*s[i] and z*c[i] are 0 and thus a[i] will be 0.  Which
means we confuse if-conversion which in turn causes this missed vectorization.
IL before if-conversion:

:
  goto ;

:
  z_3 = (float) i_9;
  D.3280_4 = c[i_9];
  D.3281_5 = D.3280_4 * z_3;
  D.3282_6 = s[i_9];
  D.3283_7 = D.3282_6 * z_3;
  yy_13 = ABS_EXPR ;
  yy_14 = ABS_EXPR ;
  if (yy_13 < yy_14)
goto ;
  else
goto ;

:

:
  # yy_28 = PHI 
  # yy_29 = PHI 

:
  # yy_16 = PHI 
  # yy_15 = PHI 
  # i_30 = PHI 
  # ivtmp.44_24 = PHI 
  t_17 = yy_15 / yy_16;
  a[i_30] = t_17;
  i_9 = i_30 + 1;
  ivtmp.44_10 = ivtmp.44_24 - 1;
  if (ivtmp.44_10 != 0)
goto ;
  else
goto ;

:
  return;

The PHI nodes in bb 6 is what makes if-conversion fail (thus, the
irregular loop entry which really should be peeled off).

This situation commonly occurs when PRE can compute the first iterations
result.  Manually peeling off the iteration like the following is a
workaround:

void foo2() {
  a[0] = 0;
  for (int i=1; i!=1024; ++i) {
float z = i;
a[i] = bar(z*s[i],z*c[i]);
 }
}

Not sure if your original issue you derived this testcase from really
matches the above problem though.

[Bug target/49515] [4.7 Regression] gcc.dg/torture/tls/thr-init-2.c -O2 -fpic execution test failure

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug bootstrap/49502] Unable to build gcc with gmp/mpc/mpfr in its tree and flag "--enable-cxx"

[franck.z.bugzilla at orange dot fr]

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

--- Comment #2 from Franck Z  2011-06-23 
12:03:31 UTC ---
Several weeks ago, with the trunk, and gmp/mpc/mpfr/ppl/cloog-ppl in the gcc
source root tree, a "configure" then "make" sequence without options was
stopped because one of the configuration checkings launched by "make" would
fail when checking for the right version of gmp.

Namely, the gmpxx.h file was said to be missing. Along with this error message,
came a reminder not to forget to use "--enable-cxx" flag when configuring gcc.

So I obeyed then. I expected it would generate the proper files needed for a
C++ binding to gmp. However, I was stalled later in the compilation by the
issue of this PR. I ended up with relying on the compiled libs provided with
the Cygwin package. I once managed to end a stage-1 compilation of gcc, but a
subsequent "svn update" from the trunk lead to new build issues.

I would leave my attempts with gcc for 3-4 weeks. Now, with a newer "svn
update" of the trunk (one-two weeks old), stage-1 compilation still doesn't
end.

I try now with gcc 4.6.0. If it fails, I'll fall back to older releases of gcc.

As long as the bootstrap ends, it's enough for my needs for now. I just aim at
trying to outline a "intelligent agent" layer in the source of gcc, so as to
improve disk use and opt out duplicate compilations during a make session. So,
I don't have any specific need for "--enable-cxx". I was just believing to do
the right thing.

Unfortunately, I may have lost track of which "configure" script was needing
gmpxx.h. My ppl/cloog-ppl libs were compliant with those advised in the
pre-requisites (0.11.2 and 0.15.10).

Thank you for any help with my configuration.

[Bug tree-optimization/49513] PRE inhibits if-conversion and vectorization

[vincenzo.innocente at cern dot ch]

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

--- Comment #2 from vincenzo Innocente  
2011-06-23 12:16:59 UTC ---
thanks for the fast analysis.

the code in question was there also to test what the vectorized code would do
for x=0 and y=0 (it is extracted from a simplified version of atan2f that gcc
can vectorize).
Being a test, I can workaround (I've to test extreme conditions explicitely
anyhow).

In any case I think that any peeling will ruin alignmement.

 hoping gcc can find ways to avoid PRE and vectorization to clash.

   vincenzo




On 23 Jun, 2011, at 1:55 PM, rguenth at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49513
> 
> Richard Guenther  changed:
> 
>   What|Removed |Added
> 
> Status|UNCONFIRMED |NEW
>   Keywords||missed-optimization
>   Last reconfirmed||2011.06.23 11:55:09
> CC||rguenth at gcc dot gnu.org
> Ever Confirmed|0   |1
>Summary|introducing a product   |PRE inhibits if-conversion
>   |inhibit vectorization   |and vectorization
> 
> --- Comment #1 from Richard Guenther  2011-06-23 
> 11:55:09 UTC ---
> That is because PRE decided to optimize the first iteration where it knows
> that z == 0 and thus z*s[i] and z*c[i] are 0 and thus a[i] will be 0.  Which
> means we confuse if-conversion which in turn causes this missed vectorization.
> IL before if-conversion:
> 
> :
>  goto ;
> 
> :
>  z_3 = (float) i_9;
>  D.3280_4 = c[i_9];
>  D.3281_5 = D.3280_4 * z_3;
>  D.3282_6 = s[i_9];
>  D.3283_7 = D.3282_6 * z_3;
>  yy_13 = ABS_EXPR ;
>  yy_14 = ABS_EXPR ;
>  if (yy_13 < yy_14)
>goto ;
>  else
>goto ;
> 
> :
> 
> :
>  # yy_28 = PHI 
>  # yy_29 = PHI 
> 
> :
>  # yy_16 = PHI 
>  # yy_15 = PHI 
>  # i_30 = PHI 
>  # ivtmp.44_24 = PHI 
>  t_17 = yy_15 / yy_16;
>  a[i_30] = t_17;
>  i_9 = i_30 + 1;
>  ivtmp.44_10 = ivtmp.44_24 - 1;
>  if (ivtmp.44_10 != 0)
>goto ;
>  else
>goto ;
> 
> :
>  return;
> 
> The PHI nodes in bb 6 is what makes if-conversion fail (thus, the
> irregular loop entry which really should be peeled off).
> 
> This situation commonly occurs when PRE can compute the first iterations
> result.  Manually peeling off the iteration like the following is a
> workaround:
> 
> void foo2() {
>  a[0] = 0;
>  for (int i=1; i!=1024; ++i) {
>float z = i;
>a[i] = bar(z*s[i],z*c[i]);
> }
> }
> 
> Not sure if your original issue you derived this testcase from really
> matches the above problem though.
> 
> -- 
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You reported the bug.

--
Il est bon de suivre sa pente, pourvu que ce soit en montant. 
A.G.
http://www.flickr.com/photos/vin60/1320965757/

[Bug testsuite/49503] Incorrect stack alignment, produced by inline assembler in tests gcc.target/i386/cleanup-1.c and gcc.target/i386/cleanup-2.c

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  2011-06-23 12:45:31 
UTC ---
(In reply to comment #4)
> Created attachment 24584 [details]
> Test showing that cleanup-* tests are not quite correct.

Wrong test.  You don't know the alignment of buf.
You should put an alignment attribute on buf.

[Bug tree-optimization/49513] DOM inhibits if-conversion and vectorization

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
Summary|PRE inhibits if-conversion  |DOM inhibits if-conversion
   |and vectorization   |and vectorization

--- Comment #3 from Richard Guenther  2011-06-23 
12:58:44 UTC ---
(In reply to comment #2)
> thanks for the fast analysis.
> 
> the code in question was there also to test what the vectorized code would do
> for x=0 and y=0 (it is extracted from a simplified version of atan2f that gcc
> can vectorize).
> Being a test, I can workaround (I've to test extreme conditions explicitely
> anyhow).
> 
> In any case I think that any peeling will ruin alignmement.
> 
>  hoping gcc can find ways to avoid PRE and vectorization to clash.

I had a closer look and it is DOM jump-threading which creates this
rotated loop.  CCin Jeff who was working in this area - PRE avoids
this kind of transformation.  Jeff - can we avoid threading through
the loop header somehow?

[Bug middle-end/49465] [4.7 Regression] Revision 175114 miscompiled 403.gcc in SPEC CPU 2006

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  2011-06-23 13:05:29 
UTC ---
(In reply to comment #3)
> Fix looking good.  Doing a cpu2k6 int test right now.

Hi Jeff, can I try your patch on my machine? Thanks.

[Bug target/49497] Incorrect lea peephole

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #4 from H.J. Lu  2011-06-23 13:12:01 
UTC ---
Fixed.

[Bug middle-end/35561] Promote written once local aggregates to static

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  2011-06-23 
13:31:01 UTC ---
Well, we could still optimize it e.g. in leaf functions or in functions that
only call leaf functions (__attribute__((leaf))).  But we do this
transformation during gimplification, so either we'd need to add an
optimization that would turn an automatic aggregate into static aggregate if
possible and useful later on (in particular, if it is determined to be never
written into and its value doesn't escape current function or current function
is leaf or only calls leaf functions and doesn't tail recurse), or we'd need to
do some analysis right before gimplification starts to find out if a function
must be leaf or only call leaf functions.

[Bug tree-optimization/49516] New: SRA generates memory references into its replacements

[jamborm at gcc dot gnu.org]

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

   Summary: SRA generates memory references into its replacements
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jamb...@gcc.gnu.org


When SRA tries to modify an assignment where on one side it should put
one new scalar replacement but the other is actually an aggregate with
a number of replacements for it, it will generate a MEM-REF into the
former replacement which can lead to miscompilations.

Originally reported here by Xinliang David Li:
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01380.html

I have only slightly changed the original testcase so that it does not
require any includes and will attach it shortly.

[Bug tree-optimization/49516] SRA generates memory references into its replacements

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.06.23 13:54:45
 AssignedTo|unassigned at gcc dot   |jamborm at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Martin Jambor  2011-06-23 
13:54:45 UTC ---
Created attachment 24585
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24585
Testcase

This is the testcase.

[Bug bootstrap/49502] Unable to build gcc with gmp/mpc/mpfr in its tree and flag "--enable-cxx"

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2011-06-23 
13:58:41 UTC ---
(In reply to comment #2)
> Namely, the gmpxx.h file was said to be missing. Along with this error 
> message,
> came a reminder not to forget to use "--enable-cxx" flag when configuring gcc.

I don't know where that message came from, because --enable-cxx is not a gcc
configure option, see http://gcc.gnu.org/install/configure.html

> So I obeyed then. I expected it would generate the proper files needed for a
> C++ binding to gmp.

GCC doesn't need a C++ binding to GMP.

> Unfortunately, I may have lost track of which "configure" script was needing
> gmpxx.h. My ppl/cloog-ppl libs were compliant with those advised in the
> pre-requisites (0.11.2 and 0.15.10).

cloog and ppl are optional, if you can't get it to build with them why not try
without them?

[Bug middle-end/49463] [4.7 Regression] LTO testcase failures

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  2011-06-23 14:04:25 
UTC ---
With the latest binutils, I still got

Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/
/export/gnu/import/git/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/strstr-asm.c
/export/gnu/import/git/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/strstr-asm-lib.c
/export/gnu/import/git/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c
 -w  -O2 -flto -flto-partition=none   -lm   -m32 -o
/export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/gcc/strstr-asm.x6   
(timeout = 300)
spawn -ignore SIGHUP /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/
/export/gnu/import/git/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/strstr-asm.c
/export/gnu/import/git/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/strstr-asm-lib.c
/export/gnu/import/git/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c
-w -O2 -flto -flto-partition=none -lm -m32 -o
/export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/gcc/strstr-asm.x6^M
`my_strstr' referenced in section `.text.startup' of /tmp/ccALUDUU.lto.o:
defined in discarded section `.text' of /tmp/ccM5l8Wd.o (symbol from plugin)^M
collect2: error: ld returned 1 exit status^M
compiler exited with status 1

[Bug middle-end/49378] [4.7 Regression] C++ is broken

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #7 from H.J. Lu  2011-06-23 14:10:02 
UTC ---
Fixed.

[Bug c++/49507] [4.6/4.7 Regression] ICE because of defaulted template destructor

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  2011-06-23 
14:28:00 UTC ---
For 4.6.1 let's just revert r174159.  Will you do that or shall I?

[Bug rtl-optimization/49504] Invalid optimization for Pmode != ptr_mode

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  2011-06-23 14:52:40 
UTC ---
*** Bug 49088 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/49088] Combine fails to properly handle zero-extension and signed int constant

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #11 from H.J. Lu  2011-06-23 14:52:40 
UTC ---
Dup

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

[Bug rtl-optimization/49088] Combine fails to properly handle zero-extension and signed int constant

[hjl at gcc dot gnu.org]

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

--- Comment #12 from hjl at gcc dot gnu.org  2011-06-23 
14:57:50 UTC ---
Author: hjl
Date: Thu Jun 23 14:57:45 2011
New Revision: 175335

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175335
Log:
Revert the last change on force_to_mode.

2011-06-23  H.J. Lu  

PR rtl-optimization/49088
* combine.c (force_to_mode): Revert the last change.

Modified:
branches/x32/gcc/ChangeLog.x32
branches/x32/gcc/combine.c

[Bug c++/49507] [4.6/4.7 Regression] ICE because of defaulted template destructor

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  2011-06-23 
15:10:01 UTC ---
Created attachment 24586
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24586
fix

Actually, this patch seems safe enough for 4.6.1.  Testing now.

[Bug fortran/24526] renamed variables from modules not visible in gdb

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Last reconfirmed|2006-01-29 17:55:51 |2011-06-21 16:00
Summary|variables from modules not  |renamed variables from
   |visible in gdb  |modules not visible in gdb

--- Comment #6 from Thomas Koenig  2011-06-23 
15:33:31 UTC ---
Things work now without variable renaming, but with it,
they sometimes don't work.  Adjusting subject.

ig25@linux-fd1f:~/Krempel/GDB> cat rename.f90
module foo   
  implicit none  
  integer :: a_foo = 3   
  integer :: b_foo = 4   
end module foo   

module bar
  use foo, only : b_bar => b_foo
  implicit none
end module bar

module baz
  implicit none
  integer :: c_baz = 5
end module baz

program main
  use foo, only : a_main => a_foo
  use bar, only : b_main => b_bar
  use baz,  c_main => c_baz
  implicit none
  print *, a_main
  print *, b_main
  print *, c_main
end program main
ig25@linux-fd1f:~/Krempel/GDB> gdb ./a.out
GNU gdb (GDB) SUSE (6.8.91.20090930-2.4)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-suse-linux".
For bug reporting instructions, please see:
...
Reading symbols from /home/ig25/Krempel/GDB/a.out...done.
(gdb) b MAIN__
Breakpoint 1 at 0x40075f: file rename.f90, line 22.
(gdb) r
Starting program: /home/ig25/Krempel/GDB/a.out
warning: the debug information found in
"/usr/lib/debug//lib64/ld-2.10.1.so.debug" does not match
"/lib64/ld-linux-x86-64.so.2" (CRC mismatch).

warning: the debug information found in
"/usr/lib/debug/lib64/ld-2.10.1.so.debug" does not match
"/lib64/ld-linux-x86-64.so.2" (CRC mismatch).

Missing separate debuginfo for /lib64/ld-linux-x86-64.so.2
Try: zypper install -C
"debuginfo(build-id)=a121943782877c885215a25513d6bf0bfb6b6723"
warning: the debug information found in
"/usr/lib/debug//lib64/libc-2.10.1.so.debug" does not match "/lib64/libc.so.6"
(CRC mismatch).

warning: the debug information found in
"/usr/lib/debug/lib64/libc-2.10.1.so.debug" does not match "/lib64/libc.so.6"
(CRC mismatch).

Missing separate debuginfo for /lib64/libc.so.6
Try: zypper install -C
"debuginfo(build-id)=a4762e3dc63d9d17b92a985d53410c4931774ebc"

Breakpoint 1, MAIN__ () at rename.f90:22
22print *, a_main
Current language:  auto
The current source language is "auto; currently fortran".
(gdb) p a_main
$1 = 3
(gdb) p b_main
No symbol "b_main" in current context.
(gdb) p c_main
No symbol "c_main" in current context.
(gdb)

[Bug target/49515] [4.7 Regression] gcc.dg/torture/tls/thr-init-2.c -O2 -fpic execution test failure

[rth at gcc dot gnu.org]

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

--- Comment #1 from Richard Henderson  2011-06-23 
15:39:19 UTC ---
(In reply to comment #0)
> Does !dtprello relocation need live $16 register? The relevant patterns in
> alpha.md do not model that dependancy.

No, DTPREL relocations are constants.  They are the offset to be added
to a TLSLDM base value.  You can see that happening both in the old and
new code sequences.

The code difference you show cannot be the real problem.  The register
allocator has made a poorer choice in 4.7, leading to an extra move,
but the code that you show is exactly equivalent.

Is linker relaxation messing with this code sequence, perhaps?

[Bug testsuite/49503] Incorrect stack alignment, produced by inline assembler in tests gcc.target/i386/cleanup-1.c and gcc.target/i386/cleanup-2.c

[michael.v.zolotukhin at gmail dot com]

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

--- Comment #7 from Michael Zolotukhin  
2011-06-23 16:00:36 UTC ---
Created attachment 24587
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24587
Fixed cleanup-regression.c

[Bug testsuite/49503] Incorrect stack alignment, produced by inline assembler in tests gcc.target/i386/cleanup-1.c and gcc.target/i386/cleanup-2.c

[michael.v.zolotukhin at gmail dot com]

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

--- Comment #8 from Michael Zolotukhin  
2011-06-23 16:03:32 UTC ---
(In reply to comment #6)
> (In reply to comment #4)
> > Created attachment 24584 [details]
> > Test showing that cleanup-* tests are not quite correct.
> 
> Wrong test.  You don't know the alignment of buf.
> You should put an alignment attribute on buf.

I added new test, with align attribute.
Compiler sometimes could make stack aligned (accidentally), and the bug
wouldn't show up.
To watch the fail, try use following command line:
gcc cleanup-regression-2.c -O0 -lm -fno-inline -fexceptions
-fnon-call-exceptions -fasynchronous-unwind-tables && ./a.out

[Bug fortran/49509] cannot promote types for arguments passed by value

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #9 from Tobias Burnus  2011-06-23 
16:06:24 UTC ---
Cf.
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/b0ffeb2f0d07d7a7#

[Bug fortran/24526] renamed variables from modules not visible in gdb

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #7 from Tobias Burnus  2011-06-23 
16:12:00 UTC ---
My impression is that this is a bug in GDB and not in GCC (cf. readelf output
below). For the following program, the result is: myvar is not found and gdb
prints the wrong variable of the two "var33": Namely, the renamed one from
"mod" and not the one of "mod2". Using "mod::var33" and "mod2::var33" works as
expected. 

14print *, myvar
(gdb)
  33
15print *, var33
(gdb)
 -42
16  end program test
(gdb) p var33
$1 = 33
(gdb) p myvar
No symbol "myvar" in current context. 



Test program:

module mod
  integer :: var11 = 11, var22 = 22, var33 = 33
end module mod

module mod2
  integer :: var33 = -42
end module mod2

program test
  use mod, myvar => var33
  use mod2 ! imports var33 == -42
  implicit none
  print *, var11  ! prints: 11
  print *, myvar  ! prints: 33
  print *, var33  ! prints: -42
end program test


Readelf looks as follows:

 [   12f]subprogram
...
 sibling  (ref4) [   1a5]
 [   153]  imported_module
   decl_file(data1) 1
   decl_line(data1) 11
   import   (ref4) [   1a5]
 [   15a]  imported_module
   decl_file(data1) 1
   decl_line(data1) 10
   import   (ref4) [   1cb]
   sibling  (ref4) [   171]
 [   165]imported_declaration
 decl_file(data1) 1
 decl_line(data1) 10
 name (strp) "myvar"
 import   (ref4) [   1d6]

[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them

[ian at airs dot com]

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

--- Comment #65 from Ian Lance Taylor  2011-06-23 16:22:05 
UTC ---
The mainline versions of both GNU ld and gold now put .ctors sections into
.init_array sections, and put .dtors sections into .fini_array sections. 
.ctors/.dtors sections with priorities are sorted correctly with
.init_array/.fini_array sections with priorities.

The gcc patch is still useful as it will permit eliminating the support for
constructors and destructors in crtbegin.o and crtend.o.  If we can do that I
believe that crtend.o can be removed, and crtbegin.o will only be needed to
call 
_Jv_RegisterClasses.

[Bug middle-end/49463] [4.7 Regression] LTO doesn't work symbol renamed via asm statement

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka  2011-06-23 
16:40:40 UTC ---
"Fix" for strstr-asm.c posted at
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01794.html

I will look into the TLS testcases next.

Honza

[Bug middle-end/49463] [4.7 Regression] LTO doesn't work symbol renamed via asm statement

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  2011-06-23 16:42:42 
UTC ---
(In reply to comment #3)
>
> I will look into the TLS testcases next.
> 

They are fixed by the new linker.

[Bug middle-end/49373] [4.7 Regression] Many testcase failures

[hubicka at gcc dot gnu.org]

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

--- Comment #13 from Jan Hubicka  2011-06-23 
16:45:15 UTC ---
Author: hubicka
Date: Thu Jun 23 16:45:08 2011
New Revision: 175336

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175336
Log:
PR tree-optimize/49373
* tree-pass.h (all_late_ipa_passes): Declare.
* cgraphunit.c (init_lowered_empty_function): Fix properties.
(cgraph_optimize): Execute late passes; remove unreachable funcions after
materialization.
* ipa-inline.c (gate_ipa_inline): Enable only when optimizing or LTOing.
* passes.c (all_late_ipa_passes): Declare.
(dump_passes, register_pass): Handle late ipa passes.
(init_optimization_passes): Move ipa_pta to late passes; schedule fixup_cfg
at beggining of all_passes.
(apply_ipa_transforms): New function.
(execute_one_pass): When doing simple ipa pass, apply all transforms.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraphunit.c
trunk/gcc/ipa-inline.c
trunk/gcc/passes.c
trunk/gcc/tree-pass.h

[Bug middle-end/49463] [4.7 Regression] LTO doesn't work symbol renamed via asm statement

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka  2011-06-23 
16:48:32 UTC ---
Good to know.  I was just about to ask how to reproduce it.
Thanks ;)

[Bug c++/36435] Partial ordering of explicit specialization should include return type

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  2011-06-23 
16:52:36 UTC ---
Author: jason
Date: Thu Jun 23 16:52:32 2011
New Revision: 175338

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175338
Log:
PR c++/36435
* pt.c (most_specialized_instantiation): Do check return types.

Added:
trunk/gcc/testsuite/g++.dg/template/partial9.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/49507] [4.6/4.7 Regression] ICE because of defaulted template destructor

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  2011-06-23 
16:56:31 UTC ---
Author: jason
Date: Thu Jun 23 16:56:27 2011
New Revision: 175343

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175343
Log:
PR c++/49507
* decl2.c (mark_used): Don't call synthesize_method for
functions defaulted outside the class.

Added:
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/defaulted30.C
Modified:
branches/gcc-4_6-branch/gcc/cp/ChangeLog
branches/gcc-4_6-branch/gcc/cp/decl2.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug c++/49440] [4.5/4.6/4.7 regression] Invalid dynamic_cast for unnamed namespace

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  2011-06-23 
16:52:52 UTC ---
Author: jason
Date: Thu Jun 23 16:52:48 2011
New Revision: 175340

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175340
Log:
PR c++/49440
* class.c (set_linkage_according_to_type): Just check TREE_PUBLIC
on the type's name.

Added:
trunk/gcc/testsuite/g++.dg/rtti/anon-ns1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/44625] [4.3/4.4/4.5/4.6/4.7 Regression] ICE after error: anonymous struct not inside named type

[paolo at gcc dot gnu.org]

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

--- Comment #7 from paolo at gcc dot gnu.org  
2011-06-23 16:58:31 UTC ---
Author: paolo
Date: Thu Jun 23 16:58:28 2011
New Revision: 175344

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175344
Log:
/cp
2011-06-23  Paolo Carlini  

PR c++/44625
* decl2.c (build_anon_union_vars): Early return error_mark_node
for a nested anonymous struct.

/testsuite
2011-06-23  Paolo Carlini  

PR c++/44625
* g++.dg/template/crash107.C: New.
* g++.dg/template/error17.C: Adjust.

Added:
trunk/gcc/testsuite/g++.dg/template/crash107.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/template/error17.C

[Bug c++/44625] [4.3/4.4/4.5/4.6 Regression] ICE after error: anonymous struct not inside named type

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||4.7.0
 Resolution||FIXED
   Target Milestone|4.3.6   |4.7.0
Summary|[4.3/4.4/4.5/4.6/4.7|[4.3/4.4/4.5/4.6
   |Regression] ICE after   |Regression] ICE after
   |error: anonymous struct not |error: anonymous struct not
   |inside named type   |inside named type

--- Comment #8 from Paolo Carlini  2011-06-23 
17:00:55 UTC ---
Fixed for 4.7.0.

[Bug c++/49395] Non-class prvalues seem to have cv-qualification with GCC

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  2011-06-23 
16:52:44 UTC ---
Author: jason
Date: Thu Jun 23 16:52:41 2011
New Revision: 175339

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175339
Log:
PR c++/49395
* init.c (build_zero_init_1): Strip cv-quals from scalar types.

Added:
trunk/gcc/testsuite/g++.dg/init/ref18.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/49395] Non-class prvalues seem to have cv-qualification with GCC

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  2011-06-23 
17:09:18 UTC ---
Fixed line 10.

[Bug bootstrap/49383] [4.7 regression] powerpc64-linux bootstrap failure due to ice in cgraph_only_called_directly_p

[hubicka at ucw dot cz]

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

--- Comment #8 from Jan Hubicka  2011-06-23 17:09:43 UTC 
---
Hi,
sorry for late reply, I was not reading bugs ML very curefully on the GCC
gathering...
> Honza, the code here is called during expansion of functions.  If called at 
> the
> start of a function body, the function is attempting to answer the question:
> Can this function be called from anywhere external to this object file?
> If called for the expansion of a call then the question is:
> Can this function call go to a function external to this object file?
> Then, once those questions are answered, further code checks whether function
> arguments and return value might be affected by the ABI in force.
> 
> We aren't at all interested in local functions, so I don't think c_node->local
> and c_node->can_change_signature are relevant.  At least, I don't see that 
> they
> give any more information than cgraph_only_called_directly_p relevant to the
> questions call_ABI_of_interest is trying to answer.

Hmm, it seems that I managed to invent here quite confusing variants of same
test.
Ideas for improvements here are certainly welcome.

Function is local if
 a) it is not having address taken
 b) it is not exported from current unit
 c) it is locally defined
 d) it is not extern inline function.
 e) it is not static ctor or dtor 

Function is only called directly must match a,b,c and e. I.e. it can be extern
inline
and this fact is useful for i.e. ipa-cp cloning decisions.

This however makes no difference at backend compilation, since all offline
copies of extern inlines are eliminated by that time. So when not doing WHOPR
both predicates are equivalent at the time you are querying them.

Main difference is that locality is defined at WPA time, while
cgraph_only_called_directly_p is computed from cgraph.  This means that in
WHOPR
when you have function A only called directly from function B and functoin A
goes
into partition 1 while, function B into partition 2,
cgraph_only_called_directly_p
at the ltrans stage will return 0, while the function will still be local.

i386 backend use the locality test to alter the ABI and it can consequentely
use
the register calling conventions cross the ltrans boubdaries (relying that both
parallel ltrans compilation will make the same decisions to alter the ABI).
I am not sure what call_ABI_of_interest control, really, but I can't imagine
it being too different from i386 case.

Honza

[Bug regression/49500] [4.7 Regression]: gcc.dg/tls/alias-1.c

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #3 from Jan Hubicka  2011-06-23 
17:11:45 UTC ---
This is most certainly mine, caused by varpool alias reorg removing some
seemingly nonsential tests in the finalization process.  This problem has
appeared once before because emultls is introducing variables without making
any visible references to them and then it introduces the references at
expansion time.  I will try to reproduce this in a crosscopmiler and try to
think of some more robust way of fixing this issue.

[Bug c++/49507] [4.6/4.7 Regression] ICE because of defaulted template destructor

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  2011-06-23 
16:53:06 UTC ---
Author: jason
Date: Thu Jun 23 16:53:03 2011
New Revision: 175342

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175342
Log:
PR c++/49507
* decl2.c (mark_used): Don't call synthesize_method for
functions defaulted outside the class.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/defaulted30.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/testsuite/ChangeLog

[Bug translation/49517] New: Translation string typo in config/rx/rx.c

[stigge at antcom dot de]

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

   Summary: Translation string typo in config/rx/rx.c
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sti...@antcom.de


Created attachment 24588
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24588
Typo fix in rx.c

Typo, see attached patch.

[Bug c++/38089] [4.3/4.4 Regression] g++ crash on invalid code

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #10 from Paolo Carlini  2011-06-23 
18:01:18 UTC ---
Fixed.

[Bug c++/38089] [4.3/4.4 Regression] g++ crash on invalid code

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Target Milestone|4.3.6   |4.5.0

[Bug c++/43081] [4.3/4.4 regression] ICE with invalid in-class initializer

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|4.3.6   |4.5.0

--- Comment #9 from Paolo Carlini  2011-06-23 
18:05:00 UTC ---
Fixed in 4.5.0.

[Bug c++/38646] [4.3/4.4 regression] ICE with invalid specialization of variadic template

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.5.0
 Resolution||FIXED
   Target Milestone|4.3.6   |4.5.0

--- Comment #12 from Paolo Carlini  2011-06-23 
18:02:21 UTC ---
Fixed in 4.5.0.

[Bug c++/42054] [4.3/4.4 Regression] ICE with invalid template parameter

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.5.0
 Resolution||FIXED
   Target Milestone|4.3.6   |4.5.0

--- Comment #6 from Paolo Carlini  2011-06-23 
18:04:15 UTC ---
Fixed in 4.5.0.

[Bug c++/46538] [4.3 Regression] ICE: SIGSEGV in cp_make_fname_decl (decl.c:3690) on invalid code when using __PRETTY_FUNCTION__

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||4.4.6
 Resolution||FIXED
Summary|[4.3/4.4 Regression] ICE:   |[4.3 Regression] ICE:
   |SIGSEGV in  |SIGSEGV in
   |cp_make_fname_decl  |cp_make_fname_decl
   |(decl.c:3690) on invalid|(decl.c:3690) on invalid
   |code when using |code when using
   |__PRETTY_FUNCTION__ |__PRETTY_FUNCTION__

--- Comment #4 from Paolo Carlini  2011-06-23 
18:09:43 UTC ---
Fixed in 4.4.6.

[Bug bootstrap/49502] Unable to build gcc with gmp/mpc/mpfr in its tree and flag "--enable-cxx"

[franck.z.bugzilla at orange dot fr]

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

--- Comment #4 from Franck Z  2011-06-23 
18:45:33 UTC ---
(In reply to comment #3)

gotcha!

It's in PPL's configure script.
When checking for the correct version of gmp, the line:

#include 

is used several times and this is what choked my building session.

Later the script analyses the error and advises --enable-cxx (it's around the
middle of the script):

if test x"$have_gmp" = xno
then
  as_fn_error "Cannot find GMP version 4.1.3 or higher.
GMP is the GNU Multi-Precision library:
see http://www.swox.com/gmp/ for more information.
When compiling the GMP library, do not forget to enable the C++ interface:
add --enable-cxx to the configuration options." "$LINENO" 5
else
  if test x"$have_gmpxx" = xno
  then
as_fn_error "GMP compiled without enabling the C++ interface.
GMP is the GNU Multi-Precision library:
see http://www.swox.com/gmp/ for more information.
When compiling the GMP library, do not forget to enable the C++ interface:
add --enable-cxx to the configuration options." "$LINENO" 5
  fi
fi

Now, apparently, as I separate the output of the compilation in a special
"objdir" directory, gmpxx.h can't be found with the paths in objdir/gmp/
because only gmp.h and mp.h are placed there. gmpxx.h is copied later from the
source directory by gmp with the "make install" command.

I should write also that this script didn't mention the absence of gmpxx.h in
objdir when a system version of gmp was already installed, for instance in
/usr/local/lib & /usr/local/include. Ominous, no?

That being said. I'll keep away from PPL and Cloog as you suggests... ^o^ ...
until I know more my way in gcc.

(--enable-cxx is indeed referenced in the pdf manual of gmp, p.6)

[Bug testsuite/49512] [4.7 Regression] FAIL: gcc.dg/tree-ssa/asm-1.c

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2011-06-23 
18:51:52 UTC ---
Author: jakub
Date: Thu Jun 23 18:51:49 2011
New Revision: 175347

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175347
Log:
PR testsuite/49512
* gcc.dg/tree-ssa/asm-1.c: Use -fdump-tree-optimized-nouid
instead of -fdump-tree-optimized.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/asm-1.c

[Bug c++/46400] g++ Segmentation Fault on heavily templated project.

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #8 from Paolo Carlini  2011-06-23 
19:28:53 UTC ---
Richard, what should we do here?

[Bug c/48091] No warning when given function arguments mismatch earlier function definition which GCC assumes to be K&R, even with --std=c99 -pedantic

[eerott at gmail dot com]

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

Eero Tamminen  changed:

   What|Removed |Added

Summary|No warning when given   |No warning when given
   |function arguments mismatch |function arguments mismatch
   |earlier function definition |earlier function definition
   |which GCC assumes to be K&R |which GCC assumes to be
   ||K&R, even with --std=c99
   ||-pedantic

--- Comment #4 from Eero Tamminen  2011-06-23 19:28:45 
UTC ---
(In reply to comment #0)
> Program:
> --
> int test(a, b)
> int a;
> int b;
> {
> return a+b;
> }
> int main(void)
> {
> return test("foo");
> }
> --

(In reply to comment #1)
> That's how K&R works.  The function definition isn't a prototype.

Right, including an ANSI-C prototype either for:
  int test(int a, int b);

or for:
  int test(const char *);

Would cause there to be a warning.  I would never have though somebody to mix
K&R & ANSI-C like that, but I just noticed that having K&R function
implementations in *.c files with ANSI-C prototypes in headers seems to be e.g.
how Glibc does things...


It still doesn't help with mistakes like "function() { ... }" for people who
have experience with other compilers than GCC.  GCC is only compiler with this
dangerous defaulting to K&R interpretation.

[Bug bootstrap/49502] Unable to build gcc with gmp/mpc/mpfr in its tree and flag "--enable-cxx"

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID

--- Comment #5 from Jonathan Wakely  2011-06-23 
19:40:42 UTC ---
(In reply to comment #4)
> When compiling the GMP library, do not forget to enable the C++ interface:

When compiling *GMP* not when compiling GCC.

> add --enable-cxx to the configuration options." "$LINENO" 5
>   fi
> fi
> 
> Now, apparently, as I separate the output of the compilation in a special
> "objdir" directory, gmpxx.h can't be found with the paths in objdir/gmp/
> because only gmp.h and mp.h are placed there. gmpxx.h is copied later from the
> source directory by gmp with the "make install" command.

Are you trying to build ppl and cloog in-tree? that doesn't work, notice that
the prerequisites page says you can put gmp, mpfr and mpc in-tree, but not ppl
and cloog:
http://gcc.gnu.org/install/prerequisites.html

To build ppl you need GMP already installed, with C++ support.

If you build GCC with GMP in-tree, you don't get GMP installed, it's just
linked into GCC.

So of course PPL finds the system gmpxx.h because that's the only one you have
installed.


> I should write also that this script didn't mention the absence of gmpxx.h in
> objdir when a system version of gmp was already installed, for instance in
> /usr/local/lib & /usr/local/include. Ominous, no?
> 
> That being said. I'll keep away from PPL and Cloog as you suggests... ^o^ ...
> until I know more my way in gcc.

I think that's best.

> (--enable-cxx is indeed referenced in the pdf manual of gmp, p.6)

Of course, it's a GMP configure option. It's not a valid GCC one, thus this PR
is invalid.

[Bug middle-end/49373] [4.7 Regression] Many testcase failures

[hubicka at gcc dot gnu.org]

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

--- Comment #14 from Jan Hubicka  2011-06-23 
19:41:30 UTC ---
Author: hubicka
Date: Thu Jun 23 19:41:26 2011
New Revision: 175350

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175350
Log:
PR middle-end/49373
* g++.dg/torture/pr43879-1_1.C: Revert the xfail introduced yesterday.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/torture/pr43879-1_1.C

[Bug regression/49500] [4.7 Regression]: gcc.dg/tls/alias-1.c

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka  2011-06-23 
19:43:09 UTC ---
Created attachment 24589
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24589
proposed patch

Hi,
the problem is that emultls introduces aliases later and it does not understand
the new representation of them.  Does the attached patch help?

Honza

[Bug middle-end/49373] [4.7 Regression] Many testcase failures

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||jakub at redhat dot com

--- Comment #15 from Jan Hubicka  2011-06-23 
19:52:02 UTC ---
OK, I think all the problems are fixed with exception of 

FAIL: gcc.dg/guality/vla-1.c  -O2 -flto  line 17 sizeof (a) == 6
FAIL: gcc.dg/guality/vla-1.c  -O2 -flto -flto-partition=none  line 17 sizeof

Jakub, do you have any idea what gets wrong here? vla-2.c fails with LTO for a
while and I don't see what can possibly be affected by the patch of mine.

Honza

[Bug tree-optimization/49516] SRA generates memory references into its replacements

[jamborm at gcc dot gnu.org]

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

--- Comment #2 from Martin Jambor  2011-06-23 
19:57:05 UTC ---
Fix submitted as http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01816.html

[Bug testsuite/49503] Incorrect stack alignment, produced by inline assembler in tests gcc.target/i386/cleanup-1.c and gcc.target/i386/cleanup-2.c

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||jakub at redhat dot com

--- Comment #9 from H.J. Lu  2011-06-23 20:15:44 
UTC ---
(In reply to comment #0)
> The tests contain asm-listing like this:
> __asm (
>   testl  %0, %0
>   jnz1f
>   .subsection 1
>   .type  _L_mutex_lock_%=, @function
> _L_mutex_lock_%=:
> 1:leaq   %1, %%rdi
> 2:subq   $128, %%rsp
> 3:call   bar
> 4:addq   $128, %%rsp
> 5:jmp21f
> ...
> 

The bug is in testcase.  When _L_mutex_lock_ calls bar, it didn't
align stack to 16byte.  But I don't think it matters here. Jakub,
do we need to fix it?

[Bug testsuite/49503] Incorrect stack alignment, produced by inline assembler in tests gcc.target/i386/cleanup-1.c and gcc.target/i386/cleanup-2.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  2011-06-23 
20:26:06 UTC ---
The testcase tests what glibc does, so IMHO it should stay as is.  None of the
functions that are called with misaligned stack actually really require it to
be aligned.

[Bug middle-end/49465] [4.7 Regression] Revision 175114 miscompiled 403.gcc in SPEC CPU 2006

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #8 from Jeffrey A. Law  2011-06-23 20:26:57 
UTC ---
Fixed per patch.

[Bug middle-end/49465] [4.7 Regression] Revision 175114 miscompiled 403.gcc in SPEC CPU 2006

[law at gcc dot gnu.org]

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

--- Comment #6 from Jeffrey A. Law  2011-06-23 20:26:10 
UTC ---
Author: law
Date: Thu Jun 23 20:26:07 2011
New Revision: 175351

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

PR middle-end/49465
* tree-ssa-threadupate.c (fix_duplicate_block_edges): Fix condition
to detect threading through joiner block.  If there was already
an edge to the new target, then do not change the PHI nodes.

*** fix_duplicate_block_edges (struct redire

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-threadupdate.c

[Bug middle-end/49465] [4.7 Regression] Revision 175114 miscompiled 403.gcc in SPEC CPU 2006

[law at redhat dot com]

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

--- Comment #7 from Jeffrey A. Law  2011-06-23 20:26:32 
UTC ---
Fixed.

[Bug middle-end/49465] [4.7 Regression] Revision 175114 miscompiled 403.gcc in SPEC CPU 2006

[law at gcc dot gnu.org]

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

--- Comment #9 from Jeffrey A. Law  2011-06-23 21:26:08 
UTC ---
Author: law
Date: Thu Jun 23 21:26:04 2011
New Revision: 175352

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

PR middle-end/49465
* tree-ssa-threadupate.c (fix_duplicate_block_edges): Fix condition
to detect threading through joiner block.  If there was already
an edge to the new target, then do not change the PHI nodes.


Modified:
trunk/gcc/ChangeLog

[Bug middle-end/48770] [4.7 Regression] wrong code with -O -fprofile-arcs -fPIC -fno-dce -fno-forward-propagate -fno-tree-forwprop

[law at gcc dot gnu.org]

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

--- Comment #7 from Jeffrey A. Law  2011-06-23 21:30:23 
UTC ---
Author: law
Date: Thu Jun 23 21:30:20 2011
New Revision: 175353

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

PR middle-end/48770
* reload.h (reload): Change to return a bool.
* ira.c (ira): If requested by reload, run a fast DCE pass after
reload has completed.  Fix comment typo.
* reload1.c (need_dce): New file scoped static.
(reload): Set reload_completed here.  Return whether or not a DCE
pass after reload is needed.
(delete_dead_insn): Set need_dce as needed.

PR middle-end/48770
* gcc.dg/pr48770.c: New test.



Added:
trunk/gcc/testsuite/gcc.dg/pr48770.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira.c
trunk/gcc/reload.h
trunk/gcc/reload1.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/48770] [4.7 Regression] wrong code with -O -fprofile-arcs -fPIC -fno-dce -fno-forward-propagate -fno-tree-forwprop

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #8 from Jeffrey A. Law  2011-06-23 21:31:31 
UTC ---
Fixed

[Bug regression/49500] [4.7 Regression]: gcc.dg/tls/alias-1.c

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #5 from dave at hiauly1 dot hia.nrc.ca 2011-06-23 21:36:05 UTC ---
On Thu, 23 Jun 2011, hubicka at gcc dot gnu.org wrote:

> Hi,
> the problem is that emultls introduces aliases later and it does not 
> understand
> the new representation of them.  Does the attached patch help?

There is a warning which may not be new:

../../gcc/gcc/tree-emutls.c: In function 'ipa_lower_emutls':
../../gcc/gcc/tree-emutls.c:776: warning: 'cvar' may be used uninitialized in
this function

Dave

[Bug testsuite/49503] Incorrect stack alignment, produced by inline assembler in tests gcc.target/i386/cleanup-1.c and gcc.target/i386/cleanup-2.c

[hjl.tools at gmail dot com]

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

--- Comment #11 from H.J. Lu  2011-06-23 22:03:49 
UTC ---
(In reply to comment #10)
> The testcase tests what glibc does, so IMHO it should stay as is.  None of the
> functions that are called with misaligned stack actually really require it to
> be aligned.

But gcc may generate SSE codes and assume stack is 16byte aligned,
which leads to segfault.

[Bug c/49518] New: ICE in vect_enhance_data_refs_alignment, at tree-vect-data-refs.c:1555

[regehr at cs dot utah.edu]

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

   Summary: ICE in vect_enhance_data_refs_alignment, at
tree-vect-data-refs.c:1555
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reg...@cs.utah.edu
CC: cheny...@cs.utah.edu
  Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
 Build: x86_64-unknown-linux-gnu


[regehr@gamow tmp032]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r175350-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r175350-install
--program-prefix=r175350- --enable-languages=c,c++
Thread model: posix
gcc version 4.7.0 20110623 (experimental) (GCC) 
[regehr@gamow tmp032]$ 
[regehr@gamow tmp032]$ 
[regehr@gamow tmp032]$ 
[regehr@gamow tmp032]$ current-gcc -O3 small.c -c
small.c: In function 'un_':
small.c:13:5: internal compiler error: in vect_enhance_data_refs_alignment, at
tree-vect-data-refs.c:1555
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[regehr@gamow tmp032]$ 
[regehr@gamow tmp032]$ 
[regehr@gamow tmp032]$ 
[regehr@gamow tmp032]$ 
[regehr@gamow tmp032]$ cat small.c
struct S1
{
  int f4;
  int f5;
  int f9;
};

int *zz;
struct S1 g_40;
struct S1 g_69;
int g_79;

int un_ (struct S1 **p_, int p_6, char p_66)
{
  char l_76[] = { 0, 0, 0, 0, 1, };
  for (g_40.f4 = 1; g_40.f4; g_40.f4 += 1)
{
  int *l_78 = &g_79;
  *l_78 = l_76[g_40.f4];
  if (zz)
return 1;
  *l_78 = p_66 >= g_40.f9;
  if (g_69.f5)
break;
}
  return 0;
}

[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them

[hjl.tools at gmail dot com]

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

--- Comment #66 from H.J. Lu  2011-06-23 23:17:04 
UTC ---
(In reply to comment #65)
> The mainline versions of both GNU ld and gold now put .ctors sections into
> .init_array sections, and put .dtors sections into .fini_array sections. 
> .ctors/.dtors sections with priorities are sorted correctly with
> .init_array/.fini_array sections with priorities.
> 
> The gcc patch is still useful as it will permit eliminating the support for
> constructors and destructors in crtbegin.o and crtend.o.  If we can do that I
> believe that crtend.o can be removed, and crtbegin.o will only be needed to
> call 
> _Jv_RegisterClasses.

[hjl@gnu-6 libgcc]$ readelf -s crtend.o

Symbol table '.symtab' contains 11 entries:
   Num:Value  Size TypeBind   Vis  Ndx Name
 0:  0 NOTYPE  LOCAL  DEFAULT  UND 
 1:  0 FILELOCAL  DEFAULT  ABS crtstuff.c
 2:  0 SECTION LOCAL  DEFAULT1 
 3:  0 SECTION LOCAL  DEFAULT2 
 4:  0 SECTION LOCAL  DEFAULT3 
 5:  0 SECTION LOCAL  DEFAULT4 
 6:  0 OBJECT  LOCAL  DEFAULT4 __FRAME_END__
 7:  0 SECTION LOCAL  DEFAULT5 
 8:  0 OBJECT  LOCAL  DEFAULT5 __JCR_END__
 9:  0 SECTION LOCAL  DEFAULT7 
10:  0 SECTION LOCAL  DEFAULT6 

We need __FRAME_END__ for exception handling and __JCR_END__ for
_Jv_RegisterClasses.

[Bug c++/49519] New: [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

   Summary: [4.7 Regression] Revision 175272 miscompiled
447.dealII in SPEC CPU 2006
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: ja...@redhat.com


On Linux/ia32, revision 175272:

http://gcc.gnu.org/ml/gcc-cvs/2011-06/msg00763.html

miscompiled 447.dealII in SPEC CPU 2006 with

-m32  -O2 -msse2 -mfpmath=sse -ffast-math

447.dealII: copy 0 non-zero return code (exit code=11, signal=0)



Contents of dealII.err

/bin/sh: line 1: 11020 Segmentation fault  (core dumped) taskset -c
$TASK_CP
U ../run_base_ref_lnx32-gcc./dealII_base.lnx32-gcc 23



Starting program:
/export/regression/rrs/spec/2006/spec/benchspec/CPU2006/447.dealII/run/run_base_ref_lnx32-gcc./dealII_base.lnx32-gcc
23
Refinement cycle: 0

Program received signal SIGSEGV, Segmentation fault.
0x08218006 in SparsityPattern::operator()(unsigned int, unsigned int) const ()
Missing separate debuginfos, use: debuginfo-install glibc-2.14-3.3.f15.i686
libgcc-4.6.0-9.fc15.i686 libstdc++-4.6.0-9.fc15.i686
(gdb) bt
#0  0x08218006 in SparsityPattern::operator()(unsigned int, unsigned int) const
()
#1  0x0821c931 in
LaplaceSolver::Solver<3>::assemble_matrix(LaplaceSolver::Solver<3>::LinearSystem&,
TriaActiveIterator<3, DoFCellAccessor<3> > const&, TriaActiveIterator<3,
DoFCellAccessor<3> > const&, Threads::DummyThreadMutex&) const ()
#2  0x0821fe7e in
LaplaceSolver::Solver<3>::assemble_linear_system(LaplaceSolver::Solver<3>::LinearSystem&)
()
#3  0x08222a32 in LaplaceSolver::Solver<3>::solve_problem() ()
#4  0x0821fa3d in LaplaceSolver::WeightedResidual<3>::solve_problem() ()
#5  0x0821b92e in Framework<3>::run(Framework<3>::ProblemDescription const&) ()
#6  0x0804bf6d in main ()
(gdb)

[Bug c++/35255] [DR 115] gcc does not do partial ordering on overloaded address resolution

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  2011-06-24 
02:13:46 UTC ---
Author: jason
Date: Fri Jun 24 02:13:41 2011
New Revision: 175367

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175367
Log:
PR c++/35255
* pt.c (resolve_overloaded_unification): Fix DR 115 handling.

Added:
trunk/gcc/testsuite/g++.dg/template/partial10.C
trunk/gcc/testsuite/g++.dg/template/partial11.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/49418] [4.6 regression] G++ discards cv-quals from template parameter types

[jason at gcc dot gnu.org]

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

--- Comment #9 from Jason Merrill  2011-06-24 
02:18:46 UTC ---
Author: jason
Date: Fri Jun 24 02:18:42 2011
New Revision: 175368

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175368
Log:
PR c++/49418
* typeck2.c (build_functional_cast): Strip cv-quals for value init.
* init.c (build_zero_init_1): Not here.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/cp/typeck2.c

[Bug c++/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

--- Comment #1 from H.J. Lu  2011-06-24 04:41:09 
UTC ---
Revert this patch:

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 4d2caa8..2716f78 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -10246,7 +10246,7 @@ tsubst_arg_types (tree arg_types,

/* Do array-to-pointer, function-to-pointer conversion, and ignore
   top-level qualifiers as required.  */
-type = TYPE_MAIN_VARIANT (type_decays_to (type));
+type = cv_unqualified (type_decays_to (type));

/* We do not substitute into default arguments here.  The standard
   mandates that they be instantiated only when needed, which is

fixes the crash.

[Bug testsuite/49512] [4.7 Regression] FAIL: gcc.dg/tree-ssa/asm-1.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Jakub Jelinek  2011-06-24 
06:58:44 UTC ---
Fixed.