http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35445
Simon Martin changed:
What|Removed |Added
CC||simartin at gcc dot gnu.org
--- Comment #5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787
--- Comment #13 from Jerry DeLisle 2011-05-02
03:29:49 UTC ---
Fixed on trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48840
Hans-Peter Nilsson changed:
What|Removed |Added
Target||sparc64-unknown-linux-gnu
--- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48841
--- Comment #1 from Hin-Tak Leung
2011-05-01 22:46:34 UTC ---
attachment posted as:
http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg00074.html
after prepending with some notes.
Mentioned the issue but forgot to mention the actual bug number, bu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48841
Summary: [regression] lot more libgomp testsuite failures
compared to 4.4.5
Product: gcc
Version: 4.4.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47726
Ruben Van Boxem changed:
What|Removed |Added
CC||vanboxem.ruben at gmail dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40894
--- Comment #10 from Hin-Tak Leung
2011-05-01 22:30:55 UTC ---
Could this be some kind of text<->num conversion bug? I can't help but thinking
0x31 is '1' in ascii character, which is 0x01 in value.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40894
Hin-Tak Leung changed:
What|Removed |Added
Known to fail||4.4.6
--- Comment #9 from Hin-Tak Leung
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46967
--- Comment #6 from Hin-Tak Leung
2011-05-01 22:24:08 UTC ---
Filed Bug 48841 for the alphaev68 libgomp failure and attached my test summary,
in case somebody wants to compare to hppa 4.4.6.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46967
--- Comment #5 from Hin-Tak Leung
2011-05-01 22:02:03 UTC ---
(In reply to comment #4)
> Regarding comment #3, look at the libgomp test log file to see why the
> tests are failing on alphaev68-dec-osf5.1a. I'm certain the problem
> is different
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48840
Hans-Peter Nilsson changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48840
Summary: [4.4/4.7 Regression] ICE, gcc_assert (old_frame_size
== get_frame_size ()) maybe fp/vis-related
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Keywords: ice-on-val
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46967
John David Anglin changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48837
Steven Bosscher changed:
What|Removed |Added
CC||rakdver at kam dot
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48837
--- Comment #6 from Steven Bosscher 2011-05-01
19:56:37 UTC ---
In the tail recursion optimization:
Breakpoint 3, gimple_call_set_tail (s=0x77ed3680, tail_p=1 '\001') at
../../trunk/gcc/gimple.h:2241
2241 GIMPLE_CHECK (s, GIMPLE_CALL);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48837
--- Comment #5 from Steven Bosscher 2011-05-01
19:24:06 UTC ---
Function foo from .143.expand dump:
;; Function int foo(int, int) (_Z3fooii)
int foo(int, int) (int a, int b)
{
int acc_tmp.13;
int add_acc.12;
int D.2091;
int D.2085;
i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46967
Hin-Tak Leung changed:
What|Removed |Added
CC||htl10 at users dot
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48837
Steven Bosscher changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47509
Thibault North changed:
What|Removed |Added
CC||tnorth at fedoraproject dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261
--- Comment #7 from Thibault North 2011-05-01
17:27:20 UTC ---
It works for me, thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261
--- Comment #5 from Thibault North 2011-05-01
17:24:57 UTC ---
Created attachment 24158
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24158
Attachment #24157 fixed to patch the right file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261
--- Comment #6 from Thibault North 2011-05-01
17:25:52 UTC ---
(I seems that the file gcc/defaults.h is the one which must be patched by the
second part of your patch)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48837
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48839
Summary: #error should terminate compilation - similar to
missing #include
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261
--- Comment #4 from Iouri Kharon 2011-05-01
13:29:35 UTC ---
Created attachment 24157
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24157
CHAR16 and CHAR32 in avr with -mint8
This patch correct bug 46261 in gcc-4.5.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787
--- Comment #11 from Jerry DeLisle 2011-05-01
12:32:20 UTC ---
Author: jvdelisle
Date: Sun May 1 12:32:18 2011
New Revision: 173231
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173231
Log:
2011-05-01 Jerry DeLisle
PR libgfortra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48830
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787
--- Comment #12 from Jerry DeLisle 2011-05-01
12:37:07 UTC ---
Author: jvdelisle
Date: Sun May 1 12:37:05 2011
New Revision: 173233
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173233
Log:
2011-05-01 Jerry DeLisle
PR libgfortra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48830
--- Comment #9 from joseph at codesourcery dot com 2011-05-01 11:26:02 UTC ---
It's probably a good idea to test patches to subreg_get_info on an e500
target such as powerpc-eabispe. I don't *think* e500 is doing anything
that would be affected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48830
Hans-Peter Nilsson changed:
What|Removed |Added
Status|ASSIGNED|NEW
--- Comment #8 from Hans-Peter N
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40947
--- Comment #11 from Hin-Tak Leung
2011-05-01 10:14:49 UTC ---
This really looks like a libtool/automake/autoconf problem, and it seems that
libjava has its own libtool bundle?
Anyway, upgrading the system libtool to 2.4 does not improve.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48795
--- Comment #3 from Nicolas Le Cam 2011-05-01
10:11:47 UTC ---
(In reply to comment #2)
> "r1->data[1] = prm2" goes above "char data[1]" bounds. How it's a false
> positive?
Because the structure is a kind of flexible array (code has to follow C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48830
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835
--- Comment #6 from Andreas Schwab 2011-05-01 07:54:16
UTC ---
That's not a problem because all pointer values are also returned in %d0 for
compatibility.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48837
--- Comment #1 from Dmitry Gorbachev
2011-05-01 05:52:09 UTC ---
Simpler testcase:
=== 8< ===
__attribute__((noinline))
int baz(void)
{
return 1;
}
inline const int& bar(const int& a, const int&
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48795
--- Comment #2 from Dmitry Gorbachev
2011-05-01 06:33:06 UTC ---
"r1->data[1] = prm2" goes above "char data[1]" bounds. How it's a false
positive?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48837
--- Comment #2 from e-maxx 2011-05-01 06:13:59 UTC ---
It affects even 4.4.3.
37 matches
Mail list logo
