[Bug c/18671] New: Structure with bit-field offset is wrong.

2004-11-24 Thread nitins2 at kpitcummins dot com
Hi,
I am using tool chain built with gcc-3.4-20040813 snapshot.
The structure offset byte is wrong for the following C-source code with "-
mrenesas" option.
Without "-mrenesas" option it gives correct offset that is 4.

The data "b2" of structure "bbb" offset is comming 8 which is wrong, it should 
be 4.

**test.c***
struct aaa{
int a1;
}*zzz;

struct bbb {
 int b1:1;
 int b2;
};

test(){
((struct bbb*)zzz)->b2 = 0x12345678;
}

Command line **
sh-elf-gcc -mrenesas  -S test.c

***test.s**
_test:
mov.l   r14,@-r15
mov r15,r14
mov.l   .L2,r1
mov.l   @r1,r2
mov.l   .L3,r1
mov.l   r1,@(8,r2)  <-WRONG OFFSET 
mov r14,r15
mov.l   @r15+,r14
rts
nop
***

Kindly suggest how to solve this bug.

Thanks in advance.

Nitin Shah,
KPIT Cummins InfoSystems Ltd.
Pune, India


Free download of GNU based tool-chains for Renesas' SH and H8 Series.
The following site also offers free technical support to its users. 
Visit http://www.kpitgnutools.com for details. 
Latest versions of KPIT GNU tools are released on October 1, 2004.


-- 
   Summary: Structure with bit-field offset is wrong.
   Product: gcc
   Version: 3.4.2
Status: UNCONFIRMED
  Severity: critical
  Priority: P1
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nitins2 at kpitcummins dot com
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: sh-unknown-elf/sh-unknown-coff


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


[Bug rtl-optimization/18237] [4.0 regression] ICE in gen_lowpart_general, at rtlhooks.c:58

2004-11-24 Thread rth at gcc dot gnu dot org

--- Additional Comments From rth at gcc dot gnu dot org  2004-11-25 07:38 
---
You *do* realize that the current problem has absolutely nothing to do with
the original report, don't you?  You *do* realize that rewriting a PR like
this is pointless, and you should file a *new* PR to cover the new problem,
don't you?

I'll look at it.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rth at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED


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


[Bug regression/18643] [3.4 Regression] fixincludes breaks RTEMS

2004-11-24 Thread corsepiu at gcc dot gnu dot org

--- Additional Comments From corsepiu at gcc dot gnu dot org  2004-11-25 
05:43 ---
Patches applied to gcc-3_4-branch and CVS-trunk.


-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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


[Bug rtl-optimization/18237] [4.0 regression] ICE in gen_lowpart_general, at rtlhooks.c:58

2004-11-24 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-25 
05:13 ---
RTH, I think this regression is caused by one of your recent patches for 
subregisters.

-- 
   What|Removed |Added

 CC||rth at gcc dot gnu dot org
 GCC target triplet|powerpc-*-linux, powerpc-   |
   |darwin  |


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


[Bug c++/18670] g++ is allowing defaulted parameters in function definition in a weird way

2004-11-24 Thread giovannibajo at libero dot it

--- Additional Comments From giovannibajo at libero dot it  2004-11-25 
04:59 ---
Yes this is standard C++, the bug is invalid.

To attach files, you first need to create the bug, then you open it in your 
browser and click on the "create new attachment" link.

-- 


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


[Bug c++/18670] g++ is allowing defaulted parameters in function definition in a weird way

2004-11-24 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-25 
04:59 ---
No, the default paramaters is done in order of parsing and not out of order 
sorry.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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


[Bug c++/18670] New: g++ is allowing defaulted parameters in function definition in a weird way

2004-11-24 Thread imran at esscc dot uq dot edu dot au
First of all let me mention the fact that I do NOT have a copy of the standards
document with me. There, now that its out of the way; here goes...

My understanding is that the trailing N parameters can be defaulted. the
following code shows how some trailing params are defaulted in the function
declaration; but more of them are defaulted in the definition!

// start program
//#include 

void f( int i, int j=0 );
void blah( void );

int main( void )
{
f( 4, 5 ); // if this is f() the program won't compile
blah();
return 0;
}

void f( int i=0, int j )
{
// std::cout << "i -> " << i << " j -> " << j << std::endl;
}

void blah( void )
{
f();
}

// end program

The above simple program illustrates what I have mentioned earlier. The code
compiles fine with this cmdline:

g++ func.cpp -o func

Some people have reported that it compiles and runs fine with gcc 3.4.x as well.
 Although rare, it is possible to observe such code huge projects. If its within
the standards, please ignore.

-- Imran

ps: where do i attach the stuff generated by 'gcc -v -save-temps
all-your-options source-file' as mentioned in the 'how to post bugs in gcc'
document?

-- 
   Summary: g++ is allowing defaulted parameters in function
definition in a weird way
   Product: gcc
   Version: 3.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: imran at esscc dot uq dot edu dot au
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: 3.3.2
  GCC host triplet: 3.3.2
GCC target triplet: 3.3.2


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


[Bug bootstrap/18058] [4.0 Regression] Sun CC cannot bootstrap GCC (static inline)

2004-11-24 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-25 
04:51 ---
Mine fix is not a full one, Rainer did post a new one which works but I cannot 
remember if it went to 
gcc-patches@, I think it did.

-- 
   What|Removed |Added

 AssignedTo|pinskia at gcc dot gnu dot  |unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW
   Keywords|patch   |


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


[Bug c++/17729] [3.4/4.0 Regression] Duplicate __attribute__((deprecated)) warning

2004-11-24 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-25 
04:48 ---
Actually the patch did not fully, it did cause some regressions after all.

-- 
   What|Removed |Added

 AssignedTo|pinskia at gcc dot gnu dot  |unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW
   Keywords|patch   |


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


[Bug regression/18643] [3.4 Regression] fixincludes breaks RTEMS

2004-11-24 Thread corsepiu at gcc dot gnu dot org

--- Additional Comments From corsepiu at gcc dot gnu dot org  2004-11-25 
04:41 ---
(In reply to comment #3)
>> So the actual question is:
>>What has set LIMITS_H_TEST to "true" before, and why isn't it set true
>> anymore?

I believe to have found the cause (testing is still in progress).

LIMITS_H_TEST is being set true in config/t-rtems, but a typo in my patch has
prevented config/t-rtems from being picked up (cf. below).

> Is fixproto being set to yes somehow in
> config.gcc for avr-rtems?
Yes, there is a second, bogus use_fixproto for avr-*-* in config.gcc.

I'll propose it to be removed, soon.

>  Do you have a special stanza
> in your config.gcc for that target that is not checked in?
No, the versions I was comparing actually were my local version before having
commited the patch and the version after I commited the patch.

However, this hint was the key to the cause: A typo had crept into the patch I
had checked in (tmake_files= instead of tmake_file=), probably having crept in
when having transferred the patch from my testing cvs-tree (with further patche
s applied) to my submission cvs-tree.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |corsepiu at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 GCC target triplet|*-rtems*|avr-*-rtems*


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


[Bug c/18669] Compiler terminates with Bus Error

2004-11-24 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-25 
04:13 ---
scripts/basic/fixdep.c:98:22: /usr/include/sys/stat.h: Input/output error
This is your problem, looks like a hardware problem.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Keywords|ice-on-valid-code   |ice-on-invalid-code, patch
 Resolution||FIXED
   Target Milestone|--- |3.4.2


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


[Bug c/18669] Compiler terminates with Bus Error

2004-11-24 Thread ajow at ucsd dot edu


-- 
   What|Removed |Added

   Attachment #7603|Preprocessed Source |Preprocessed Source for
description||3.3.4


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


[Bug c/18669] Compiler terminates with Bus Error

2004-11-24 Thread ajow at ucsd dot edu

--- Additional Comments From ajow at ucsd dot edu  2004-11-25 04:11 ---
Created an attachment (id=7604)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7604&action=view)
Preprocessed source for 3.4.2


-- 


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


[Bug c/18669] Compiler terminates with Bus Error

2004-11-24 Thread ajow at ucsd dot edu

--- Additional Comments From ajow at ucsd dot edu  2004-11-25 04:10 ---
(In reply to comment #1)
> Can you try 3.3.5 and/or 3.4.x?

The following is the output from gcc version 3.4.2 (Debian 3.4.2-2).  I have
also attached the fixdep.i file for 3.4.2

scripts/basic/fixdep.c:98:22: /usr/include/sys/stat.h: Input/output error
scripts/basic/fixdep.c: In function `do_config_file':
scripts/basic/fixdep.c:255: error: storage size of 'st' isn't known
scripts/basic/fixdep.c:265: warning: implicit declaration of function `fstat'
scripts/basic/fixdep.c:255: warning: unused variable `st'
scripts/basic/fixdep.c: In function `print_deps':
scripts/basic/fixdep.c:325: error: storage size of 'st' isn't known
scripts/basic/fixdep.c:325: warning: unused variable `st'


-- 
   What|Removed |Added

  Component|preprocessor|c


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


[Bug preprocessor/18669] Compiler terminates with Bus Error

2004-11-24 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-25 
04:03 ---
Hmm, this looks like the preprocessor is crashing out.

-- 
   What|Removed |Added

  Component|c   |preprocessor
   Keywords||ice-on-valid-code


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


[Bug c/18669] Compiler terminates with Bus Error

2004-11-24 Thread ajow at ucsd dot edu

--- Additional Comments From ajow at ucsd dot edu  2004-11-25 04:01 ---
Created an attachment (id=7603)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7603&action=view)
Preprocessed Source


-- 


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


[Bug libgcj/18266] SIGSEGV in GC_register_finalizer_inner ()

2004-11-24 Thread tromey at gcc dot gnu dot org


-- 
   What|Removed |Added

OtherBugsDependingO||17574
  nThis||


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


[Bug java/17574] [meta-bug] gcj and libgcj 4.0 tracking PR

2004-11-24 Thread tromey at gcc dot gnu dot org

--- Additional Comments From tromey at gcc dot gnu dot org  2004-11-25 
03:26 ---
18266: low-level bug in Reference code; this is used by
  many real applications


-- 
   What|Removed |Added

  BugsThisDependsOn||18266


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


[Bug libgcj/18266] SIGSEGV in GC_register_finalizer_inner ()

2004-11-24 Thread tromey at gcc dot gnu dot org

--- Additional Comments From tromey at gcc dot gnu dot org  2004-11-25 
03:25 ---
Oops, I wasn't aware that the locks code was using finalizers.
We had to make special consideration in the reference code for
String.intern; we can do something similar for locks.
This is pretty important, I am going to add it to our 4.0
wish list.


-- 


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


[Bug c++/18545] [3.4/4.0 regression] ICE when returning undefined type

2004-11-24 Thread mark at codesourcery dot com

--- Additional Comments From mark at codesourcery dot com  2004-11-25 02:45 
---
Subject: Re:  [3.4/4.0 regression] ICE when returning undefined
 type

reichelt at gcc dot gnu dot org wrote:
> --- Additional Comments From reichelt at gcc dot gnu dot org  2004-11-25 
> 02:42 ---
> Mark, it looks like the following patch fixes the problem.

Thanks; I've already got a slightly cleaner version.



-- 


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


[Bug c++/18625] [3.4/4.0 regression] triple error message for invalid typedef

2004-11-24 Thread mmitchel at gcc dot gnu dot org


-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |mark at codesourcery dot com
   |dot org |
 Status|NEW |ASSIGNED


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


[Bug c++/18545] [3.4/4.0 regression] ICE when returning undefined type

2004-11-24 Thread reichelt at gcc dot gnu dot org

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-11-25 
02:42 ---
Mark, it looks like the following patch fixes the problem.

Index: typeck.c
===
RCS file: /home/reichelt/GCC/CVS/gcc-cvs/gcc/gcc/cp/typeck.c,v
retrieving revision 1.597
diff -u -p -r1.597 typeck.c
--- typeck.c22 Nov 2004 12:15:36 -  1.597
+++ typeck.c25 Nov 2004 01:41:11 -
@@ -6287,6 +6287,7 @@ check_return_expr (tree retval)
   if (fn_returns_value_p && flag_elide_constructors)
 {
   if (retval != NULL_TREE
+ && TREE_TYPE (retval) != error_mark_node
  && (current_function_return_value == NULL_TREE
  || current_function_return_value == retval)
  && TREE_CODE (retval) == VAR_DECL


-- 


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


[Bug c++/18545] [3.4/4.0 regression] ICE when returning undefined type

2004-11-24 Thread mmitchel at gcc dot gnu dot org


-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |mark at codesourcery dot com
   |dot org |
 Status|NEW |ASSIGNED


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


[Bug c++/18001] [4.0 regression] Badly formatted error message (quotation problem)

2004-11-24 Thread mmitchel at gcc dot gnu dot org


-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |mark at codesourcery dot com
   |dot org |
 Status|NEW |ASSIGNED


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


[Bug c++/18466] [3.3/3.4/4.0 regression] int ::i; accepted

2004-11-24 Thread mmitchel at gcc dot gnu dot org


-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |mark at codesourcery dot com
   |dot org |
 Status|NEW |ASSIGNED


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


[Bug rtl-optimization/18331] [4.0 regression] mmix-knuth-mmixware testsuite failure: execute/ieee/fp-cmp-8.c gcc.dg/20040625-1.c

2004-11-24 Thread hp at gcc dot gnu dot org

--- Additional Comments From hp at gcc dot gnu dot org  2004-11-25 01:56 
---
I'm on it.  Looks like a target bug.

-- 
   What|Removed |Added

 Status|NEW |ASSIGNED
   Last reconfirmed|2004-11-07 02:13:30 |2004-11-25 01:56:17
   date||


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


[Bug libgcj/18266] SIGSEGV in GC_register_finalizer_inner ()

2004-11-24 Thread Hans dot Boehm at hp dot com

--- Additional Comments From Hans dot Boehm at hp dot com  2004-11-25 01:50 
---
After finally finding time to look at the code, it appears that my earlier 
guesses were correct.

::java::lang::ref::Reference::create in natReference.cc calls 
_Jv_RegisterFinalizer(referent ...), where referent is an arbitrary object, 
which may already have a finalizer.  This is bad news, since the original 
finalizer will be dropped.

The original finalizer may be a Java finalizer, or it may be one that was 
registered by the hash synchronization code to clean up a heavy lock entry for 
the object.  In either case we lose.  (The hash synchronization code is careful 
to not lose the original finalizer.)  In both cases I think, we are likely to 
mostly introduce leaks, and crash only occasionally.  So this may explain some 
other misbehavior.

The fix may require some thought.  At a minimum, we need to export more GC 
functionality, so that the Reference implementation can retrieve the old 
finalizer.  (The hash synchronization code currently cheats and goes directly 
to the GC interface, which should also be fixed.)

I think that so long as Reference gets the ordering right, and doesn't assume 
that all finalizers are Java finalizers, the hash synchronization code should 
work.  It needs to drop the heavy lock before the object is deallocated, and 
while the lock is not held.  I don't think the timing otherwise matters.  If 
the object is resurrected 17 times, we can drop the heavy lock at any of those 
points, recreating it if necessary.

This really needs to be fixed to make any use of References reliable.

-- 
   What|Removed |Added

 CC||tromey at redhat dot com


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


[Bug driver/18549] -save-temps option ends with corrupt object file

2004-11-24 Thread h dot rind at mondial dot co dot at

--- Additional Comments From h dot rind at mondial dot co dot at  
2004-11-25 01:46 ---
the following might be a similar problem:

if h8300-hms-gcc 3.3.1 is called with the -save-temps option on h8300-hms it 
produces
a wrong output architecture.
a call to the linker results in the following error message:
h8300-hms-ld: skipping incompatible main.o when searching for main.o
h8300-hms-ld: cannot find main.o

used call:
h8300-hms-gcc -mh -c -Wall -W -Wcast-qual -Wwrite-strings -Wno-unused -save-
temps main.cpp

i figured out that gcc creates h8300-architecture instead of h8300h, which is 
why
the linker fails. this can be checked with "h8300-hms-objdump.exe -f main.o".

omitting -save-temps resolves the problem.
OS: Win2000 (tested, behaviour can be reproduced)


-- 


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


[Bug c/18669] Compiler terminates with Bus Error

2004-11-24 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-25 
01:09 ---
Also can you attach the preprocessed source instead of copying into the 
comments?

-- 


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


[Bug c/18669] Compiler terminates with Bus Error

2004-11-24 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-25 
01:08 ---
Can you try 3.3.5 and/or 3.4.x?

-- 


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


[Bug c/18669] New: Compiler terminates with Bus Error

2004-11-24 Thread ajow at ucsd dot edu
Bus error before compiler terminates when compiling the Linux kernel
(kernel-source-2.6.8 in Debian) on Thinkpad T40 running Debian testing (gcc
version 3.3.4 (Debian 1:3.3.4-13))

Command causing the problem:
gcc -Wp,-MD,scripts/basic/.fixdep.d -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -o scripts/basic/fixdep scripts/basic/fixdep.c

Compiler output:
In file included from scripts/basic/fixdep.c:98:
/usr/include/sys/stat.h:-4269: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions, see
.

Preprocessed file contents (fixdep.i):
# 1 "scripts/basic/fixdep.c"
# 1 ""
# 1 ""
# 1 "scripts/basic/fixdep.c"
# 97 "scripts/basic/fixdep.c"
# 1 "/usr/include/sys/types.h" 1 3 4
# 27 "/usr/include/sys/types.h" 3 4
# 1 "/usr/include/features.h" 1 3 4
# 295 "/usr/include/features.h" 3 4
# 1 "/usr/include/sys/cdefs.h" 1 3 4
# 296 "/usr/include/features.h" 2 3 4
# 318 "/usr/include/features.h" 3 4
# 1 "/usr/include/gnu/stubs.h" 1 3 4
# 319 "/usr/include/features.h" 2 3 4
# 28 "/usr/include/sys/types.h" 2 3 4



# 1 "/usr/include/bits/types.h" 1 3 4
# 28 "/usr/include/bits/types.h" 3 4
# 1 "/usr/include/bits/wordsize.h" 1 3 4
# 29 "/usr/include/bits/types.h" 2 3 4


# 1 "/usr/lib/gcc-lib/i486-linux/3.3.4/include/stddef.h" 1 3 4
# 213 "/usr/lib/gcc-lib/i486-linux/3.3.4/include/stddef.h" 3 4
typedef unsigned int size_t;
# 32 "/usr/include/bits/types.h" 2 3 4


typedef unsigned char __u_char;
typedef unsigned short int __u_short;
typedef unsigned int __u_int;
typedef unsigned long int __u_long;


typedef signed char __int8_t;
typedef unsigned char __uint8_t;
typedef signed short int __int16_t;
typedef unsigned short int __uint16_t;
typedef signed int __int32_t;
typedef unsigned int __uint32_t;




__extension__ typedef signed long long int __int64_t;
__extension__ typedef unsigned long long int __uint64_t;







__extension__ typedef long long int __quad_t;
__extension__ typedef unsigned long long int __u_quad_t;
# 129 "/usr/include/bits/types.h" 3 4
# 1 "/usr/include/bits/typesizes.h" 1 3 4
# 130 "/usr/include/bits/types.h" 2 3 4






__extension__ typedef unsigned long long int __dev_t;
__extension__ typedef unsigned int __uid_t;
__extension__ typedef unsigned int __gid_t;
__extension__ typedef unsigned long int __ino_t;
__extension__ typedef unsigned long long int __ino64_t;
__extension__ typedef unsigned int __mode_t;
__extension__ typedef unsigned int __nlink_t;
__extension__ typedef long int __off_t;
__extension__ typedef long long int __off64_t;
__extension__ typedef int __pid_t;
__extension__ typedef struct { int __val[2]; } __fsid_t;
__extension__ typedef long int __clock_t;
__extension__ typedef unsigned long int __rlim_t;
__extension__ typedef unsigned long long int __rlim64_t;
__extension__ typedef unsigned int __id_t;
__extension__ typedef long int __time_t;
__extension__ typedef unsigned int __useconds_t;
__extension__ typedef long int __suseconds_t;

__extension__ typedef int __daddr_t;
__extension__ typedef long int __swblk_t;
__extension__ typedef int __key_t;


__extension__ typedef int __clockid_t;


__extension__ typedef int __timer_t;


__extension__ typedef long int __blksize_t;




__extension__ typedef long int __blkcnt_t;
__extension__ typedef long long int __blkcnt64_t;


__extension__ typedef unsigned long int __fsblkcnt_t;
__extension__ typedef unsigned long long int __fsblkcnt64_t;


__extension__ typedef unsigned long int __fsfilcnt_t;
__extension__ typedef unsigned long long int __fsfilcnt64_t;

__extension__ typedef int __ssize_t;



typedef __off64_t __loff_t;
typedef __quad_t *__qaddr_t;
typedef char *__caddr_t;


__extension__ typedef int __intptr_t;


__extension__ typedef unsigned int __socklen_t;
# 32 "/usr/include/sys/types.h" 2 3 4



typedef __u_char u_char;
typedef __u_short u_short;
typedef __u_int u_int;
typedef __u_long u_long;
typedef __quad_t quad_t;
typedef __u_quad_t u_quad_t;
typedef __fsid_t fsid_t;




typedef __loff_t loff_t;



typedef __ino_t ino_t;
# 62 "/usr/include/sys/types.h" 3 4
typedef __dev_t dev_t;




typedef __gid_t gid_t;




typedef __mode_t mode_t;




typedef __nlink_t nlink_t;




typedef __uid_t uid_t;





typedef __off_t off_t;
# 100 "/usr/include/sys/types.h" 3 4
typedef __pid_t pid_t;




typedef __id_t id_t;




typedef __ssize_t ssize_t;





typedef __daddr_t daddr_t;
typedef __caddr_t caddr_t;





typedef __key_t key_t;
# 133 "/usr/include/sys/types.h" 3 4
# 1 "/usr/include/time.h" 1 3 4
# 74 "/usr/include/time.h" 3 4


typedef __time_t time_t;



# 92 "/usr/include/time.h" 3 4
typedef __clockid_t clockid_t;
# 104 "/usr/include/time.h" 3 4
typedef __timer_t timer_t;
# 134 "/usr/include/sys/types.h" 2 3 4
# 147 "/usr/include/sys/types.h" 3 4
# 1 "/usr/lib/gcc-lib/i486-linux/3.3.4/include/stddef.h" 1 3 4
# 148 "/usr/include/sys/types.h" 2 3 4



typedef unsigned long int ulong;
t

[Bug target/18668] New: use prescott's fisttp

2004-11-24 Thread commie1 at gmx dot net
When compiling code that converts a float to an int using -march=prescott gcc
will often use cvtts[sd]2si, but sometimes it will use the old method of:

fnstcw  -2(%ebp) # store the control word
movzwl  -2(%ebp), %eax
orw $3072, %ax   # change it to truncate
movw%ax, -4(%ebp)
fldcw   -4(%ebp) # load that new value
fistpll -16(%ebp)# perform the conversion
fldcw   -2(%ebp) # and load the previous value

which prescott (and beyond, presumably) can reduce to: fisttpll -16(%ebp)

The code in this case was:

unsigned int oof(double d)
{
  unsigned int i;
  i = d;
  return i;
}

I've found hardly any mention of this instruction in the mailinglists, the code
or bugzilla (PR12308). Perhaps the cvtts[sd]2si should be used with unsigned as
well, perhaps there are other reasons not to have fisttp, I'd like to know.

-- 
   Summary: use prescott's fisttp
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: commie1 at gmx dot net
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=18668


[Bug tree-optimization/18601] [4.0 Regression] tree cfglceanup is slow

2004-11-24 Thread rakdver at gcc dot gnu dot org

--- Additional Comments From rakdver at gcc dot gnu dot org  2004-11-25 
01:02 ---
Patch:

http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02089.html

-- 
   What|Removed |Added

   Keywords||patch


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


[Bug c/18666] Conversion of floating point into bit-fields

2004-11-24 Thread joseph at codesourcery dot com

--- Additional Comments From joseph at codesourcery dot com  2004-11-25 
00:52 ---
Subject: Re:  New: Conversion of floating point into bit-fields

On Thu, 25 Nov 2004, jakub at gcc dot gnu dot org wrote:

> a valid test or not?  This worked with 3.4.x and earlier, but doesn't any
> longer.  The question is mainly if the type of a.i for the 6.3.1.4/1 purposes
> is unsigned int (in this case it would be well-defined, 16 is representable
> in unsigned int and storing 16 into unsigned int i : 1 bitfield is defined),
> or if the type is integer type with precision 1.

There are at least three DRs affirming that the type is unsigned:1, i.e. a 
type with precision 1.



-- 


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


[Bug middle-end/18667] ice with --parm integer-share-limit=0

2004-11-24 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-25 
00:49 ---
A related failure is with =1:
gcc t.c --param integer-share-limit=1
:0: internal compiler error: tree check: accessed elt 2 of tree_vec 
with 1 elts in 
build_int_cst_wide, at tree.c:630
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

-- 


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


[Bug middle-end/18667] New: ice with --parm integer-share-limit=0

2004-11-24 Thread pinskia at gcc dot gnu dot org
cat /dev/null>t.c
gcc t.c --parm integer-share-limit=0 

this gives a bus error.

-- 
   Summary: ice with --parm integer-share-limit=0
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P2
 Component: middle-end
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,nathan at gcc dot gnu
dot org


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


[Bug c/18666] New: Conversion of floating point into bit-fields

2004-11-24 Thread jakub at gcc dot gnu dot org
Is
/* { dg-do run } */
/* { dg-options "-std=c99 -pedantic-errors } */

struct A { unsigned int i : 1; } a;
extern void abort (void);

int
main (void)
{
  a.i = 16.0;
  if (a.i != 0)
abort ();
  return 0;
}

a valid test or not?  This worked with 3.4.x and earlier, but doesn't any
longer.  The question is mainly if the type of a.i for the 6.3.1.4/1 purposes
is unsigned int (in this case it would be well-defined, 16 is representable
in unsigned int and storing 16 into unsigned int i : 1 bitfield is defined),
or if the type is integer type with precision 1.

-- 
   Summary: Conversion of floating point into bit-fields
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
CC: aoliva at redhat dot com,gcc-bugs at gcc dot gnu dot
org,joseph at codesourcery dot com


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


[Bug tree-optimization/18241] [4.0 Regression] linux kernel loop gets miscompiled

2004-11-24 Thread ak at muc dot de

--- Additional Comments From ak at muc dot de  2004-11-25 00:22 ---
Problem still happens as of HEAD 041125

-- 


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


[Bug tree-optimization/18576] [3.4/4.0 Regression] missing jump threading because of type changes

2004-11-24 Thread law at redhat dot com

--- Additional Comments From law at redhat dot com  2004-11-25 00:22 ---
Subject: Re:  [3.4/4.0 Regression] missing
jump threading because of type changes

On Wed, 2004-11-24 at 22:38 +, steven at gcc dot gnu dot org wrote:
> --- Additional Comments From steven at gcc dot gnu dot org  2004-11-24 
> 22:38 ---
> I don't think this is "minor".  We have many places where we have 
> predicates returning "bool", and this PR suggests that we can never 
> thread on their results because of casts. 
>  
> Adding Jeff, this may be a new prey for him after he's done with 
> Bug 15524 ;-) 
There are a number of ways we can attack this.  I don't know if any are
appropriate for 4.0 though.

One approach is to go with the phi optimization rewrite which allows it
to work with > 2 predecessors to the PHI block.

Another would be to look at Kazu's work which (IIRC) tried to identify
typecasts which were fed by PHIs with all constant arguments.  It then
removed the typecast and original PHI and installed a new PHI with a
result of the proper type.

A third would be to revamp the jump threading selection code.   In the
early days of the jump threading code we couldn't handle SSA graph
updates if we threaded through a block with side effects.  The new
SSA graph update code handles that case, so the selection code shouldn't
need to be so conservative anymore.

I think ultimately we'll want to do all three.  The question in my mind
is which (if any) are suitable for gcc 4.0.

jeff




-- 


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


[Bug middle-end/18071] [3.4/4.0 Regression] -Winline does not respect -fno-default-inline

2004-11-24 Thread giovannibajo at libero dot it

--- Additional Comments From giovannibajo at libero dot it  2004-11-25 
00:20 ---
The problem appears to be the other way round. The C frontend mark the 
declaration as DECL_DECLARED_INLINE but not as DECL_INLINE because the body is 
not available. The relevant portion of code is this:


else if (declspecs->inline_p)
  {
/* Record that the function is declared `inline'.  */
DECL_DECLARED_INLINE_P (decl) = 1;

/* Do not mark bare declarations as DECL_INLINE.  Doing so
   in the presence of multiple declarations can result in
   the abstract origin pointing between the declarations,
   which will confuse dwarf2out.  */
if (initialized)
  {
DECL_INLINE (decl) = 1;
if (storage_class == csc_extern)
  current_extern_inline = 1;
  }


The C++ frontend instead does not have this issue: by default, all declarations 
marked by DECL_DECLARED_INLINE are also marked with DECL_INLINE. In fact, the 
testcase works even after my patch when compiled with cc1plus.

The code has been there since this patch: http://gcc.gnu.org/ml/gcc-cvs/2001-
12/msg00833.html. It fixed PR 5163. I tried removing the if(initialized) and 
always set DECL_INLINE even for functions with no bodies, and the testcase for 
the bug still succeeds. Maybe the weirdness in dwarf2out has been fixed since 
then.

RTH, do you think it makes sense to remove that check and set DECL_INLINE even 
for functions with no bodies in the C frontend? The C++ FE does that.

-- 
   What|Removed |Added

 CC||rth at gcc dot gnu dot org,
   ||stevenb at suse dot de


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


[Bug c++/18285] [4.0 regression] multiple types in typedef not rejected

2004-11-24 Thread mmitchel at gcc dot gnu dot org

--- Additional Comments From mmitchel at gcc dot gnu dot org  2004-11-24 
23:24 ---
Fixed in GCC 4.0.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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


[Bug c++/17473] [3.3/3.4 Regression] typedef redefinition in struct is accepted

2004-11-24 Thread mmitchel at gcc dot gnu dot org

--- Additional Comments From mmitchel at gcc dot gnu dot org  2004-11-24 
23:24 ---
Fixed in GCC 4.0.  

I do not intend to backport this to 3.4.x, as doing so would potentially break
code that works in 3.4.3, and has no semantic ambiguity.  

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to fail|3.0.4 3.2.2 3.3.1 3.3.4 |3.0.4 3.2.2 3.3.1 3.3.4
   |3.4.0 4.0.0 |3.4.0
  Known to work|2.95|2.95 4.0.0
 Resolution||FIXED
Summary|[3.3/3.4/4.0 Regression]|[3.3/3.4 Regression] typedef
   |typedef redefinition in |redefinition in struct is
   |struct is accepted  |accepted
   Target Milestone|3.4.4   |4.0.0


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


[Bug c++/17473] [3.3/3.4/4.0 Regression] typedef redefinition in struct is accepted

2004-11-24 Thread cvs-commit at gcc dot gnu dot org

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-11-24 
23:19 ---
Subject: Bug 17473

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-11-24 23:18:56

Modified files:
gcc/cp : ChangeLog name-lookup.c parser.c 
gcc/testsuite  : ChangeLog 
gcc/testsuite/g++.dg/template: typedef1.C 
gcc/testsuite/g++.old-deja/g++.other: typedef7.C 
Added files:
gcc/testsuite/g++.dg/parse: typedef7.C 
Removed files:
gcc/testsuite/g++.dg/tc1: dr56.C 

Log message:
PR c++/17473
* name-lookup.c (supplement_binding): Do not allow typedefs to be
redefined in class scope.

PR c++/18285
* parser.c (cp_parser_set_decl_type_spec): Do not try to allow
redefinitions of builtin types other that "bool" or "wchar_t".

PR c++/17473
* g++.dg/tc1/dr56.C: Remove.
* g++.dg/template/typedef1.C: Add dg-error markers.
* g++.old-deja/g++.other/typedef7.C: Likewise.

PR c++/18285
* g++.dg/parse/typedef7.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4494&r2=1.4495
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/name-lookup.c.diff?cvsroot=gcc&r1=1.92&r2=1.93
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&r1=1.280&r2=1.281
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4644&r2=1.4645
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/tc1/dr56.C.diff?cvsroot=gcc&r1=1.2&r2=NONE
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/typedef1.C.diff?cvsroot=gcc&r1=1.1&r2=1.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.old-deja/g++.other/typedef7.C.diff?cvsroot=gcc&r1=1.3&r2=1.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/typedef7.C.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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


[Bug c++/18285] [4.0 regression] multiple types in typedef not rejected

2004-11-24 Thread cvs-commit at gcc dot gnu dot org

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-11-24 
23:19 ---
Subject: Bug 18285

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-11-24 23:18:56

Modified files:
gcc/cp : ChangeLog name-lookup.c parser.c 
gcc/testsuite  : ChangeLog 
gcc/testsuite/g++.dg/template: typedef1.C 
gcc/testsuite/g++.old-deja/g++.other: typedef7.C 
Added files:
gcc/testsuite/g++.dg/parse: typedef7.C 
Removed files:
gcc/testsuite/g++.dg/tc1: dr56.C 

Log message:
PR c++/17473
* name-lookup.c (supplement_binding): Do not allow typedefs to be
redefined in class scope.

PR c++/18285
* parser.c (cp_parser_set_decl_type_spec): Do not try to allow
redefinitions of builtin types other that "bool" or "wchar_t".

PR c++/17473
* g++.dg/tc1/dr56.C: Remove.
* g++.dg/template/typedef1.C: Add dg-error markers.
* g++.old-deja/g++.other/typedef7.C: Likewise.

PR c++/18285
* g++.dg/parse/typedef7.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4494&r2=1.4495
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/name-lookup.c.diff?cvsroot=gcc&r1=1.92&r2=1.93
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&r1=1.280&r2=1.281
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4644&r2=1.4645
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/tc1/dr56.C.diff?cvsroot=gcc&r1=1.2&r2=NONE
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/typedef1.C.diff?cvsroot=gcc&r1=1.1&r2=1.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.old-deja/g++.other/typedef7.C.diff?cvsroot=gcc&r1=1.3&r2=1.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/typedef7.C.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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


[Bug c++/18652] [4.0 regression] ICE on invalid redeclaration

2004-11-24 Thread reichelt at gcc dot gnu dot org

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-11-24 
23:18 ---
IMHO duplicate_decls and/or its callers are broken.
The comment on top of duplicate_decls reads:

  /* If NEWDECL is a redeclaration of OLDDECL, merge the declarations.
 If the redeclaration is invalid, a diagnostic is issued, and the
 error_mark_node is returned.  Otherwise, OLDDECL is returned.

 If NEWDECL is not a redeclaration of OLDDECL, NULL_TREE is
 returned.  */

  tree
  duplicate_decls (tree newdecl, tree olddecl)

But in many situations we return a NULL_TREE, if an error occurred. In fact
we only return an error_mark_node twice. In the first case this leads to
the ICE:

  error ("%q#D redeclared as different kind of symbol", newdecl);
  if (TREE_CODE (olddecl) == TREE_LIST)
olddecl = TREE_VALUE (olddecl);
  cp_error_at ("previous declaration of %q#D", olddecl);

  return error_mark_node;

Changing the error_mark_node into NULL_TREE in fact makes the ICE go away.
However, that causes a minor regression in the testsuite:

  FAIL: g++.dg/other/error8.C duplicate error messages (test for bogus messages,
line 8)
  FAIL: g++.dg/other/error8.C duplicate error messages (test for bogus messages,
line 9)

Looks like the right fix is to make duplicate_decls behave like the comment
says and teach the callers how to handle error_mark_node.
Maybe this even fixes the triple error message in PR18625.


-- 


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


[Bug tree-optimization/18650] [4.0 Regression] Failure in tree-ssa/loop-2.c with powerpc64 with biarch

2004-11-24 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-24 
23:01 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-11-24 23:01:11
   date||
Summary|Failure in tree-ssa/loop-2.c|[4.0 Regression] Failure in
   |with powerpc64 with biarch  |tree-ssa/loop-2.c with
   ||powerpc64 with biarch
   Target Milestone|--- |4.0.0


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


[Bug tree-optimization/18650] Failure in tree-ssa/loop-2.c with powerpc64 with biarch

2004-11-24 Thread jgrimm2 at us dot ibm dot com

--- Additional Comments From jgrimm2 at us dot ibm dot com  2004-11-24 
22:59 ---
This set of changes seems to have caused the regression:
http://gcc.gnu.org/ml/gcc-cvs/2004-10/msg01561.html

Or more specifically
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-ivopts.c.diff?cvsroot=gcc&r1=2.20&r2=2.21

If I re-enable walking all of the candidates (as opposed to just the "important"
ones" I get back the optimizations that were present before and this test case
will pass again. 



-- 


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


[Bug target/18665] -ftrapv borks up simple integer arithmetic

2004-11-24 Thread pinskia at gcc dot gnu dot org


-- 
   What|Removed |Added

   Severity|critical|normal
   Keywords||wrong-code


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


[Bug tree-optimization/18576] [3.4/4.0 Regression] missing jump threading because of type changes

2004-11-24 Thread steven at gcc dot gnu dot org

--- Additional Comments From steven at gcc dot gnu dot org  2004-11-24 
22:38 ---
I don't think this is "minor".  We have many places where we have 
predicates returning "bool", and this PR suggests that we can never 
thread on their results because of casts. 
 
Adding Jeff, this may be a new prey for him after he's done with 
Bug 15524 ;-) 

-- 
   What|Removed |Added

 CC||law at redhat dot com
   Severity|minor   |normal
   Last reconfirmed|2004-11-20 16:44:20 |2004-11-24 22:38:25
   date||


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


[Bug target/18665] -ftrapv borks up simple integer arithmetic

2004-11-24 Thread skunk at iskunk dot org

--- Additional Comments From skunk at iskunk dot org  2004-11-24 22:32 
---
Created an attachment (id=7600)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7600&action=view)
Test case exhibiting subject bug

The bug occurs in the lib.c file. I have added some extra printf()s and an
assert() to make it stand out. The makefile's default target will compile the
program and execute it in the manner that raises the bug.

-- 


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


[Bug rtl-optimization/17825] [3.4/4.0 Regression] ICE in reg_bitfield_target_p

2004-11-24 Thread cvs-commit at gcc dot gnu dot org

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-11-24 
22:29 ---
Subject: Bug 17825

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-rhl-branch
Changes by: [EMAIL PROTECTED]   2004-11-24 22:28:46

Modified files:
gcc: ChangeLog combine.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.c-torture/compile: 20041119-1.c 

Log message:
PR rtl-optimization/17825
* combine.c (subst): Ignore STRICT_LOW_PART no matter if REG_P (new)
or not.

* gcc.c-torture/compile/20041119-1.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=2.2326.2.399.2.58&r2=2.2326.2.399.2.59
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/combine.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.400.4.6.2.3&r2=1.400.4.6.2.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.3389.2.170.2.29&r2=1.3389.2.170.2.30
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/20041119-1.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=NONE&r2=1.1.2.1



-- 


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


[Bug target/18665] New: -ftrapv borks up simple integer arithmetic

2004-11-24 Thread skunk at iskunk dot org
A large program was failing mysteriously on our new Opteron box. Went through it
with a fine-toothed debugger, until I came to the line

k -= i;  /*  and  are ints */

Before this line: k == 2, i == 1
 After this line: k == -14, i == 1

Compiling without -ftrapv makes this weirdness go away.

I will attach a tarball containing two .c files and a makefile, basically the
aforementioned big program with all irrelevant code ripped out---just enough to
reproduce the problem.

This bug first came up with 3.4.2, as shipped with Fedora Core 3 (x86-64). I
built 3.4.3 with the below configuration to confirm that the bug is still 
present.

Output from "gcc -v"

Reading specs from
/mnt/freeport/opt/gcc-3.4.3--linux64/bin/../lib/gcc/x86_64-unknown-linux-gnu/3.4.3/specs
Configured with: /mnt/freeport/src/gcc/current/configure
--prefix=/mnt/freeport/arch/linux64 --disable-dependency-tracking
--disable-shared --disable-nls --with-libiconv-prefix=/mnt/freeport/arch/linux64
--disable-multilib --with-arch=opteron
Thread model: posix
gcc version 3.4.3

-- 
   Summary: -ftrapv borks up simple integer arithmetic
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: skunk at iskunk 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=18665


[Bug target/13158] bad unwind info as a result of sibcall

2004-11-24 Thread cvs-commit at gcc dot gnu dot org

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-11-24 
22:23 ---
Subject: Bug 13158

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-rhl-branch
Changes by: [EMAIL PROTECTED]   2004-11-24 22:22:29

Modified files:
gcc: ChangeLog emit-rtl.c 
gcc/config/ia64: ia64.c 

Log message:
2004-10-27  David Mosberger  <[EMAIL PROTECTED]>
James E Wilson  <[EMAIL PROTECTED]>

PR target/13158
* config/ia64/ia64.c (ia64_expand_epilogue): Set RTX_FRAME_RELATED_P on
sibcall alloc instruction.
(process_set): Handle sibcall alloc instruction.

2004-10-26  James E Wilson  <[EMAIL PROTECTED]>

PR target/18010
* emit-rtl.c (emit_copy_of_insn_after): Copy RTX_FRAME_RELATED_P.

2004-02-03  Kazu Hirata  <[EMAIL PROTECTED]>

* config/ia64/ia64.c: Use const0_rtx instead of GEN_INT (0).

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=2.2326.2.399.2.57&r2=2.2326.2.399.2.58
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/emit-rtl.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.365.4.5&r2=1.365.4.5.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.265.2.6.2.5&r2=1.265.2.6.2.6



-- 


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


[Bug target/18010] bad unwind info due to multiple returns (missing epilogue)

2004-11-24 Thread cvs-commit at gcc dot gnu dot org

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-11-24 
22:23 ---
Subject: Bug 18010

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-rhl-branch
Changes by: [EMAIL PROTECTED]   2004-11-24 22:22:29

Modified files:
gcc: ChangeLog emit-rtl.c 
gcc/config/ia64: ia64.c 

Log message:
2004-10-27  David Mosberger  <[EMAIL PROTECTED]>
James E Wilson  <[EMAIL PROTECTED]>

PR target/13158
* config/ia64/ia64.c (ia64_expand_epilogue): Set RTX_FRAME_RELATED_P on
sibcall alloc instruction.
(process_set): Handle sibcall alloc instruction.

2004-10-26  James E Wilson  <[EMAIL PROTECTED]>

PR target/18010
* emit-rtl.c (emit_copy_of_insn_after): Copy RTX_FRAME_RELATED_P.

2004-02-03  Kazu Hirata  <[EMAIL PROTECTED]>

* config/ia64/ia64.c: Use const0_rtx instead of GEN_INT (0).

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=2.2326.2.399.2.57&r2=2.2326.2.399.2.58
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/emit-rtl.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.365.4.5&r2=1.365.4.5.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.265.2.6.2.5&r2=1.265.2.6.2.6



-- 


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


[Bug tree-optimization/18659] [4.0 Regression] ACATS ICE in bug in tree-sra.c:1507 on x86 and ppc-darwin (6 FAIL)

2004-11-24 Thread laurent at guerby dot net

--- Additional Comments From laurent at guerby dot net  2004-11-24 22:21 
---
These 6 ACATS FAIL appeared between 20041027 13:16:33 CET and 20041107 12:23:42
CET (together with 21 additional ACATS FAIL...).


-- 


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


[Bug c/18282] PR c/17384 patch causes regression from 3.4.2

2004-11-24 Thread cvs-commit at gcc dot gnu dot org

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-11-24 
22:18 ---
Subject: Bug 18282

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-rhl-branch
Changes by: [EMAIL PROTECTED]   2004-11-24 22:18:16

Modified files:
gcc: ChangeLog c-common.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.c-torture/compile: 20041102-1.c 

Log message:
PR c/18282
* c-common.c (handle_mode_attribute): Allow mode attribute
on enums when the mode is integral.

* gcc.c-torture/compile/20041102-1.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=2.2326.2.399.2.55&r2=2.2326.2.399.2.56
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-common.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.476.4.6.2.7&r2=1.476.4.6.2.8
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.3389.2.170.2.28&r2=1.3389.2.170.2.29
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/20041102-1.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=NONE&r2=1.1.2.1



-- 


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


[Bug c++/18639] poor out-of-memory handling

2004-11-24 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-24 
22:15 ---
But most of the time again any out of memory is usually a bug.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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


[Bug ada/18661] ACATS c974012 ICE calc_dfs_tree, at dominance.c:376

2004-11-24 Thread laurent at guerby dot net

--- Additional Comments From laurent at guerby dot net  2004-11-24 22:15 
---
This appeared betwen 20041115 23:24:06 CET (last PASS I have on this test) and
20041121 21:37:00 CET.

-- 


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


[Bug c++/18639] poor out-of-memory handling

2004-11-24 Thread igodard at pacbell dot net

--- Additional Comments From igodard at pacbell dot net  2004-11-24 22:12 
---
Thank you for the excellent explanation, but your explanation was redundant; I 
do (and did) understand why the nature of the problem is opaque. I'm not filing 
this bug because I don't understand; I'm filing a QOI report because the 
initial 
message wouldn't leave the average user with an understanding.

The actual compiler message in such a case would be much better if it contained 
a brief explanation of the situation like the one you've given here, including 
what the possibilities are, why you don't know, and what to do to narrow down 
the problem on a generic operating system. I am *not* saying you have to fix 
the 
OS; I do feel that you *should* tell the user everything that you know, 
including that you don't know.

This is a situation where message terseness is not a virtue. The existing 
message is confusing and unhelpful, even to will understand the problem and 
what 
to do. I suggested an alternative phrasing; but anything would be better so 
long 
as it explains:

1) was terminated by the OS
2) could have been out of a resource, killed by user request, did a nasty (i.e. 
segv), or something else OS dependent.
3) a generic suggestion for how to find out what was the actual cause
4) how to file a report is nothing else works.

gcc has a generic problem with its messages: they assume the user is 
intimiately 
familiar with the host, the language, and how the compiler works. This makes 
lousy messages for your actual user community.  This is another case of poor 
message QOI.

May I suggest that you circulate this report and its discussion among your 
collegues and see what they think about the general message philosophy and this 
message in particular. I'm giving up here and won't re-open this again, but the 
QOI issue won't go away just because I do.

Ivan

-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|WONTFIX |


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


[Bug target/17751] Undefined .LCTOC0 symbol

2004-11-24 Thread cvs-commit at gcc dot gnu dot org

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-11-24 
22:11 ---
Subject: Bug 17751

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-rhl-branch
Changes by: [EMAIL PROTECTED]   2004-11-24 22:11:00

Modified files:
gcc: ChangeLog 
gcc/config/rs6000: rs6000.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg: ppc64-toc.c 

Log message:
PR target/17751
* config/rs6000/rs6000.c (rs6000_file_start): Create toc section
for AIX ABI or ELF -fPIC.
(rs6000_emit_load_toc_table): Don't create toc_section here.
(rs6000_xcoff_file_start): Nor here.

* gcc.dg/ppc64-toc.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=2.2326.2.399.2.53&r2=2.2326.2.399.2.54
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.576.2.15.2.12&r2=1.576.2.15.2.13
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.3389.2.170.2.26&r2=1.3389.2.170.2.27
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/ppc64-toc.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=NONE&r2=1.1.2.1



-- 


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


[Bug tree-optimization/18650] Failure in tree-ssa/loop-2.c with powerpc64 with biarch

2004-11-24 Thread jgrimm2 at us dot ibm dot com

--- Additional Comments From jgrimm2 at us dot ibm dot com  2004-11-24 
22:08 ---
Ugh. Ignore my comments on add_to_evolution comment, I was sleepy when I wrote
up notes.  The dumps still may be useful though. 

-- 


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


[Bug other/18555] -isysroot is not documented

2004-11-24 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-24 
22:05 ---
So the only -isysroot is not documented now.

-- 
   What|Removed |Added

   Keywords||documentation
Summary|Need a command line switch  |-isysroot is not documented
   |to control gcc's include and|
   |libary finding mechanism|


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


[Bug tree-optimization/18664] [4.0 Regression] ACATS ICE cxaa010 expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:660

2004-11-24 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-24 
22:02 ---
And ppc-darwin.  This is the second most ICE I get on ppc-darwin.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|ada |tree-optimization
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-11-24 22:02:51
   date||
Summary|ACATS ICE cxaa010 expected  |[4.0 Regression] ACATS ICE
   |ssa_name, have var_decl in  |cxaa010 expected ssa_name,
   |verify_ssa, at tree-|have var_decl in verify_ssa,
   |ssa.c:660   |at tree-ssa.c:660
   Target Milestone|--- |4.0.0


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


[Bug ada/18663] ACATS ICE cc1221d expected integer_cst, have nop_expr in tree_int_cst_lt, at tree.c:3779

2004-11-24 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-24 
22:01 ---
Confirmed also on ppc-darwin.

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-11-24 22:01:24
   date||


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


[Bug ada/18664] New: ACATS ICE cxaa010 expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:660

2004-11-24 Thread laurent at guerby dot net
Present on both x86 and x86_64.

compiling cxaa010.adb
+===GNAT BUG DETECTED==+
| 4.0.0 20041122 (experimental) (i686-pc-linux-gnu) GCC error: |
| tree check: expected ssa_name, have var_decl in verify_ssa, at   |
|tree-ssa.c:660|

-- 
   Summary: ACATS ICE cxaa010 expected ssa_name, have var_decl in
verify_ssa, at tree-ssa.c:660
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P2
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent at guerby dot net
CC: gcc-bugs at gcc dot gnu dot org,laurent at guerby dot
net


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


[Bug tree-optimization/18662] [4.0 Regression] ACATS ICE c97114a verify_stmts failed / Statement marked for throw, but doesn't

2004-11-24 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-24 
22:00 ---
Does not happen on ppc-darwin, I wonder why.

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
  Component|ada |tree-optimization
Summary|ACATS ICE c97114a   |[4.0 Regression] ACATS ICE
   |verify_stmts failed /   |c97114a verify_stmts failed
   |Statement marked for throw, |/ Statement marked for
   |but doesn't |throw, but doesn't
   Target Milestone|--- |4.0.0


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


[Bug ada/18663] New: ACATS ICE cc1221d expected integer_cst, have nop_expr in tree_int_cst_lt, at tree.c:3779

2004-11-24 Thread laurent at guerby dot net
Present on both x86 and x86_64.

+===GNAT BUG DETECTED==+
| 4.0.0 20041122 (experimental) (i686-pc-linux-gnu) GCC error: |
| tree check: expected integer_cst, have nop_expr in tree_int_cst_lt,  |
|at tree.c:3779|
| Error detected at cc1221d.adb:173:5  |

-- 
   Summary: ACATS ICE cc1221d expected integer_cst, have nop_expr in
tree_int_cst_lt, at tree.c:3779
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P2
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent at guerby dot net
CC: gcc-bugs at gcc dot gnu dot org,laurent at guerby dot
net


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


[Bug ada/18661] ACATS c974012 ICE calc_dfs_tree, at dominance.c:376

2004-11-24 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-24 
21:58 ---
Confiremd, also on ppc-darwin.
http://gcc.gnu.org/ml/gcc-testresults/2004-11/msg00937.html

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-11-24 21:58:33
   date||
Summary|ACATS c974012 ICE   |ACATS c974012 ICE
   |calc_dfs_tree, at   |calc_dfs_tree, at
   |dominance.c:376 |dominance.c:376


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


[Bug ada/18662] New: ACATS ICE c97114a verify_stmts failed / Statement marked for throw, but doesn't

2004-11-24 Thread laurent at guerby dot net
Present on both x86 and x86_64

c97114a.adb: In function 'C97114A.T':
c97114a.adb:132: error: Statement marked for throw, but doesn't.
#   VUSE ;
D.1127_106 = S0D.924.ARRAYD.922[1]{lb: 1 sz: 8}.sD.816;

+===GNAT BUG DETECTED==+
| 4.0.0 20041122 (experimental) (i686-pc-linux-gnu) verify_stmts failed.   |
| Error detected at c97114a.adb:196:6  |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|

-- 
   Summary: ACATS ICE c97114a verify_stmts failed / Statement marked
for throw, but doesn't
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P2
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent at guerby dot net
CC: gcc-bugs at gcc dot gnu dot org,laurent at guerby dot
net


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


[Bug ada/18661] New: ACATS c974012 ICE calc_dfs_tree, at dominance.c:376

2004-11-24 Thread laurent at guerby dot net
Present both on x86 and x86_64

+===GNAT BUG DETECTED==+
| 4.0.0 20041122 (experimental) (i686-pc-linux-gnu) GCC error: |
| in calc_dfs_tree, at dominance.c:376 |
| Error detected at c974012.adb:165:5  |

-- 
   Summary: ACATS c974012 ICE calc_dfs_tree, at dominance.c:376
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P2
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent at guerby dot net
CC: gcc-bugs at gcc dot gnu dot org,laurent at guerby dot
net


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


[Bug ada/18660] New: ACATS spurious front-end error c432003.adb:134:21: too few discriminants given in constraint

2004-11-24 Thread laurent at guerby dot net
Present on x86 and x86_64, a priori ACATS code is valid, so no error should 
occur.
The code is quite complicated.

-- 
   Summary: ACATS spurious front-end error c432003.adb:134:21: too
few discriminants given in constraint
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P2
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent at guerby dot net
CC: gcc-bugs at gcc dot gnu dot org,laurent at guerby dot
net


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


[Bug tree-optimization/18659] [4.0 Regression] ACATS ICE in bug in tree-sra.c:1507 on x86 and ppc-darwin (6 FAIL)

2004-11-24 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-24 
21:44 ---
This might be fixed by:
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02030.html

But since I have not tried it yet and it looks like the build is broken, I 
don't know.

-- 


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


[Bug libfortran/18284] BACKSPACE broken

2004-11-24 Thread bdavis at gcc dot gnu dot org

--- Additional Comments From bdavis at gcc dot gnu dot org  2004-11-24 
21:42 ---
revised patch:

http://gcc.gnu.org/ml/fortran/2004-11/msg00189.html

-- 


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


[Bug tree-optimization/18659] [4.0 Regression] ACATS ICE in bug in tree-sra.c:1507 on x86 and ppc-darwin (6 FAIL)

2004-11-24 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-24 
21:39 ---
Confirmed, also fails on ppc-darwin.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|ada |tree-optimization
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-11-24 21:39:55
   date||
Summary|ACATS ICE in bug in tree-   |[4.0 Regression] ACATS ICE
   |sra.c:1507 on x86 (6 FAIL)  |in bug in tree-sra.c:1507 on
   ||x86 and ppc-darwin (6 FAIL)
   Target Milestone|--- |4.0.0


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


[Bug middle-end/15700] [4.0 Regression] [unit-at-a-time] Inlining problem leads to miscompilation of glibc

2004-11-24 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-24 
21:37 ---
Then mark the static function as used.  Again the problem is related to that 
gcc does not look into the 
string of alias period, except for when writting out the asm.
extern __typeof (foo_internal) work __attribute__ ((alias ("foo_internal")));

-- 
   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID


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


[Bug ada/18659] New: ACATS ICE in bug in tree-sra.c:1507 on x86 (6 FAIL)

2004-11-24 Thread laurent at guerby dot net
This happens on x86 but not on x86_64, 6 ACATS test have the following ICE:
+===GNAT BUG DETECTED==+
| 4.0.0 20041122 (experimental) (i686-pc-linux-gnu) GCC error: |
| in generate_element_copy, at tree-sra.c:1507 |
| Error detected at c32001e.adb:253:5  |

c32001e
c52011a
c64105b
c95086b
cd2b11a
cd2b11b

-- 
   Summary: ACATS ICE in bug in tree-sra.c:1507 on x86 (6 FAIL)
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P2
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent at guerby dot net
CC: gcc-bugs at gcc dot gnu dot org,laurent at guerby dot
net


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


[Bug middle-end/15700] [4.0 Regression] [unit-at-a-time] Inlining problem leads to miscompilation of glibc

2004-11-24 Thread hjl at lucon dot org

--- Additional Comments From hjl at lucon dot org  2004-11-24 21:31 ---
I am not sure why it shouldn't work. Given

static void
foo_internal ()
{
}

extern void (*foo) ();
void
xxx ()
{
  foo = &foo_internal;
}

void
bar ()
{
  foo_internal ();
}

Gcc 4.0 has no problems inlining foo_internal and emitting its body at the
same time. The only difference here is the address of foo_internal vs. an
external alias of foo_internal. In fact, gcc 4.0 does the right thing for

static void
foo_internal ()
{
}

extern void (*foo) ();
void
xxx ()
{
  foo = &foo_internal;
}

extern __typeof (foo_internal) work __attribute__ ((alias ("foo_internal")));

void
bar ()
{
  foo_internal ();
}

Gcc 4.0 has to do inlining and emitting body of a static functon anyway. How
to make it to work with external alias?

-- 
   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |


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


[Bug c++/18649] terminate called after throwing - IOT/Abort trap (core dumped)

2004-11-24 Thread askees at appfluent dot com

--- Additional Comments From askees at appfluent dot com  2004-11-24 21:29 
---
I downloaded 3.4.3 and the bug still exists.  So, it is not a duplicate of 
13391.  

-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|DUPLICATE   |
Version|3.4.2   |3.4.3


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


[Bug tree-optimization/18658] [4.0 Regression] ACATS ICE c330001 simplify-rtx.c:3780 (propagating a constant across a VIEW_CONVERT_EXPR)

2004-11-24 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-24 
21:27 ---
Confirmed.

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
  Component|ada |tree-optimization
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-11-24 21:27:20
   date||
Summary|ACATS ICE c330001 simplify- |[4.0 Regression] ACATS ICE
   |rtx.c:3780  (propagating a  |c330001 simplify-rtx.c:3780
   |constant across a   |(propagating a constant
   |VIEW_CONVERT_EXPR)  |across a VIEW_CONVERT_EXPR)
   Target Milestone|--- |4.0.0


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


[Bug ada/18658] New: ACATS ICE c330001 simplify-rtx.c:3780 (propagating a constant across a VIEW_CONVERT_EXPR)

2004-11-24 Thread laurent at guerby dot net
Andrew Pinski has some comments on the issue, see

http://gcc.gnu.org/ml/gcc/2004-11/msg00730.html

+===GNAT BUG DETECTED==+
| 4.0.0 20041122 (experimental) (i686-pc-linux-gnu) GCC error: |
| in simplify_gen_subreg, at simplify-rtx.c:3780   |
| Error detected at c330001_0.adb:20:1 |

Present on both x86 and x86_64.

-- 
   Summary: ACATS ICE c330001 simplify-rtx.c:3780  (propagating a
constant across a VIEW_CONVERT_EXPR)
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P2
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent at guerby dot net
CC: gcc-bugs at gcc dot gnu dot org,laurent at guerby dot
net


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


[Bug ada/18657] ACATS c61008a fold-const.c:1980 ICE on x86_64, works on x86

2004-11-24 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-24 
21:22 ---
This works on ppc-darwin also:
http://gcc.gnu.org/ml/gcc-testresults/2004-11/msg00937.html

Maybe this is 64bit related.

-- 
   What|Removed |Added

 GCC target triplet||x86_64-linux-gnu


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


[Bug ada/18657] New: ACATS c61008a fold-const.c:1980 ICE on x86_64, works on x86

2004-11-24 Thread laurent at guerby dot net
+===GNAT BUG DETECTED==+
| 4.0.0 20041122 (experimental) (x86_64-unknown-linux-gnu) GCC error:  |
| in fold_convert, at fold-const.c:1980|
| Error detected at c61008a.adb:266:5  |

-- 
   Summary: ACATS c61008a fold-const.c:1980 ICE on x86_64, works on
x86
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P2
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent at guerby dot net
CC: gcc-bugs at gcc dot gnu dot org,laurent at guerby dot
net


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


[Bug ada/18455] incorrect execution

2004-11-24 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-24 
21:13 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-11-24 21:13:39
   date||


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


[Bug ada/18454] Illegal program not detected, RM 10.1.5(4), 8.1(16)

2004-11-24 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-24 
21:12 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||accepts-invalid
   Last reconfirmed|-00-00 00:00:00 |2004-11-24 21:12:30
   date||


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


[Bug ada/18453] Legal instantiation rejected; illegal instantiation accepted

2004-11-24 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-24 
21:09 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||accepts-invalid, rejects-
   ||valid
   Last reconfirmed|-00-00 00:00:00 |2004-11-24 21:09:38
   date||


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


[Bug ada/17318] Put_Line (X'Img (Index)), index ignored

2004-11-24 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-24 
21:06 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-11-24 21:06:03
   date||


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


[Bug c++/17473] [3.3/3.4/4.0 Regression] typedef redefinition in struct is accepted

2004-11-24 Thread mmitchel at gcc dot gnu dot org


-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |mark at codesourcery dot com
   |dot org |
 Status|NEW |ASSIGNED


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


[Bug target/18189] [3.3 regression] __fixunsdfdi problem on m68k

2004-11-24 Thread schwab at suse dot de

--- Additional Comments From schwab at suse dot de  2004-11-24 20:57 ---
It looks like a linker bug. 

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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


[Bug ada/17960] GNAT.Sockets Stream feature not working properly

2004-11-24 Thread laurent at guerby dot net

--- Additional Comments From laurent at guerby dot net  2004-11-24 20:54 
---
Works for me when I change a bity the code as follows:

declare
Message : String (1..5);
begin
String'Read (Channel, Message);
Ada.Text_IO.Put_Line (Message);
end;

I believe the behaviour of the original code is not very well defined
per stream and socket semantics.

-- 


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


[Bug ada/17960] GNAT.Sockets Stream feature not working properly

2004-11-24 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-24 
20:41 ---
This does not crash for me on ppc-darwin on the mainline but I don't really 
know what is the correct 
behavior for this test, could one of the Ada people look at this to check to 
see if works for them on 
i686-pc-linux-gnu?

-- 


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


[Bug ada/15807] Legal program runs incorrectly, RM 3.10.2(3,29)

2004-11-24 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-24 
20:37 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-11-24 20:37:48
   date||


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


[Bug ada/15102] Building shared libgnat may fail linking non-PIC object files

2004-11-24 Thread schwab at suse dot de

--- Additional Comments From schwab at suse dot de  2004-11-24 20:34 ---
It happened recently for me on ia64. 

-- 
   What|Removed |Added

 CC||schwab at suse dot de


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


[Bug middle-end/15700] [4.0 Regression] [unit-at-a-time] Inlining problem leads to miscompilation of glibc

2004-11-24 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-24 
20:32 ---
*** Bug 18656 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||hjl at lucon dot org


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


[Bug c/18656] [4.0 regression]: alias attribute stops working with -O2 and above

2004-11-24 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-24 
20:32 ---
This is a dup of bug 15700, also a glibc bug, see 
.

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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


[Bug c/18656] New: [4.0 regression]: alias attribute stops working with -O2 and above

2004-11-24 Thread hjl at lucon dot org
On Linux/ia32, Linux/x86_64 and Linux/ia64, I got

[EMAIL PROTECTED] alias]$ cat foo.c
static void
foo_internal ()
{
}
extern __typeof (foo_internal) foo __attribute__ ((alias ("foo_internal")));
void
bar ()
{
  foo_internal ();
}
[EMAIL PROTECTED] alias]$ /usr/gcc-4.0/bin/gcc -c foo.c -O2
[EMAIL PROTECTED] alias]$ nm foo.o
 T bar
 U foo_internal

-- 
   Summary: [4.0 regression]: alias attribute stops working with -O2
and above
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
CC: gcc-bugs at gcc dot gnu dot org


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


[Bug ada/15156] gnatlink does not link due to undefined symbol _gnat__strings_E

2004-11-24 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-24 
20:23 ---
Yes this is fixed. Now thanks for fixing it.

-- 
   What|Removed |Added

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


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


[Bug rtl-optimization/18237] [4.0 regression] ICE in gen_lowpart_general, at rtlhooks.c:58

2004-11-24 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-24 
20:21 ---
in gen_lowpart_general, at rtlhooks.c:58
is a diffrent failure which might have been introduced between the time James 
and I tried to bootstrap.

And now the problem is an rtl problem.

-- 
   What|Removed |Added

  Component|tree-optimization   |rtl-optimization
   Keywords||build
Summary|[4.0 regression]  tree  |[4.0 regression]  ICE in
   |check: expected ssa_name,   |gen_lowpart_general, at
   |have var_decl in verify_ssa |rtlhooks.c:58


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


[Bug ada/17566] Gnatxref formatting

2004-11-24 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-24 
20:18 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-11-24 20:18:17
   date||


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


[Bug ada/14416] [3.4/4.0 Regression] Gnat does not compile valid code

2004-11-24 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-24 
20:16 ---
Fixed now on the mainline.

-- 
   What|Removed |Added

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


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


[Bug tree-optimization/18237] [4.0 regression] tree check: expected ssa_name, have var_decl in verify_ssa

2004-11-24 Thread debian-gcc at lists dot debian dot org

--- Additional Comments From debian-gcc at lists dot debian dot org  
2004-11-24 20:16 ---
still seeing the ICE with 20041124 on powerpc-linux:

  Matthias

[...]
../../xgcc -B../../ -c -g -O2 -fPIC  -W -Wall -gnatpg  s-stratt.adb -o
s-stratt.o
+===GNAT BUG DETECTED==+
| 4.0.0 20041124 (experimental) (powerpc-unknown-linux-gnu) GCC error: |
| in gen_lowpart_general, at rtlhooks.c:58 |
| Error detected at s-stratt.adb:671:1 |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases, 
so please double check that the problem can still 
be reproduced with the set of files listed.



raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:376
make[7]: *** [s-stratt.o] Error 1

-- 


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


  1   2   3   >