Andrew Pinski wrote:
On Jul 4, 2006, at 5:07 PM, Yuri Pudgorodsky wrote:
Can someone make the decision to reopen PR optimization/12085?
And I posted a patch to do the same in Objective-C mode as C mode :).
http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01013.html
That indeed will fix PR for
Ian Lance Taylor writes:
Andrew Haley [EMAIL PROTECTED] writes:
Ian Lance Taylor writes:
Yuri Pudgorodsky [EMAIL PROTECTED] writes:
Compiling openssl-0.9.8b with gcc-4.2 snapshots, I found gcc 4.2
fortifies its check for function pointer conversion and generates
On Jul 5, 2006, at 2:36 AM, Yuri Pudgorodsky wrote:
1) with direct cast: (int (*)(int)) foo
- warn/trap since 3.x
2) with cast through void fptr: (int (*)(int)) (int(*)()) foo
- warn/trap since 4.2 current
I don't see why you are invoking this undefined behavior anyways.
What are you trying
Mike Stump wrote:
svn ls -r40553 svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-2_95-branch/
gcc/testsuite
appears to be fairly close. Don't know why the tag was messed up.
This number comes from the tags/gcc-2_95_3 tag.
Thx a lot Mike,
This is what i get from svn repo (after importing
Andrew Haley [EMAIL PROTECTED] writes:
[...]
| If we're going to guarantee this stuff for the future, we'll have to
| fix the bug, make sure it's doesn't destabilize the compiler and write
| some test cases. If we're really serious about it we should make it a
| documented extension to C.
if
Andrew Pinski wrote:
On Jul 5, 2006, at 2:36 AM, Yuri Pudgorodsky wrote:
1) with direct cast: (int (*)(int)) foo
- warn/trap since 3.x
2) with cast through void fptr: (int (*)(int)) (int(*)()) foo
- warn/trap since 4.2 current
I don't see why you are invoking this undefined behavior
Gabriel Dos Reis wrote:
Furthermore, I've read people suggesting that we are gratuitously
broking code. That is misleading. The code was invoking undefined
behaviour and, before, we did not make any explicit guarantee about
the semantics.
It is one thing to argue for changing gear; but,
Yuri Pudgorodsky [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
| Furthermore, I've read people suggesting that we are gratuitously
| broking code. That is misleading. The code was invoking undefined
| behaviour and, before, we did not make any explicit guarantee about
| the semantics.
I apologize for presenting something which appears to be a strawman
argument. That would never be my intent. Let me restate: I don't
think gcc should ever insert a trap call for undefined code. We
should only insert a trap call for code which will provably trap.
We're currently breaking
Ian Lance Taylor writes:
Andrew Haley [EMAIL PROTECTED] writes:
If we're going to guarantee this stuff for the future, we'll have
to fix the bug, make sure it's doesn't destabilize the compiler
and write some test cases. If we're really serious about it we
should make it a
What do we do if compiler ICE generating code for valid C syntax with
defined behavior? Fix it!
Why should we go another way for valid C syntax with undefined behavior?
The answer is in the question, no?
--
Eric Botcazou
This question is not appropriate for the gcc@gcc.gnu.org mailing list.
It would be appropriate on the [EMAIL PROTECTED] mailing list.
Thanks.
[EMAIL PROTECTED] writes:
I am wondering if i have used -O, -O2 or -O3, do i still benifit from
flags such as -march -fmpmath -ffast-math -mmx -sse
Ian Lance Taylor [EMAIL PROTECTED] writes:
I personally don't agree that this needs to be a documented extension.
I'm simply going on a more general rule which I tried to state above:
I don't think we should insert a trap call for undefined code.
I realized that I am still not stating my
For what it's worth, I tried to recreate the ICE after removing the
trap insertion, but failed. So I'm not even sure the trap insertion
is fixing a real problem any more. It works at the moment simply
because it treats the call through a cast as a call through a function
pointer, and
Andrew Haley [EMAIL PROTECTED] writes:
If we make a change for openssh to allow this undefined behaviour,
then do we agree to keep it working or not? If we agree that we will,
then we have to at least add some test cases and we have to add some
internal documentation to gcc. If we don't
Kazu Hirata [EMAIL PROTECTED] writes:
I keep finding places in GCC sources that check whether a member of
TYPE_ARG_TYPES is 0. For example,
for (link = TYPE_ARG_TYPES (function_or_method_type);
link TREE_VALUE (link);
link = TREE_CHAIN (link))
gen_type_die
Ian Lance Taylor wrote:
Kazu Hirata [EMAIL PROTECTED] writes:
I keep finding places in GCC sources that check whether a member of
TYPE_ARG_TYPES is 0. For example,
for (link = TYPE_ARG_TYPES (function_or_method_type);
link TREE_VALUE (link);
link = TREE_CHAIN (link))
Daniel Berlin wrote:
I believe it also happens with varargs functions in some cases, if there
was nothing but a varargs parameter.
This is the one and only case in which it should occur, but, yes, it is
possible.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
On Wed, Jul 05, 2006 at 11:49:58AM -0400, Daniel Berlin wrote:
I believe it also happens with varargs functions in some cases, if there
was nothing but a varargs parameter.
I was recently reminded that that's not valid C. Is there any language
which lets you get away with only unnamed
Hi Ian,
I keep finding places in GCC sources that check whether a member of
TYPE_ARG_TYPES is 0. For example,
for (link = TYPE_ARG_TYPES (function_or_method_type);
link TREE_VALUE (link);
link = TREE_CHAIN (link))
gen_type_die (TREE_VALUE (link), context_die);
Notice that
Kazu Hirata wrote:
Hi Ian,
I keep finding places in GCC sources that check whether a member of
TYPE_ARG_TYPES is 0. For example,
for (link = TYPE_ARG_TYPES (function_or_method_type);
link TREE_VALUE (link);
link = TREE_CHAIN (link))
gen_type_die (TREE_VALUE (link),
Ian Lance Taylor writes:
Andrew Haley [EMAIL PROTECTED] writes:
If we make a change for openssh to allow this undefined behaviour,
then do we agree to keep it working or not? If we agree that we will,
then we have to at least add some test cases and we have to add some
internal
On Jul 5, 2006, at 8:38 AM, Ian Lance Taylor wrote:
To me this is related to the point I raised at the steering committee
panel discussion (I know you weren't there): I think we are too casual
about breaking existing working code.
What happens when a target comes along and passes different
On Wed, Jul 05, 2006 at 09:11:32AM -0700, Andrew Pinski wrote:
What happens when a target comes along and passes different pointers
types differently. Like say a floating point pointer in the FP
register and an pointer to an integer in the general purpose
register, wouldn't that also break
Andrew Pinski [EMAIL PROTECTED] writes:
On Jul 5, 2006, at 8:38 AM, Ian Lance Taylor wrote:
To me this is related to the point I raised at the steering committee
panel discussion (I know you weren't there): I think we are too casual
about breaking existing working code.
What happens
On 05 July 2006 17:12, Andrew Pinski wrote:
On Jul 5, 2006, at 8:38 AM, Ian Lance Taylor wrote:
To me this is related to the point I raised at the steering committee
panel discussion (I know you weren't there): I think we are too casual
about breaking existing working code.
What happens
What happens when a target comes along and passes different pointers
types
differently. Like say a floating point pointer in the FP register and an
pointer to an integer in the general purpose register, wouldn't that also
break the code in question? Yes this is in theory but still saying
Eric Botcazou wrote:
make[3]: Leaving directory `/mnt/scratch/nightly/2006-07-04/i686'
Comparing stages 2 and 3
warning: ./cc1-checksum.o differs
warning: ./cc1plus-checksum.o differs
warning: ./cc1obj-checksum.o differs
Bootstrap comparison failure!
Does the attached patch make any
No, I still get the same set of .o files that differ, and the -fdump-noaddr
(See PR other/28251) peephole2 dump for cfg.c compiled with stage1 /
stage2 cc1 is still the same.
Then I'm puzzled. The original patch is supposed to be essentially a nop for
languages that do not use
Joern Rennecke wrote:
Eric Botcazou wrote:
make[3]: Leaving directory `/mnt/scratch/nightly/2006-07-04/i686'
Comparing stages 2 and 3
warning: ./cc1-checksum.o differs
warning: ./cc1plus-checksum.o differs
warning: ./cc1obj-checksum.o differs
Bootstrap comparison failure!
Does the
On Jul 5, 2006, at 2:26 AM, J.J.Garcia wrote:
Can i assume that what im using (2.95.2.1) is the last used
previously to
release 2.95.3 20010315 (release)?
Not really. If you were going to stake your life on it, you'd not
want to do that. I doubt the stakes are that high however. Anyway,
Joern RENNECKE writes:
Joern Rennecke wrote:
Eric Botcazou wrote:
make[3]: Leaving directory `/mnt/scratch/nightly/2006-07-04/i686'
Comparing stages 2 and 3
warning: ./cc1-checksum.o differs
warning: ./cc1plus-checksum.o differs
warning: ./cc1obj-checksum.o differs
On Jul 4, 2006, at 7:43 PM, [EMAIL PROTECTED] wrote:
The codec is at http://www.sourceforge.net/projects/openavs/.
Currently, it requires a 3Ghz or better CPU to get a resonable
framerate. I would like the codec to be useful even on 586
( 1Ghz or
so ). Any ideas?
Recode slower parts in
Hi,
On Wednesday 05 July 2006 19:57, Mike Stump wrote:
On Jul 4, 2006, at 7:43 PM, [EMAIL PROTECTED] wrote:
The codec is at http://www.sourceforge.net/projects/openavs/.
Currently, it requires a 3Ghz or better CPU to get a resonable
framerate. I would like the codec to be useful even on
On 05 July 2006 19:11, Rene Rebe wrote:
Hi,
On Wednesday 05 July 2006 19:57, Mike Stump wrote:
On Jul 4, 2006, at 7:43 PM, [EMAIL PROTECTED] wrote:
The codec is at http://www.sourceforge.net/projects/openavs/.
Currently, it requires a 3Ghz or better CPU to get a resonable
framerate. I
Mark Mitchell wrote:
I'm not sure the number above is in and of itself terribly meaningful,
in part because Volker has been filing many
ICE-on-invalid-after-error-message PRs against the C++ front end. These
don't really even show up for users in releases, due to the confused by
earlier errors
Hi,
On Wednesday 05 July 2006 20:26, Dave Korn wrote:
I believe Lionel's real problem is likely to be that he was hoping that
turning on the -mmx -sse -sse2 -3dnow options would auto-vectorise his code
for him.
Lionel, (IIUIC) those options just /enable/ the use of the various SIMD
On Jul 4, 2006, at 5:18 PM, Andrew Pinski wrote:
And I posted a patch to do the same in Objective-C mode as C mode :).
http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01013.html
Is the reason that Objective-C was excluded been fixed? If so, while
I don't like the semantics in place now, I'd
David Edelsohn wrote:
I am pleased to announce that the GCC Steering Committee has
appointed Ulrich Weigand to the role of reload maintainer.
Thank you!
Please join me in congratulating Ulrich on his new role. Ulrich,
please update your entry in the MAINTAINERS file.
I've
Mike Stump [EMAIL PROTECTED] writes:
On Jul 4, 2006, at 5:18 PM, Andrew Pinski wrote:
And I posted a patch to do the same in Objective-C mode as C mode :).
http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01013.html
Is the reason that Objective-C was excluded been fixed? If so, while
I
(Resending after update on archive link below.)
A proposal was made to pick one the Decimal Floating-Point encodings from
the IEEE754r draft in the x86-64 psABI a few weeks ago (see thread starting
at http://www.amd64.org/lists/discuss/thrd215.html#08857). Given that any
such decision can have
Andrew Haley wrote:
So it seems I have to abandom the system compiler for doing bootstraps.
Can you make a simple testcase for this?
Andrew.
Attached.
This fails at -O0..-O2 for gcc 3.2.2 and gcc 3.2.3 on
i686-pc-linux-gnu. For gcc 3.4.3,
it still fails at -O1.
4.2.0 appears to be
Hmm, as far as I can tell, stage1 i386.c:ix86_split_ashr has been
miscompiled by gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-54).
Thanks a bunch for sorting this out!
--
Eric Botcazou
Ian Lance Taylor wrote:
Mike Stump [EMAIL PROTECTED] writes:
On Jul 4, 2006, at 5:18 PM, Andrew Pinski wrote:
And I posted a patch to do the same in Objective-C mode as C mode :).
http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01013.html
Is the reason that Objective-C was
Ian Lance Taylor [EMAIL PROTECTED] writes:
[...]
| I personally don't agree that this needs to be a documented extension.
| I'm simply going on a more general rule which I tried to state above:
| I don't think we should insert a trap call for undefined code.
If it should not a documented
Ian Lance Taylor [EMAIL PROTECTED] writes:
| Andrew Haley [EMAIL PROTECTED] writes:
|
| If we make a change for openssh to allow this undefined behaviour,
| then do we agree to keep it working or not? If we agree that we will,
| then we have to at least add some test cases and we have to add
Ian Lance Taylor wrote:
I realized that I am still not stating my position very clearly. I
don't think we should make any extra effort to make this code work:
after all, the code is undefined. I just think 1) we should not
insert a trap; 2) we should not ICE.
I agree. If the inlining
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot
|dot org
--- Comment #1 from aoliva at gcc dot gnu dot org 2006-07-05 06:04 ---
Created an attachment (id=11822)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11822action=view)
Patch that fixes the bug
This patch fixes the problem for me.
--
(...)
../../gcc/config/soft-fp/floatsisf.c:36: warning: no previous prototype for
'__floatsisf'
/home/users/builder/rpm/BUILD/trunk/builddir/./gcc/xgcc
-B/home/users/builder/rpm/BUILD/trunk/builddir/./gcc/ -B/usr/ppc-pld-linux/bin/
-B/usr/ppc-pld-linux/lib/ -isystem /usr/ppc-pld-linux/include
--- Comment #5 from bonzini at gnu dot org 2006-07-05 06:20 ---
Subject: Bug 28218
Author: bonzini
Date: Wed Jul 5 06:20:19 2006
New Revision: 115197
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115197
Log:
2006-07-04 Paolo Bonzini [EMAIL PROTECTED]
PR
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-05 06:23 ---
How did you configure GCC?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28264
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-07-05 06:24 ---
soft-fp is included by default on powerpc-linux and it works for everyone I
know.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28264
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-07-05 06:25 ---
And config/soft-fp/divdf3.c is there for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28264
--- Comment #6 from bonzini at gnu dot org 2006-07-05 06:47 ---
Subject: Bug 28218
Author: bonzini
Date: Wed Jul 5 06:47:21 2006
New Revision: 115198
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115198
Log:
2006-07-04 Paolo Bonzini [EMAIL PROTECTED]
PR
--- Comment #7 from bonzini at gnu dot org 2006-07-05 06:49 ---
patch committed to 4.1 branch and mainline (where it was latent)
--
bonzini at gnu dot org changed:
What|Removed |Added
libstdc++-v3/include/ext/codecvt_specializations.h uses iconv_t and causes
errors while building an i686-pc-linux-gnu to i686-pc-mingw32 cross-compiler.
(I'm at trunk revision 115196.)
Strangely however, this does not cause a build failure and is therefore not
catastrophic for this target.
GCC
--- Comment #1 from rmathew at gcc dot gnu dot org 2006-07-05 07:32 ---
Created an attachment (id=11823)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11823action=view)
The portion of the build log that shows the error reported in this PR.
--
--- Comment #4 from pluto at agmk dot net 2006-07-05 08:19 ---
ohhh, now I see what's wrong.
Out of Memory: Killed process 18248 (cc1).
the PPC970FX box has 1GB ram + 1GB swap.
i'll re-run build and try to reproduce this memory-hog.
--
--- Comment #2 from uros at kss-loka dot si 2006-07-05 08:25 ---
Created an attachment (id=11824)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11824action=view)
Patch to implement pow(x,1.0/3.0) = cbrt(x) optimization
I have the patch that implements the optimization ready, just
--
uros at kss-loka dot si changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |uros at kss-loka dot si
|dot org |
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-07-05 09:04
---
As far as I can tell this has been fixed now so closing as such. Yes I did
test to make sure the function calls are no longer being duplicated.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #20 from pinskia at gcc dot gnu dot org 2006-07-05 09:05
---
Fixed on the mainline.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #67 from pinskia at gcc dot gnu dot org 2006-07-05 09:06
---
Does anyone have new numbers for this, Richard G.'s recent memory patches have
an effect on the compile time also I noticed between 7% and 10% on at least
CSiBE.
--
--- Comment #30 from pinskia at gcc dot gnu dot org 2006-07-05 09:14
---
Can you do timings on these again on the mainline since it looks like Richard
G.'s memory patches also improved compile time for C at least on the CSiBE
benchmark.
--
--- Comment #7 from tobias dot burnus at physik dot fu-berlin dot de
2006-07-05 09:23 ---
The patch did not apply to 4.1, so I will have to submit a back port.
Thanks, Paul. I think this is the most serious bug in gfortran 4.1.x as it
silently produces wrong results.
--
tobias dot
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-07-05 09:27 ---
It is slightly different now:
leal-4(%edi), %eax
movl%eax, %edi
movl(%eax), %eax
testl %eax, %eax
But still the same issue.
--
pinskia at gcc dot gnu dot org
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2006-07-05 09:45
---
(In reply to comment #9)
mingw has an implementation of _IO_ldtoa() and _IO_ldtostr(), based on Stephen
Moshier's ioldoubl package, that could be used. Currently, the ldtoa function
is not exposed, but there
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-07-05
09:47 ---
Created an attachment (id=11825)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11825action=view)
Fix for PR28237 and the last bit of PR2320.
I have not had time to do a full regtest; just
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-07-05 09:50
---
struct FF {
__m128 d;
.
}
Mine I have a patch for this I cannot believe I found this before. The patch
has been tested a bit at least in the local tree I have been playing out with.
SRA should use element
--- Comment #4 from uros at kss-loka dot si 2006-07-05 10:10 ---
This still fails with current mainline gcc.
--
uros at kss-loka dot si changed:
What|Removed |Added
--- Comment #5 from patchapp at dberlin dot org 2006-07-05 10:45 ---
Subject: Bug number PR28162
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-07/msg00133.html
--
--- Comment #4 from dtemirbulatov at gmail dot com 2006-07-05 10:46 ---
fix
we need to check first operand for FIELD_DECL before gimpilfying COMPONENT_REF
this is a wrong fix, it caused some regressions
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26696
--- Comment #5 from patchapp at dberlin dot org 2006-07-05 10:50 ---
Subject: Bug number PR28158
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-07/msg00134.html
--
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-07-05 10:54
---
Subject: Bug 27084
Author: rguenth
Date: Wed Jul 5 10:54:17 2006
New Revision: 115200
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115200
Log:
2006-07-05 Richard Guenther [EMAIL PROTECTED]
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-07-05 10:58
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-07-05 11:03 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #14 from lopezibanez at gmail dot com 2006-07-05 11:15 ---
Created an attachment (id=11826)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11826action=view)
split current functionality of Wconversion in two different options
This patch divides the functionality of
--- Comment #15 from lopezibanez at gmail dot com 2006-07-05 11:18 ---
Created an attachment (id=11827)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11827action=view)
Adds a new function which detects when a real value can be exactly represented
as an integer.
Patch 2of3
--- Comment #16 from lopezibanez at gmail dot com 2006-07-05 11:22 ---
Created an attachment (id=11828)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11828action=view)
detect implicit conversions where a value may change
patch 3of3 http://gcc.gnu.org/wiki/Wcoercion#Background
--- Comment #8 from lopezibanez at gmail dot com 2006-07-05 11:34 ---
I think we may close this bug report since either:
* The solution is to split the functionality of Wconversion as conceived by the
Wcoercion project http://gcc.gnu.org/wiki/Wcoercion#Background. In that case,
this is
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-07-05 11:37 ---
See comment #1, this is how it is intended.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-07-05 11:43
---
(In reply to comment #5)
Can we close this?
I think we can. If someone has precise input on how we can make -fbounds-check
even faster, please reopen this PR with extra details.
--
fxcoudert at gcc dot gnu
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-07-05 11:50
---
I have a patch here: http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00137.html
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
The following invalid code snippet triggers an ICE since GCC 4.0.0:
struct A
{
int i;
A(int = X);
};
void foo()
{
A().i;
}
bug.cc:4: error: 'X' was not declared in this scope
bug.cc: In function 'void foo()':
bug.cc:9: internal compiler error: in
The following invalid code snippet triggers a segfault since GCC 4.0.0:
struct A
{
void* operator new(__SIZE_TYPE__, int = X);
void operator delete(void*, int);
A();
};
void foo()
{
new A;
}
The following valid code snippet triggers an ICE on mainline:
int __attribute__((vector_size(8))) a;
void foo()
{
a += a*a;
}
bug.c: In function 'foo':
bug.c:5: internal
The following invalid code snippet triggers an ICE on mainline:
templateint struct A;
struct __attribute__((unused)) A0;
bug.cc:3: error: template argument 1 is invalid
The following invalid code snippet triggers an ICE since GCC 3.1:
void foo(long double d)
{
asm( :: a (d));
}
bug.c: In function 'foo':
bug.c:3: error: impossible register
The specialization of a function is not called if compile with -03 option,
the generic implementation is called insteed.
This appear only if the declaration of the specialization is in another
file.
The specialization is called if compiled with -02 or lees optimization, or
if the generic
--- Comment #1 from maxime dot fiandino at imag dot fr 2006-07-05 13:11
---
Created an attachment (id=11829)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11829action=view)
The main, just call the template function foo and return the return value
--
--- Comment #2 from maxime dot fiandino at imag dot fr 2006-07-05 13:12
---
Created an attachment (id=11830)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11830action=view)
the specialization
The specialization on int return true
--
--- Comment #3 from maxime dot fiandino at imag dot fr 2006-07-05 13:12
---
Created an attachment (id=11831)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11831action=view)
The header with the generic implementation
The generic template function return false
--
--- Comment #4 from maxime dot fiandino at imag dot fr 2006-07-05 13:14
---
Created an attachment (id=11832)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11832action=view)
The makefile to test
This makefile create two executable
TC1 compiled with -02 which work well
TC2
--- Comment #5 from maxime dot fiandino at imag dot fr 2006-07-05 13:18
---
This bug was firstly discover under gcc3.2.3, then we test with 4.1.1 with the
same results. The test case is very short.
--
maxime dot fiandino at imag dot fr changed:
What|Removed
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-07-05 13:36 ---
With checking enabled we have
obj2/gcc ./cc1plus -quiet -O2 t.ii
t.ii: In static member function 'static IntType
boost::random::const_modIntType, m::mult_schrage(IntType, IntType) [with
IntType = int, IntType m =
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--- Comment #2 from s_j_newbury at yahoo dot co dot uk 2006-07-05 13:38
---
This bug is still present with binutils-2.17.50.0.2. I am still uncertain
whether gcc is producing invalid code or the check in binutils is wrong. I
have found this bug to be triggered while compiling gcc and
--- Comment #3 from amylaar at gcc dot gnu dot org 2006-07-05 13:42 ---
Created an attachment (id=11833)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11833action=view)
dump diff for mainline r115174 bootstrap failure
The diff with -fdump-noaddr is indeed much more useful to track
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-07-05 13:48 ---
I can reproduce it on the 4.1 branch on i686, but not on trunk. Very slowly
eating all of memory. Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28187
1 - 100 of 202 matches
Mail list logo
