--- Comment #3 from schwab at suse dot de 2007-02-15 09:40 ---
> It is not a small command line passed to gcc but one enormous command line
> passed to /bin/bash.
This is wrong. The executed command is gcc, and it only needs 500 bytes of
argument space.
--
http://gcc.gnu.org/bugzi
--- Comment #8 from burnus at gcc dot gnu dot org 2007-02-15 09:45 ---
The link to c.l.fortran is:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/23aa68ecce460e50
Richard Main: "The pointer assignment is ok. I [...] don't have
time to adequately peruse the rest of
--- Comment #9 from sfilippone at uniroma2 dot it 2007-02-15 09:55 ---
(In reply to comment #8)
> The link to c.l.fortran is:
> http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/23aa68ecce460e50
>
> Richard Main: "The pointer assignment is ok. I [...] don't have
> ti
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-02-15 09:56 ---
Confirmed:
#1 0x00cffee3 in vect_get_vec_def_for_stmt_copy (
dt=vect_induction_def, vec_oprnd=0x2abeb1648480)
at /space/rguenther/src/svn/trunk/gcc/tree-vect-transform.c:901
901 gcc_assert (
--- Comment #2 from krischik at users dot sourceforge dot net 2007-02-15
10:07 ---
<<
and you should use a GNAT version older than the version you are building
indeed.
>>
For Linux that would be OK - just use the compiler from the distribution. But
for "pentium4-pc-mingw32msv" it is no
--- Comment #2 from krischik at users dot sourceforge dot net 2007-02-15
10:09 ---
And exactly which older, working mingw version would you suggest if
GNAT GPL 2006 (20060522-34)
Copyright 1996-2006, Free Software Foundation, Inc.
is not old enough.
Martin
--
krischik at users d
--- Comment #3 from charlet at gcc dot gnu dot org 2007-02-15 10:16 ---
Any version from the FSF sources than the version you're trying
to build should do (e.g. GCC 3.4, 4.0, 4.1).
Anyway, you do not need to be a maintainer do submit and commit patches,
so if this issue is blocking you,
--- Comment #3 from charlet at gcc dot gnu dot org 2007-02-15 10:19 ---
If you want to act like a maintainer, then I'd suggest you submit patches,
and once you get approval, commit them, it's trivial after all, as you said.
The issue here is that you're trying to mix compilers from diff
--- Comment #3 from dorit at il dot ibm dot com 2007-02-15 10:21 ---
I'll look into it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30795
--- Comment #10 from burnus at gcc dot gnu dot org 2007-02-15 10:32 ---
> > I have still to re-read the test case to check whether TARGET is required
>
> However the accessed component is a POINTER to a derived type [...]
Ok, I somehow didn't realize
type field
type(mesh),
--- Comment #11 from sfilippone at uniroma2 dot it 2007-02-15 10:42 ---
(In reply to comment #10)
> > > I have still to re-read the test case to check whether TARGET is required
> >
> > However the accessed component is a POINTER to a derived type [...]
>
> Ok, I somehow didn't realiz
--- Comment #3 from med04hrt at studserv dot uni-leipzig dot de 2007-02-15
12:17 ---
(In reply to comment #0)
> The following simple c code gives segmentation fault on a GNU-Linux system
> (Redhat-9.0) running on a Pentium 4 machine with 512 MB RAM.
>
>
> Source file : test.c
>
> ---
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-02-15 12:41
---
It triggers on the c++tester (x86_64) for boost and tramp3d as well. Can we
please fix this asap? Thanks.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
The 2-line source that triggers the error:
#define A(x,...) x##,##__VA_ARGS__
A(1)
Error message:
a.c:6: internal compiler error: Geannuleerd
Please submit a full bug report
The source file is from:
http://www.kernel.org/git/?p=linux/kernel/git/josh/sparse.git;a=blob;f=validation/preprocessor13.
Hello,
When trying to build compiler on mingw I get the following error message:
-
gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -fno-common -DHAVE_CONFIG_H -I.
-Iada -I../../gcc-4.2-20070207/gcc
--- Comment #13 from manu at gcc dot gnu dot org 2007-02-15 14:24 ---
Another candidate to warn for undefined behaviour PR 968 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30334
--- Comment #14 from manu at gcc dot gnu dot org 2007-02-15 14:25 ---
(In reply to comment #13)
> Another candidate to warn for undefined behaviour PR 968 ?
>
Argh, I meant PR 986.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30334
I can only reproduce this problem on the sh target with a gcc version 3.4.3.
However my analysis makes me believe the problem still exists on the trunk.
After greg I have the following sequence :
(insn:HI 11 10 12 0 (set (reg/v/f:SI 2 r2 [orig:160 PrivateData_p ] [160])
(const_int 128 [0x
One of the most common problems I face in compiling programs with many
dependancies is that, if a dependency is missing, the resulting error messages
almost invariably scroll off the screen instantly, and even apart from the
scrolling, the single relevant error ("Cannot open : No such file or
direc
--- Comment #4 from krischik at users dot sourceforge dot net 2007-02-15
15:00 ---
Hello Andreas,
If you say so I believe you.
And it is not that important: I tried with gcc-4.2-20070207 and the problem did
not appear again. Only now Ada fails with "Argument list to long" see bug#3080
--- Comment #1 from charlet at gcc dot gnu dot org 2007-02-15 15:03 ---
Looks like a mingw/environment issue to me.
Never seen such thing myself.
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
---
During installation of gcc-4.1.2 ("gmake MAKE=gmake install") the following
error occurred on our Solaris systems:
echo 'SYSTEM_HEADER_DIR="'"`echo /usr/include | sed -e :a -e "s,[^/]*/\.\.\/,,"
-e ta`"'"' \
>
/slt/devel/toolsbase/gcc/4.1.2/sparc-sun-solaris2.10/lib/gcc/sparc-sun-solaris2.
--- Comment #1 from christian dot bruel at st dot com 2007-02-15 15:37
---
The bug might be clearer to explain like this
we have
16: (set reg:r1) (const_int 188)
17: (set reg:r1) (plus (reg:r1 reg:r2)
18: (set reg:r1) (mem (plus (reg:r1) (const_int 4))
is transformed into
16: (set reg
--- Comment #2 from christian dot bruel at st dot com 2007-02-15 15:55
---
Created an attachment (id=13052)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13052&action=view)
Proposed fix for postreload combine
the following patch fixes the problem in the sh 3.4.3 compiler.
Since
--- Comment #19 from pcarlini at suse dot de 2007-02-15 16:06 ---
Also, I don't think the XFAIL-ing has been implemented in the correct way. We
are now seeing logs like:
http://gcc.gnu.org/ml/gcc-testresults/2007-02/msg00570.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=307
--- Comment #31 from tobi at gcc dot gnu dot org 2007-02-15 16:20 ---
Subject: Bug 30478
Author: tobi
Date: Thu Feb 15 16:20:46 2007
New Revision: 122002
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122002
Log:
PR fortran/30478
fortran/
* decl.c (create_enum_history, gfc_free_
--- Comment #32 from tobi at gcc dot gnu dot org 2007-02-15 16:22 ---
Fixed.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from manu at gcc dot gnu dot org 2007-02-15 17:23 ---
Why DECL_INLINE is tested?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30794
--- Comment #12 from patchapp at dberlin dot org 2007-02-15 17:25 ---
Subject: Bug number PR30793
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01366.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #2 from krischik at users dot sourceforge dot net 2007-02-15
17:40 ---
Hello Arno,
I reported a few similar bugs to the PolyORB team long ago and we found the
reason as well:
Windows:
---
gnat-mingw-gcc-4.2.0.log:checking the maximum length of command line
--- Comment #3 from charlet at gcc dot gnu dot org 2007-02-15 17:50 ---
The command line you quoted is much less than 8192 characters (I count 3744
characters), so I guess your build environment is somehow creating additional
limitations, and/or some shell artefact or a bug in make is ca
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-02-15 17:51 ---
*** Bug 30808 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-15 17:51 ---
*** This bug has been marked as a duplicate of 15638 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot
|dot org
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|00
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-02-15 19:30 ---
*** Bug 30794 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 2007-02-15 19:30 ---
*** This bug has been marked as a duplicate of 12603 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from kargl at gcc dot gnu dot org 2007-02-15 19:33 ---
Subject: Bug 30799
Author: kargl
Date: Thu Feb 15 19:33:13 2007
New Revision: 122012
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122012
Log:
2007-02-15 Steven G. Kargl <[EMAIL PROTECTED]>
PR fort
--- Comment #5 from kargl at gcc dot gnu dot org 2007-02-15 19:47 ---
Fixed on 4.1, 4.2, and trunk.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
When I pass BOOT_STRAP="-march=athlon -O2" on the command line of make to
bootstrap gcc then they are not being used. The flags for bootstrapping always
default to "-g -O2".
I believe this is due to BOOT_CFLAGS missing in the top-level's Makefile lists
for variables to pass on to sub-level Makefil
--- Comment #30 from aesok at gcc dot gnu dot org 2007-02-15 20:02 ---
Subject: Bug 19087
Author: aesok
Date: Thu Feb 15 20:01:59 2007
New Revision: 122013
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122013
Log:
PR target/19087
* config/avr/avr.c (DWARF2_ADDR_
--- Comment #3 from steven at gcc dot gnu dot org 2007-02-15 20:06 ---
The third hunk of the patch changes something:
Index: local-alloc.c
===
--- local-alloc.c (revision 121794)
+++ local-alloc.c (working copy)
--- Comment #31 from aesok at gcc dot gnu dot org 2007-02-15 20:13 ---
Fixed in 4.1.3, 4.2.0 and 4.3.0.
--
aesok at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2007-02-15 20:15 ---
NB we don't add the REG_EQUIV note because insn 136 has multiple sets. Such
insns can't have REG_EQ* notes according to set_unique_reg_note. But that, I
think, is not the bug. More likely is that I exposed a latent
The manual says __FUNCTION__ is just another name for __func__ but the two
behave slightly differently (the former is not allowed in function declarations
while the latter is). __PRETTY_FUNCTION__ is also allowed but with slightly
different (and, IMO, rather unusual) effects.
I propose that __FUNC
--- Comment #5 from kargl at gcc dot gnu dot org 2007-02-15 20:50 ---
Does this still fail for others? I can't get the ICE to occur.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25252
Even though a function's exception specification isn't part of its type
(neither is the fact that the function is virtual) it would be useful to
include it in __PRETTY_FUNCTION__ (just as virtual is). This is a request for
such an enhancement.
--
Summary: enhancement: exception specif
I've used a #define to set a value, I've set a declared variable to the same
text value and I've set a second declared variable to the #define value. The
declared values are the same, the #define value differs.
If this were a simple round off error, all three values should be the same. As
they are
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-15 21:17 ---
Do you know the status of the C++0x paper about this C99 "extension"?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30811
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-15 21:23 ---
This works correctly on powerpc-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30813
--- Comment #2 from kevin dot glass at pnl dot gov 2007-02-15 21:26 ---
Subject: RE: Numerical error--#define value differs from declared variable
value
I ran on a 64-bit Itanium running Red Hat linux, I'm not sure which
version.
-Original Message-
From: pinskia at gcc dot g
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-15 21:28 ---
You mentioned BOOT_STRAP in your comment is that correct?
Also did you use "make bootstrap" and not just a plain make?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30810
--- Comment #2 from sebor at roguewave dot com 2007-02-15 21:29 ---
No, I'm not aware of any such paper. AFAIK, neither __FUNCTION__ nor
__PRETTY_FUNCTION__ is specified by either C or C++, or proposed for inclusion
either of them (I could be wrong). They're gcc extensions, aren't they?
--- Comment #20 from hp at gcc dot gnu dot org 2007-02-15 21:43 ---
In reply to comment #19, it's because the dg-bogus test trigs for that target;
it hits the ICE. As Mark didn't see the fail when testing, and noone else
complained, I originally thought only cris-*-* and perhaps one or
--- Comment #6 from dominiq at lps dot ens dot fr 2007-02-15 21:43 ---
I have the ICE
pr25252.f90:6.46:
MODULE PROCEDURE sreal, schar, sint => sreal
1
Error: Syntax error in MODULE PROCEDURE statement at (1)
pr25252.f90:0: intern
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-02-15 21:48 ---
Just a quick note here, the argument list is way below the max of 8k.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30806
--- Comment #8 from manu at gcc dot gnu dot org 2007-02-15 22:15 ---
Subject: Bug 28943
Author: manu
Date: Thu Feb 15 22:15:20 2007
New Revision: 122016
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122016
Log:
2007-02-15 Manuel Lopez-Ibanez <[EMAIL PROTECTED]>
PR c+
--- Comment #9 from manu at gcc dot gnu dot org 2007-02-15 22:31 ---
Subject: Bug 26494
Author: manu
Date: Thu Feb 15 22:31:17 2007
New Revision: 122017
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122017
Log:
2007-02-15 Manuel Lopez-Ibanez <[EMAIL PROTECTED]>
PR c/
--- Comment #10 from manu at gcc dot gnu dot org 2007-02-15 22:33 ---
Fixed in GCC 4.3
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #9 from manu at gcc dot gnu dot org 2007-02-15 22:35 ---
Fixed in GCC 4.3
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-15 22:54 ---
IIRC __FUNCTION__ is really __func__ defined by the C99 standard. So is
__func__ allowed as a default argument in the C++0x?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30811
--- Comment #4 from sebor at roguewave dot com 2007-02-15 23:06 ---
The wording proposed in N1970 for the C++ __func__ indentifier reads:
-1- The identifier __func__ shall be implicitly declared by the translator
as if, immediately following the opening brace of each function defin
--- Comment #5 from pthaugen at us dot ibm dot com 2007-02-15 23:36 ---
Seeing similar behavior on PPC for CPU2000. Comparing revisions 119759 and
119760, 179.art degrades 24% and 200.sixtrack degrades 50%.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30735
Hi All
Using the command line: gfortran -fbounds-check test.f95, I compiled this:
program test
integer :: it, neighbrs(var)
neighbrs = pack( (/ ( it, it=1, 30 ) /), (/ ( it, it=1, 30 ) /) < 3, (/ ( 0,
it=1, 30 ) /) )
end program test
substituting different values for var to get different res
Reduced testcase without OpenMP:
int f(unsigned section1)
{
switch (section1)
{
case 1: for(;;);
default : __builtin_trap ();
}
}
--
Summary: [4.3 Regression] pr29965.c fails on the mainline,
switches and __builtin_trap
Product: gcc
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-16 00:37 ---
Oh, the ICE I get is:
t.c:8: error: fallthru edge after unconditional jump 2
t.c:8: error: wrong amount of branch edges after unconditional jump 2
t.c:8: error: verify_flow_info: Incorrect fallthru 2->3
t.c:8: error:
--- Comment #5 from ian at airs dot com 2007-02-16 00:38 ---
I believe this is also related to the failure of gcc.c-torture/execute/simd-1.c
on i686-pc-linux-gnu at -O1 and above.
I think the problem is that we fail to add a REG_EQUIV note here in
local-alloc.c:
if (REG_N_SET
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-16 01:19 ---
Subject: Bug 30729
Author: pinskia
Date: Fri Feb 16 01:19:23 2007
New Revision: 122027
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122027
Log:
2007-02-15 Andrew Pinski <[EMAIL PROTECTED]>
PR mi
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-16 01:20 ---
Fixed on the trunk, will apply to the other branches later.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
The testcase started to fail recently, I'm not sure if this points to a bug in
gcc or mpfr. CCing Kaveh, as it's probably one of his mpfr patches that caused
this. Here's a debug run:
tobias-schluters-computer:~/src/dev tobi$ uname -a
Darwin tobias-schluters-computer.local 8.8.3 Darwin Kernel Ve
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-02-16 01:23 ---
Subject: Bug 30158
Author: pinskia
Date: Fri Feb 16 01:23:35 2007
New Revision: 122028
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122028
Log:
2007-02-15 Andrew Pinski <[EMAIL PROTECTED]>
PR C+
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-02-16 01:24 ---
Fixed on the trunk, might apply later next week to the other branches.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from tobi at gcc dot gnu dot org 2007-02-16 01:25 ---
My mpfr is version 2.2.1 as distributed by fink.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30816
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-16 01:27 ---
Subject: Bug 30433
Author: pinskia
Date: Fri Feb 16 01:27:42 2007
New Revision: 122029
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122029
Log:
2007-02-15 Andrew Pinski <[EMAIL PROTECTED]>
PR mi
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-02-16 01:28 ---
Fixed on the trunk will apply to the branches next week.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|pending |rtl-optimization
Summary|Spec cpu2k6/h264ref and |[4.3
--- Comment #2 from tobi at gcc dot gnu dot org 2007-02-16 01:30 ---
One more thing: I'm fairly sure the bug didn't appear with r118042 where erf
handling via mpfr was introduced.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30816
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-16 01:34 ---
3.0.4 and 2.95.3 did not ICE on this. Confirmed a regression. I don't know if
this is valid or not.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-16 01:36 ---
Usually you set CONFIG_SHELL to a different shell as /bin/sh on solaris is not
a POSIX compatiable shell.
See http://gcc.gnu.org/install/specific.html#x-x-solaris2 .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-16 01:48 ---
>I believe this is due to BOOT_CFLAGS missing in the top-level's Makefile lists
They are passed down, see EXTRA_GCC_FLAGS.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #21 from pinskia at gcc dot gnu dot org 2007-02-16 01:49
---
I am still reducing this source.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30768
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Summary|[4.2/4.3 Regression]|[4.2/4.3 Regre
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-02-16 01:58 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-16 02:00 ---
If it fails, then the ABI for x86 solaris is different from almost all other
x86 targets.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30777
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.3 regression]: |[4.3 regression]
|BOOT_CFLAGS="-O2 -g - |BOOT
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30778
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Known to fail||3
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||30770, 30778
Keywords||build
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-16 02:06 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|norma
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-16 02:32 ---
You might want to start thinking to update the prerelease of the compiler, it
is a couple months old now. THis works for me on the trunk and in 4.1.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30797
--- Comment #64 from jvdelisle at gcc dot gnu dot org 2007-02-16 02:50
---
I now have a machine at home here running i686-pc-gnu-linux that I plan to set
up daily compile test on. Joost, does that link in coment #63 get updated
daily?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #10 from sayle at gcc dot gnu dot org 2007-02-16 03:38 ---
Subject: Bug 30391
Author: sayle
Date: Fri Feb 16 03:38:22 2007
New Revision: 122030
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122030
Log:
PR middle-end/30391
* tree.c (expr_align): Hand
--- Comment #3 from ghazi at gcc dot gnu dot org 2007-02-16 03:44 ---
I'll try to help but I don't think this has anything to do with my patches.
Fortran was using mpfr for evaluating intrinsics way before I touched anything,
and I believe it uses it's own historical mechanism from it's
--- Comment #4 from kargl at gcc dot gnu dot org 2007-02-16 03:53 ---
(In reply to comment #3)
> I'll try to help but I don't think this has anything to do with my patches.
> Fortran was using mpfr for evaluating intrinsics way before I touched
> anything,
> and I believe it uses it's
--- Comment #5 from ghazi at gcc dot gnu dot org 2007-02-16 05:08 ---
(In reply to comment #3)
> 3. I'm suspicious about the mpfr you grabbed. Try building mpfr yourself
> from
> source and run it's testsuite to make sure it's healthy. Then link gcc with
> that and retry. I seem to
--- Comment #6 from ghazi at gcc dot gnu dot org 2007-02-16 05:16 ---
(In reply to comment #4)
> [...] It may be darwin-specific.
> This is my best guess. Consider
> program j
> x = erf(1.5)
> end program j
> With a 4.2 gfortran prior to your patches, -fdump-tree-original gives
> MAIN
--- Comment #6 from steven at gcc dot gnu dot org 2007-02-16 05:26 ---
What Ian said is probably right, and the patch below should fix it. I haven't
tried it yet, though...
Index: local-alloc.c
===
--- local-alloc.c
--- Comment #65 from jv244 at cam dot ac dot uk 2007-02-16 05:57 ---
(In reply to comment #64)
> I now have a machine at home here running i686-pc-gnu-linux that I plan to set
> up daily compile test on. Joost, does that link in coment #63 get updated
> daily?
>
No, the idea is that y
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2007-02-16 06:12
---
Fixed in 4.1.2 and later.
Note that you don't need -fno-strict-aliasing with -O, it's the default.
You don't need -mcpu=v9 -m64 -Wa,-xarch=v9 either, it's also the default.
--
ebotcazou at gcc dot gnu dot or
1 - 100 of 109 matches
Mail list logo
