Preprocessing this:
#line 12312312312435
produces:
# 2936042099 ".../foo.c"
C99 specifies that the argument to #line shall be > 0 and < 2^31-1, and even if
it didn't, truncation like this should at least be warned about.
-Chris
--
Summary: #line range not verified
Produ
--- Comment #4 from sayle at gcc dot gnu dot org 2006-06-19 04:21 ---
Subject: Bug 27802
Author: sayle
Date: Mon Jun 19 04:21:22 2006
New Revision: 114766
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114766
Log:
PR middle-end/27802
* reg-stack.c (subst_stack_r
FAIL: PR18699 execution - source compiled test
FAIL: PR18699 execution - gij test
FAIL: PR18699 execution - bytecode->native test
FAIL: PR18699 execution - gij test
FAIL: PR18699 -findirect-dispatch execution - bytecode->native test
FAIL: PR18699 -O3 execution - source compiled test
FAIL: PR18699 e
--- Comment #4 from danglin at gcc dot gnu dot org 2006-06-19 03:11 ---
Fixed by patch.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #3 from danglin at gcc dot gnu dot org 2006-06-19 03:08 ---
Subject: Bug 27254
Author: danglin
Date: Mon Jun 19 03:07:54 2006
New Revision: 114765
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114765
Log:
PR libgomp/27254
* io/unit.c (get_internal_un
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2006-06-19
02:17 ---
Subject: Re: ACATS: c37215h on hppa-linux
> BTW, according to http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg00700.html
> cd5003e is failing on hppa-linux whereas it passes on x86 and x86_64 and I
> don'
--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2006-06-19
02:02 ---
Subject: Re: [4.2 Regression] FAIL: gcc.c-torture/execute/builtin-bitops-1.c
execution, -O3 -fomit-frame-pointeO
> could you please try to simplify the testcase, ideally to separate just the
> single mis
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot
|dot org
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot
|dot org
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot
|dot org
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot
|dot org
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-06-18 21:01
---
I am taking a shot at this.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pault at gcc dot gnu dot org 2006-06-18 19:43 ---
Harald,
The date at which you submitted this is an insult to my sensibilities; I hope
that you appreciate the progress that we have made elsewhere and forgive us
slowness in responding to this? That said, I have been
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.1.2
Known to work||4.2.0
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-06-18 17:36
---
Subject: Bug 26801
Author: fxcoudert
Date: Sun Jun 18 17:36:47 2006
New Revision: 114757
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114757
Log:
PR fortran/26801
* trans-intrinsic.c (g
--- Comment #1 from tbm at cyrius dot com 2006-06-18 17:16 ---
Created an attachment (id=11691)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11691&action=view)
testsuite logs
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28077
libmudflap.cth/pass39-frag.c (and I think pass37-frag.c) produce mudflap
violations on Alpha. In dmesg, you get messages like these:
pass39-frag.exe(7421): unaligned trap at 000120001ff8: b029001c2022000f 29
1
pass39-frag.exe(7552): unaligned trap at 000120001ff8: b029001c2022000f 29
1
--- Comment #6 from tbm at cyrius dot com 2006-06-18 17:04 ---
Frank, are you also going to apply this patch to the 4.0 and 4.1 branches?
--
tbm at cyrius dot com changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-18 16:35 ---
Breakpoint 6, assemble_zeros (size=7976) at ../../gcc/varasm.c:1526
6170 assemble_zeros (SYMBOL_REF_BLOCK_OFFSET (symbol) - offset);
(gdb) p debug_rtx(symbol)
(symbol_ref:DI ("tmp") [flags 0x82] )
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-06-18 10:58 ---
operand_equal_p (bD.1525.valD.1524, (long intD.2) bD.1525.valD.1524, 0)
is true. make_range preserved the cast to (long int) for a reason, though.
If we fix operand_equal_p, we no longer fold the test, but keep
--- Comment #2 from laurent at guerby dot net 2006-06-18 10:52 ---
This works on x86 and x86_64 as of 20060615, do you know when it started to
fail?
BTW, according to http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg00700.html
cd5003e is failing on hppa-linux whereas it passes on x86 an
--- Comment #28 from pcarlini at suse dot de 2006-06-18 10:13 ---
Correction, our testcases are already fine, zero_state does the job...
Anyway...
--
pcarlini at suse dot de changed:
What|Removed |Added
-
--- Comment #27 from pcarlini at suse dot de 2006-06-18 10:03 ---
(In reply to comment #26)
> Thiemo Seufer diagnosed this as a problem with the testcases: mbstate_t needs
> explictly initialising to all-bits-zero with memset. After doing this
>
> std::memset(&state, 0, sizeof(mbstat
--- Comment #26 from rleigh at debian dot org 2006-06-18 09:51 ---
Thiemo Seufer diagnosed this as a problem with the testcases: mbstate_t needs
explictly initialising to all-bits-zero with memset. After doing this
std::memset(&state, 0, sizeof(mbstate_t));
all the testcases work fo
--- Comment #25 from pcarlini at suse dot de 2006-06-18 09:35 ---
(In reply to comment #24)
> terminate called after throwing an instance of 'std::runtime_error'
> what(): locale::facet::_S_create_c_locale name not valid
This is the standard throw which happens when a named locale ca
26 matches
Mail list logo
