Ian Lance Taylor wrote :
Kai Ruottu [EMAIL PROTECTED] writes:
Ok, the traditional evolutionary method is to not reinvent the wheel
with the already tested target components but let then be as they are
and produce only the stuff required for the new $host, the GNU
binutils and the GCC
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Feb 10, 2007 at 03:09:41PM +0200, Robert Dewar wrote:
Ian Lance Taylor wrote:
Jie Zhang [EMAIL PROTECTED] writes:
But now gcc seems to optimize it away. For the following function:
$ cat t.c
#include limits.h
void foo (int rc)
{
On Sun, Feb 11, 2007 at 09:51:33PM -0800, Paul Eggert wrote:
Given that there is still discussion and work on GCC for this topic
anyway[1], I don't think Autoconf should be doing anything just yet.
Yeah, it is just too early.
Both of the solutions that Bruno suggested seem too drastic to me
Mark Mitchell writes:
Kaveh R. GHAZI wrote:
[Java folks: see below for check-in window for daylight savings time
patches.]
Therefore, if the Java folks have daylight savings time patches that
they would like to check in, please do so before Monday evening,
California time.
Done.
Kai Ruottu [EMAIL PROTECTED] writes:
For which existing targets the prebuilt C libraries are missing? Or
which are the
targets which don't have any suitable, compatible or something C library
which could serve as that temporary bootstrap target C library
during the GCC
build? In those
On Sun, Feb 11, 2007 at 01:04:05PM -0800, H. J. Lu wrote:
On Sun, Feb 11, 2007 at 01:00:41PM -0800, H. J. Lu wrote:
make bootstrap used to compare stage2 and stage3 after gcc was
bootstrapped. make bootstrap would abort if comparison was failed.
Now, compare stage2 and stage3 is not longer
On Mon, Feb 12, 2007 at 09:53:00AM -0800, Joe Buck wrote:
On Sun, Feb 11, 2007 at 01:04:05PM -0800, H. J. Lu wrote:
On Sun, Feb 11, 2007 at 01:00:41PM -0800, H. J. Lu wrote:
make bootstrap used to compare stage2 and stage3 after gcc was
bootstrapped. make bootstrap would abort if
Ian, Richard, Diego --
I've explicitly forwarded this to you, as folks who have done work on
middle-end optimization and have seen lots of real-world code.
(That's not to say that I'm not looking for comments from anyone and
everyone -- but I'm specifically trying to get at least some feedback,
Hi,
I am reading the code of autovect branch and curious about how to deal
with the dependencies of virtual defs/uses. In the function
vect_analyze_scalar_cycles( ), I found the statement Skip virtual
phi's. The data dependences that are associated with virtual defs/uses
( i.e., memory accesses)
On 2/12/07, Jiahua He [EMAIL PROTECTED] wrote:
Hi,
I am reading the code of autovect branch and curious about how to deal
with the dependencies of virtual defs/uses. In the function
vect_analyze_scalar_cycles( ), I found the statement Skip virtual
phi's. The data dependences that are associated
Thanks! In fact, I should ask how to deal with idiom (such as
reduction, induction) recognition for virtual defs/uses.
Jiahua
2007/2/12, Daniel Berlin [EMAIL PROTECTED]:
On 2/12/07, Jiahua He [EMAIL PROTECTED] wrote:
Hi,
I am reading the code of autovect branch and curious about how to
On 2/12/07, Jiahua He [EMAIL PROTECTED] wrote:
Hi,
I am reading the code of autovect branch and curious about how to deal
with the dependencies of virtual defs/uses. In the function
vect_analyze_scalar_cycles( ), I found the statement Skip virtual
phi's. The data dependences that are
Thanks! In fact, I should ask how to deal with idiom (such as
reduction, induction) recognition for virtual defs/uses.
Just curious - what is this for? (are you interested in this in the context
of vectorization? is there a specific example you have in mind?)
dorit
Jiahua
2007/2/12,
On Sunday I had accidentally chat about the df infrastructure on
IIRC. I've got some thoughts which I'd like to share.
I like df infrastructure code from the day one for its clearness.
Unfortunately users don't see it and probably don't care about it.
With my point of view the df
On Mon, Feb 12, 2007 at 10:06:11AM -0800, Mark Mitchell wrote:
Does it seem overly aggressive to you to assume f cannot throw
in g, given:
void f() {}
void g() { f(); }
where this code is in a shared library?
Yes.
If F is part of the exported (and overridable) interface of
the
On 2/12/07, Vladimir Makarov [EMAIL PROTECTED] wrote:
I like df infrastructure code from the day one for its clearness.
Unfortunately users don't see it and probably don't care about it.
With my point of view the df infrastructure has a design flaw. It
extracts a lot of information about RTL
Oh, I see. For reduction and induction, you don't need to deal with
the condition with vdef. I am considering how to implement an idiom
with vdef, like SCAN (prefix sum). And by the way, do you support
idioms with vuses?
Jiahua
2007/2/12, Dorit Nuzman [EMAIL PROTECTED]:
Thanks! In fact, I
Richard Henderson wrote:
On Mon, Feb 12, 2007 at 10:06:11AM -0800, Mark Mitchell wrote:
Does it seem overly aggressive to you to assume f cannot throw
in g, given:
void f() {}
void g() { f(); }
where this code is in a shared library?
Yes.
If F is part of the exported (and
Vladimir Makarov wrote:
On Sunday I had accidentally chat about the df infrastructure on
IIRC. I've got some thoughts which I'd like to share.
I like df infrastructure code from the day one for its clearness.
Unfortunately users don't see it and probably don't care about it.
You're right
Larry Evans wrote:
How does one dump the trees in pt.c:tsubst in some hunan readable
cp_dump_tree(di, args);
cp_dump_tree is a hook for printing C++ specific trees. Try dump_node
in tree-dump.c instead. Or one of the other functions in this file.
I'm not sure if you can call dump_node
Mark Mitchell [EMAIL PROTECTED] writes:
But, aren't big C++ shared libraries rather different? Does KDE
actually use throw() everywhere, or visibility attributes? But,
presumably, most people don't replace the implementation of
ScrollBar::ScrollUp or whatever. I'd be happy to know I'm
On 02/11/2007 05:59 PM, Gerald Pfeifer wrote:
On Sun, 11 Feb 2007, Larry Evans wrote:
[snip]
I can't comment on the contents, but that HTML file is generated from
our texinfo documentation; the master source for that is
gcc/doc/install.texi
in our SVN repository.
Gerald
THanks Gerald.
Vladimir Makarov writes:
Vlad Especially I did not like David Edelhson's phrase and no new
Vlad private dataflow schemes will be allowed in gcc passes. It was not
Vlad such his first expression. Such phrases are killing competition which
Vlad is bad for gcc. What if the new specialized scheme
On Mon, Feb 12, 2007 at 01:16:43PM -0800, Ian Lance Taylor wrote:
Mark Mitchell [EMAIL PROTECTED] writes:
But, aren't big C++ shared libraries rather different? Does KDE
actually use throw() everywhere, or visibility attributes? But,
presumably, most people don't replace the
David Edelsohn wrote:
Vladimir Makarov writes:
Third, I am disappointed that you chose to make this argument
personal.
David, I really apologize to make it personal. We are all one community
and we are all thinking to make gcc a better compiler.
On Mon, Feb 12, 2007 at 01:30:41PM -0800, Richard Henderson wrote:
On Mon, Feb 12, 2007 at 01:16:43PM -0800, Ian Lance Taylor wrote:
Mark Mitchell [EMAIL PROTECTED] writes:
But, aren't big C++ shared libraries rather different? Does KDE
actually use throw() everywhere, or visibility
Richard Henderson wrote:
On Mon, Feb 12, 2007 at 01:16:43PM -0800, Ian Lance Taylor wrote:
Mark Mitchell [EMAIL PROTECTED] writes:
But, aren't big C++ shared libraries rather different? Does KDE
actually use throw() everywhere, or visibility attributes? But,
presumably, most people don't
Joe Buck wrote:
If KDE doesn't use throw(), or visibility attributees, that's a
failing in KDE, not the compiler.
Will 4.1.2 be worse than 4.1.1 for code that has these kinds of failings?
Yes. On workstation and server systems, most of the issue will be
somewhat larger binaries. On
Joe Buck wrote:
Will 4.1.2 be worse than 4.1.1 for code that has these kinds of failings?
On Mon, Feb 12, 2007 at 01:53:10PM -0800, Mark Mitchell wrote:
Yes
If so, then it might be better to push the fix that allows overrides that
throw back to 4.2, and circulate warnings to affected
Snapshot gcc-4.1-20070212 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070212/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Given that we're not going to mess about further with DECL_REPLACEABLE_P
(since the case that Kaven raised involving PIC compilation of functions
using exceptions is a non-bug), I don't think we need to do RC3.
The only changes that we've had since RC2 are Andrew Haley's Java
timezone changes and
Vladimir Makarov writes:
Vlad Especially I did not like David Edelhson's phrase and no new
Vlad private dataflow schemes will be allowed in gcc passes. It was not
Vlad such his first expression. Such phrases are killing competition which
Vlad is bad for gcc. What if the new specialized
On Sunday I had accidentally chat about the df infrastructure on
IIRC. I've got some thoughts which I'd like to share.
I like df infrastructure code from the day one for its clearness.
Unfortunately users don't see it and probably don't care about it.
With my point of view the df
Vlad,
I think that different people can have different perspectives.
You have been working on improving the register allocation for several
years, but very little has come of it because the reload
infrastructure does not suit itself to being integrated with modern
register allocators. You
On Feb 11, 2007, at 1:17 PM, Brendon Costa wrote:
I am coding an extension for GCC and am having some difficulty with
pre-compiled headers. I dont know if my understanding of how they
work is completely correct and so my code is getting a segfault.
You _must_ have clean data structures and
Richard Kenner wrote:
Vladimir Makarov writes:
Vlad Especially I did not like David Edelhson's phrase and no new
Vlad private dataflow schemes will be allowed in gcc passes. It was not
Vlad such his first expression. Such phrases are killing competition which
Vlad is bad for
On Feb 12, 2007, at 12:54 PM, Jiahua He wrote:
Oh, I see. For reduction and induction, you don't need to deal with
the condition with vdef. I am considering how to implement an idiom
with vdef, like SCAN (prefix sum). And by the way, do you support
idioms with vuses?
Jiahua
2007/2/12, Dorit
Steven Bosscher wrote:
On 2/12/07, Vladimir Makarov [EMAIL PROTECTED] wrote:
I like df infrastructure code from the day one for its clearness.
Unfortunately users don't see it and probably don't care about it.
With my point of view the df infrastructure has a design flaw. It
extracts a lot
Mark Mitchell wrote:
Vladimir Makarov wrote:
On Sunday I had accidentally chat about the df infrastructure on
IIRC. I've got some thoughts which I'd like to share.
I like df infrastructure code from the day one for its clearness.
Unfortunately users don't see it and probably don't care
Vladimir N. Makarov wrote:
However, my understanding (as someone who's not an expert on the DF code
base) is that, as you say, the new stuff is much tidier. I understood
the objective to be not so much that DF itself would directly improve
the generated code, but rather than it would provide
On 2/12/07, Vladimir Makarov [EMAIL PROTECTED] wrote:
On Sunday I had accidentally chat about the df infrastructure on
IIRC. I've got some thoughts which I'd like to share.
I like df infrastructure code from the day one for its clearness.
Unfortunately users don't see it and probably don't
On 2/13/07, Vladimir N. Makarov [EMAIL PROTECTED] wrote:
There are certainly performance issues here. There are limits on
how much I, and the others who have worked on this have been able to
change before we do our merge. So far, only those passes that were
directly hacked into flow, such
Vladimir N. Makarov [EMAIL PROTECTED] writes:
I know some work is being done on incremental df analysis. It could
decrease time for rescanning RTL between passes. Let us hope on this.
My understanding is that on dataflow-branch the DF information is now
fully incremental.
I don't really
Hello
On Mon, 12 Feb 2007 19:46:35 -0800 Mike Stump mrs at apple dot com wrote
The mental model you should use for PCH is this, when processing a header,
the compiler does a complete memory walk and dumps it to a file. Upon
`reading' the pch file, it mmaps all that memory back in, throwing
what happens with the data previously loaded by a previous pch include file?
I can't figure out why every GTY()-ed global data (extern or static) should
be overwritten at each PCH inclusion, but then maybe I am wrong.
There can be only one PCH inclusion in every compilation.
Paolo
--- Comment #3 from armin at xos dot net 2007-02-12 08:06 ---
Subject: Re: compile error / segmentation fault / 64bit compiler
sorry it's early in the morning ...
sun studio 11: cc: sun C 5.8 2005/10/13
do you need further information? i compiled mysql/apache/perl/...
so far
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2007-02-12 08:21
---
do you need further information?
Yes, see http://gcc.gnu.org/bugs.html for instructions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30769
I just tried to compile Suse Linux package ladspa-1.12.code10-56
with the GNU C++ compiler version 4.3 snapshot 20070209.
The compiler said
Descriptor.h: In static member function 'static void*
DescriptorT::_instantiate(const _LADSPA_Descriptor*, ulong) [with T =
CabinetII]':
Descriptor.h:117:
--- Comment #1 from dcb314 at hotmail dot com 2007-02-12 08:53 ---
Created an attachment (id=13038)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13038action=view)
C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30771
I just tried to compile Suse Linux package lsvpd-0.16.0-36
with the GNU C++ compiler version 4.3 snapshot 20070209.
The compiler said
In file included from node.c:31:
/usr/include/stdlib.h: In function 'atof':
/usr/include/stdlib.h:400: internal compiler error: in optimize_inline_calls,
at
--- Comment #1 from dcb314 at hotmail dot com 2007-02-12 08:55 ---
Created an attachment (id=13039)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13039action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30772
--- Comment #23 from manu at gcc dot gnu dot org 2007-02-12 09:32 ---
Subject: Bug 7651
Author: manu
Date: Mon Feb 12 09:32:08 2007
New Revision: 121843
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121843
Log:
2007-02-12 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-02-12 09:48 ---
I'd say Doctor, it hurts when I do this -fno-unit-at-a-time RIP.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-02-12 09:58 ---
Confirmed. We hit
#1 0x00ecf362 in vectorizable_type_promotion (stmt=0x2afac97cd000,
bsi=0x0, vec_stmt=0x0)
at /space/rguenther/src/svn/trunk/gcc/tree-vect-transform.c:2752
2752 gcc_assert
--- Comment #3 from Helge dot Avlesen at bccs dot uib dot no 2007-02-12
10:03 ---
Subject: Re: assembly snippets for nano second resolution wall clock time
jv244 at cam dot ac dot uk [EMAIL PROTECTED] writes:
is this comment about get_clockfreq.o actually correct ? I find it
--- Comment #3 from dorit at il dot ibm dot com 2007-02-12 10:11 ---
I'll look into it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30771
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-02-12 10:41 ---
*** Bug 30772 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30563
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-12 10:41 ---
*** This bug has been marked as a duplicate of 30563 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from mike at tedder dot com 2007-02-12 10:45 ---
Whatever this bug was in 3.4.3, does not occur or has been fixed in gcc-3.4.6
or gcc-4.1.1. Both of these compile bootstrap without any problems.
For the record (and just to make sure it wasn't anything specific with my
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-02-12 10:49 ---
To dect an ODR violation in this case, means a couple of things. First you
cannot compare byte for byte the function as one might be compiled with
optimizations and the other was compiled without. And then if you
Benchmarks spec cpu2006/464.h264ref and cpu2006/482.sphinx3 miscompare its
output with 'test' dataset when compiled with trunk GCC revision 121821 at -O2
optimization level.
Binary regression search showed that regression is caused by More REG_EQ*
notes cleanups patch
--- Comment #12 from dorit at gcc dot gnu dot org 2007-02-12 13:15 ---
Subject: Bug 29145
Author: dorit
Date: Mon Feb 12 13:14:52 2007
New Revision: 121844
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121844
Log:
PR tree-optimization/29145
* tree-data-ref.c
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #4 from dorit at il dot ibm dot com 2007-02-12 14:23 ---
I'm testing the patch below. (wasn;t able to reproduce the problem in the
attched testcase, but here's a reduced testcase for the problem that Richi
described - thanks!:
int a[128];
int
main()
{
short i;
for
Several testsuite failures have arisen on solaris2.10 when using -fpic (not
-fPIC). The problem has gotten worse over time and I don't believe the
testcases are changing, so GCC has gotten worse for some reason. The logfiles
look like this:
ld: fatal: too many symbols require `small' PIC
--- Comment #1 from ghazi at gcc dot gnu dot org 2007-02-12 14:39 ---
This didn't seem to arise in 4.0.x, but all later branches have the problem.
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from armin at xos dot net 2007-02-12 14:40 ---
Subject: Re: compile error / segmentation fault / 64bit compiler
Stash.i is attached
i compiled gcc with the above compiler. normal 64bit bootstrapping.
cc - gcc 32 (can create 64bit with -m64) - gcc 32/64 (generates
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2007-02-12 14:54
---
i compiled gcc with the above compiler. normal 64bit bootstrapping.
cc - gcc 32 (can create 64bit with -m64) - gcc 32/64 (generates 64bit)
- gcc 64 (full 64bit)
That's probably a duplicate of PR other/23541
--- Comment #2 from ghazi at gcc dot gnu dot org 2007-02-12 14:56 ---
Correction, on 4.0.3 4.0.4, I get one error:
FAIL: tmpdir-gcc.dg-struct-layout-1/t002 c_compat_x_tst.o-c_compat_y_tst.o link
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00732.html
AIX:doug:0 make bootstrap
make[1]: Entering directory `/voltds/doug/tmp/gcc-3.4.6/libiberty'
make[2]: Entering directory `/voltds/doug/tmp/gcc-3.4.6/libiberty/testsuite'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/voltds/doug/tmp/gcc-3.4.6/libiberty/testsuite'
make[1]:
--- Comment #1 from nospampeeps at yahoo dot com 2007-02-12 15:18 ---
Created an attachment (id=13041)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13041action=view)
Core dump.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30775
--- Comment #3 from ghazi at gcc dot gnu dot org 2007-02-12 15:22 ---
Hmm on June *15th*, the -fbounds-check flag was added to the fortran testcase
gfortran.dg/cray_pointers_2.f90, and taking that flag out of today's sources
allows the testcase to pass with -fpic.
However clearly my
--- Comment #9 from rwgk at yahoo dot com 2007-02-12 15:47 ---
My binary search (using the gcc-4_2-branch) stopped here:
119790 OK
119791 fails
The corresponding commit was:
% svn log -r 119791
r119791 |
--- Comment #48 from jv244 at cam dot ac dot uk 2007-02-12 15:56 ---
Currently, there is a new ICE on CP2K (see initial comment) that happens at any
optimisation level:
gfortran -c all_cp2k_gfortran.f90
all_cp2k_gfortran.f90:118549: internal compiler error: Segmentation fault
Please
I am building on a SunFire T2000, Solaris 10 os. The test programs replaces the
stdin and stdout fds of the child with pipes from the parent. I keep thinking
there has to be a stupid mistake here somewhere but I can't find it and
everyone I show it to thinks it should work too.
I ran test using
--- Comment #10 from bangerth at dealii dot org 2007-02-12 16:03 ---
Daniel, any idea?
--
bangerth at dealii dot org changed:
What|Removed |Added
CC|
--- Comment #49 from fxcoudert at gcc dot gnu dot org 2007-02-12 16:16
---
(In reply to comment #48)
Currently, there is a new ICE on CP2K (see initial comment) that happens at
any
optimisation level:
gfortran -c all_cp2k_gfortran.f90
all_cp2k_gfortran.f90:118549: internal
--- Comment #11 from dberlin at gcc dot gnu dot org 2007-02-12 16:37
---
(In reply to comment #10)
Daniel, any idea?
None.
This change actually made us more conservative with points-to, it certainly
won't cause *more* things to be optimized away.
--
--- Comment #50 from jv244 at cam dot ac dot uk 2007-02-12 17:09 ---
I really think CP2K should be added to some nightly
tester somewhere by gfortran developers...
Well, I second that, but we first need to get it working (like, the middle-end
people have to move on PR30391).
--- Comment #2 from stuart at apple dot com 2007-02-12 17:11 ---
Almost certainly my fault; I'll look into this. Suggested workaround: choose a
different target cpu; 'pentium4' works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30757
--- Comment #51 from jv244 at cam dot ac dot uk 2007-02-12 17:12 ---
I'm pretty sure it's the same problem that was already reported here:
http://gcc.gnu.org/ml/fortran/2007-02/msg00250.html
Of course, a confirmation wouldn't hurt, but I don't have time right now. If
you manage
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-12 17:14 ---
This target is known to bootstrap with 3.4.6.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30775
--- Comment #52 from pinskia at gcc dot gnu dot org 2007-02-12 17:20
---
I don't know if this triggers something, looks like a simple statement.
Yes that triggers my memory of PR 30391.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
--- Comment #35 from bergner at gcc dot gnu dot org 2007-02-12 17:29
---
Created an attachment (id=13042)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13042action=view)
Alternate patch to commutative_operand_precedence to increase the precedence of
REG_POINTER and MEM_POINTER
--- Comment #14 from fang at csl dot cornell dot edu 2007-02-12 17:31
---
I'm seeing some failures with 4.1.2-RC2 on test case pr23237.c on
powerpc7400-apple-darwin8, posted:
http://gcc.gnu.org/ml/gcc-testresults/2007-02/msg00475.html
Are these known/expected/new?
--
fang at csl
--- Comment #53 from jv244 at cam dot ac dot uk 2007-02-12 17:52 ---
(In reply to comment #52)
I don't know if this triggers something, looks like a simple statement.
Yes that triggers my memory of PR 30391.
No, that one only happens at -O1 and above, the current ICE is at -O0
--- Comment #54 from pault at gcc dot gnu dot org 2007-02-12 18:02 ---
(In reply to comment #53)
(In reply to comment #52)
I don't know if this triggers something, looks like a simple statement.
Yes that triggers my memory of PR 30391.
No, that one only happens at -O1 and
FAIL: gcc.target/i386/abi-1.c scan-assembler xmm0
Not certain if this is a code generation problem or a
test suite problem.
The generated code does not use mmx/sse registers.
verbose output:
/opt/gnu.org/gcc-4.1/bin/gcc abi-1.c -v -O1 -msse -mno-sse2 -S -o abi-1.s
Using built-in specs.
Target:
--- Comment #6 from pluto at agmk dot net 2007-02-12 18:25 ---
Created an attachment (id=13043)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13043action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052
--- Comment #55 from jv244 at cam dot ac dot uk 2007-02-12 18:26 ---
Nonetheless, I do not see it being associated with my doo-doo in module.c, do
you?
I'm not an expert, but this is a traceback, leading to module.c:
Program received signal SIGSEGV, Segmentation fault.
--- Comment #7 from pluto at agmk dot net 2007-02-12 18:27 ---
x86_64-pld-linux-g++ -c -fPIC -O2 -fno-strict-aliasing -fwrapv -march=x86-64
-fno-strict-aliasing -gdwarf-2 -g2 -Wall -W -D_REENTRANT --save-temps
-ftime-report -fmem-report -DQT_NO_DEBUG -DQT_CORE_LIB -I.
--- Comment #56 from fxcoudert at gcc dot gnu dot org 2007-02-12 18:30
---
(In reply to comment #55)
Program received signal SIGSEGV, Segmentation fault.
gfc_insert_bbt (root=0x0, new=0x7a23c80, compare=0x459ed0 compare_symtree)
at
--- Comment #3 from stuart at apple dot com 2007-02-12 18:32 ---
O.K., the breakage here is that athlon-xp is an SSE1 machine, and most of the
conversions in the patch require SSE2. It looks like SSE1 will support a few
of the new conversions (e.g. unsigned int32 = float); I'll see
--- Comment #4 from ian at airs dot com 2007-02-12 18:45 ---
Tom Tromey helped me recreate this with a cross-compiler.
I'm currently testing this patch:
Index: lower-subreg.c
===
--- lower-subreg.c (revision 121769)
--
ian at airs dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ian at airs dot com
|dot org |
Reduced from combine.c, fails if compiled with -O1 -mtune=k8, doesn't fail
with -O1 -mtune=generic.
possibly introduced between r119211 and r119769 (not sure about this).
// ---8---
extern void *memset (void *, int, unsigned
trying to find a testcase for what is currently an issue in PR29975 I ran into
this:
[EMAIL PROTECTED]:/scratch/vondele/clean/cp2k/obj/Linux-x86-64-gfortran/sdbg
gfortran t.f90
t.f90:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if
--- Comment #57 from jv244 at cam dot ac dot uk 2007-02-12 19:18 ---
Yes, that's the one: http://gcc.gnu.org/ml/fortran/2007-02/msg00250.html
for people reducing the bug, I found that it is in the module cp_fm_pool_types.
This indicates the the line number indicated in the segfault
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
|
--- Comment #3 from aoliva at gcc dot gnu dot org 2007-02-12 19:26 ---
Sorry, for some reason I had missed the e-mail with the question about this.
Yes, the check in was bogus. I still don't understand how it happened. Sorry
about that.
--
1 - 100 of 146 matches
Mail list logo
