--- Comment #2 from george dot chapman at lmco dot com 2006-04-17 22:01
---
Created an attachment (id=11288)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11288action=view)
shell input
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27186
Test gcc.target/powerpc/doloop-1.c has failed on mainline for powerpc64-linux
with -m64 and for powerpc-apple-darwin8.5.0 since this patch was added:
http://gcc.gnu.org/viewcvs?view=revrev=112126
r112126 | mkuvyrkov | 2006-03-16 05:20:39 + (Thu, 16 Mar 2006) | 9 lines
2006-03-16 Maxim
--
bdavis at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bdavis at gcc dot gnu dot
|dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-17 22:54 ---
*** This bug has been marked as a duplicate of 26727 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-17 22:54 ---
*** Bug 27187 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
|| echo './'`kopetecontactlist.cpp
kopetecontactlist.cpp: In member function `QStringList
KopeteContactList::contactFileProtocols(const QString)':
kopetecontactlist.cpp:779: internal error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See
--- Comment #7 from alexey at cs dot sunysb dot edu 2006-04-18 00:06
---
(In reply to comment #6)
In C, there is no ordering left to right, please go read the C FAQ at:
http://www.eskimo.com/~scs/c-faq.com/expr/index.html
subpage:
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-04-18 00:21 ---
(In reply to comment #7)
(In reply to comment #6)
In C, there is no ordering left to right, please go read the C FAQ at:
http://www.eskimo.com/~scs/c-faq.com/expr/index.html
subpage:
--- Comment #3 from george dot chapman at lmco dot com 2006-04-18 00:35
---
(From update of attachment 11287)
Missing body for Managed_Storage.
--
george dot chapman at lmco dot com changed:
What|Removed |Added
--- Comment #4 from george dot chapman at lmco dot com 2006-04-18 00:36
---
Created an attachment (id=11289)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11289action=view)
gnatchop input
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27186
--- Comment #5 from george dot chapman at lmco dot com 2006-04-18 00:40
---
Compiles at -O0 but not -O1 and subsequent.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27186
/home/dave/gcc-4.2/objdir/./gcc/xgcc -B/home/dave/gcc-4.2/objdir/./gcc/
-B/home/
dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/bin/
-B/home/dave/opt/gnu/gcc/gcc-4.2.0/hp
pa-linux/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/include
-isys
tem
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||aldyh at gcc dot gnu dot org
Keywords|
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-18 01:33 ---
Sorry Aldy for CCing you (I saw prune_unused and thought it was your front-end
patch). When in fact it was:
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00641.html
That caused the ICE.
--
pinskia at gcc dot
char* help =
Usage: foo [options]
-v verbose
-d debug
;
Code like the above should work. It is really convenient when editing this
code that you do not have to terminate your lines with cruft like \n\
Of course this is pure convenience, but I never heard any convincing
argument why this
--- Comment #2 from wszafran at users dot sourceforge dot net 2006-04-18
03:10 ---
Yes, it works like a charm now. I only built the CygWin-hosted,
MinGW-targetting compiler with your patch applied, but I suppose a similar
result would be achieved with a compiler bootstrapped on
--- Comment #9 from bangerth at dealii dot org 2006-04-18 03:21 ---
It does not matter either. The evaluation of a function argument is an atomic
procedure.
No, it actually isn't.
If it starts it should generate a result. Isn't it strange if the
compiler evaluates a little bit
--- Comment #4 from bangerth at dealii dot org 2006-04-18 03:28 ---
This is not a bug. While the name in a function call is looked up from
inside the class, the name of a member function is looked up in the
global scope. There, the member in question here is inaccessible.
W.
--
--- Comment #1 from bangerth at dealii dot org 2006-04-18 03:30 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
/home/jerry/gcc/4.2/./gcc/xgcc -B/home/jerry/gcc/4.2/./gcc/
-B/home/jerry/gcc/usr/i686-pc-linux-gnu/bin/
-B/home/jerry/gcc/usr/i686-pc-linux-gnu/lib/ -isystem
/home/jerry/gcc/usr/i686-pc-linux-gnu/include -isystem
/home/jerry/gcc/usr/i686-pc-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC
-W
--- Comment #2 from bangerth at dealii dot org 2006-04-18 03:45 ---
Confirmed, though this doesn't seem to have anything to do with PR 9050.
Here's a shorter testcase:
--
struct B{};
struct Bar : virtual B {
template typename T Bar( T const cast );
};
--- Comment #3 from bangerth at dealii dot org 2006-04-18 03:47 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #8 from bangerth at dealii dot org 2006-04-18 03:50 ---
We've had numerous such reports in the past. The compiler can't do anything
to detect whether it has run out of stack space. What happens is that a
program allocates stack space, the operating systems gives it to the
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27053
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-04-18 03:51
---
I just found this already reported.
*** This bug has been marked as a duplicate of 27188 ***
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-04-18 03:51
---
*** Bug 27191 has been marked as a duplicate of this bug. ***
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
The program below confuses gcc in such a way that it generates code loading the
byte-address of bar() into the Z register, which causes icall to jump off to
neverneverland. Rather, the double-byte address of bar() should be loaded into
Z before the indirect call.
This bug is also present in gcc
dump-tree-original-raw does not print the linkage for
a variable with file scope.
--- test case (sta.c)---
static int static_var=9;
double global_var = 0;
main() {
int x;
x = 4+ static_var + global_var;
return x;
}
-- to reproduce ---
gcc -fdump-tree-original-raw sta.c
101 - 128 of 128 matches
Mail list logo
