[Bug rtl-optimization/36998] [4.3/4.4 regression] Ada bootstrap broken on i586-*-*

[kkojima at gcc dot gnu dot org]

--- Comment #4 from kkojima at gcc dot gnu dot org  2008-08-02 05:48 ---
For SH processors with FPU, 4.3 and 4.4 fail to bootstrap during
building libjava with:

../../../../../../ORIG/trunk/libjava/classpath/native/fdlibm/dtoa.c:885:
internal compiler error: in compute_barrier_args_size_1, at dwarf2out.c:1230

It looks that these targets have the similar problem.


-- 

kkojima at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||kkojima at gcc dot gnu dot
   ||org


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

[Bug c++/37006] explicitly deleted inline function gives warning "used but never defined"

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-08-02 05:14:36
   date||


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

[Bug debug/37002] [4.4 Regression] No debug info on unreferenced parameters

[hjl at gcc dot gnu dot org]

--- Comment #2 from hjl at gcc dot gnu dot org  2008-08-02 04:52 ---
Subject: Bug 37002

Author: hjl
Date: Sat Aug  2 04:51:03 2008
New Revision: 138551

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138551
Log:
2008-08-01  H.J. Lu  <[EMAIL PROTECTED]>

PR debug/37002
* dwarf2out.c (mem_loc_descriptor): Use DRAP for vDRAP which
has been optimized out.

Modified:
branches/stack/gcc/ChangeLog.stackalign
branches/stack/gcc/dwarf2out.c


-- 


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

[Bug tree-optimization/36922] ICE in tree-data-ref.c with -ftree-loop-linear

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2008-08-02 03:49 
---
*** Bug 37007 has been marked as a duplicate of this bug. ***


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||janis at gcc dot gnu dot org


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

[Bug tree-optimization/37007] ICE in initialize_matrix_A with gamess for -ftree-loop-linear

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2008-08-02 03:49 
---


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


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/37006] explicitly deleted inline function gives warning "used but never defined"

[chris dot fairles at gmail dot com]

--- Comment #2 from chris dot fairles at gmail dot com  2008-08-02 02:11 
---
Also note that the boolean conversion operators aren't required to get the
warning.


-- 


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

[Bug tree-optimization/37007] ICE in initialize_matrix_A with gamess for -ftree-loop-linear

[janis at gcc dot gnu dot org]

--- Comment #1 from janis at gcc dot gnu dot org  2008-08-02 01:07 ---
Oh good grief, this is a duplicate of 36922; sorry about that.


-- 


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

[Bug tree-optimization/37007] New: ICE in initialize_matrix_A with gamess for -ftree-loop-linear

[janis at gcc dot gnu dot org]

Fortran benchmark gamess from SPEC CPU2006 fails to build with current mainline
on powerpc-linux with "-O2 -ftree-loop-linear" due to the following ICE:

elm3b149% /home/janis/tools/gcc-trunk-anonsvn/bin/gfortran -c -O2
-ftree-loop-linear bug.f
bug.f: In function ‘foo’:
bug.f:1: internal compiler error: in initialize_matrix_A, at
tree-data-ref.c:1899
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The following minimized testcase demonstrates the same problem:

  subroutine foo (n,x,y)
  implicit none
  double precision y(23821)
  double precision x(0:2*n)
  integer len,i,j,k,n
  len=0
  do i=0,n
do j=0,i
  do k=j,i
len=len+1
y(len)=x(i-j)/(x(k+j)*x(i-k))
  enddo
enddo
  enddo
  return
  end

The failure starts with this patch:

   http://gcc.gnu.org/viewcvs?view=rev&rev=135116

r135116 | spop | 2008-05-09 16:17:47 + (Fri, 09 May 2008)


-- 
   Summary: ICE in initialize_matrix_A with gamess for -ftree-loop-
linear
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
GCC target triplet: powerpc-unknown-linux-gnu


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

[Bug c++/37006] explicitly deleted inline function gives warning "used but never defined"

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2008-08-01 23:33 
---
Let's CC Jason...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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

[Bug target/35659] [4.3/4.4 Regression] Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64

[sje at cup dot hp dot com]

--- Comment #22 from sje at cup dot hp dot com  2008-08-01 23:28 ---
Maxim, have you had time to look at this bug?  Given that it is generating bad
code and is in 4.3.0 and 4.3.1 I was wondering if it will be fixed for 4.3.2.


-- 


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

[Bug c++/37006] New: explicitly deleted inline function gives warning "used but never defined"

[chris dot fairles at gmail dot com]

Given the following snip:

template
struct A {
  template
  bool operator==(const A&) = delete;
  operator bool () { return true; }
};

int main()
{
  A a1;
  A a2;
  if(a1 == a2) {}
}

Compilation with g++44 -std=gnu++0x gives:
error: deleted function bool A::operator==(const A&) [with U = void, T =
int]
which is correct but it also issues:
At global scope:
warning: inline function bool A::operator==(const A&) [with U = void, T =
int] used but never defined

A similar test case without templates works as expected:
struct B {};

struct C
{
  bool operator==(const B&) = delete;
  operator bool () { return true; }
};

int main() {
  B b;
  C c;
  if(c == a) {}
}

That is, it gives only the error for the deleted function (and where its used).


-- 
   Summary: explicitly deleted inline function gives warning "used
but never defined"
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris dot fairles at gmail dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

I N G Y E N - S M S ( NEM W A R E Z )

[i . n . g . y . e . n]

Hello

Gondoltad volna mennyi minden ingyen van az intereneten?
Ingyen sms , ingyen termékek?
Az oldalunk ezeket a helyeket foglalja össze.
Ha érdekel látogass el cimünkre

http://ingyenviheto.dy.hu/

Oldalunk nemtartalmaz semmilyen (e r o t i k u s) illetve (i l l e g á l i s) 
tartalmat.

Üdv

[Bug fortran/36577] Segmentation fault from gfortran compilation

[dfranke at gcc dot gnu dot org]

--- Comment #11 from dfranke at gcc dot gnu dot org  2008-08-01 21:36 
---
Closing as WORKSFORME, Reporter can not reproduce the problem.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WORKSFORME
   Target Milestone|--- |4.4.0


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

[Bug fortran/36577] Segmentation fault from gfortran compilation

[zhonghaij at yahoo dot com]

--- Comment #10 from zhonghaij at yahoo dot com  2008-08-01 20:32 ---
Subject: Re:  Segmentation fault from gfortran compilation

Based on my test, the new version will work.
Thanks


--- On Sun, 7/27/08, dfranke at gcc dot gnu dot org <[EMAIL PROTECTED]>
wrote:

> From: dfranke at gcc dot gnu dot org <[EMAIL PROTECTED]>
> Subject: [Bug fortran/36577] Segmentation fault from gfortran compilation
> To: [EMAIL PROTECTED]
> Date: Sunday, July 27, 2008, 9:55 AM
> --- Comment #9 from dfranke at gcc dot gnu dot org 
> 2008-07-27 16:55 ---
> Anything new here?
> Did you try a newer version of gfortran as suggested by
> Steve?
> If it still does not work for you, could you provide a
> self-contained test
> case?
> 
> 
> -- 
> 
> dfranke at gcc dot gnu dot org changed:
> 
>What|Removed |Added
> 
>  Status|UNCONFIRMED |WAITING
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36577
> 
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone
> who is.
> You reported the bug, or are watching the reporter.





-- 


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

[Bug ada/37005] New: GNAT Bug Box for cd2a24e.adb:37 at tree-vrp.c:392

[joel at gcc dot gnu dot org]

Did not occur with SVN trunk revision 138315 as reported here
http://gcc.gnu.org/ml/gcc-testresults/2008-07/msg02920.html


+===GNAT BUG DETECTED==+
| 4.4.0 20080801 (experimental) [trunk revision 138517]
(sparc-unknown-rtems4.9) GCC error:|
| in set_value_range, at tree-vrp.c:392|
| Error detected around cd2a24e.adb:37 |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+
Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.

cd2a24e.adb
/home/joel/work-gnat/svn/gcc/gcc/testsuite/ada/acats/work-sis/support/report.ads


raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:424
End of compilation


-- 
   Summary: GNAT Bug Box for cd2a24e.adb:37 at tree-vrp.c:392
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC target triplet: sparc-rtems4.9


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

[Bug c/37001] Uninitialized static variables on x86_64

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-08-01 20:15 ---
Well, that only hints at that the bss section is not cleared properly which
is the job of the kernel and/or the dynamic linker.


-- 


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

[Bug target/37003] 4.2.2 -mfpmath=sse causes movapd from non-16-byte aligned address

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal


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

[Bug rtl-optimization/36998] [4.3/4.4 regression] Ada bootstrap broken on i586-*-*

[jason at gcc dot gnu dot org]

--- Comment #3 from jason at gcc dot gnu dot org  2008-08-01 20:01 ---
Assuming that (set SP otherreg) resets args_size to 0 seems strictly better
than the current situation, and if it turns out to be wrong we ought to see
another crash like this one, so it seems fair to try.  Otherwise we'd need to
hook into CSE, I guess.


-- 


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

[Bug c/34389] -Wconversion produces wrong warning

[manu at gcc dot gnu dot org]

--- Comment #13 from manu at gcc dot gnu dot org  2008-08-01 19:36 ---
I created PR 37004 to cover the issue with C++ front-end. Apart from that, this
bug is FIXED in GCC 4.4.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c++/37004] [C++ only] Wconversion warns for short y = 0x7fff; short z = (short) x & y;

[manu at gcc dot gnu dot org]

-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-08-01 19:35:25
   date||


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

[Bug c++/37004] New: [C++ only] Wconversion warns for short y = 0x7fff; short z = (short) x & y;

[manu at gcc dot gnu dot org]

This comes from PR 34389 and it only fails in C++. There is already a testcase:

trunk/gcc/testsuite/g++.dg/warn/Wconversion-pr34389.C

short  mask1(short x)
{
  short y = 0x7fff;
  return x & y; /* { dg-bogus "conversion" "conversion" { xfail *-*-* } 8 } */
}


In C, build_binary_op constructs:

 
unit size 
arg 0 
arg 1 


while C++ builds:

 
unit size 

arg 0 

arg 0 
arg 1 

arg 0 


The difference is in shorten_binary_op->common_type. In C, it returns short
int, while in C++ it returns int. If it returned short int in C++, I think it
will avoid warning.

A more robust fix would be to make conversion_warning smart enough to handle
the C++ expression. Not sure how to do that, though.


-- 
   Summary: [C++ only] Wconversion warns for short y = 0x7fff; short
z = (short) x & y;
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org


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

[Bug target/36992] Very stange code for _mm_move_epi64

[ubizjak at gmail dot com]

--- Comment #8 from ubizjak at gmail dot com  2008-08-01 19:32 ---
(In reply to comment #7)

> But it isn't necessary at all. We should use
> 
> movq %xmm0,%xmm0

It looks to me that we should add:

  [(set (match_operand:V2DI 0 "register_operand" "=x")
(vec_concat:V2DI
  (match_operand:DI 1 "nonimmediate_operand" "!x")
  (match_operand:DI 2 "vector_move_operand"  " C")))]

to the alternatives of all vec_concatv2di patterns.

Perhaps we need something like that also for all vec_concatv2si patterns, since
x can also hold SImode value, and movd fills upper part of target SSE reg with
zeroes.

"!" guarantees, that this alternative applies only when input value is already
in SSE reg.


-- 


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

[Bug c/37001] Uninitialized static variables on x86_64

[gerald at wireshark dot org]

--- Comment #4 from gerald at wireshark dot org  2008-08-01 19:05 ---
I am "the application developer" and I've done my job. I'm asking you why gcc
isn't setting a variable to 0 when we've explicitly told it to do so.

Watching tap_current gives me the following:
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) break dissect_bssmap
Function "dissect_bssmap" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 1 (dissect_bssmap) pending.
(gdb) run -nVr /tmp/fuzz-2008-07-31-3587.pcap > /dev/null
Starting program: /home/gerald/devel/wireshark/.libs/lt-tshark -nVr
/tmp/fuzz-2008-07-31-3587.pcap > /dev/null
[Thread debugging using libthread_db enabled]
[New Thread 47286662778672 (LWP 10314)]
Breakpoint 2 at 0x2b01c4b4b7a0: file packet-gsm_a.c, line 20279.
Pending breakpoint "dissect_bssmap" resolved
[Switching to Thread 47286662778672 (LWP 10314)]

Breakpoint 2, dissect_bssmap (tvb=0x125bc60, pinfo=0x125a0a0, tree=0x125af40)
at packet-gsm_a.c:20279
20279   {
(gdb) watch tap_current
Hardware watchpoint 3: tap_current
(gdb) c
Continuing.
dissect_bssmap tap_current: 3323523940
Hardware watchpoint 3: tap_current

Old value = 3323523940
New value = 3323523941
dissect_bssmap (tvb=0x125bc60, pinfo=0x125a0a0, tree=0x125af40)
at packet-gsm_a.c:20315
20315   tap_p = &tap_rec[tap_current];
(gdb)

Shouldn't it be

Old value = 0
New value = 1

instead?

At any rate, I've checked in a workaround in the Wireshark SVN repository and
opened a bug for this issue at Launchpad.net.
http://anonsvn.wireshark.org/viewvc/index.py?view=rev&revision=25886
https://bugs.launchpad.net/ubuntu/+source/gcc-4.1/+bug/254025

As I mentioned in the initial report, trying to report a gcc bug at
Launchpad.net points me to the gcc Bugzilla. If this isn't the correct path to
follow, maybe you should tell them to stop doing that.

Thank you for your time.


-- 

gerald at wireshark dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug tree-optimization/36991] [4.3 Regression] ICE in remove_useless_stmts_1, at tree-cfg.c:1882

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2008-08-01 19:02 ---
Subject: Bug 36991

Author: jakub
Date: Fri Aug  1 19:01:33 2008
New Revision: 138530

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138530
Log:
2008-08-01  Jakub Jelinek  <[EMAIL PROTECTED]>

PR tree-optimization/36991
* gcc.dg/pr36991.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr36991.c
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/36991] [4.3 Regression] ICE in remove_useless_stmts_1, at tree-cfg.c:1882

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2008-08-01 19:02 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/36991] [4.3 Regression] ICE in remove_useless_stmts_1, at tree-cfg.c:1882

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2008-08-01 18:59 ---
Subject: Bug 36991

Author: jakub
Date: Fri Aug  1 18:58:24 2008
New Revision: 138529

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138529
Log:
PR tree-optimization/36991
* gimplify.c (gimplify_init_constructor): Call tree_to_gimple_tuple
on expr_p before appending it to pre_p.

* gcc.dg/pr36991.c: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pr36991.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/gimplify.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/36408] [4.3/4.4 regression] ICE with statement expression in template

[dodji at gcc dot gnu dot org]

--- Comment #11 from dodji at gcc dot gnu dot org  2008-08-01 17:54 ---
Doug, thanks for your comments.

I have submitted the patch to the list
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00082.html.


-- 


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

[Bug c++/35852] -Wconversion rejects bitwise negation and assignment, cannot cast around

[manu at gcc dot gnu dot org]

--- Comment #4 from manu at gcc dot gnu dot org  2008-08-01 17:54 ---
To be honest, I am not sure what deserves a warning and what not in this
testcase.

FOO is 19, ~FOO is -20. Therefore 
ushort x = ~FOO seems to deserve a warning (with -Wsing-conversion at least).

x = x & -20 is handled as x = (int)x & -20. If x == 0x, this seems like the
case above and probably deserves a warning.

lv = lv & ~rv is seen as:

 
unit size 
arg 0 

arg 0 
arg 0 >>
arg 1 
arg 0 
arg 0 
tree_0 arg 0 

That is, we would need to peek inside each operand and recursively check
whether the expressions/conversions are safe. I don't know if this is feasible
at all and I personally don't know at this moment how to implement it properly.

On the other hand, in mainline, I don't get any warnings for:

x = x & ushort(~FOO);   // -Wconversion
x = x & ushort(~ushort(FOO));   // -Wconversion
x &= static_cast(~FOO); // -Wconversion

So that seems fixed.


-- 


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

[Bug c/37003] 4.2.2 -mfpmath=sse causes movapd from non-16-byte aligned address

[gkumar007 at gmail dot com]

--- Comment #2 from gkumar007 at gmail dot com  2008-08-01 17:36 ---
Created an attachment (id=15995)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15995&action=view)
the generated assmebly code


-- 


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

[Bug c/37003] 4.2.2 -mfpmath=sse causes movapd from non-16-byte aligned address

[gkumar007 at gmail dot com]

--- Comment #1 from gkumar007 at gmail dot com  2008-08-01 17:35 ---
Created an attachment (id=15994)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15994&action=view)
the test case exhibiting the wrong code generation


-- 


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

[Bug c/37003] New: 4.2.2 -mfpmath=sse causes movapd from non-16-byte aligned address

[gkumar007 at gmail dot com]

gcc-4.2.2 seems to generating wrong/misaligned code for movapd.

I have used the same test case mentione here (for almost the similar bug)
http://gcc.gnu.org/bugzilla/attachment.cgi?id=6012


The relavent information about the version and the files are as follows:

The version of gcc:
gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../../src/gcc-4.2.2/configure
--prefix=/depot/gcc-4.2.2-static --disable-shared
--enable-threads=posix --disable-checking --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions
--enable-languages=c,c++,objc,fortran --with-cpu=generic
--host=i386-redhat-linux
Thread model: posi

$ gcc -g -O2 -funsigned-bitfields -fsigned-char -ffloat-store -Wformat
 -msse2 -mfpmath=sse  -c sse.c
$ objdump -Sd sse.o > sse_asm.txt

$ grep movapd sse_asm.txt
 a3:   66 0f 28 c2 movapd %xmm2,%xmm0
 cb:   66 0f 28 c1 movapd %xmm1,%xmm0
 f6:   66 0f 28 c4 movapd %xmm4,%xmm0
 165:   66 0f 29 9d 38 fe ffmovapd %xmm3,0xfe38(%ebp) #<
 185:   66 0f 28 9d 38 fe ffmovapd 0xfe38(%ebp),%xmm3


Is this a known issue? If so, is there are there any suggested
workarounds (other than upgrading to later versions :-) ?

Regards,
Gowri Kumar


-- 
   Summary: 4.2.2 -mfpmath=sse causes movapd from non-16-byte
aligned address
   Product: gcc
   Version: 4.2.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gkumar007 at gmail dot com
  GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux


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

[Bug c/37001] Uninitialized static variables on x86_64

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-08-01 17:24 ---
Just as a hint - as this is a static symbol you may want to use a gdb
watchpoint to see what changes it.  Just do

gdb> watch tap_current


-- 


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

[Bug c/37001] Uninitialized static variables on x86_64

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-08-01 17:23 ---
GCC 4.1 is no longer maintained, please try a newer version and provide a
smaller testcase (we are _not_ downloading software and debugging it - this
is the obligation of the application developer).


-- 


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

[Bug debug/37002] [4.4 Regression] No debug info on unreferenced parameters

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2008-08-01 16:50 ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00080.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||08/msg00080.html


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

[Bug debug/37002] New: [4.4 Regression] No debug info on unreferenced parameters

[hjl dot tools at gmail dot com]

[EMAIL PROTECTED] gcc]$ cat /tmp/x.c
#include 

void
foo (int x, int y, int z)
{
  printf ("hello\n");
}

int
main ()
{
  foo (3000, 3303, -193);
}
[EMAIL PROTECTED] gcc]$ ./xgcc -B./ -m32 -mforce-drap -mstackrealign /tmp/x.c -g
[EMAIL PROTECTED] gcc]$ /usr/bin/gdb a.out 
GNU gdb Fedora (6.8-12.fc9)
...
(gdb) b foo
Breakpoint 1 at 0x80483b5: file /tmp/x.c, line 6.
(gdb) r
Starting program: /export/build/gnu/gcc-work/build-x86_64-linux/gcc/a.out 

Breakpoint 1, foo () at /tmp/x.c:6
6 printf ("hello\n");
Missing separate debuginfos, use: debuginfo-install glibc.i686
(gdb) 

The unreferenced parameters aren't available. The problem is when
DRAP is used to align stack, the parameters are referenced via
internal_arg_pointer, which may be a copy of DRAP. When the RTL
that assigning DRAP to internal_arg_pointer is optimized away
since it is never referenced in the function body, mem_loc_descriptor
finds a pseudo register:

  if (REGNO (rtl) < FIRST_PSEUDO_REGISTER)
mem_loc_result = based_loc_descr (rtl, 0, VAR_INIT_STATUS_INITIALIZED);

where rtl is internal_arg_pointer and doesn't generate debug info.


-- 
   Summary: [4.4 Regression] No debug info on unreferenced
parameters
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: i686-pc-linux-gnu


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

[Bug c/37001] Uninitialized static variables on x86_64

[gerald at wireshark dot org]

--- Comment #1 from gerald at wireshark dot org  2008-08-01 16:31 ---
Created an attachment (id=15993)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15993&action=view)
Add debugging printfs to epan/dissectors/packet-gsm_a.c


-- 


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

[Bug c/37001] New: Uninitialized static variables on x86_64

[gerald at wireshark dot org]

Wireshark's Buildbot system recently uncovered what appears to be a bug in gcc.
The following code:

static guinttap_current=0;
[ ... ]
fprintf(stderr, "dissect_bssmap tap_current: %u\n", tap_current);

produces the following output:

dissect_bssmap tap_current: 2801996644

'gcc -v' output:
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1
--enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug
--enable-mpfr --enable-checking=release x86_64-linux-gnu
Thread model: posix
gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)

(I realize this may be an Ubuntu-specific bug. Launchpad.net pointed me here.)

Steps to reproduce:

  Download a recent Wireshark tarball from 
  http://www.wireshark.org/download/automated/src/ or check out from SVN at
  http://anonsvn.wireshark.org/wireshark/trunk/

  Apply the patch which I'll attach shortly and build Wireshark

  Download the capture file from
 
http://www.wireshark.org/download/automated/captures/fuzz-2008-07-31-3587.pcap

  Run './tshark -nVr /tmp/fuzz-2008-07-31-3587.pcap > /dev/null 2> /tmp/tp.out
; head -10 /tmp/tp.out'

You should see something like the following:

dissect_bssmap tap_current: 2801996644
dissect_bssmap tap_current: 0
dissect_bssmap tap_current: 1
dissect_dtap tap_current: 2801996612
dissect_bssmap tap_current: 2
dissect_dtap tap_current: 0
dissect_bssmap tap_current: 3
dissect_dtap tap_current: 1
dissect_bssmap tap_current: 0
dissect_bssmap tap_current: 1

Sorry I don't have a smaller test case.


-- 
   Summary: Uninitialized static variables on x86_64
   Product: gcc
   Version: 4.1.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gerald at wireshark dot org
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


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

[Bug target/36851] [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64 UNIX

[ro at techfak dot uni-bielefeld dot de]

--- Comment #5 from ro at techfak dot uni-bielefeld dot de  2008-08-01 
16:24 ---
Subject: Re:  [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64
UNIX

rguenth at gcc dot gnu dot org writes:

> If you provide a preprocessed testcase maybe he can.  Otherwise patches 
> welcome
> I guess.

Done.  Unfortunately, I won't be available for testing until September 1st.

If this cannot be resolved, I'll certainly need quite some guidance to fix
it myself.

Rainer


-- 


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

[Bug target/36851] [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64 UNIX

[ro at gcc dot gnu dot org]

--- Comment #4 from ro at gcc dot gnu dot org  2008-08-01 16:22 ---
Created an attachment (id=15992)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15992&action=view)
preprocessed libstdc++-v3/src/strstream.cc


-- 


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

[Bug rtl-optimization/36998] [4.3/4.4 regression] Ada bootstrap broken on i586-*-*

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2008-08-01 16:13 ---
I've managed to reproduce it, only happens with -mtune=i586 apparently.
Without my patch GCC doesn't ICE, just creates bad unwind info.
In *.greg dump we have (in uname__uname_lt):
(insn:HI 10 9 11 3 uname.adb:615 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int -12 [0xfff4])))
(clobber (reg:CC 17 flags))
]) 249 {*addsi_1} (nil))

(insn:HI 11 10 12 3 uname.adb:615 (set (mem/i:SI (pre_dec:SI (reg/f:SI 7 sp))
[0 S4 A32])
(reg/v:SI 0 ax [orig:70 left ] [70])) 40 {*pushsi2} (nil))

(call_insn:HI 12 11 13 3 uname.adb:615 (call (mem:QI (symbol_ref:SI
("namet__get_name_string") [flags 0x41] )) 40 {*pushsi2} (nil))

(insn:HI 29 28 30 3 uname.adb:616 (set (mem/f/i:SI (pre_dec:SI (reg/f:SI 7 sp))
[0 S4 A32])
(reg/f:SI 5 di [88])) 40 {*pushsi2} (nil))

(call_insn:HI 30 29 33 3 uname.adb:616 (set (reg:SI 0 ax)
(call (mem:QI (symbol_ref:SI ("memcpy") [flags 0x41] ) [0 S1 A8])
(const_int 16 [0x10]))) 839 {*call_value_0}
(expr_list:REG_EH_REGION (const_int 0 [0x0])
(nil))
(nil))

and no stack adjustments in between.  The first insn listed above starts at
args_size 0 level, then the first call is at args_size 16 level, then we pop up
the stack back to args_size 0 level, decrease by 4 bytes again and push 3 * 4
bytes, so again memcpy is at args_size 16 level.
But *.postreload decides to change insn 16 into:
(insn:HI 16 15 173 3 uname.adb:616 (set (reg/f:SI 7 sp)
(reg/f:SI 5 di [88])) 47 {*movsi_1} (nil))
which is equivalent to the sp = sp + 16, but unfortunately is something
stack_adjust_offset doesn't track for the args_size adjustments.  Which means
that args_size on the second call will be 32 instead of the correct 16, and
with my patch it ICEs because label 127 is reachable both from a place where
args_size is 0 (jump_insn 8) and from a place where gcc believes it is 16
(after the memcpy call).

Not sure what's the best way to fix this though.  I can surely remove the
assert and let it silently generate invalid unwind info, but I don't think
that's a good idea.  So, either reload is changed not to do this (pointless)
replacement,
or perhaps the dwarf2out.c could assume if sp is set to some register (rather
than sp + const), args_size should be reset to 0 (though, I really don't know
if
that would be a safe assumption).  Tracking all registers that might ever
contain some pointers into the stack would be a nightmare.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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

[Bug c++/3187] gcc lays down two copies of constructors

[amylaar at gcc dot gnu dot org]

--- Comment #31 from amylaar at gcc dot gnu dot org  2008-08-01 16:07 
---
(In reply to comment #27)
> (In reply to comment #20)
> 
> Ian proposed handling the simple case in which the two constructors ("clones")
> are identical by emitting the code only once, but labelling it with the 
> symbols
> for both constructors.  This scheme fails in the case that the constructors
> must go in a comdat group. What do we name the group?  If we invent a new 
> name,
> this will have ABI impact, as other implementations must not step on it.  If 
> we
> use the name of one of the constructors, we may find that the section is
> discarded in favor of a like-named section produced by another compiler, but
> which need not define both symbols, resulting in link-incompatibility.

link-incompatibility is often of a lesser concern in the embedded world,
where some people are prepared to rebuild all their libraries if they can
save 20% code space this way.
Thus, having an option to use the scheme where the comdat section - if any -
is named after only one of the constructors / destructors would be helpful.
For situations where there are more concerns about link compatibility, I
suppose we could initiate a transitionary period where we put a weak
definition of the *1* con/destructor in the *2* section, and vice versa.
When a user is confident that all the libraries are built at least with this
transitionary scheme, they can turn on a switch to only emit the needed
sections, thus saving at least some space where not all the constructors /
destructors are coming from the libraries.
This transitionary period could be ended on a target-by-target basis when
the an ABI change is deemed safe, or extended indefinitely where it is
not considered safe.


-- 

amylaar at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||amylaar at gcc dot gnu dot
   ||org


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

[Bug target/36851] [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64 UNIX

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-08-01 16:06 ---
If you provide a preprocessed testcase maybe he can.  Otherwise patches welcome
I guess.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|bootstrap   |target
   Keywords||build
   Target Milestone|--- |4.4.0


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

[Bug bootstrap/37000] gen-classlist.sh uses unrecognized 'test' arguments

[deisner at gmail dot com]

--- Comment #2 from deisner at gmail dot com  2008-08-01 15:22 ---
(In reply to comment #1)
> Have you tried setting CONFIG_SHELL as suggested?

Apologies, I did not see that.  I'll try this next time. 


-- 


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

[Bug bootstrap/37000] gen-classlist.sh uses unrecognized 'test' arguments

[brian at dessent dot net]

--- Comment #1 from brian at dessent dot net  2008-08-01 15:19 ---
Subject: Re:   New: gen-classlist.sh uses unrecognized 
 'test' arguments

Using /bin/sh with Solaris is documented to fail:
http://gcc.gnu.org/install/specific.html#x-x-solaris2

Have you tried setting CONFIG_SHELL as suggested?


-- 


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

[Bug c++/36971] Portability issue from gcc 2.96 to gcc 4.1.1 for c++ casting

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

   Severity|major   |normal


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

[Bug rtl-optimization/36998] [4.3/4.4 regression] Ada bootstrap broken on i586-*-*

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2008-08-01 15:10 ---
Weird, I've bootstrapped/regtested 4.3 branch this morning, including ada, on
{i?86,x86_64,ppc,ppc64}-linux just fine, r138443, so the dwarf2out.c changes
were in.


-- 


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

[Bug bootstrap/37000] New: gen-classlist.sh uses unrecognized 'test' arguments

[deisner at gmail dot com]

[I can't decide if this should be reported against gcc or classpath.  Apologies
if I got it wrong.]

My gcc build is failing when gen-classlist.sh is invoked, in two places:

First place:

top_builddir=..
top_srcdir=../../../../../../gcc-4.2.4/libjava/classpath /bin/sh
./gen-classlist.sh standard
Adding java source files from srcdir
'../../../../../../gcc-4.2.4/libjava/classpath'.
Adding java source files from VM directory
/export/data/software/cradle/build/gcc/gcc-4.2.4/libjava
Adding java source files from VM directory
/export/data/software/cradle/build/gcc/objdir/sparc-sun-solaris2.9/sparcv9/libjava
./gen-classlist.sh: test: unknown operator -ef
make: *** [genclasses] Error 1

Second place:

Adding java source files from srcdir
'../../../../../../gcc-4.2.4/libjava/classpath'.
Adding java source files from VM directory
/export/data/software/cradle/build/gcc/gcc-4.2.4/libjava
Adding java source files from VM directory
/export/data/software/cradle/build/gcc/objdir/sparc-sun-solaris2.9/sparcv9/libjava
Adding generated files in builddir '..'.
./gen-classlist.sh: test: argument expected
make: *** [genclasses] Error 1

The first problem occurs because on Solaris 9, at least, the /bin/sh test
built-in doesn't understand the -ef operator, and the second problem occurs
because it doesn't understand the -e operator.  From the Solaris test(1) man
page:

---8<---
  file1 -ef file2
True if file1 and file2 exist and  refer  to  the
same file. (Not available in sh.)
...
  -e file
True if file exists. (Not available in sh.)
--->8---

Workaround: In gen-classlist.sh, replace those two calls to test with
/usr/bin/test.


-- 
   Summary: gen-classlist.sh uses unrecognized 'test' arguments
   Product: gcc
   Version: 4.2.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: deisner at gmail dot com
 GCC build triplet: sparc-sun-solaris2.9
  GCC host triplet: sparc-sun-solaris2.9
GCC target triplet: sparc-sun-solaris2.9


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

[Bug c++/36971] Portability issue from gcc 2.96 to gcc 4.1.1 for c++ casting

[shyam_77_2000 at yahoo dot com]

-- 

shyam_77_2000 at yahoo dot com changed:

   What|Removed |Added

 CC||shyam_77_2000 at yahoo dot
   ||com
   Severity|normal  |major


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

[Bug bootstrap/36851] [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64 UNIX

[ro at gcc dot gnu dot org]

--- Comment #2 from ro at gcc dot gnu dot org  2008-08-01 14:27 ---
Jan,

unfortunately, I haven't heard back from you yet.  Any chance to get this fixed
reasonably soon?

  Rainer


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jh at suse dot cz


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

[Bug c++/36999] New: Erroneous "declaration 'class ...' does not declare anything" warnings possible

[simon_baldwin at yahoo dot com]

The following example program produces several unwarranted "declaration ...
does not declare anything" warnings.  This problem is also present in gcc 4.3,
since this is when the warning was introduced.

File /tmp/warning.cc:
class C1 {
 public: class C2 { };
};

void cf1 (class C1::C2, void*);  // Should not provoke a warning
void cf2 (void*, class C1::C2);
void cf3 (C1::C2, void*);

namespace N {

enum E1 { foo };
enum E2 { bar };

template 
class TC1 { };

template 
class TC2 : public TC1 { };

}

void
tcf1 (N::TC2 *arg1,  // Should not provoke a warning
  N::TC2 *arg2,
  N::TC2 *arg3)
{
}

void *
tcf2 (void *x)
{
  return (void *)
(N::TC2 *)  // Should not provoke a warning
(N::TC2 *)
(N::TC2 *)
x;
}

/tmp/warning.cc:5: warning: declaration 'class C1::C2' does not declare
anything
/tmp/warning.cc:23: warning: declaration 'enum N::E1' does not declare anything
/tmp/warning.cc: In function 'void* tcf2(void*)':
/tmp/warning.cc:33: warning: declaration 'enum N::E1' does not declare anything


-- 
   Summary: Erroneous "declaration 'class ...' does not declare
anything" warnings possible
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: simon_baldwin at yahoo dot com
GCC target triplet: i386-unknown-linux-gnu


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

[Bug c++/36408] [4.3/4.4 regression] ICE with statement expression in template

[dgregor at gcc dot gnu dot org]

--- Comment #10 from dgregor at gcc dot gnu dot org  2008-08-01 14:05 
---
(In reply to comment #9)
> >  - the error message we give in this case is pretty poor. Here we have an
> >empty initializer, but the error message we get back is "void value not 
> >ignored
> >as it ought to be", which really doesn't tell us much of anything about the
> >problem.
> 
> I agree. Though I think addressing that should be best done in another bug
> that we can open straight away when we close this one, if you agree.

Agreed.

> >  - since the statement-expression is obviously empty, can we produce this
> >error message at template definition time, rather than waiting until
> >instantiation time? (If the answer isn't a quick "yes", don't worry about it;
> >I'll eventually be going through the initialization bits to check more of 
> >them
> >at template definition time anyway.)
> 
> Yes, that would be handy. Though here again, I think we should be opening
> another bug to track that.

It's probably not worth opening a bug report for this, unless it's some
placeholder bug that says, "we should diagnose as many errors as template
definition time as possible." Such a bug is almost impossible to close :)

Your updated patch looks good, but I can't approve it. I suggesting pinging
Jason to get approval.


-- 


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

[Bug tree-optimization/36991] [4.3 Regression] ICE in remove_useless_stmts_1, at tree-cfg.c:1882

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2008-08-01 13:55 ---
Missing tree_to_gimple_tuple call in gimplify_init_constructor when want_value.


-- 


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

[Bug c++/36408] [4.3/4.4 regression] ICE with statement expression in template

[dodji at gcc dot gnu dot org]

--- Comment #9 from dodji at gcc dot gnu dot org  2008-08-01 13:32 ---
Created an attachment (id=15991)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15991&action=view)
updated patch

>  - the error message we give in this case is pretty poor. Here we have an
>empty initializer, but the error message we get back is "void value not ignored
>as it ought to be", which really doesn't tell us much of anything about the
>problem.

I agree. Though I think addressing that should be best done in another bug
that we can open straight away when we close this one, if you agree.

>The real issue here is that the statement expression has no return
>value, so we should say as such. This same problem can occur with non-empty
>statement expressions whose last statement does not produce a value, right?
>We
>should test this case, too.

I think the problem (g++ not issuing any warning)
is due to the tsubsted initializer yielding NULL.
An expression made of a statement list which last statement
does not return any value whould be tsubsted to a statement list
of type VOID_TYPE, I believe.

For instance the current g++ 4.3.0 issues the warning for the
following code snippet:

void foo ();
void bar ();

void
func ()
{
  int y = 0;
  int i = ({ foo (); if (y) bar (); });
}

/home/dodji/devel/src/test.cc: In function 'void func()':
/home/dodji/devel/src/test.cc:8: error: void value not ignored as it ought to
be

>
>  - since the statement-expression is obviously empty, can we produce this
>error message at template definition time, rather than waiting until
>instantiation time? (If the answer isn't a quick "yes", don't worry about it;
>I'll eventually be going through the initialization bits to check more of them
>at template definition time anyway.)

Yes, that would be handy. Though here again, I think we should be opening
another bug to track that.

>
>  - is_pack_expansion_node_p is a pretty general name for a function that is
>specific to initializer lists (in general, a TREE_LIST with a pack expansion in
>its TREE_VALUE isn't necessarily an "expansion node"). I suggest calling this
>"initializer_is_pack_expansion_p".
>

Right. This updated patch addresses that.

>  - Please put some braces inside the if (init && !t) block. Omitting the
>braces for "then" and "else" is okay for small one-liner bodies, but shouldn't
>be done when there are if-elses nested inside.

Fixed in this udpated patch.

>
>  - parse/empty-statement.C is a strange place to put this check, which deals
>with template instantiation. Perhaps call it template/empty-init-statement.C?

Yup. Fixed.
>
>  - In the top of the testcase, "PR c++/P36408" should be "PR c++/36408"

Fixed as well.

Thank you for your comments.


-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #15989|0   |1
is obsolete||


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

[Bug rtl-optimization/36998] New: [4.3/4.4 regression] Ada bootstrap broken on i586-*-*

[ebotcazou at gcc dot gnu dot org]

This is on the 4.3 branch but the mainline is affected too:

/home/eric/build/gcc-4_3-branch/native32/./prev-gcc/xgcc
-B/home/eric/build/gcc-4_3-branch/native32/./prev-gcc/
-B/home/eric/install/gcc-4_3-branch/i586-suse-linux/bin/ -c -g -O2
-fomit-frame-pointer  -gnatpg -gnata -nostdinc -I- -I. -Iada
-I/home/eric/svn/gcc-4_3-branch/gcc/ada
/home/eric/svn/gcc-4_3-branch/gcc/ada/uname.adb -o ada/uname.o
+===GNAT BUG DETECTED==+
| 4.3.2 20080801 (prerelease) [gcc-4_3-branch revision 138516]
(i586-suse-linux-gnu) GCC error:|
| in compute_barrier_args_size_1, at dwarf2out.c:1180  |
| Error detected around /home/eric/svn/gcc-4_3-branch/gcc/ada/uname.adb:648|
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|

Very likely trigged by the fix for PR rtl-optimization/36419.


-- 
   Summary: [4.3/4.4 regression] Ada bootstrap broken on i586-*-*
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ebotcazou at gcc dot gnu dot org
  GCC host triplet: i586-*-*


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

[Bug target/36992] Very stange code for _mm_move_epi64

[hjl dot tools at gmail dot com]

--- Comment #7 from hjl dot tools at gmail dot com  2008-08-01 13:25 ---
(In reply to comment #6)
> with -march=core2 it uses
> 
> movd%xmm0, %rax
> movq%rax, %xmm0
>

Even this isn't necessary. We should just use

movq %xmm0,%xmm0

> with -march=opteron (and -march=generic) it uses
> 
> movhps  .LC0(%rip), %xmm0
> 
> ISTR there is some penalty for using movq on opteron?

Opteron doesn't like inter-unit move, like

movd%xmm0, %rax

But it isn't necessary at all. We should use

movq %xmm0,%xmm0

anyway.


-- 


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

[Bug target/36992] Very stange code for _mm_move_epi64

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2008-08-01 13:21 ---
with -march=core2 it uses

movd%xmm0, %rax
movq%rax, %xmm0

with -march=opteron (and -march=generic) it uses

movhps  .LC0(%rip), %xmm0

ISTR there is some penalty for using movq on opteron?


-- 


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

[Bug middle-end/36997] [4.4 Regression] ICE with incompatible arg to '__builtin_ia32_paddq

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-08-01 13:19 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/36997] [4.4 Regression] ICE with incompatible arg to '__builtin_ia32_paddq

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-08-01 13:14 ---
Subject: Bug 36997

Author: rguenth
Date: Fri Aug  1 13:12:38 2008
New Revision: 138515

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138515
Log:
2008-08-01  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/36997
* gimplify.c (gimplify_call_expr): Set error_mark_node on GS_ERROR.

* gcc.dg/pr36997.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr36997.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/36991] [4.3 Regression] ICE in remove_useless_stmts_1, at tree-cfg.c:1882

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2008-08-01 13:08 ---
Looking into this.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-08-01 11:15:10 |2008-08-01 13:08:15
   date||


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

[Bug target/36992] Very stange code for _mm_move_epi64

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2008-08-01 12:55 ---
(In reply to comment #3)
> Btw, 4.3 generates
> 
> test:
> .LFB518:
> movhps  .LC0(%rip), %xmm0
> ret
> 
> Likewise does gcc-4.4 (SUSE Linux) 4.4.0 20080611.  And current trunk.

It should be

movq %xmm0, %xmm0

with optimization.

> 
> So ... why are you exactly complaining about the code generated for -O0 again?
> 

It should use "movq". There is no need to use MMX moves, like
"movq %mm0, -40(%rbp)".


-- 


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

[Bug target/36992] Very stange code for _mm_move_epi64

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2008-08-01 12:53 ---
(In reply to comment #2)
> Google leads me to VC++ reference which says "Moves the lower 64 bits of the
> lower 64 bits of the result, zeroing the upper bits.
> 
> I guess inlining and type fixing messes this up very early.
> 

Please download Intel64/IA32 SDM from:

http://developer.intel.com/products/processor/manuals/index.htm

_mm_move_epi64 is an intrinsic for "movq".


-- 


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

[Bug target/36904] [4.4 Regression] vector context sensitive keyword vs macros

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2008-08-01 12:45 ---
Created an attachment (id=15990)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15990&action=view)
gcc44-pr36904.patch

Partial fix, which fixes the testcase from this PR, but still other cases
in the made up testcase fail and I don't know if they are meant to work or not.


-- 


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

[Bug target/36992] Very stange code for _mm_move_epi64

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-08-01 12:06 ---
Btw, 4.3 generates

test:
.LFB518:
movhps  .LC0(%rip), %xmm0
ret

Likewise does gcc-4.4 (SUSE Linux) 4.4.0 20080611.  And current trunk.

So ... why are you exactly complaining about the code generated for -O0 again?


-- 


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

[Bug target/36992] Very stange code for _mm_move_epi64

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-08-01 12:04 ---
Google leads me to VC++ reference which says "Moves the lower 64 bits of the
lower 64 bits of the result, zeroing the upper bits.

I guess inlining and type fixing messes this up very early.


-- 


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

[Bug bootstrap/36995] [4.3 Regression] cannot build combined tree from 4.3 branch + trunk binutils

[joseph at codesourcery dot com]

--- Comment #1 from joseph at codesourcery dot com  2008-08-01 12:01 ---
Subject: Re:   New: [4.3 Regression] cannot build combined
 tree from 4.3 branch + trunk binutils

On Fri, 1 Aug 2008, bonzini at gnu dot org wrote:

> trunk binutils needs the sha1 implementation from libiberty, but it's not on
> 4.3 branch.  does the rule that gcc files should override the corresponding 
> src
> files hold for release branches?  if so, should i backport revision 133503 
> from
> trunk to 4.3 branch?  it is safe and only adds the relevant files to include/
> and libiberty/.

This is not a regression.  If using combined trees you always need to take 
the *most recent* version of libiberty and reconcile any API changes 
manually.


-- 


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

[Bug target/36992] Very stange code for _mm_move_epi64

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-08-01 11:58 ---
It's very (un-)useful that

extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_move_epi64 (__m128i __A)
{
  return _mm_set_epi64 ((__m64)0LL, _mm_movepi64_pi64 (__A));
}

it is not even documented what the function is supposed to do...


-- 


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

[Bug c++/36408] [4.3/4.4 regression] ICE with statement expression in template

[dgregor at gcc dot gnu dot org]

--- Comment #8 from dgregor at gcc dot gnu dot org  2008-08-01 11:55 ---
Thanks Jakub, Dodji for working on this. Some comments:

Some nits:

  - the error message we give in this case is pretty poor. Here we have an
empty initializer, but the error message we get back is "void value not ignored
as it ought to be", which really doesn't tell us much of anything about the
problem. The real issue here is that the statement expression has no return
value, so we should say as such. This same problem can occur with non-empty
statement expressions whose last statement does not produce a value, right? We
should test this case, too.

  - since the statement-expression is obviously empty, can we produce this
error message at template definition time, rather than waiting until
instantiation time? (If the answer isn't a quick "yes", don't worry about it;
I'll eventually be going through the initialization bits to check more of them
at template definition time anyway.)

  - is_pack_expansion_node_p is a pretty general name for a function that is
specific to initializer lists (in general, a TREE_LIST with a pack expansion in
its TREE_VALUE isn't necessarily an "expansion node"). I suggest calling this
"initializer_is_pack_expansion_p".

  - Please put some braces inside the if (init && !t) block. Omitting the
braces for "then" and "else" is okay for small one-liner bodies, but shouldn't
be done when there are if-elses nested inside.

  - parse/empty-statement.C is a strange place to put this check, which deals
with template instantiation. Perhaps call it template/empty-init-statement.C?

  - In the top of the testcase, "PR c++/P36408" should be "PR c++/36408"


-- 


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

[Bug middle-end/36997] [4.4 Regression] ICE with incompatible arg to '__builtin_ia32_paddq

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-08-01 11:49 ---
gimplify_call_expr sets *expr_p to NULL_TREE on GS_ERROR.  Setting it to
error_mark_node instead fixes the problem.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Keywords||error-recovery
   Last reconfirmed|-00-00 00:00:00 |2008-08-01 11:49:24
   date||
   Target Milestone|--- |4.4.0


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

[Bug c++/36993] g++ crashes with segfault upon wrong placement of case label

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-08-01 11:48 ---
GCC 3.3 accepts the code with

t.C: In function `int main()':
t.C:3: warning: unreachable code at beginning of switch statement


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-invalid-code
  Known to fail||4.1.3 4.2.4 4.3.1 4.4.0
  Known to work||3.3.3
   Last reconfirmed|-00-00 00:00:00 |2008-08-01 11:48:46
   date||


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

[Bug middle-end/36997] New: [4.4 Regression] ICE with incompatible arg to '__builtin_ia32_paddq

[rguenth at gcc dot gnu dot org]

typedef int __m64 __attribute__ ((__vector_size__ (8), __may_alias__));
__m64
_mm_add_si64 (__m64 __m1, __m64 __m2) 
{
  return (__m64) __builtin_ia32_paddq ((long long)__m1, (long long)__m2);
}

0x009d7b13 in tree_ssa_useless_type_conversion (expr=0x0)
at /space/rguenther/src/svn/trunk/gcc/tree-ssa.c:1235
1235  if (CONVERT_EXPR_P (expr)

#0  0x009d7b13 in tree_ssa_useless_type_conversion (expr=0x0)
at /space/rguenther/src/svn/trunk/gcc/tree-ssa.c:1235
#1  0x006e5c21 in gimplify_compound_lval (expr_p=0x77ff8338, 
pre_p=0x7fffccc0, post_p=0x7fffb800, fallback=fb_rvalue)
at /space/rguenther/src/svn/trunk/gcc/gimplify.c:2094
#2  0x00702a7f in gimplify_expr (expr_p=0x77ff8338, 
pre_p=0x7fffccc0, post_p=0x7fffb800, 
gimple_test_f=0x6dc3ae , fallback=fb_rvalue)
at /space/rguenther/src/svn/trunk/gcc/gimplify.c:6301
#3  0x006f3dfe in gimplify_modify_expr (expr_p=0x7fffc0f8, 
pre_p=0x7fffccc0, post_p=0x7fffb800, want_value=0 '\0')
at /space/rguenther/src/svn/trunk/gcc/gimplify.c:4252
#4  0x00702bcb in gimplify_expr (expr_p=0x7fffc0f8, 
pre_p=0x7fffccc0, post_p=0x7fffb800, 
gimple_test_f=0x6d4265 , fallback=fb_none)
at /space/rguenther/src/svn/trunk/gcc/gimplify.c:6342

6301  ret = gimplify_compound_lval (expr_p, pre_p, post_p,
(gdb) call debug_generic_expr (*expr_p)
VIEW_CONVERT_EXPR()

the V_C_E has a NULL_TREE arg0 ...

Breakpoint 3, gimplify_stmt (stmt_p=0x7752b998, seq_p=0x7fffd888)
at /space/rguenther/src/svn/trunk/gcc/gimplify.c:5018
5018  if (!*seq_p)
(gdb) call debug_generic_expr (*stmt_p)
{
  return (__m64) VIEW_CONVERT_EXPR(__builtin_ia32_paddq (<<< error
>>>, <<< error >>>));
}

hmm, no wonder.


-- 
   Summary: [4.4 Regression] ICE with incompatible arg to
'__builtin_ia32_paddq
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org


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

[Bug tree-optimization/36991] [4.3 Regression] ICE in remove_useless_stmts_1, at tree-cfg.c:1882

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-08-01 11:36 ---
Actually the 4.4 ICE is different.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.3.1 4.4.0 |4.3.1
  Known to work|4.2.4   |4.2.4 4.4.0
Summary|[4.3/4.4 Regression] ICE in |[4.3 Regression] ICE in
   |remove_useless_stmts_1, at  |remove_useless_stmts_1, at
   |tree-cfg.c:1882 |tree-cfg.c:1882


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

[Bug middle-end/36988] [4.4 Regression] ICE in gimple_rhs_has_side_effects, at gimple.c:2369

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-08-01 11:22 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/36991] [4.3/4.4 Regression] ICE in remove_useless_stmts_1, at tree-cfg.c:1882

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-08-01 11:21 ---
After gimplification we have

  D.1560 = {D.1558, D.1559, 0.0, 0.0};
  dV2_dv->v[0][1] = D.1560;
  D.1561 = dV2_dv->v[0][1];
  dV2_dv->v[1][0] = D.1561;

but

dV2_dv->v[0][1] = D.1560

seems to be still a MODIFY_EXPR.


-- 


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

[Bug middle-end/36988] [4.4 Regression] ICE in gimple_rhs_has_side_effects, at gimple.c:2369

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-08-01 11:19 ---
Subject: Bug 36988

Author: rguenth
Date: Fri Aug  1 11:18:36 2008
New Revision: 138512

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138512
Log:
2008-08-01  Richard Guenther  <[EMAIL PROTECTED]>

PR tree-optimization/36988
* tree-ssa-ccp.c (ccp_fold): Conversions of constants only
do not matter if that doesn't change volatile qualification.

* gcc.c-torture/compile/pr36988.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr36988.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ccp.c


-- 


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

[Bug tree-optimization/36991] [4.3/4.4 Regression] ICE in remove_useless_stmts_1, at tree-cfg.c:1882

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-08-01 11:15 ---
Confirmed.  Reduced testcase:

typedef float v4sf __attribute__ ((vector_size(16)));
typedef v4sf v4;
typedef union {
  v4sf v[4][4];
} m4v4;
void skew3(const v4 _v, m4v4 *dV2_dv)
{
  float *v = ((float *) &_v);
  if (dV2_dv)
dV2_dv->v[1][0] = dV2_dv->v[0][1] = (v4){ v[1], v[0], 0., 0};
}


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
  Known to fail||4.3.1 4.4.0
  Known to work||4.2.4
   Last reconfirmed|-00-00 00:00:00 |2008-08-01 11:15:10
   date||
Summary|internal compiler error: in |[4.3/4.4 Regression] ICE in
   |remove_useless_stmts_1, at  |remove_useless_stmts_1, at
   |tree-cfg.c:1882 |tree-cfg.c:1882
   Target Milestone|--- |4.3.2


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

[Bug c/36996] Bad optimization

[schwab at suse dot de]

--- Comment #1 from schwab at suse dot de  2008-08-01 10:59 ---
This depends on undefined behaviour when mask + 0x overflows.  Change
mask to unsigned to get defined behaviour.


-- 

schwab at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/35852] -Wconversion rejects bitwise negation and assignment, cannot cast around

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2008-08-01 10:22 
---
If you just comment out the andnot(T&, T&&) overload, and compile without
-std=c++0x, I think the warnings at issue are all still there.


-- 


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

[Bug c++/35852] -Wconversion rejects bitwise negation and assignment, cannot cast around

[manu at gcc dot gnu dot org]

--- Comment #2 from manu at gcc dot gnu dot org  2008-08-01 10:08 ---
Could you provide a testcase that does not need -std=c++0x ?


-- 


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

[Bug c/36996] New: Bad optimization

[nroets at gmail dot com]

When the program below is compiled with -O2, it goes into an endless loop.

#include 

int main (void)
{
  int mask;
  for (mask = 0; (mask & 7) != 4; mask += 0x) {
printf ("%x\n", mask & 7);
  }
}

The output of gcc -v is 
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-targets=all --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)


-- 
   Summary: Bad optimization
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nroets at gmail dot com
GCC target triplet: i486-linux-gnu


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

[Bug rtl-optimization/35542] [4.3 Regression] fwprop only propagates one operand

[bonzini at gcc dot gnu dot org]

--- Comment #9 from bonzini at gnu dot org  2008-08-01 09:55 ---
Subject: Bug 35542

Author: bonzini
Date: Fri Aug  1 09:54:04 2008
New Revision: 138505

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138505
Log:
2008-08-01  Paolo Bonzini  <[EMAIL PROTECTED]>

Backport from mainline:
2008-04-02  Andy Hutchinson <[EMAIL PROTECTED]>

PR rtl-optimization/35542
* fwprop.c (forward_propagate_and_simplify): Replace
loc_reg_mentioned_in_p with reg_mentioned_p.


Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/fwprop.c


-- 


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

[Bug rtl-optimization/35542] [4.3 Regression] fwprop only propagates one operand

[bonzini at gnu dot org]

--- Comment #8 from bonzini at gnu dot org  2008-08-01 09:54 ---
backported


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work|4.4.0   |4.4.0 4.3.2
 Resolution||FIXED


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

[Bug bootstrap/35752] [4.3 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[bonzini at gcc dot gnu dot org]

--- Comment #61 from bonzini at gnu dot org  2008-08-01 09:52 ---
Subject: Bug 35752

Author: bonzini
Date: Fri Aug  1 09:51:03 2008
New Revision: 138504

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138504
Log:
2008-08-01  Paolo Bonzini  <[EMAIL PROTECTED]>

PR bootstrap/35752
* Makefile.in (objdir): Set it here.
* configure.ac: Not here.  Find dynamic linker characteristics.
* exec-tool.in: Use them.
* aclocal.m4: Regenerate.
* configure: Regenerate.


Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/Makefile.in
branches/gcc-4_3-branch/gcc/aclocal.m4
branches/gcc-4_3-branch/gcc/configure
branches/gcc-4_3-branch/gcc/configure.ac
branches/gcc-4_3-branch/gcc/exec-tool.in


-- 


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

[Bug middle-end/36988] [4.4 Regression] ICE in gimple_rhs_has_side_effects, at gimple.c:2369

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-08-01 09:37 ---
typedef struct {
unsigned char mbxCommand;
} MAILBOX_t;
void lpfc_sli_brdrestart(void)
{
  volatile unsigned int word0;
  MAILBOX_t *mb;
  mb = (MAILBOX_t *) &word0;
  mb->mbxCommand = 0x1A;
  __writel((*(unsigned int *) mb));
}

So, we CCP &word0 into *mb.0_2 in

:
  mb_1 = (struct MAILBOX_t *) &word0;
  mb_1->mbxCommand ={v} 26;
  mb.0_2 = (unsigned int *) mb_1;
  D.1953_3 = *mb.0_2;

which is ok, but since word0 is volatile (and thus has TREE_SIDE_EFFECTS set)
the assert in gimple_rhs_has_side_effects complains about the statement
not being volatile, which is bogus.

The real problem here is that we do not trust the statement state
(this wasn't a volatile load in the source, so it should not become one
by mere propagation either), but try to verify it using state on the operands.
Now - as DECLs are shared - we have no choice other than making the statement
volatile here or not doing the propagation.  Both of which sucks, as we
have to sprinkle code to deal which such cases everywhere.


-- 


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

[Bug c++/36408] [4.3/4.4 regression] ICE with statement expression in template

[dodji at gcc dot gnu dot org]

--- Comment #7 from dodji at gcc dot gnu dot org  2008-08-01 09:33 ---
Created an attachment (id=15989)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15989&action=view)
fixed a typo.

Woops, thanks Paolo. I have Updated the patch.


-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #15988|0   |1
is obsolete||


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

[Bug bootstrap/36995] New: [4.3 Regression] cannot build combined tree from 4.3 branch + trunk binutils

[bonzini at gnu dot org]

trunk binutils needs the sha1 implementation from libiberty, but it's not on
4.3 branch.  does the rule that gcc files should override the corresponding src
files hold for release branches?  if so, should i backport revision 133503 from
trunk to 4.3 branch?  it is safe and only adds the relevant files to include/
and libiberty/.


-- 
   Summary: [4.3 Regression] cannot build combined tree from 4.3
branch + trunk binutils
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
  GCC host triplet: i686-pc-linux-gnu


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

[Bug c++/36408] [4.3/4.4 regression] ICE with statement expression in template

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2008-08-01 09:07 
---
Typo in dg-options: you mean c++0x


-- 


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

[Bug bootstrap/33503] [4.3/4.4 Regression] problems with libtool wrapper scripts on mingw32

[rwild at gcc dot gnu dot org]

--- Comment #3 from rwild at gcc dot gnu dot org  2008-08-01 09:05 ---
Have you tried configuring like this?

  CONFIG_SHELL='C:/msys/1.0/bin/sh.exe' C:/msys/1.0/bin/sh.exe \
../gcc-4.3XX/configure [OPTIONS...]


-- 


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

[Bug c++/36408] [4.3/4.4 regression] ICE with statement expression in template

[dodji at gcc dot gnu dot org]

-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dodji at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-08-01 08:55:06
   date||


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

[Bug c++/36408] [4.3/4.4 regression] ICE with statement expression in template

[dodji at gcc dot gnu dot org]

--- Comment #5 from dodji at gcc dot gnu dot org  2008-08-01 08:54 ---
Created an attachment (id=15988)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15988&action=view)
first fix attempt.

This patch fixes the problem for me on gcc-4_3-branch.

Regtested for x86_64 on gcc-4_3-branch. I will recompile my trunk right away
and test the patch there.
If the patch looks okayish to you guys and works on trunk for me I can send it
to gcc-patch for review.

Comments welcome.

Thanks.


-- 


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

[Bug bootstrap/33503] [4.3/4.4 Regression] problems with libtool wrapper scripts on mingw32

[bonzini at gnu dot org]

--- Comment #2 from bonzini at gnu dot org  2008-08-01 08:44 ---
not really a duplicate


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
  Known to fail||4.3.2 4.4.0
  Known to work||4.2.0
 Resolution|DUPLICATE   |
Summary|Can not build gcc from  |[4.3/4.4 Regression]
   |combined tree - bug in  |problems with libtool
   |libtool |wrapper scripts on mingw32


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

[Bug bootstrap/35752] [4.3 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[bonzini at gnu dot org]

--- Comment #60 from bonzini at gnu dot org  2008-08-01 08:26 ---
There is no need for additional patches: a trunk bootstrap is now building gcc
stage2, so it's fixed there.  I'll backport to 4.3 the patch from comment #36.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED
   Last reconfirmed|2008-04-21 15:52:43 |2008-08-01 08:26:06
   date||
Summary|[4.3/4.4 Regression]:   |[4.3 Regression]: Combined
   |Combined gcc + binutils |gcc + binutils source tree
   |source tree doesn't |doesn't bootstrap with --
   |bootstrap with --enable-|enable-shared
   |shared  |


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

[Bug fortran/34228] -std=f* should diagnose used but later typed variables

[domob at gcc dot gnu dot org]

-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |domob at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-11-29 11:24:37 |2008-08-01 08:26:38
   date||


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

[Bug other/36994] New: gcc/makefile contains one very long line (over 2k)

[jayk123 at hotmail dot com]

gcc-4.3.1/gcc/makefile contains one very long line, via substitution of
gtfiles.
This is "inconvenient" and "annoying" but works.
I have a patch for it. It has been seen to work on Cygwin, but not work on
Linux. Waiting for Autoconf >=2.60 (currently using 2.59) will make this
easier, so maybe just wait. I will see if I can make it work on a few
platforms, possibly by using per-language substitutions, without newlines.
(given that the list of languages is not hardcoded, not obviously trivial, but
maybe easy enough, gotta go read the code again..)

--- /src/gcc.orig/gcc/configure 2008-05-21 01:54:15.0 -0700
+++ /src/gcc/gcc/configure  2008-07-28 01:55:52.692206100 -0700
@@ -17026,13 +17026,31 @@
all_languages="$all_languages $language"
all_compilers="$all_compilers $compilers"
all_outputs="$all_outputs $outputs"
-   all_gtfiles="$all_gtfiles [$subdir] $gtfiles"
+# Three slashes: Later, via sed/AC_SUBST, first two will become one, third
escapes the newline.
+   all_gtfiles="$all_gtfiles"' \\\
+  '"[$subdir] $gtfiles"
 done

 # Pick up gtfiles for c
 gtfiles=
 . ${srcdir}/c-config-lang.in
-all_gtfiles="$all_gtfiles [c] $gtfiles"
+# Three slashes: Later, via sed/AC_SUBST, first two will become one, third
escapes the newline.
+all_gtfiles="$all_gtfiles"' \\\
+  '"[c] $gtfiles"
+
+#
+# Wrap every few elements in all_gtfiles, to keep line lengths
+# somewhat down, unless it has any quotes, which confuse things.
+#
+cat < conftest.gt1
+$all_gtfiles
+EOF
+if grep [\"\'] conftest.gt1; then :; else
+  # Six slashes will immediately become three slashes. Later, via
sed/AC_SUBST, first two will become one, third escapes the newline.
+  # The seventh slash is for the newline the first time.
+  sed 's/\([^ \\][^ \\]* \)\{5\}/\0\\\n  /g' conftest.gt1 > conftest.gt2
+  all_gtfiles=`cat conftest.gt2`
+fi

 check_languages=
 for language in $all_selected_languages
--- /src/gcc.orig/gcc/configure.ac  2008-05-21 01:54:15.0 -0700
+++ /src/gcc/gcc/configure.ac   2008-07-28 01:55:43.270331100 -0700
@@ -3639,13 +3639,33 @@
all_languages="$all_languages $language"
all_compilers="$all_compilers $compilers"
all_outputs="$all_outputs $outputs"
-   all_gtfiles="$all_gtfiles [[$subdir]] $gtfiles"
+# Three slashes: Later, via sed/AC_SUBST, first two will become one, third
escapes the newline.
+   all_gtfiles="$all_gtfiles"' \\\
+  '"[[$subdir]] $gtfiles"
 done

 # Pick up gtfiles for c
 gtfiles=
 . ${srcdir}/c-config-lang.in
-all_gtfiles="$all_gtfiles [[c]] $gtfiles"
+# Three slashes: Later, via sed/AC_SUBST, first two will become one, third
escapes the newline.
+all_gtfiles="$all_gtfiles"' \\\
+  '"[[c]] $gtfiles"
+
+#
+# Wrap every few elements in all_gtfiles, to keep line lengths
+# somewhat down, unless it has any quotes, which confuse things.
+#
+cat < conftest.gt1
+$all_gtfiles
+EOF
+changequote(,)dnl
+if grep [\"\'] conftest.gt1; then :; else
+  # Six slashes will immediately become three slashes. Later, via
sed/AC_SUBST, first two will become one, third escapes the newline.
+  # The seventh slash is for the newline the first time.
+  sed 's/\([^ \\][^ \\]* \)\{5\}/\0\\\n  /g' conftest.gt1 > conftest.gt2
+  all_gtfiles=`cat conftest.gt2`
+fi
+changequote([,])dnl

 check_languages=
 for language in $all_selected_languages


-- 
   Summary: gcc/makefile contains one very long line (over 2k)
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jayk123 at hotmail dot com
 GCC build triplet: any
  GCC host triplet: any
GCC target triplet: any


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

[Bug c++/36993] New: g++ crashes with segfault upon wrong placement of case label

[drahflow at gmx dot de]

given the following code:

int main(void) {
  switch(0)
for(struct T {
  void f() {
case 1: ;
  }
};; );
}

/tmp % g++ test11.c++ -O4 -W -Wall -Wextra --pedantic  
test11.c++: In member function 'void main()::T::f()':
test11.c++:5: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .


-- 
   Summary: g++ crashes with segfault upon wrong placement of case
label
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drahflow at gmx dot de


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