We noticed that __builtin_constant_p() sometimes fails to recognise a function
that always returns 0 as being constant.
The code snippet below shows that gcc can work it out if we force the
evaluation into an inline function. It looks like this postpones the evaluation
of __builtin_constant_p to a
--- Comment #15 from aoliva at gcc dot gnu dot org 2006-03-17 06:27 ---
I failed to note this PR when I checked in
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01039.html as revision 112170,
sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8047
--- Comment #17 from aoliva at gcc dot gnu dot org 2006-03-17 06:25 ---
I failed to note this PR when I checked in
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01039.html as revision 112170,
sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23602
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-03-17 01:12
---
Subject: Re: [4.2 Regression]: Gcc generates unaligned access
On Mar 16, 2006, at 8:06 PM, schwab at suse dot de wrote:
> --- Comment #17 from schwab at suse dot de 2006-03-17 01:06
> ---
> PPC does no
On Mar 16, 2006, at 8:06 PM, schwab at suse dot de wrote:
--- Comment #17 from schwab at suse dot de 2006-03-17 01:06
---
PPC does not trap on unaligned integer load and store.
That is not true, it traps on some. It all depends on the hardware.
Please don't say it does not trap on n
--- 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
--- 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 #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 a
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 STR
--- 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
--- 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 this
--- 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 #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 re
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 gener
--- 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.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- 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 #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 #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 #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 pro
--- 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 #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 #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 g
--- 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 #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=gcc&view=rev&rev=112154
Log:
PR target/26189
Backport from mainline.
* inc
--- 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 --with-ld=XX
--- 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
--with-local-prefix=XX
--- 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 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 changed
--- 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 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 |Added
--- 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=gcc&view=rev&rev=112152
Log:
PR middle-end/26379
Backport from mainline.
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):
HashTable::FactoryEntry>
Factory::sFactoryTable ;
The following lines do compile (but see cavea
--- 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
--- 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 #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 w
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. Func
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26721
--- 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
> http://gcc.gnu.org/ml/gcc-patches/2006-03/ms
--- 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 #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=gcc&view=rev&rev=112147
Log:
2006-03-16 Roger Sayle <[EMAIL PROTECTED]>
Daniel S
--- 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 #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
Sta
--- 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=gcc&view=rev&rev=112143
Log:
PR libgcj/26706:
* aclocal.m4, configure: Rebui
--- 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 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
http://gcc.gnu.org/ml/gcc-patches/20
--- 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=gcc&view=rev&rev=112142
Log:
PR libgcj/26706:
* aclocal.m4, configure: Rebui
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|c |target
--- 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=11060&action=view)
The jbig.i file that causes ICE
This is a part of jbigkit.tar.gz library for JBIG pictures.
--
http://gcc.gnu.org/
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 0x2
--- 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):
s
--- 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 ha
--- 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 #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 #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 #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, +,
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- 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
--- 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=gcc&view=rev&rev=112141
Log:
PR target/25917
Backport from mainline.
* con
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 to
--- 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=gcc&view=rev&rev=112140
Log:
PR target/25917
Backport from mainline.
* con
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 void
--- 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
--- 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 dot
--- 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 #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:24 ---
Confirmed, ivopts is causing this one.
--
pinskia 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
int table[32][256];
int main(void)
{
int i, j;
for (i = 0
--- 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
AssignedTo|u
--- 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=gcc&view=rev&rev=112136
Log:
PR middle-end/21781
* real.c (real_from_string):
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; root:xnu-792.6.56.obj~1/R
--- 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
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 PROTECTED]:
--- 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
--- 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=11059&action=view)
Original LAPACK source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26717
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.
Ch
--- 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:
:
0: 27bd8010addiu sp,sp,-32752
4: ffbe7fe0sd s8,32736(sp)
8
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 fo
--- 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=11058&action=view)
fpu configuration file for mactel, uses apple supplied fenv.h
For clearing this uses feclearexcept (FE_ALL_EXCEPT)
For
--- 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 #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 /gcc/auto-host.h #define HAVE_SYS_RESOURCE_H 1 makes
build pass this point where it failed.
This was set to #undef de
--- 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
---
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 #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
Status|UNCON
--- Comment #5 from mtodorov at alu dot hr 2006-03-16 13:35 ---
Changing /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 not found i
--- 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 #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 #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 #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
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 #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.
-
--- 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 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
config/fpu-
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
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) run
--- 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=11057&action=view)
generated gcc/ggc-common.i with make options + -save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26711
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 #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
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- 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
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/
-B/usr/lo
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
1 - 100 of 105 matches
Mail list logo
