--- Comment #2 from steven at gcc dot gnu dot org 2008-01-08 08:37 ---
Let's bring this problem to Jakub's attention...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ubizjak at gmail dot com 2008-01-08 08:42 ---
Hm, I don't see the reason, why this is a regression. What this PR shows is the
limitation of the precision of rcpss instruction.
Actually, this 2ulp precision is the reason, why -mrecip is not enabled by
default for
--- Comment #3 from jakub at gcc dot gnu dot org 2008-01-08 08:46 ---
Just have to agree with Andrew, the code is buggy, fprintf etc. really are
allowed to be defined as macros. That said, glibc 2.7 and later when used with
gcc 4.3 and later uses inline functions instead of macros even
--- Comment #4 from jakub at gcc dot gnu dot org 2008-01-08 08:49 ---
The easiest fix is to use (p.fprintf)(p, %i, 123); instead of
p.fprintf(p, %i, 123); whenever using some identifier which POSIX allows to
be defined as function-like macro, BTW.
--
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-08 09:22 ---
Patch by Paul: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00269.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34681
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-08 09:22 ---
Patch by Paul: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00269.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34704
--- Comment #25 from rguenth at gcc dot gnu dot org 2008-01-08 09:55
---
The unroll problem is that if you have multiple loops like
for (i=0; i3; ++i)
a[i] = i;
...
for (i=0; i3; ++i)
a[i] = i;
then even though we are in loop closed SSA form, we rename all
--- Comment #5 from jv244 at cam dot ac dot uk 2008-01-08 09:52 ---
updated the summary after the analysis in comment #4, and and CCed Dorit for
the vectorization issue.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #24 from rguenth at gcc dot gnu dot org 2008-01-08 09:46
---
The patch in comment #14 reduces compile time from 120s to 80s. I'll try to
get it into shape.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
--- Comment #2 from dominiq at lps dot ens dot fr 2008-01-08 09:46 ---
I don't think either that this is a regression, only a bad side effect. A
possibility to overcome it would be to change the way theNewton-Raphson
iteration is computed. Presently it seems to be x1=x0*(2.0-x*x0) which
--- Comment #3 from dominiq at lps dot ens dot fr 2008-01-08 10:17 ---
I just had a look to the doc patch in
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00273.html:
...
+Note that while the throughput of the sequence is higher than the throughput
+of the non-reciprocal instruction,
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-08 10:27 ---
I have a working patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-08 10:26 ---
I think we want to account PHI nodes as real copies instead (d-count +=
PHI_NUM_ARGS (...)) -- if they involve real operands (not VOPs).
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-08 10:17 ---
I agree, this is not a regression, but a documentation issue (patch was
posted).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-08 10:21 ---
No idea if Uros has access to spec, so maybe you can quote the snippet where
rsqrtss is used from the assembly of 481.wrf?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34709
--- Comment #4 from pault at gcc dot gnu dot org 2008-01-08 10:31 ---
Created an attachment (id=14898)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14898action=view)
A fix and testcase for this PR
This is regtesting right now.
Paul
--
--- Comment #26 from rguenth at gcc dot gnu dot org 2008-01-08 11:06
---
We do a _lot_ of calls to var_ann during the compilation:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds secondscalls s/call s/call
--- Comment #2 from ubizjak at gmail dot com 2008-01-08 11:23 ---
(In reply to comment #1)
No idea if Uros has access to spec, so maybe you can quote the snippet where
rsqrtss is used from the assembly of 481.wrf?
Unfortunatelly no... does this patch help:
Index: i386.c
--- Comment #27 from rguenth at gcc dot gnu dot org 2008-01-08 12:13
---
Subject: Bug 34683
Author: rguenth
Date: Tue Jan 8 12:12:56 2008
New Revision: 131393
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131393
Log:
2008-01-08 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #29 from steven at gcc dot gnu dot org 2008-01-08 12:18 ---
Re. comment #26
More proof that assert checking _is_ expensive. I wonder how much compile time
can be blamed overall on release checking (i.e. checking disabled vs. release
checking).
Have you ever compared e.g.
--- Comment #5 from hubicka at ucw dot cz 2008-01-08 12:15 ---
Subject: Re: Inlining heuristics issue
I think we want to account PHI nodes as real copies instead (d-count +=
PHI_NUM_ARGS (...)) -- if they involve real operands (not VOPs).
We ignore cost of MODIFY_EXPR in assumption
--- Comment #28 from steven at gcc dot gnu dot org 2008-01-08 12:17 ---
Re. comment #26
More proof that assert checking _is_ expensive. I wonder how much compile time
can be blamed overall on release checking (i.e. checking disabled vs. release
checking).
Have you ever compared e.g.
--- Comment #6 from rguenther at suse dot de 2008-01-08 12:21 ---
Subject: Re: Inlining heuristics issue
On Tue, 8 Jan 2008, hubicka at ucw dot cz wrote:
--- Comment #5 from hubicka at ucw dot cz 2008-01-08 12:15 ---
Subject: Re: Inlining heuristics issue
I think we
--- Comment #7 from hubicka at ucw dot cz 2008-01-08 12:22 ---
Subject: Re: Inlining heuristics issue
With some experimentation, the PHI change makes the costs to go up in
quite weird ways not taking into account that most of PHIs are
elliminated by coalescing. So I will stay with
--- Comment #1 from pault at gcc dot gnu dot org 2008-01-08 12:57 ---
This is fixed in a patch that I am working on that sorts out the whole business
of function characteristics in one go.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed
--- Comment #11 from steven at gcc dot gnu dot org 2008-01-08 12:53 ---
Created an attachment (id=14899)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14899action=view)
Reject combination of -fno-unit-at-a-time and -finline-functions-called-once
Untested, but shows how easy it
--- Comment #30 from rguenth at gcc dot gnu dot org 2008-01-08 12:30
---
No, I didn't. But yes, overzealous asserts in the simple inline accessor
functions are probably counter-productive. For example things like
static inline bool
gimple_aliases_computed_p (const struct function
--- Comment #5 from steven at gcc dot gnu dot org 2008-01-08 12:40 ---
Would be nice if someone could analyze this, or at least reconfirm that the
problem still exists.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #31 from rguenth at gcc dot gnu dot org 2008-01-08 12:55
---
Another hot assert is
static inline tree
memory_partition (tree sym)
{
tree tag;
/* MPTs belong to their own partition. */
if (TREE_CODE (sym) == MEMORY_PARTITION_TAG)
return sym;
gcc_assert
--- Comment #2 from pault at gcc dot gnu dot org 2008-01-08 12:57 ---
This is fixed in a patch that I am working on that sorts out the whole business
of function characteristics in one go.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from pault at gcc dot gnu dot org 2008-01-08 12:58 ---
This is fixed in a patch that I am working on that sorts out the whole business
of function characteristics in one go.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from amacleod at redhat dot com 2008-01-08 13:27 ---
yes, many PHIs are eliminated by coalescing. If you wanted to experiment at
some point for more accuracy, you can look at the PHI arguments. Any argument
which has a different base name than the LHS of the PHI, or is a
--- Comment #32 from steven at gcc dot gnu dot org 2008-01-08 13:08 ---
You are of course right that for this test case the bigger win is in the
algorithmic issues.
On the other hand, for compile time in general, the gcc_asserts are IMHO the
worst thing that happened to GCC since the
--- Comment #8 from jakub at gcc dot gnu dot org 2008-01-08 13:02 ---
Created an attachment (id=14900)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14900action=view)
openbabel_perl.ii.bz2
Here is the original testcase, compile on ppc64-linux or with - ppc64-linux
cross, with -O2
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-08 13:35 ---
Reconfirmed.
Flat profile:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds secondscalls s/call s/call name
23.89 41.61
--- Comment #11 from hjl at lucon dot org 2008-01-08 13:56 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00294.html
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #5 from uros at gcc dot gnu dot org 2008-01-08 13:51 ---
Subject: Bug 34702
Author: uros
Date: Tue Jan 8 13:50:14 2008
New Revision: 131394
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131394
Log:
PR target/34702
* doc/invoke.texi (i386 and x86-64
--- Comment #10 from hubicka at ucw dot cz 2008-01-08 14:14 ---
Subject: Re: Inlining heuristics issue
yes, many PHIs are eliminated by coalescing. If you wanted to experiment at
some point for more accuracy, you can look at the PHI arguments. Any argument
which has a different
--- Comment #6 from ubizjak at gmail dot com 2008-01-08 14:02 ---
(In reply to comment #3)
It looks nice, but could you add (after converting my frenglish) something
along the line in particular the inverse of 1.0 is no longer 1.0, but
0.9994 (or nearest(1.0,-1.0) or its C*
--- Comment #7 from dominiq at lps dot ens dot fr 2008-01-08 14:20 ---
the NR enhanced reciprocals provide adequate precision with great speedup
Two quick remarks along this line:
(1) On Core2Duo the speedup is not obvious for the polyhedron testsuite,
excepted for gas_dyn 7.7s vs.
--- Comment #7 from dnovillo at gcc dot gnu dot org 2008-01-08 14:24
---
Will work on this.
--
dnovillo at gcc dot gnu dot org changed:
What|Removed |Added
=/usr/include
--with-mpfr-lib=/usr/lib --enable-languages=c++,fortran
--enable-checking=release
Thread model: posix
gcc version 4.3.0 20080108 (experimental) [trunk revision 131394] (GCC)
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic'
/afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux
--- Comment #3 from pault at gcc dot gnu dot org 2008-01-08 15:13 ---
Subject: Bug 34681
Author: pault
Date: Tue Jan 8 15:12:34 2008
New Revision: 131395
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131395
Log:
2008-01-08 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #3 from pault at gcc dot gnu dot org 2008-01-08 15:13 ---
Subject: Bug 34704
Author: pault
Date: Tue Jan 8 15:12:34 2008
New Revision: 131395
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131395
Log:
2008-01-08 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #5 from pault at gcc dot gnu dot org 2008-01-08 15:15 ---
Subject: Bug 34476
Author: pault
Date: Tue Jan 8 15:14:33 2008
New Revision: 131396
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131396
Log:
2008-01-08 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #4 from pault at gcc dot gnu dot org 2008-01-08 15:15 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pault at gcc dot gnu dot org 2008-01-08 15:16 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pault at gcc dot gnu dot org 2008-01-08 15:16 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #45 from bergner at gcc dot gnu dot org 2008-01-08 15:44
---
This has been fixed in mainline (4.3), but has not been fixed in 4.2. I'm ok
with not back porting this to 4.2. I'll give everyone a few days to object,
otherwise I'll change the Target Milestone to 4.3 and
--- Comment #30 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-08
15:51 ---
Subject: Re: wo_prof_two_strs.c:56: internal compiler error: in
find_new_var_of_type, at ipa-struct-reorg.c:605
Subject: Re: wo_prof_two_strs.c:56: internal compiler
error: in find_new_var_of_type,
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29469
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #7 from steven at gcc dot gnu dot org 2008-01-08 16:26 ---
This is marked as a regression -- but from what? Did this work in GCC 4.2?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from steven at gcc dot gnu dot org 2008-01-08 16:20 ---
Diego,
Is this something you plan to work on for GCC 4.3?
Does this still qualify as a 4.3 regression?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29607
--- Comment #2 from jakub at gcc dot gnu dot org 2008-01-08 16:11 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from jakub at gcc dot gnu dot org 2008-01-08 16:11 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from jakub at gcc dot gnu dot org 2008-01-08 16:09 ---
Subject: Bug 34694
Author: jakub
Date: Tue Jan 8 16:08:24 2008
New Revision: 131398
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131398
Log:
PR middle-end/34694
* omp-low.c (copy_var_decl):
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Last reconfirmed|2006-08-11 13:29:43 |2008-01-08
--- Comment #4 from jakub at gcc dot gnu dot org 2008-01-08 16:07 ---
Subject: Bug 33890
Author: jakub
Date: Tue Jan 8 16:06:31 2008
New Revision: 131397
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131397
Log:
PR c++/33890
* semantics.c (finish_omp_for): Don't
--- Comment #17 from steven at gcc dot gnu dot org 2008-01-08 16:14 ---
Does anyone know how to reproduce this with a cross-compiler?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944
--- Comment #17 from dnovillo at google dot com 2008-01-08 16:23 ---
Subject: Re: [4.3 Regression] alias set partitioning dependent on SFT
DECL_UIDs
On 8 Jan 2008 16:20:39 -, steven at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
Diego,
Is this something you plan to work on for
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-01-08 16:49 ---
I would suggest to go with the patch in comment #3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763
--- Comment #18 from rguenth at gcc dot gnu dot org 2008-01-08 16:29
---
The testcase reproduces for me on a x86_64 - hppa64-linux cross on trunk
with -O2 -fno-inline-small-functions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944
--- Comment #1 from steven at gcc dot gnu dot org 2008-01-08 17:08 ---
*** This bug has been marked as a duplicate of 34314 ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2008-01-08 17:08 ---
*** Bug 34606 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from rguenth at gcc dot gnu dot org 2008-01-08 16:40
---
I don't think anything is wrong with 'alias set partitioning dependent on SFT
DECL_UIDs'. If two SFTs score equal we need to discriminate them somehow.
DECL_UID is exactly the right thing to use for this.
Note
--- Comment #20 from steven at gcc dot gnu dot org 2008-01-08 16:36 ---
So this bug was worked around -- but can this be fixed properly for GCC 4.3?
Richi, is this just another example of the SFT problems reported in other PRs?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31863
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-01-08 16:45 ---
Yes, this doesn't ICE for me for 4.2.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from rguenth at gcc dot gnu dot org 2008-01-08 16:54
---
Well, the many SFTs don't help the situation for sure. But we can't do
anything
for 4.3 here, as only after walking all the fields in push_fields_to_fieldstack
we figure out we better not generate SFTs here.
--- Comment #33 from rguenth at gcc dot gnu dot org 2008-01-08 16:29
---
Subject: Bug 34683
Author: rguenth
Date: Tue Jan 8 16:29:14 2008
New Revision: 131400
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131400
Log:
2008-01-08 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #20 from rguenth at gcc dot gnu dot org 2008-01-08 17:18
---
Lets just close this as fixed then, as the problem went away.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from steven at gcc dot gnu dot org 2008-01-08 17:21 ---
OK. I was asking because of the final remark in comment #11. Let's close this
as fixed because the test suite failure is gone and it's unclear what's left to
work on.
--
--- Comment #6 from manu at gcc dot gnu dot org 2008-01-08 17:26 ---
(In reply to comment #3)
I also counted about 300 similar cases where Intel
produced warning #593. I think there is quite a bit
of pointless computation going on.
Thanks. I think optimisers should remove all of
--- Comment #7 from rguenther at suse dot de 2008-01-08 17:27 ---
Subject: Re: [4.1/4.2/4.3 Regression] Bogus
inlining failed in call to `xxx': redefined extern inline functions are not
considered for inlining
On Tue, 8 Jan 2008, jakub at gcc dot gnu dot org wrote:
--- Comment
--- Comment #2 from manu at gcc dot gnu dot org 2008-01-08 17:13 ---
It works.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #6 from jakub at gcc dot gnu dot org 2008-01-08 17:25 ---
So do I and even am using that patch for quite some time in our gcc packages.
But Mark objected to that:
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00589.html
The current state of things is bad, because with glibc
--- Comment #19 from dnovillo at google dot com 2008-01-08 17:06 ---
Subject: Re: [4.3 Regression] alias set partitioning dependent on SFT
DECL_UIDs
I don't think anything is wrong with 'alias set partitioning dependent on SFT
DECL_UIDs'. If two SFTs score equal we need to
--- Comment #3 from manu at gcc dot gnu dot org 2008-01-08 17:08 ---
Waiting for feedback.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2008-01-08 17:10
---
Michael, any reason for being so scrupulous and not forcing the mode?
Index: expr.c
===
--- expr.c (revision 131326)
+++ expr.c (working
--- Comment #4 from manu at gcc dot gnu dot org 2008-01-08 17:46 ---
Waiting for feedback.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from manu at gcc dot gnu dot org 2008-01-08 17:55 ---
I think the consensus is clear on what needs to be done. So this is confirmed.
Just needs someone to do it. Unfortunately, given the huge amount of open
issues, I would guess that making undefined code work is quite
--- Comment #4 from manu at gcc dot gnu dot org 2008-01-08 17:30 ---
(In reply to comment #3)
Most of them will be fixed by:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00447.html
I still have to decide if we want to remove ggc_stats or not.
As far as I can see this patch was
--- Comment #3 from hjl at lucon dot org 2008-01-08 18:01 ---
(In reply to comment #2)
(In reply to comment #1)
No idea if Uros has access to spec, so maybe you can quote the snippet where
rsqrtss is used from the assembly of 481.wrf?
Unfortunatelly no... does this patch help:
Snapshot gcc-4.3-20080104, gcc-4.3-20071109.
Test code below. When 'inline' modifier and 'always_inline' attribute are used
only in the definition of min, inlining does not appear to happen (and no
error is output). When I add the modifier and attribute to the declaration of
min, inlining does
--- Comment #4 from hjl at lucon dot org 2008-01-08 18:24 ---
(In reply to comment #2)
BTW: What happens if -mrecip is used to compile 481.wrf?
-O2 -mrecip -ffast-math miscompiles 481.wrf on Linux/Intel64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34709
--- Comment #5 from ubizjak at gmail dot com 2008-01-08 18:36 ---
(In reply to comment #3)
It works.
Ok, then we have the same issue with rsqrtss as with rcpss in PR target/34702.
I'll disable -mrecip as default for -ffast-math.
--
ubizjak at gmail dot com changed:
--- Comment #6 from pluto at agmk dot net 2008-01-08 19:00 ---
(In reply to comment #5)
Mine, but this will not get in until around the 25th.
ping ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34212
--- Comment #6 from uros at gcc dot gnu dot org 2008-01-08 19:23 ---
Subject: Bug 34709
Author: uros
Date: Tue Jan 8 19:22:46 2008
New Revision: 131403
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131403
Log:
PR target/34709
Revert:
2008-01-05 Uros
--- Comment #7 from ubizjak at gmail dot com 2008-01-08 19:27 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from aleksey dot shipilev at gmail dot com 2008-01-08 19:07
---
Created an attachment (id=14901)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14901action=view)
test used in issue
This test was derived from powertweak code, which segfaults.
--
When building application (namely, powertweak) with gcc 4.1.2 using -02,
application experiences segfault during startup. When building in the same
configuration but using -O1, all works fine.
Attached microtest (test.c) which resembles the problem:
# gcc test.c ./a.out
before: output=bff74f74,
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2008-01-08 19:04
---
This may be fixable employing gfc_trans_assignment at the right place similar
to the fix Paul used in PR34438. I have not time to chase this. Un-assigning.
--
jvdelisle at gcc dot gnu dot org changed:
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-08 19:35 ---
I always get:
before: output=bfda12b4, buf=bfda10b4
after: output=bfda12b4, buf=bfda10b4
sizeof(buf)=512
result=-1
I really don't think this is a GCC bug.
--
--- Comment #13 from pluto at agmk dot net 2008-01-08 19:44 ---
Created an attachment (id=14903)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14903action=view)
testacase for /opt/gcc43/bin/g++ 32395.ii -Wall -c -O1 -m32
--
pluto at agmk dot net changed:
What
--- Comment #3 from aleksey dot shipilev at gmail dot com 2008-01-08 19:47
---
Sorry, Andrew, but result=-1 shows that ioctl failed to read enough data from
the device (maybe your device does not support SMART?). I tried to get rid of
any of such hardware-specific code, but can't
--- Comment #7 from sascha-web-gcc dot gnu dot org at silbe dot org
2008-01-08 19:29 ---
Created an attachment (id=14902)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14902action=view)
another asm code block triggering the error
Just been hit by this after upgrading to Ubuntu
--- Comment #8 from eric dot weddington at atmel dot com 2008-01-08 19:49
---
(In reply to comment #7)
Created an attachment (id=14902)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14902action=view) [edit]
another asm code block triggering the error
Just been hit by this
Ada runtime of gcc trunk (r131371) does not have OpenBSD specific sections, so
the pthreads library and related features are not used/enabled on OpenBSD.
Patch at http://iki.fi/tero.koskinen/gcc/gcc-ada-gnattools-tasking.diff adds
files a-intnam-openbsd.ads, g-soccon-openbsd.ads,
1 - 100 of 145 matches
Mail list logo
