--- Comment #2 from mail at sebastianbauer dot info 2007-03-21 07:15
---
Created an attachment (id=13241)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13241&action=view)
The output of the compiler invocation and the executable.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #1 from mail at sebastianbauer dot info 2007-03-21 07:14
---
Created an attachment (id=13240)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13240&action=view)
The simple test source.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31291
The purpose of the attached code is to print out the internal representation of
some floating points. However, when compiling with optimizations turned on the
behaviour of the compiled program is not the expected one (i.e. the proper hex
representation is not printed out, but something else, here 0
--- Comment #6 from bangerth at dealii dot org 2007-03-21 03:59 ---
(In reply to comment #4)
> so in other words you're saying the solution to this is
> "if you want it to work with GCC, make your code non-portable"
>
> afaik "__attribute__ (( weak ))" is not part of the standard, its
--- Comment #5 from jima at cadence dot com 2007-03-21 02:31 ---
(In reply to comment #4)
> (In reply to comment #3)
>... Why do you think 1 or 2 more
> instructions will be a hit, most of the problems you are going to hit into now
> is cache issues anyways unless you do a better malloc
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-21 01:40 ---
(In reply to comment #3)
> Can you point me to a description of the C++ aliasing rules?
You can find some of it on http://gcc.gnu.org/bugs.html under the non bug
section. There are a lot more pages on then I can
--- Comment #3 from jima at cadence dot com 2007-03-21 01:32 ---
Can you point me to a description of the C++ aliasing rules?
Is the memcpy() workaround specific to GCC, or is memcpy
part of the standard with special rules regarding aliasing?
(I ask because our code base has to work on
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-21 01:14 ---
Note memcpy is the only way to be aliasing safe in this case, oh and make sure
you don't cast the incomming pointer from malloc or from your free.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31289
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-21 01:13 ---
This is definitely a C/C++ aliasing violation as you are first accessing it as
a MyHeap::Node and then as derived.
Here is how I would fix it for the first one I would change it to:
void * newnode = malloc(bytes_
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-21 00:49 ---
The testcase contains:
f(j)int j;{return j++>0;}
Which is equialvant to:
f(j)int j;{return(j+1)>0;}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31290
While looking into a testsuite failure when I folded while expanding, I found
gcc.c-torture/execute/920612-1.c failed because it depends on overflow of
signed integer being undefined.
--
Summary: gcc.c-torture/execute/920612-1.c depends on overflow
being defined
// BUG DEMO for gcc 4.1.2 (and 4.1.1) for 32-bit x86
//
// If operator delete() is over-ridden in a base class, then
// if the implementation of delete() stores into the storage used
// by the object, the store seems to be removed by the compiler
// (maybe because the compiler thinks stores to a d
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-03-21 00:10
---
(In reply to comment #2)
> interface.c:567 is where it all starts.
Thanks for the pointer.
> If complex is excluded from product, we run into a
> problem with the test for the shape of the two operands.
I think
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-21 00:01
---
(In reply to comment #0)
> CHARACTER(LEN=3), DIMENSION(10) :: Z
> CHARACTER(LEN=10) :: res
> Z(:)="123"
> write(*,'(10A1)') TRANSPOSE(RESHAPE(Z(:)(2:2),(/5,2/)))
> END
Same thing happens with
write(*,'(10A1)')
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-03-20 23:51
---
I think test.f is not valid Fortran, because size(p,1) is not a valid
specification expression. See 7.1.6 of the F2003 standard: it is a array
inquiry function (size) with an argument that is a variable (p) whose
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-03-20 22:46 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from membar at gcc dot gnu dot org 2007-03-20 22:45 ---
This fix works for me. Thanks. Not sure who's responsible for closing this out.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31264
--- Comment #7 from dje at gcc dot gnu dot org 2007-03-20 22:41 ---
If GNU Binutils and Linker do not support AIX 5L sufficiently to bootstrap GCC,
then you should infer that does not support AIX 5L sufficiently for anything
"interesting", like shared libraries.
--
http://gcc.gnu.or
--- Comment #6 from kstemen at centeris dot com 2007-03-20 22:19 ---
That says you can't bootstrap GCC on AIX 5L with GNU ld and as. It doesn't say
you can't build a cross compiler with them, and it doesn't say you can't use
them after GCC is bootstrapped.
In fact, I have looked at coll
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-03-20 22:15 ---
"The native as and ld are recommended for bootstrapping on AIX 4 and required
for bootstrapping on AIX 5L. The GNU Assembler reports that it supports WEAK
symbols on AIX 4, which causes GCC to try to utilize weak sym
--- Comment #4 from kstemen at centeris dot com 2007-03-20 22:10 ---
Tell me what binutils doesn't support and I'll file a bug on binutils. I
already filed a bug about the default rpath in the cross compiler version of
gnu ld for AIX 5.3.0.0, and they fixed it. They didn't say anything a
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-20 21:59 ---
>If it would help you, I can give you the options I used to configure binutils,
> and a list of the AIX libraries in my AIX sysroot.
Does not matter, binutils does not support AIX 5.3 features.
--
pinskia at gcc
--- Comment #4 from dje at gcc dot gnu dot org 2007-03-20 21:48 ---
and more info http://gcc.gnu.org/ml/gcc-help/2007-03/msg00095.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31282
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-20 21:48 ---
http://gcc.gnu.org/ml/gcc-help/2007-03/msg00095.html
According to IBM, the fix for this APAR IY90737 is incorporated into
Service Pack 5300-05-04.
Do you have that installed?
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #2 from dje at gcc dot gnu dot org 2007-03-20 21:47 ---
Andrew Pinski pointed out that this is known with a workaround:
http://www-128.ibm.com/developerworks/forums/dw_thread.jsp?forum=747&thread=119546&cat=72
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31282
--- Comment #2 from kstemen at centeris dot com 2007-03-20 21:45 ---
I'm trying to create rpms of cross compilers. I looked on the crosstools
website, but it doesn't look like it supports that. So I am more or less
building the cross compiler from scratch.
I noticed that C++ is unsuppor
--- Comment #1 from dje at gcc dot gnu dot org 2007-03-20 21:43 ---
Compiling with -pthread adds -D_THREAD_SAFE to the defined macros, which causes
different header files to be included. Prior to GCC 4.3, this appears to cause
a non-unique name to be chosen for the global constructor in
--- Comment #1 from dje at gcc dot gnu dot org 2007-03-20 21:40 ---
What tools are you using for the cross-compiler? Cross-compiling to AIX is not
supported because the rest of the GNU crosstools are incomplete for AIX 5.
--
dje at gcc dot gnu dot org changed:
What|R
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-20 21:26 ---
*** This bug has been marked as a duplicate of 31287 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-20 21:26 ---
*** Bug 31288 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31287
--- Comment #30 from sje at cup dot hp dot com 2007-03-20 21:13 ---
I tried the C++ and Fortran tests (in addition to C) with version 122821 using
a non-boostrapped compiler but I got no new failures. It looks like the only
failing test case we have is the compiler itself.
--
http:
--- Comment #14 from Tobias dot Schlueter at physik dot uni-muenchen dot de
2007-03-20 21:04 ---
Subject: Re: short-circuit in -fbounds-check
pinskia at gcc dot gnu dot org wrote:
>> But I'll stop this discussion here, and will stay with g95 when I want to
>> bound-check my program.
>
I have a simple for for loop that initializes a char array and never stops.
Here is a small sample program that simulated the problem.
#include
int main(int argc, char *argv[]){
int i=0;
char name_array[7][100];
for (i=0; i <= 7; i++)
{
printf("Loop i: %d\n", i);
na
--- Comment #2 from bryan_sauser at pa-ucl dot com 2007-03-20 21:03 ---
Was code given to me by Contract programmer. Released person simple mistake
after reviewing.
--
bryan_sauser at pa-ucl dot com changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-20 21:01 ---
Note you are going over name_array's bounds so you are invoking undefined
behavior. 7 <= 7. arrays go from 0 to last-1 in C or (0, last-1] in math
notation for C arrays.
--
http://gcc.gnu.org/bugzilla/show_bug.
I have a simple for for loop that initializes a char array and never stops.
Here is a small sample program that simulated the problem.
#include
int main(int argc, char *argv[]){
int i=0;
char name_array[7][100];
for (i=0; i <= 7; i++)
{
printf("Loop i: %d\n", i);
na
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-03-20 20:58
---
> But I'll stop this discussion here, and will stay with g95 when I want to
> bound-check my program.
Why short circuiting is legal and so is not short circuiting. Yes Gfortran's
behavior is semi inconstaint but
--- Comment #12 from Tobias dot Schlueter at physik dot uni-muenchen dot de
2007-03-20 20:17 ---
Subject: Re: short-circuit in -fbounds-check
I'm on your side, mimo, no need to convince me :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31269
--- Comment #11 from mimo2 at free dot fr 2007-03-20 20:12 ---
hi tobi, may-be they have strong arguments as you say, but I've not catched
them. And I still believe that if there is an ambiguity in the standard, the
solution is to have a -fshort-circuit to let the user decide what he wan
--- Comment #1 from bangerth at dealii dot org 2007-03-20 20:02 ---
Confirmed.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC|
--- Comment #23 from patchapp at dberlin dot org 2007-03-20 19:42 ---
Subject: Bug number PR7302
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/2007-03/msg01347.html
--
http://gcc.gnu.org/bugzilla/sh
As found by Salvatore Filippone using valgrind.
---
program testcshft
integer :: alist(4)
!!$alist = (/1,2,3,4/)
alist =cshift(alist,-1)
write(*,*) alist
end program testcshft
-
==6801== Conditional jump or move depends on uninitialised value(s)
> ==
--- Comment #10 from tobi at gcc dot gnu dot org 2007-03-20 19:11 ---
Mimo,
you rely on behavior that is not specified by the standard. It says explicitly
that only, in order to determine the value of an expression, only as much of it
needs to be evaluated, as is needed to determine th
--- Comment #22 from manu at gcc dot gnu dot org 2007-03-20 19:01 ---
(In reply to comment #21)
> http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01343.html
>
Hint, if you use the patch queue[1], it takes care of adding a comment pointing
to the patch. Also, your patch lacks a Changelog [
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-03-20 18:57 ---
(In reply to comment #8)
> Why do you say the code is undefined. The last version (comment #5) is totally
> valid, but possible side effects in the function k could lead to different
> results depending on the fact t
--- Comment #8 from mimo2 at free dot fr 2007-03-20 18:52 ---
Why do you say the code is undefined. The last version (comment #5) is totally
valid, but possible side effects in the function k could lead to different
results depending on the fact that the -fbounds-check is set or no.
And
--- Comment #21 from pluto at agmk dot net 2007-03-20 18:52 ---
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01343.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7302
--- Comment #4 from pthaugen at us dot ibm dot com 2007-03-20 18:10 ---
Created an attachment (id=13239)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13239&action=view)
Fortran source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31280
--- Comment #3 from pthaugen at us dot ibm dot com 2007-03-20 18:09 ---
Created an attachment (id=13238)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13238&action=view)
Fortran source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31280
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-03-20 18:03 ---
> I don't see why nobody besides me thinks that consistency
Because the code is undefined either way you look at it :).
Yes GCC might allow it to work without -fbounds-check but that does not mean it
will work somew
--- Comment #6 from tobi at gcc dot gnu dot org 2007-03-20 17:50 ---
I don't see why nobody besides me thinks that consistency, whether it's
mandated by the standard or not is a user-friendly feature. Yes I understand
the arguments for our current behavior, but I'm not going to discuss
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-20 17:45 ---
> It is not hard to do "b _gfortran_out_of_bounds" in gdb.
Well, it is not always easy to find the symbol. In C it is much easier:
Essentially all you type is what you get. Fortran with all its hidden library
calls i
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-03-20 17:43
---
*** Bug 31284 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-20 17:43 ---
And the issue here is really PR19430
For some reason gfortran decided that print will cause a pass via reference :).
*** This bug has been marked as a duplicate of 19430 ***
--
pinskia at gcc dot gnu dot org ch
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-20 17:38 ---
Forgot to write that this is a Fortran program. Use
gfortran -Wall -O
to compile it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31284
In the following program, the uninitialized "i" is only detected if one
uncomments the print statement.
program test
implicit none
integer :: i,j
j = i*5
print*,i
end program test
--
Summary: Uninitialized variable not detected
Product: gcc
Version: 4.3.0
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-20 17:36 ---
It is not hard to do "b _gfortran_out_of_bounds" in gdb.
I never understood why gfortran or any language these extra features when there
is something called a debugger.
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-20 17:34 ---
You can just send them to me if you want.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31280
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
Component|libstdc++ |other
http:/
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-20 17:17 ---
*** This bug has been marked as a duplicate of 31281 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-20 17:17 ---
*** Bug 31283 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31281
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-20 17:16 ---
This works for me on the trunk on powerpc-linux-gnu with the GNU runtime and
next runtime.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
The 4.2 ObjC compiler ICEs on this (nonsensically reduced) testcase. Compile
with -O2:
int f(unsigned int i)
{
@try { } @catch(id) { }
for (;;)
for (;;)
@try {
if (i)
break;
} @catch(id) { }
}
The 4.0 compiler does not ICE with this testcase.
--
--- Comment #6 from rth at gcc dot gnu dot org 2007-03-20 17:09 ---
Spill slots *are* being aligned, else you'd see SEGV, not incorrect data.
Aliasing *is* the problem:
pand(%esi), %xmm0
movl$1, (%ebx)
movl$2, 4(%ebx)
movl$3, 8(%ebx)
Just a note on the severity, I've marked this as a "blocker" because it seems
quite basic and it makes it impossible for us to use GCC/G++ to generate a
thread safe shared object for use with JNI. Please adjust as appropriate.
I'm not sure if this is a g++ bug or a libstdc++ bug, I've followed Da
The 4.2 ObjC compiler ICEs on this (nonsensically reduced) testcase. Compile
with -O2:
int f(unsigned int i)
{
@try { } @catch(id) { }
for (;;)
for (;;)
@try {
if (i)
break;
} @catch(id) { }
}
The 4.0 compiler does not ICE with this testcase.
--
--- Comment #19 from spark at gcc dot gnu dot org 2007-03-20 16:45 ---
Subject: Bug 30590
Author: spark
Date: Tue Mar 20 16:44:54 2007
New Revision: 123090
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123090
Log:
2007-03-20 Seongbae Park <[EMAIL PROTECTED]>
PR tree-o
--- Comment #18 from spark at gcc dot gnu dot org 2007-03-20 16:44 ---
Subject: Bug 30590
Author: spark
Date: Tue Mar 20 16:44:00 2007
New Revision: 123089
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123089
Log:
2007-03-20 Seongbae Park <[EMAIL PROTECTED]>
PR tree-o
--- Comment #15 from pinskia at gcc dot gnu dot org 2007-03-20 16:14
---
> Is this also true for complex double on 32 bit architectures (i.e., 4 GPRs)
> or do you mean the GPR is used to pass a pointer?
4 GPRS
Yes this was a stupid decission on Apple's part for not looking at fixing G
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-03-20 16:12
---
The recommended way is to post a message to gcc@gcc.gnu.org or
[EMAIL PROTECTED]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31249
--- Comment #13 from dominiq at lps dot ens dot fr 2007-03-20 16:08 ---
> You can propose that we only enable sincos transformation
> if TARGET_HAS_SINCOS is set, I wouldn't necessarily object to
> that. (The targets I care for have a sincos)
Sound reasonable: replacing:
return (TAR
--- Comment #11 from pthaugen at us dot ibm dot com 2007-03-20 15:54
---
31280 opened.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30562
--- Comment #1 from pthaugen at us dot ibm dot com 2007-03-20 15:53 ---
Having trouble attatching source files, will keep trying...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31280
Seeing the following with mainline using -O2 -ftree-loop-linear when
building galgel benchmark from cpu2000.
I couldn't whittle down to a single testcase so will attatch both source files.
178.galgel/run> /home/pthaugen/install/gcc/trunk/bin/gfortran -c -m64
-ffixed-form -O2 -ftree-loop-linear mo
--- Comment #17 from spark at gcc dot gnu dot org 2007-03-20 15:42 ---
Subject: Bug 30590
Author: spark
Date: Tue Mar 20 15:42:37 2007
New Revision: 123087
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123087
Log:
2007-03-19 Seongbae Park <[EMAIL PROTECTED]>
PR tree-o
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31279
In Fortran one can specify the intent of variables thus if all arguments have
INTENT(IN) then GCC should be able to detect that alist in the call to cshift
is uninitialized.
This depends on the middle end support of intents (PR31094) plus using these in
gfortran.
Example (using an intrinsic funct
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-03-20 15:37
---
> Looks like I can reproduce with mainline using -O2 -ftree-loop-linear when
> building galgel benchmark from cpu2000.
This is a different issue and should be filed in a different bug.
--
http://gcc.gnu.org/b
--- Comment #9 from pthaugen at us dot ibm dot com 2007-03-20 15:31 ---
Looks like I can reproduce with mainline using -O2 -ftree-loop-linear when
building galgel benchmark from cpu2000.
(My FORTRAN skills are lacking, so couldn't whittle down to a single testcase,
but got close)
178.g
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-03-20 15:29 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-03-20 15:21 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-20 15:20 ---
*** This bug has been marked as a duplicate of 29826 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-03-20 15:20 ---
*** Bug 31275 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-03-20 15:06
---
Depends on how you name it ;) You can propose that we only enable sincos
transformation if TARGET_HAS_SINCOS is set, I wouldn't necessarily object to
that.
(The targets I care for have a sincos)
--
http://gcc
--- Comment #11 from dominiq at lps dot ens dot fr 2007-03-20 14:57 ---
Subject: Re: pseudo-optimzation with sincos/cexpi
> That sin+cos is practically sincos (so you get one for free). Just not every
> library exports that sincos.
Does not this assume that it exists a real sincos(x)
A backtrace (or coredump) would be nice for array out of bounds.
It would have to be implemented in as library call. This could be combined with
given more information (accessed index, allowed index) which is often
requested, e.g. PR 31270).
--
Summary: Backtrace/coredump for array-o
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-03-20 14:26
---
That sin+cos is practically sincos (so you get one for free). Just not every
library exports that sincos.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31249
--- Comment #9 from dominiq at lps dot ens dot fr 2007-03-20 14:03 ---
> I agree it's surprising to get user-visible effects with the
> TARGET_C99_FUNCTIONS difference between the frontends,
> but they are (supposed to) providing C99 runtime completion
> by their runtime libraries. An
--- Comment #3 from arcangelpip at hotmail dot com 2007-03-20 13:58 ---
I just tried with the latest sources for 4.1 and it still ICE with that. Same
place same message. It may work on 4.2 and 4.3 but it doesn't work for me on
4.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3127
--- Comment #8 from dominiq at lps dot ens dot fr 2007-03-20 13:57 ---
> The only reason why cexp is slow on PPC darwin is because the ABI is stupid.
> Complex float arguments are passed via the GPR and returned also the same way
> instead of via the FPRs. So you will get a transfer of
--- Comment #8 from mueller at gcc dot gnu dot org 2007-03-20 12:48 ---
*** Bug 30864 has been marked as a duplicate of this bug. ***
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from mueller at gcc dot gnu dot org 2007-03-20 12:48 ---
testcase works after PR31146 fix
*** This bug has been marked as a duplicate of 31146 ***
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from aph at gcc dot gnu dot org 2007-03-20 12:45 ---
Subject: Bug 31264
Author: aph
Date: Tue Mar 20 12:45:19 2007
New Revision: 123085
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123085
Log:
2007-03-19 Andrew Haley <[EMAIL PROTECTED]>
PR tree-optimi
--- Comment #2 from pcarlini at suse dot de 2007-03-20 11:45 ---
Related to C++/30982?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31267
--- Comment #1 from guillaume dot melquiond at ens-lyon dot fr 2007-03-20
11:22 ---
I just encountered another instance of a missing typename diagnostic. This time
with a different message, so I add it here for completeness:
a.cpp:5: error: dependent-name T::#typename_type not suppo
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-03-20 11:05 ---
A slightly related testcase is now properly optimized.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31146
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-03-20 11:04 ---
I agree it's surprising to get user-visible effects with the
TARGET_C99_FUNCTIONS
difference between the frontends, but they are (supposed to) providing C99
runtime completion by their runtime libraries. And they re
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-20 10:54 ---
Confirmed. Also related to PR28778 - call clobbering is broken in 4.1. I
don't
see us fixing this on the 4.1 branch though.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-20 10:43 ---
I see on x86_64 with -O2 (vrp can cleanup this somewhat):
in_canforward:
.LFB2:
movl%edi, %eax
andl$240, %eax
cmpl$240, %eax
je .L4
cmpl$224, %eax
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-20 10:39 ---
Confirmed. This is neither done at the tree nor at the rtl level.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
1 - 100 of 116 matches
Mail list logo
