--- Comment #1 from deji_aking at yahoo dot ca 2006-12-28 07:26 ---
The pre-processed is too big to attach, I've put it on
ftp://czar.eas.yorku.ca/pub/datalist.cpp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30316
O.k sorry about the bad summary (I know almost nothing about c++). I had
installed 4.2.0 pre-release for my fortran needs and was trying to compile a
package (beast-0.7.1, from beast.gtk.org) on fedora rawhide and I'm getting
this ICE;
>>
if g++ -DHAVE_CONFIG_H -DBIRNET_LOG_DOMAIN='"signal"' -DPA
Using gcc-4.3-20061223 targeting i386-linux and options "-O9
-fomit-frame-pointer -fexpensive-optimizations -S", my test program to detect
unsigned integer overflow:
extern void abort(void);
unsigned foo(unsigned a, unsigned b) {
unsigned sum = a + b;
if (sum < a) abort(); /* check for ove
I was experimenting with some code to test for overflow (wrapping) in unsigned
multiplication in C. My test code:
typedef unsigned long size_t;
extern void *malloc(size_t), abort(void);
void *allocate(size_t num) {
const size_t size = 140;
size_t total = num * size;
if (total / size
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #4 from tromey at gcc dot gnu dot org 2006-12-28 04:49 ---
This is a bug against a very old release for code that no longer
exists. Is it ok to give up and close it as invalid?
The bug management page is not clear on when old bugs can be closed;
I think this one should be be
--- Comment #4 from tromey at gcc dot gnu dot org 2006-12-28 04:22 ---
FWIW what happens here is that 'foo;' is turned into
'-> >>;' by cpp; then the second error is emitted by the
C parser. You can easily see this by comparing the -E output
against the --syntax-only output.
The proble
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-28 03:05 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
gcc rejects following valid code.
static inline void bar(){}
struct S
{
signed int i: 32;
};
int main()
{
struct S x = {32};
sizeof(x.i+0);
return 0;
}
gcc version: 4.2 20061212
--
Summary: sizeof of expression including bit-field
Product: gcc
Version
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-28 01:44 ---
Hmm, I don't know this is really valid code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30311
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-28 01:42 ---
http://gcc.gnu.org/translation.html
http://www.iro.umontreal.ca/translation/
We cannot fix this at all. report it to the german translation maintainer for
GCC.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-12-28 01:42
---
Subject: Bug 30014
Author: jvdelisle
Date: Thu Dec 28 01:41:57 2006
New Revision: 120235
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120235
Log:
2006-12-27 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-12-28 01:40
---
Subject: Bug 30014
Author: jvdelisle
Date: Thu Dec 28 01:40:23 2006
New Revision: 120234
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120234
Log:
2006-12-27 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-12-28 01:39
---
Subject: Bug 30014
Author: jvdelisle
Date: Thu Dec 28 01:39:15 2006
New Revision: 120233
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120233
Log:
2006-12-27 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-12-28 01:39
---
I can reproduce the problem with the following code snippet:
=
virtual void foo();
=
"Fehler in der deutschen Übersetzung sind an
[EMAIL PROTECTED] zu melden."
This is pri
--- Comment #10 from tromey at gcc dot gnu dot org 2006-12-28 01:38 ---
Is this patch just waiting for someone to commit it?
The paperwork is all done?
If so please respond and I will check it in.
--
tromey at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from tromey at gcc dot gnu dot org 2006-12-28 01:34 ---
This seems reasonable enough to me, offhand.
I suppose and are translated
because they may be visible as part of error reporting,
but this doesn't seem super compelling to me.
I think the fix for this is a couple o
--- Comment #1 from tromey at gcc dot gnu dot org 2006-12-28 01:28 ---
Also 6.10.8.4 says that various other macros, like __DATE__,
shall not be the subject of #define or #undef. Currently we
warn in these cases but perhaps we ought to have a pedwarn instead.
I have a patch for the '#i
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-12-28 01:14
---
Reduced testcase, fails with -O or higher:
=
inline double bar(double x)
{
long double d;
__asm__ ("" : "=t" (d) : "0" (x));
return d;
}
double foo(double x)
{
if (
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-12-28 01:11 ---
Another Testcase (simplier):
#define f(x) ({ unsigned tmp=x; tmp; })
unsigned foo(unsigned x) {
return __builtin_constant_p(x) ? 0 : f(x);
}
--
pinskia at gcc dot gnu dot org changed:
W
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-12-28 01:10 ---
*** Bug 30312 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-28 01:10 ---
The patch I have for PR 30253 also fixes this issue.
*** This bug has been marked as a duplicate of 30253 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from tromey at gcc dot gnu dot org 2006-12-28 00:59 ---
The followup patch here:
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00868.html
.. looked reasonable to me (although the ChangeLog entry
is overly verbose). However I can't approve it.
--
tromey at gcc dot gnu
This is actually a bootstrap failure on i386-unknown-freebsd5.4, but with
some work I managed to destill this radically.
When invoking `${BUILDDIR}/gcc/xgcc -B${BUILDDIR}/gcc -O1 x.cc` on
#define f(x) ({ unsigned tmp=x; tmp; })
unsigned foo(unsigned x) {
return __builtin_constant_p(x
--- Comment #1 from hjl at lucon dot org 2006-12-28 00:11 ---
Created an attachment (id=12844)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12844&action=view)
A testcase
A testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30311
[EMAIL PROTECTED] build_base_o2.]$ /usr/gcc-4.3/bin/gcc foo.i -O2 -S
foo.c: In function Perl_pp_int:
foo.c:60: internal compiler error: in subreg_get_info, at rtlanal.c:3065
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instruc
--- Comment #6 from ian at gcc dot gnu dot org 2006-12-27 23:40 ---
Subject: Bug 26964
Author: ian
Date: Wed Dec 27 23:39:58 2006
New Revision: 120225
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120225
Log:
PR debug/26964
* dwarf2out.c (gen_type_die): Don't wr
--- Comment #5 from ian at airs dot com 2006-12-27 22:54 ---
Fixed on active branches.
--
ian at airs dot com changed:
What|Removed |Added
Status|NEW
--- Comment #4 from ian at gcc dot gnu dot org 2006-12-27 22:24 ---
Subject: Bug 26964
Author: ian
Date: Wed Dec 27 22:23:55 2006
New Revision: 120223
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120223
Log:
PR debug/26964
* dwarf2out.c (gen_type_die): Don't wr
--- Comment #3 from ian at gcc dot gnu dot org 2006-12-27 22:22 ---
Subject: Bug 26964
Author: ian
Date: Wed Dec 27 22:22:47 2006
New Revision: 120222
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120222
Log:
PR debug/26964
* dwarf2out.c (gen_type_die): Don't wr
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-27 22:14 ---
(In reply to comment #3)
> FWIW this doesn't entirely look like a bug to me.
> The code is reaching a gcc_unreachable() statement,
> so this is more along the lines of a properly
> functioning internal check.
But we
--- Comment #3 from tromey at gcc dot gnu dot org 2006-12-27 22:08 ---
FWIW this doesn't entirely look like a bug to me.
The code is reaching a gcc_unreachable() statement,
so this is more along the lines of a properly
functioning internal check.
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #2 from ian at gcc dot gnu dot org 2006-12-27 21:48 ---
Subject: Bug 26964
Author: ian
Date: Wed Dec 27 21:48:05 2006
New Revision: 120221
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120221
Log:
PR debug/26964
* dwarf2out.c (gen_type_die): Don't wr
--- Comment #8 from tromey at gcc dot gnu dot org 2006-12-27 21:43 ---
I looked at this a bit.
The basic problem resembles bug #14438 in a way.
The source code here has an unterminated "call" to a function-like
macro. cpp thinks all the subsequent #define directives are
in the expansio
--- Comment #5 from belyshev at depni dot sinp dot msu dot ru 2006-12-27
20:19 ---
(In reply to comment #4)
> The reduced testcase doesn't link for me btw:
sorry, forgot to mention: both tests require -lsigc-2.0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30252
--- Comment #2 from patchapp at dberlin dot org 2006-12-27 19:35 ---
Subject: Bug number PR30034
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/2006-12/msg01730.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-27 17:01 ---
(In reply to comment #1)
> Note this is actually wrong-code.
No, it is not.
In notneg, if x is -2147483647-1, it is obviously, we have an overflow as
-(-2147483647-1) is overflowed.
In negnot, if x is 2147483647, t
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-12-27 16:48 ---
This is folded to
;; Function notneg (notneg)
;; enabled by -tree-original
{
return x != -2147483648;
}
;; Function negnot (negnot)
;; enabled by -tree-original
{
return x != 2147483647;
}
via
/* C
--- Comment #3 from pault at gcc dot gnu dot org 2006-12-27 16:38 ---
I suppose that I had better accept it...
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-12-27 16:21
---
Just to mention it - you can use 'long double' to force 80bit spills.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30255
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-12-27 16:18 ---
The patch referenced only could have uncovered a latent problem. mem-ssa might
simply have hidden it again.
The reduced testcase doesn't link for me btw:
/tmp/ccGXFf9y.o: In function `A::bar()':
589.ii:(.text+0x2c
--- Comment #2 from pault at gcc dot gnu dot org 2006-12-27 13:46 ---
Subject: Bug 25135
Author: pault
Date: Wed Dec 27 13:46:47 2006
New Revision: 120218
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120218
Log:
2006-12-27 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #2 from pault at gcc dot gnu dot org 2006-12-27 13:46 ---
Subject: Bug 20896
Author: pault
Date: Wed Dec 27 13:46:47 2006
New Revision: 120218
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120218
Log:
2006-12-27 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
Since a few days the following code triggers an ICE with the latest SVN
version:
> cat bug.c
void* malloc(unsigned);
void f()
{
void* p = malloc(0);
}
> g++ -fipa-pta bug.c
bug.c: In function 'void f()':
bug.c:5: internal compiler error: Segmentation fault
Compilation with gcc works a
--- Comment #5 from tromey at gcc dot gnu dot org 2006-12-27 11:14 ---
The reason we did this is that, when we wrote libgcj, we wanted to
be able to control various abi-changing things via command-line
arguments. And, the best place to do much of the checking was in
the libgcj configur
45 matches
Mail list logo
