--- Comment #14 from bkoz at gcc dot gnu dot org 2009-12-17 08:18 ---
Created an attachment (id=19333)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19333&action=view)
part 2
diff after merge of part 1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21772
Attached testcase from linux kernel fails to compile with latest trunk rev
155302 on mips architecture.
options to pass -c -O1
$ mips-oe-linux-gcc y.c -c -O1
y.c: In function ptrace_setregs:
y.c:12917:1: internal compiler error: in sra_modify_expr, at tree-sra.c:2175
Please submit a full bug re
--- Comment #1 from raj dot khem at gmail dot com 2009-12-17 08:36 ---
Created an attachment (id=19334)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19334&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42398
--- Comment #3 from davek at gcc dot gnu dot org 2009-12-17 09:04 ---
This is starting to look like an LD bug. The function is there in the objects
fed into the final link:
$ x86_64-w64-mingw32-nm -C .libs/string-inst.o | grep reserve
t .text$_ZNSs7reserveEy
0
I am using an svn checkout of 4.5 trying to play with new c++0x features. I've
tried debugging this myself, but gcc is huge and this is my first foray into
it. I will list what I know.
My checkout information :
$ svn info
Path: .
URL: svn://gcc.gnu.org/svn/gcc/trunk
Repository Root: svn://gcc.g
--- Comment #8 from janus at gcc dot gnu dot org 2009-12-17 09:28 ---
Subject: Bug 42144
Author: janus
Date: Thu Dec 17 09:28:25 2009
New Revision: 155305
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155305
Log:
gcc/fortran/
2009-12-17 Janus Weil
PR fortran/42144
--- Comment #1 from knomenet at gmail dot com 2009-12-17 09:29 ---
Created an attachment (id=19335)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19335&action=view)
This is a file that should trigger the segfault.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42399
--- Comment #17 from nbenoit at tuxfamily dot org 2009-12-17 09:32 ---
(In reply to comment #16)
> Created an attachment (id=19332)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19332&action=view) [edit]
> Real fix
>
> Now, before I blow it again, would you be so kind to test this
--- Comment #18 from nbenoit at tuxfamily dot org 2009-12-17 09:34 ---
(In reply to comment #17)
> (In reply to comment #16)
> > Created an attachment (id=19332)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19332&action=view) [edit]
> > Real fix
> >
> > Now, before I blow it agai
--- Comment #15 from bkoz at gcc dot gnu dot org 2009-12-17 09:37 ---
Subject: Bug 21772
Author: bkoz
Date: Thu Dec 17 09:37:16 2009
New Revision: 155306
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155306
Log:
2009-12-16 Benjamin Kosnik
PR libstdc++/21772 part 2
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-12-17 09:43
---
Looks sensible to me, although maybe "resource_unavailable_try_again" is a
better error:
resource_unavailable_try_again the system lacked the necessary resources to
create another thread, or the system-imposed l
--- Comment #9 from janus at gcc dot gnu dot org 2009-12-17 09:46 ---
Fixed on trunk with r155305 (on fortran-dev it was working already). Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from paolo dot carlini at oracle dot com 2009-12-17 09:48
---
Yeah, the description technically fits better, but indeed, without -pthread the
system cannot create thread *at all*, I'm afraid many users could be mystified
by that...
--
http://gcc.gnu.org/bugzilla/show
--- Comment #16 from paolo dot carlini at oracle dot com 2009-12-17 09:58
---
The std::array error seems indeed bogus: if I'm not wrong, it happens when
swapping arrays, and there are no guarantees that the operation doesn't throw
for std::array, because it's requires to just swap the
--- Comment #4 from davek at gcc dot gnu dot org 2009-12-17 10:07 ---
Ok, it's not an LD bug. LD is doing the right thing, which in this case turns
out to be filtering it out of the list of exports due to the version script.
In the 32-bit multilib, we have this version of std::string::
most likely the changes of 155302 are the cause.
../../gcc-4-5-libwork/gcc/objc/objc-act.c: In function objc_substitute_decl:
../../gcc-4-5-libwork/gcc/objc/objc-act.c:3118:14: error: incompatible type for
argument 3 of build_indirect_ref
../../gcc-4-5-libwork/gcc/c-common.h:465:13: note: expe
--- Comment #5 from davek at gcc dot gnu dot org 2009-12-17 10:20 ---
Starting to think that actually this is just how the ABI should be for w64 and
the version script for libstdc++ just has a weakness. If I'm guessing right,
it's because w64 is the only LLP64 target that is why this wo
--- Comment #6 from paolo dot carlini at oracle dot com 2009-12-17 10:25
---
Under linux, it's just unsigned long, which is 64-bit anyway, because actually
it's a size_t. Seems strange that we didn't notice yet, but it's well possible
that on some 64-bit systems a size_t is an unsigned
--- Comment #4 from ramana at gcc dot gnu dot org 2009-12-17 10:49 ---
Confirmed -
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #5 from paolo at gcc dot gnu dot org 2009-12-17 11:09 ---
Subject: Bug 42198
Author: paolo
Date: Thu Dec 17 11:09:05 2009
New Revision: 155308
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155308
Log:
2009-12-17 Paolo Carlini
PR libstdc++/42198
*
--- Comment #6 from paolo dot carlini at oracle dot com 2009-12-17 11:11
---
Done.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pzhao at gcc dot gnu dot org
|dot org
--- Comment #1 from rainer at emrich-ebersheim dot de 2009-12-17 11:21
---
(In reply to comment #0)
> most likely the changes of 155302 are the cause.
>
> ../../gcc-4-5-libwork/gcc/objc/objc-act.c: In function objc_substitute_decl:
> ../../gcc-4-5-libwork/gcc/objc/objc-act.c:3118:14:
--- Comment #4 from rainer at emrich-ebersheim dot de 2009-12-17 11:22
---
(In reply to comment #3)
> Fixed for 4.5.0.
>
This breaks bootstrap at stage 2 in objc/objc-act.c see PR42400,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42400
--
rainer at emrich-ebersheim dot de changed:
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-12-17 11:23 ---
I can reproduce it on i?86-linux with an extra assert.
Index: gcc/expr.c
===
--- gcc/expr.c (revision 155297)
+++ gcc/expr.c (working copy)
@@ -1194,
--- Comment #7 from davek at gcc dot gnu dot org 2009-12-17 11:27 ---
Created an attachment (id=19336)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19336&action=view)
differences between 32-bit and 64-bit exported symbols
There's a bunch more missing than just std::string::reserv
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-17 11:29 ---
Hm? The TREE_STATIC is ok, the bug is that the actual arguments are
different and maybe that inside the __MAIN BLOCK vars there shouldn't
be a function decl.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42122
--- Comment #2 from developer at sandoe-acoustics dot co dot uk 2009-12-17
11:30 ---
Created an attachment (id=19337)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19337&action=view)
apply the new ref_operator to objc-act.c
this is a mechanical change to the file, bootstrapped an
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-17 11:44 ---
Confirmed.
int ptrace_setregs(void)
{
union { unsigned int l; int t; } __gu_tmp;
__asm__ __volatile__("" : "=r" (__gu_tmp.l));
return __gu_tmp.t;
}
--
rguenth at gcc dot gnu dot org changed:
Wh
--- Comment #9 from rearnsha at gcc dot gnu dot org 2009-12-17 11:46
---
Agreed, this is really a target bug.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #10 from rearnsha at gcc dot gnu dot org 2009-12-17 11:50
---
Subject: Bug 42372
Author: rearnsha
Date: Thu Dec 17 11:50:06 2009
New Revision: 155310
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155310
Log:
PR target/42372
* arm.md (pic_add_dot_plu
--- Comment #11 from rearnsha at gcc dot gnu dot org 2009-12-17 11:51
---
Fixed
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #8 from davek at gcc dot gnu dot org 2009-12-17 11:52 ---
Created an attachment (id=19338)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19338&action=view)
salient diffs extracted
I removed all the matching +/- line pairs from the raw diff file where a
signature change
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-12-17 11:53 ---
It's also a middle-end issue.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from jwakely dot gcc at gmail dot com 2009-12-17 11:55
---
I can't see any 100% reliable way to prevent this problem, because the
catch-all specialisation of iterator_traits can be instantiated with
non-iterator types.
We could try tricks like this to restrict std::next
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-17 12:00
---
Fixed with:
http://gcc.gnu.org/ml/gcc-cvs/2009-12/msg00455.html
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #24 from jwakely dot gcc at gmail dot com 2009-12-17 12:01
---
Although that breaks if any of the iterator-like operators exists but is not
accessible - I think concepts would have worked in that case, but I'm not sure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4049
--- Comment #25 from paolo dot carlini at oracle dot com 2009-12-17 12:07
---
Interesting trick, really, the power of extended SFINAE ;) I think we should
keep that in mind, for the DO THE RIGHT THING clause of the containers too, for
example (some time ago Howard told me that in his Me
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-17 12:09
---
Yeah, the usual accessibility issue: in Santa Cruz I discussed that briefly
with Doug, he pretended to convince people that with extended SFINAE you can
implement trivially *any* introspection trait, then someb
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-17 12:10
---
Sorry, the last comment is for 40497.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40856
--- Comment #26 from paolo dot carlini at oracle dot com 2009-12-17 12:11
---
Yeah, the usual accessibility issue: in Santa Cruz I discussed that briefly
with Doug, he pretended to convince people that with extended SFINAE you can
implement trivially *any* introspection trait, then some
--- Comment #27 from jwakely dot gcc at gmail dot com 2009-12-17 12:23
---
ha!
std::next would want is_input_iterator and std::prev would ideally want
is_bidi_iterator, so maybe more than one trait
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40497
--- Comment #28 from paolo dot carlini at oracle dot com 2009-12-17 12:25
---
Actually, details, std::next now wants _ForwardIterator, don't ask me to lookup
the DR ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40497
--- Comment #4 from linuxl4 at sohu dot com 2009-12-17 12:32 ---
confirmed! Today my gcc 4.5 bootstrap also failed :(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42400
--- Comment #7 from uros at gcc dot gnu dot org 2009-12-17 12:33 ---
Subject: Bug 32280
Author: uros
Date: Thu Dec 17 12:33:09 2009
New Revision: 155312
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155312
Log:
PR target/32280
* config/i386/i386-modes.def (V1TI)
> cat main.cc
struct Foo { static void f(); };
int main() { Foo::f(); }
> cat Foo.cc
#include
#include
struct Foo { static void f(); };
void Foo::f()
{
typedef std::map Map;
static Map m;
Map::const_iterator it = m.find(0);
if (it != m.end()) {
> cat main.cc
struct Foo { static void f(); };
int main() { Foo::f(); }
> cat Foo.cc
#include
#include
struct Foo { static void f(); };
void Foo::f()
{
typedef std::map Map;
static Map m;
Map::const_iterator it = m.find(0);
if (it != m.end()) {
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-17 12:55 ---
Combining -O0 on either compile or link side with -On on the other side has
interesting effects.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42402
$ install/bin/arm-none-linux-gnueabi-gcc --version
arm-none-linux-gnueabi-gcc (GCC) 4.5.0 20091214 (experimental)
[...]
GCC fails to re-adjust the CFA after pop:
$ cat d.c
void foo(void)
{
register int r7 asm("r7");
asm volatile ("" : : "r" (r7) : "memory");
}
$ install/bin/arm-none-linux-gnueabi-gcc --version
arm-none-linux-gnueabi-gcc (GCC) 4.5.0 20091214 (experimental)
[...]
This GCC contains the following patch for gcc/config/arm/arm.c:
@@ -1877,7 +1877,8 @@ arm_override_options (void)
debug info. However this also creates th
--- Comment #1 from tschwinge at gcc dot gnu dot org 2009-12-17 14:12
---
Last paragraph: .cfi_adjust_cfa_offset *-4*, of course.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42403
--- Comment #5 from martin at mpa-garching dot mpg dot de 2009-12-17 14:12
---
> GCC with -std=c99 makes sure to properly handle the i387 FPU excess precision.
> With -fexcess-precision=fast the code is as fast (and non-conforming) like
> with GCC 4.4. Using -std=gnu99 is also an optio
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-17 14:26 ---
It is DOM which threads over the check in bb 12:
:
__y_90 = __y_108;
D.2866_92 = __y_108->_M_value_field.first;
if (D.2866_92 > 0)
goto ;
else
goto ;
:
# SR.42_94 = PHI
if (SR.42_94 != &m._M_t.
I'm trying to get java to run on the ARM processor based SheevaPlug. I am
compiling on the SheevaPlug, itself.
At /mnt/seagate2/work/gjc/trunk, I pulled from Subversion:
plug trunk # svn info
Path: .
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-12-17 14:36 ---
Subject: Bug 42397
Author: rguenth
Date: Thu Dec 17 14:36:43 2009
New Revision: 155316
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155316
Log:
2009-12-17 Richard Guenther
PR middle-end/42397
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-12-17 14:39 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
gcc issues warning when using the tolower function along with an optimization
flag. This warning also happens in other versions of gcc apart from 4.4.2
gcc -std=c99 -pedantic -O2 -Wall -Wunreachable-code a.c
a.c:13: warning: will never be executed
#include
#include
#include
int main(void)
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-17 15:17 ---
Btw, the single-file testcase
#include
#include
int main ()
{
typedef std::map Map;
static Map m;
Map::const_iterator it = m.find(0);
if (it != m.end()) {
std::string s = it->second;
}
}
fails t
--- Comment #9 from davek at gcc dot gnu dot org 2009-12-17 15:25 ---
Subject: Bug 42377
Author: davek
Date: Thu Dec 17 15:25:36 2009
New Revision: 155318
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155318
Log:
PR target/42377
* config/abi/pre/gnu.ver: Adjust
--- Comment #10 from davek at gcc dot gnu dot org 2009-12-17 15:27 ---
Should be fixed in SVN now. Rainer, please verify when you get a chance.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-17 16:20 ---
-Wunreachable-code is broken and has been removed in 4.5.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-17 16:22 ---
Make sure your install library path is in LD_LIBRARY_PATH.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-12-17 16:22 ---
Documentation improvement is always welcome, especially if you looked for it
but
missed the critical piece.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42376
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-17 16:25 ---
I'm not sure if arm has been updated for CFI in the prologue/epilogue.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from hjl dot tools at gmail dot com 2009-12-17 16:38 ---
It is caused by revision 147995:
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00974.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
A potential source of error for C programmers is the inadvertent covering of
one header file by another with the same name. This issue is documented by
CERT in the "CERT C Secure Coding Standard" as "PRE08-C. Guarantee that header
file names are unique
[https://www.securecoding.cert.org/confluence
--- Comment #3 from bkoz at gcc dot gnu dot org 2009-12-17 17:04 ---
We really need something for gcc-4.5/porting_to.html
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from jlpoole at pon dot net 2009-12-17 17:18 ---
Thank you. This worked:
export LD_LIBRARY_PATH=/usr/local/gcj/usr/local/lib
then
plug bin # ./gcj -v -I /usr/local/gcj/usr/local/share/java/libgcj-4.5.0.jar
/var
/work/gcj/HelloWorld.java
--
jlpoole at pon dot net cha
--- Comment #3 from hjl dot tools at gmail dot com 2009-12-17 17:27 ---
This is caused by new SRA:
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00959.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42398
There is no templatized user-provided seed()
and related constructors in the C++0x random
number generation library. The draft N3000 says
that the engines (Mersenne Twister, among others)
have
template explicit mersenne_twister_engine(Sseq& q);
template void seed(Sseq& q);
in order to use a user-
(This Bug follows 4205 which is not marked FIXED)
On armv5tel-unknown-linux-gnueabi I compiled gcj plus .../contrib/download_ecj.
Last Changed Rev: 155206
Last Changed Date: 2009-12-13 21:06:50 -0800 (Sun, 13 Dec 2009)
installed
--- Comment #1 from paolo dot carlini at oracle dot com 2009-12-17 17:55
---
Yes, this is known, no need to keep this issue open for ongoing C++0x work: the
issue basically is that has not been un-conceptualized yet in the WP,
now that Concepts are gone, and we are for now keeping the
--- Comment #10 from espindola at gcc dot gnu dot org 2009-12-17 18:09
---
I tried to build gcc on darwin to debug this but the build fails with a link
failure (sorry, don't remember exactly where). Do I need to do something
special to build on darwin?
The error message is emitted when
--- Comment #11 from dominiq at lps dot ens dot fr 2009-12-17 19:16 ---
> I tried to build gcc on darwin to debug this but the build fails with a link
> failure (sorry, don't remember exactly where). Do I need to do something
> special to build on darwin?
On which version of darwin did
--- Comment #11 from jakub at gcc dot gnu dot org 2009-12-17 19:29 ---
Subject: Bug 42386
Author: jakub
Date: Thu Dec 17 19:29:48 2009
New Revision: 155321
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155321
Log:
PR c++/42386
* ipa.c (function_and_variable_visi
--- Comment #8 from jakub at gcc dot gnu dot org 2009-12-17 19:31 ---
Subject: Bug 41679
Author: jakub
Date: Thu Dec 17 19:30:58 2009
New Revision: 155322
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155322
Log:
PR debug/41679
* var-tracking.c (add_stores): Avo
--- Comment #9 from jakub at gcc dot gnu dot org 2009-12-17 19:32 ---
Subject: Bug 41679
Author: jakub
Date: Thu Dec 17 19:31:52 2009
New Revision: 155323
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155323
Log:
PR debug/41679
* var-tracking.c (use_type): Remov
--- Comment #10 from jakub at gcc dot gnu dot org 2009-12-17 19:32 ---
Subject: Bug 41679
Author: jakub
Date: Thu Dec 17 19:32:32 2009
New Revision: 155324
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155324
Log:
PR debug/41679
* var-tracking.c (count_uses): Co
pragma ada_83;
with text_io;
procedure test1 is
type T1 is record
str: string(1..10);
end record;
x1: T1 := (str => (others => 49)); --ERROR: 49 is not a character
begin
text_io.put_line(x1.str);
end test1;
$ gnatmake test1; ./test1
gcc-4.3 -c test1.adb
gnatbind -x test1.ali
g
--- Comment #1 from ludovic at ludovic-brenta dot org 2009-12-17 19:42
---
Fixed in 4.4; this PR only to document the the issue for users of previous
versions.
--
ludovic at ludovic-brenta dot org changed:
What|Removed |Added
-
package pak1 is
type T1 is new integer;
type T1_access is access all T1;
x1: aliased T1;
x2: T1 := x1'access.all;--ERROR: 4.1(8) (missed)
x3: T1_access := T1_access(x1'access); --ERROR: 4.6(6) (detected)
end pak1;
Gnat misses the error involving x1'access.all.
RM 3
--- Comment #1 from ludovic at ludovic-brenta dot org 2009-12-17 19:47
---
RM 8.6(27)/2 is also relevant:
When a construct is one that requires that its expected type be a
single type in a given class, the type of the construct shall be
determinable solely from the context in w
--- Comment #2 from developer at sandoe-acoustics dot co dot uk 2009-12-17
19:51 ---
Created an attachment (id=19339)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19339&action=view)
updated patch to allow specification of -static-libstdc++ on the CL while
generating PCH
--
de
package pak1 is
type T1 is tagged null record;
x1: T1;
x2: T1'class := x1;
x3: T1'class renames x1; --ERROR: (detected) T1'class vs T1
x4: T1 renames x2;--ERROR: (missed)T1 vs T1'class
end pak1;
$ gnatmake pak1
gcc-4.3 -c pak1.ads
pak1.ads:5:25: expected type "T1'class
--- Comment #1 from ludovic at ludovic-brenta dot org 2009-12-17 19:52
---
$ gnatmake pak1
gcc-4.4 -c pak1.ads
pak1.ads:5:25: expected type "T1'class" defined at line 2
pak1.ads:5:25: found type "T1" defined at line 2
pak1.ads:6:19: dynamically tagged expression not allowed
gnatmake: "p
--- Comment #3 from developer at sandoe-acoustics dot co dot uk 2009-12-17
19:54 ---
the patch has been modified following the discussions in:
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00862.html
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00855.html
to re-write "-static-libstdc++"
--- Comment #4 from davek at gcc dot gnu dot org 2009-12-17 19:58 ---
(In reply to comment #2)
> Created an attachment (id=19339)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19339&action=view) [edit]
> updated patch to allow specification of -static-libstdc++ on the CL while
> ge
with Text_IO;
procedure test1 is
task type T1 is
entry E1;
end T1;
task body T1 is
begin
Text_IO.Put_Line ("T1 started");
accept E1;
Text_IO.Put_Line ("T1 done");
end T1;
function f1 return T1 is
begin
return R : T1;
end f1;
procedure p2 (
--- Comment #4 from pault at gcc dot gnu dot org 2009-12-17 20:17 ---
I think that FX was right, since Toon has not responded in 6 months.
Entering a WONTFIX
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
gcc/Makefile.in contains the line
sed '/set tmpdir/ s|testsuite|$(TESTSUITEDIR)/$*|' \
< ../../site.exp > tmp-site.exp; \
which caused a large number of test failures because I had the testsuite in a
path that included the word "testsuite" which was erroneously expanded.
Be
test.cc:
class A {
void f();
}
void A::f() {
A::A();
}
g++ -c test.cc
/tmp/cciN3Byt.s: Assembler messages:
/tmp/cciN3Byt.s:18: Warning: missing operand; zero assumed
/tmp/cciN3Byt.s:18: Error: undefined symbol `_ZN1AC1Ev' in operation
/tmp/cciN3Byt.s:18: Error: undefined symbol `INTERNAL' in
--- Comment #1 from truedfx at gentoo dot org 2009-12-17 20:51 ---
And here's the generated assembly:
.file "test.cc"
.text
.align 2
.globl _ZN1A1fEv
.type _ZN1A1fEv, @function
_ZN1A1fEv:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi
--- Comment #1 from pault at gcc dot gnu dot org 2009-12-17 20:51 ---
I believe that gfortran behaves correctly in all the testcases in this thread.
I have written to Bob Corbet to see if he agrees. The nub of the matter is
that a local declaration always has precedence over a host ass
--- Comment #10 from pault at gcc dot gnu dot org 2009-12-17 20:54 ---
(In reply to comment #9)
> With the upcoming release of 4.5, I think it would be nice to fix/improve the
> translation related bugs now, i.e. this, PR38573 and PR40489.
>
> As I have no idea how to reproduce/check/wh
--- Comment #12 from jakub at gcc dot gnu dot org 2009-12-17 20:56 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #11 from jakub at gcc dot gnu dot org 2009-12-17 20:57 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from pault at gcc dot gnu dot org 2009-12-17 21:02 ---
Hmmm! :-)
Since Cray pointers are non-standard, one might argue for undetermined
behaviour. However, logically, both pointer and pointee are symbols in the
modules and so should be use associated.
Therefore, I vote
--- Comment #5 from pault at gcc dot gnu dot org 2009-12-17 21:04 ---
(In reply to comment #4)
> (In reply to comment #3)
Gentlemen,
What is the word on this? A WONTFIX?
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39654
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirm
1 - 100 of 155 matches
Mail list logo
