Test code:
! checking gcc/4.4.1 and gcc/4.4.2 for __x86_64__ defined
#ifndef __x86_64__
print *, '__x86_64__ not defined'
#endif
print *, 'End of Test'
end
Output for 4.4.2 and 4.4.1:
> aprun -n 1 ./x
__x86_64__ not defined
End of Test
Application 2193686 resources: utime 0, stime 0
This code shows that the definitions for omp_integer_kind and omp_logical_kind
are missing from the omp_lib.h include file. If the module is used instead,
there is no error.
! derived from OpenMP test omp3f/F03_3_2_11_1a.f90
program F03_3_2_11_1a
! use omp_lib
implicit none
include 'o
--- Comment #4 from reichelt at gcc dot gnu dot org 2009-11-14 03:31
---
Fixed.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONF
Looking at msmpeg4.s from PR 41567, build with -O2 -fPIC, we see
.LC2:
data8 mv_tables#+72
...
addl r14 = @gprel(.LC2), gp
We should not have spilled that address to the constant pool.
Add -mno-sdata and it gets worse -- LC2 moves from .sdata to
the .data.rel.ro section but we
--- Comment #14 from rth at gcc dot gnu dot org 2009-11-14 02:22 ---
This is a linker bug. Recompiling without -g, so as to get error messages
without the unhelpful symbolic interpretation, I can reproduce
msmpeg4.c:(.text.unlikely+0xbe2): relocation truncated to fit: GPREL22 against
`
--- Comment #3 from paolo dot carlini at oracle dot com 2009-11-14 01:58
---
Funny, and I agree the compiler should behave more gracefully, but this code is
invalid per 17.4.3.1.2: names containing a double underscore are reserved.
--
paolo dot carlini at oracle dot com changed:
--- Comment #2 from d dot g dot gorbachev at gmail dot com 2009-11-14
01:31 ---
Created an attachment (id=19015)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19015&action=view)
The bug.cc file
Sorry, forgot it. :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42038
--- Comment #1 from paolo dot carlini at oracle dot com 2009-11-14 00:15
---
And bug.cc is...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
`g++ bug.cc' causes this error:
bug.cc: In function 'void f()':
bug.cc:5:20: error: '__cxa_begin_catch' cannot be used as a function
bug.cc:5:20: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in useless_type_conversion_p, at tree-ssa.c:1221
--
--- Comment #2 from d dot g dot gorbachev at gmail dot com 2009-11-13
23:53 ---
Created an attachment (id=19014)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19014&action=view)
Backtrace
gcc version 4.5.0 20091112 (experimental)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2009-11-13
23:52 ---
Created an attachment (id=19013)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19013&action=view)
Testcase
gcc -flto -fuse-linker-plugin chew.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4203
lto1: internal compiler error: vector VEC(ld_plugin_symbol_resolution_t,heap)
grow domain error, in lto_resolution_read at lto/lto.c:313
--
Summary: "grow domain error" in lto1
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
--- Comment #8 from jason at redhat dot com 2009-11-13 23:18 ---
Subject: Re: libstdc++ seems to miss std::basic_string, std::allocator >::basic_string(char*,
char*, std::allocator const&)
On 11/13/2009 04:16 PM, hubicka at ucw dot cz wrote:
> I am confused why I get link error given
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-11-13 23:12 ---
I think this is related to PR 7221.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-11-13 23:11 ---
I think this is the same as bug 7221.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42011
--- Comment #5 from longb at cray dot com 2009-11-13 22:19 ---
I tried 4.4.2 and do not any longer see the segfault on the Cray XT system. I
suspect this was fixed by addressing the problem noted in Comment #3.
The original problem of not issuing the error message at compile time rema
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-11-13 21:59 ---
*** Bug 42036 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42033
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-13 21:59 ---
*** This bug has been marked as a duplicate of 42033 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-11-13 21:58 ---
*** Bug 42035 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42033
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-13 21:58 ---
*** This bug has been marked as a duplicate of 42033 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from hubicka at ucw dot cz 2009-11-13 21:16 ---
Subject: Re: libstdc++ seems to miss std::basic_string, std::allocator >::basic_string(char*,
char*, std::allocator const&)
> I see. Seems a compiler problem indeed, because, as Jason mentioned, the
> template is explicitly
--- Comment #6 from jamborm at gcc dot gnu dot org 2009-11-13 21:13 ---
Created an attachment (id=19012)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19012&action=view)
Proposed fix.
Proposed fix I am currently bootstrapping.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42
--- Comment #4 from paolo dot carlini at oracle dot com 2009-11-13 21:10
---
I see. Seems a compiler problem indeed, because, as Jason mentioned, the
template is explicitly instantiated in string-inst.cc and marked to be exported
in the linker script for the *.so. I have no idea what li
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-13 21:07 ---
*** Bug 42034 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-13 21:07 ---
*** This bug has been marked as a duplicate of 29234 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from sc09q4 at bullseye dot com 2009-11-13 21:04 ---
Let's look at these tokens "T()(int())" in detail.
(1) Yes "T()" looks like a function declarator:
T()(int())
111
(2) Then follows something in parenthesis, which looks a lot like C++03
direct-declarator rule
--- Comment #3 from hubicka at ucw dot cz 2009-11-13 21:01 ---
Subject: Re: libstdc++ seems to miss std::basic_string, std::allocator >::basic_string(char*,
char*, std::allocator const&)
This fails with --static only:
j...@gcc17:~/gcc-install/lib64$ nm -C libstdc++.so | less
j...@gcc1
Hi,
compiling tramp3d with -fwhole-program leads to:
/home/jh/gcc-install/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib64/libstdc++.a(sstream-inst.o):
In function `std::basic_stringbuf,
std::allocator >::str() const':
/home/jh/trunk/build5/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstr
Hi,
compiling tramp3d with -fwhole-program leads to:
/home/jh/gcc-install/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib64/libstdc++.a(sstream-inst.o):
In function `std::basic_stringbuf,
std::allocator >::str() const':
/home/jh/trunk/build5/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstr
--- Comment #6 from paolo dot carlini at oracle dot com 2009-11-13 20:51
---
Note that, as far as I have been told by Richard, the warning itself doesn't
point to an actual miscompilation in 4.4, because (PRE, etc.) aren't strong
enough. Thus, first people should double check that, and
--- Comment #10 from dominiq at lps dot ens dot fr 2009-11-13 20:43 ---
> So you can narrow it down to between revision 152380 and 152615.
My bracket is 152431 (no failures) and 152615 (failures).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41988
--- Comment #9 from hjl dot tools at gmail dot com 2009-11-13 20:38 ---
(In reply to comment #7)
> Well I know it appeared between revision 152380 and 153960. I don't have a
> narrower revision right now though.
>
Please read
Since at least revision 152615, I see the following failur
--- Comment #2 from paolo dot carlini at oracle dot com 2009-11-13 20:37
---
It's normally exported from the *.so, just grep it:
000a90d0 W std::basic_string,
std::allocator >::basic_string(char*, char*, std::allocator
const&)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-11-13 20:35 ---
The only other change that might have caused it as far as I can tell is the IFC
changes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41988
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-11-13 20:31 ---
Well I know it appeared between revision 152380 and 153960. I don't have a
narrower revision right now though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41988
--- Comment #6 from hjl dot tools at gmail dot com 2009-11-13 20:22 ---
(In reply to comment #4)
> (In reply to comment #3)
> > Is this a regression or a new test? They are OK on Linux.
> >
> > BTW, stack alignment was checked in a long time ago.
>
> The tests are old, they are from 2
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-13 20:21 ---
I don't think this is a bug. There is an ambiguous in the syntax in figuring
out if T() (int()) is a function declaration or a calling the operator() on a
newly created T. The C++ standard resolves it as being a fu
The program below demonstrates an incorrect error on an expression involving
operator(). The error incorrectly reported is "error: 'type name' declared as
function returning a function".
#include
struct T {
int operator()(int) const { printf("hello\n"); return 1; }
};
int main()
{
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #1 from jason at gcc dot gnu dot org 2009-11-13 20:08 ---
libstdc++ does define that function, in string-inst.cc. And it shouldn't be
defined anywhere else. I don't know what would be causing that error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42033
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-11-13 20:02 ---
There are definitely a lot of casts like
static_cast<_Link_type>(_M_node)
in stl_list.h. If _M_node is ever not a rb_tree_node but only a
rb_tree_node_base
(which probably is the case again for the head of the t
--- Comment #3 from michael dot a dot richmond at nasa dot gov 2009-11-13
19:56 ---
The error was caused by a full disk. I apologize for wasting your time.
--
michael dot a dot richmond at nasa dot gov changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-11-13 19:54 ---
It may be related to PR41316, I suspected that the library might contain
similar patterns in other containers besides forward_list.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42032
--- Comment #8 from uros at gcc dot gnu dot org 2009-11-13 19:52 ---
Subject: Bug 41900
Author: uros
Date: Fri Nov 13 19:51:52 2009
New Revision: 154171
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154171
Log:
2009-11-13 Uros Bizjak
PR target/41900
(*call_p
--- Comment #3 from evan at chromium dot org 2009-11-13 19:49 ---
I brought this up on the Google-internal C list. They reduced it further:
$ cat main.cc
#include
int main(void)
{
typedef std::map MyMap2;
MyMap2 map2_;
MyMap2::iterator map_iter2 = map2_.find(5);
return *m
--- Comment #5 from jamborm at gcc dot gnu dot org 2009-11-13 19:34 ---
Yep, this is definitely mine. Even though I have a fix for the above
testcase, it unfortunately does not work for my all-time favorite
one-filed structures, e.g.:
typedef struct
{
void *p;
} Ptr;
struct A
{
i
--- Comment #2 from craig dot schlenter at gmail dot com 2009-11-13 19:34
---
(In reply to comment #1)
> Might be related to PR 39390.
Would it be possible for someone to test the code from the description section
with trunk please .. if error messages were removed, the problem should
--- Comment #2 from michael dot a dot richmond at nasa dot gov 2009-11-13
19:34 ---
The version of binutils provided by Debian is not the latest:
mrich...@msc545ux:~$ ld --version
GNU ld (GNU Binutils for Debian) 2.18.0.20080103
Copyright 2007 Free Software Foundation, Inc.
This progra
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-13 19:25 ---
Might be related to PR 39390.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42032
Hi,
compiling tramp3d with -fwhole-program leads to:
/home/jh/gcc-install/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib64/libstdc++.a(sstream-inst.o):
In function `std::basic_stringbuf,
std::allocator >::str() const':
/home/jh/trunk/build5/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstr
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-13 19:24 ---
Which binutils version do you have installed? You might want to try a newer
version of binutils since that includes ld.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
I'm seeing the following error:
In function int main():
cc1plus: warning: dereferencing pointer does break
strict-aliasing
rules
/usr/lib/gcc/i386-redhat-linux/4.4.0/../../../../include/c++/4.4.0/bits/stl_tree.h:184:
note: initialized from here
I'm unsure of these are legitimate warnings i.e
--- Comment #7 from uros at gcc dot gnu dot org 2009-11-13 19:13 ---
Subject: Bug 41900
Author: uros
Date: Fri Nov 13 19:13:16 2009
New Revision: 154169
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154169
Log:
2009-11-13 Uros Bizjak
PR target/41900
(*call_p
--- Comment #15 from jason at gcc dot gnu dot org 2009-11-13 18:48 ---
Fixed for 4.5.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #8 from jason at gcc dot gnu dot org 2009-11-13 18:48 ---
Fixed for 4.5.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
--- Comment #11 from jason at gcc dot gnu dot org 2009-11-13 18:47 ---
Fixed for 4.5.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|REOP
--- Comment #7 from jason at gcc dot gnu dot org 2009-11-13 18:47 ---
Subject: Bug 34274
Author: jason
Date: Fri Nov 13 18:46:47 2009
New Revision: 154164
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154164
Log:
PR c++/27425
PR c++/34274
* pt.c (expand_
--- Comment #10 from jason at gcc dot gnu dot org 2009-11-13 18:47 ---
Subject: Bug 27425
Author: jason
Date: Fri Nov 13 18:46:47 2009
New Revision: 154164
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154164
Log:
PR c++/27425
PR c++/34274
* pt.c (expand
--- Comment #14 from jason at gcc dot gnu dot org 2009-11-13 18:46 ---
Subject: Bug 29363
Author: jason
Date: Fri Nov 13 18:46:39 2009
New Revision: 154163
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154163
Log:
PR c++/29363
* decl.c (create_implicit_typedef):
--- Comment #3 from jakub at gcc dot gnu dot org 2009-11-13 18:42 ---
Subject: Bug 42029
Author: jakub
Date: Fri Nov 13 18:42:32 2009
New Revision: 154162
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154162
Log:
PR middle-end/42029
* gimplify.c (gimplify_omp_at
--- Comment #2 from jakub at gcc dot gnu dot org 2009-11-13 18:38 ---
Subject: Bug 42029
Author: jakub
Date: Fri Nov 13 18:38:36 2009
New Revision: 154161
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154161
Log:
PR middle-end/42029
* gimplify.c (gimplify_omp_at
--- Comment #6 from uros at gcc dot gnu dot org 2009-11-13 18:33 ---
Subject: Bug 41900
Author: uros
Date: Fri Nov 13 18:33:37 2009
New Revision: 154160
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154160
Log:
2009-11-13 Uros Bizjak
PR target/41900
(*call_p
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #1 from ro at gcc dot gnu dot org 2009-11-13 18:08 ---
Richard, any preferences on how to fix this? The approach outlined in the
report
doesn't work since intl/loadmsgcat.c uses this definition of PRId64
# define PRId64 (sizeof (long) == 8 ? "ld" : "lld")
which doesn't mix
--- Comment #18 from jason at gcc dot gnu dot org 2009-11-13 18:03 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #17 from jason at gcc dot gnu dot org 2009-11-13 18:03 ---
Subject: Bug 21008
Author: jason
Date: Fri Nov 13 18:03:31 2009
New Revision: 154158
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154158
Log:
PR c++/21008, DR 515
* semantics.c (finish_non_s
--- Comment #19 from jason at gcc dot gnu dot org 2009-11-13 18:02 ---
Fixed for 4.5.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #18 from jason at gcc dot gnu dot org 2009-11-13 17:59 ---
Subject: Bug 26965
Author: jason
Date: Fri Nov 13 17:59:26 2009
New Revision: 154157
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154157
Log:
PR debug/26965
* dwarf2out.c (gen_variable_die):
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2009-11-13 17:55
---
Investigating.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jason at gcc dot gnu dot org 2009-11-13 17:52 ---
Oops.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
CC||lmillward at gcc dot gnu dot
|
--- Comment #8 from paolo dot carlini at oracle dot com 2009-11-13 17:45
---
Jason, see Comment #3, it still ICEs for me...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27425
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2009-11-13 17:37
---
> This is an interesting suggestion. However, the results in doing
> this are mixed. It fixes the current testcase on hpux but not linux.
Yes, you additionally need this for Linux:
2009-11-12 Eric Botcazou
--- Comment #1 from ramana at gcc dot gnu dot org 2009-11-13 17:32 ---
(In reply to comment #0)
> In gcc4.2.1 targeting ARM processors, pure leaf functions were able to make
> use
> of r14 / lr (the link register). However, in gcc4.3.2 and gcc4.4.1 (and
> presumably since then, since I
--- Comment #1 from ramana at gcc dot gnu dot org 2009-11-13 17:23 ---
Created an attachment (id=19011)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19011&action=view)
Reduced testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42031
The patch here http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00515.html breaks
CSibe builds at Os for thumb2. I've attached a reduced testcase with this bug
report. This was reduced from linux-2.4.23/fs/nfs/read.c .
Building with -fno-schedule-insns works.
Command Line options used -mcpu=cortex-a
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-11-13 16:57 ---
One should note on darwin we have:
/* On Darwin, the stack is 128-bit aligned at the point of every call.
Failure to ensure this will lead to a crash in the system libraries
or dynamic loader. */
#undef STACK_
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-11-13 16:56 ---
(In reply to comment #3)
> Is this a regression or a new test? They are OK on Linux.
>
> BTW, stack alignment was checked in a long time ago.
The tests are old, they are from 2003 :).
The patch which I was talking
--- Comment #7 from jason at gcc dot gnu dot org 2009-11-13 16:56 ---
No longer ICEs in 4.3+.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2009-11-13 16:45 ---
(In reply to comment #1)
> This was more likely caused by HJL's stack alignment patches based on the
> context of the ICE.
>
> I had also saw this the last time I ran the testsuite on x86-darwin.
>
Is this a regre
--- Comment #4 from jamborm at gcc dot gnu dot org 2009-11-13 16:36 ---
This seems to be IPA SRA and thus mine.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #10 from jason at gcc dot gnu dot org 2009-11-13 16:16 ---
Bumping down the priority since it doesn't ICE on 4.4+ and it's unclear whether
or not the code should be valid.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #16 from jason at gcc dot gnu dot org 2009-11-13 15:37 ---
Subject: Bug 21008
Author: jason
Date: Fri Nov 13 15:37:29 2009
New Revision: 154153
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154153
Log:
PR c++/21008, DR 515
* semantics.c (finish_non_s
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #2 from ubizjak at gmail dot com 2009-11-13 15:10 ---
Adding CC.
--
ubizjak at gmail dot com changed:
What|Removed |Added
CC|
--- Comment #15 from mark at codesourcery dot com 2009-11-13 15:07 ---
Subject: Re: [4.3/4.4/4.5 Regression] typedef doesn't fully
expose base class type
jason at gcc dot gnu dot org wrote:
> I'm assuming Mark isn't actually working on this bug.
Sad, but true.
--
http://gcc.gnu.
When I attempt to compile the 11/12/09 snapshot of gcc 4.5 on an HP-PA
workstation under Debian Linux 5.0 I get the message:
/home/mrichmon/gcc-4.5-20091112/g95/./prev-gcc/xgcc
-B/home/mrichmon/gcc-4.5-20091112/g95/./prev-gcc/
-B/home/mrichmon/irun/hppa1.1-unknown-linux-gnu/bin/
-B/home/mrichmon/i
--- Comment #17 from jason at gcc dot gnu dot org 2009-11-13 14:42 ---
.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from jason at gcc dot gnu dot org 2009-11-13 14:42 ---
Fixed for 4.5.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
--- Comment #16 from jason at gcc dot gnu dot org 2009-11-13 14:41 ---
Fixed for 4.5.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.
--- Comment #8 from jason at gcc dot gnu dot org 2009-11-13 14:41 ---
Subject: Bug 35075
Author: jason
Date: Fri Nov 13 14:40:32 2009
New Revision: 154151
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154151
Log:
PR c++/35075
* pt.c (convert_nontype_argument): G
--- Comment #15 from jason at gcc dot gnu dot org 2009-11-13 14:41 ---
Subject: Bug 21008
Author: jason
Date: Fri Nov 13 14:40:22 2009
New Revision: 154150
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154150
Log:
PR c++/21008, DR 515
* semantics.c (finish_non_s
--- Comment #15 from jason at gcc dot gnu dot org 2009-11-13 14:40 ---
Subject: Bug 11987
Author: jason
Date: Fri Nov 13 14:40:13 2009
New Revision: 154149
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154149
Log:
PR c++/11987
* parser.c (cp_parser_direct_declar
--- Comment #3 from abel at gcc dot gnu dot org 2009-11-13 14:33 ---
Subject: Bug 41697
Author: abel
Date: Fri Nov 13 14:32:52 2009
New Revision: 154148
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154148
Log:
PR rtl-optimization/41697
* sel-sched-ir.c (fallthr
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-11-13
14:26 ---
I tried the patch from comment 3 on x86_64-apple-darwin9.8.0 and the gcj
crashes still occur. I wonder if this change only makes the bug potentially go
latent on certain hardware for intel darwin. It is unc
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2009-11-13
14:20 ---
Subject: Re: FAIL: gnat.dg/null_pointer_deref1.adb execution test
> I see that it fails on HP-UX as well. That's probably because there is
> something missing in the fallback routines in config/pa, namely
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-13 13:52 ---
some DECL_GIMPLE_REG_P is missing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42029
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-11-13 13:49 ---
It looks like it is induction variable related.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-13 13:42 ---
I will have a look.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #2 from hubicka at ucw dot cz 2009-11-13 13:40 ---
Subject: Re: New: [4.5 regression] Revision 154128 caused many failures
These are frontend bugs caught by sanity check I accidentally comitted.
I posted objc fix and C++ part is in testing.
Honza
--
http://gcc.gnu.or
1 - 100 of 120 matches
Mail list logo