I have been looking at the source in
class.c:
clone_function_decl()
clone_constructors_and_destructors()
pt.c:
check_explicit_specialization()
In pt.c: check_explicit_specialization() it specifically requests that
the clone function of a specialised constructor NOT add the new clone
Zdenek Dvorak [EMAIL PROTECTED] writes:
for project http://gcc.gnu.org/wiki/PreservingLoops, I am considering
introducing a tree LOOP_HEADER with single argument N (number of
iterations of the loop), that would be present in IL at the beginning of
header of each loop. I have following
Hello,
quite a lot at the moment). To keep the information valid, we need
to prevent optimizations from destroying it (e.g., if the number
is n_1 = n_2 - 1, and this is the last use of n_1, we do not want
DCE to remove it); this is easy to achieve if n_1 would be the
You are proposing to complete the ssa representation such that
foreach_ssa_uses also iterates over the niter information (a bit like vrp
modifies the ssa chains with its extra assert information). Wouldn't it
be possible to not insert this niter information in the representation of
the
Hello,
You are proposing to complete the ssa representation such that
foreach_ssa_uses also iterates over the niter information (a bit like vrp
modifies the ssa chains with its extra assert information). Wouldn't it
be possible to not insert this niter information in the representation
Hi all,
i want to make a statistic(i haven't found one) over linux source
code, and i want to know how many times expressions are simplified by
gcc.
I've found that -O -ftree-dominator-opts -fdump-tree-optimized
writes a file optimized, now if i can compare it with a not optimized
one i win,
Hello,
at the moment, RTL level loop optimizers and most of the tree-level loop
optimizers do not have assigned specific maintainers. I think this
clearly starts to become a significant problem -- many of the
loop-optimizer related patches in 4.2 timeframe remained unreviewed (the
vectorizer
Hi Andrew,
On Wed, 25 Oct 2006, Andrew Haley wrote:
I must admit to being a little perplexed by this.
We have an unsafe optimization that causes bad code to be generated on
at least one platform. However, we want to continue to perform this
unsafe optimization on our release branch until
Dino Puller [EMAIL PROTECTED] writes:
i want to make a statistic(i haven't found one) over linux source
code, and i want to know how many times expressions are simplified by
gcc.
I don't think any of us know what you mean by how many times
expressions are simplified. Can you be more
Hello,
for project http://gcc.gnu.org/wiki/PreservingLoops, I am considering
introducing a tree LOOP_HEADER with single argument N (number of
iterations of the loop), that would be present in IL at the beginning of
header of each loop. I have following motivations:
1) One of the goals of the
Eric Botcazou [EMAIL PROTECTED] writes:
Also, having patches on mainline and not a release branch can cause
quite a bit of confusion. Witness what happend with PR 28243, where I
fixed something on mainline, but it was not directly approved for a
release branch. Then Eric B. worked around the
Eric Botcazou wrote:
Lots of people seem to test release branches -- probably more than mainline
-- and I would hope that using the fix from this PR is by far the strongest
contender.
Definitely. People report bugs against released versions and expect fixes for
these versions, not for
David Daney wrote:
Eric Botcazou wrote:
Lots of people seem to test release branches -- probably more than
mainline
-- and I would hope that using the fix from this PR is by far the
strongest contender.
Definitely. People report bugs against released versions and expect
fixes for these
Hello,
for project http://gcc.gnu.org/wiki/PreservingLoops, I am considering
introducing a tree LOOP_HEADER with single argument N (number of
iterations of the loop), that would be present in IL at the beginning of
header of each loop. I have following motivations:
1) One of the goals of
Hello,
for project http://gcc.gnu.org/wiki/PreservingLoops, I am considering
introducing a tree LOOP_HEADER with single argument N (number of
iterations of the loop), that would be present in IL at the beginning of
header of each loop. I have following motivations:
1) One of the
On Tue, Oct 10, 2006 at 11:21:41AM -0500, Menezes, Evandro wrote:
H.J., do you have the i386 psABI in source form somewhere I could get
it, to make the corresponding changes?
Actually, it's about an extension to the i386 psABI and it's an idea still in
its infancy:
On Wed, 25 Oct 2006, Richard Sandiford wrote:
Roger Sayle [EMAIL PROTECTED] writes:
Once explained, I'd expect most maintainers would make precisely the
same call?
I suppose the counter-argument is that we shouldn't ship 4.2 in its
current state. We should either back out the patch that
Finally before I finish the retrospective part of this e-mail, I'll
point out this isn't a sudden recent unilateral policy decision, but
purely a crystallization of the prescribed GCC work-flow outlined in
contributing.html that has been refined over many years.
I disagree. I've been working
Hello,
So, the passes that maniuplate loop structure need to know about
LOOP_HEADER and others do not need to worry about LOOP_HEADER.
More acurately, the passes that manipulate the cfg. Right now most of
these passes don't even know they modify the loop structure.
Now, focusing on the
On 10/25/06, Zdenek Dvorak [EMAIL PROTECTED] wrote:
Hello,
So, the passes that maniuplate loop structure need to know about
LOOP_HEADER and others do not need to worry about LOOP_HEADER.
More acurately, the passes that manipulate the cfg. Right now most of
these passes don't even know they
and seeing the reaction of people,
I probably won't use it. The main reason for considering to use
the tree node for me was the possibility to make the number of iterations
of the loop as its operand, so that I would not need to worry about
keeping it alive through dce, copy/constant
Eric Botcazou wrote:
Finally before I finish the retrospective part of this e-mail, I'll
point out this isn't a sudden recent unilateral policy decision, but
purely a crystallization of the prescribed GCC work-flow outlined in
contributing.html that has been refined over many years.
I've
On 10/25/06, Andrew Pinski [EMAIL PROTECTED] wrote:
and seeing the reaction of people,
I probably won't use it. The main reason for considering to use
the tree node for me was the possibility to make the number of iterations
of the loop as its operand, so that I would not need to worry
On 10/25/06, Devang Patel [EMAIL PROTECTED] wrote:
One way to achieve this is to mark n_1 (in your example) as
do not dead strip because I know it is used , kind of attribute((used)).
This is what as I understand LOOP_HEADER is used for.
Big difference. New tree vs TREE_USED or
On 10/25/06, Zdenek Dvorak [EMAIL PROTECTED] wrote:
it definitely is not the only way, and seeing the reaction of people,
I probably won't use it. The main reason for considering to use
the tree node for me was the possibility to make the number of iterations
of the loop as its operand, so that
On 10/25/06, Steven Bosscher [EMAIL PROTECTED] wrote:
So you would mark n_1 with TREE_USED, and never let it be removed?
What would happen if e.g. the entire loop turns out to be dead code?
Or if the loop is rewritten (e.g. vectorized) in a way that changes
the number of iterations of the loop?
For many years, the default gcc compile options for C code generated
by Gambit, the Scheme-C compiler, were very simple (-O1 -fschedule-
insns2 -fno-math-errno -fno-trapping-math) and I didn't have problems
with gcc's space requirements to compile those files. (I often ran
into complexity
Hello,
On 10/25/06, Steven Bosscher [EMAIL PROTECTED] wrote:
So you would mark n_1 with TREE_USED, and never let it be removed?
What would happen if e.g. the entire loop turns out to be dead code?
Or if the loop is rewritten (e.g. vectorized) in a way that changes
the number of iterations
On Wed, 2006-10-25 at 13:01 -0700, Devang Patel wrote:
However, various optimizer needs to know about this special tree node.
not really (not any more than they know about other tree codes that are
not interesting for them).
If we take an example of Jump Threading pass then it needs to
On Thu, 2006-10-26 at 00:45 +0200, Zdenek Dvorak wrote:
actually, that will be trivial once jump threading updates loop properly
(I have a patch for that).
I'd like to see that.
I recall poking at having threading update things like loop exit
points and gave up. The problem is you could
Hi all,
Well after trying numerous different approaches to find the
FUNCTION_DECL node for a constructor like MyClass::MyClass(int) from a
FUNCTION_DECL node for one of the constructors: MyClass::__comp_ctor
(int) or similar, I have found that there is a VERY simple way to do
this using
Hello,
On Thu, 2006-10-26 at 00:45 +0200, Zdenek Dvorak wrote:
actually, that will be trivial once jump threading updates loop properly
(I have a patch for that).
I'd like to see that.
I recall poking at having threading update things like loop exit
points and gave up. The problem is
Bonjour
Est ce que votre organisation (gcc) utilise ou prévoit utiliser le
télémarketing à court ou moyen terme ?
Nous pouvons vous aider.
Visiter le http://www.telemarketing.ca.cx/
Agence de télémarketing JL, est une entreprise qui se spécialise depuis
plus de 20 ans dans l'exécution de
--- Comment #5 from kloedej at knmi dot nl 2006-10-25 07:16 ---
Thanks for your additional explanation, and the link to the original mail in
the mailing list.
A last remark on my side is then about the actual text of this error message.
People not familiar with the choice made in the
--- Comment #5 from pault at gcc dot gnu dot org 2006-10-25 07:18 ---
This fixes it but has not been regtested. I was hoping to have found a
slightly cleaner way to fix this but did not alight on anything that would not
be a big performance. It's OK for rank 1 arrays but for rank 2
--- Comment #6 from uros at kss-loka dot si 2006-10-25 07:33 ---
Revision 118024 clears the way for MOD and MODULO implementation:
http://gcc.gnu.org/ml/gcc-cvs/2006-10/msg00703.html
BTW: I don't know fortran requirements, but built-in functions produce faster
code if errno is not
--- Comment #3 from keinstein_junior at gmx dot net 2006-10-25 07:41
---
Created an attachment (id=12488)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12488action=view)
one failing and one working set of .mod files
In the tar archive there are two subtrees:
src-ICE has all
--- Comment #13 from kreckel at ginac dot de 2006-10-25 07:54 ---
(In reply to comment #12)
It doesn't disappear with -fno-tree-ter, as I would assume if it were a TER
bug.
I just discovered that it does disappear with -fno-tree-sink, though.
--
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-10-25 07:57
---
So what is happening is there explict barrier for the divide so we assume we
can move it. I don't know what the correct thing is really, scheduling will
have the same issue and so will being able to delete the
--- Comment #9 from bonzini at gnu dot org 2006-10-25 08:11 ---
Subject: Bug 29092
Author: bonzini
Date: Wed Oct 25 08:11:26 2006
New Revision: 118025
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118025
Log:
2006-10-25 Paolo Bonzini [EMAIL PROTECTED]
PR c/29092
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-10-25 08:19
---
I'm adding Steve Kargl to the CC list, since he's our arithmetics expert :)
(In reply to comment #6)
Revision 118024 clears the way for MOD and MODULO implementation:
--- Comment #3 from vladimir at codesourcery dot com 2006-10-25 08:54
---
I've confirmed that the patch does adds the exe extension for
$target-gcc-$version, when building arm-none-eabi.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28400
--- Comment #4 from uros at gcc dot gnu dot org 2006-10-25 10:14 ---
Subject: Bug 28909
Author: uros
Date: Wed Oct 25 10:14:41 2006
New Revision: 118028
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118028
Log:
PR target/28909
* config/i386/sync.md (sync_addmode,
--- Comment #8 from uros at kss-loka dot si 2006-10-25 11:48 ---
(In reply to comment #7)
Just to be sure I understand: we are garanteed that BUILT_IN_REMAINDER{F,,L}
and BUILT_IN_FMOD{F,,L} are always available, right?
Yes. The expansion does not depend on -ffast-math anymore.
--- Comment #6 from uros at kss-loka dot si 2006-10-25 12:04 ---
(In reply to comment #5)
With more registers (x86_64) the stack moves are gone, but: (!)
(testing done on AMD Athlon fam 15 model 35 stepping 2)
On Xeon 3.6, SSE is now faster:
gcc -O2 -march=pentium4 -mfpmath=387
On 25 Oct 2006 05:23:00 -, pinskia at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-25 05:22 ---
_ZTCN33_GLOBAL__N_t.cc__2292CFAC11NullostreamE0_13basic_ostream
# _ZTI13basic_ostream = V_MAY_DEF
--- Comment #5 from dberlin at gcc dot gnu dot org 2006-10-25 12:12 ---
Subject: Re: [4.2/4.3 Regression] tree check: expected ssa_name, have var_decl
in is_old_name, at tree-into-ssa.c:558
On 25 Oct 2006 05:23:00 -, pinskia at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #7 from uros at kss-loka dot si 2006-10-25 12:18 ---
(In reply to comment #6)
On Xeon 3.6, SSE is now faster:
... but for -ffast-math:
SSE: user0m0.756s
x87: user0m0.612s
Yes, x87 is faster for -ffast-math by some 20%.
--
--- Comment #3 from JoeGTN1 at NetZero dot net 2006-10-25 12:44 ---
I think the pertinent part of this bug is:
Is it possible to split this file?
It took 6-8 hours to compile this file alone on my xbox, which only has 64m
of memory but should be considered a sufficiently modern
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-25 13:09 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #15 from kreckel at ginac dot de 2006-10-25 13:22 ---
(In reply to comment #14)
Maybe scheduling would have the same issue. The fact that the result of the
division is not used is a red herring, though. Of course, the assumption is
that it's actually used.
--
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-10-25 13:53
---
(In reply to comment #8)
In the later case, expansion will fall-back to normal library call.
OK. So on system where the math library doesn't have remainderl, for example,
we shouldn't use BUILT_IN_REMAINDERL or
--- Comment #2 from vincent at vinc17 dot org 2006-10-25 14:00 ---
(In reply to comment #1)
So this sounds like a bug in your installation.
This cannot be with my installation in particular as the bug occurred on
various Linux machines (only one is mine). However it could be due to
--- Comment #10 from uros at kss-loka dot si 2006-10-25 14:16 ---
(In reply to comment #9)
In the later case, expansion will fall-back to normal library call.
OK. So on system where the math library doesn't have remainderl, for example,
we shouldn't use BUILT_IN_REMAINDERL or it
I just tried to compile Suse Linux 10.1 package abiword-2.4.5-6 with the new
GNU C compiler version 4.3 snapshot 20061023 on a x86_64 machine.
The compiler said
ap_Menu_Functions.cpp: In function 'EV_Menu_ItemState
ap_GetState_SetPosImage(AV_View*, XAP_Menu_Id)':
ap_Menu_Functions.cpp:1588:
--- Comment #1 from dcb314 at hotmail dot com 2006-10-25 14:29 ---
Created an attachment (id=12489)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12489action=view)
C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29590
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-25 14:39 ---
*** This bug has been marked as a duplicate of 29567 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-10-25 14:39 ---
*** Bug 29590 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from bonzini at gnu dot org 2006-10-25 14:55 ---
Subject: Bug 29092
Author: bonzini
Date: Wed Oct 25 14:55:09 2006
New Revision: 118034
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118034
Log:
2006-10-26 Paolo Bonzini [EMAIL PROTECTED]
PR c/29092
--- Comment #11 from bonzini at gnu dot org 2006-10-25 14:55 ---
committed to all branches
--
bonzini at gnu dot org changed:
What|Removed |Added
After compilation test1.c with -O2 program loops unending.. Yeah I know is
possible cause -fstrict-aliasing and program works compilated with -O2
-fno-strict-aliasing
It works too if it was compilated just only with -fstrict-aliasing so it loops
when some other optimization was turned on.
It
--- Comment #1 from darkjames at darkjames dot ath dot cx 2006-10-25 16:12
---
Created an attachment (id=12490)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12490action=view)
First testcase
First testcase loops unending with -O2, not loops with -O2 -fno-strict-aliasing
||
--- Comment #2 from darkjames at darkjames dot ath dot cx 2006-10-25 16:13
---
Created an attachment (id=12491)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12491action=view)
Second testcase
test1.c + added printf() to loop, not loops with -O2
--
--- Comment #4 from billt at tutsys dot com 2006-10-25 16:13 ---
No luck using gcc 4.1.1 as the bootstrap compiler: I used the existing compiler
to build and install just the C compiler, which worked fine. make bootstrap
failed to build gcj using 4.1.1 as the C compiler. I then built
--- Comment #3 from darkjames at darkjames dot ath dot cx 2006-10-25 16:20
---
By the way, it's possible to fix the code in other way than using unions?
It just need to work both for wchar_t strings and normal strings...
If you have some ideas how, it'll be nice if you give me some
--- Comment #4 from rick at hartmantech dot com 2006-10-25 16:23 ---
The problem is not only confined to sufficiently modern machines. Some of us
have a conservationist sort of outlook, and are happy to find a use for an
older machine as a router, firewall, Kerberos server or whatever.
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-25 16:45 ---
In the both case, you are accessing wchar * via char * which causes an
alias violation.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The following code has a subtle bug:
#include assert.h
class Blah
{
public:
const unsigned int myfoo;
Blah(const unsigned int p):
myfoo(p) {}
const unsigned int getfoo()
{
return myfoo;
}
};
int main()
{
int foo(42);
Blah baz(foo);
++foo;
assert(foo == baz.getfoo());
--- Comment #5 from darkjames at darkjames dot ath dot cx 2006-10-25 17:11
---
Yeah, I know, but why gcc generate good code if we add that printf to test1.c
(test2.c) ? It's still wchar * - char * still aliasing violation.
or if we replace:
__SN(str, 1); with
str = (CHAR_T *) (((char
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-10-25 17:18 ---
(In reply to comment #5)
Yeah, I know, but why gcc generate good code if we add that printf to test1.c
(test2.c) ? It's still wchar * - char * still aliasing violation.
Yes but there is a barrier which cause
--- Comment #7 from darkjames at darkjames dot ath dot cx 2006-10-25 17:24
---
Ok, one more question, is it possible to gcc print some warnings about code
like that? Cause even with -Wall it doesn't ;(
gcc4 is quite more verbose than gcc3 so I think
It'll be better to print warning
If I run jv-convert with no arguments I see an NPE:
opsy. jv-convert
Exception in thread main java.lang.NullPointerException
at gnu.gcj.convert.IOConverter.canonicalize(libgcj.so.7)
at gnu.gcj.convert.BytesToUnicode.getDecoder(libgcj.so.7)
at java.io.InputStreamReader.init(libgcj.so.7)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-25 18:56 ---
This warning is hard to get right as there are many many pieces of code that
depends on binding an rvalue to an constant reference.
This bug is related to PR 986.
--
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-10-25 20:11 ---
(In reply to comment #1)
Thomas,
Have you written Adrain about his plans concerning his patch?
Not yet (I tried CC'ing him with this, but apparently this doesn't work).
IIRC (and Adrian, please correct me) his
I noticed this while developing/debugging the source file, the code is in a
very rough and buggy state but the behavior I'm getting seems to be tied to a
properly formed printf().
$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--- Comment #1 from tkoenig at gcc dot gnu dot org 2006-10-25 20:39 ---
This is not a maxloc bug per se. Look at this:
$ cat a9.f90
INTEGER :: K(3)=1
INTEGER, PARAMETER :: J(3)=2
write (6,*) J1
END
$ gfortran -fdump-tree-original a9.f90
$ ./a.out
F
Output should be
F F F
instead.
--- Comment #1 from nigelenki at comcast dot net 2006-10-25 20:41 ---
Created an attachment (id=12492)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12492action=view)
decrypt_1.2.c
C source file, there's a big block that says GCC MISCOMPILATION above the
printf triggering this.
--- Comment #15 from ghazi at gcc dot gnu dot org 2006-10-25 20:44 ---
Subject: Bug 29335
Author: ghazi
Date: Wed Oct 25 20:44:09 2006
New Revision: 118042
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118042
Log:
PR middle-end/29335
* builtins.c
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-25 20:45 ---
How did you build it? It says
t.c: In function a_hash:
t.c:95: warning: right shift count = width of type
also it seems to need proper input...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29595
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-10-25 20:51 ---
Eh, we're not going to debug your code for you. It looks too buggy and
segfaults on me.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from nigelenki at comcast dot net 2006-10-25 21:42 ---
Issue was passing an unsigned long int to a %i instead of %li format specifier
in printf(). I didn't know my C library altered anything if %n wasn't
specified... oh well, my bug.
--
Please find attached a sample program, which does not compile.
Unfortunately this program depends on boost. I use the current boost version
1.33.1. The include files algorithm and iostream are the ones belonging to
gcc-4.1.1.
--
Summary: overloaded function not found
--- Comment #1 from again at gmx dot de 2006-10-25 21:45 ---
Created an attachment (id=12493)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12493action=view)
test.cpp (sample program that does not compile)
This program does not compile (commandline g++ test.cpp -o test)
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-25 21:48 ---
Can you provide the preprocessed source which you can get via -save-temps and
it will be called something .ii.
Also you can provide the error message you get?
--
--- Comment #3 from again at gmx dot de 2006-10-25 21:50 ---
Created an attachment (id=12494)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12494action=view)
output of g++ test.cpp -o test
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29596
--- Comment #4 from again at gmx dot de 2006-10-25 21:51 ---
Created an attachment (id=12495)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12495action=view)
output of Visual C++ .NET 2003 plus output of compiled program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29596
--- Comment #5 from again at gmx dot de 2006-10-25 21:53 ---
test.ii produced by `g++ -v -save-temps test.cpp -o test' is to bug for
bugzilla -- you can find it here:
http://schlotter.org/pub/test.ii (1.2MB)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29596
--- Comment #6 from again at gmx dot de 2006-10-25 21:57 ---
Remark to test.cpp:23:
std::cout boost::lambda::_1 '\n'
This should find the overloaded operator defined in boost/tuple_io.hpp.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29596
The following code should return the base2 logarithm of 64 (ie 6)
double d = log(64.0) / log(2.0);
int i = (int)d;
cout i;
And indeed it does output 6. However, if you attempt to cast it on the same
line, then it returns 5.
int i2 = (int)( log(64.0) / log(2.0) );
int i3 = static_castint(
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-25 22:05 ---
This comes from precission of the floating point.
*** This bug has been marked as a duplicate of 323 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #84 from pinskia at gcc dot gnu dot org 2006-10-25 22:05
---
*** Bug 29597 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from daney at gcc dot gnu dot org 2006-10-25 22:29 ---
Subject: Bug 29519
Author: daney
Date: Wed Oct 25 22:29:10 2006
New Revision: 118044
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118044
Log:
PR middle-end/29519
* rtlanal.c
--- Comment #11 from daney at gcc dot gnu dot org 2006-10-25 22:34 ---
With the (now committed) patches, my testing shows the problem as fixed.
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from mstaley at lanl dot gov 2006-10-25 22:38 ---
(In reply to comment #1)
This is most likely a purify problem. Have you tried using valgrind instead?
I just tried valgrind. I'm not really familiar with valgrind, but as far
as I can tell it reports no problems. So,
Executing on host: /home/dave/gnu/gcc-4.2/objdir/gcc/xgcc
-B/home/dave/gnu/gcc-4
.2/objdir/gcc/
/home/dave/gnu/gcc-4.2/gcc/gcc/testsuite/gcc.dg/tree-ssa/loadpre1
.c -O2 -fdump-tree-pre-stats -fno-show-column -S -o loadpre1.s(timeout =
300)
PASS: gcc.dg/tree-ssa/loadpre1.c (test for excess
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-25 23:04 ---
This is mentioned in:
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01003.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #37 from ghazi at gcc dot gnu dot org 2006-10-26 00:59 ---
A request for this optimization made by Bruce in Sept 2000. :-)
http://gcc.gnu.org/ml/gcc-patches/2000-09/msg00877.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982
--- Comment #11 from sgk at troutmask dot apl dot washington dot edu
2006-10-26 04:03 ---
Subject: Re: Intrinsic MOD incorrect for large arg1/arg2 and slow.
On Wed, Oct 25, 2006 at 08:19:21AM -, fxcoudert at gcc dot gnu dot org
wrote:
I'm adding Steve Kargl to the CC list,
--- Comment #3 from pcarlini at suse dot de 2006-10-26 04:22 ---
(In reply to comment #2)
I just tried valgrind. I'm not really familiar with valgrind, but as far
as I can tell it reports no problems. So, either purify is wrong, valgrind
is wrong, or they're both wrong in different
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mueller at gcc dot gnu dot
|dot org
1 - 100 of 103 matches
Mail list logo
