[Bug tree-optimization/23816] New: ICE in extract_insn, at recog.c:2084

[belyshev at depni dot sinp dot msu dot ru]

// test case, compile with "-O1 -fstrict-aliasing -ftree-vectorize" :

void foo (float a[32], float b[2][32])
{
  int i;
  for (i = 0; i < 32; i++)
a[i] = (b[0][i] > b[1][i]) ? b[0][i] : b[1][i];
}

// compiler output:
psy.i: In function 'foo':
psy.i:6: error: unrecognizable insn:
(insn 98 97 99 11 (set (reg:V4SF 110)
(unspec:V4SF [
(reg:V4SF 89 [ vect_var_.40 ])
(reg:V4SF 85 [ vect_var_.47 ])
] 52)) -1 (nil)
(nil))
psy.i:6: internal compiler error: in extract_insn, at recog.c:2084

-- 
   Summary: ICE in extract_insn, at recog.c:2084
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: belyshev at depni dot sinp dot msu dot ru
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug fortran/23815] New: Add -byteswapio flag

[rrr6399 at futuretek dot com]

It is pretty typical that aero engineers involved in CFD (computational
fluid dynamics) need to ship around large (50-1000 MB) binary files between
various big-endian and little-endian machines without having to reformat them. 

Typically they generate files that are all big-endian using a compiler switch to
avoid having to byte swap as well. So it'd be great to have a compiler switch
that reversed the byte order of integers (2, 4, 8 byte) and floating point
numbers (4, 8 byte) when they are read from or written to an unformatted file.

For instance if you had an 4 byte int stored as an array of chars,
you might swap it using this simple approach:
 for (i = 0; i < 4; i++ ) {
   swappedBytes[i] = bytes[3-i];
 }

or if you want to do the bit shifting thing, you do do it this way:

return (((buf [ 3 ] & 0xff) << 24) | ((buf [ 2 ] & 0xff) << 16) |
   ((buf [ 1 ] & 0xff) << 8) | (buf [ 0 ] & 0xff));

(I grabbed this code from converToInt() in: 
gcc-4.1-20050909/libjava/classpath/gnu/CORBA/CDR/LittleEndianInputStream.java)

-- 
   Summary: Add -byteswapio flag
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P1
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rrr6399 at futuretek dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug fortran/23814] unformatted files from gfortran are incompatible with g77 unformatted files and solaris f95 unformatted files

[rrr6399 at futuretek dot com]

--- Additional Comments From rrr6399 at futuretek dot com  2005-09-11 04:07 
---
I just found this discussion:
http://gcc.gnu.org/ml/fortran/2005-05/msg00431.html

It doesn't look like from the docs that it was implemented in the main-line yet,
is it available somehow else?

It seems to me that unformatted files on 32 bit machines should be compatible.
I don't know of any other fortran compiler that assumes 64 bit record markers. 
We really need a flag to change the behavior if it is not available already.

BTW, it is pretty typical that aero engineers involved in CFD (computational
fluid dynamics) need to ship around large (50-1000 MB) binary files between
various machines without having to reformat them. Typically they generate files
that are all big-endian using a compiler switch to avoid having to byte swap as
well. So, while we're at it, it'd be great to have a compiler switch that
reversed the byte order of integers (2, 4, 8 byte) and floating point numbers
(4, 8 byte) when they are read from or written to an unformatted file.


-- 


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

[Bug fortran/23814] New: unformatted files from gfortran are incompatible with g77 unformatted files and solaris f95 unformatted files

[rrr6399 at futuretek dot com]

I ran into a problem with unformatted files with gfortran. It appears that it is
padding the delimitters to 8 byte boundaries (or the delimitters are 64 bit
longs) rather than the normal 4 byte delimitter approach. 

For instance, I have a program that does this:

   write(1) 1
   end

g77 and solaris f95 returns (ignoring the byteswapping issues):
od -x fort.1:
000 0004  0001  0004 

gfortran returns:
000 0004    0001  0004 
020  

is there a flag to make the delimitters 4 bytes rather than 8 bytes?

-- 
   Summary: unformatted files from gfortran are incompatible with
g77 unformatted files and solaris f95 unformatted files
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P1
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rrr6399 at futuretek dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector

[billy dot biggs at gmail dot com]

--- Additional Comments From billy dot biggs at gmail dot com  2005-09-11 
03:02 ---
The original bug report is dated 2003-11-27.   greenrd -- are you sure this is
the sasme bug?

-- 
   What|Removed |Added

 CC||billy dot biggs at gmail dot
   ||com


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

[Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector

[david at jpackage dot org]

--- Additional Comments From david at jpackage dot org  2005-09-11 02:59 
---
I am experiencing something that looks similar to this with eclipse on x86_64.
Here is the stack trace on amd64.

#0  0x2bb7c710 in GC_local_gcj_malloc () from 
/usr/lib/../lib64/libgcj.so.6
#1  0x2b7c4fa0 in _Jv_AllocObjectNoFinalizer () from
/usr/lib/../lib64/libgcj.so.6
#2  0x2b7c4ff8 in _Jv_AllocObject () from /usr/lib/../lib64/libgcj.so.6
#3  0x2b7c50fd in _Jv_remJ () from /usr/lib/../lib64/libgcj.so.6
#4  
#5  0x2bb7d835 in GC_local_malloc_atomic () from
/usr/lib/../lib64/libgcj.so.6
#6  0x2b7c4f13 in _Jv_AllocString () from /usr/lib/../lib64/libgcj.so.6
#7  0x2b7fcdd4 in _Jv_NewString () from /usr/lib/../lib64/libgcj.so.6
#8  0x2b7fe3e8 in java::lang::Thread::gen_name () from
/usr/lib/../lib64/libgcj.so.6
#9  0x2b7fea0d in _Jv_AttachCurrentThread () from
/usr/lib/../lib64/libgcj.so.6
#10 0x2b7c76c2 in _Jv_FreeJNIEnv () from /usr/lib/../lib64/libgcj.so.6
#11 0x2aaab17e6b32 in callback () from
/home/david/.eclipse/org.eclipse.osgi/bundles/104/1/.cp/libswt-gtk-3138.so
#12 0x2aaab17d4bb7 in fn70_4 () from
/home/david/.eclipse/org.eclipse.osgi/bundles/104/1/.cp/libswt-gtk-3138.so
#13 0x2aaab6f46441 in NSGetModule () from
/usr/lib64/mozilla-firefox-1.0.6/components/libnecko.so
#14 0x2aaab6342746 in nsStreamCopierOB::FillOutputBuffer () from
/usr/lib64/mozilla-firefox-1.0.6/libxpcom.so
#15 0x2aaab6341815 in nsPipe::OnPipeException () from
/usr/lib64/mozilla-firefox-1.0.6/libxpcom.so
#16 0x2aaab6342a6d in nsStreamCopierOB::DoCopy () from
/usr/lib64/mozilla-firefox-1.0.6/libxpcom.so
#17 0x2aaab63428b6 in nsAStreamCopier::Process () from
/usr/lib64/mozilla-firefox-1.0.6/libxpcom.so
#18 0x2aaab6342d4f in nsAStreamCopier::HandleContinuationEvent () from
/usr/lib64/mozilla-firefox-1.0.6/libxpcom.so
#19 0x2aaab63577c9 in PL_HandleEvent () from
/usr/lib64/mozilla-firefox-1.0.6/libxpcom.so
#20 0x2aaab6f3d3f8 in NSGetModule () from
/usr/lib64/mozilla-firefox-1.0.6/components/libnecko.so
#21 0x2aaab66e2b14 in PR_Select () from /usr/lib/../lib64/libnspr4.so
#22 0x2c6ed91c in start_thread () from /lib64/tls/libpthread.so.0
#23 0x2c5771f2 in clone () from /lib64/tls/libc.so.6
#24 0x in ?? ()


-- 


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

[Bug rtl-optimization/23813] New: redundant register assignments not eliminated

[raeburn at raeburn dot org]

(CVS sources from ~6AM today US/Eastern, i.e., about 16 hours before submission)

Compiling source below with -O9 -fomit-frame-pointer, there are cases where 
registers are assigned 
multiple times without any labels in between; a register assigned zero, used in 
an inclusive-or, then 
overwritten; another register assigned zero and never used.

This 64-bit byteswap routine also exhibits the problems I submitted in 23810, 
23811, 23812, but I 
think one or two of these might be separate problems from those.

typedef unsigned long long uint64_t;
typedef unsigned long uint32_t;
uint64_t bitreverse (uint64_t n) {
  /* Dr. Dobbs Journal 1983, reported in Sean Eron Anderson's "bit
 twiddling hacks" web site,
 http://graphics.stanford.edu/~seander/bithacks.html .  */
#define REV64_STEP(VAR, SHIFT, MASK) \
  VAR = (((VAR >> SHIFT) & MASK) | ((VAR << SHIFT) & (0xULL & 
~MASK)))

  REV64_STEP(n,  1, 0xULL); /* odd/even bits */
  REV64_STEP(n,  2, 0xULL); /* bitpairs */
  REV64_STEP(n,  4, 0x0F0F0F0F0F0F0F0FULL); /* nibbles */
  REV64_STEP(n,  8, 0x00FF00FF00FF00FFULL); /* bytes */
  REV64_STEP(n, 16, 0xULL); /* halfwords */
  REV64_STEP(n, 32, 0xULL); /* full words */
  return n;
}

assembly generated:

bitreverse:
pushl   %edi
pushl   %esi
pushl   %ebx
movl16(%esp), %eax
movl20(%esp), %edx
movl%eax, %ecx
movl%edx, %ebx
shrdl   $1, %ebx, %ecx
shldl   $1, %eax, %edx
addl%eax, %eax
shrl%ebx
andl$-1431655766, %eax
andl$-1431655766, %edx
andl$1431655765, %ecx
andl$1431655765, %ebx
orl %eax, %ecx
orl %edx, %ebx
movl%ecx, %eax
movl%ebx, %edi
movl%ecx, %esi
movl%ebx, %edx
shrdl   $2, %edi, %esi
shldl   $2, %eax, %edx
andl$858993459, %esi
shrl$2, %edi
andl$-858993460, %edx
sall$2, %eax
andl$858993459, %edi
andl$-858993460, %eax
orl %edx, %edi
orl %eax, %esi
movl%edi, %ebx
movl%esi, %eax
movl%esi, %ecx
movl%edi, %edx
shrdl   $4, %ebx, %ecx
shldl   $4, %eax, %edx
andl$252645135, %ecx
shrl$4, %ebx
andl$-252645136, %edx
sall$4, %eax
andl$252645135, %ebx
andl$-252645136, %eax
orl %edx, %ebx
orl %eax, %ecx
movl%ebx, %edi
movl%ecx, %esi
movl%ecx, %eax
shrdl   $8, %edi, %esi
movl%ebx, %edx
shrl$8, %edi
andl$16711935, %esi
andl$16711935, %edi
shldl   $8, %eax, %edx
sall$8, %eax
andl$-16711936, %edx
andl$-16711936, %eax
orl %edx, %edi
orl %eax, %esi
# we're about to copy this from esi to eax then clear esi;
# wouldn't putting output in eax be better?
movl%edi, %ebx
movl%esi, %eax
movl%esi, %ecx
movl%edi, %edx
xorl%esi, %esi # esi set to zero
# PRs 23810, 23811 look at this code:
shrdl   $16, %ebx, %ecx
shldl   $16, %eax, %edx
andl$65535, %ecx
shrl$16, %ebx
andl$-65536, %edx
andl$65535, %ebx
sall$16, %eax
orl %edx, %ebx
andl$-65536, %eax
movl%ebx, %edx
orl %eax, %ecx # output to ecx then move to eax, instead of just 
output to eax?
movl%ecx, %ebx # ebx only used to ior into edx, while ecx value 
still live
movl%ecx, %eax # assign eax twice??
movl%edx, %eax
xorl%edx, %edx # clear edx twice??
xorl%edx, %edx
orl %esi, %eax # esi still zero
orl %ebx, %edx
movl$0, %ecx # why? insn note shows REG_UNUSED
popl%ebx
popl%esi
popl%edi
ret

A version of this swap routine that splits the 64-bit value into two 32-bit 
chunks, performs bit-
reversals on the chunks, and puts the two chunks back together in reverse 
order, comes out shorter, 
despite still showing the PR23810/23811 problems, but it does the same work as 
this function should.

I suspect at least some of these come from preserving DImode operations until 
fairly late, e.g., 
assigning a DImode to eax/edx, then shifting right 32 (eax:=edx, edx:=0), stuff 
like that.  I haven't 
figured out the esi and ecx bits yet though.

-- 
   Summary: redundant register assignments not eliminated
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc do

[Bug rtl-optimization/23812] New: swapping DImode halves produces poor x86 register allocation

[raeburn at raeburn dot org]

(CVS sources, ~6AM this morning US/eastern)

typedef unsigned long long uint64_t;
uint64_t foo (uint64_t n) {
  return (n >> 32) | (n << 32);
}

compiled with -O9 -fomit-frame-pointer:

foo:
pushl   %ebx
movl12(%esp), %ebx
movl8(%esp), %ecx
movl%ebx, %eax
popl%ebx
movl%ecx, %edx
ret

It should've been able to load 4(%esp) and 8(%esp) into %edx and %eax 
respectively, without using the 
extra stack slot to save ebx.

-- 
   Summary: swapping DImode halves produces poor x86 register
allocation
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raeburn at raeburn dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c++/20293] [3.4/4.0/4.1 regression] Wrong diagnostic for ambiguous access

[bangerth at dealii dot org]

-- 
Bug 20293 depends on bug 100, which changed state.

Bug 100 Summary: confusing name lookup diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=100

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

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

[Bug c++/12272] wrong error message using declaration shadows namespace

[bangerth at dealii dot org]

-- 
Bug 12272 depends on bug 100, which changed state.

Bug 100 Summary: confusing name lookup diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=100

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

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

[Bug c++/100] confusing name lookup diagnostic

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2005-09-11 01:50 
---
This is good enough. The fact that the compiler says that a name is 
not declared when it is in fact ambiguous is treated in a number of 
other PRs. 
 
W. 

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/23811] New: returning 64-bit value turns off some 32-bit optimizations

[raeburn at raeburn dot org]

The function below, compiled with -O9 -fomit-frame-pointer, fails to optimize 
the final 16-bit swap 
into an x86 "roll" instruction *if* the return type is uint64_t.  If the return 
type is uint32_t, a roll 
instruction is generated, and the resulting code is 6 instructions (19 bytes) 
shorter.  All of the math in 
the function is done in 32-bit unsigned values, so ideally the only effect of 
setting the return type to 
uint64_t should be that the compiler arranges for %edx to be zero at the end.

typedef unsigned long long uint64_t;
typedef unsigned long uint32_t;
#define REV32STEP(VAR, SHIFT, MASK) \
  VAR = (((VAR >> SHIFT) & MASK) | ((VAR << SHIFT) & (0xUL & ~MASK)))
uint64_t bitreverse2 (uint32_t n) {
  uint32_t lower = n;
  REV32STEP(lower,  1, 0xUL); /* odd/even bits */
  REV32STEP(lower,  2, 0xUL); /* bitpairs */
  REV32STEP(lower,  4, 0x0F0F0F0FUL); /* nibbles */
  REV32STEP(lower,  8, 0x00FF00FFUL); /* bytes */
  REV32STEP(lower, 16, 0xUL); /* halfwords */
  return lower;
}

64-bit version:

bitreverse2:
movl4(%esp), %edx
movl%edx, %eax
addl%edx, %edx
shrl%eax
andl$-1431655766, %edx
andl$1431655765, %eax
orl %edx, %eax
movl%eax, %edx
shrl$2, %edx
sall$2, %eax
andl$858993459, %edx
andl$-858993460, %eax
orl %eax, %edx
movl%edx, %eax
shrl$4, %eax
sall$4, %edx
andl$252645135, %eax
andl$-252645136, %edx
orl %edx, %eax
xorl%edx, %edx   # <- edx is cleared here
movl%eax, %ecx
shrl$8, %ecx
sall$8, %eax
andl$16711935, %ecx
andl$-16711936, %eax
orl %eax, %ecx
# final swap starts here
movl%ecx, %eax
shrl$16, %eax
sall$16, %ecx
andl$65535, %eax# <- redundant after shift
andl$-65536, %ecx  # <- redundant after shift
orl %ecx, %eax
ret

32-bit version:

bitreverse2:
movl4(%esp), %edx
movl%edx, %eax
addl%edx, %edx
shrl%eax
andl$-1431655766, %edx
andl$1431655765, %eax
orl %edx, %eax
movl%eax, %edx
shrl$2, %edx
sall$2, %eax
andl$858993459, %edx
andl$-858993460, %eax
orl %eax, %edx
movl%edx, %ecx
shrl$4, %ecx
sall$4, %edx
andl$252645135, %ecx
andl$-252645136, %edx
orl %edx, %ecx
movl%ecx, %eax
shrl$8, %eax
sall$8, %ecx
andl$16711935, %eax
andl$-16711936, %ecx
orl %ecx, %eax
roll$16, %eax # <- final swap
ret

This is with compiler sources from CVS as of about 6AM this morning US/Eastern.

-- 
   Summary: returning 64-bit value turns off some 32-bit
optimizations
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: minor
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raeburn at raeburn dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug rtl-optimization/23810] New: missed 64-bit shift+mask optimizations on 32-bit arch

[gcc-bugzilla at gcc dot gnu dot org]

(Sources are from CVS as of about 6AM US/Eastern time today.)

I'm testing out how well gcc optimizes some code for reversing bit
strings.  It appears that on x86 at least, double-word shifts followed
by masks that zero out all the bits that crossed the word boundary are
not optimized as well as they could be.

In the included file, compiled with "-O9 -fomit-frame-pointer",
functions rt and rt2 both result in assembly code including a
double-word shift, bringing two bits from the upper half of the
argument into the top of the lower half of the double-word value, then
masks that word with 0x, which zeros out those bits:

rt:
movl8(%esp), %edx
movl4(%esp), %eax
shrdl   $2, %edx, %eax
shrl$2, %edx
andl$858993459, %eax
andl$858993459, %edx
ret

Okay, in this case, the only optimization would be to make the shift
not reference both %edx and %eax, and drop the reference to the upper
half flom the RTL during optimization.  To highlight the issue a
little more, rt4 is like rt but only returns the lower half.  Still,
the upper half is read in from memory (and shifted!) needlessly:

rt4:
movl8(%esp), %edx
movl4(%esp), %eax
shrdl   $2, %edx, %eax
andl$858993459, %eax
shrl$2, %edx
ret

Function left shows the same problem, shifting in the opposite
direction:

left:
movl4(%esp), %eax
movl8(%esp), %edx
shldl   $2, %eax, %edx
sall$2, %eax
andl$-858993460, %edx
andl$-858993460, %eax
ret

The "andl" of %edx with 0x will clobber the bits brought in
from %eax.

I haven't got the hang of reading ppc assembly yet, but I think the
Mac OS X compiler (10.4.2 = "gcc version 4.0.0 (Apple Computer,
Inc. build 5026)") is missing similar optimizations.  I haven't tried
the cvs code on ppc.

Environment:
System: Linux kal-el 2.4.17 #4 SMP Sun Apr 6 16:25:37 EDT 2003 i686 GNU/Linux
Architecture: i686


host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../src/configure --enable-maintainer-mode 
--prefix=/u3/raeburn/gcc/linux/Install --enable-languages=c,c++,java,objc 
--no-create --no-recursion : (reconfigured) ../src/configure 
--prefix=/u3/raeburn/gcc/linux/Install

How-To-Repeat:

typedef unsigned long long uint64_t;
typedef unsigned long uint32_t;

uint64_t rt (uint64_t n) { return (n >> 2) & 0xULL; }
uint64_t rt2 (uint64_t n) { return (n & (0xULL << 2)) >> 2; }
uint32_t rt4 (uint64_t n) { return (n >> 2) & 0x; }
uint64_t left(uint64_t n) {
  return (n << 2) & (0xULL & ~0xULL);
}

-- 
   Summary: missed 64-bit shift+mask optimizations on 32-bit arch
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raeburn at raeburn dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c/23809] Misleading documentation for -mmmx/msse/...

[steven at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-09-10 22:10:26
   date||


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

[Bug c/23809] Misleading documentation for -mmmx/msse/...

[billy dot biggs at gmail dot com]

--- Additional Comments From billy dot biggs at gmail dot com  2005-09-10 
22:04 ---
Created an attachment (id=9706)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9706&action=view)
Patch


-- 


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

[Bug c/23809] New: Misleading documentation for -mmmx/msse/...

[billy dot biggs at gmail dot com]

The compiler options for -mmmx, -msse, etc, serve two purposes:

  1. They allow the programmer to use the compiler built-ins for easily
 writing MMX/SSE code.
  2. They allow the compiler to use MMX/SSE instructions in generated code.

However, the documentation does not explicitly state the second point, only
the first.  This had caused much confusion in the development community, as
programmers using the MMX/SSE intrinsics often use runtime CPU detection.

The attached patch updates the documentation to be more explicit about the
effect of these options.

-- 
   Summary: Misleading documentation for -mmmx/msse/...
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: billy dot biggs at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug fortran/22502] [4.0.1 Regression] ICE constructing arrays with "(/ /)"

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2005-09-10 
21:42 ---
Now also fixed on the 4.0 branch.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.0.2


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

[Bug fortran/22502] [4.0.1 Regression] ICE constructing arrays with "(/ /)"

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-09-10 
21:40 ---
Subject: Bug 22502

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-09-10 21:40:00

Modified files:
gcc/fortran: ChangeLog trans-types.h 

Log message:
PR fortran/22502
Backport:

2005-07-29  Steven Bosscher  <[EMAIL PROTECTED]>
* trans-types.h (gfc_array_range_type): Add missing GTY decl for this.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.335.2.116&r2=1.335.2.117
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-types.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.9&r2=1.9.14.1



-- 


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

[Bug debug/23806] [4.0/4.1 Regression] -gstabs with VLAs does not work

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-09-10 21:13 
---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug debug/23806] [4.0/4.1 Regression] -gstabs with VLAs does not work

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-09-10 
21:11 ---
Subject: Bug 23806

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-09-10 21:11:30

Modified files:
gcc: ChangeLog dbxout.c 

Log message:
PR debug/23806
* dbxout.c (dbxout_expand_expr): New.
(dbxout_symbol): Use it.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.424&r2=2.7592.2.425
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/dbxout.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.221.2.3&r2=1.221.2.4



-- 


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

[Bug debug/23806] [4.0/4.1 Regression] -gstabs with VLAs does not work

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-09-10 
21:10 ---
Subject: Bug 23806

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-09-10 21:10:43

Modified files:
gcc: ChangeLog dbxout.c 

Log message:
PR debug/23806
* dbxout.c (dbxout_expand_expr): New.
(dbxout_symbol): Use it.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9930&r2=2.9931
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/dbxout.c.diff?cvsroot=gcc&r1=1.238&r2=1.239



-- 


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

[Bug middle-end/23125] [4.0/4.1 Regression] OpenBSD's zic.c causes g++ but not gcc to segfault

[geoffk at geoffk dot org]

--- Additional Comments From geoffk at geoffk dot org  2005-09-10 20:34 
---
Subject: Re:  [4.0/4.1 Regression] OpenBSD's zic.c causes g++ but not gcc to 
segfault


On 09/09/2005, at 9:56 PM, pinskia at gcc dot gnu dot org wrote:

> So it is little harder to fix than I had previous thought as there  
> is no way to know if user set the decl
> name or if it was just the name of the decl.   The front-ends have  
> to be fixed to call
> set_user_assembler_name all the time and then make_decl_rtl needs  
> to be updated for that but I don't
> have the time to test that patch.

You should be able to tell if the user set the name because it will  
start with a '*'.



-- 


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

[Bug c++/100] confusing name lookup diagnostic

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-10 
19:26 ---
*** Bug 12582 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||mckelvey at maskull dot com


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

[Bug c++/12582] unhelpful message with ambiguous typedef

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-10 
19:25 ---
This is a dup of bug 100.

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

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/12349] gcc accepts specialization of template in typedef

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-10 
19:24 ---
Fixed in 4.0.0:
t.cc:3: error: template declaration of ‘typedef’


-- 
   What|Removed |Added

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


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

[Bug tree-optimization/18412] missed vectorization opportunity due to aliasing issue

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-10 
18:16 ---
This is really a three fold problem.  First cobbler needs to be flow sensitive. 
 Second Array references 
need to be allowed on pointers.  Thrid, scanf needs to be marked as only 
touching the pointers passed 
to it.

-- 
   What|Removed |Added

  BugsThisDependsOn||23384


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

[Bug middle-end/16802] PowerPC - Unnecessary extsw

[pinskia at gcc dot gnu dot org]

-- 
Bug 16802 depends on bug 18373, which changed state.

Bug 18373 Summary: [meta-bug] VRP Value Range Propagation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18373

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/21258] Teach VRP to pick up a constant from case label.

[pinskia at gcc dot gnu dot org]

-- 
Bug 21258 depends on bug 18373, which changed state.

Bug 18373 Summary: [meta-bug] VRP Value Range Propagation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18373

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/14341] Missed comparison optimization (VRP)

[pinskia at gcc dot gnu dot org]

-- 
Bug 14341 depends on bug 18373, which changed state.

Bug 18373 Summary: [meta-bug] VRP Value Range Propagation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18373

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/17100] Missed opportunity for value range optimization

[pinskia at gcc dot gnu dot org]

-- 
Bug 17100 depends on bug 18373, which changed state.

Bug 18373 Summary: [meta-bug] VRP Value Range Propagation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18373

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/21368] VRP does not know that &s.a != NULL

[pinskia at gcc dot gnu dot org]

-- 
Bug 21368 depends on bug 18373, which changed state.

Bug 18373 Summary: [meta-bug] VRP Value Range Propagation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18373

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/20701] [tcb] VRP does not eliminate a redundant "if" statement.

[pinskia at gcc dot gnu dot org]

-- 
Bug 20701 depends on bug 18373, which changed state.

Bug 18373 Summary: [meta-bug] VRP Value Range Propagation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18373

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug middle-end/21076] [4.1 Regression] ACATs ICE cxh1001 at tree-vrp.c:124 (fold bug)

[pinskia at gcc dot gnu dot org]

-- 
Bug 21076 depends on bug 18373, which changed state.

Bug 18373 Summary: [meta-bug] VRP Value Range Propagation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18373

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/21090] VRP does not notice nonzero-ness from a PHI node

[pinskia at gcc dot gnu dot org]

-- 
Bug 21090 depends on bug 18373, which changed state.

Bug 18373 Summary: [meta-bug] VRP Value Range Propagation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18373

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/21348] tree-vrp.c:has_assert_expr is useless.

[pinskia at gcc dot gnu dot org]

-- 
Bug 21348 depends on bug 18373, which changed state.

Bug 18373 Summary: [meta-bug] VRP Value Range Propagation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18373

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/21367] VRP does not fold "if (a == b)" in a certain situation

[pinskia at gcc dot gnu dot org]

-- 
Bug 21367 depends on bug 18373, which changed state.

Bug 18373 Summary: [meta-bug] VRP Value Range Propagation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18373

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/21086] VRP does not extract a value from a comparison expression.

[pinskia at gcc dot gnu dot org]

-- 
Bug 21086 depends on bug 18373, which changed state.

Bug 18373 Summary: [meta-bug] VRP Value Range Propagation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18373

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/21582] (optimisation) VRP pass could/should use non-null function attribute

[pinskia at gcc dot gnu dot org]

-- 
Bug 21582 depends on bug 18373, which changed state.

Bug 18373 Summary: [meta-bug] VRP Value Range Propagation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18373

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/21332] [4.1 Regression] -ftree-vrp makes a loop doesn't execute a body

[pinskia at gcc dot gnu dot org]

-- 
Bug 21332 depends on bug 18373, which changed state.

Bug 18373 Summary: [meta-bug] VRP Value Range Propagation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18373

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/14495] [tree-ssa] Propagate range info into a switch statement

[pinskia at gcc dot gnu dot org]

-- 
Bug 14495 depends on bug 18373, which changed state.

Bug 18373 Summary: [meta-bug] VRP Value Range Propagation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18373

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/21289] A numeric range is spoiled by a symblic one in VRP

[pinskia at gcc dot gnu dot org]

-- 
Bug 21289 depends on bug 18373, which changed state.

Bug 18373 Summary: [meta-bug] VRP Value Range Propagation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18373

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/8681] Generates unneeded test

[pinskia at gcc dot gnu dot org]

-- 
Bug 8681 depends on bug 18373, which changed state.

Bug 18373 Summary: [meta-bug] VRP Value Range Propagation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18373

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/21029] [4.1 Regression] vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances

[pinskia at gcc dot gnu dot org]

-- 
Bug 21029 depends on bug 18373, which changed state.

Bug 18373 Summary: [meta-bug] VRP Value Range Propagation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18373

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/18373] [meta-bug] VRP Value Range Propagation

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-10 
18:09 ---
This has been fixed for 4.1.0.

-- 
   What|Removed |Added

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


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

[Bug tree-optimization/21458] VRP does not remove a conditional in a loop

[pinskia at gcc dot gnu dot org]

-- 
Bug 21458 depends on bug 18373, which changed state.

Bug 18373 Summary: [meta-bug] VRP Value Range Propagation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18373

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/17106] Opportunity to eliminate loads from TOC.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-10 
18:02 ---
This should be helped or fixed by:
http://gcc.gnu.org/wiki/Section%20Anchor%20Optimisations

-- 
   What|Removed |Added

   Last reconfirmed|2005-05-08 18:55:21 |2005-09-10 18:02:38
   date||


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

[Bug tree-optimization/16797] Opportunity to remove unnecessary load instructions

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-10 
17:59 ---
Another testcase which effects all targets:
int logic_func1(int b, int d) {
  if (d< b) return b+3; else return d+3;
}

int logic_func2(int b, int d)
{
  int a;
  if (d< b) a = b; else a = d;
  return a+3;
}

Basicially if we move the +3 to the common code, this would be better  (note in 
the orginal testcase it is 
a cast).

-- 


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

[Bug middle-end/22480] [4.1 Regression] ICE in convert_move, at expr.c:390 with -ftree-vectorize

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-10 
16:32 ---
This causes a build failure if you turn on -ftree-vectorize when building the 
target libraries.

-- 
   What|Removed |Added

   Keywords||build


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

[Bug middle-end/22480] [4.1 Regression] ICE in convert_move, at expr.c:390 with -ftree-vectorize

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-10 
16:31 ---
*** Bug 23808 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||tprince at computer dot org


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

[Bug tree-optimization/23808] ICE in convert-move, building libgfortran with tree-vectorize

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-10 
16:31 ---
This an obvious dup of bug 22480.
The loop in question:
  for (n = 0; n < rank; n++)
mstride[n] <<= 1;

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/23808] ICE in convert-move, building libgfortran with tree-vectorize

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|c   |tree-optimization
   Keywords||build, ice-on-valid-code


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

[Bug c/23808] New: ICE in convert-move, building libgfortran with tree-vectorize

[tprince at computer dot org]

GNU C version 4.1.0 20050909 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.1.0 20050909 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: f9d7f64473108ed4ae233ca41e01773c
GNU assembler version 2.14.90.0.4 (x86_64-redhat-linux) using BFD version 2.14.9
0.0.4 20030523
../../../libgfortran/generated/maxloc0_4_i4.c: In function 'mmaxloc0_4_i4':
../../../libgfortran/generated/maxloc0_4_i4.c:231: internal compiler error: in c
onvert_move, at expr.c:390

-- 
   Summary: ICE in convert-move, building libgfortran with tree-
vectorize
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tprince at computer dot org
CC: gcc-bugs at gcc dot gnu dot org
 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=23808

[Bug libfortran/20179] cannot mix C and Fortran I/O

[fxcoudert at gcc dot gnu dot org]

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-09-10 
16:16 ---
I should add that the code concerned is in io/transfer.c, line 1174:

  /* Overwriting an existing sequential file ?
 it is always safe to truncate the file on the first write */
  if (g.mode == WRITING
  && current_unit->flags.access == ACCESS_SEQUENTIAL
  && current_unit->last_record == 0)
struncate(current_unit->s);

Well, my opinion is that this comment is wrong! :)

-- 


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

[Bug libfortran/20179] cannot mix C and Fortran I/O

[fxcoudert at gcc dot gnu dot org]

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-09-10 
16:06 ---
Looking at that again, it is clear that there is a bug in the way libgfortran
handles pre-connected units. In short, the fd-based I/O library behaves like it
is the first program to access the file; this is not right for pre-connected
units. First example:

$ cat b.c
extern void foo_(void);
int main ()
{
  write (1, "Hello world\n", 13);
  foo_ ();
  return 0;
}
$ cat b.f
  subroutine foo
  write (*,"(A)") "Ciao world!"
  end
$ ./b.out 
Hello world
Fortran runtime error: End of record


$ cat a.sh  
#!/bin/sh
${*} a.f
echo Before
./a.out
echo After
$ cat a.f 
  print *, "foo"
  end
$ ./a.sh ./debug/irun/bin/gfortran -static > foo && cat foo
 foo
After
$ ./a.sh ./debug/irun/bin/gfortran -static 
Before
 foo
After

>From the strace, the problem is quite clear: fd_truncate is called on the fd #1
(stdout), when the unit is opened.

-- 
   What|Removed |Added

   Priority|P3  |P2


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

[Bug c++/23807] Mixed-type arithmetic error

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-10 
15:42 ---
unsigned int res = ~us;

Is equivant to:
unsigned int res = ~(int)us;


-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug debug/23806] [4.0/4.1 Regression] -gstabs with VLAs does not work

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-10 
15:29 ---
Note this causes a build failure while building libiberty/cp-demangle.c on 
targets that default to stabs.

-- 
   What|Removed |Added

 GCC target triplet|x86_64-*-linux-gnu  |
   Keywords||build


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

[Bug debug/23806] [4.0/4.1 Regression] -gstabs with VLAs does not work

[dje at gcc dot gnu dot org]

--- Additional Comments From dje at gcc dot gnu dot org  2005-09-10 15:28 
---
The same ICE causes a bootstrap failure on AIX when compiling
libiberty/cp-demangle.c

cp-demangle.c: In function 'is_ctor_or_dtor':
cp-demangle.c:4127: internal compiler error: in make_decl_rtl, at varasm.c:890


-- 
   What|Removed |Added

 CC||dje at gcc dot gnu dot org


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

[Bug fortran/18899] [gfortran] ubound wrongly calculated for passed array

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-09-10 
14:56 ---
If I replace the declaration of a in foo with, 
 
integer :: a(0:1) 
 
then the test does pass. 
 
So this seems to be a problem with assumed shape arrays. 

-- 


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

[Bug c++/23807] Mixed-type arithmetic error

[igodard at pacbell dot net]

--- Additional Comments From igodard at pacbell dot net  2005-09-10 14:33 
---
Simpler test case:
#include

int main () {
unsigned short us = 0;
unsigned int res = ~us;
std::cerr << "res: 0x" << std::hex << res << ", us: 0x"  << us << "\n";
return 0;
}


gets you:

~/ootbc/members/src$ g++ foo.cc
~/ootbc/members/src$ a.out
res: 0x, us: 0x0



-- 


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

[Bug c++/23807] New: Mixed-type arithmetic error

[igodard at pacbell dot net]

#include

int main () {
unsigned short us = ~0;
unsigned int ui = 1;
unsigned int res = ui + us;
std::cerr << "res: " << res << ", ui: " << ui << ", us: 0x"
<< std::hex << us << "\n";
res = 1;
res = res + us;
std::cerr << "res: " << res << ", ui: " << ui << ", us: 0x"
<< std::hex << us << "\n";
return 0;
}


gets you:

~/ootbc/members/src$ g++ foo.cc
~/ootbc/members/src$ a.out
res: 65536, ui: 1, us: 0x
res: 1, ui: 1, us: 0x


Compiler:
~/ootbc/members/src$ gcc -v
Reading specs from 
/mnt/export/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.0/specs
Configured with: ../gcc/configure --prefix=/site
Thread model: posix
gcc version 3.4.0

Appears to be an optimization error, and non-update (first) version gives
correct result.

-- 
   Summary: Mixed-type arithmetic error
   Product: gcc
   Version: 3.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug tree-optimization/22438] [4.1 Regression] ICE SEGV in is_gimple_variable at tree-gimple.c:239

[belyshev at depni dot sinp dot msu dot ru]

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru  
2005-09-10 13:03 ---
*** Bug 22516 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||falk at debian dot org


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

[Bug tree-optimization/22516] [4.1 Regression] Segfault with ivopts at -O

[belyshev at depni dot sinp dot msu dot ru]

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru  
2005-09-10 13:03 ---
(In reply to comment #3)
> A regression hunt on powerpc-linux shows that the test case starts failing
> with this patch from rakdver:
> 
>   http://gcc.gnu.org/ml/gcc-cvs/2005-07/msg00181.html

so this is a dup of PR 22438

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

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/23799] [4.1 regression] ICE: no-op convert from 8 to 4 bytes in initializer

[schwab at suse dot de]

--- Additional Comments From schwab at suse dot de  2005-09-10 10:19 ---
Also fails on x86-64, according to  
.  All 64-bit 
targets appear to be affected. 

-- 
   What|Removed |Added

 GCC target triplet|ia64-*-*|*64-*-*


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

[Bug middle-end/19430] Missing uninitialized warning

[mike at codeweavers dot com]

--- Additional Comments From mike at codeweavers dot com  2005-09-10 08:07 
---

Simplifying things a bit:

void foo(int*);
void bar(void) { int x; if(x) foo(&x); }

gcc -c foo.c -Wall -O2 -Wuninitialized

(More stunning silence.)


-- 


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

[Bug fortran/22502] [4.0.1 Regression] ICE constructing arrays with "(/ /)"

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2005-09-10 
07:50 ---
Taking care of the backport to the 4.0 branch.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |reichelt at gcc dot gnu dot
   |dot org |org
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2005-
   ||09/msg00646.html
 Status|NEW |ASSIGNED
   Keywords||patch
  Known to fail|4.0.1 4.0.2 4.1.0   |4.0.1 4.0.2
  Known to work|4.0.0   |4.0.0 4.1.0
Summary|[4.0.1/4.1 Regression] ICE  |[4.0.1 Regression] ICE
   |constructing arrays with "(/|constructing arrays with "(/
   |/)" |/)"


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

[Bug debug/23806] [4.0/4.1 Regression] -gstabs with VLAs does not work

[rth at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rth at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-09-10 07:21:19
   date||


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