[Bug libgcj/19688] New: gcc-3.4.3 failed to compile on a Slackware Linux system

[icman at eol dot ca]

PROBLEM:
Compiling gcc 3.4.3 fails miserably.  I am not a sophisticated developer, just a
power user.  The most I can do when a package doesn't compile is make some minor
changes to header files or install the missing libraries.  I read your
bug-report instructions, and the giberish about preprocessor files and
re-compiling with --save-temps is to me exactly that... giberish.  If you need
more information than I have provided, send me the commands to run, and I will
happily gather the information for you.

COMMANDS USED:

mkdir gcc-build
../gcc-3.4.3/configure
make

LAST BIT OF OUTPUT (last compiler action):

/home/shane/Downloads/Unix/gcc-build/gcc/xgcc -shared-libgcc
-B/home/shane/Downloads/Unix/gcc-build/gcc/ -nostdinc++
-L/home/shane/Downloads/Unix/gcc-build/i686-pc-linux-gnu/libstdc++-v3/src
-L/home/shane/Downloads/Unix/gcc-build/i686-pc-linux-gnu/libstdc++-v3/src/.libs
-B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem
/usr/local/i686-pc-linux-gnu/include -isystem
/usr/local/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
-I../../../gcc-3.4.3/libjava -I./include -I./gcj -I../../../gcc-3.4.3/libjava
-Iinclude -I../../../gcc-3.4.3/libjava/include
-I/home/shane/Downloads/Unix/gcc-3.4.3/boehm-gc/include
-DGC_LINUX_THREADS=1 -D_REENTRANT=1 -DTHREAD_LOCAL_ALLOC=1 -DSILENT=1
-DNO_SIGNALS=1 -DALL_INTERIOR_POINTERS=1 -DJAVA_FINALIZATION=1
-DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1 -I../../../gcc-3.4.3/libjava/libltdl
-I../../../gcc-3.4.3/libjava/libltdl
-I../../../gcc-3.4.3/libjava/.././libjava/../gcc
-I../../../gcc-3.4.3/libjava/../zlib
-I../../../gcc-3.4.3/libjava/../libffi/include -I../libffi/include -O2 -g -O2
-fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum
-ffloat-store -W -Wall -D_GNU_SOURCE -DPREFIX=\"/usr/local\"
-DLIBDIR=\"/usr/local/lib\"
-DBOOT_CLASS_PATH=\"/usr/local/share/java/libgcj-3.4.3.jar\" -g -O2
-D_GNU_SOURCE -Wp,-MD,.deps/verify.pp -c ../../../gcc-3.4.3/libjava/verify.cc 
-fPIC -DPIC -o .libs/verify.o

FAILURE GENERATES:

../../../gcc-3.4.3/libjava/verify.cc:45: warning: unused parameter 'fmt'
xgcc: Internal error: Terminated (program cc1plus)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html> for instructions.
make[2]: *** [verify.lo] Error 1
make[2]: Leaving directory
`/home/shane/Downloads/Unix/gcc-build/i686-pc-linux-gnu/libjava'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/home/shane/Downloads/Unix/gcc-build/i686-pc-linux-gnu/libjava'
make: *** [all-target-libjava] Error 2

ENVIRONMENT:

gcc -v:

bash-2.05b# gcc -v
Reading specs from /usr/lib/gcc-lib/i386-slackware-linux/3.2.2/specs
Configured with: ../gcc-3.2.2/configure --prefix=/usr --enable-shared
--enable-threads=posix --enable-__cxa_atexit --disable-checking --with-gnu-ld
--verbose --target=i386-slackware-linux --host=i386-slackware-linux
Thread model: posix
gcc version 3.2.2

uname -a:

bash-2.05b# uname -a
Linux tower 2.6.10 #4 Fri Jan 28 16:06:12 EST 2005 i686 unknown

-- 
   Summary: gcc-3.4.3 failed to compile on a Slackware Linux system
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: icman at eol dot ca
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org


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

[Bug rtl-optimization/13300] [3.3/3.4/4.0 regression] Variable incorrectly identified as a biv

[rsandifo at gcc dot gnu dot org]

--- Additional Comments From rsandifo at gcc dot gnu dot org  2005-01-29 
08:30 ---
The purpose of this PR is to trak a bogus assumption in loop.c,
and that assumption is still there.  See the referenced gcc-patches
message.  So although the testcase might be fixed, I think we should
still keep this open.

-- 
   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug middle-end/19689] ICE in store_bit_field, at expmed.c

[aj at gcc dot gnu dot org]

--- Additional Comments From aj at gcc dot gnu dot org  2005-01-29 08:39 
---
Created an attachment (id=8098)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8098&action=view)
Preprocessed source file


-- 


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

[Bug middle-end/19689] ICE in store_bit_field, at expmed.c

[aj at gcc dot gnu dot org]

--- Additional Comments From aj at gcc dot gnu dot org  2005-01-29 08:46 
---
Note this bug has been introduced after 2005-01-25. 

-- 


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

[Bug target/19690] New: ICE with -O3 -march=athlon-xp -mfpmath=sse -mno-80387

[Thomas dot Koenig at online dot de]

This is from a BLAS routine.

gfortran -O3 -g -march=athlon-xp -mfpmath=sse -mno-80387 -c ddot.f
ddot.f: In function 'ddot':
ddot.f:46: error: insn does not satisfy its constraints:
(insn 365 364 366 12 ddot.f:24 (set (reg:DF 21 xmm0 [104])
(mem:DF (plus:SI (reg/f:SI 6 bp)
(const_int -120 [0xff88])) [0 S8 A8])) 64 {*movdf_nointeger}
(nil)
(nil))
ddot.f:46: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:391
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
$ gfortran -v ; gfortran -dumpmachine
Using built-in specs.
Configured with: ../gcc/configure --prefix=/home/ig25 --enable-languages=c,f95
Thread model: posix
gcc version 4.0.0 20050129 (experimental)
i686-pc-linux-gnu
$ cat BLAS/SRC/ddot.f
  double precision function ddot(n,dx,incx,dy,incy)
c
c forms the dot product of two vectors.
c uses unrolled loops for increments equal to one.
c jack dongarra, linpack, 3/11/78.
c modified 12/3/93, array(1) declarations changed to array(*)
c
  double precision dx(*),dy(*),dtemp
  integer i,incx,incy,ix,iy,m,mp1,n
c
  ddot = 0.0d0
  dtemp = 0.0d0
  if(n.le.0)return
  if(incx.eq.1.and.incy.eq.1)go to 20
c
ccode for unequal increments or equal increments
c  not equal to 1
c
  ix = 1
  iy = 1
  if(incx.lt.0)ix = (-n+1)*incx + 1
  if(incy.lt.0)iy = (-n+1)*incy + 1
  do 10 i = 1,n
dtemp = dtemp + dx(ix)*dy(iy)
ix = ix + incx
iy = iy + incy
   10 continue
  ddot = dtemp
  return
c
ccode for both increments equal to 1
c
c
cclean-up loop
c
   20 m = mod(n,5)
  if( m .eq. 0 ) go to 40
  do 30 i = 1,m
dtemp = dtemp + dx(i)*dy(i)
   30 continue
  if( n .lt. 5 ) go to 60
   40 mp1 = m + 1
  do 50 i = mp1,n,5
dtemp = dtemp + dx(i)*dy(i) + dx(i + 1)*dy(i + 1) +
 *   dx(i + 2)*dy(i + 2) + dx(i + 3)*dy(i + 3) + dx(i + 4)*dy(i + 4)
   50 continue
   60 ddot = dtemp
  return
  end

Line 46 is the '50 continue' line.

Thomas

-- 
   Summary: ICE with -O3 -march=athlon-xp -mfpmath=sse -mno-80387
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu


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

[Bug target/19690] ICE with -O3 -march=athlon-xp -mfpmath=sse -mno-80387

[Thomas dot Koenig at online dot de]

-- 
   What|Removed |Added

   Keywords||ice-on-valid-code


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

[Bug middle-end/19689] [4.0 Regression] ICE in store_bit_field, at expmed.c

[belyshev at depni dot sinp dot msu dot ru]

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru  
2005-01-29 09:28 ---
// reduced testcase, compile with '-O1':

struct
{
  int b : 29;
} f;

void foo (short j)
{
  f.b = j;
}


-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  GCC build triplet|*   |
   GCC host triplet|*   |
 GCC target triplet|*   |
   Keywords||ice-on-valid-code
  Known to fail||4.0.0
  Known to work||3.4.4
   Last reconfirmed|-00-00 00:00:00 |2005-01-29 09:28:35
   date||
Summary|ICE in store_bit_field, at  |[4.0 Regression] ICE in
   |expmed.c|store_bit_field, at expmed.c
   Target Milestone|--- |4.0.0


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

[Bug c/19685] [3.3 Regression] ICE in verify_local_live_at_start, at flow.c:574

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-01-29 
11:15 ---
Confirmed, but on i686 only.

-- 
   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
   Severity|critical|normal
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  GCC build triplet|i486-linux-gcc  |i686-*-*
   GCC host triplet|i486-linux-gcc  |i686-*-*
 GCC target triplet|i486-linux-gcc  |i686-*-*
  Known to fail||3.0.4 3.1.1 3.2.3 3.3.5
   ||3.3.6
  Known to work||2.95.3 2.96 3.4.4 4.0.0
   Last reconfirmed|-00-00 00:00:00 |2005-01-29 11:15:29
   date||
Summary|ICE, in |[3.3 Regression] ICE in
   |verify_local_live_at_start, |verify_local_live_at_start,
   |at flow.c:574   |at flow.c:574
   Target Milestone|--- |3.3.6


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

[Bug fortran/19691] New: gfortran reports "Internal Error: printf is broken"

[billingd at gcc dot gnu dot org]

The following case is reduced from a LAPACK testsuite failure on i686-pc-
cygwin with gfortran 20050129.  The equivalence is just a way to capture the 
floating point value that triggers the error.  Not sure yet if this a gfortran 
bug or a cygwin libc problem.

Test case is

  real r
  integer i
  equivalence (r,i)
  i = 2139095040
  write(6,*) 'r = ', r
  end

g77 gives: 
 r =   Inf

gfortran gives:
At line 5 of file printf_bug.f
Internal Error: printf is broken
 r =

-- 
   Summary: gfortran reports "Internal Error: printf is broken"
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: billingd at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin


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

[Bug middle-end/19689] [4.0 Regression] ICE in store_bit_field, at expmed.c

[belyshev at depni dot sinp dot msu dot ru]

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru  
2005-01-29 12:03 ---
Caused by this patch:

2005-01-26  Richard Henderson  <[EMAIL PROTECTED]>

PR middle-end/18008
* c-decl.c (finish_struct): Set DECL_MODE after resetting a
field's type.
* expr.c (store_field): Strip conversions to odd-bit-sized types
if the destination field width matches.


-- 
   What|Removed |Added

 CC||rth at gcc dot gnu dot org


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

[Bug middle-end/19689] [4.0 Regression] ICE in store_bit_field, at expmed.c

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-01-29 
12:34 ---
#1  0x00645c3a in store_bit_field (str_rtx=0x2a9598d7e0, bitsize=29, 
bitnum=0, 
fieldmode=VOIDmode, value=0x2a9598d6c0) at expmed.c:731 
731 gcc_assert (CONSTANT_P (value)); 
(gdb) l 
726   else 
727 /* Parse phase is supposed to make VALUE's data type 
728match that of the component reference, which is a type 
729at least as wide as the field; so VALUE should have 
730a mode that corresponds to that type.  */ 
731 gcc_assert (CONSTANT_P (value)); 
732 } 
733 
734   /* If this machine's insv insists on a register, 
735  get VALUE1 into a register.  */ 
(gdb) p debug_rtx(value) 
(reg/v:HI 58 [ j ]) 
$1 = void 
(gdb) bt 
#0  fancy_abort (file=0xa73574 "../../mainline/gcc/expmed.c", line=731, 
function=0xa73590 "store_bit_field") at diagnostic.c:556 
#1  0x00645c3a in store_bit_field (str_rtx=0x2a9598d7e0, bitsize=29, 
bitnum=0, 
fieldmode=VOIDmode, value=0x2a9598d6c0) at expmed.c:731 
#2  0x00645a16 in store_bit_field (str_rtx=0x2a9598d7a0, bitsize=29, 
bitnum=0, 
fieldmode=VOIDmode, value=0x2a9598d6c0) at expmed.c:667 
#3  0x0065fc01 in store_field (target=0x2a9598d7a0, bitsize=29, 
bitpos=0, mode=VOIDmode, 
exp=0x2a95988c30, type=0x2a959888f0, alias_set=0) at expr.c:5270 
#4  0x0065a23f in expand_assignment (to=0x2a95895870, 
from=0x2a95a31000) at expr.c:3876 
#5  0x006755e2 in expand_expr_real_1 (exp=0x2a958958c0, target=0x0, 
tmode=VOIDmode, 
modifier=EXPAND_NORMAL, alt_rtl=0x0) at expr.c:8120 
#6  0x00664d4a in expand_expr_real (exp=0x2a958958c0, 
target=0x2a95894400, tmode=VOIDmode, 
modifier=EXPAND_NORMAL, alt_rtl=0x0) at expr.c:6336 
#7  0x008aaff1 in expand_expr (exp=0x2a958958c0, target=0x2a95894400, 
mode=VOIDmode, 
modifier=EXPAND_NORMAL) at expr.h:482 
#8  0x008a3d79 in expand_expr_stmt (exp=0x2a958958c0) at stmt.c:1326 
 
The statement we choque on is "fD.1449.bD.1447 = () jD.1450;" 
 
The final_cleanup dumps looks like this: 
 
;; Function foo (foo) 
 
foo (jD.1450) 
{ 
  # BLOCK 0 
  # PRED: ENTRY [100.0%]  (fallthru,exec) 
  #   fD.1449_4 = V_MAY_DEF ; 
  fD.1449.bD.1447 = () jD.1450; 
  return; 
  # SUCC: EXIT [100.0%] 
 
} 
 
(note btw that the virtual operands are still renamed, which is also 
a but really... :-/) 
 
The patch that introduced this bug is this one: 
http://gcc.gnu.org/ml/gcc-cvs/2005-01/msg01091.html 
 

-- 


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

[Bug fortran/19691] gfortran reports "Internal Error: printf is broken"

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
12:40 ---
Cygwin's printf is broken on powerpc-darwin I get:
 r =   +Infinity


This is a dup of bug 19363 anyways.

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug libfortran/19363] List directed write of Infinity and NaN has regressed

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
12:40 ---
*** Bug 19691 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||billingd at gcc dot gnu dot
   ||org


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

[Bug target/19686] avr-gcc 4.0: loop performance decrease (extra conversion)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
12:45 ---
There is a conversion to unsigned int:
(ivtmp.2 != (unsigned int) (x - 1) * 65535 + 65535)

but isn't that free?

-- 


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

[Bug middle-end/19687] [4.0 Regression] ICE with union initializer

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
12:46 ---
Confirmed, here is the backtrace:
#0  categorize_ctor_elements_1 (ctor=0x41587320, p_nz_elts=0xbfffea10, 
p_nc_elts=0xbfffea18, 
p_elt_count=0xbfffea20, p_must_clear=0xbfffea08 "") at 
/Users/pinskia/src/local3/gcc/gcc/expr.c:
4373
#1  0x00137738 in mostly_zeros_p (exp=0x41587320) at 
/Users/pinskia/src/local3/gcc/gcc/expr.c:
4500
#2  0x00137738 in mostly_zeros_p (exp=0x41587320) at 
/Users/pinskia/src/local3/gcc/gcc/expr.c:
4500
#3  0x0013aed4 in expand_expr_real_1 (exp=0x0, target=0x41588040, 
tmode=VOIDmode, 
modifier=3221219848, alt_rtl=0x0) at 
/Users/pinskia/src/local3/gcc/gcc/expr.c:6731
#4  0x0013d2e4 in expand_expr_real (exp=0x41587320, target=0x31, tmode=BLKmode, 
modifier=EXPAND_NORMAL, alt_rtl=0x0) at 
/Users/pinskia/src/local3/gcc/gcc/expr.c:6342
#5  0x00141974 in store_expr (exp=0x41587320, target=0x1, call_param_p=49) at 
/Users/pinskia/
src/local3/gcc/gcc/expr.c:4105
#6  0x001430a8 in expand_assignment (to=0x4150a400, from=0x1) at 
/Users/pinskia/src/local3/
gcc/gcc/expr.c:3984
#7  0x00139698 in expand_expr_real_1 (exp=0x41583510, target=0x4150a400, 
tmode=VOIDmode, 
modifier=EXPAND_NORMAL, alt_rtl=0x0) at 
/Users/pinskia/src/local3/gcc/gcc/expr.c:8120
#8  0x0013d1e0 in expand_expr_real (exp=0x41587320, target=0x33, 
tmode=1096293376, 
modifier=1095866624, alt_rtl=0x0) at 
/Users/pinskia/src/local3/gcc/gcc/expr.c:6336
#9  0x0025ba40 in expand_expr_stmt (exp=0x33) at 
/Users/pinskia/src/local3/gcc/gcc/expr.h:482
#10 0x00287038 in tree_expand_cfg () at 
/Users/pinskia/src/local3/gcc/gcc/cfgexpand.c:1133


-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
 GCC target triplet|i386-pc-linux-gnu   |
   Last reconfirmed|-00-00 00:00:00 |2005-01-29 12:46:39
   date||
   Target Milestone|--- |4.0.0


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

[Bug middle-end/19689] [4.0 Regression] ICE in store_bit_field, at expmed.c

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-01-29 
12:49 ---
rth's comment on the patch: 
5220  /* If EXP is a NOP_EXPR of precision less than its mode, then 
that 
5221 implies a mask operation.  If the precision is the same size 
as 
5222 the field we're storing into, that mask is redundant.  This 
is 
5223 particularly common with bit field assignments generated by 
the 
5224 C front end.  */ 
5225  if (TREE_CODE (exp) == NOP_EXPR 
5226  && INTEGRAL_TYPE_P (TREE_TYPE (exp)) 
5227  && (TYPE_PRECISION (TREE_TYPE (exp)) 
5228  < GET_MODE_BITSIZE (TYPE_MODE (TREE_TYPE (exp 
5229  && bitsize == TYPE_PRECISION (TREE_TYPE (exp))) 
 
But in this case the NOP_EXPR also changes the mode of its operand from 
HImode to SImode: 
(gdb) p debug_tree(exp) 
  
unit size  
align 32 symtab 0 alias set -1 precision 29 min  max > 
 
arg 0  
unit size  
align 16 symtab 0 alias set -1 precision 16 min  max  
pointer_to_this > 
used HI file t.c line 8 size  unit size 
 
align 16 context  result  initial  
(reg/v:HI 58 [ j ]) 
arg-type  unit size  
align 32 symtab 0 alias set -1 precision 32 min  max  
pointer_to_this > arg-type-as-written 
 
incoming-rtl (reg:SI 5 di [ j ])>> 
 

-- 


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

[Bug other/19688] gcc-3.4.3 failed to compile on a Slackware Linux system

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
12:50 ---
xgcc: Internal error: Terminated (program cc1plus)
That means you ran out of memory while compiling.
Do you have swap enabled?

Also you should using "make bootstrap" and not just make as the directions in 
http://gcc.gnu.org/
install/ say to.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |WAITING
  Component|libgcj  |other


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

[Bug middle-end/19689] [4.0 Regression] ICE in store_bit_field, at expmed.c

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-01-29 
12:54 ---
Something like this?? 
Index: expr.c 
=== 
RCS file: /cvs/gcc/gcc/gcc/expr.c,v 
retrieving revision 1.776 
diff -u -3 -p -r1.776 expr.c 
--- expr.c  27 Jan 2005 00:07:41 -  1.776 
+++ expr.c  29 Jan 2005 12:54:25 - 
@@ -5224,6 +5224,8 @@ store_field (rtx target, HOST_WIDE_INT b 
 C front end.  */ 
   if (TREE_CODE (exp) == NOP_EXPR 
  && INTEGRAL_TYPE_P (TREE_TYPE (exp)) 
+ && (TYPE_MODE (TREE_TYPE (exp)) 
+ == TYPE_MODE (TREE_TYPE (TREE_OPERAND (exp, 0 
  && (TYPE_PRECISION (TREE_TYPE (exp)) 
  < GET_MODE_BITSIZE (TYPE_MODE (TREE_TYPE (exp 
  && bitsize == TYPE_PRECISION (TREE_TYPE (exp))) 
 

-- 


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

[Bug target/19664] -fvisibility-inlines-hidden fails with gcc's extern template extension on amd64

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
13:05 ---
(In reply to comment #5)
> It is a compiler bug. VisTest::VisTest() is never defined.
> R_X86_64_PC32 relocation may not reach it at runtime when it is
> called. The new linker catches this particular bug at linktime.

Actually this is not a gcc or a linker bug but a programmers.
Basically -fvisibility=hidden -fvisibility-inlines-hidden says all I repeat all 
functions (defined or not) as 
hidden.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/19690] ICE with -O3 -march=athlon-xp -mfpmath=sse -mno-80387

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||rth at gcc dot gnu dot org
   Keywords||ssemmx


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

[Bug target/19690] ICE with -O3 -march=athlon-xp -mfpmath=sse -mno-80387

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
13:14 ---
I should note (I think others have to before) that -mno-80387 
***changes* the ABI.

-- 


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

[Bug tree-optimization/19333] [4.0 Regression] C front end accepts arrays of incomplete types

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-01-29 
13:20 ---
Lemme take this one... 

-- 
   What|Removed |Added

 AssignedTo|rakdver at gcc dot gnu dot  |steven at gcc dot gnu dot
   |org |org
   Severity|critical|normal
Summary|[4.0 Regression] Compilation|[4.0 Regression] C front end
   |SEGFAULTs with -O1 -finline-|accepts arrays of incomplete
   |functions on the x86_64 |types
   |architecture.   |


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

[Bug bootstrap/19692] New: Internal error during gcc 3.3.5 bootstrap (Alpha)

[pascal at quies dot net]

alphaev56-unknown-linux-gnu
building gcc 3.3.5 with gcc 3.3.4:

# cd gcc-build
# ../gcc-3.3.5/configure --prefix=/usr \
--libexecdir=/usr/lib \
--with-local-prefix=/usr \
--enable-shared \
--disable-multilib \
--enable-threads=posix \
--with-cpu=21164a \
--enable-__cxa_atexit \
--enable-languages=c,c++ \
--disable-nls \
--with-system-zlib
[...]
# make bootstrap
[...]
/usr/src/gcc-build/gcc/xgcc -shared-libgcc -B/usr/src/gcc-build/gcc/ -nostdinc++
-L/usr/src/gcc-build/alphaev56-unknown-linux-gnu/libstdc++-v3/src
-L/usr/src/gcc-build/alphaev56-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/usr/alphaev56-unknown-linux-gnu/bin/ -B/usr/alphaev56-unknown-linux-gnu/lib/
-isystem /usr/alphaev56-unknown-linux-gnu/include -nostdinc++
-I/usr/src/gcc-build/alphaev56-unknown-linux-gnu/libstdc++-v3/include/alphaev56-unknown-linux-gnu
-I/usr/src/gcc-build/alphaev56-unknown-linux-gnu/libstdc++-v3/include
-I../../../../gcc-3.3.5/libstdc++-v3/libsupc++
-I../../../../gcc-3.3.5/libstdc++-v3/libmath -g -O2 -D_GNU_SOURCE -mieee
-fno-implicit-templates -Wall -Wno-format -W -Wwrite-strings
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections -c
../../../../gcc-3.3.5/libstdc++-v3/src/fstream-inst.cc  -fPIC -DPIC -o
.libs/fstream-inst.o
xgcc: Internal error: Killed (program cc1plus)
Please submit a full bug report.

-- 
   Summary: Internal error during gcc 3.3.5 bootstrap (Alpha)
   Product: gcc
   Version: 3.3.5
Status: UNCONFIRMED
  Severity: critical
  Priority: P1
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pascal at quies dot net
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug tree-optimization/19333] [4.0 Regression] C front end accepts arrays of incomplete types

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
13:23 ---
*** Bug 19390 has been marked as a duplicate of this bug. ***

-- 
Bug 19333 depends on bug 19390, which changed state.

Bug 19390 Summary: Accepts invalid code (well I don't know if it is invalid or 
not but I think it should be)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19390

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

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

[Bug c/19390] Accepts invalid code (well I don't know if it is invalid or not but I think it should be)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
13:23 ---


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

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug bootstrap/19692] Internal error during gcc 3.3.5 bootstrap (Alpha)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
13:24 ---
xgcc: Internal error: Killed (program cc1plus)

This means that the amount of memory used was too much for your machine.

How much memory/swap do you have?

-- 
   What|Removed |Added

   Severity|critical|minor
 Status|UNCONFIRMED |WAITING


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

[Bug c/19333] [4.0 Regression] C front end accepts arrays of incomplete types

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
13:25 ---
Simple testcase now:
extern short int aa[][];

-- 
   What|Removed |Added

  Component|tree-optimization   |c
   Keywords||accepts-invalid


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

[Bug c++/13384] error: non-lvalue in assignment - message a little misleading for C++

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
13:32 ---
But note C++ has a definition of lvalue and rvalues so the message is still 
correct in the C++ sense.

-- 
   What|Removed |Added

   Last reconfirmed|2004-06-13 09:42:53 |2005-01-29 13:32:04
   date||


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

[Bug c++/14748] Unhelpful error message about use of invalid field name __ct

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
13:37 ---
Fixed by accepting it in 4.0.0.  What changed was the name of the constructor 
internally was renamed 
to " __ct".

-- 
   What|Removed |Added

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


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

[Bug target/14973] ICE with -maltivec for vector types not matching HW types

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
13:39 ---
Fixed, most likely for a while now.

-- 
   What|Removed |Added

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


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

[Bug c++/15759] ICE with function pointers

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
13:43 ---
Note the following is make sure that we create correct code:
extern "C" void exit (int);
extern "C" void abort();
int defValue() { exit(0);return(0); }
int(*defaultValue)() = defValue;
void a(int blah = defaultValue()) {}
int main() { a(); abort (); }

And with checking not enabled we get the correct code (which I find werid but 
hey).

-- 
   What|Removed |Added

   Keywords||ice-checking


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

[Bug fortran/19693] New: optimization problem with LAPACK routine cgtts2.f

[billingd at gcc dot gnu dot org]

With gfortran 20050129 I get a testsuite failure at -O2 that I don't see at -
O0.  The failure is in the CGT tests in ctest.in:

 CGT:  General tridiagonal
 Matrix types (1-6 have specified condition numbers):
1. Diagonal7. Random, unspecified CNDNUM
2. Random, CNDNUM = 2  8. First column zero
3. Random, CNDNUM = sqrt(0.1/EPS)  9. Last column zero
4. Random, CNDNUM = 0.1/EPS   10. Last n/2 columns zero
5. Scaled near underflow  11. Scaled near underflow
6. Scaled near overflow   12. Scaled near overflow
 Test ratios:
1: norm( L * U - A )  / ( N * norm(A) * EPS )
2: norm( B - A * X )  / ( norm(A) * norm(X) * EPS )
3: norm( X - XACT )   / ( norm(XACT) * CNDNUM * EPS )
4: norm( X - XACT )   / ( norm(XACT) * CNDNUM * EPS ), refined
5: norm( X - XACT )   / ( norm(XACT) * (error bound) )
6: (backward error)   / EPS
7: RCOND * CNDNUM - 1.0
 Messages:
 NORM ='O', N =1,   type  5, test( 7) =  0.16777E+08
 NORM ='I', N =1,   type  5, test( 7) =  0.16777E+08
 TRANS='N', N =1, NRHS=  1, type  5, test( 3) = 

I have reduced it to the miscompilation of routine cgtts2.f at -O2.  I have 
isolated a single failing case, but if I try to change the routine the problem 
evaporates.

Attached is:
 - driv.f: a small driver program
 - cgtts2.f: the LAPACK routine with the problem.

To reproduce:

gfortran -o pass.exe -O0 driv.f cgtts2.f
gfortran -o fail.exe -O0 driv.f cgtts2.f
./pass
 B(1,1) =  ( 4.0564819E+31,  0.00)

./fail
At line 15 of file driv.f
Internal Error: printf is broken
 B(1,1) =  (

Note:  The internal error is PR 19363

-- 
   Summary: optimization problem with LAPACK routine cgtts2.f
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: billingd at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin


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

[Bug fortran/19693] optimization problem with LAPACK routine cgtts2.f

[billingd at gcc dot gnu dot org]

--- Additional Comments From billingd at gcc dot gnu dot org  2005-01-29 
13:51 ---
Created an attachment (id=8099)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8099&action=view)
driv.f: test driver

driv.f is driver routine

-- 


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

[Bug fortran/19693] optimization problem with LAPACK routine cgtts2.f

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||wrong-code


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

[Bug fortran/19693] optimization problem with LAPACK routine cgtts2.f

[billingd at gcc dot gnu dot org]

--- Additional Comments From billingd at gcc dot gnu dot org  2005-01-29 
13:52 ---
Created an attachment (id=8100)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8100&action=view)
cgtts2.f is LAPACK routine that is miscompiled

cgtts2.f is LAPACK routine that is miscompiled

-- 


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

[Bug fortran/19693] optimization problem with LAPACK routine cgtts2.f

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
13:55 ---
At -O0 on powerpc-darwin I get:
 B(1,1) =  ( +Infinity,   NaN)



-- 


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

[Bug target/19300] [4.0 Regression] PCH failures on sparc-linux

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
14:01 ---
Even though this is a user visible regression.  This is not a regression as it 
was just by chance that this 
worked in the first place:
.

Removing the target milestone because sparc-linux is not a primary or secondary 
target and this was 
only working by chance before

-- 
   What|Removed |Added

   Target Milestone|4.0.0   |---


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

[Bug target/19664] -fvisibility-inlines-hidden fails with gcc's extern template extension on amd64

[andreas dot pokorny at gmx dot de]

--- Additional Comments From andreas dot pokorny at gmx dot de  2005-01-29 
15:08 ---
If it is a programmers bug, why does it happen only with amd64, but not with
ia32 or ia64?

>  Actually this is not a gcc or a linker bug but a programmers.
>  Basically -fvisibility=hidden -fvisibility-inlines-hidden says all I repeat
all functions (defined or not) 
>  as hidden.

This does not explain why gcc should fail to create the library. In my opinion
the programmer isnt the one to blame, he declared a strucutre, which should not
be exported to the library, and a function that should be exported. Within his
library he uses that structure, whats wrong about that? 

-- 


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

[Bug target/19664] -fvisibility-inlines-hidden fails with gcc's extern template extension on amd64

[andreas dot pokorny at gmx dot de]

--- Additional Comments From andreas dot pokorny at gmx dot de  2005-01-29 
15:26 ---
I am also refereing to this example: 
http://gcc.gnu.org/ml/libstdc++/2005-01/msg00300.html


-- 


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

[Bug bootstrap/19692] Internal error during gcc 3.3.5 bootstrap (Alpha)

[pascal at quies dot net]

--- Additional Comments From pascal at quies dot net  2005-01-29 15:28 
---
(In reply to comment #1)
> How much memory/swap do you have?
64MB/48MB

A upgrade to 128MB swap solved the problem.

Thank you very much for the quick responce and the correct answer :)

-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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

[Bug target/19664] -fvisibility-inlines-hidden fails with gcc's extern template extension on amd64

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
15:28 ---
(In reply to comment #8)
> I am also refereing to this example: 
> http://gcc.gnu.org/ml/libstdc++/2005-01/msg00300.html

Now there is a libstdc++ bug for not using pop/push of the visibility in the 
headers which is not what I 
orginally thought this bug was about.

-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
15:32 ---
(In reply to comment #9)
> (In reply to comment #8)
> > I am also refereing to this example: 
> > http://gcc.gnu.org/ml/libstdc++/2005-01/msg00300.html
> 
> Now there is a libstdc++ bug for not using pop/push of the visibility in the 
> headers which is not what 
> I orginally thought this bug was about.

If you actually commented saying that this came from libstdc++ and then I would 
have commented 
saying that there needs some push/pop in the headers but instead you gave a 
simplified example which 
is not a gcc/linker bug but a programmers mistake.

Confirmed, changing the summary to match the correct the sumbitter's mistake of 
not giving the full 
story.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|target  |libstdc++
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-01-29 15:32:29
   date||
Summary|-fvisibility-inlines-hidden |libstdc++ headers should
   |fails with gcc's extern |have pop/push of the
   |template extension on amd64 |visibility around the
   ||declarations


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

[Bug fortran/19589] Regression: Error on Data assignment with LOGICAL*1

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-29 
15:36 ---
Subject: Bug 19589

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-01-29 15:35:51

Modified files:
gcc/fortran: ChangeLog expr.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gfortran.dg: logical_data_1.f90 

Log message:
2005-01-29  Steven G. Kargl  <[EMAIL PROTECTED]>

PR fortran/19589
* expr.c (gfc_check_assign):  Check for conformance of logical operands
testsuite/
* gfortran.dg/logical_data_1.f90: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.314&r2=1.315
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/expr.c.diff?cvsroot=gcc&r1=1.19&r2=1.20
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4953&r2=1.4954
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/logical_data_1.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
15:37 ---
Note the orginal testcase is:
#include  
int some_function( std::string const& do_something ) __attribute__ 
((visibility("default")));

int some_function( std::string const& do_something ) 
{
  std::string another_string;
  return 0;
}


-- 


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

[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran

[pinskia at gcc dot gnu dot org]

-- 
Bug 19292 depends on bug 19589, which changed state.

Bug 19589 Summary: Regression: Error on Data assignment with LOGICAL*1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19589

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug libfortran/19595] eor does not work

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-29 
15:45 ---
Subject: Bug 19595

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-01-29 15:45:17

Modified files:
gcc/testsuite  : ChangeLog 
libgfortran: ChangeLog 
libgfortran/io : transfer.c 
Added files:
gcc/testsuite/gfortran.dg: eor_1.f90 

Log message:
2005-01-29  Thomas Koenig  <[EMAIL PROTECTED]>

PR libfortran/19595
* io/transfer.c (data_transfer_init): eor requires advance="NO".
testsuite/
* gfortran.dg/eor_1.f90:  New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4954&r2=1.4955
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/eor_1.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.154&r2=1.155
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/transfer.c.diff?cvsroot=gcc&r1=1.30&r2=1.31



-- 


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

[Bug fortran/19589] Regression: Error on Data assignment with LOGICAL*1

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
15:39 ---
Fixed.

-- 
   What|Removed |Added

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


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

[Bug libfortran/19595] eor does not work

[pbrook at gcc dot gnu dot org]

--- Additional Comments From pbrook at gcc dot gnu dot org  2005-01-29 
15:46 ---
Fixed.

-- 
   What|Removed |Added

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


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

[Bug libfortran/19595] eor does not work

[pbrook at gcc dot gnu dot org]

--- Additional Comments From pbrook at gcc dot gnu dot org  2005-01-29 
15:47 ---
Whoops, maybe not fixed.

-- 
   What|Removed |Added

   Last reconfirmed|2005-01-26 21:48:45 |2005-01-29 15:47:00
   date||


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

[Bug libfortran/19595] eor does not work

[pbrook at gcc dot gnu dot org]

--- Additional Comments From pbrook at gcc dot gnu dot org  2005-01-29 
15:47 ---
.

-- 
   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug c/19694] New: Warning about mismatched function declaration is now error

[eliz at gnu dot org]

Consider the following source file:

static int
foo (arg1, arg2)
 void *arg1, *arg2;
{
  bar (arg1, arg2);
  return 0;
}

void
bar (arg1, arg2)
 void *arg1, *arg2;
{
  callme (arg1, arg2);
}

If I compile it with GCC 3.3.3 or earlier, I get a warning:

 tfwd.c:11: warning: type mismatch with previous implicit declaration
 tfwd.c:5: warning: previous implicit declaration of `bar'
 tfwd.c:11: warning: `bar' was previously implicitly declared to return `int'

But if I compile with 3.4.3, I get an error:

 tfwd.c:11: error: conflicting types for 'bar'
 tfwd.c:5: error: previous implicit declaration of 'bar' was here

I think this is a bug: GCC should not emit diagnostics for this code, certainly 
not flag it as an error, except perhaps under -ansi -pedantic.  There's nothing 
wrong with having a function defined after it is used; GCC should not force me 
write bottom-up code, nor add gratuitous prototypes for functions defined in 
the same source file where they are used.

-- 
   Summary: Warning about mismatched function declaration is now
error
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eliz at gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i386-msdos-djgpp
  GCC host triplet: i386-msdos-djgpp
GCC target triplet: i386-msdos-djgpp


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

[Bug c/19694] [3.4 Regression] Warning about mismatched function declaration is now error

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
16:23 ---
Confirmed, only a 3.4 regression, it works on the mainline (we get warnings and 
not errors).

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||rejects-valid
  Known to fail||3.4.3
  Known to work||4.0.0 3.3.3
   Last reconfirmed|-00-00 00:00:00 |2005-01-29 16:23:01
   date||
Summary|Warning about mismatched|[3.4 Regression] Warning
   |function declaration is now |about mismatched function
   |error   |declaration is now error
   Target Milestone|--- |3.4.4


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

[Bug target/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[andreas dot pokorny at gmx dot de]

--- Additional Comments From andreas dot pokorny at gmx dot de  2005-01-29 
16:24 ---
I am sorry, in my attempt to reduce the exmaple I introduced a bug in the 
testcase. 

-- 
   What|Removed |Added

  Component|libstdc++   |target


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
16:26 ---
(In reply to comment #12)
> I am sorry, in my attempt to reduce the exmaple I introduced a bug in the 
> testcase. 
Yes and this is not a target related bug at all but a libstdc++ one.

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
  Component|target  |libstdc++


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

[Bug c/18166] top const stripped in structs for C

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-01-29 16:31 
---
My patch 
should cause fields to be given the correct types within the C front
end, and might thereby fix this bug.


-- 


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

[Bug middle-end/19695] New: [4.0 Regression] gcc.c-torture/execute/builtins/strlen-3.c:20: ICE: verify_flow_sensitive_alias_info failed

[danglin at gcc dot gnu dot org]

Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/xgcc -B/mnt/gnu/gcc-3.3/objdir/gc
c/ /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/strlen-3.c
/mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/strlen-3-lib.c
 /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c  -
w  -O1   -lm   -o /mnt/gnu/gcc-3.3/objdir/gcc/testsuite/strlen-3.x1(timeout
= 300)
/mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/strlen-3.c: In
 function 'main_test':
/mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/strlen-3.c:20:
 error: Pointers with a memory tag, should have points-to sets or point to mallo
c
foo_28, name memory tag: NMT___6, points-to vars: { }
foo, UID 8, const char *
/mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/strlen-3.c:20:
 internal compiler error: verify_flow_sensitive_alias_info failed.

This regression was introduced between Jan 27 03:49:03 UTC 2005 and
Jan 29 00:52:49 UTC 2005.

-- 
   Summary: [4.0 Regression] gcc.c-torture/execute/builtins/strlen-
3.c:20: ICE: verify_flow_sensitive_alias_info failed
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: hppa*-hp-hpux11.11
  GCC host triplet: hppa*-hp-hpux11.11
GCC target triplet: hppa*-hp-hpux11.11


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

[Bug c++/19628] [3.4/4.0 Regression] g++ no longer accepts __builtin_constant_p in constant-expressions

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
17:31 ---
Patch here: .

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||patch, rejects-valid
   Last reconfirmed|-00-00 00:00:00 |2005-01-29 17:31:57
   date||


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

[Bug middle-end/19695] [4.0 Regression] gcc.c-torture/execute/builtins/strlen-3.c:20: ICE: verify_flow_sensitive_alias_info failed

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
17:33 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/19670] [4.0 regression] testsuite failure: gcc.c-torture/execute/builtins/strlen-3.c compilation, -O1

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
17:33 ---
*** Bug 19695 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||danglin at gcc dot gnu dot
   ||org


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

[Bug c++/19185] ICE: cp_expr_size, at cp/cp-lang.c:308

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
17:35 ---
Confirmed, there is another dup of this bug.  I have seen somewhere 
PCC_STATIC_STRUCT_RETURN 
causes problems with c++ before.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-01-29 17:35:01
   date||
Summary|[3.3 only] ICE: |ICE: cp_expr_size, at cp/cp-
   |cp_expr_size, at cp/cp- |lang.c:308
   |lang.c:308  |
   Target Milestone|3.3.6   |---


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

[Bug c++/19222] [4.0 Regression] ICE: in fold_convert, at fold-const.c:1980

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
17:36 ---
This is a dup of bug 19185 which is exactly the same problem just changed where 
the ICE is.

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

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/19185] ICE: cp_expr_size, at cp/cp-lang.c:308

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
17:36 ---
*** Bug 19222 has been marked as a duplicate of this bug. ***

-- 


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

[Bug c++/19185] [3.3/3.4/4.0 Regression] ICE: cp_expr_size, at cp/cp-lang.c:308

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
17:41 ---
http://gcc.gnu.org/ml/gcc/2001-01/msg01594.html
http://gcc.gnu.org/ml/gcc/2001-01/msg01721.html
http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00817.html
http://gcc.gnu.org/ml/gcc/2001-02/msg00461.html
http://gcc.gnu.org/ml/gcc-patches/2002-12/msg00755.html

This is a regression but not setting the target milestone based on Mark's email.

-- 
   What|Removed |Added

  GCC build triplet|vax-dec-ultrix4.3   |
   GCC host triplet|vax-dec-ultrix4.3   |
Summary|ICE: cp_expr_size, at cp/cp-|[3.3/3.4/4.0 Regression]
   |lang.c:308  |ICE: cp_expr_size, at cp/cp-
   ||lang.c:308


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

[Bug fortran/18565] gfortran: CONJG: false error message about standard violation

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-29 
17:46 ---
Subject: Bug 18565

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-01-29 17:46:35

Modified files:
gcc/fortran: ChangeLog check.c intrinsic.c intrinsic.h 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gfortran.dg: double_complex_1.f90 

Log message:
2005-01-29  Paul Brook  <[EMAIL PROTECTED]>

PR fortran/18565
* check.c (real_or_complex_check): New function.
(gfc_check_fn_c, gfc_check_fn_r, gfc_check_fn_rc): New functions.
* intrinsic.c (add_functions): Use new check functions.
* intrinsic.h (gfc_check_fn_c, gfc_check_fn_r, gfc_check_fn_rc):
Add prototypes.
testsuite/
* gfortran.dg/double_complex_1.f90: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.315&r2=1.316
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/check.c.diff?cvsroot=gcc&r1=1.22&r2=1.23
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/intrinsic.c.diff?cvsroot=gcc&r1=1.37&r2=1.38
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/intrinsic.h.diff?cvsroot=gcc&r1=1.20&r2=1.21
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4956&r2=1.4957
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/double_complex_1.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug fortran/18565] gfortran: CONJG: false error message about standard violation

[pbrook at gcc dot gnu dot org]

--- Additional Comments From pbrook at gcc dot gnu dot org  2005-01-29 
17:48 ---
Fixed.

-- 
   What|Removed |Added

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


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

[Bug other/19696] New: gcc.c-torture/execute/ieee/copysign1.c: Unsatisfied symbols: copysignl

[danglin at gcc dot gnu dot org]

PASS: gcc.c-torture/execute/ieee/compare-fp-4.c execution,  -Os
Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/xgcc -B/mnt/gnu/gcc-3.3/objdir/gc
c/ /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.c-torture/execute/ieee/copysign1.c  -w
  -O0   -lm   -o /mnt/gnu/gcc-3.3/objdir/gcc/testsuite/copysign1.x0(timeout
= 300)
/usr/ccs/bin/ld: Unsatisfied symbols:
   copysignl (first referenced in /var/tmp//ccmMQ8Qt.o) (code)
collect2: ld returned 1 exit status

-- 
   Summary: gcc.c-torture/execute/ieee/copysign1.c: Unsatisfied
symbols: copysignl
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: hppa2.0w-hp-hpux11.11
  GCC host triplet: hppa2.0w-hp-hpux11.11
GCC target triplet: hppa2.0w-hp-hpux11.11


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

[Bug other/19696] gcc.c-torture/execute/ieee/copysign1.c: Unsatisfied symbols: copysignl

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
17:51 ---
Confirmed on powerpc-darwin7.7.0 which also does not have fully the C99 math 
functions (well have 
all of them except for the long double form.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  GCC build triplet|hppa2.0w-hp-hpux11.11   |
   GCC host triplet|hppa2.0w-hp-hpux11.11   |
 GCC target triplet|hppa2.0w-hp-hpux11.11   |hppa2.0w-hp-hpux11.11,
   ||powerpc-darwin
   Last reconfirmed|-00-00 00:00:00 |2005-01-29 17:51:01
   date||


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

[Bug middle-end/19697] New: [4.0 Regression] gcc.c-torture/execute/ieee/mzero6.c:24: error: unrecognizable insn

[danglin at gcc dot gnu dot org]

Executing on host: /test/gnu/gcc-3.3/objdir/gcc/xgcc -B/test/gnu/gcc-3.3/objdir/
gcc/ /test/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.c-torture/execute/ieee/mzero6.c  -w
  -O0   -lm   -o /test/gnu/gcc-3.3/objdir/gcc/testsuite/mzero6.x0(timeout =
300)
/test/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.c-torture/execute/ieee/mzero6.c: In func
tion 'main':
/test/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.c-torture/execute/ieee/mzero6.c:24: erro
r: unrecognizable insn:
(insn 18 17 19 1 (set (reg:DI 73)
(and:DI (const_int 9223372036854775807 [0x7fff])
(reg:DI 74))) -1 (nil)
(expr_list:REG_DEAD (reg:DI 74)
(nil)))
/test/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.c-torture/execute/ieee/mzero6.c:24: inte
rnal compiler error: in extract_insn, at recog.c:2020

This regression was introduced between Jan 25 02:13:35 UTC 2005 and Jan 29
00:52:49 UTC 2005.

-- 
   Summary: [4.0 Regression] gcc.c-torture/execute/ieee/mzero6.c:24:
error: unrecognizable insn
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: hppa64-hp-hpux11.11
  GCC host triplet: hppa64-hp-hpux11.11
GCC target triplet: hppa64-hp-hpux11.11


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

[Bug middle-end/19583] [4.0 Regression] Incorrect diagnostic: control may reach end of non-void function '...' being inlined

[larsbj at gullik dot net]

--- Additional Comments From larsbj at gullik dot net  2005-01-29 19:09 
---
This does not seem to be fixed so reopening.

-- 
   What|Removed |Added

 CC||larsbj at gullik dot net


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

[Bug middle-end/19698] New: [4.0 regression] Infinite loop in update_life_info

[schwab at suse dot de]

The attached test causes the compiler to hang in update_life_info (called from 
rest_of_handle_life) while compiling the FFT function with -O2.

-- 
   Summary: [4.0 regression] Infinite loop in update_life_info
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schwab at suse dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: ia64-linux


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

[Bug middle-end/19698] [4.0 regression] Infinite loop in update_life_info

[schwab at suse dot de]

--- Additional Comments From schwab at suse dot de  2005-01-29 19:18 ---
Created an attachment (id=8102)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8102&action=view)
Test case


-- 


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

[Bug target/19530] MMX load intrinsic produces SSE superfluous instructions (movlps)

[guardia at sympatico dot ca]

--- Additional Comments From guardia at sympatico dot ca  2005-01-29 19:21 
---
Hum, ok we can do a "movd %mm0, %eax", that's why it gets combined... 

Well, I give up. The V8QI (and whatever) -> V2SI conversion seems to be causing
all the trouble here if we look at the RTL of something like:
__m64 moo(__v8qi mmx1)
{
   mmx1 = __builtin_ia32_punpcklbw (mmx1, mmx1);
   return mmx1;
}

It explicitly asks for a conversion to V2SI (__m64) that gets assigned to an xmm
register afterwards:
(insn 15 14 17 1 (set (reg:V8QI 58 [ D.2201 ])
(reg:V8QI 62)) -1 (nil)
(nil))

(insn 17 15 18 1 (set (reg:V2SI 63)
(subreg:V2SI (reg:V8QI 58 [ D.2201 ]) 0)) -1 (nil)
(nil))

(insn 18 17 19 1 (set (mem/i:V2SI (reg/f:SI 60 [ D.2206 ]) [0 +0 S8 
A64])
(reg:V2SI 63)) -1 (nil)
(nil))

So... the only way to fix this would be to either make the register allocator
more intelligent (bug 19161), or to provide intrinsics like the Intel compiler
does with one to one mapping to instructions directly. right? That wouldn't be
such a bad idea, I think... instead of using the current __builtins for stuff in
*mmintrin.h, we could use a different set of builtins that only supports V2SI
and nothing else..? Well, that's going to be for another time ;)

-- 


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

[Bug c++/19699] New: [4.0 Regression] warning about not returning from end of a non-void function because of dead code

[pinskia at gcc dot gnu dot org]

Reduced testcase (why don't we remove the dead code before inlining).
void g(void);
inline int f(void)
{
  return 1;
  g();
}
int h(void)
{
  return f();
}

Note this is reduced from:
#include 
#include 
void foo(std::vector & matches)
{
 char * buf[10];
 matches.insert(matches.end(), buf, buf + 10);
}

(also why does libstdc++ have dead code in its headers.

-- 
   Summary: [4.0 Regression] warning about not returning from end of
a non-void function because of dead code
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug middle-end/19583] [4.0 Regression] Incorrect diagnostic: control may reach end of non-void function '...' being inlined

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
19:23 ---
(In reply to comment #23)
> This does not seem to be fixed so reopening.
I opened another PR because it is related but not fully the same problem.  (PR 
19699).

-- 


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

[Bug c++/19699] [4.0 Regression] warning about not returning from end of a non-void function because of dead code

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.0.0


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

[Bug middle-end/19698] [4.0 regression] Infinite loop in update_life_info

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||compile-time-hog
   Target Milestone|--- |4.0.0


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

[Bug middle-end/19699] [4.0 Regression] warning about not returning from end of a non-void function because of dead code

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
19:25 ---
I also happens with the C front-end too.

-- 
   What|Removed |Added

  Component|c++ |middle-end


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

[Bug tree-optimization/15791] fold misses that two ADDR_EXPR of an arrary obvious not equal

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-29 
19:25 ---
Subject: Bug 15791

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-01-29 19:25:17

Modified files:
gcc: ChangeLog fold-const.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg/tree-ssa: pr15791-1.c pr15791-2.c 
   pr15791-3.c pr15791-4.c 
   pr15791-5.c 
gcc/testsuite/g++.dg/tree-ssa: pr15791-1.C pr15791-2.C 
   pr15791-3.C pr15791-4.C 
   pr15791-5.C 

Log message:
2005-01-29  Richard Guenther <[EMAIL PROTECTED]>

PR tree-optimization/15791
* fold-const.c (extract_array_ref): New function.
(fold): Fold comparisons between &a[i] and &a[j] or
semantically equivalent trees.

* gcc.dg/tree-ssa/pr15791-1.c: New testcase.
* gcc.dg/tree-ssa/pr15791-2.c: Likewise.
* gcc.dg/tree-ssa/pr15791-3.c: Likewise.
* gcc.dg/tree-ssa/pr15791-4.c: Likewise.
* gcc.dg/tree-ssa/pr15791-5.c: Likewise.
* g++.dg/tree-ssa/pr15791-1.C: Likewise.
* g++.dg/tree-ssa/pr15791-2.C: Likewise.
* g++.dg/tree-ssa/pr15791-3.C: Likewise.
* g++.dg/tree-ssa/pr15791-4.C: Likewise.
* g++.dg/tree-ssa/pr15791-5.C: Likewise.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7325&r2=2.7326
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gcc&r1=1.498&r2=1.499
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4957&r2=1.4958
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr15791-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr15791-2.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr15791-3.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr15791-4.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr15791-5.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/tree-ssa/pr15791-1.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/tree-ssa/pr15791-2.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/tree-ssa/pr15791-3.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/tree-ssa/pr15791-4.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/tree-ssa/pr15791-5.C.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug middle-end/19699] [4.0 Regression] warning about not returning from end of a non-void function because of dead code

[larsbj at gullik dot net]

-- 
   What|Removed |Added

 CC||larsbj at gullik dot net


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

[Bug tree-optimization/19639] Funny (horrible) code for empty destructor

[pinskia at gcc dot gnu dot org]

-- 
Bug 19639 depends on bug 15791, which changed state.

Bug 15791 Summary: fold misses that two ADDR_EXPR of an arrary obvious not equal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15791

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/15791] fold misses that two ADDR_EXPR of an arrary obvious not equal

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
19:39 ---
Fixed.

-- 
   What|Removed |Added

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


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

[Bug target/19690] ICE with -O3 -march=athlon-xp -mfpmath=sse -mno-80387

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-01-29 
20:01 ---
Created an attachment (id=8103)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8103&action=view)
Failing preprocessed C source code

To see wether this problem can also be exposed with the C
frontend, I ran the subroutine through f2c and preprocessed it
with "gcc -E".

Still the same error:
$ gcc -O3 -g -march=athlon-xp -mfpmath=sse -mno-80387 ddot.i
ddot.c: In function 'ddot_':
ddot.c:91: error: insn does not satisfy its constraints:
(insn 346 345 347 8 ddot.c:53 (set (reg:DF 21 xmm0 [103])
(mem:DF (plus:SI (reg/f:SI 6 bp)
(const_int -128 [0xff80])) [0 S8 A8])) 64
{*movdf_nointeger} (nil)
(nil))
ddot.c:91: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:391
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

so this is indeed independent of the front end.

Thomas

-- 


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

[Bug tree-optimization/19639] Funny (horrible) code for empty destructor

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
20:48 ---
(In reply to comment #5)
> What other pass than fold() is supposed to handle this sort of simplification?
Actually if you look at the tree dumps you will see that we removed that if.  
It does not help the testcase 
as we already removed that if on the rtl level.  But now the only problem is 
removing empty loops.

-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-01-29 20:52 
---
Interesting ;) After so many months, it turns out we have to add push/pop to
*all* the headers?!? Why nobody mentioned that before?!? Not a big deal, in 
case,
but I'm somewhat suprised.

-- 


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

[Bug target/19700] New: ICE in final_scan_insn with O1 -g -march=athlon-xp -mfpmath=sse

[Thomas dot Koenig at online dot de]

Compiling LAPACK:

gfortran -O1 -g -march=athlon-xp -mfpmath=sse  -c slanv2.f
slanv2.f: In function 'slanv2':
slanv2.f:202: error: could not split insn
(insn 95 567 566 slanv2.f:78 (parallel [
(set (reg:SF 21 xmm0)
(unspec:SF [
(reg:SF 26 xmm5 [123])
(const_vector:V4SF [
(const_double:SF 2147483392 [0x7f00] +NaN
[+NaN])
(const_double:SF 0 [0x0] 0.0 [0x0.0p+0])
(const_double:SF 0 [0x0] 0.0 [0x0.0p+0])
(const_double:SF 0 [0x0] 0.0 [0x0.0p+0])
])
(reg:SF 22 xmm1)
(reg:V4SF 21 xmm0)
] 100))
(clobber (reg:V4SF 22 xmm1))
]) 251 {*copysignsf3} (insn_list:REG_DEP_TRUE 92 (insn_list:REG_DEP_TRUE
93 (insn_list:REG_DEP_TRUE 94 (nil
(expr_list:REG_DEAD (reg:SF 22 xmm1)
(expr_list:REG_UNUSED (reg:V4SF 22 xmm1)
(nil
slanv2.f:202: internal compiler error: in final_scan_insn, at final.c:2501
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[1]: *** [slanv2.o] Error 1
make[1]: Leaving directory `/home/ig25/LAPACK/SRC'
make: *** [lapacklib] Error 2
$ gfortran -v
Using built-in specs.
Configured with: ../gcc/configure --prefix=/home/ig25 --enable-languages=c,f95
Thread model: posix
gcc version 4.0.0 20050129 (experimental)

-- 
   Summary: ICE in final_scan_insn with O1 -g -march=athlon-xp -
mfpmath=sse
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu


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

[Bug target/19700] ICE in final_scan_insn with O1 -g -march=athlon-xp -mfpmath=sse

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-01-29 
21:11 ---
Created an attachment (id=8104)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8104&action=view)
Failing source code


-- 


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

[Bug target/19700] ICE in final_scan_insn with O1 -g -march=athlon-xp -mfpmath=sse

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||ice-on-valid-code, ssemmx


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

[Bug tree-optimization/19639] Funny (horrible) code for empty destructor

[rguenth at tat dot physik dot uni-tuebingen dot de]

--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen 
dot de  2005-01-29 21:14 ---
Or we could simply unroll the loop completely, but while SCEV finds
the IV as

(set_scalar_evolution
  (scalar = this_6)
  (scalar_evolution = {(struct Foo * const) &x.foo[2] - 4B, +, -4B}_1))
)

it does not know about the number of iterations:

(set_nb_iterations_in_loop = scev_not_known))

  # BLOCK 1 
  # PRED: 3 [100.0%]  (fallthru) 0 [100.0%]  (fallthru,exec)
Invalid sum of incoming frequencies 10258, should be 1
  # thisD.1628_1 = PHI ;
:;
  thisD.1628_6 = thisD.1628_1 - 4;
  if (thisD.1628_6 == &xD.1600.fooD.1587) goto ; else goto ;
  # SUCC: 2 [11.0%]  (loop_exit,true,exec) 3 [89.0%]  (dfs_back,false,exec)
  
  # BLOCK 3 
  # PRED: 1 [89.0%]  (dfs_back,false,exec)
:;
  goto  (); 
  # SUCC: 1 [100.0%]  (fallthru)

-- 


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

[Bug tree-optimization/19639] Funny (horrible) code for empty destructor

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-29 
21:19 ---
As(In reply to comment #7)
> Or we could simply unroll the loop completely, but while SCEV finds
> the IV as

Again this is most likely because fold does not fold "&x.foo[2] - 4B" to 
"&x.foo[0]", or someone forgets 
to call fold on that.  I know that fold_stmt can do it.

-- 


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

[Bug middle-end/19687] [4.0 Regression] ICE with union initializer

[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|NEW |ASSIGNED
   Last reconfirmed|2005-01-29 12:46:39 |2005-01-29 21:57:39
   date||


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

[Bug middle-end/19689] [4.0 Regression] ICE in store_bit_field, at expmed.c

[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|NEW |ASSIGNED
   Last reconfirmed|2005-01-29 09:28:35 |2005-01-29 21:58:17
   date||


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

[Bug ada/19489] gnat tools not buildable cross

[neroden at gcc dot gnu dot org]

--- Additional Comments From neroden at gcc dot gnu dot org  2005-01-29 
22:19 ---
>You may try adding a gnattools directory, whose makefile and configury is   
based   
>on libada's, but which is a host module rather than a target module.   
   
Correct (dammit).  :-)   
 
I've already done this on the libada-gnattools-branch,   
but I've also done some other things there, which wouldn't be suitable for 
stage 3.  Please try a snapshot of the libada-gnattools-branch from... hmm, 
let's see...  December 1, 2004.  
  
If it works correctly (and I know it works correctly for native tools),  
it's safe enough to merge to mainline even in stage 3.  I would have done so 
already, but without a bug report, it wasn't stage-3-suitable. 
  
If it doesn't, come back to me; I expect that there's some incremental change 
on top of it which should sort out any remaining problems.   

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-01-29 22:19:59
   date||


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

[Bug ada/19489] gnat tools not buildable cross

[laurent at guerby dot net]

--- Additional Comments From laurent at guerby dot net  2005-01-29 22:39 
---
Since it is clearly a regression (vs 3.2 cross RTEMS/Ada capabilities), would
you mind proposing a patch to current 4.0 libada? I've included Arnaud in CC.

-- 
   What|Removed |Added

 CC||charlet at adacore dot com


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

5000 € PAR MOIS!..3 h par jour!!..VOUS INTERESSE???

[easywork_mondialexchange]

En démarrant aujourd’hui, en travaillant sérieusement, 
vous pourrez tirer immédiatement avantage des bénéfices et atteindre les 
objectifs suivants :
1. Les meilleurs gagnent 5.000 €/mois à temps partiel.
2. Les meilleurs gagnent 10.000 €/mois à temps complet.
3. Tous vos clients vous paient cash !
4. Vous vendrez un produit qui ne coûte pratiquement rien à produire.
5. Votre seul investissement est votre temps.
6. Vous démarrez demain avec seulement 25 €
7. Vous disposez d’un marché fort de plus de 40 millions de clients potentiels.
Tout se fait par emails. ET, FAIT EXTRAORDINAIRE, ÇA MARCHE! ÇA MARCHE MEME 
TRES FORT!!
Pour en savoir plus, contactez-moi par Email
Indiquez simplement « envoyez moi un dossier » comme objet de votre message.

[Bug libstdc++/19656] libstdc++ testsuite results differ if bootstrap gcc 4.0 using some gcc 4.0 version or early (gcc 3.4.3) gcc version at FreeBSD

[wanderer at rsu dot ru]

--- Additional Comments From wanderer at rsu dot ru  2005-01-29 23:49 
---
Result my "find the exact configuration patch that broke this":

gcc mainline bootstraped using FreeBSD 5.3 system compiler (gcc 3.4.2) display 
error "cc1: no iconv implementation, cannot convert from ISO8859-1 to UTF-8" at
"-finput-charset=ISO8859-1" use always starting from adding -finput-charset 
option to gcc CVS mainline (2004-02-02 20:20 GMT).


-- 


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

[Bug tree-optimization/19701] New: [4.0 regression] Way too many IVs

[falk at debian dot org]

GNU C version 4.0.0 20050120 (experimental) (alphaev68-unknown-linux-gnu)

Test case:

void fbSolidFillmmx(int w, unsigned char *d) {
while (w >= 64) {
*(unsigned long long *) (d +  0) = 0;
*(unsigned long long *) (d +  8) = 0;
*(unsigned long long *) (d + 16) = 0;
*(unsigned long long *) (d + 24) = 0;
*(unsigned long long *) (d + 32) = 0;
*(unsigned long long *) (d + 40) = 0;
*(unsigned long long *) (d + 48) = 0;
*(unsigned long long *) (d + 56) = 0;
w -= 64;
d += 64;
}
}

gives

fbSolidFillmmx:
cmple $16,63,$1
bne $1,$L5
lda $8,8($17)
lda $7,16($17)
lda $6,24($17)
lda $5,32($17)
lda $4,40($17)
lda $3,48($17)
lda $2,56($17)
mov $31,$22
.align 4
$L4:
stq $31,0($17)
lda $22,64($22)
lda $17,64($17)
stq $31,0($8)
subl $16,$22,$1
lda $8,64($8)
stq $31,0($7)
cmple $1,63,$1
lda $7,64($7)
stq $31,0($6)
lda $6,64($6)
stq $31,0($5)
lda $5,64($5)
stq $31,0($4)
lda $4,64($4)
stq $31,0($3)
lda $3,64($3)
stq $31,0($2)
lda $2,64($2)
beq $1,$L4
$L5:
ret $31,($26),1

gcc-3.4 generates reasonable code:

fbSolidFillmmx:
cmple $16,63,$1
bne $1,$L6
.align 4
$L11:
subl $16,64,$16
stq $31,0($17)
stq $31,8($17)
cmple $16,63,$1
stq $31,16($17)
stq $31,24($17)
stq $31,32($17)
stq $31,40($17)
stq $31,48($17)
stq $31,56($17)
lda $17,64($17)
beq $1,$L11
$L6:
ret $31,($26),1

-- 
   Summary: [4.0 regression] Way too many IVs
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: falk at debian dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: alphaev68-unknown-linux-gnu
  GCC host triplet: alphaev68-unknown-linux-gnu
GCC target triplet: alphaev68-unknown-linux-gnu


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

[Bug tree-optimization/19701] [4.0 regression] Way too many IVs

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-01-30 
00:55 ---
Can you add a tree dump and the output with -fno-ivopts? 

-- 


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

[Bug tree-optimization/19701] [4.0 regression] Way too many IVs

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-30 
01:08 ---
Confirmed, also happens on powerpc-darwin (This might be the one of the reasons 
why SPEC is slower 
on the mainline on some tests with -fivopts turned on).

Yes this is one of the few true iv-opts problems.  -fno-ivopts fixes the 
problem, I will attach the tree 
dumps for PPC soon.

-- 
   What|Removed |Added

   Severity|normal  |minor
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  GCC build triplet|alphaev68-unknown-linux-gnu |
   GCC host triplet|alphaev68-unknown-linux-gnu |
 GCC target triplet|alphaev68-unknown-linux-gnu |alpha*-*-*, powerpc*-*-*
   Keywords||missed-optimization
   Last reconfirmed|-00-00 00:00:00 |2005-01-30 01:08:22
   date||
   Target Milestone|--- |4.0.0


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

[Bug tree-optimization/19701] [4.0 regression] Way too many IVs

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-30 
01:12 ---
Here is the .optimizate dump for -fno-ivopts (the most optimial code):
{
:
  if (w > 63) goto ; else goto ;

:;
  *(long long unsigned int *) d = 0;
  *(long long unsigned int *) (d + 8B) = 0;
  *(long long unsigned int *) (d + 16B) = 0;
  *(long long unsigned int *) (d + 24B) = 0;
  *(long long unsigned int *) (d + 32B) = 0;
  *(long long unsigned int *) (d + 40B) = 0;
  *(long long unsigned int *) (d + 48B) = 0;
  *(long long unsigned int *) (d + 56B) = 0;
  w = w - 64;
  d = d + 64B;
  if (w > 63) goto ; else goto ;

:;
  return;

}
(just like what is in the source, one iv).

The tree dump for ivopts is still on (well the inner loop to show the problem):
:;
  *(long long unsigned int *) d.19 = 0;
  *ivtmp.10 = 0;
  *ivtmp.11 = 0;
  *ivtmp.12 = 0;
  *ivtmp.13 = 0;
  *ivtmp.14 = 0;
  *ivtmp.15 = 0;
  *ivtmp.16 = 0;
  d.19 = d.19 + 64B;
  ivtmp.10 = ivtmp.10 + 64B;
  ivtmp.11 = ivtmp.11 + 64B;
  ivtmp.12 = ivtmp.12 + 64B;
  ivtmp.13 = ivtmp.13 + 64B;
  ivtmp.14 = ivtmp.14 + 64B;
  ivtmp.15 = ivtmp.15 + 64B;
  ivtmp.16 = ivtmp.16 + 64B;
  if ((int) ((unsigned int) w + (unsigned int) d - (unsigned int) d.19) > 63) 
goto ; else goto ;

Some times is better to use only one IV especially for a manually unrolled loop 
which is what this loop 
is.


-- 


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

[Bug tree-optimization/19701] [4.0 regression] Way too many IVs

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-01-30 
01:33 ---
Also happens on x86-64, but not on x86. 
 

-- 
   What|Removed |Added

 CC||rakdver at gcc dot gnu dot
   ||org
 GCC target triplet|alpha*-*-*, powerpc*-*-*|
   Priority|P2  |P1


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