gfortran.fortran-torture/execute/intrinsic_fraction_exponent.f90 and
gfortran.fortran-torture/execute/intrinsic_set_exponent.f90 fail at all
optimization levels on i386-netbsdelf3.0.
See http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg00860.html.
--
Summary: two testsuite failures o
--- Comment #15 from patchapp at dberlin dot org 2006-02-17 04:33 ---
Subject: Bug number PR26136
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/2006-02/msg01387.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-02-17 03:37
---
Hmm, I wonder if the following loop in scev_probably_wraps_p is wrong.
estimate_numbers_of_iterations_loop (loop);
for (bound = loop->bounds; bound; bound = bound->next)
if (proved_non_wrapping_p (at_stmt,
--- Comment #13 from law at redhat dot com 2006-02-17 02:47 ---
Subject: Re: [4.2 Regression]
25_algorithms/prev_permutation/1.cc on powerpc{64,}-linux and
powerpc-darwin
On Fri, 2006-02-17 at 01:17 +, pinskia at gcc dot gnu dot org wrote:
>
> --- Comment #12 from pins
--- Comment #6 from jde at google dot com 2006-02-17 01:23 ---
Using the source above, and gcc-4,[01], I at least get the error message, but
4.1 still dies...
gcc-4.0.1-glibc-2.3.2-i686-piii-linux-gnu-g++ -c main.cc
main.cc:7: error: ISO C++ forbids declaration of 'type' with no type
ma
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||4.0.3 4.1.0 4.2.0 3.4.6
Target Milestone|4.0.3
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-02-17 01:17
---
(In reply to comment #11)
> I've just checked in a patch which may (or may not) fix this problem;
> can you update your stor-layout.c and see if that change happens to
> fix this problem.
Nope, sorry it does not f
--- Comment #15 from sayle at gcc dot gnu dot org 2006-02-17 01:13 ---
Subject: Bug 16787
Author: sayle
Date: Fri Feb 17 01:13:38 2006
New Revision: 72
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=72
Log:
2006-02-16 Roger Sayle <[EMAIL PROTECTED]>
R. Scot
--- Comment #5 from dberlin at gcc dot gnu dot org 2006-02-17 01:04 ---
Subject: Re: [Tree-ssa] alias analysis
deficiency
On Thu, 2006-02-16 at 21:40 +, pinskia at gcc dot gnu dot org wrote:
>
> --- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-16 21:40
> --
On Thu, 2006-02-16 at 21:40 +, pinskia at gcc dot gnu dot org wrote:
>
> --- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-16 21:40
> ---
> We get:
> # bitmap_free_7 = PHI ;
> :;
>
> # bitmap_free_1 = PHI ;
> :;
> # VUSE ;
> D.1534_4 = head_3->using_obstack;
> i
Given the following code from gdb's funcargs test:
typedef struct s
{
short s;
int i;
long l;
} SVAL;
void recurse (SVAL a, int depth)
{
a.s = a.i = a.l = --depth;
if (depth == 0)
hitbottom ();
else
recurse (a, depth);
}
compiled with -g
gcc-4.0 does not emit a dwarf locatio
--- Comment #11 from law at redhat dot com 2006-02-17 00:19 ---
Subject: Re: [4.2 Regression]
25_algorithms/prev_permutation/1.cc on powerpc{64,}-linux and
powerpc-darwin
On Wed, 2006-02-15 at 15:37 +, pinskia at gcc dot gnu dot org wrote:
>
> --- Comment #7 from pinsk
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2006-02-17 00:07
---
A patch is testing and I am working up some additional test cases. The test
case in this PR is working.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26136
--- Comment #16 from hjl at gcc dot gnu dot org 2006-02-17 00:03 ---
Subject: Bug 25603
Author: hjl
Date: Fri Feb 17 00:03:06 2006
New Revision: 62
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=62
Log:
2006-02-16 Denis Nagorny <[EMAIL PROTECTED]>
PR rtl-optimi
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-16 23:46 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from jsm28 at gcc dot gnu dot org 2006-02-16 23:41 ---
Fixed for 4.2.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
--- Comment #8 from jsm28 at gcc dot gnu dot org 2006-02-16 23:40 ---
Fixed for 4.2.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
--- Comment #11 from jsm28 at gcc dot gnu dot org 2006-02-16 23:39 ---
Fixed for 4.2.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #4 from jsm28 at gcc dot gnu dot org 2006-02-16 23:38 ---
Subject: Bug 24837
Author: jsm28
Date: Thu Feb 16 23:38:44 2006
New Revision: 61
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=61
Log:
PR libstdc++/14939
PR target/20353
PR tar
--- Comment #10 from jsm28 at gcc dot gnu dot org 2006-02-16 23:38 ---
Subject: Bug 14939
Author: jsm28
Date: Thu Feb 16 23:38:44 2006
New Revision: 61
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=61
Log:
PR libstdc++/14939
PR target/20353
PR ta
--- Comment #7 from jsm28 at gcc dot gnu dot org 2006-02-16 23:38 ---
Subject: Bug 20353
Author: jsm28
Date: Thu Feb 16 23:38:44 2006
New Revision: 61
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=61
Log:
PR libstdc++/14939
PR target/20353
PR tar
--- Comment #4 from jsm28 at gcc dot gnu dot org 2006-02-16 23:38 ---
Subject: Bug 24578
Author: jsm28
Date: Thu Feb 16 23:38:44 2006
New Revision: 61
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=61
Log:
PR libstdc++/14939
PR target/20353
PR tar
--- Comment #3 from jsm28 at gcc dot gnu dot org 2006-02-16 23:29 ---
Subject: Bug 24578
Author: jsm28
Date: Thu Feb 16 23:29:10 2006
New Revision: 60
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=60
Log:
gcc:
PR target/20353
PR target/24578
PR t
--- Comment #9 from jsm28 at gcc dot gnu dot org 2006-02-16 23:29 ---
Subject: Bug 14939
Author: jsm28
Date: Thu Feb 16 23:29:10 2006
New Revision: 60
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=60
Log:
gcc:
PR target/20353
PR target/24578
PR t
--- Comment #3 from jsm28 at gcc dot gnu dot org 2006-02-16 23:29 ---
Subject: Bug 24837
Author: jsm28
Date: Thu Feb 16 23:29:10 2006
New Revision: 60
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=60
Log:
gcc:
PR target/20353
PR target/24578
PR t
--- Comment #6 from jsm28 at gcc dot gnu dot org 2006-02-16 23:29 ---
Subject: Bug 20353
Author: jsm28
Date: Thu Feb 16 23:29:10 2006
New Revision: 60
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=60
Log:
gcc:
PR target/20353
PR target/24578
PR t
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-16 21:50 ---
Fixed in 4.1.0 and above:
t.cc:8: error: reference to NsIn is ambiguous
t.cc:4: error: candidates are: namespace NsIn { }
t.cc:2: error: namespace NsOut::NsIn { }
t.cc:8: error: expected , or ...
Using floats, floor() returns wrong result, as shown in this program:
( BTW, using gcc 4.0.1 )
#include
#include
int
main()
{
floatx( 3.31682e-7 );
floaty( -292.608 );
floatz( 19.5072 );
std::cout << "Using floats, floor() returns the wrong result:" <<
std::
If there is an ambiguity with the namespace resolution, the 3.4/4.0 compiler
error message is very unclear while it was much better in 3.3 (and even 2.95):
% cat ns.cpp
namespace NsOut { namespace NsIn { struct Foo { }; } }
namespace NsIn { struct Foo { }; }
using namespace NsOut;
void foo(NsIn
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-16 21:40 ---
We get:
# bitmap_free_7 = PHI ;
:;
# bitmap_free_1 = PHI ;
:;
# VUSE ;
D.1534_4 = head_3->using_obstack;
if (D.1534_4 != 0) goto ; else goto ;
:;
# bitmap_free_6 = V_MUST_DEF ;
bitmap_free = elt_5
--- Comment #1 from jakub at gcc dot gnu dot org 2006-02-16 21:35 ---
Subject: Bug 26224
Author: jakub
Date: Thu Feb 16 21:35:38 2006
New Revision: 53
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=53
Log:
PR fortran/26224
* parse.c (parse_omp_do, parse_o
--- Comment #12 from jakub at gcc dot gnu dot org 2006-02-16 21:31 ---
Subject: Bug 26316
Author: jakub
Date: Thu Feb 16 21:31:20 2006
New Revision: 52
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=52
Log:
* openmp.c (resolve_omp_clauses): Add a dummy case label
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-16 21:25 ---
Fixed by Daniel's patches.
We get now:
:
D.1542 = xmalloc ((long unsigned int) n_basic_blocks * 4);
e = frob ();
D.1544 = e->dest;
D.1545 = D.1544->flags;
if ((D.1545 & 4) == 0) goto ; else goto ;
:;
D.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14705
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-02-16 21:17 ---
Comment #0 and #2 are fixed now by:
2006-02-16 Daniel Berlin <[EMAIL PROTECTED]>
* tree-ssa-operands.c (access_can_touch_variable): Fix typo in
previous change.
2006-02-15 Daniel Berlin <[EMAIL PR
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-16 20:41 ---
*** Bug 26328 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 2006-02-16 20:41 ---
First --with-long-double-128 does nothing on Darwin.
Second this is a dup of bug 25978.
*** This bug has been marked as a duplicate of 25978 ***
--
pinskia at gcc dot gnu dot org changed:
What|Re
--- Comment #2 from sje at cup dot hp dot com 2006-02-16 20:40 ---
This header worked with GCC 3.* but 4.0 is pickier about having an array of an
unknown type. I will submit a fixincludes patch to fix the header.
--
sje at cup dot hp dot com changed:
What|Removed
--
Summary: Timouts in libgomp tests with --with-long-double-128
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-02-16 20:17
---
And for 4.0.3 now.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Miles
--- Comment #13 from sayle at gcc dot gnu dot org 2006-02-16 20:15 ---
Subject: Bug 16787
Author: sayle
Date: Thu Feb 16 20:15:10 2006
New Revision: 47
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=47
Log:
2006-02-16 Roger Sayle <[EMAIL PROTECTED]>
R. Scot
--- Comment #11 from nathan at gcc dot gnu dot org 2006-02-16 20:12 ---
Is this still an issue in 4.1/4.2. IIUC I've cleaned up the points where this
warning was/was not being emitted.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17519
--- Comment #11 from steven at gcc dot gnu dot org 2006-02-16 20:10 ---
There was a question almost a year and a half ago, asking whether this bug is
fixed now. The question so far remains unanswered?
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from steven at gcc dot gnu dot org 2006-02-16 20:09 ---
Do we know if this bug is still present?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from steven at gcc dot gnu dot org 2006-02-16 20:04 ---
One and a half year without any activity -- what's up with this bug?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
I've few memory leaks to report and they are as follows,
ipa-inline.c in function cgraph_early_inlining. pointer 'order'
tree-if-conv.c infunction combine_blocks, returned memory.
loop-unroll.c in function referenced_in_one_insn_in_loop_p, pointer 'body'
cfgloop.c in function cancel_loop, pointer
--- Comment #6 from steven at gcc dot gnu dot org 2006-02-16 19:58 ---
Ignore my comment #5, I mis-grep-ed the insn uids :-/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26223
--- Comment #5 from steven at gcc dot gnu dot org 2006-02-16 19:51 ---
Silly question maybe, but why is reg-stack doing anything at all if -mno-80387?
Before reg-stack we have,
(insn 26 12 27 3 (set (mem/c:XF (plus:DI (reg/f:DI 6 bp)
(const_int -16 [0xfff0]
--- Comment #14 from dberlin at gcc dot gnu dot org 2006-02-16 19:46
---
So uh, has anyone figured out why we don't get 1500 with -fno-tree-pre?
Does -fno-gcse help too?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
When GCC is configured with --prefix=/opt/gnu/gcc/gcc-4.1.0,
libgnarl and libgnat are installed in
/opt/gnu/gcc/gcc-4.1.0/lib/gcc/hppa2.0w-hp-hpux11.11/4.1.0/adalib. libgcc_s.sl
is in /opt/gnu/gcc/gcc-4.1.0/lib.
-bash-2.05b$ chatr libgnat-4.1.sl
libgnat-4.1.sl:
shared library
sh
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-02-16 17:53 ---
This seems somewhat more complicated than I thought -- vectorizer actually does
not touch the statement with changed vops, it just clobbers alias info somehow
so that we are adding vops for it we did not before. I wi
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-02-16 17:44 ---
powerpc-darwin has the failure and it supports 128bit long double by default.
powerpc64-linux does not which is why I am removing it from the target.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-02-16 17:43
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-02-16 17:43
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2006-02-16 17:37
---
> Unfortunate, but confirmed. *sigh*
OK, they all fail at -O0 too, so it's very likely a front-end problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26315
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2006-02-16 17:37
---
Fixed by Zdenek.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #11 from sayle at gcc dot gnu dot org 2006-02-16 16:45 ---
Subject: Bug 16787
Author: sayle
Date: Thu Feb 16 16:45:49 2006
New Revision: 45
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=45
Log:
2006-02-16 Roger Sayle <[EMAIL PROTECTED]>
R. Scot
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-16 16:17 ---
Also I should point out this is not documented in the user manual because well
users should not be deleting directories. It is documented in the internals
manual, maybe not as big as it should be but it is there.
--- Comment #35 from pinskia at gcc dot gnu dot org 2006-02-16 16:11
---
(In reply to comment #34)
> This is a dup of bug 26323 which explains what really wants to be changed
> instead of going in circles of the current correct [documented] behavior.
--
http://gcc.gnu.org/bugzilla/
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-16 16:11 ---
*** Bug 26259 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #34 from pinskia at gcc dot gnu dot org 2006-02-16 16:11
---
This bug was orginally opened and not really explaining what happened until
comment #2 and even then it was really "You tell the doctor, it hurts when I do
this and the doctor explains, do not that then". The reas
PR 26259 raises a semi valid concern but it was not written correctly in the
first place which is why it was closed so I am opening this new one to explain
what is going on.
Toplevel directories are sometimes associated with languages via
gcc/language/config-lang.in but that associated and be remo
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Summary|--enable-languages=c,c++ not|toplevel
--- Comment #33 from gdr at gcc dot gnu dot org 2006-02-16 15:56 ---
.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #32 from gdr at gcc dot gnu dot org 2006-02-16 15:53 ---
.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2006-02-16 15:30:19
--- Comment #31 from gdr at integrable-solutions dot net 2006-02-16 15:53
---
Subject: Re: --enable-languages=c,c++ not working as expected, documented when
removing gcc/ada and libada but not gnattools
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| (In reply to comme
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-02-16 15:50 ---
*** Bug 22017 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-02-16 15:50
---
Reading the documentation for '-mrtd' I'm tempted to close this as invalid.
The
user is changing the ABI while still linking to libraries with a different ABI.
The fact that overriding builtins is not possible is
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-02-16 15:50 ---
There's a similar issue with trying to override certain builtins calling
convention with -mrtd in effect. Consider
extern void* __attribute__((__cdecl__)) memcpy(void*, void*, __SIZE_TYPE__);
we even after seeing
--- Comment #5 from rakdver at gcc dot gnu dot org 2006-02-16 15:47 ---
Subject: Bug 26296
Author: rakdver
Date: Thu Feb 16 15:47:20 2006
New Revision: 39
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=39
Log:
PR rtl-optimization/26296
* Makefile.in (loop
--- Comment #30 from pinskia at gcc dot gnu dot org 2006-02-16 15:37
---
(In reply to comment #29)
> > Again this bug is about removing two directories and then trying to build
>
> You're totally confused. The bug really is about components being built
> when they are not asked for.
--- Comment #4 from pluto at agmk dot net 2006-02-16 15:32 ---
(In reply to comment #3)
> I don't know if this is really valid code as long double on x86_64 uses 387 so
> turning off 387 explicitly says no 387 instructions. In fact I think the
> regression was caused by actually -mno-38
--- Comment #29 from gdr at gcc dot gnu dot org 2006-02-16 15:30 ---
(In reply to comment #28)
> (In reply to comment #24)
> > Since Ben is removing directories in the first place, this is the reason why
> > this is invalid and not because gnattools is being built even with
> > --enable-
--- Comment #8 from walter dot zimmer at dlr dot de 2006-02-16 15:28
---
(In reply to comment #6)
> Here is a newer patch which fixes it:
I didn't look (or even understand) what the patch does, but I can contribute
empirical evidence that the following construct:
SUBROUTINE FOO (
--- Comment #15 from rakdver at gcc dot gnu dot org 2006-02-16 15:25
---
Now fixed also in 4.1.
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from rakdver at gcc dot gnu dot org 2006-02-16 15:23
---
Subject: Bug 26209
Author: rakdver
Date: Thu Feb 16 15:23:24 2006
New Revision: 38
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=38
Log:
PR tree-optimization/26209
* tree-ssa-loop.
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-16 15:19 ---
(In reply to comment #4)
> Mark, why isn't this marked as a regression?
Most likey because I and others did not notice it was a regression and could
not tell from either the patch or the bug report it was.
--
pin
Hello gcc-bugs,
# gcc -O3 z.adb
gcc -O3 z.adb
+===GNAT BUG
DETECTED==+
| 3.3.5 (Debian 1:3.3.5-13) (i486-pc-linux-gnu) Gigi abort, Code=116
|
| Error detected at crypto-types-big_numbers.ads:309:41
|
| Please submit a
--- Comment #4 from amylaar at gcc dot gnu dot org 2006-02-16 15:13 ---
Mark, why isn't this marked as a regression? Before this patch:
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01422.html ,
we rather erred on the side of copying too much and possibly aborting.
Now we silently genera
--- Comment #25 from gdr at integrable-solutions dot net 2006-02-16 14:49
---
Subject: Re: --enable-languages=c,c++ not working as expected, documented
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| How would you guys design this?
That was explained in the several me
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-16 15:12 ---
I don't know if this is really valid code as long double on x86_64 uses 387 so
turning off 387 explicitly says no 387 instructions. In fact I think the
regression was caused by actually -mno-387 working correctly in
--- Comment #28 from pinskia at gcc dot gnu dot org 2006-02-16 15:09
---
(In reply to comment #24)
> Since Ben is removing directories in the first place, this is the reason why
> this is invalid and not because gnattools is being built even with
> --enable-language=c++.
Again this has
--- Comment #26 from gdr at integrable-solutions dot net 2006-02-16 14:52
---
Subject: Re: --enable-languages=c,c++ not working as expected, documented
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| GDR you commented on this before:
| http://gcc.gnu.org/ml/java/2000-1
--- Comment #27 from gdr at gcc dot gnu dot org 2006-02-16 14:54 ---
see comment #12.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLV
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-02-16 14:12
---
Confirmed.
Even simpler testcase (crashes with "gcc -mno-80387"):
===
long double foo(long double x) { return x; }
===
--
--- Comment #6 from eedelman at gcc dot gnu dot org 2006-02-16 14:12
---
With Philippe's testcase, I can reproduce the problem on my system now.
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from P dot Schaffnit at access dot rwth-aachen dot de
2006-02-16 14:08 ---
Created an attachment (id=10862)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10862&action=view)
Sources which exhibit this behaviour (under 32-bit linux)
Hi!
Here's something that exhibit
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-02-16 13:57
---
Thread for the PR 8866 fix:
http://gcc.gnu.org/ml/gcc-patches/2003-04/msg01438.html
Though I am wondering why do people think it could not trap because it can if
it was moved. Seems like NoTrap is useless in gene
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-02-16 13:54
---
The NOTRAP was added when PR 8866 was fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #9 from rakdver at gcc dot gnu dot org 2006-02-16 13:53 ---
Given that do_tablejump was the very first setter of MEM_NOTRAP_P, it is not
likely that it would be the wrong one (unless all other setters that came later
chose the other possible semantics).
--
http://gcc.gnu
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-02-16 13:47 ---
/* Generate a memory referring to non-trapping constant memory. */
Which might mean that do_tablejump is using it wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26316
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-02-16 13:42 ---
http://gcc.gnu.org/ml/gcc/2005-09/msg00021.html
There are most likely other talk here too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26316
--- Comment #4 from ben dot midgley at ultra-datel dot com 2006-02-16
13:41 ---
Subject: RE: Accessing array embedded in a record with
representation clause
Appologies just re-read, paying attention this time.
-Original Message-
From: pinskia at gcc dot gnu dot org [mail
--- Comment #6 from rakdver at gcc dot gnu dot org 2006-02-16 13:38 ---
Sadly, Jakub is probably right -- since the very beginning, MEM_NOTRAP_P was
used to mean that the mem cannot trap in its current context. This makes
MEM_NOTRAP_P completely useless as far as code motion is concerne
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-02-16 13:36
---
It all looks like a mess wrt -mrtd, I'm not going to touch this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22017
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-16 13:35 ---
(In reply to comment #4)
> The MEM is marked as MEM_NOTRAP_P, by do_tablejump -> gen_const_mem.
> Still, IMHO you can't do that, otherwise we couldn't mark any MEM
> as MEM_NOTRAP_P unless it has constant operand. I
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-02-16 13:34
---
A similar issue is in PR11772 - we fail to account for -mrtd when expanding
calls to builtin functions or functions from libgcc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22017
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-02-16 13:25
---
The problem is we cannot simply use (implicit_)built_in_decl[BUILT_IN_MEMCPY]
here
either because that one is still the internal one, and if annotating our memcpy
decl with __attribute__((__cdecl__)) we warn:
/tmp
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-02-16 13:22
---
The problem is that we do not honour the override decl for memcpy simply
because
for expand_call ("foo(&i, st);") we end up in emit_block_move_via_libcall which
builds yet another "memcpy" decl via expr.c:init_bloc
1 - 100 of 127 matches
Mail list logo
