On 10/2/07, Jack Howarth [EMAIL PROTECTED] wrote:
The fink packaging for gcc42/gcc43 builds fine on Macintel when we use...
--with-arch=nocona --with-tune=generic --host=i686-apple-darwin8
This gets further, failing now for a very different reason:
cc -O2 -g -O2 -m64 -O2 -O2 -g -O2
Hi there,
Mainline currently doesn't bootstrap on mips-sgi-irix6.5 due to an ICE
while compiling mips-sgi-irix6.5/64/libgcc/_powitf2.o at stage 1. This
happens, afaict, with any use of the TF mode with either -mabi=64 or
-mabi=n32:
$ cat foo.i
void __powitf2 (float x __attribute__ ((mode (TF
Ïðèâåò , ÿ õî÷ó âàì ïðåäëîæèòü îòëè÷íûé è ïðîâåðåííûé ñïîñîá çàðàáîòêà â
Èíòåðíåòå ! ÿ íåáóäó ñäåñü ïèñàòü èíôó , òàê÷òî êòî èìååò æåëàíèå îòëè÷íî è
íå-òåæåëî çàðàáàòûâàòü òàê îòïèøèòå íà ìàèë [EMAIL PROTECTED] èëè icq 8001177
Ñ óâàæåíèåì Âèêòîð.
Hi,
I have a rather nasty optimization issue with gfortran (as of yesterday). As I
think it could
be an optimization issue and not an gfortran frontend issue, I post it here,
the fortran list was not able to help so far.
I narrowed my problem to one single fortran function. If I compile this
On 10/3/07, Manfred Schwarb [EMAIL PROTECTED] wrote:
Hi,
I have a rather nasty optimization issue with gfortran (as of yesterday). As
I think it could
be an optimization issue and not an gfortran frontend issue, I post it here,
the fortran list was not able to help so far.
I narrowed my
On Wed, Oct 03, 2007 at 12:24:27PM +0200, Manfred Schwarb wrote:
I'm in a loss where to search for the real cause. Has anybody a hint
how to proceed further?
Sounds like weird-but-somewhat-determinist behaviour you can get when
you do out-of-bounds access on the stack or this kind of problems.
Hi,
I have a rather nasty optimization issue with gfortran (as of
yesterday). As I think it could
be an optimization issue and not an gfortran frontend issue, I post it
here,
the fortran list was not able to help so far.
I narrowed my problem to one single fortran function. If I
On Wed, Oct 03, 2007 at 12:24:27PM +0200, Manfred Schwarb wrote:
I'm in a loss where to search for the real cause. Has anybody a hint
how to proceed further?
Sounds like weird-but-somewhat-determinist behaviour you can get when
you do out-of-bounds access on the stack or this kind of
Doug Gregor [EMAIL PROTECTED] writes:
On 10/2/07, Jack Howarth [EMAIL PROTECTED] wrote:
The fink packaging for gcc42/gcc43 builds fine on Macintel when we use...
--with-arch=nocona --with-tune=generic --host=i686-apple-darwin8
This gets further, failing now for a very different
Ian Lance Taylor [EMAIL PROTECTED] writes:
Doug Gregor [EMAIL PROTECTED] writes:
On 10/2/07, Jack Howarth [EMAIL PROTECTED] wrote:
The fink packaging for gcc42/gcc43 builds fine on Macintel when we
use...
--with-arch=nocona --with-tune=generic --host=i686-apple-darwin8
In
Please do not send messages to both [EMAIL PROTECTED] and
[EMAIL PROTECTED] This message should only have gone to gcc-help.
Thanks.
Ignacio Molinero [EMAIL PROTECTED] writes:
I tried to compile gcc 4.1.2 (the final release) on Linux (Ubuntu
7.04) for windows beacuse I'm trying to make a
This is the beta release of binutils 2.18.50.0.2 for Linux, which is
based on binutils 2007 1001 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been
Hi all,
I try to generate cross-compiler to support -pthread in command line
with gcc-4.1.1. I build my compiler using the following configuration.
./configure --enable-threads=posix --target=our-cpu
After I generate cc1, it doesn't support -pthread command, could anyone
give me some
Hi all,
I have a already written code in C which should be compiled using GCC. In
this code there is an 4x3 array which will be passed to a function as
unbounded array:
int arr[4][3]
myFunc (int myArray[][3])
{
int temp=myArray[7][0]
}
In this function, values out of boundaries of input
Ian,
Why should using a Canadian Cross suddenly break on
Mac OS X? We have been using --host when building gcc
packages in fink on Mac OS X for ages and it has never
been a problem. I would think this should become a PR
if gcc trunk has regressed on this issue.
Jack
ps For example,
Jack Howarth [EMAIL PROTECTED] writes:
Why should using a Canadian Cross suddenly break on
Mac OS X? We have been using --host when building gcc
packages in fink on Mac OS X for ages and it has never
been a problem. I would think this should become a PR
if gcc trunk has regressed on this
Maggie [EMAIL PROTECTED] writes:
I try to generate cross-compiler to support -pthread in command line
with gcc-4.1.1. I build my compiler using the following configuration.
./configure --enable-threads=posix --target=our-cpu
After I generate cc1, it doesn't support -pthread command, could
Daniel Bengtsson [EMAIL PROTECTED] writes:
I have a already written code in C which should be compiled using GCC. In
this code there is an 4x3 array which will be passed to a function as
unbounded array:
int arr[4][3]
myFunc (int myArray[][3])
{
int temp=myArray[7][0]
}
In this
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2007-10-03 06:08
---
Try to revert the big SRA patch.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from fxcoudert at gcc dot gnu dot org 2007-10-03 08:08
---
Further reduced testcase:
integer i(1)
print *, transfer(achar(i), x)
end
The type mismatch disappears if you change the transfer statement into
transfer([x]), x, so this is a problem in the return type
Mainline currently doesn't bootstrap on mips-sgi-irix6.5 due to an ICE while
compiling mips-sgi-irix6.5/64/libgcc/_powitf2.o at stage 1. This happens,
afaict, with any use of the TF mode with either -mabi=64 or -mabi=n32:
$ cat foo.i
void __powitf2 (float x __attribute__ ((mode (TF {}
$
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-10-03 09:46
---
Subject: Bug 26682
Author: fxcoudert
Date: Wed Oct 3 09:46:46 2007
New Revision: 128977
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128977
Log:
PR fortran/26682
* options.c
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-10-03 10:02
---
Subject: Bug 31899
Author: rguenth
Date: Wed Oct 3 10:01:43 2007
New Revision: 128978
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128978
Log:
2007-10-03 Doug Kwan [EMAIL PROTECTED]
Richard
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-10-03 10:04
---
Fixed on the trunk, queued for 4.2.3.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from jason at gcc dot gnu dot org 2007-10-03 10:43 ---
Subject: Bug 15764
Author: jason
Date: Wed Oct 3 10:43:42 2007
New Revision: 128979
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128979
Log:
PR c++/15764
* cp/decl.c (wrap_cleanups_r): New
--- Comment #3 from tobi at gcc dot gnu dot org 2007-10-03 11:37 ---
Subject: Bug 33198
Author: tobi
Date: Wed Oct 3 11:37:44 2007
New Revision: 128980
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128980
Log:
PR fortran/33198
fortran/
* resolve.c (has_default_initializer):
This was seen on ppc-darwin and x86_64-linux with -m32:
$ cat x.f90
implicit none
type vec3
integer, dimension(1) :: coords
end type vec3
type(vec3), parameter :: v1 = vec3((/ 0 /))
integer :: i
i = 1
print *, v1%coords ((/i/))
end
$ gfortran -m32 x.f90
x.f90:9.23:
print
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
Sorry for the details - might not be required as I already tracked down the
problem to the source line...
When NM_FOR_TARGET requires arguments (fex -B -X32_64 for aix), checking for
nm in gcc/configure{,.ac} is broken:
Assume
*) source is /source/gcc-4.2.0
*) builddir is /build
*) configured
I have a rather nasty optimization issue with gfortran (as of yesterday).
As I think it could be an optimization issue and not an gfortran frontend
issue, so I assigned it to the middle-end.
I narrowed my problem to one single fortran function. If I compile this
function with
gfortran -O2
--- Comment #1 from manfred99 at gmx dot ch 2007-10-03 12:46 ---
Created an attachment (id=14288)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14288action=view)
Source code of affected function
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33638
--- Comment #2 from manfred99 at gmx dot ch 2007-10-03 12:47 ---
Created an attachment (id=14289)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14289action=view)
Assembler code of original code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33638
--- Comment #3 from manfred99 at gmx dot ch 2007-10-03 12:49 ---
Created an attachment (id=14290)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14290action=view)
Assembler code when commenting line 315, works
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33638
This is from https://bugzilla.redhat.com/show_bug.cgi?id=297961
The problem is that .class files can now (as of Java 1.5) contain classes whose
name contains a hyphen. The mangling used to generate internal labels in gcj
passes these hyphens through to the assembler rather than mangling them.
--- Comment #1 from aph at gcc dot gnu dot org 2007-10-03 13:00 ---
Subject: Bug 33639
Author: aph
Date: Wed Oct 3 12:59:57 2007
New Revision: 128981
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128981
Log:
2007-10-03 Andrew Haley [EMAIL PROTECTED]
PR java/33639
--- Comment #2 from aph at gcc dot gnu dot org 2007-10-03 13:02 ---
Fixed.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from dominiq at lps dot ens dot fr 2007-10-03 13:03 ---
On PPC Darwin, I get:
[karma] f90/bug% gfc pr33636.f90
[karma] f90/bug% a.out
0
[karma] f90/bug% gfc -m64 pr33636.f90
[karma] f90/bug% a.out
0
[karma] f90/bug% gfc
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org
|dot org
--- Comment #1 from bangerth at dealii dot org 2007-10-03 14:48 ---
Confirmed, a regression introduced by the new parser in 3.4.0.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #4 from tobi at gcc dot gnu dot org 2007-10-03 15:01 ---
Fixed on trunk.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--
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 2007-10-03 15:38 ---
One should note the gnu binutils does not support the newer features in aix so
it is really not supported with gcc on aix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33637
--- Comment #4 from ubizjak at gmail dot com 2007-10-03 15:43 ---
Please provide enough sources to create an _executable_ that shows the failure.
We are dealing with runtime failure here.
A _short_ testcase (30 lines) is nice to have, so all non-related parts should
be removed.
--- Comment #3 from spop at gcc dot gnu dot org 2007-10-03 15:45 ---
Subject: Bug 33576
Author: spop
Date: Wed Oct 3 15:45:10 2007
New Revision: 128986
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128986
Log:
2007-10-03 Sebastian Pop [EMAIL PROTECTED]
PR
--- Comment #4 from spop at gcc dot gnu dot org 2007-10-03 15:47 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from tobi at gcc dot gnu dot org 2007-10-03 16:12 ---
Created an attachment (id=14291)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14291action=view)
Putative patch
This patch fixes the testcase.
FX, I take it that you have a ready-built compiler with
--- Comment #2 from tobi at gcc dot gnu dot org 2007-10-03 16:22 ---
Created an attachment (id=14292)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14292action=view)
Putative patch redux
Coming to think of it, the charlen thing can probably also be moved to the
first switch and
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-10-03 16:26
---
(In reply to comment #1)
Created an attachment (id=14291)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14291action=view) [edit]
Putative patch
I thought about that, because it seems right, but the the
--- Comment #4 from Tobias dot Schlueter at physik dot uni-muenchen dot de
2007-10-03 16:36 ---
Subject: Re: Parentheses get wrong kind during matching
fxcoudert at gcc dot gnu dot org wrote:
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-10-03 16:26
---
(In
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-10-03 16:40
---
(In reply to comment #4)
OTOH I'm seeing a testsuite failure with derived_comp_array_ref_5.f90
for which I have no explanation at the moment, I'll have to doublecheck
if it disappears without my patch.
--- Comment #2 from razin at avaya dot com 2007-10-03 16:44 ---
(In reply to comment #1)
*** This bug has been marked as a duplicate of 27232 ***
Hello!
I am currently experiencing the same problem when using 4.2.1. There is not
particular description if this bug is going to be
--- Comment #6 from Tobias dot Schlueter at physik dot uni-muenchen dot de
2007-10-03 16:46 ---
Subject: Re: Parentheses get wrong kind during matching
fxcoudert at gcc dot gnu dot org wrote:
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-10-03 16:40
---
(In
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-10-03 16:52
---
(In reply to comment #6)
failures of default_format_1.f90 (which I'm seeing as well)
You're seeing failures of default_format_1.f90 on i686-darwin (IIRC, that's
what you've got these days)? That's not supposed
I'm seeing a regression in gcc-4.2.2 prerelease:
FAIL: g++.dg/other/unused1.C scan-assembler
(string|ascii?)z?\\tclass2(|000)
The failure happens on multiple (all?) configurations starting around Sept
13th:
CLEAN results:
http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00609.html
Benchmark perlbmk from SPEC CPU2000 fails at runtime on powerpc64-linux with
several sets of optimization flags. When built with a compiler configured with
--enable-checks=all, file toke.c fails to build. The following minimized
testcase:
typedef enum { one, two } exp;
extern exp pe;
extern
--- Comment #8 from Tobias dot Schlueter at physik dot uni-muenchen dot de
2007-10-03 17:06 ---
Subject: Re: Parentheses get wrong kind during matching
fxcoudert at gcc dot gnu dot org wrote:
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-10-03 16:52
---
(In
Almost any source file compiled for any of a large number of targets
(powerpc*-*, arm-eabi, hppa-linux, mipsel-linux, s390*-linux, sh*-*, sparc*-*)
with -O2 -frtl-abstract-sequences results in the following:
bug1.c: In function foo:
bug1.c:8: error: unrecognizable insn:
(insn 28bug1.c:8:
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-10-03 17:09
---
(In reply to comment #8)
I checked all tests individually, and both the tests related to
tiny(0.0_8) fail.
That means Apple's printf() failures to read and write denormals are not
powerpc-specific. I've
When I compile the program listed below with the command gfortran -c
sysmat.f90 I get the message Warning: Line truncated at (1)
PROGRAM sysmat
! The following line has enough trailing blanks to make it 133 characters long
i = 0
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-10-03 17:39 ---
I think this warning is correct even if the characters are spaces.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33643
Benchmark crafty from SPEC CPU2000 gets an ICE for 32-bit powerpc (linux, aix,
darwin, eabi) when compiled with -O2 -ftrapv, as shown by this minimized test:
extern char *bar (const char *);
int *m, *b;
void
foo (void)
{
int *mv;
int p;
char a[17];
p = bar (a) - a;
for (mv = m; mv b;
--- Comment #1 from janis at gcc dot gnu dot org 2007-10-03 18:08 ---
A regression hunt identified the following patch:
http://gcc.gnu.org/viewcvs?view=revrev=125624
r125624 | dberlin | 2007-06-11 18:02:15 + (Mon, 11 Jun 2007)
This is the merge of the dataflow branch into
Benchmark vortex from SPEC CPU2000 compiled with -O2 -fno-unit-at-atime for
powerpc64-linux fails to build due to a missing symbol. For each of 24 cross
cc1's that I tried, symbol That from the following minimized testcase is not
defined in the .s file:
extern void bar (int *);
void
foo (void)
{
--- Comment #11 from jason at gcc dot gnu dot org 2007-10-03 18:26 ---
Fixed for 4.3.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rsandifo at gcc dot gnu dot org 2007-10-03 18:39
---
Sorry, this is my fault.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
Gcc 4.3 revision 128980 generates:
str.fppized.f90:337.29:
module procedure create
1
Error: Ambiguous interfaces 'create' and 'create' in generic interface
'create_' at (1)
str.fppized.f90:337.29:
Revision 128885 is OK.
--
Summary: [4.3
--- Comment #2 from rsandifo at gcc dot gnu dot org 2007-10-03 18:39
---
Subject: Bug 33635
Author: rsandifo
Date: Wed Oct 3 18:39:30 2007
New Revision: 128991
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128991
Log:
gcc/
PR target/33635
*
--- Comment #3 from rsandifo at gcc dot gnu dot org 2007-10-03 18:42
---
Thanks for the report. As per my gcc-patches@ message,
I think the committed patch is at least a step on the
road to recovery. Please let me know if it fixes things,
or if it still isn't enough.
--
rsandifo
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-10-03 18:51 ---
This may work:
$ svn diff
Index: resolve.c
===
--- resolve.c (revision 128885)
+++ resolve.c (working copy)
@@ -6563,7 +6563,7 @@ resolve_charlen
--- Comment #16 from dorit at gcc dot gnu dot org 2007-10-03 18:52 ---
Ryan, thanks a lot for the info. FYI, I started a discussion about this here:
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00202.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32893
In the library .../lib64/libgfortran.a, the 4.1.2 version has a routine
_gfortran_copy_string
in the strong_intrinsics.o component. For the same 4.2.1 library there is no
corresponding entry point.
It appears that codes compiled with 4.1.2 generate internal calls to this entry
point.
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-03 18:32 ---
I'll have a look.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-10-03 19:22 ---
And this is by design. gfortran 4.1 is ABI incompatiable with gfortran 4.2.
This is one of the reasons why in 4.2 (or is it only on the trunk), we added
symbol versioning support. This is not the only place where
--- Comment #10 from dominiq at lps dot ens dot fr 2007-10-03 19:30 ---
gcc/testsuite/gfortran.dg/default_format_1.f90 passes the test if I replace
if (y /= x) res = res + 1
by
z=0.0_k
if (abs(x-y)nearest(z,1.0_k)) res = res + 1
in the two places of test_r8,
--- Comment #11 from dominiq at lps dot ens dot fr 2007-10-03 19:34 ---
BTW I have forgotten to explain why I have to use an auxiliary variable 'z': if
I usenearest(0.0_8,1.0_8); I get
default_format_1_db.f90:70.29:
if (abs(x-y)nearest(0.0_8,1.0_8)) print *, x, y, x-y
--- Comment #2 from longb at cray dot com 2007-10-03 19:44 ---
Subject: Re: _gfortran_copy_string missing in libgfortran.a
I suspected this might be the case, but did not find it documented.
Thanks for the quick reply.
Cheers,
Bill
pinskia at gcc dot gnu dot org wrote:
---
--- Comment #5 from manfred99 at gmx dot ch 2007-10-03 20:10 ---
Subject: Re: optimization bug: wrong code with
-fforce-addr
--- Comment #4 from ubizjak at gmail dot com 2007-10-03 15:43 ---
Please provide enough sources to create an _executable_ that shows the
failure.
--- Comment #1 from ghazi at gcc dot gnu dot org 2007-10-03 20:42 ---
This looks like PR33429. Perhaps we should backport the XFAIL that was
installed on mainline.
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
Most benchmarks in SPEC CPU2000 fail to compile with an ICE when compiled with
-O2 -fmodulo-sched -freorder-blocks-and-partition for powerpc* and s390*
targets. Compiling the following minimized testcase:
unsigned res;
void
foo (unsigned code, int len)
{
int i;
for (i = 0; i len; i++)
--- Comment #1 from hjl at lucon dot org 2007-10-03 20:33 ---
[EMAIL PROTECTED] build_base_o2.]$ cat bar.f90
module BAR_MODULE
implicit none
private
publiccreate_
interface create_
module procedure create
end interface
contains
subroutine create(self)
--- Comment #2 from hjl at lucon dot org 2007-10-03 20:55 ---
It should be:
[EMAIL PROTECTED] pr33646]$ cat bar.f90
module BAR_MODULE
implicit none
private
publiccreate_
interface create_
module procedure create
end interface
type system_type
--- Comment #3 from pault at gcc dot gnu dot org 2007-10-03 21:21 ---
hj,
It's me - I'll revert the patch that did this, right away.
Cheers
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33646
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-03
21:23 ---
Subject: Re: bootstrap with ada failed
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2007-10-03 06:08
---
Try to revert the big SRA patch.
128907 is ok. 128908 is broken.
Dave
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-03 21:02 ---
-frtl-abstract-sequences
It is a size optimization method. This option is to find identical
sequences of code, which can be turned into pseudo-procedures and then replace
all occurrences with calls to the newly
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-10-03 21:27
---
Subject: Bug 26682
Author: fxcoudert
Date: Wed Oct 3 21:27:39 2007
New Revision: 128993
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128993
Log:
PR fortran/26682
* trans-decl.c
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-10-03 21:30
---
I've fixed 1 and 2 (and added an error message when -fwhole-program is used
with Fortran), and there is a separate PR to track 3, so I'll close this one.
--
fxcoudert at gcc dot gnu dot org changed:
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2007-10-03 21:31
---
128907 is ok. 128908 is broken.
OK, thanks for confirming.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from dominiq at lps dot ens dot fr 2007-10-03 21:32 ---
It's me
I have warned you;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33646
--- Comment #5 from hjl at lucon dot org 2007-10-03 21:38 ---
Revision 128954:
http://gcc.gnu.org/ml/gcc-cvs/2007-10/msg00058.html
is the cause.
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-10-03 22:05
---
(In reply to comment #2)
Created an attachment (id=14292)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14292action=view) [edit]
Putative patch redux
That patch regtests fines on x86_64-linux with
--- Comment #9 from hjl at lucon dot org 2007-10-03 22:17 ---
(In reply to comment #8)
Subject: Re: attribute((aligned)) doesn't work for variables on the stack for
greater than required alignement
On 3 Oct 2007 22:04:28 -, hjl at lucon dot org
[EMAIL PROTECTED] wrote:
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-10-03 22:07 ---
Subject: Re: attribute((aligned)) doesn't work for variables on the stack for
greater than required alignement
On 3 Oct 2007 22:04:28 -, hjl at lucon dot org
[EMAIL PROTECTED] wrote:
--- Comment #7 from
--- Comment #7 from hjl at lucon dot org 2007-10-03 22:04 ---
What is the performance impact of
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01167.html
Intel compiler has a very efficient way to align the stack:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28074
It saves stack
--- Comment #8 from jason at gcc dot gnu dot org 2007-10-03 21:54 ---
The error the trunk gives is correct; this is not one of the allowed uses of a
member function name in [expr.prim]p10.
--
jason at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from david_albert at axiometric dot com 2007-10-03 22:06
---
This issue has affected *many* developers on a variety of platforms including
ARM and PPC. There is no elegant way to resolve this without searching through
every line of code. There is a warning -Wcast-align
--- Comment #3 from rask at gcc dot gnu dot org 2007-10-03 22:13 ---
You could open a request for a warning when a null pointer check is optimized
away after dereferencing the pointer.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33629
--- Comment #10 from hjl at lucon dot org 2007-10-03 22:27 ---
For backend with frame pointer and working -fomit-frame-pointer -g, can
we
1. Make -fomit-frame-pointer per function, instead of per file.
2. Enable -fomit-frame-pointer for functions which need stack alignment.
3. Mark
Every test in SPEC CPU2000 causes cc1 to segfault when built with:
-O2
-fno-tree-ch
-fno-tree-copy-prop
-fno-tree-dominator-opts
-fno-tree-store-copy-prop
-fno-tree-vrp
Yes, a normal person wouldn't do that, but in theory we'd like the optimization
passes to not rely on each other.
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-10-03 22:40
---
(In reply to comment #7)
It saves stack pointer in frame pointer. Can we implement it for suitable
cases/backends and properly handle
This only helps x86 really. If you look at my patch, it already implements
Just about any input to gcc for any target results in the following ICE for
-O2 -fno-tree-salias:
bug7.c: In function foo:
bug7.c:1: internal compiler error: in verify_curr_properties, at passes.c:1043
Please submit a full bug report,
with preprocessed source if appropriate.
See
1 - 100 of 127 matches
Mail list logo