--- Additional Comments From steven at gcc dot gnu dot org 2004-11-15
08:15 ---
Any progress on a fix for this bug?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16681
Dear GCC developer,
I'm not sure if this is true bug. I will explain what happens.
I have this gcc -v output:
Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.1/specs
Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local
--infodir=/usr/share/info
--- Additional Comments From hp at gcc dot gnu dot org 2004-11-15 09:51
---
Damage. When I change to emit a smallest_mode_for_size instead of BLKmode,
GCC makes a (subreg:BLK parmreg) and something else breaks. Ugh!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18494
Hello,
$ cat try.c
int main(void) {
struct X {
int s[20] : 1;
int *p : 2;
int (*f)(float) : 3;
} x;
return 0;
}
$ gcc -W -Wall -Wundef -Wendif-labels -Wshadow -Wpointer-arith -Wcast-align
-Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline
-
--
What|Removed |Added
OtherBugsDependingO||18499
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17340
The test case for 17340 exposes quadratic behavior caused by
abnormal edges in the CFG:
% cumulative self self total
time seconds secondscalls s/call s/call name
13.83 36.6037.60 272892 0.00 0.00 remove_edge
4.90 50.9213.32
--- Additional Comments From steven at gcc dot gnu dot org 2004-11-15
10:34 ---
Perhaps we should have an edge flag to mark edges dead, then walk the
entire CFG visiting all succ edges once (marking the dead ones) and
have a function remove_many_edges() in cfg.c to kill marked edges...
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-15
10:34 ---
Subject: Bug 18471
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-11-15 10:34:06
Modified files:
gcc/cp : ChangeLog decl.c name-lookup.c name-l
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-11-15
10:37 ---
Fixed by patch:
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01321.html
No formatting change was necessary. In addition, the testcase
from this PR is added as g++.dg/template/crash26.C.
--
--- Additional Comments From jh at suse dot cz 2004-11-15 10:37 ---
Subject: Re: New: [4.0 Regression] quadratic behavior in cfgexpand
> The test case for 17340 exposes quadratic behavior caused by
> abnormal edges in the CFG:
>
>
> % cumulative self self to
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18471
--- Additional Comments From stevenb at suse dot de 2004-11-15 10:41
---
Subject: Re: [4.0 Regression] quadratic behavior in cfgexpand
Actually this has always been there, independent of the edge vector
work. The old code has exactly the same problem.
There is *no* canonical way to r
--- Additional Comments From steven at gcc dot gnu dot org 2004-11-15
11:38 ---
Created an attachment (id=7547)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7547&action=view)
Suggestion for removing many edges at once
Something like this might help. There are still a few other p
It fails on the following versions of gcc.
arm-elf target, i686-pc-linux-gnu host:
gcc version 3.3.2
i386-redhat-linux: gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)
i486-linux:gcc version 3.3.4 (Debian 1:3.3.4-13)
powerpc-macintosh: gcc version 3.3 20030304 (Apple
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-15
12:04 ---
This is a regression wrt to the Fortran 77 compiler.
--
What|Removed |Added
Su
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-15
12:05 ---
This is a regression wrt to the Fortran 77 compiler.
--
What|Removed |Added
Su
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-15
12:08 ---
The compiler can now automatically emit VIS instructions with -mvis.
--
What|Removed |Added
---
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-15
12:11 ---
Investigating.
--
What|Removed |Added
CC|ebotcazou at gcc dot gnu dot|
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-15
12:16 ---
I think the sparclite-*-* targets should be removed for 4.0. Is there a new
round of target removing scheduled before the 4.0.0 release?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12027
--- Additional Comments From gerald at pfeifer dot com 2004-11-15 12:17
---
I'm seeing this in general, on *all* platforms, if I set CFLAGS to a string
ending with a blank: export CFLAGS="-pipe ", for example.
--
What|Removed |Added
--
The attached testcase has an uninitialized variable, it is not
diagnosed with -O2 -W -Wall. Gcc 3.2 says,
uninit.i: In function `bitmap_print_value_set':
uninit.i:8: warning: `first' might be used uninitialized in this function
this is a regression
--
Summary: Missing 'used unintial
--- Additional Comments From nathan at gcc dot gnu dot org 2004-11-15
13:36 ---
Created an attachment (id=7548)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7548&action=view)
test case, from tree-ssa-pre.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
--- Additional Comments From joseph at codesourcery dot com 2004-11-15
13:42 ---
Subject: Re: New: gcc allows non-integral bitfield types
On Mon, 15 Nov 2004, rwxr-xr-x at gmx dot de wrote:
> Is this a bug in gcc or am I missing something?
This is indeed a regression bug in 3.4 and 4
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
13:50 ---
Confirmed, CCP is removing the use of the uninitialized variable.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
13:51 ---
Confirmed:
: Search converges between 2003-12-16-trunk (#429) and 2003-12-17-trunk (#430).
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
14:06 ---
Confirmed, still present on the mainline.
For the mainline the problem could be solved by a DECL_EXPR around a TYPE_DECL.
--
What|Removed |Added
-
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
14:10 ---
This should be rejected, why it is not I don't know.
--
What|Removed |Added
Stat
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
14:12 ---
Does setting LD_LIBRARY_PATH to /sys/sdf/sci help?
I don't know if we can count this as a bug or not.
--
What|Removed |Added
--
What|Removed |Added
Component|libfortran |fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18496
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
14:15 ---
I think this is autoconf/automake/libtool bug (it is a quoting problem I
assume).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18222
Hello,
$ echo '??-' | gcc -P -E -trigraphs -std=gnu99 -trigraphs -
:1:1: warning: trigraph ??- ignored, use -trigraphs to enable
??-
$
That shouldn't happen. Apparently -trigraphs is ignored with -std=gnu99. Weird.
Lukas
--
Summary: trigraphs don't work with -std=gnu99
Pr
--- Additional Comments From paulthomas2 at wanadoo dot fr 2004-11-15
14:58 ---
Looking at the source of SPREAD, I note that it does not assert the rank of the
output matrix. Thus, in the fragment from the LLNL test it should be possible
to output the calls to SPREAD to temporary arra
--- Additional Comments From jlquinn at gcc dot gnu dot org 2004-11-15
15:02 ---
I don't see any of those failures. I updated tonight (11/12). Did a fresh
config and make (not bootstrap) on x86 pentium M.
FAIL: 23_containers/bitset/input/1.cc (test for excess errors)
FAIL: 23_containe
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-11-15
15:02 ---
This showed up in linux-powerpc64 builds over the weekend on build machine's
belonging to Janis and myself.
I'm just doing a normal bootstrap, not profiledbootstrap. The build machines
are both SMP mac
--
What|Removed |Added
CC||jgrimm2 at us dot ibm dot
||com
http://gcc.gnu.org/bugzilla/sho
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
15:15 ---
Confirmed, the problem is either in the C front-end (which is really the code
which drives the
preprocessor library) or in the C driver part:
/Users/pinskia/local/libexec/gcc/powerpc-apple-darwin7.6.0/4.0
Compiling the following function on x86 with options -O -fomit-frame-pointer
-msse -S seems to result in erroneous code.
#include
__m128 bug(__m128 a, __m128 b) {
__m128 c = _mm_sub_ps(a, b);
return _mm_move_ss(c, a);
}
This is what the function in the resulting .s file looke li
Compiling the following function on x86 with options -O -fomit-frame-pointer
-msse -S seems to result in erroneous code.
#include
__m128 bug(__m128 a, __m128 b) {
__m128 c = _mm_sub_ps(a, b);
return _mm_move_ss(c, a);
}
This is what the function in the resulting .s file looke li
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
15:41 ---
*** This bug has been marked as a duplicate of 18503 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
15:41 ---
*** Bug 18504 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18503
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
15:47 ---
No you are reading the asm backwards, the corresponding intel asm is:
bug:subss %xmm0, %xmm1
ret
Which you can get with -masm=intel.
--
What|Removed |Added
--
--- Additional Comments From joseph at codesourcery dot com 2004-11-15
15:51 ---
Subject: Re: trigraphs don't work with -std=gnu99
On Mon, 15 Nov 2004, pinskia at gcc dot gnu dot org wrote:
> Confirmed, the problem is either in the C front-end (which is really the code
> which drives
--- Additional Comments From torgeihe at stud dot ntnu dot no 2004-11-15
16:26 ---
Subject: Re: _mm_move_ss SSE intrinsic causes
erroneous
pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
> 15:47 ---
> No you are
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-11-15
16:46 ---
Hmmm in Makefile.in
macro_list : $(GCC_PASSES)
echo | $(GCC_FOR_TARGET) -E -dM - | \
sed -n 's/^#define \([^_][a-zA-Z0-9_]*\).*/\1/p ; \
s/^#define \(_[^_A-Z][a-zA-Z0-9_]*\)
--- Additional Comments From law at redhat dot com 2004-11-15 17:01 ---
Subject: Re: [4.0 Regression] ICE with
-funroll-loops
On Sun, 2004-11-14 at 15:47 +, kazu at cs dot umass dot edu wrote:
> --- Additional Comments From kazu at cs dot umass dot edu 2004-11-14
> 15:
--- Additional Comments From bkoz at redhat dot com 2004-11-15 17:04
---
Subject: Re: Floating point output is slow
>I don't see any of those failures. I updated tonight (11/12). Did a fresh
>config and make (not bootstrap) on x86 pentium M.
Hmmm. Well, maybe I munged the floatconv
--- Additional Comments From jlquinn at gcc dot gnu dot org 2004-11-15
17:23 ---
OK, my problem is that the patch didn't actually get applied to mainline. So
it's not so surprising I didn't see the failures.
I'll apply locally and debug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Additional Comments From zhaojiangbin at yahoo dot com 2004-11-15
17:54 ---
(In reply to comment #0)
> The code in question:
> begin
> struct C
> {
> template void f() {}
> };
>
> template void ff()
> {
> C c;
> c.f(); // <--
> }
> end
Sorry there was a m
--- Additional Comments From law at redhat dot com 2004-11-15 17:56 ---
Subject: Re: [4.0 Regression] ICE with
-funroll-loops
On Sun, 2004-11-14 at 17:50 +, giovannibajo at libero dot it wrote:
> --- Additional Comments From giovannibajo at libero dot it 2004-11-14
> 1
--- Additional Comments From phil at mkdoc dot com 2004-11-15 18:03 ---
This bug also affects GCJ 3.3.2 on GNU/Linux and 3.3.3 on Cygwin.
The class org.w3c.tidy.ParserImpl in the JTidy tool is another test case.
http://sourceforge.net/projects/jtidy/
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
18:09 ---
"c.f();" is just a dup of bug 795 which was fixed by the new parser in 3.4.x.
Now we do have a bug in that we accept the code without though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18497
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
18:12 ---
confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-11-15
18:40 ---
seems like this may just be a race on tmp-macro_list?? the macro_list code
looks bogus, but really doesn't account for the behavior. not sure how parallel
build races are protected against gcc build machine
--- Additional Comments From dorit at il dot ibm dot com 2004-11-15 18:53
---
(In reply to comment #2)
> At least on powerpc-darwin (with -m64) we now vectorize these loops but we
ICE because we have:
> pointer_type + int_type which is not valid and is even worse on 64bit targets
as in
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-11-15
19:04 ---
Just noticed there is thread on gcc-patches on this:
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01232.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18486
--- Additional Comments From giovannibajo at libero dot it 2004-11-15
19:25 ---
Doesn't the quadraticy come from VEC_unordered_remove? If you have M total
edges and you want to remove N of them, the complexity is O(N*M) with vectors,
but used to be O(N) with lists.
--
http://gcc.gn
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
19:30 ---
No they come from that fact remove_edge is O(number of edges in succ of
BB)+O(number of edges in
pred of BB) and then you are doing O(number of edges) with calling remove_edge
the whole thing now
becomes
--- Additional Comments From stevenb at suse dot de 2004-11-15 19:31
---
Subject: Re: [4.0 Regression] quadratic behavior in cfgexpand
The complexity is O(N) with vectors and with lists. How on earth
do you get to O(N*M)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18499
--- Additional Comments From jim at dishaw dot org 2004-11-15 21:55 ---
Subject: Re: Build fails with "libgmp.so.6 not found" error
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
> --- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
> 14:12 --
--- Additional Comments From bkoz at gcc dot gnu dot org 2004-11-15 22:01
---
--disable-nls doesn't kill the build, but it does give extra fails in 22_locale
for the messages facet. This is expected.
I'll close this next week unless somebody can tell me what the problem is.
-benjamin
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-15
22:10 ---
Subject: Bug 18498
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-11-15 22:10:17
Modified files:
gcc: ChangeLog c-decl.c
gcc/tests
Sometime between 20041112 (my last successful bootstrap) and 20041115, five
tests in gcc.dg/vect start getting an ICE for -m64 on powerpc64-linux-gnu:
elm3b11% /home/janis/tools/gcc-mline-20041115-patches/bin/gcc -m64 -maltivec -O2
-ftree-vectorize vect-60.c
vect-60.c: In function main1:
vect
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org |
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
22:31 ---
Yes this is the same as PR 18403, which was reported by Dorit and then found by
me that we now ICE.
*** This bug has been marked as a duplicate of 18403 ***
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
22:31 ---
*** Bug 18505 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
Poor generated code for initializing vectors with constants because vec_init
pattern is not defined for Altivec.
--
Summary: Altivec definitions of vec_init
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: enhancement
Prior
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aldyh at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
22:51 ---
PR 10469 looks like a testcase where this could improve the code generation.
--
What|Removed |Added
--
For the testcase in PR 13776 (ir.ii) we spend a lot of time (10% out of 120
seconds) in ggc_alloc.
Most of that time comes from creatting/expanding the block_defs_stack varray in
tree-into-ssa.c
Why is this GC allocated in the first place?
Maybe this should be a non-gc'ed VEC.
We know that this v
When building the compiler without bootstrapping, ie. with make all-gcc, the
file libgcc_s_nof.so.1 is always rebuilt and a bogus libgcc_s_nof.so.1. (with
a trailing dot) is created. During this rebuild basename is called without
argument because $(STAGE_PREFIX) is empty.
--
Summa
[EMAIL PROTECTED]:/tmp$ g++ -o try_catch try_catch.cc
[EMAIL PROTECTED]:/tmp$ ./try_catch
Segmentation fault (core dumped)
[EMAIL PROTECTED]:/tmp$ g++ -fomit-frame-pointer -o try_catch try_catch.cc
[EMAIL PROTECTED]:/tmp$ ./try_catch
[EMAIL PROTECTED]:/tmp$
[EMAIL PROTECTED]:/tmp$ g++ -O1 -fno-o
--- Additional Comments From tausq at debian dot org 2004-11-16 00:07
---
Created an attachment (id=7550)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7550&action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18509
--
What|Removed |Added
Component|c++ |target
Keywords||EH, wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-16
00:13 ---
This is most likely only effects 3.3.x because something changed in the
back-end to support
exceptions better.
--
What|Removed |Added
--
GCC currently doesn't have any builtin functions to access SPARCs VIS
instructions. It should have nice functions for instructions such as
fpack{16,32,fix} .
--
Summary: GCC should have instrinsics for SPARC VIS instructions
Product: gcc
Version: 4.0.0
--- Additional Comments From phython at gcc dot gnu dot org 2004-11-16
00:36 ---
Created an attachment (id=7551)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7551&action=view)
VIS intrinsics patch, fails in recog
This patch gets GCC to the point where recog fails to recognize th
--- Additional Comments From danglin at gcc dot gnu dot org 2004-11-16
00:40 ---
I don't believe there have been any specific changes to the backend
with respect to exception support since 3.3.0. 3.0 didn't have dwarf2
EH support. There possibly have been some changes in the libstdc++
--- Additional Comments From tausq at debian dot org 2004-11-16 00:55
---
(In reply to comment #3)
> I don't believe there have been any specific changes to the backend
> with respect to exception support since 3.3.0. 3.0 didn't have dwarf2
> EH support. There possibly have been some c
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca
2004-11-16 01:00 ---
Subject: Re: [3.3 only] [hppa] try-catch program fails when
> > Which exception model (sjlj or dwarf2) are you using?
>
> sjlj for gcc-3.3. now that you mention it, i see that my 3.4 compiler is
>
For x86 cross sh4-unknown-linux-gnu, 4.0.0 cc1plus segfaults
when compiling libstdc++-v3/src/localename.cc:
Program received signal SIGSEGV, Segmentation fault.
0x082d8e77 in regno_clobbered_p (regno=1139, insn=0x9bb9, mode=SImode, sets=0)
at ../../ORIG/gcc/gcc/reload.c:6931
6931 unsigned
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-16
01:51 ---
ir.cc 47.17 69.26 -31.89 72.42 129.49 -44.07 100.1 165.27
-39.43
I just sped up ir.cc a little with my patch to cp-gimplify.c (which was
committed)
Reference: http://gcc.gnu.org/ml/gc
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-16
02:01 ---
Subject: Bug 13010
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-11-16 02:01:19
Modified files:
gcc/fortran: ChangeLog
gcc/testsuite : C
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-16
02:02 ---
Subject: Bug 13010
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-11-16 02:02:38
Modified files:
gcc/fortran: trans-array.c trans-types.c trans-typ
--- Additional Comments From pbrook at gcc dot gnu dot org 2004-11-16
02:03 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
Hello,
I was just wondering around code and following code resulted in ICE (MinGW
3.4.2). I don't think that this is some kind of terrible bug as the code is
obviously wrong (or isn't it?). Maybe you'll want to know about it, at least
the compiler want me to report bug :) Maybe someone already
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-16
02:21 ---
Confirmed.
: Search converges between 2003-07-08-trunk (#288) and 2003-07-09-trunk (#289).
reduced testcase:
template struct property {
};
struct iii : public property {
const int get_callback()
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-11-16
02:35 ---
More compact testcase:
==
template struct A {};
struct B : A<0>
{
void foo() { this->A<0>; }
};
==
This is really invalid code.
--
# c++ -O2 -DUNRAR -c recvol.cpp
recvol.cpp: In member function `bool RecVolumes::Restore(RAROptions*, const
char*, const wchar*, bool)':
recvol.cpp:377: internal compiler error: Bus error
--
Summary: unrar 3.4.3 build fails with bus error
Product: gcc
V
--- Additional Comments From brian at cubik dot ca 2004-11-16 02:40 ---
Created an attachment (id=7552)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7552&action=view)
recvol.ii (preprocessed source)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18513
--- Additional Comments From jim at dishaw dot org 2004-11-16 02:41 ---
I attempted the build again execpt that I set LD_LIBRARY_PATH=/sys/sdf/sci/lib
before the first configure and it now builds to completion. Is this buggy
behaviour or the intended behaviour? One part of the configure
--
What|Removed |Added
Component|c++ |rtl-optimization
Keywords||ice-on-valid-code
http://gcc.gnu.org/bugzill
--- Additional Comments From james_avera at yahoo dot com 2004-11-16 02:47
---
Subject: Re: bad code in template function called from template class method
Hi,
Can you summarize what aliasing rule is violated?
Note that the argument is a ref, so the code is
not taking the adderess of
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-16
02:52 ---
Read http://gcc.gnu.org/bugs.html#nonbugs_general
Casting does not work as expected when optimization is turned on.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18468
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-11-16
02:55 ---
Hmmm... the following patch seems to have allowed my build to complete. Changed
sed line and created s-macro_list target/timestamp'd file, similar to what is
done throughout Makefile.in. Dropping into bugz
--- Additional Comments From phython at gcc dot gnu dot org 2004-11-16
04:17 ---
Having sparc_expand_builtin return target/op[0] instead of pat makes gets rid
of the problems in extract_insn.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18510
--- Additional Comments From law at redhat dot com 2004-11-16 04:25 ---
Subject: Re: [4.0 Regression] ICE with
-funroll-loops
On Sun, 2004-11-14 at 17:50 +, giovannibajo at libero dot it wrote:
> --- Additional Comments From giovannibajo at libero dot it 2004-11-14
> 1
Compile the following test case:
extern "C" {
typedef unsigned long size_t;
int snprintf(char * , size_t, const char * , ...) __asm("_fancy_snprintf");
}
namespace std { using ::snprintf; }
namespace std { void foo() { snprintf(0, 3, ""); } }
If you examine the assembly file or the .o file
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-16
04:37 ---
Confirmed on ppc-darwin but it works on x86-linux for some reason.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-16
05:33 ---
now I understand why it works on x86-linux, size_t is defined as unsigned int
and not unsigned long.
It worked in 3.3.
The problem appeared between 20030301 and 20030302.
--
What|Removed
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org |
Status|NEW
1 - 100 of 106 matches
Mail list logo
