--- Comment #13 from jb at gcc dot gnu dot org 2006-03-16 08:30 ---
(In reply to comment #12)
The attached C program fails on IA64 because the printf rounds the last digit
of MIN_LDBL down when it prints it and so it can't be read back in. The basic
problem is that LDBL_MAX and
--- Comment #5 from paul dot richard dot thomas at cea dot fr 2006-03-16
08:38 ---
Yes, it is not quite as spectacular as before but present nonetheless. By
comparing pointer and non-pointer cases, I measure an overhead of 12 +/- 7 ns
on a 2.4Ghz PIV. I have no idea why the error is
--- Comment #5 from bkoz at gcc dot gnu dot org 2006-03-16 08:39 ---
glibcxx_gnu_ld_version is only set when building natively, but used when
--with-gnu-ld which implies --enable-symvers=gnu.
This is the bug. Unfortunately, GLIBCXX_CHECK_LINKER_FEATURES is a native-only
test.
--- Comment #4 from bkoz at gcc dot gnu dot org 2006-03-16 08:40 ---
I'm going to check this in to libstdcxx_so_7-branch. It will be easier to test
there.
Please try to make a self-contained testcase for this, ie one file, no make
file, etc.
-benjamin
--
--- Comment #6 from ralf dot corsepius at rtems dot org 2006-03-16 09:06
---
(In reply to comment #5)
Unfortunately, GLIBCXX_CHECK_LINKER_FEATURES is a native-only test.
Could you explain why it is native-only?
AFAIS, it tries to run the linker, which is a build-host tool at this
I am unable to compile gcc 3.3.6 downloaded from mirror ftp.gwdg.de.
./configure make -j2 triggers the following errors:
f/com.c: At top level:
f/com.c:11080: error: conflicting types for ?ffecom_gfrt_basictype?
f/com.h:236: error: previous declaration of ?ffecom_gfrt_basictype? was here
This
For the released 4.1.0, building runtime/compile_options.c (and others) fail on
i386 os x with a non-relocatable subtraction error. A simple short term
workaround is to use -fno-common when building
Output from cut and pasted line:
/Users/Shared/gcc/./gcc/xgcc -B/Users/Shared/gcc/./gcc/
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-16 10:50 ---
Unfortunately you are late and both the 3.3 and the 3.4 series have been
dicontinued ;) So, this is at least fixed in 4.0.0.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from Sven dot Rebhan at gmail dot com 2006-03-16 11:44
---
I know that i am to late, but I (and probably others) depend on this special
version (for policy reasons), so I wanted to share my knowledge with others. :)
EOT
--
Hardware: apple powerpc dual g4 867 MHz
OS: Mac OS X 10.2.8 Jaguar
Kernel: Darwin 6.8
Build platform: apple's GCC version 1151, based on gcc version 20020420 from
Dec2002DevToolsCD.dmg
odcctools-20060226
GCC version:4.2.0-20060311,
--- Comment #1 from mtodorov at alu dot hr 2006-03-16 12:26 ---
Created an attachment (id=11057)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11057action=view)
generated gcc/ggc-common.i with make options + -save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26711
All attempts to run code compiled with gfortran fail if there is a floating
point print. This seems to be
due to a floating point underflow exception being invoked.
cat test.f
program test
real a
a = 10.0
print *,a
stop
end
gdb stack trace follows:
(gdb)
Allocation of stack frames is limited to a maximum of 32k, regardless of how
much memory is needed by local variables. Addressing of local variables, on the
other hand, is also possible beyond the 32k limit. This can lead to
unpredictable application behavior. No compiler warning is generated. See
--- Comment #1 from ccb at dl dot ac dot uk 2006-03-16 12:35 ---
I have played with this some more, and it seems to be an floating point
underflow. Default configure results in FPU_HOST_HEADER=config/fpu-387.h,
however, Darwin on i386 uses a fenv.h that is similar to that in
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-16 12:38 ---
Please try 4.0.3 or 4.1.0, the 3.4 series is no longer maintained (you may turn
to your system provider though).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-16 13:04 ---
Fixed in 4.2.0, the port is fundamentally borken before then.
This one problem was fixed by:
2006-01-11 Andrew Pinski [EMAIL PROTECTED]
* config/i386/darwin.h (SUBTARGET_ENCODE_SECTION_INFO): Define.
--
Somebody in c.l.c++.m[1] dug out an overlooked clause in 12.2/5
[class.temporary], namely that A temporary bound to a reference member in a
constructor's ctor-initializer (12.6.2) persists until the constructor exists
The following piece of code should therefore print:
===
A()
A()
B()
~A()
~A()
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-16 13:17 ---
Hmm, I wonder if this is related to:
http://lists.apple.com/archives/Darwin-dev/2006/Mar/msg00102.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26712
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-16 13:24 ---
*** This bug has been marked as a duplicate of 13982 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-16 13:24 ---
*** Bug 26711 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-16 13:32 ---
(In reply to comment #1)
I have played with this some more, and it seems to be an floating point
underflow. Default configure results in FPU_HOST_HEADER=config/fpu-387.h,
however, Darwin on i386 uses a fenv.h
--- Comment #5 from mtodorov at alu dot hr 2006-03-16 13:35 ---
Changing build_dir/gcc/auto-host.h #define HAVE_SYS_RESOURCE_H 1 makes build
pass this point where it failed.
This was set to #undef despite having the include in /usr/incude/sys/resource.h
I guess configure script has
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-16 13:39 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Hi all,
I've been trying upgrade our C environment on our solaris boxes to GCC4.1
Currently we're using GCC 3.4.2 from Sun Freeware's online packages.
$ gcc --version
gcc (GCC) 3.4.2
...
Using the same ./configure options on 4 clean sparc Solaris systems (running
2.6, 7, 8 and 9) systems I find
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-16 14:11 ---
Not a GCC bug as explained by Joseph.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from mtodorov at alu dot hr 2006-03-16 14:12 ---
Subject: Re: Compilation breaks in gcc/genattrtab.c on
Mac OS X 10.2.8 on G4 with odcctools
Changing build_dir/gcc/auto-host.h #define HAVE_SYS_RESOURCE_H 1 makes
build pass this point where it failed.
This was set to
--- Comment #7 from rakdver at gcc dot gnu dot org 2006-03-16 14:29 ---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01019.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ccb at dl dot ac dot uk 2006-03-16 14:30 ---
Created an attachment (id=11058)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11058action=view)
fpu configuration file for mactel, uses apple supplied fenv.h
For clearing this uses feclearexcept (FE_ALL_EXCEPT)
For
Compiling and running the code below with gfortran 4.1 or mainline
produces the output
foo1
foo2
foo2
instead of the correct output
foo1
foo1
foo2
This occurs with 4.1 (release), 4.1.1 and mainline.
4.0.3 (prerelease) produces the correct output.
module mod1
implicit none
interface
--- Comment #2 from christoph dot stueckjuergen at siemens dot com
2006-03-16 15:08 ---
I tried 4.1.0. The assembly code looks slightly different, but the problem
remains the same:
main:
0: 27bd8010addiu sp,sp,-32752
4: ffbe7fe0sd s8,32736(sp)
Hi,
compiling LAPACK with -O -ffast-math leads to an ICE
in LAPACK's csptri.f and csytri.f:
% gfortran -O -ffast-math -c csptri.f
csptri.f: In function 'csptri':
csptri.f:1: internal compiler error: in find_lattice_value, at
tree-complex.c:133
The same error is encountered in the other file.
--- Comment #1 from anlauf at gmx dot de 2006-03-16 15:45 ---
Created an attachment (id=11059)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11059action=view)
Original LAPACK source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26717
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-16 15:59 ---
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26717
rusinante: gcc -v
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.4.4 [FreeBSD] 20050518
rusinante:
rusinante: uname -a
FreeBSD ws3-plovdiv.digsys.bg 6.1-PRERELEASE FreeBSD
6.1-PRERELEASE #0: Fri Mar 10 16:53:41 EET 2006
[EMAIL
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-16 16:21 ---
Reduced C testcase:
_Complex float f(_Complex float a, _Complex float b)
{
_Complex float c = a/a;
return c/ b;
}
--
The problem is that fold is folding a/a to 1.0 but not the complex version.
--
pinskia
Building gcc V4.1.0 fails on an Apple Power G5 when building libstdc++.
Environment
Machine: Apple Power G5 (quad 2.5 Ghz), Mac OS X 10.4.4
uname -a output:-
Darwin epx-paprika1.imp.univie.ac.at 8.4.0 Darwin Kernel Version 8.4.0: Tue Jan
3 18:22:10 PST 2006;
--- Comment #2 from sayle at gcc dot gnu dot org 2006-03-16 16:34 ---
Subject: Bug 21781
Author: sayle
Date: Thu Mar 16 16:34:05 2006
New Revision: 112136
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112136
Log:
PR middle-end/21781
* real.c (real_from_string):
--- Comment #1 from tromey at gcc dot gnu dot org 2006-03-16 18:19 ---
Testing a patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
System info: Debian Unstable, x86 (Transmeta Crusoe TM5800)
The following program produces different output when compiled with and without
optimisations. This didn't occur with gcc 4.0.3, it seems to be new with 4.1.0.
#include stdio.h
int table[32][256];
int main(void)
{
int i, j;
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-16 18:24 ---
Confirmed, ivopts is causing this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-16 18:27 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-16 18:29 ---
This is interesting as this worked for me on powerpc-darwin7.9.0 just fine. Do
you have a GNU binutils nm in your path?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26718
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-03-16 18:31
---
Pretty weird indeed. What's the bootstrap compiler on the Solaris 8 machine?
Is it the same as on the other machines? Could you try a C-only bootstrap with
it and with another one?
--
ebotcazou at gcc
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-03-16 18:33 ---
Hmm, this source works for me just fine on powerpc-darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26678
In the following test, gcj fails to generate an access method for the private
static members of type char, byte, and short, although it does generate the
access method for the private static members of type int and Object.
class AccessTest {
public interface Foo {
public
--- Comment #7 from sje at gcc dot gnu dot org 2006-03-16 18:40 ---
Subject: Bug 25917
Author: sje
Date: Thu Mar 16 18:40:08 2006
New Revision: 112140
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112140
Log:
PR target/25917
Backport from mainline.
*
With gcc version 4.2.0 20060316 (experimental) [trunk revision 112138 clean],
I got
lt-gcj-dbtool(10892): unaligned access to 0x6fff9d63,
ip=0x217a02e0
lt-gcj-dbtool(10892): unaligned access to 0x6fff9d6b,
ip=0x217a0301
lt-gcj-dbtool(10892): unaligned access
--- Comment #8 from sje at gcc dot gnu dot org 2006-03-16 18:42 ---
Subject: Bug 25917
Author: sje
Date: Thu Mar 16 18:42:18 2006
New Revision: 112141
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112141
Log:
PR target/25917
Backport from mainline.
*
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-16 18:42 ---
self contained testcase?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26721
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from rakdver at gcc dot gnu dot org 2006-03-16 18:50 ---
This is a scev analysis problem; on code
D.2160_17 = (signed char) j_15;
D.2161_18 = (int) D.2160_17;
it says D.2161_18 = {0, +, 1}; however, since it wraps at 128 to -127, this is
not correct -- (int) {0, +,
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-03-16 18:50 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from rakdver at gcc dot gnu dot org 2006-03-16 18:51 ---
More precisely, the correct chrec would be
(int) (char) {0,+,1}
since we assume signed chrecs do not overflow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26719
--- Comment #2 from perrin at msli dot com 2006-03-16 18:58 ---
Thanks, those new tools worked.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26708
--- Comment #4 from kargl at gcc dot gnu dot org 2006-03-16 18:58 ---
It looks like Andrew has found your problem. I will, however,
suggest that you reconsider using --fast-math with gfortran.
One of my codes works correctly without --fast-math, but it
will generate NaN's with it. I
--- Comment #2 from hjl at lucon dot org 2006-03-16 18:58 ---
The testcases are in gcc testsuites. I got tens of those. Pick one from
lt-gcj-dbtool(10892):
strncpy-chk.x1(16065):
strncpy-chk.x2(16153):
strncpy-chk.x3(16260):
strncpy-chk.x4(16419):
PR9577(17600):
strncpy-chk.x2(23626):
Hardware: Xeon 3.2 GHz dual-core
OS: Linux Debian sarge 2.6.14.3-grsec #1 SMP
Attachment with .i follows.
gcc -O2 -W -march=pentium3 -mmmx -msse -msse2 -I../libjbig -c -o jbig.o
jbig.c
jbig.c: In function `encode_sde':
jbig.c:1474: error: unrecognizable insn:
(insn:HI 3480 3479 3127 20
--- Comment #1 from mtodorov at alu dot hr 2006-03-16 19:05 ---
Created an attachment (id=11060)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11060action=view)
The jbig.i file that causes ICE
This is a part of jbigkit.tar.gz library for JBIG pictures.
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|c |target
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-16 19:08 ---
Subject: Bug 26706
Author: tromey
Date: Thu Mar 16 19:08:07 2006
New Revision: 112142
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112142
Log:
PR libgcj/26706:
* aclocal.m4, configure:
--- Comment #3 from hjl at lucon dot org 2006-03-16 19:08 ---
It may be related to
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01001.html
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01000.html
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00999.html
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-16 19:09 ---
Can you give output of gcc -v?
This works just fine with FSF's GCC 3.3.3 and 3.4.0 and 4.1.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26722
--- Comment #3 from tromey at gcc dot gnu dot org 2006-03-16 19:12 ---
Subject: Bug 26706
Author: tromey
Date: Thu Mar 16 19:12:29 2006
New Revision: 112143
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112143
Log:
PR libgcj/26706:
* aclocal.m4, configure:
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-16 19:15 ---
I checked in the fix.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from hjl at lucon dot org 2006-03-16 19:17 ---
BTW, I saw it on RHEL 4 U3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26721
--- Comment #3 from sayle at gcc dot gnu dot org 2006-03-16 19:47 ---
Subject: Bug 18259
Author: sayle
Date: Thu Mar 16 19:47:19 2006
New Revision: 112147
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112147
Log:
2006-03-16 Roger Sayle [EMAIL PROTECTED]
Daniel
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-16 20:18 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2006-03-16 20:32
---
(In reply to comment #3)
It may be related to
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01001.html
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01000.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26721
Almost verbatim from the standard:
/// 1. Objects with static storage duration are destroyed
///and functions registered by calling atexit are
///called. Objects with static storage duration are
///destroyed in the reverse order of the completion
///of their constructor.
/// 2.
--- Comment #3 from mtodorov at alu dot hr 2006-03-16 21:05 ---
Subject: Re: ICE in extract_insn, at recog.c:2175
Of course, I should have done it in the first place:
[EMAIL PROTECTED]:~/jbigkit/libjbig$ gcc -v
Reading specs from /usr/lib/gcc-lib/x86_64-linux/3.3.5/specs
Configured
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-16 21:28 ---
Can you give the output of gcc -v?
This is the output I get:
FIRST::FIRST()
SECOND::SECOND()
whatever
@post_exit
SECOND::~SECOND()
FIRST::~FIRST()
@pre_exit
--enable-__cxa_atexit is required to get this behavior,
--- Comment #1 from pault at gcc dot gnu dot org 2006-03-16 21:31 ---
Yes indeed. It occurs for 4.1 and 4.2 but NOT for 4.0.
I have put this to severity major because we must get interfaces right.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed
I've seen other posts asking a similar question, but the solution continues to
evade me.
I have a line of code that compiles and runs as designed with MSVC but not
under g++ 3.4.2 (mingw-special):
HashTableFactoryAbstractProductUnitTest::FactoryEntry
--- Comment #6 from sayle at gcc dot gnu dot org 2006-03-16 21:33 ---
Subject: Bug 26379
Author: sayle
Date: Thu Mar 16 21:33:38 2006
New Revision: 112152
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112152
Log:
PR middle-end/26379
Backport from mainline.
--- Comment #2 from fang at csl dot cornell dot edu 2006-03-16 21:39
---
Looks like my problem from PR 26385, but I was trying to use odcctools' nm.
Is GNU binutils' nm also suitable?
--
fang at csl dot cornell dot edu changed:
What|Removed
--- Comment #2 from sje at cup dot hp dot com 2006-03-16 21:45 ---
I am resolving this bug as fixed with the same resolution as PR 24476, since
the change I made for PR 24476 also fixes this failure. See PR 24476 for more
information on the problem fix. Basically, you have to use the
--- Comment #2 from pault at gcc dot gnu dot org 2006-03-16 21:53 ---
Annoyingly, the bug has been introduced by one of my patches:
http://gcc.gnu.org/ml/fortran/2006-01/msg00424.html
It was the bit for PR25070.
I'll see what I can do.
Paul
--
pault at gcc dot gnu dot org
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-16 21:54 ---
(In reply to comment #2)
Looks like my problem from PR 26385, but I was trying to use odcctools' nm.
Is GNU binutils' nm also suitable?
I have never used the GNU binutils or even odcctools nm which is why I asked.
--- Comment #2 from ivan at sierra-da dot com 2006-03-16 21:56 ---
gcc -v:
Reading specs from
/project/tools/linux_i686_2.3.2-2005-08-31-17.44.37/stow/gcc-3.3.3/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/specs
Configured with: XXX/gcc-3.3.3/configure --prefix=XXXgcc-3.3.3
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-16 22:00 ---
(In reply to comment #2)
gcc -v:
Configured with: XXX/gcc-3.3.3/configure --prefix=XXXgcc-3.3.3
--with-local-prefix=XXX --enable-languages=c,c++
--with-libiconv-prefix=XXX/gcc-3.3.3 --with-gnu-ld
--- Comment #5 from sje at gcc dot gnu dot org 2006-03-16 22:02 ---
Subject: Bug 26189
Author: sje
Date: Thu Mar 16 22:02:43 2006
New Revision: 112154
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112154
Log:
PR target/26189
Backport from mainline.
*
--- Comment #6 from sje at cup dot hp dot com 2006-03-16 22:03 ---
Fixed on 4.0 line for 4.0.4, 4.1 line for 4.1.1 and on ToT for 4.2.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #1 from pcarlini at suse dot de 2006-03-16 22:17 ---
Working on it.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #6 from sje at cup dot hp dot com 2006-03-16 22:25 ---
Here is a cut down test case, I guess GCC is trying to map the strncpy into an
integer move without taking alignment into account.
extern char *strncpy (char *, const char *, __SIZE_TYPE__);
int main()
{
const char
--- Comment #7 from sje at cup dot hp dot com 2006-03-16 23:06 ---
It looks to me like this is due to Richard Guenther's patch at:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00737.html
When I removed the non-structure part of this patch the problem went away.
specifically I changed
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-03-16 23:09 ---
(In reply to comment #7)
It looks to me like this is due to Richard Guenther's patch at:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00737.html
When I removed the non-structure part of this patch the problem
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-03-16 23:10 ---
Why is ia64-linux-gnu setting STRICT_ALIGNMENT to true even though it works by
default? Yes it is slower but there is setting for that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26721
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-03-16 23:13
---
(In reply to comment #6)
Here is a cut down test case, I guess GCC is trying to map the strncpy into an
integer move without taking alignment into account.
This is all dead code, this testcase does nothing for
--- Comment #11 from sje at cup dot hp dot com 2006-03-16 23:16 ---
I compiled the test case at -O1 on IA64 HP-UX to get the bus error due to the
unaligned access. IA64 HP-UX does require STRICT_ALIGNMENT.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26721
--- Comment #12 from schwab at suse dot de 2006-03-16 23:37 ---
(In reply to comment #9)
Why is ia64-linux-gnu setting STRICT_ALIGNMENT to true even though it works by
default?
prctl --unaligned=signal will make it generate bus errors.
--
On Mar 16, 2006, at 6:37 PM, schwab at suse dot de wrote:
--- Comment #12 from schwab at suse dot de 2006-03-16 23:37
---
(In reply to comment #9)
Why is ia64-linux-gnu setting STRICT_ALIGNMENT to true even though it
works by
default?
prctl --unaligned=signal will make it
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-03-16 23:54
---
Subject: Re: [4.2 Regression]: Gcc generates unaligned access
On Mar 16, 2006, at 6:37 PM, schwab at suse dot de wrote:
--- Comment #12 from schwab at suse dot de 2006-03-16 23:37
---
(In reply
--- Comment #7 from roger at eyesopen dot com 2006-03-17 00:17 ---
I've now committed this patch (as approved by Mark) to the 4.0 branch for
Jakub, so this PR can be closed.
--
roger at eyesopen dot com changed:
What|Removed |Added
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-03-17 00:22
---
Now ia64-hpux is a different story.
Maybe the real question is why DSE/DCE is not deleting the dead code which it
is?
But for future reference the docs for STRICT_ALIGNMENT is:
@defmac STRICT_ALIGNMENT
Define
--- Comment #15 from schwab at suse dot de 2006-03-17 00:37 ---
Both alpha and sparc can emulate unaligned accesses, and both set
STRICT_ALIGNMENT.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26721
On Mar 16, 2006, at 7:37 PM, schwab at suse dot de wrote:
--- Comment #15 from schwab at suse dot de 2006-03-17 00:37
---
Both alpha and sparc can emulate unaligned accesses, and both set
STRICT_ALIGNMENT.
And PPC can emulate unalgined access (and does by default) and it
sets
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-03-17 00:40
---
Subject: Re: [4.2 Regression]: Gcc generates unaligned access
On Mar 16, 2006, at 7:37 PM, schwab at suse dot de wrote:
--- Comment #15 from schwab at suse dot de 2006-03-17 00:37
---
Both alpha
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-17 01:03 ---
This works for me in 3.3.3 and 3.3.6 so closing as works for me.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from schwab at suse dot de 2006-03-17 01:06 ---
PPC does not trap on unaligned integer load and store. Neither ia64 nor alpha
nor sparc can do unaligned load and store in hardware.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26721
1 - 100 of 105 matches
Mail list logo
