Hi,
my latest typo (a typename in the return statement of a template
function) caused an internal compiler error with gcc 4.0.2 and
gcc 3.4.3. (No ICE with gcc 3.3.4).
#include utility
templatetypename It typename std::pairIt,double
test(It it)
{
return typename std::pairIt,double(it, 0.0);
--- Comment #2 from bonzini at gcc dot gnu dot org 2005-11-21 08:24 ---
easy_altivec_constant should only be called with AltiVec integer vector modes,
all of which can be represented with a const_vector of const_ints. Anyway,
looking into it.
Paolo
--
bonzini at gcc dot gnu dot
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2005-11-21 09:02
---
It should now work again on all supported platforms.
Confirmed on all versions of Solaris. Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24909
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2005-11-21 09:11
---
(In reply to comment #0)
conjga = conj(*pa);
or
conjga = conjl(*pa);
or
conjga = conjf(*pa);
I'm ready to do that, but since complex numbers in C are always a pain, I want
to know: are we sure that
--- Comment #3 from bonzini at gcc dot gnu dot org 2005-11-21 09:12 ---
Got a patch, but I am curious about Andrew's comment. I couldn't find a reason
why r106588 *introduced* the bug rather than unveiling a latent one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24951
--- Comment #11 from krebbel at gcc dot gnu dot org 2005-11-21 09:29
---
Ok, knowing that this may only happen if the return value
of a function has a complex type a trivial fix could look
like this:
Index: gcc/flow.c
===
--- Comment #12 from jakub at gcc dot gnu dot org 2005-11-21 09:41 ---
Subject: Bug 17965
Author: jakub
Date: Mon Nov 21 09:41:42 2005
New Revision: 107289
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107289
Log:
PR middle-end/17965
* calls.c (expand_call,
--- Comment #13 from jakub at gcc dot gnu dot org 2005-11-21 09:43 ---
Subject: Bug 20303
Author: jakub
Date: Mon Nov 21 09:43:10 2005
New Revision: 107290
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107290
Log:
2005-05-18 H.J. Lu [EMAIL PROTECTED]
PR
--- Comment #1 from charlet at gcc dot gnu dot org 2005-11-21 09:43 ---
I got a bugzilla internal error when trying to attach a proposed
patch, so here it is inline (be careful with tabs and spaces,
I'd suggest applying the patch manually):
--- libada/Makefile.in.orig 2005-11-21
--- Comment #10 from jakub at gcc dot gnu dot org 2005-11-21 09:52 ---
Subject: Bug 17828
Author: jakub
Date: Mon Nov 21 09:52:20 2005
New Revision: 107297
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107297
Log:
PR target/17828
*
--- Comment #12 from jakub at gcc dot gnu dot org 2005-11-21 09:55 ---
Subject: Bug 20268
Author: jakub
Date: Mon Nov 21 09:55:14 2005
New Revision: 107300
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107300
Log:
PR debug/20268
* dwarf2out.c
--- Comment #31 from pcarlini at suse dot de 2005-11-21 10:40 ---
(In reply to comment #30)
Created an attachment (id=10303)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10303action=view) [edit]
Defines __cplusplus to 199711L and overrides it in c++config.h for solaris 8
As-is,
--- Comment #39 from gdr at gcc dot gnu dot org 2005-11-21 10:41 ---
Fixed in 4.0.0 and higher.
Won't fix for 3.4.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from pluto at agmk dot net 2005-11-21 11:29 ---
without Uros' mmx-patch the gcc-4.1.0-20051113 generates amazing code:
(gcc -O3 -march=pentium3 -S -fomit-frame-pointer pr14552.c)
test: subl$20, %esp
movlw, %eax
movlw+4, %edx
movl
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|uros at kss-loka dot si |unassigned at gcc dot gnu
|
--- Comment #17 from pcarlini at suse dot de 2005-11-21 11:34 ---
Sorry.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2005-11-21 11:45
---
FreeBSD has the same problem with missing long double math
functions. I tried to add an appropriate XFAIL clause for
FreeBSD, but dejagnu would still process the file.
Huh... the following patch fixes the
--- Comment #16 from fxcoudert at gcc dot gnu dot org 2005-11-21 12:04
---
(In reply to comment #15)
Huh... the following patch fixes the problem for me. Can I install it?
Fine with me. Consider approved after testing on some C99-aware platform (like
solaris2.10). Please commit on
The following source will report
C:\Dev-Cpp\Projects\test-stlport\main_17.cpp In function `void test_17()':
12 C:\Dev-Cpp\Projects\test-stlport\main_17.cpp [Warning] will never be
executed
12 C:\Dev-Cpp\Projects\test-stlport\main_17.cpp [Warning] will never be
executed
when using
FAIL: tmpdir-gcc.dg-struct-layout-1/t026 c_compat_x_tst.o-c_compat_y_tst.o
execute
(more specifically, test2495 fails)
--
Summary: [4.1/4.2 Regression] tmpdir-gcc.dg-struct-layout-1/t026
fails execution
Product: gcc
Version: 4.1.0
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-21 12:22 ---
Created an attachment (id=10306)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10306action=view)
testcase
Compile and link the three files in the tar with -O0.
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-11-21 12:26 ---
works on i686 with 4.1.0 and 4.0.2
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #32 from pedro dot lamarao at mndfck dot org 2005-11-21 12:26
---
Yes, I'll take a shot at this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-11-21 12:29 ---
4.0.2 seems to fail also, maybe a testsuite bug? Still somebody needs to
investigate closer.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from hubicka at gcc dot gnu dot org 2005-11-21 13:14 ---
Subject: Bug 24653
Author: hubicka
Date: Mon Nov 21 13:14:02 2005
New Revision: 107304
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107304
Log:
PR tree-optimization/24653
* tree-ssa-ccp.c
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-21 13:17 ---
Fixed for 4.0.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #33 from pedro dot lamarao at mndfck dot org 2005-11-21 13:26
---
Created an attachment (id=10307)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10307action=view)
Defines __cplusplus to 199711L and overrides it for solaris 8 *only*
Please see comment #33 before
--- Comment #34 from pedro dot lamarao at mndfck dot org 2005-11-21 13:29
---
I attached a patch containing Paolo's suggestions.
It was produced with svn diff -x -up after an svn copy like this:
[EMAIL PROTECTED] gcc] svn copy libstdc++-v3/config/os/solaris/solaris2.{7,8}
svn diff
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-21 13:30 ---
Fixed at least on the mainline for 4.2.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #35 from pcarlini at suse dot de 2005-11-21 13:35 ---
(In reply to comment #34)
I attached a patch containing Paolo's suggestions.
Thanks. Looks fine to me. If Eric could test it on his Solaris machines it
would be great (remember the svn copy! ;) ...
Before finally
--- Comment #4 from rguenth at gcc dot gnu dot org 2005-11-21 13:40 ---
Old value = 0
New value = 1
check2495 (arg0={a = 27121, b = {c = {d = true, e = 359101392}}},
arg1=0x5019ec, arg2={a = 30216, b = {c = {d = true, e = 1}}})
at t026_y.min.i:71
71 if (arg2.b.c.e !=
--- Comment #10 from ray at ultramarine dot com 2005-11-21 13:52 ---
(In reply to comment #9)
(In reply to comment #8)
Tried yesterday's snapshot of 4.1 and it still does not work.
OK, I'm on it. Looks like someone forgot about CRLF systems :)
I'll try to submit a first patch
--- Comment #36 from ebotcazou at gcc dot gnu dot org 2005-11-21 13:59
---
Thanks. Looks fine to me. If Eric could test it on his Solaris machines it
would be great (remember the svn copy! ;) ...
Sure.
Before finally committing it, probably we want to add a short comment before
When trying to compile the attached source file with
$ ~/gcc/bin/g++ --version
g++ (GCC) 4.2.0 20051121 (experimental)
with the options
/Users/eschnett/gcc/bin/g++ -DCARPET_INT -DCARPET_REAL -DCARPET_COMPLEX
-mlongcall -ftrapv -fwrapv -fbounds-check -g3 -Wall -Wshadow -Wpointer-arith
-Wcast
--- Comment #1 from schnetter at aei dot mpg dot de 2005-11-21 14:01
---
Created an attachment (id=10309)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10309action=view)
Failing source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24970
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2005-11-21 14:02
---
(In reply to comment #10)
The following changes in transfer.c appear to fix the problem in Linux:
Confirming this patch, I have something similar in my own tree. But there are
some other problems with CRLF and
--- Comment #2 from schnetter at aei dot mpg dot de 2005-11-21 14:03
---
Created an attachment (id=10310)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10310action=view)
Failing preprocessed sourc code (gzipped)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24970
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2005-11-21 14:06
---
Fine with me. Consider approved after testing on some C99-aware platform (like
solaris2.10)
Thanks. My main machine is actually x86-64/Linux so I've verified there that
the large real tests are still
--- Comment #5 from rguenth at gcc dot gnu dot org 2005-11-21 14:06 ---
Disassembly with the first two checks removed (only the third aborts):
foo:
.LFB2:
subq$24, %rsp #,
.LCFI0:
movlx+8(%rip), %eax #, tmp62
movl16(%rsp), %edx #, tmp60
--- Comment #12 from jvdelisle at verizon dot net 2005-11-21 14:21 ---
Subject: Re: GFORTRAN input and carriage returns
fxcoudert at gcc dot gnu dot org wrote:
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2005-11-21 14:02
---
(In reply to comment #10)
The
--- Comment #6 from matz at suse dot de 2005-11-21 14:25 ---
Something is fishy. Iff registers are used for passing then it would have to
be %rdi and %rsi (not %rax)! So the high part of this struct (where the
bitfield lies) is not passed at all here. Per ABI this whole struct
should
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|middle-end |target
Keywords||ABI
Target
--- Comment #7 from rguenth at gcc dot gnu dot org 2005-11-21 14:35 ---
More reduced/simplified:
void abort(void);
struct S2495 {
int a;
struct{
int d;
int e:31;
} c;
};
struct S2495 x;
void foo(struct S2495 a) __attribute__((noinline));
void foo(struct S2495
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-21
14:36 ---
Subject: Re: [4.1/4.2 Regression] make[7]: rc: Command not found
Apparently the libada Makefile is not passing some variables to ada/Makefile
properly, so this patch might address the problem you are
--- Comment #9 from hubicka at ucw dot cz 2005-11-21 14:44 ---
Subject: Re: [4.1 regression] EON regressed seriously on x86-64
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-21 13:30
---
Fixed at least on the mainline for 4.2.0.
I am going to fix it on
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-21 14:55 ---
# 1
/Users/eschnett/Cvanilla/configs/einstein-orange-gcc-debug/bindings/Configuration/Thorns/time.h
1 3 4
Hmm, it is including the wrong time.h for some reason.
Could you add -v and provide the output, I am
--- Comment #7 from joel at gcc dot gnu dot org 2005-11-21 14:56 ---
(In reply to comment #6)
Shall we close this as WORKSFORME?
Looks like it.
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from charlet at adacore dot com 2005-11-21 14:59 ---
Subject: Re: [4.1/4.2 Regression] make[7]: rc: Command not found
I'm not sure either. I did notice that the build that had a problem
was using an old version of make (3.79.1). I removed this and now this
system
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-21 15:01 ---
We have in libstdc++:
#include time.h
So this is invalid. -I does:
-I dir
Add the directory dir to the list of directories to be searched
for header files. Directories named by -I are
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-21 15:02 ---
As I said this is invalid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from pluto at agmk dot net 2005-11-21 15:05 ---
gcc-3.3.6 produces better code:
test: movqw, %mm1
psllw $1, %mm1
movq%mm1, w
movqw, %mm1
movq%mm1, dw
ret
.comm dw,8,8
.comm w,8,8
can we
--- Comment #3 from msharov at hotmail dot com 2005-11-21 15:07 ---
By its very nature, demonstrating the problem requires a large example, so I am
unable to provide a sufficiently compact one to post here. You can, however,
download the project I'm having problems with from SourceForge
--- Comment #19 from pinskia at gcc dot gnu dot org 2005-11-21 15:09
---
(In reply to comment #18)
can we classify this as a code size regression?
No because 3.3.x was also wrong in the sense it did not emit an emms.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14552
--- Comment #37 from pedro dot lamarao at mndfck dot org 2005-11-21 15:11
---
Yes, please *heavily* comment.
If this is approved, someone could do the copy on the relevant branches, then
I'd send a patch with better comments and changelog to the gcc-patches list.
--
(972) uname -a
FreeBSD gadoid.ices.cmu.edu 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #0: Mon Feb 23
20:45:55 GMT 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
i386
(973) cat a.c
#include stdlib.h
#include stdio.h
int main(int argc,char *argv[])
{
float n = 40;
int i;
for (i = 0;i
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-21 15:16 ---
This code should have been rejected as it is for 3.4.0 and above.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-21 15:16 ---
Note the error is:
t.c:17: error: conflicting types for foo
t.c:10: error: previous implicit declaration of foo was here
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24971
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-21 15:16
---
(In reply to comment #11)
Could somebody with an Intel 64bit system try to bootstrap this?
I don't have an Intel 64bit machine, but I can do a bootstrap on a x86_64
machine with this patch.
--
(972) uname -a
FreeBSD gadoid.ices.cmu.edu 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #0: Mon Feb 23
20:45:55 GMT 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
i386
(973) cat a.c
#include stdlib.h
#include stdio.h
int main(int argc,char *argv[])
{
float n = 40;
int i;
for (i = 0;i
(972) uname -a
FreeBSD gadoid.ices.cmu.edu 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #0: Mon Feb 23
20:45:55 GMT 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
i386
(973) cat a.c
#include stdlib.h
#include stdio.h
int main(int argc,char *argv[])
{
float n = 40;
int i;
for (i = 0;i
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-21 15:18 ---
*** This bug has been marked as a duplicate of 24971 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-21 15:18 ---
*** Bug 24972 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24971
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-21 15:18 ---
*** This bug has been marked as a duplicate of 24971 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-21 15:18 ---
*** Bug 24973 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24971
--- Comment #4 from rearnsha at gcc dot gnu dot org 2005-11-21 15:19
---
It seems to me that the problem here is that a 'warning' is too strong here,
particularly with -Werror. We really need a diagnostic that is non-fatal to
the compilation, since there's nothing really wrong with
--- Comment #38 from pcarlini at suse dot de 2005-11-21 15:22 ---
(In reply to comment #37)
Yes, please *heavily* comment.
If this is approved, someone could do the copy on the relevant branches, then
I'd send a patch with better comments and changelog to the gcc-patches list.
--- Comment #5 from hansen at cmu dot edu 2005-11-21 15:28 ---
(In reply to comment #2)
Note the error is:
t.c:17: error: conflicting types for foo
t.c:10: error: previous implicit declaration of foo was here
I only get warnings in 3.3.0. Even with warnings, I still do not
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-21 15:29 ---
3.2.3 also gets this wrong the same way.
The callee side says the struct comes on the stack.
The caller side says the struct goes in via %rdi.
Which one is correct?
--
pinskia at gcc dot gnu dot org changed:
--- Comment #3 from machata at post dot cz 2005-11-21 15:31 ---
Created an attachment (id=10311)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10311action=view)
Allow comma only on second and further passes of declarator processing loop.
The patch addresses the problem by eating
--- Comment #5 from msharov at hotmail dot com 2005-11-21 15:34 ---
I would disagree. If the compiler ends up creating a function call where I
expect a simple movl, that _is_ something I want to hear about as a warning. I
have some code that uses inlines in really tight loops and having
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-21 15:35 ---
Here is the rtl which is produced by expanding foo(x):
(insn 15 13 16 (set (reg/f:DI 63)
(symbol_ref:DI (x) var_decl 0x2b15eb00 x)) -1 (nil)
(nil))
(insn 16 15 17 (set (reg:DI 62)
We currently miscompile DLV with -fstrict-aliasing, and the only aliasing
issues
that are visible are inside libstdc++:
/usr/include/c++/4.1.0/bits/basic_string.h:180: warning: dereferencing
type-punned pointer will break strict-aliasing rules
/usr/include/c++/4.1.0/bits/stl_set.h:348: warning:
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-21 15:44 ---
Created an attachment (id=10312)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10312action=view)
patch to enable aliasing warnings for C++
Apply to see the warnings (even during a libstdc++ build).
--
--- Comment #6 from rearnsha at gcc dot gnu dot org 2005-11-21 15:49
---
Subject: Re: -Os should maximize inlining --param
values.
I didn't say the compiler shouldn't say anything, I said it shouldn't be
fatal. Regardless of whether or not you think the limits are too low,
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-21 15:51 ---
(In reply to comment #1)
Created an attachment (id=10312)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10312action=view) [edit]
patch to enable aliasing warnings for C++
Note I think this patch is slightly
--- Comment #14 from pault at gcc dot gnu dot org 2005-11-21 15:53 ---
I have become more than a little bit concerned that this PR is a wild goose
chase.
Applying a similar patch to Erik's, I can persuade some bits of code to do
something. Furthermore, they are even the same things
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-21 15:56 ---
This is a dup of bug 19253 which is fixed in 3.4.5, and 4.0.3. That might be
why you did not find the bug.
*** This bug has been marked as a duplicate of 19253 ***
--
pinskia at gcc dot gnu dot org changed:
--- Comment #17 from pinskia at gcc dot gnu dot org 2005-11-21 15:56
---
*** Bug 24967 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from msharov at hotmail dot com 2005-11-21 16:01 ---
(In reply to comment #6)
This is not something that should cause -Werror to refuse compilation.
Well, according to the manpage, -Werror treats _all_ warnings as fatal, no
matter what they are about. Since -Winline is
--- Comment #5 from jb at gcc dot gnu dot org 2005-11-21 16:01 ---
Just as a general note, the deadline for dwarf3 comments is Dec 1, 2005. So if
anyone with some clue about how to improve support for debugging fortran has
some good suggestions that would require changes in the debug
--- Comment #3 from chris at bubblescope dot net 2005-11-21 16:03 ---
While it does look like there might be an error in this warning code, I also
have a feeling we are doing something bad here. I looked at the examples in
stl_set.h and we are doing reference casting from a
--- Comment #4 from pcarlini at suse dot de 2005-11-21 16:05 ---
Thanks. I'm looking into the issue. The part involving set seems to me much
more
critical and hopefully solvable without breaking the ABI, because we are not
exporting anything from the library involving set/multiset. I
--- Comment #6 from pault at gcc dot gnu dot org 2005-11-21 16:06 ---
Subject: Bug 24223
Author: pault
Date: Mon Nov 21 16:05:58 2005
New Revision: 107310
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107310
Log:
2005-11-21 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #3 from pault at gcc dot gnu dot org 2005-11-21 16:06 ---
Subject: Bug 24705
Author: pault
Date: Mon Nov 21 16:05:58 2005
New Revision: 107310
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107310
Log:
2005-11-21 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-21 16:06 ---
(In reply to comment #7)
I'm pretty sure that if you run a poll of all the C++
programmers, they'll tell you that they expect the former to always be inlined
in an optimized build, while the latter ought to depend
--- Comment #13 from krebbel at gcc dot gnu dot org 2005-11-21 16:07
---
I don't have an Intel 64bit machine, but I can do a bootstrap on a x86_64
machine with this patch.
Ups. That's what I was trying to suggest - an unusual typo isn't it? ;-)
Thanks for taking care of this!
--
--- Comment #1 from rsandifo at gcc dot gnu dot org 2005-11-21 16:09
---
Confirmed. Here's a dejagnu-style testcase:
// PR c++/20416. We correctly constructed the temporary S in foo(),
// but incorrectly destroyed it every time foo() was called.
// { dg-do run }
extern C void abort
--- Comment #5 from pcarlini at suse dot de 2005-11-21 16:09 ---
One more bit of info (meant for Chris too): I think the cast has been added
when
set was changed to have both iterator and const_iterator as const iterator
types.
Since we are not exporting anything, I suppose we can fix
--- Comment #2 from rsandifo at gcc dot gnu dot org 2005-11-21 16:09
---
BTW, this is 12.2/5.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20416
--- Comment #3 from dje at gcc dot gnu dot org 2005-11-21 16:12 ---
Subject: Bug 24953
Author: dje
Date: Mon Nov 21 16:12:32 2005
New Revision: 107311
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107311
Log:
PR target/24953
* config/rs6000/predicates.md
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-11-21 16:19
---
(In reply to comment #13)
Ups. That's what I was trying to suggest - an unusual typo isn't it? ;-)
Thanks for taking care of this!
Actually I was wrong in saying that only complex modes can show up here. It
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-11-21 16:22
---
(In reply to comment #14)
The testcase to get that construct is:
Compiling with -mpowerpc64 to get the mixed mode. I would not doubt that the
arm failure is a similar issue but not with complex types.
--
--- Comment #9 from msharov at hotmail dot com 2005-11-21 16:25 ---
(In reply to comment #8)
Depends on which C++ developers and if they have really thought about all
their
uses of inline (most have not even though they say they want functions
declared
as inline to be inlined)?
--- Comment #6 from pcarlini at suse dot de 2005-11-21 16:28 ---
Actually, to be 100% safe wrt binary compatibility (addresses, etc.) we can
also overload for _Rb_tree::const_iterator the involved _Rb_tree functions,
I'm preparing a patch.
--
--- Comment #4 from bonzini at gcc dot gnu dot org 2005-11-21 16:38 ---
Subject: Bug 24951
Author: bonzini
Date: Mon Nov 21 16:38:13 2005
New Revision: 107312
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107312
Log:
2005-11-21 Paolo Bonzini [EMAIL PROTECTED]
PR
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-21 16:50
---
Fixed in 4.1.0 and above for now.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from bonzini at gcc dot gnu dot org 2005-11-21 17:04 ---
Subject: Bug 24951
Author: bonzini
Date: Mon Nov 21 17:04:11 2005
New Revision: 107313
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107313
Log:
2005-11-21 Paolo Bonzini [EMAIL PROTECTED]
PR
--- Comment #6 from bonzini at gcc dot gnu dot org 2005-11-21 17:05 ---
Andreas, can you confirm it is fixed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24951
This testcase:
int a = 0xe+100;
Produces a diagnostic message that would surprise
most users:
foo.c:1:9: error: invalid suffix +100 on integer constant
I'm not sure what the standard says about ambiguity
between the hex float notation and the regular + operator,
but many users are going to
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-21 17:28 ---
(In reply to comment #0)
but many users are going to think of this behavior as
a parser bug.
This is more of a tokenizer error rather than a parser error.
Anyways 2.95.3 gives:
t.c:1: missing white space after
1 - 100 of 184 matches
Mail list logo
