Hi,
I was working on improving the results of scev, when VRP has broken
the bootstrap, eliminating loops that were estimated as running a
single time. These loop bound estimates come from the undefined
behavior of accessing over the bounds of statically allocated data in
genautomata.c:
***
On Mon, Sep 19, 2005 at 11:14:20AM +0200, Sebastian Pop wrote:
+ /* decls is statically declared as containing a single element, but
+ then, during the execution, other data is appended to the end of
+ this array, and elements over the statically allocated size are
+ accessed!
Joe Buck [EMAIL PROTECTED] writes:
In that sense, -Wall effectively means all the warnings we recommend
that you use. Some people might want to argue with this, but that
is the practical effect.
A -Weverything that turned on all boolean warnings would be nice. It
would be useless alone, but
Sebastian Pop [EMAIL PROTECTED] writes:
| Hi,
|
| I was working on improving the results of scev, when VRP has broken
| the bootstrap, eliminating loops that were estimated as running a
| single time. These loop bound estimates come from the undefined
| behavior of accessing over the bounds of
Gabriel Dos Reis wrote:
If VRP is doing what you described in the comment as its work, then
VRP is broken. Period. The fix is to fix VRP. It is such a C
idomatic construct than I would not have expected any optimizer to
break it. And that is very worrisome and scary.
Okay, VRP is not
Oh, and I'll have to say that this idiom is *so* common in C90
code, predating the specific C99 syntax, that you simply cannot
add code that breaks it. At least not enabled by default.
I was worried for a few minutes after your first message. :-)
Definitely, we cannot (again) shoot ourselves
On Mon, Sep 19, 2005 at 12:07:45PM +0200, Sebastian Pop wrote:
By the way, how is this different than detecting a bound on:
...
int foo[1335];
...
some_struct{ int foo[1335];} s;
Because here the variables are *known* to have a specific size.
Similarly with static and global variables,
Sebastian Pop [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
|
| If VRP is doing what you described in the comment as its work, then
| VRP is broken. Period. The fix is to fix VRP. It is such a C
| idomatic construct than I would not have expected any optimizer to
| break it. And
* Sebastian Pop:
By the way, how is this different than detecting a bound on:
{
int foo[1335];
for (i = 0; i some_param; i++)
foo[i];
}
vs.
{
some_struct{ int foo[1335];} s;
for (i = 0; i some_param; i++)
s.foo[i];
}
Nothing. But in the genautomata case,
Original Message
From: Richard Henderson
Sent: 19 September 2005 11:26
On Mon, Sep 19, 2005 at 12:07:45PM +0200, Sebastian Pop wrote:
By the way, how is this different than detecting a bound on: ...
int foo[1335];
...
some_struct{ int foo[1335];} s;
Because here the variables
Dave Korn [EMAIL PROTECTED] wrote:
Do you suppose the idiom is common enough that VRP could special-case
arrays of size 1 at the end of a struct ? And still obtain the benefits
of the optimisation in 99.99% of all non-variable-length-tail-array cases?
It makes sense to me. We could special
On Mon, 12 Sep 2005, Giovanni Bajo wrote:
I suggest you to double check also the list present in this mail:
http://gcc.gnu.org/ml/gcc-patches/2004-06/msg01625.html
This was never publically approved, but it reflects views of many GCC
maintainers. Surely it does not hurt to follow those
Gerald Pfeifer [EMAIL PROTECTED] wrote:
I suggest you to double check also the list present in this mail:
http://gcc.gnu.org/ml/gcc-patches/2004-06/msg01625.html
This was never publically approved, but it reflects views of many GCC
maintainers. Surely it does not hurt to follow those
Dave Korn [EMAIL PROTECTED] writes:
| Original Message
| From: Richard Henderson
| Sent: 19 September 2005 11:26
|
| On Mon, Sep 19, 2005 at 12:07:45PM +0200, Sebastian Pop wrote:
| By the way, how is this different than detecting a bound on: ...
|int foo[1335];
| ...
|
Giovanni Bajo [EMAIL PROTECTED] writes:
| Dave Korn [EMAIL PROTECTED] wrote:
|
|Do you suppose the idiom is common enough that VRP could special-case
| arrays of size 1 at the end of a struct ? And still obtain the benefits
| of the optimisation in 99.99% of all
Thanks for all the explanations.
Richard Henderson wrote:
In the case of the (fake) flexible array member, you do not know
how large the object allocated from malloc was unless you can
track down the actual malloc call.
Gabriel Dos Reis wrote:
typedef struct {
int data[1];
Gabriel Dos Reis [EMAIL PROTECTED] wrote:
Do you suppose the idiom is common enough that VRP could special-case
arrays of size 1 at the end of a struct ? And still obtain the
benefits
of the optimisation in 99.99% of all non-variable-length-tail-array
cases?
It makes sense to me. We could
Original Message
From: [EMAIL PROTECTED]
Sent: 19 September 2005 12:09
Dave Korn writes:
Original Message
From: Richard Henderson
Sent: 19 September 2005 11:26
In the case of the (fake) flexible array member, you do not know
how large the object allocated from malloc was
Andrew Pinski wrote:
On Sep 19, 2005, at 12:46 AM, H. J. Lu wrote:
http://people.redhat.com/dnovillo/spec2000/
shows that gcc 4.1 has been failing vortex in SPEC CPU 2000 on
Linux/EM64T and Linux/PPC64 at least since Aug. 7, 2005. The current
gcc 4.1 also failed vortex on Linux/ia64. Is that
On Mon, 19 Sep 2005, Giovanni Bajo wrote:
I see that I reviewed it with two days back then. Not everything I
could/can approve as web pages maintainer (because it looks like
policy changes), but I see that about half of the changes I only
had minor editorial comments on.
Would you mind
Hello,
You really do not want to get a correction for:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23631
before release?
I checked again with 4.0.2 20050917, and nothing
has changed since:
http://gcc.gnu.org/ml/gcc/2005-09/msg00251.html
Etienne.
Per Abrahamsen wrote:
The idea was that you would be sure to get all the (boolean) warnings
that are relevant for your project, and can give an explicit reason
for each warning you don't want.
It would be particularly useful when upgrading GCC, in order to be
sure you get the benefit of any
Giovanni Bajo [EMAIL PROTECTED] writes:
| Gabriel Dos Reis [EMAIL PROTECTED] wrote:
|
|Do you suppose the idiom is common enough that VRP could special-case
| arrays of size 1 at the end of a struct ? And still obtain the
| benefits
| of the optimisation in 99.99% of all
If this is still correct, I will just restrict the analyzer to not
infer any property from data defined in structs.
This is wrong :).
If accessing p-bar via p-before_end[5] is not correct, I can
restrict the analyzer to work only on non last array in a struct.
You can't guarantee
On Mon, Sep 19, 2005 at 09:03:48AM -0400, Daniel Berlin wrote:
Anyway, the real fix is to simply not attempt to derive information when
the access is through a pointer (IE it is not related to structs at all,
it's the fact that these are heap allocated), unless you have info about
the malloc
Daniel Berlin [EMAIL PROTECTED] writes:
| |
| | Do you suppose the idiom is common enough that VRP could special-case
| | arrays of size 1 at the end of a struct ?
|
| it could be array of size 2, 3, 4, 5, ...
|
| Except that anything but array of size 1 is not such a C idomatic
|
Robert Dewar [EMAIL PROTECTED] writes:
Per Abrahamsen wrote:
The idea was that you would be sure to get all the (boolean) warnings
that are relevant for your project, and can give an explicit reason
for each warning you don't want.
It would be particularly useful when upgrading GCC, in
On Mon, 2005-09-19 at 15:07 +0200, Jakub Jelinek wrote:
On Mon, Sep 19, 2005 at 09:03:48AM -0400, Daniel Berlin wrote:
Anyway, the real fix is to simply not attempt to derive information when
the access is through a pointer (IE it is not related to structs at all,
it's the fact that these
On Fri, 2 Sep 2005, Christopher Faylor wrote:
Huh? What does Red Hat have to do with anything? Red Hat doesn't
provide the tools. Cygwin is a volunteer effort.
According to http://cygwin.com/license.html (and the link from there)
Red Hat does provide tools for some set of users at least:
On 9/19/05, Paolo Bonzini [EMAIL PROTECTED] wrote:
I applied the patch by hand (not working with CVS) and it
does _not_ solve the problem.
In this case, I am sorry but the probability of a fix before the release
is close to zero.
The problem with 4.0 is that it behaves completely
1. Not interprocedurally.
True, it was written before the IPA infrastructure was added.
For 4.2 the plan is to rewrite it using Diego's propagator and then
IPA propagation should be added too. It will be useful for both
__builtin_object_size builtin itself as well as other passes that might
Original Message
From: [EMAIL PROTECTED]
Sent: 19 September 2005 14:01
Dave Korn [EMAIL PROTECTED] writes:
[...]
I've seen this trick used again and again and again, and *I* haven't
_ever_ seen anyone use anything except an array size of [1] in this
place.
[...]
Have
Gabriel Dos Reis [EMAIL PROTECTED] wrote:
Do you suppose the idiom is common enough that VRP could
special-case
arrays of size 1 at the end of a struct ? And still obtain the
benefits of the optimisation in 99.99% of all
non-variable-length-tail-array cases?
It makes sense to me. We
shreyas krishnan wrote:
Hi ,
I am looking for an efficient data structure to map from a
range of addresses to a single address. As it is used at runtime, I
want it to be as efficient as possible, with perhaps updaing more
important that retreiving. Are there any examples of such data
shreyas == shreyas krishnan [EMAIL PROTECTED] writes:
shreyas Hi , I am looking for an efficient data structure to map
shreyas from a range of addresses to a single address. As it is
shreyas used at runtime, I want it to be as efficient as possible,
shreyas with perhaps updaing more
Florian Weimer wrote:
Doesn't it eleminate too many checks, even? 8-/
Not that I know of
And, to be absolutely honest, Ada only requires a small subset of all
the checks that are required to make pointers completely safe. Once
you use 'Unchecked_Access, Unchecked_Deallocation, or GNAT's
I understand a tree, perhaps height balanced would give me a O(logn).
I am also worried abt
the constant factor for these or in other words the quality of
compiler generated code for such mechanisms. Any ideas on that ?
Shrey
On 9/19/05, Paul Koning [EMAIL PROTECTED] wrote:
shreyas ==
On Sep 19, 2005, at 5:14 AM, Sebastian Pop wrote:
Hi,
I was working on improving the results of scev, when VRP has broken
the bootstrap, eliminating loops that were estimated as running a
single time. These loop bound estimates come from the undefined
behavior of accessing over the bounds of
WHY are you resurrecting this discussion?
On Mon, Sep 19, 2005 at 03:30:37PM +0200, Gerald Pfeifer wrote (after a 2+ week
delay):
On Fri, 2 Sep 2005, Christopher Faylor wrote:
Huh? What does Red Hat have to do with anything? Red Hat doesn't
provide the tools. Cygwin is a volunteer effort.
On Monday 19 September 2005 01:10, Joe Buck wrote:
On Sun, Sep 18, 2005 at 06:54:26PM +0200, Florian Weimer wrote:
Generally speaking, we want -Wall to be safe to use. gcc has some
warnings that can't be silenced without making correct programs
worse (-Weffc++ comes to mind); these are not
Hi,
We're assessing many proposals to add forwarding constructors and
forwarding functions to C++0x; and I got a question.
In standard C++, constructors cannot be recursive functions. I'm
wondering whether the multiple entry-points implementation strategy used
by GCC depends in anyway on
On Sep 19, 2005, at 1:44 PM, Gabriel Dos Reis wrote:
Hi,
We're assessing many proposals to add forwarding constructors and
forwarding functions to C++0x; and I got a question.
In standard C++, constructors cannot be recursive functions. I'm
wondering whether the multiple entry-points
Please test, post test results to gcc-testresults, and send me an email
pointing at the results.
Still OK for SPARC/Solaris:
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00929.html
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00930.html
On Mon, Sep 19, 2005 at 01:50:35PM -0400, Andrew Pinski wrote:
On Sep 19, 2005, at 1:44 PM, Gabriel Dos Reis wrote:
Hi,
We're assessing many proposals to add forwarding constructors and
forwarding functions to C++0x; and I got a question.
In standard C++, constructors cannot
Andrew Pinski [EMAIL PROTECTED] writes:
| On Sep 19, 2005, at 1:44 PM, Gabriel Dos Reis wrote:
|
|
| Hi,
|
| We're assessing many proposals to add forwarding constructors and
| forwarding functions to C++0x; and I got a question.
|
| In standard C++, constructors cannot be recursive
L.S.
A simple question:
When I build a shared object (or executable) by doing:
gcc -pipe -o myLib.so myLib.c -lm
How does the linker get the object code for myLib?
a. from a temporary file, saved by the compiler?
b. on stdin from a pipe that connects to the compilers stdout?
c. ???
The
On Sep 17, 2005, at 3:33 PM, Gabriel Dos Reis wrote:
C++98 came before C99, so who diverged from whom?
You seem to not not how the C++ standard was made. In fact, it come
before C99, like it or not. The intention was that C++ would come up
with a follow on standard that tracked C99, in
Erik Leunissen [EMAIL PROTECTED] writes:
gcc -pipe -o myLib.so myLib.c -lm
How does the linker get the object code for myLib?
a. from a temporary file, saved by the compiler?
b. on stdin from a pipe that connects to the compilers stdout?
c. ???
It's case a. The -pipe option is ignored
On Sep 18, 2005, at 2:43 PM, Ulrich Weigand wrote:
In fact, as far as I can recall, 4.0.2 will be the first
ever GCC release with zero testsuite FAILs across all
languages on s390-ibm-linux ...
[ rub eyes ]
[ head explodes ]
[ desperately trying to make sense of the world ]
You didn't test
Mike Stump [EMAIL PROTECTED] writes:
| On Sep 17, 2005, at 3:33 PM, Gabriel Dos Reis wrote:
| C++98 came before C99, so who diverged from whom?
|
| You seem to not not how the C++ standard was made.
Thank you very much.
| In fact, it come before C99, like it or not.
Oh really? What did I
Original Message
From: Andreas Schwab
Sent: 19 September 2005 20:20
Erik Leunissen [EMAIL PROTECTED] writes:
gcc -pipe -o myLib.so myLib.c -lm
How does the linker get the object code for myLib?
a. from a temporary file, saved by the compiler?
b. on stdin from a pipe that
GCC 4.0.2 RC2 is now available here
Sill ok on arm-none-elf:
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00938.html
Paul
You didn't test --enable-languages=obj-c++
Yeah, it's a plot, we positively refuse to test everything Apple has *not*
contributed. ;-)
--
Eric Botcazou
On Sep 19, 2005, at 3:21 PM, Mike Stump wrote:
On Sep 18, 2005, at 2:43 PM, Ulrich Weigand wrote:
In fact, as far as I can recall, 4.0.2 will be the first
ever GCC release with zero testsuite FAILs across all
languages on s390-ibm-linux ...
[ rub eyes ]
[ head explodes ]
[ desperately
Anyways, all of the known failures with the obj-c++ with the GNU
runtime have been filed and someone needs to look into them.
Are you talking about these?
=== obj-c++ tests ===
Running target unix
FAIL: obj-c++.dg/bitfield-1.mm (test for excess errors)
FAIL:
On Sep 19, 2005, at 4:21 PM, Eric Botcazou wrote:
Anyways, all of the known failures with the obj-c++ with the GNU
runtime have been filed and someone needs to look into them.
Are you talking about these?
I filed them as bugs, not fixed them.
Thanks,
Andrew Pinski
Please test, post test results to gcc-testresults, and send me an email
pointing at the results.
OK for sh4-unknown-linux-gnu:
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00902.html
Regards,
kaz
On Sun, Sep 18, 2005 at 09:41:54AM -0700, Mark Mitchell wrote:
Please test, post test results to gcc-testresults, and send me an email
pointing at the results.
OK for powerpc64-unknown-linux-gnu:
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00942.html
Janis
Gabriel Dos Reis said:
[...]
Good. It seems to me like those who would be spending a great deal of
time and money are not sufficiently convinced by your arguments.
Consequently, it appears that they are not in position to explain your
strong opinion to the committees -- personally, I'm not
Just to review, the second function here was the problem:
(-march=pentium4 -mtune=prescott -O2 -mfpmath=sse -msse2)
#include xmmintrin.h
__m128i foo3(__m128i z, __m128i a, int N) {
int i;
for (i=0; iN; i++) {
a = _mm_add_epi64(z, a);
}
return
On Mon, Sep 19, 2005 at 05:19:20PM -0700, Dale Johannesen wrote:
(Although just which subregs are safe to look under will require more
attention than I've given it, if we want this in.)
Look at MODES_TIEABLE or something.
Really I don't think this is an RA problem at all.
You don't?!?
On Sep 19, 2005, at 5:30 PM, Richard Henderson wrote:
(define_insn *addmixedmode3
[(set (match_operand:V2DI 0 register_operand =x)
(subreg:V2DI (plus:SSEMODE124
(match_operand:SSEMODE124 2 nonimmediate_operand xm)
(subreg:SSEMODE124 (match_operand:V2DI 1
Zack Weinberg [EMAIL PROTECTED] writes:
[...]
| Also: why do you care so much about this corner case? I only care from the
| implementation perspective, since I doubt it matters to any real software that
| GCC might compile. I'm pointing out an approach to the problem which would
| avoid
Another correction:
Shin-ming Liu (HP) attended the meeting. In fact, he led the call :-)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Mark K. Smith
Sent: Monday, September 19, 2005 4:00 PM
To: Gelato-GCC; GCC
Subject: 15 Sept notes from GCC
On Mon, 2005-09-19 at 17:33 -0700, Dale Johannesen wrote:
On Sep 19, 2005, at 5:30 PM, Richard Henderson wrote:
(define_insn *addmixedmode3
[(set (match_operand:V2DI 0 register_operand =x)
(subreg:V2DI (plus:SSEMODE124
(match_operand:SSEMODE124 2 nonimmediate_operand xm)
Gabriel Dos Reis wrote:
In standard C++, constructors cannot be recursive functions. I'm
wondering whether the multiple entry-points implementation strategy used
by GCC depends in anyway on the absence of recursive definition.
Echoing others, I do not forsee any problem with multiple
Etienne Lorrain wrote:
Hello,
You really do not want to get a correction for:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23631
before release?
I'd love to get a patch for this problem. -- but there's no readily
available prospect, and this is not a regression from 4.0.x. The
primary
On Mon, Sep 19, 2005 at 05:33:54PM -0700, Dale Johannesen wrote:
Do you have any constructive suggestions for how the RA might be fixed,
then?
Short term? No. But I don't see this as a short term problem.
r~
Hello,
It's my new port of gcc. Libgcc is almost compiled for now, except
unwind-dw2-fde.c.
The error information is
'../../gcc-3.4.4/gcc/unwind-dw2-fde.c:968: internal compiler error:
in insert_save,
at caller-save.c:728
Please submit a full bug report'
Of course, there are some thing wrong
--- Additional Comments From dorit at il dot ibm dot com 2005-09-19 06:52
---
do these ia64 reduction testcase failures still occur?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23188
--- Additional Comments From dorit at il dot ibm dot com 2005-09-19 06:54
---
does this ia64 reduction testcase failure still occur?
--
What|Removed |Added
Compiler version:
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.4/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-19
07:09 ---
No because you are violating C/C++ aliasing rules.
See http://gcc.gnu.org/bugs.html
Casting does not work as expected when optimization is turned on.
It applies to both C and C++.
Yes -Wstrict-aliasing
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-19
07:09 ---
*** Bug 23961 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-19
07:12 ---
For anyone else.
Read http://gcc.gnu.org/bugs.html
The non bug section: Casting does not work as expected when optimization is
turned on. part.
Also 14024 is the bug for C++ front-end not reporting
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-19
08:15 ---
Are you sure you did mean PR23490? This talks about a rtl problem...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23955
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-09-19
08:18 ---
*** This bug has been marked as a duplicate of 15975 ***
--
What|Removed |Added
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-09-19
08:18 ---
*** Bug 16606 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
Bug
--
Bug 22101 depends on bug 16606, which changed state.
Bug 16606 Summary: gfortran error with a valid derived type definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16606
What|Old Value |New Value
TOTAL : 129.54 5.37 135.98
Peak memory usage is 468694 kB (4.0.2 20050919) vs. 532350 kB (4.1.0 20050916).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23955
gfortran -c bug3.f90
bug3.f90: In function set_value:
bug3.f90:12:
Please submit a full bug report,
with preprocessed source if appropriate.
See
The following code causes an ICE with any -O flag except -O0:
#include mmintrin.h
#include stdint.h
int main(int argc, char *argv[]) {
__m64 a, b, c;
a = b = c = (__m64)(uint64_t)argc; /* Load with arbitrary values */
a = _mm_slli_pi16(a, 3);
a = _mm_adds_pi16(a, b);
c =
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-19
11:07 ---
Even the bad timings for postreload-gcse are almost entirely to blame on RTL
alias analysis:
CPU: P4 / Xeon with 2 hyper-threads, speed 3194.18 MHz (estimated)
Counted GLOBAL_POWER_EVENTS events (time
The -Wparentheses switch (as well as -Wall) doesn't catch logical assignments
used as truth values. For example:
int i = 0;
if (i |= 1) {};
if (i ^= 1) {};
if (i = 1) {};
--
Summary: -Wparentheses doesn't catch all assignments used as
truth value
--- Additional Comments From Erwin dot Unruh at fujitsu-siemens dot com
2005-09-19 12:25 ---
Created an attachment (id=9773)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9773action=view)
testcase supplement
Here is some additional coding, which calls the function given in the bug
--- Additional Comments From falk at debian dot org 2005-09-19 12:28
---
(In reply to comment #0)
The -Wparentheses switch (as well as -Wall) doesn't catch logical assignments
used as truth values. For example:
int i = 0;
if (i |= 1) {};
if (i ^= 1) {};
if (i = 1) {};
What
--- Additional Comments From glebius at FreeBSD dot org 2005-09-19 13:06
---
Subject: Re: -Wparentheses doesn't catch all assignments used as truth value
On Mon, Sep 19, 2005 at 12:28:55PM -, falk at debian dot org wrote:
f --- Additional Comments From falk at debian dot org
--- Additional Comments From falk at debian dot org 2005-09-19 13:14
---
(In reply to comment #2)
Well, all these examples are assignments. I don't agree that '=' is a somewhat
unique or special assignment.
But of course it is. It is the only case where people make mistakes.
--- Additional Comments From glebius at FreeBSD dot org 2005-09-19 13:21
---
Subject: Re: -Wparentheses doesn't catch all assignments used as truth value
On Mon, Sep 19, 2005 at 01:14:18PM -, falk at debian dot org wrote:
f Well, all these examples are assignments. I don't agree
--- Additional Comments From amacleod at redhat dot com 2005-09-19 14:03
---
I thought there was a discussion in
http://gcc.gnu.org/ml/gcc/2005-08/msg00692.html
where the solution for dealing with releasing ssa names now that we have
immediate use data available all the time is to
For the testcase
templatetypename T void foo(T);
void bar()
{
struct A a;
foo(a);
}
the we get the following error message since GCC 3.4.0:
bug.cc: In function 'void bar()':
bug.cc:5: error: aggregate 'A a' has incomplete type and cannot be defined
bug.cc:6: error: no
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot
|dot org |org
URL|
--
What|Removed |Added
Component|c |target
Keywords||ice-on-valid-code, ssemmx
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-19
14:45 ---
I could sware this was discussed before in a bug.
--
What|Removed |Added
--
What|Removed |Added
Known to fail||4.0.2
Known to work||4.1.0
Summary|MMX intrinsics cause ICE in
--
What|Removed |Added
Severity|critical|normal
Keywords||ice-on-valid-code
Summary|internal compiler
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-19
15:14 ---
*** This bug has been marked as a duplicate of 19546 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-19
15:14 ---
*** Bug 23962 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-09-19
15:19 ---
Another patch that improves the code on i686:
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01159.html
(with -O2 -fomit-frame-pointer:)
.L4:
movl(%ebp,%edx,4), %eax
movl
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-19
15:23 ---
(In reply to comment #1)
where the solution for dealing with releasing ssa names now that we have
immediate use data available all the time is to simply add a lightning fast
pass
which removes unused
1 - 100 of 164 matches
Mail list logo
