[Bug c++/26883] ICE when assigning memory attribute to class with simple constructor
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-27 08:09 ---
We ICE in
if (base && DECL_P (base)
&& TREE_READONLY (base)
&& (TREE_STATIC (base) || DECL_EXTERNAL (base)))
{
tree base_type = TREE_TYPE (base);
gcc_assert (!(base_type && TYPE_NEEDS_CONSTRUCTING (base_type))
|| DECL_ARTIFICIAL (base));
MEM_READONLY_P (ref) = 1;
Now, it is indeed questionable to put a non-POD into ro memory. So I think
this is INVALID - but let's see what others think.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|target |c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26883
[Bug target/26883] ICE when assigning memory attribute to class with simple constructor
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-27 08:12 --- (In reply to comment #1) > We ICE in > Now, it is indeed questionable to put a non-POD into ro memory. So I think > this is INVALID - but let's see what others think. The target should have rejected progmem and not placed const on the decl. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26883
[Bug debug/26881] [4.1/4.2 Regression] internal compiler error in dwarf2out_finish
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-03-27 08:17 ---
(gdb) up
#1 0x082e8034 in dwarf2out_finish (filename=0xbfb6d1ca "t.c")
at /space/rguenther/src/svn/summit/gcc/dwarf2out.c:14104
14104 gcc_assert (context && TREE_CODE (context) ==
FUNCTION_DECL);
(gdb) print context
$1 = (tree) 0xb7d91138
(gdb) call debug_generic_expr(context)
BLOCK
SUPERCONTEXT: BLOCK 0xb7d9116c
VARS: unionunion
{
} uD.1525 ttD.1526 cD.1527
eh? what's that? cfun is also NULL.
(gdb) call debug_generic_expr(node->created_for)
union
{
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26881
[Bug libstdc++/26875] Array allocator use count is shared between array_allocator instances
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-27 08:29 --- Confirmed. Though it looks like this is a fundamental problem of the interface provided. Should be documented so though. Also destroying an array allocator instance does not reset the __array_used value, so only ever one allocator instance per Type/Storage can be used even sequentially after each other. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to fail|4.2.0 |4.0.3 4.1.0 4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-03-27 08:29:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26875
[Bug middle-end/26831] sibcall, sibcall_value, sibcall_pop, sibcall_value_pop: standard names not documented.
--- Comment #3 from dave dot korn at artimi dot com 2006-03-27 10:05 --- Added by rth's sibcall optimisations back in March 2000: http://gcc.gnu.org/viewcvs?rev=32612&view=rev Should we give him a ping? cheers, DaveK -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26831
[Bug libstdc++/26875] Array allocator use count is shared between array_allocator instances
--- Comment #4 from bart dot vanassche at gmail dot com 2006-03-27 10:53 --- (In reply to comment #3) > Confirmed. Though it looks like this is a fundamental problem of the > interface > provided. Should be documented so though. Also destroying an array allocator > instance does not reset the __array_used value, so only ever one allocator > instance per Type/Storage can be used even sequentially after each other. I don't think it's an interface problem -- IMHO changing __array_used into a (non-static) member of class array_allocator<> would solve this issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26875
[Bug libstdc++/26875] Array allocator use count is shared between array_allocator instances
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-03-27 11:10 --- Yes, though that would be an ABI change - that it's static _is_ the interface provided. Should definitely be fixed in v7 though. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26875
[Bug libstdc++/26875] Array allocator use count is shared between array_allocator instances
--- Comment #6 from pcarlini at suse dot de 2006-03-27 11:17 --- Guys, yes we can try to improve a bit this small extension class, but it's definitely not high-priority, it's just a simple extension, not used elsewhere in the library. And, yes, as such, we can also fix it before v7, we have only to agree about what we really want. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26875
[Bug c++/26365] [3.4/4.0/4.1/4.2 Regression] ICE in finish_class_member_access_expr, at cp/typeck.c
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-03-27 11:27
---
Here are two more reduced testcases. The first ICEs since GCC 3.4.0,
the second since at least GCC 2.95.3:
=
struct A {};
namespace N
{
template void foo();
}
void bar(A *p)
{
p->N::foo<0>();
}
=
=
struct A {};
namespace N
{
template void foo();
}
void bar(A *p)
{
p->N::foo<0>; // without parens
}
=
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Keywords||monitored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26365
[Bug c++/26884] New: [4.1/4.2 regression] Misleading diagnostic for invalid array initializer
For the follwoing code snippet a bogus diagnostic is emitted since
GCC 4.1.0:
int main()
{
int a[2] = { 2, 3 };
int b[2] = a;
}
bug.cc: In function 'int main()':
bug.cc:4: error: cannot convert 'int [2]' to 'int [2]' in initialization
This message is confusing since transforming int[2] into int[2]
shouldn't be hard. The problem is that you cannot use an array
for initialization at all.
Before we got:
bug.cc: In function 'int main()':
bug.cc:4: error: invalid initializer
which is not too helpful, but at least correct.
--
Summary: [4.1/4.2 regression] Misleading diagnostic for invalid
array initializer
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: diagnostic, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26884
[Bug libstdc++/26733] move semantics vs. debug mode
--- Comment #4 from pcarlini at suse dot de 2006-03-27 12:34 --- Working on it. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-27 12:34:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26733
[Bug target/26885] New: [4.1/4.2 regression] -m64 -m32 no longer creates 32-bit object
Up until
2005-06-13 Mark Mitchell <[EMAIL PROTECTED]>
* config/i386/x86-64.h (ASM_SPEC): Explicitly pass --64 to the
assembler in 64-bit mode.
change -m64 -m32 used to work on x86_64 (I know it is quite fragile and
on many arches doesn't DTRT), but now as the asm spec has:
%{m32:--32} %{-m64:--64} we for both -m64 -m32 and -m32 -m64 end up with
--32 --64 being passed to the assembler (in that order).
Guess best would be to say in *.opt rather than RejectNegative what the
negative
of the option is (for m32 Negative(m64) and for m64 Negative(m32) or something
like that) and handle this in gcc.c/opts.c.
--
Summary: [4.1/4.2 regression] -m64 -m32 no longer creates 32-bit
object
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26885
[Bug tree-optimization/26859] [4.2 Regression] ICE Segmentation Fault
--- Comment #5 from malitzke at metronets dot com 2006-03-27 15:17 --- The fairly extensive changes submitted by Mr Sebastian Pop solved the PR 26859 as originally reported by myself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26859
[Bug fortran/23201] [4.1/4.2 Regression] ICE verify_ssa failed, gfortran references non-existing fields
--- Comment #10 from dir at lanl dot gov 2006-03-27 15:24 --- This error seems to have gone away. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23201
[Bug tree-optimization/26763] [4.1 Regression] wrong final value of induction variable calculated
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-03-20 10:15:36 |2006-03-27 15:43:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26763
[Bug c++/26886] New: missing warning for no return statement in function returning non-void
Missing warning for no return statement in function returning non-void
The following code when compiled with -Wreturn-type -c
prints a warning about function test2 which is a non-void function missing a
return statement, but it does not print a warning about test1.
tmp.C: In function `int test2()':
tmp.C:17: warning: control reaches end of non-void function
If I comment out both lines in test1, I then get both warnings:
tmp.C: In member function `int foo::test1()':
tmp.C:10: warning: no return statement in function returning non-void
tmp.C: In function `int test2()':
tmp.C:17: warning: control reaches end of non-void function
///
int xxx = 999;
class foo
{
public:
int test1()
{
if (xxx == 10)
return 0;
}
};
int test2()
{
if (xxx == 10)
return 0;
}
///
I need it to warn about test1.
--
Summary: missing warning for no return statement in function
returning non-void
Product: gcc
Version: 3.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jpoland at cadence dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26886
[Bug middle-end/26611] openmp gomp ICE at gimplify.c:4257
--- Comment #7 from jakub at gcc dot gnu dot org 2006-03-27 16:12 --- Fixed in SVN. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26611
[Bug libstdc++/26887] New: const_reverse_iterator does not have a mixed equality or inequality operator
The behavior of const_reverse_iterator is different from the behavior of
const_iterator, due to having no mixed const/non-const equality or inequality
operators. Consider the following code:
#include
#include
using std::map;
using std::cout;
using std::endl;
using std::string;
void test1()
{
map< int, string > map1;
map1[ 0 ] = "test1";
map1[ 1 ] = "test2";
typedef map< int, string >::const_iterator conit;
// The following is okay because although map1.end()
// returns a non-const iterator, const_iterator has a
// mixed const/non-const inequality operator defined.
for( conit cit = map1.begin() ; cit != map1.end() ; ++cit )
cout << ( *cit ).second << endl;
}
void test3( const map< int, string > &map1 )
{
typedef map< int, string >::const_reverse_iterator conit;
// The following is okay, because map1.rend() returns
// a const_reverse_iterator
for( conit cit = map1.rbegin() ; cit != map1.rend() ; ++cit )
cout << ( *cit ).second << endl;
}
void test2()
{
map< int, string > map1;
map1[ 0 ] = "test1";
map1[ 1 ] = "test2";
typedef map< int, string >::const_reverse_iterator conit;
test3( map1 );
// The following line fails to compile:
// map1.rend() returns a non-const reverse_iterator
// and there is no mixed inequality operator
for( conit cit = map1.rbegin() ; cit != map1.rend() ; ++cit )
cout << ( *cit ).second << endl;
}
int main()
{
test1();
test2();
return 0;
}
--
Summary: const_reverse_iterator does not have a mixed equality or
inequality operator
Product: gcc
Version: 3.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schaudhu at blackrock dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26887
[Bug c++/25015] [gomp] Function names cannot be demangled due to ".omp_fn" suffix
--- Comment #3 from jakub at gcc dot gnu dot org 2006-03-27 16:29 --- What we perhaps could do is hack up C++ lang_decl_name etc., so that for the artificially created .omp_fn* functions the diagnostic machinery would instead print the name of the original function, perhaps annotated with #pragma omp region of ... or something similar. Not sure if we can use for that just if (DECL_ARTIFICIAL (current_function_decl) && name starts with create_omp_child_function_name prefix) or if we would need to add some special attribute or bit (and if the latter, if it is worth doing). -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25015
[Bug target/26885] [4.1/4.2 regression] -m64 -m32 no longer creates 32-bit object
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-27 16:37 --- Confirmed, -m32 -m64 is also broken too. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-27 16:37:46 date|| Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26885
[Bug libstdc++/26887] const_reverse_iterator does not have a mixed equality or inequality operator
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-27 16:40 --- This fails in 4.0.3: t.cc: In function void test2(): t.cc:48: error: no match for operator!= in cit != std::map<_Key, _Tp, _Compare, _Alloc>::rend() [with _Key = int, _Tp = std::basic_string, std::allocator >, _Compare = std::less, _Alloc = std::allocator, std::allocator > > >]() But works in both 4.1.0 and the mainline. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.0.3 Known to work||4.1.0 4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26887
[Bug c++/26884] [4.1/4.2 regression] Misleading diagnostic for invalid array initializer
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-27 16:42 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.1.0 4.2.0 Known to work||4.0.3 Last reconfirmed|-00-00 00:00:00 |2006-03-27 16:42:12 date|| Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26884
[Bug tree-optimization/26797] [4.2 Regression] ACATS c35507m cd2a23e cxh1001 failures
--- Comment #4 from law at redhat dot com 2006-03-27 17:09 --- It seems to me that the fundamental problem is that the testcase manages to stuff the value "3" into an object which is supposed to only have the range [4, 5]. ie, if you put a breakpoint in C35507M.NEWCHARBRP and examine the first parameter (ie A) you'll find that on the first call and second calls "A" has the value 4 and 5 respectively. However, on the 3rd call it has the value 3, which is clearly out of "A"'s range [3, 4]. I suspect there are similar issues with C35507M.CHARRP since it has similar looking code. Someone with a better knowledge of the Ada front-end, the langauge and the testsuite is going to need to chime in at this point. From the data I see, VRP is doing exactly what we want and expect it to do. -- law at redhat dot com changed: What|Removed |Added CC||kenner at vlsi1 dot ultra ||dot nyu dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug libfortran/26889] New: libfortran build fails with: object requires TLS, but TLS failed to initialize
I'm using GMP 4.2 and MPFR 2.2.0, both built with gcc-4.0.2. When I go to build gcc-4.0.3, I get the following error: /afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_59/gcc/gfortran -B/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_59/gcc/ -B/usr/pubsw/sparc-sun-solaris2.9/bin/ -B/usr/pubsw/sparc-sun-solaris2.9/lib/ -isystem /usr/pubsw/sparc-sun-solaris2.9/include -isystem /usr/pubsw/sparc-sun-solaris2.9/sys-include -I . -Wall -fno-repack-arrays -fno-underscoring -c ../../../../gcc-4.0.3/libgfortran/intrinsics/selected_int_kind.f90 -fPIC -DPIC -o .libs/selected_int_kind.o ld.so.1: f951: fatal: /afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_59/gcc/f951: object requires TLS, but TLS failed to initialize gfortran: Internal error: Killed (program f951) Please submit a full bug report. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: libfortran build fails with: object requires TLS, but TLS failed to initialize Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: quanah at stanford dot edu GCC build triplet: sparc-sun-solaris2.9 GCC host triplet: sparc-sun-solaris2.9 GCC target triplet: sparc-sun-solaris2.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug tree-optimization/26797] [4.2 Regression] ACATS c35507m cd2a23e cxh1001 failures
--- Comment #5 from law at redhat dot com 2006-03-27 17:22 --- The cd2a23e test seems to have the same root cause as c35507m. No clue about cxh1001 -- I'd rather not spend a lot of time analyzing cxh1001 without first getting some resolution on the known issues with c35507m and cd2a23e. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug fortran/26889] libfortran build fails with: object requires TLS, but TLS failed to initialize
--- Comment #1 from quanah at stanford dot edu 2006-03-27 17:23 --- change to fortran, instead of libfortran. -- quanah at stanford dot edu changed: What|Removed |Added Component|libfortran |fortran http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug libfortran/26890] New: SIZE parameter interacts with same variable in IO list character length specification.
The program below produces the correct result for the first read and nothing
for the second. ifort and g95 produce the same result for each. It is my
belief that this construct is not strictly standard compliant but it is widely
used - I found this during my efforts to make iso_varying_string work.
The code looks OK, so I think that the logic in the library needs a little bit
of tweaking:
nchars = 80;
{
struct __st_parameter_dt dt_parm.8;
dt_parm.8.common.filename = "advance_io.f90";
dt_parm.8.common.line = 21;
dt_parm.8.common.unit = 10;
dt_parm.8.advance = "no";
dt_parm.8.advance_len = 2;
dt_parm.8.format = "(a)";
dt_parm.8.format_len = 3;
dt_parm.8.size = &nchars;
dt_parm.8.common.flags = 13328;
_gfortran_st_read (&dt_parm.8);
_gfortran_transfer_character (&dt_parm.8, &buffer, NON_LVALUE_EXPR
) ;
_gfortran_st_read_done (&dt_parm.8);
switch (dt_parm.8.common.flags & 3)
{
case 3:;
goto __label_000999;
}
}
Paul
character(80) :: buffer, line
integer :: nchars
line = "The quick brown fox jumps over the lazy dog."
open (10)
write (10, '(a)') trim(line)
rewind (10)
nchars = 80
read (10, '(a)', advance = 'no', size = nchars, eor = 998) buffer
998 print *, nchars, buffer
rewind (10)
buffer = ""
nchars = 80
read (10, '(a)', advance = 'no', size = nchars, eor = 999) buffer (:nchars)
999 print *, nchars, buffer
close (10)
end
--
Summary: SIZE parameter interacts with same variable in IO list
character length specification.
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pault at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26890
[Bug libstdc++/26887] const_reverse_iterator does not have a mixed equality or inequality operator
--- Comment #2 from pcarlini at suse dot de 2006-03-27 17:28 --- Will not be fixed in 4_0-branch. *** This bug has been marked as a duplicate of 11729 *** -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26887
[Bug libstdc++/11729] [DR280] no operator!= for const_reverse_iterator
--- Comment #15 from pcarlini at suse dot de 2006-03-27 17:28 --- *** Bug 26887 has been marked as a duplicate of this bug. *** -- pcarlini at suse dot de changed: What|Removed |Added CC||schaudhu at blackrock dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11729
[Bug tree-optimization/26796] [4.2 Regression] ACATS ICE c34002a c52005 spurious storage_error
--- Comment #3 from law at redhat dot com 2006-03-27 17:53 --- Separate issue than 26797. Not sure how to fix yet, but it's definitely a bug in the new code. jeff -- law at redhat dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |law at redhat dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-03-22 10:32:16 |2006-03-27 17:53:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26796
[Bug libgcj/26858] NullPointerException not generated for large classes...
--- Comment #3 from mckinlay at redhat dot com 2006-03-27 18:28 --- GCJ could be made to generate explicit null checks when large offsets are used. It is probably relatively rare to have a normal object that is larger than a page, so performance for most apps shouldn't be effected. Note that array accesses should not need this as the "length" field will be dereferenced first, triggering NullPointerException, assuming bounds checks are used. I would also expect Strings should not have a problem. Do we know who's heap exactly is mapped at such a low address? If its mapped by Java/Boehm GC, then we can probably just fix the GC to not map things at such low addresses (or to insert guard pages there instead). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26858
[Bug libgcj/25916] java.text.NumberFormat.getCurrencyInstance throws IllegalArgumentExceptions even on standard locales
--- Comment #10 from tromey at gcc dot gnu dot org 2006-03-27 18:29 --- The classpath import won't happen for the 4.1.x branch. However, a workaround could be applied locally in Currency (or wherever) as long as it doesn't change the ABI. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25916
[Bug bootstrap/26829] broken classpath install (missed tools.zip), zip or fastjar not found
--- Comment #8 from tromey at gcc dot gnu dot org 2006-03-27 18:36 --- I'll handle this when I remove fastjar. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-03-24 17:14:23 |2006-03-27 18:36:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26829
[Bug libgcj/26858] NullPointerException not generated for large classes...
--- Comment #4 from ddaney at avtrex dot com 2006-03-27 18:42 --- Subject: Re: NullPointerException not generated for large classes... mckinlay at redhat dot com wrote: > --- Comment #3 from mckinlay at redhat dot com 2006-03-27 18:28 --- > GCJ could be made to generate explicit null checks when large offsets are > used. > It is probably relatively rare to have a normal object that is larger than a > page, so performance for most apps shouldn't be effected. > > Note that array accesses should not need this as the "length" field will be > dereferenced first, triggering NullPointerException, assuming bounds checks > are > used. I would also expect Strings should not have a problem. > > Do we know who's heap exactly is mapped at such a low address? If its mapped > by > Java/Boehm GC, then we can probably just fix the GC to not map things at such > low addresses (or to insert guard pages there instead). It is libgcj's (Boehm GC) heap in my tests that is at 0x1000. This message: http://gcc.gnu.org/ml/java/2006-03/msg00206.html Has more thoughts on the subject. David Daney. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26858
[Bug libgcj/26861] VirtualMachineError in interperter.
--- Comment #1 from tromey at gcc dot gnu dot org 2006-03-27 18:43 --- The error appears to be intentional: jint field_offset = field->u.boffset; if (field_offset > 0x) throw new java::lang::VirtualMachineError; However, I don't know what purpose this could serve. Perhaps it is a mistake on the part of the original author, thinking that this somehow reflects the internal limit of 65535 fields per .class file. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-27 18:43:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26861
[Bug fortran/26891] New: Automatic conversion for optional parameters of missing dummies
Both ifort and g95 produce viable executables with the following:
logical :: back =.true.
print *, myscan ("The quick brown fox jumped over the lazy dog", &
"brown", back)
print *, myscan ("The quick brown fox jumped over the lazy dog", &
"lazy")
contains
integer function myscan (str, substr, back)
character(*), intent(in) :: str, substr
logical, optional, intent(in) :: back
myscan = scan (str, substr, back)
end function myscan
end
gfortran seg faults in executing the second call myscan because the call to
intrinsic scan is made with in indirect reference to NULL; ie. the missing
argument back.
I think that, strictly speaking, the outcome of this code is not defined by the
standard. However, it does seem that other compilers quietly do the right
thing.
This fixes it:
Index: gcc/fortran/trans-intrinsic.c
===
--- gcc/fortran/trans-intrinsic.c (révision 112278)
+++ gcc/fortran/trans-intrinsic.c (copie de travail)
@@ -159,14 +159,42 @@
real_compnt_info;
+/* Converts a missing, optional argument into a null or zero, if the
+ formal argument is optional. */
+
+static void
+gfc_conv_missing_dummy (gfc_se * se, gfc_expr * arg, gfc_expr * expr)
+{
+ gfc_actual_arglist *actual;
+ gfc_intrinsic_arg *formal;
+ tree tmp;
+
+ formal = expr->value.function.isym->formal;
+ if (formal == NULL)
+return;
+
+ for (actual = expr->value.function.actual; actual; actual = actual->next,
+ formal = formal ? formal->next : NULL)
+if (actual->expr == arg && formal && formal->optional)
+ {
+ tmp = gfc_conv_expr_present (actual->expr->symtree->n.sym);
+ tmp = build3 (COND_EXPR, TREE_TYPE (se->expr), tmp, se->expr,
+ convert (TREE_TYPE (se->expr), integer_zero_node));
+ tmp = gfc_evaluate_now (tmp, &se->pre);
+ se->expr = tmp;
+ return;
+ }
+}
+
+
/* Evaluate the arguments to an intrinsic function. */
static tree
gfc_conv_intrinsic_function_args (gfc_se * se, gfc_expr * expr)
{
gfc_actual_arglist *actual;
+ gfc_se argse;
tree args;
- gfc_se argse;
args = NULL_TREE;
for (actual = expr->value.function.actual; actual; actual = actual->next)
@@ -188,6 +216,10 @@
else
gfc_conv_expr_val (&argse, actual->expr);
+ if (actual->expr->expr_type ==EXPR_VARIABLE
+ && actual->expr->symtree->n.sym->attr.optional)
+ gfc_conv_missing_dummy (&argse, actual->expr, expr);
+
gfc_add_block_to_block (&se->pre, &argse.pre);
gfc_add_block_to_block (&se->post, &argse.post);
args = gfc_chainon_list (args, argse.expr);
I will persue the standard before submitting this patch - I need to decide if
the conversion should be conditional on the standard in force and if
gfc_conv_function_call needs to be treated in the same way.
Paul
--
Summary: Automatic conversion for optional parameters of missing
dummies
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pault at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26891
[Bug fortran/26889] libfortran build fails with: object requires TLS, but TLS failed to initialize
--- Comment #2 from quanah at stanford dot edu 2006-03-27 19:23 --- On Solaris 8, the build fails also, except with the following error: /afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_58/gcc/gfortran -B/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_58/gcc/ -B/usr/pubsw/sparc-sun-solaris2.8/bin/ -B/usr/pubsw/sparc-sun-solaris2.8/lib/ -isystem /usr/pubsw/sparc-sun-solaris2.8/include -isystem /usr/pubsw/sparc-sun-solaris2.8/sys-include -I . -Wall -fno-repack-arrays -fno-underscoring -c ../../../../gcc-4.0.3/libgfortran/intrinsics/selected_int_kind.f90 -fPIC -DPIC -o .libs/selected_int_kind.o :0: internal compiler error: Segmentation Fault -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug preprocessor/26857] Warning for absolute or dotted header paths
--- Comment #1 from mbland at google dot com 2006-03-27 19:25 --- I've got a working patch for 4.1.0, including a test case, reviewed by Ian Lance Taylor. As soon as "our people" can work out an agreement with "your people" over copyright assignment, I'll be sure to post it to this PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26857
[Bug bootstrap/26892] New: Can't compile a 64-bit gcc
Configured and built with env CC='gcc -mcpu=970 -m64' ../configure --enable-checking=no --prefix=/pkgs/gcc-mainline --with-gmp=/opt/local/ --with-mpfr=/opt/local/ --with-as=/usr/local/odcctools-20060123/bin/as --with-ld=/usr/local/odcctools-20060123/bin/ld; make -j 8 bootstrap BOOT_CFLAGS='-mcpu=970 -m64 -O2 -g' >& build.log Bootstrap fails with true "AR_FLAGS=rc" "CC_FOR_BUILD=/Users/lucier/programs/gcc/mainline/objdir64/./prev-gcc/xgcc -B/Users/lucier/programs/gcc/mainline/objdir64/./prev-gcc/ -B/pkgs/gcc-mainline/powerpc-apple-darwin8.5.0/bin/" "CFLAGS=-mcpu=970 -m64 -O2 -g" "CXXFLAGS=-g -O2" "CFLAGS_FOR_BUILD=-g -O2" "CFLAGS_FOR_TARGET=-O2 -g -O2 " "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c" "LDFLAGS=" "LIBCFLAGS=-mcpu=970 -m64 -O2 -g" "LIBCFLAGS_FOR_TARGET=-O2 -g -O2 " "MAKE=make" "MAKEINFO=makeinfo --split-size=500 --split-size=500 --split-size=500 " "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "EXPECT=expect" "RUNTEST=runtest" "RUNTESTFLAGS=" "exec_prefix=/pkgs/gcc-mainline" "infodir=/pkgs/gcc-mainline/info" "libdir=/pkgs/gcc-mainline/lib" "prefix=/pkgs/gcc-mainline" "tooldir=/pkgs/gcc-mainline/powerpc-apple-darwin8.5.0" "AR=ar" "AS=as" "CC=/Users/lucier/programs/gcc/mainline/objdir64/./prev-gcc/xgcc -B/Users/lucier/programs/gcc/mainline/objdir64/./prev-gcc/ -B/pkgs/gcc-mainline/powerpc-apple-darwin8.5.0/bin/" "CXX=c++" "LD=ld" "LIBCFLAGS=-mcpu=970 -m64 -O2 -g" "NM=nm" "PICFLAG=" "RANLIB=ranlib" "DESTDIR=" DO=all multi-do # make /Users/lucier/programs/gcc/mainline/objdir64/./prev-gcc/xgcc -B/Users/lucier/programs/gcc/mainline/objdir64/./prev-gcc/ -B/pkgs/gcc-mainline/powerpc-apple-darwin8.5.0/bin/ -mcpu=970 -m64 -O2 -g -o makedepend \ makedepend.o libcpp.a ../libiberty/libiberty.a \ ./../intl/libintl.a -liconv -liconv ld64 warning: in /usr/lib/libiconv.dylib, file does not contain requested architecture ld64 warning: in /usr/lib/libiconv.dylib, file does not contain requested architecture can't resolve symbols: _libiconv, referenced from: _convert_using_iconv in libcpp.a(charset.o) __nl_find_msg in libintl.a(dcigettext.o) _libiconv_close, referenced from: __cpp_destroy_iconv in libcpp.a(charset.o) __cpp_convert_input in libcpp.a(charset.o) __nl_free_domain_conv in libintl.a(loadmsgcat.o) _libiconv_open, referenced from: _init_iconv_desc in libcpp.a(charset.o) __nl_init_domain_conv in libintl.a(loadmsgcat.o) _libiconv_set_relocation_prefix, referenced from: _libintl_set_relocation_prefix in libintl.a(relocatable.o) ld64 failed: symbol(s) not found -- Summary: Can't compile a 64-bit gcc Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu GCC build triplet: powerpc-apple-darwin8.5.0 GCC host triplet: powerpc-apple-darwin8.5.0 GCC target triplet: powerpc-apple-darwin8.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26892
[Bug c/26818] [4.1/4.2 Regression] tree check: expected class �type�, have �exceptional� (error_mark) in finish_struct, at c-decl.c:5350 (time.c)
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-03-27 20:03 --- Testing a patch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26818
[Bug libfortran/25378] [Fortran 2003] maxloc for all-false mask
--- Comment #5 from tkoenig at gcc dot gnu dot org 2006-03-27 20:05 --- Subject: Bug 25378 Author: tkoenig Date: Mon Mar 27 20:05:24 2006 New Revision: 112425 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112425 Log: 2006-03-27 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/20935 Backport from mainline * m4/iforeach.m4: Add SCALAR_FOREACH_FUNCTION macro. * m4/ifunction.m4: Add SCALAR_ARRAY_FUNCTION macro. * m4/minloc0.m4: Use SCALAR_FOREACH_FUNCTION. * m4/minloc1.m4: Use SCALAR_ARRAY_FUNCTION. * m4/maxloc0.m4: Use SCALAR_FOREACH_FUNCTION. * m4/maxloc1.m4: Use SCALAR_ARRAY_FUNCTION. * m4/minval.m4: Likewise. * m4/maxval.m4: Likewise. * m4/product.m4: Likewise. * m4/sum.m4: Likewise. * minloc0_16_i16.c : Regenerated. * minloc0_16_i4.c : Regenerated. * minloc0_16_i8.c : Regenerated. * minloc0_16_r10.c : Regenerated. * minloc0_16_r16.c : Regenerated. * minloc0_16_r4.c : Regenerated. * minloc0_16_r8.c : Regenerated. * minloc0_4_i16.c : Regenerated. * minloc0_4_i4.c : Regenerated. * minloc0_4_i8.c : Regenerated. * minloc0_4_r10.c : Regenerated. * minloc0_4_r16.c : Regenerated. * minloc0_4_r4.c : Regenerated. * minloc0_4_r8.c : Regenerated. * minloc0_8_i16.c : Regenerated. * minloc0_8_i4.c : Regenerated. * minloc0_8_i8.c : Regenerated. * minloc0_8_r10.c : Regenerated. * minloc0_8_r16.c : Regenerated. * minloc0_8_r4.c : Regenerated. * minloc0_8_r8.c : Regenerated. * minloc1_16_i16.c : Regenerated. * minloc1_16_i4.c : Regenerated. * minloc1_16_i8.c : Regenerated. * minloc1_16_r10.c : Regenerated. * minloc1_16_r16.c : Regenerated. * minloc1_16_r4.c : Regenerated. * minloc1_16_r8.c : Regenerated. * minloc1_4_i16.c : Regenerated. * minloc1_4_i4.c : Regenerated. * minloc1_4_i8.c : Regenerated. * minloc1_4_r10.c : Regenerated. * minloc1_4_r16.c : Regenerated. * minloc1_4_r4.c : Regenerated. * minloc1_4_r8.c : Regenerated. * minloc1_8_i16.c : Regenerated. * minloc1_8_i4.c : Regenerated. * minloc1_8_i8.c : Regenerated. * minloc1_8_r10.c : Regenerated. * minloc1_8_r16.c : Regenerated. * minloc1_8_r4.c : Regenerated. * minloc1_8_r8.c : Regenerated. * maxloc0_16_i16.c : Regenerated. * maxloc0_16_i4.c : Regenerated. * maxloc0_16_i8.c : Regenerated. * maxloc0_16_r10.c : Regenerated. * maxloc0_16_r16.c : Regenerated. * maxloc0_16_r4.c : Regenerated. * maxloc0_16_r8.c : Regenerated. * maxloc0_4_i16.c : Regenerated. * maxloc0_4_i4.c : Regenerated. * maxloc0_4_i8.c : Regenerated. * maxloc0_4_r10.c : Regenerated. * maxloc0_4_r16.c : Regenerated. * maxloc0_4_r4.c : Regenerated. * maxloc0_4_r8.c : Regenerated. * maxloc0_8_i16.c : Regenerated. * maxloc0_8_i4.c : Regenerated. * maxloc0_8_i8.c : Regenerated. * maxloc0_8_r10.c : Regenerated. * maxloc0_8_r16.c : Regenerated. * maxloc0_8_r4.c : Regenerated. * maxloc0_8_r8.c : Regenerated. * maxloc1_16_i16.c : Regenerated. * maxloc1_16_i4.c : Regenerated. * maxloc1_16_i8.c : Regenerated. * maxloc1_16_r10.c : Regenerated. * maxloc1_16_r16.c : Regenerated. * maxloc1_16_r4.c : Regenerated. * maxloc1_16_r8.c : Regenerated. * maxloc1_4_i16.c : Regenerated. * maxloc1_4_i4.c : Regenerated. * maxloc1_4_i8.c : Regenerated. * maxloc1_4_r10.c : Regenerated. * maxloc1_4_r16.c : Regenerated. * maxloc1_4_r4.c : Regenerated. * maxloc1_4_r8.c : Regenerated. * maxloc1_8_i16.c : Regenerated. * maxloc1_8_i4.c : Regenerated. * maxloc1_8_i8.c : Regenerated. * maxloc1_8_r10.c : Regenerated. * maxloc1_8_r16.c : Regenerated. * maxloc1_8_r4.c : Regenerated. * maxloc1_8_r8.c : Regenerated. * maxval_i16.c : Regenerated. * maxval_i4.c : Regenerated. * maxval_i8.c : Regenerated. * maxval_r10.c : Regenerated. * maxval_r16.c : Regenerated. * maxval_r4.c : Regenerated. * maxval_r8.c : Regenerated. * minval_i16.c : Regenerated. * minval_i4.c : Regenerated. * minval_i8.c : Regenerated. * minval_r10.c : Regenerated. * minval_r16.c : Regenerated. * minval_r4.c : Regenerated. * minval_r8.c : Regenerated. * sum_c10.c : Regenerated. * sum_c16.c : Regenerated. * sum_c4.c : Regenerated. * sum_c8.c : Regenerated. * sum_i16.c : Regenerated. * sum_i4.c : Regenerated. * sum_i8.c : Rege
[Bug fortran/20935] failed assertion for maxloc(n, mask=.true.)
--- Comment #8 from tkoenig at gcc dot gnu dot org 2006-03-27 20:05 --- Subject: Bug 20935 Author: tkoenig Date: Mon Mar 27 20:05:24 2006 New Revision: 112425 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112425 Log: 2006-03-27 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/20935 Backport from mainline * m4/iforeach.m4: Add SCALAR_FOREACH_FUNCTION macro. * m4/ifunction.m4: Add SCALAR_ARRAY_FUNCTION macro. * m4/minloc0.m4: Use SCALAR_FOREACH_FUNCTION. * m4/minloc1.m4: Use SCALAR_ARRAY_FUNCTION. * m4/maxloc0.m4: Use SCALAR_FOREACH_FUNCTION. * m4/maxloc1.m4: Use SCALAR_ARRAY_FUNCTION. * m4/minval.m4: Likewise. * m4/maxval.m4: Likewise. * m4/product.m4: Likewise. * m4/sum.m4: Likewise. * minloc0_16_i16.c : Regenerated. * minloc0_16_i4.c : Regenerated. * minloc0_16_i8.c : Regenerated. * minloc0_16_r10.c : Regenerated. * minloc0_16_r16.c : Regenerated. * minloc0_16_r4.c : Regenerated. * minloc0_16_r8.c : Regenerated. * minloc0_4_i16.c : Regenerated. * minloc0_4_i4.c : Regenerated. * minloc0_4_i8.c : Regenerated. * minloc0_4_r10.c : Regenerated. * minloc0_4_r16.c : Regenerated. * minloc0_4_r4.c : Regenerated. * minloc0_4_r8.c : Regenerated. * minloc0_8_i16.c : Regenerated. * minloc0_8_i4.c : Regenerated. * minloc0_8_i8.c : Regenerated. * minloc0_8_r10.c : Regenerated. * minloc0_8_r16.c : Regenerated. * minloc0_8_r4.c : Regenerated. * minloc0_8_r8.c : Regenerated. * minloc1_16_i16.c : Regenerated. * minloc1_16_i4.c : Regenerated. * minloc1_16_i8.c : Regenerated. * minloc1_16_r10.c : Regenerated. * minloc1_16_r16.c : Regenerated. * minloc1_16_r4.c : Regenerated. * minloc1_16_r8.c : Regenerated. * minloc1_4_i16.c : Regenerated. * minloc1_4_i4.c : Regenerated. * minloc1_4_i8.c : Regenerated. * minloc1_4_r10.c : Regenerated. * minloc1_4_r16.c : Regenerated. * minloc1_4_r4.c : Regenerated. * minloc1_4_r8.c : Regenerated. * minloc1_8_i16.c : Regenerated. * minloc1_8_i4.c : Regenerated. * minloc1_8_i8.c : Regenerated. * minloc1_8_r10.c : Regenerated. * minloc1_8_r16.c : Regenerated. * minloc1_8_r4.c : Regenerated. * minloc1_8_r8.c : Regenerated. * maxloc0_16_i16.c : Regenerated. * maxloc0_16_i4.c : Regenerated. * maxloc0_16_i8.c : Regenerated. * maxloc0_16_r10.c : Regenerated. * maxloc0_16_r16.c : Regenerated. * maxloc0_16_r4.c : Regenerated. * maxloc0_16_r8.c : Regenerated. * maxloc0_4_i16.c : Regenerated. * maxloc0_4_i4.c : Regenerated. * maxloc0_4_i8.c : Regenerated. * maxloc0_4_r10.c : Regenerated. * maxloc0_4_r16.c : Regenerated. * maxloc0_4_r4.c : Regenerated. * maxloc0_4_r8.c : Regenerated. * maxloc0_8_i16.c : Regenerated. * maxloc0_8_i4.c : Regenerated. * maxloc0_8_i8.c : Regenerated. * maxloc0_8_r10.c : Regenerated. * maxloc0_8_r16.c : Regenerated. * maxloc0_8_r4.c : Regenerated. * maxloc0_8_r8.c : Regenerated. * maxloc1_16_i16.c : Regenerated. * maxloc1_16_i4.c : Regenerated. * maxloc1_16_i8.c : Regenerated. * maxloc1_16_r10.c : Regenerated. * maxloc1_16_r16.c : Regenerated. * maxloc1_16_r4.c : Regenerated. * maxloc1_16_r8.c : Regenerated. * maxloc1_4_i16.c : Regenerated. * maxloc1_4_i4.c : Regenerated. * maxloc1_4_i8.c : Regenerated. * maxloc1_4_r10.c : Regenerated. * maxloc1_4_r16.c : Regenerated. * maxloc1_4_r4.c : Regenerated. * maxloc1_4_r8.c : Regenerated. * maxloc1_8_i16.c : Regenerated. * maxloc1_8_i4.c : Regenerated. * maxloc1_8_i8.c : Regenerated. * maxloc1_8_r10.c : Regenerated. * maxloc1_8_r16.c : Regenerated. * maxloc1_8_r4.c : Regenerated. * maxloc1_8_r8.c : Regenerated. * maxval_i16.c : Regenerated. * maxval_i4.c : Regenerated. * maxval_i8.c : Regenerated. * maxval_r10.c : Regenerated. * maxval_r16.c : Regenerated. * maxval_r4.c : Regenerated. * maxval_r8.c : Regenerated. * minval_i16.c : Regenerated. * minval_i4.c : Regenerated. * minval_i8.c : Regenerated. * minval_r10.c : Regenerated. * minval_r16.c : Regenerated. * minval_r4.c : Regenerated. * minval_r8.c : Regenerated. * sum_c10.c : Regenerated. * sum_c16.c : Regenerated. * sum_c4.c : Regenerated. * sum_c8.c : Regenerated. * sum_i16.c : Regenerated. * sum_i4.c : Regenerated. * sum_i8.c : Rege
[Bug tree-optimization/26797] [4.2 Regression] ACATS c35507m cd2a23e cxh1001 failures
--- Comment #6 from laurent at guerby dot net 2006-03-27 20:12 ---
c35507m tests an enumeration with representation clause in Ada, here the enum
has two values, one assigned the representation 4 ('a') and the other the
representation 5 (b)
At one point the test asks what's the enum value associated with 2, in Ada an
exception must be raised so the front-end inserts a few convertions as shown by
gcc -c -gnatdg :
before FE expansion:
IF CHAR'VAL (IDENT_INT(2)) = B THEN
FAILED ( "NO EXCEPTION RAISED FOR " &
"CHAR'VAL (IDENT_INT(2)) - 1" );
ELSE
FAILED ( "NO EXCEPTION RAISED FOR " &
"CHAR'VAL (IDENT_INT(2)) - 2" );
END IF;
after:
function c35507m__charRP (A : c35507m__char; F : boolean) return
integer is
begin
if system__unsigned_types__unsigned!(A) in 4 .. 5 then
return integer(system__unsigned_types__unsigned!(A) - 4);
else
[constraint_error when F "invalid data"]
return -1;
end if;
end c35507m__charRP;
]
B_4 : begin
if c35507m__char!(4 + c35507m__charRP (c35507m__char!(4 + {
report__ident_int (2)}), true)) = b then
report__failed (
"NO EXCEPTION RAISED FOR CHAR'VAL (IDENT_INT(2)) - 1");
else
report__failed (
"NO EXCEPTION RAISED FOR CHAR'VAL (IDENT_INT(2)) - 2");
end if;
I don't know how it goes through gigi and the BE but the check
system__unsigned_types__unsigned!(A) in 4 .. 5
must not go away. May be the front-end is wrong in using function c35507m__char
as input type for the parameter though.
Richard?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug fortran/26889] libfortran build fails with: object requires TLS, but TLS failed to initialize
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-03-27 20:15 --- Very likely a GMP/MFPR problem, try to disable TLS support in the library. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug tree-optimization/26797] [4.2 Regression] ACATS c35507m cd2a23e cxh1001 failures
--- Comment #7 from law at redhat dot com 2006-03-27 20:31 --- Subject: Re: [4.2 Regression] ACATS c35507m cd2a23e cxh1001 failures On Mon, 2006-03-27 at 20:12 +, laurent at guerby dot net wrote: > > I don't know how it goes through gigi and the BE but the check > > system__unsigned_types__unsigned!(A) in 4 .. 5 > > must not go away. May be the front-end is wrong in using function > c35507m__char > as input type for the parameter though. And this is the heart of why I'm not a fan of Ada's type representation. We have an object, A with a defined type which only allows the values 4 & 5. However, we have a program which effectively demands that we put the value 3 into A. VRP is doing exactly what it should be doing with the code it's being presented. Ada needs to either pass A in a different type, or use some other kind of conversion mechanism which doesn't allow VRP to propagate range information from the parameter. I've never looked closely, but VIEW_CONVERT_EXPR may be what you want rather than a NOP_EXPR or CONVERT_EXPR. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug libstdc++/26733] move semantics vs. debug mode
--- Comment #5 from paolo at gcc dot gnu dot org 2006-03-27 20:33 --- Subject: Bug 26733 Author: paolo Date: Mon Mar 27 20:33:41 2006 New Revision: 112426 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112426 Log: 2006-03-27 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/26733 * include/bits/basic_string.h (operator[]): Commit for real 2005-05-19 mainline change, lost in a merge. * include/debug/deque (deque<>::deque(__gnu_cxx::__rvalref<>), deque<>::operator=(__gnu_cxx::__rvalref<>)): Add (struct __is_moveable >): Add. * include/debug/list (list<>::list(__gnu_cxx::__rvalref<>), list<>::operator=(__gnu_cxx::__rvalref<>)): Add (struct __is_moveable >): Add. * include/debug/map.h (map<>::map(__gnu_cxx::__rvalref<>), map<>::operator=(__gnu_cxx::__rvalref<>)): Add. (struct __is_moveable >): Add. * include/debug/multimap.h (multimap<>::multimap(__gnu_cxx:: __rvalref<>), multimap<>::operator=(__gnu_cxx::__rvalref<>)): Add. (struct __is_moveable >): Add. * include/debug/multiset.h (multiset<>::multiset(__gnu_cxx:: __rvalref<>), multiset<>::operator=(__gnu_cxx::__rvalref<>)): Add (struct __is_moveable >): Add. * include/debug/set.h (set<>::set(__gnu_cxx::__rvalref<>), set<>::operator=(__gnu_cxx::__rvalref<>)): Add. (struct __is_moveable >): Add. * include/debug/vector (vector<>::vector(__gnu_cxx:: __rvalref<>), vector<>::operator=(__gnu_cxx::__rvalref<>)): Add (struct __is_moveable >): Add. * testsuite/23_containers/deque/resize/moveable.cc: In debug mode allow for one additional copy for each resize, due to the by value second argument. * testsuite/23_containers/vector/resize/moveable.cc: Likewise. Modified: branches/libstdcxx_so_7-branch/libstdc++-v3/ChangeLog.libstdcxx_so_7-branch branches/libstdcxx_so_7-branch/libstdc++-v3/include/bits/basic_string.h branches/libstdcxx_so_7-branch/libstdc++-v3/include/debug/deque branches/libstdcxx_so_7-branch/libstdc++-v3/include/debug/list branches/libstdcxx_so_7-branch/libstdc++-v3/include/debug/map.h branches/libstdcxx_so_7-branch/libstdc++-v3/include/debug/multimap.h branches/libstdcxx_so_7-branch/libstdc++-v3/include/debug/multiset.h branches/libstdcxx_so_7-branch/libstdc++-v3/include/debug/set.h branches/libstdcxx_so_7-branch/libstdc++-v3/include/debug/vector branches/libstdcxx_so_7-branch/libstdc++-v3/testsuite/23_containers/deque/resize/moveable.cc branches/libstdcxx_so_7-branch/libstdc++-v3/testsuite/23_containers/vector/resize/moveable.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26733
[Bug libstdc++/26733] move semantics vs. debug mode
--- Comment #6 from pcarlini at suse dot de 2006-03-27 20:35 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26733
[Bug fortran/26889] libfortran build fails with: object requires TLS, but TLS failed to initialize
--- Comment #4 from quanah at stanford dot edu 2006-03-27 20:48 --- Disable TLS support in *which* library? GMP, MPFR, or libfortran? There are no options in the configure for GMP or MPFR referring to TLS/SSL. --Quanah -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug target/19087] Overflowed address in dwarf debug line information
--- Comment #20 from j at uriah dot heep dot sax dot de 2006-03-27 20:53
---
I suggest that this change should be accompanied by another indication in
the output that tells the ELF/DWARF-2 consumer about the changed pointer
size. Otherwise the consumer will experience "funny" behaviour.
While there are many ELF fields available that are otherwise unused on
this architecture (like the OS or ABI fields), there doesn't seem to exist
any practical way to modify their contents through the assembler/linker
interface. Thus, and after checking other GCC code like the section
".note.GNU-stack" suggested at the end of varasm.c, I think adding something
like
named_section_flags (".note.DWARF2-32", SECTION_DEBUG);
to function avr_file_end() in gcc/config/avr/avr.c appears to be a suitable
way to me to flag this information to the potential consumer.
--
j at uriah dot heep dot sax dot de changed:
What|Removed |Added
CC||j at uriah dot heep dot sax
||dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087
[Bug fortran/26889] libfortran build fails with: object requires TLS, but TLS failed to initialize
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2006-03-27 21:00 --- > Disable TLS support in *which* library? GMP/MPFR. > There are no options in the configure for GMP or MPFR referring to TLS/SSL. Did you build gcc-4.0.2 with Fortran support? If so, could you try building 4.0.3 with the same version of GMP/MPFR as with 4.0.2? In the meantime, I'll try to reproduce the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug java/26042] ICE in mark_reference_fields, at java/boehm.c:105
--- Comment #7 from tromey at gcc dot gnu dot org 2006-03-27 22:03 --- I was able to reproduce this with svn head on a ppc32 build. A ppc64 build did not show this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26042
[Bug fortran/26889] libfortran build fails with: object requires TLS, but TLS failed to initialize
--- Comment #6 from quanah at stanford dot edu 2006-03-27 22:09 --- I don't see a way to disable "TLS" support in GMP or MPFR, but I'll keep poking. I didn't build gcc 4.0.2 with Fortran support because I needed to build gcc to build GMP and MPFR. ;) Building gcc 4.0.1 also fails for me, but with an entirely different error and location. I'll open a separate bug on that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug libfortran/26893] New: kinds.h not generated, causing failure
In building gcc 4.1.0, I get the following error: config.status: executing gstdint.h commands config.status: executing gstdint.h commands make[2]: Entering directory `/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_59/sparc-sun-solaris2.9/libgfortran' /bin/sh ../../../../gcc-4.1.0/libgfortran/mk-sik-inc.sh '/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_59/./gcc/gfortran -B/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_59/./gcc/ -B/usr/pubsw/sparc-sun-solaris2.9/bin/ -B/usr/pubsw/sparc-sun-solaris2.9/lib/ -isystem /usr/pubsw/sparc-sun-solaris2.9/include -isystem /usr/pubsw/sparc-sun-solaris2.9/sys-include -I . -Wall -fno-repack-arrays -fno-underscoring ' > selected_int_kind.inc || rm selected_int_kind.inc /bin/sh ../../../../gcc-4.1.0/libgfortran/mk-srk-inc.sh '/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_59/./gcc/gfortran -B/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_59/./gcc/ -B/usr/pubsw/sparc-sun-solaris2.9/bin/ -B/usr/pubsw/sparc-sun-solaris2.9/lib/ -isystem /usr/pubsw/sparc-sun-solaris2.9/include -isystem /usr/pubsw/sparc-sun-solaris2.9/sys-include -I . -Wall -fno-repack-arrays -fno-underscoring ' > selected_real_kind.inc || rm selected_real_kind.inc /bin/sh ../../../../gcc-4.1.0/libgfortran/mk-kinds-h.sh '/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_59/./gcc/gfortran -B/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_59/./gcc/ -B/usr/pubsw/sparc-sun-solaris2.9/bin/ -B/usr/pubsw/sparc-sun-solaris2.9/lib/ -isystem /usr/pubsw/sparc-sun-solaris2.9/include -isystem /usr/pubsw/sparc-sun-solaris2.9/sys-include -I . -Wall -fno-repack-arrays -fno-underscoring ' > kinds.h || rm kinds.h ../../../../gcc-4.1.0/libgfortran/mk-kinds-h.sh: Unknown type grep '^#' < kinds.h > kinds.inc /bin/sh: kinds.h: cannot open make[2]: *** [kinds.inc] Error 1 make[2]: Leaving directory `/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_59/sparc-sun-solaris2.9/libgfortran' make[1]: *** [all-target-libgfortran] Error 2 make[1]: Leaving directory `/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_59' make: *** [all] Error 2 -- Summary: kinds.h not generated, causing failure Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: quanah at stanford dot edu GCC build triplet: sparc-sun-solaris2.9 GCC host triplet: sparc-sun-solaris2.9 GCC target triplet: sparc-sun-solaris2.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26893
[Bug fortran/26889] libfortran build fails with: object requires TLS, but TLS failed to initialize
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2006-03-27 22:19 --- > I didn't build gcc 4.0.2 with Fortran support because I needed to build gcc to > build GMP and MPFR. ;) Of course. :-) I just rebuild 4.0.3 with 4.0.2 on SPARC/Solaris 8: gax% CC=gcc40 /home/eric/svn/gcc-4_0-branch/configure --prefix=/opt/build/eric/local/gcc-4_0-branch --with-gmp=/opt/build/eric/local --with-mpfr=/opt/build/eric/local --with-local-prefix=/opt/build/eric/local --enable-languages=c,f95 gax% gcc/xgcc -v Using built-in specs. Target: sparc-sun-solaris2.8 Configured with: /home/eric/svn/gcc-4_0-branch/configure --prefix=/opt/build/eric/local/gcc-4_0-branch --with-gmp=/opt/build/eric/local --with-mpfr=/opt/build/eric/local --with-local-prefix=/opt/build/eric/local --enable-languages=c,f95 Thread model: posix gcc version 4.0.3 > Building gcc 4.0.1 also fails for me, but with an entirely different error and > location. I'll open a separate bug on that. Really weird. GCC 4.0.x is known to build without a hitch on SPARC/Solaris. Please specify the exact configure line and the exact make line. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug libfortran/26893] kinds.h not generated, causing failure
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-03-27 22:22 --- /bin/sh is not supported on SPARC/Solaris. Please read the instructions at: http://gcc.gnu.org/install/specific.html#x-x-solaris2 -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26893
[Bug fortran/26889] libfortran build fails with: object requires TLS, but TLS failed to initialize
--- Comment #8 from quanah at stanford dot edu 2006-03-27 22:27 --- sorry, I meant 4.1.0, and you answered that well enough. ;) *how* do I build gmp/mpfr without TLS? I don't see any configure options that make sense for this... I'll note that GMP was built with ABI=32 in my case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug libfortran/26893] kinds.h not generated, causing failure
--- Comment #2 from quanah at stanford dot edu 2006-03-27 22:28 --- ah, thanks. Never hit that issue with any gcc release until now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26893
[Bug fortran/26889] libfortran build fails with: object requires TLS, but TLS failed to initialize
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2006-03-27 22:32 --- > I'll note that GMP was built with ABI=32 in my case. I'd recommend to configure it as specified in the instructions: http://gcc.gnu.org/install/specific.html#sparc-sun-solaris2 And you also need to make sure the resulting library is visible from the dynamic linker, i.e. 'ldd f951' should not have unresolved references. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug tree-optimization/26763] [4.1 Regression] wrong final value of induction variable calculated
--- Comment #3 from rakdver at gcc dot gnu dot org 2006-03-27 22:33 --- (gdb) call debug_generic_stmt (ret) startD.1278_2 + -3B > startD.1278_2 + 396B; (gdb) call debug_generic_stmt (fold (ret)) 1 I guess the reasoning of fold is: it is pointer arithmetics, so it does not wrap. (-3B) = (0xfff...7) > 396B, so the result is always true. 4.0 does not have final value replacement, and 4.2 has different # of iterations analysis; but most likely some similar problem is latent in both versions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26763
[Bug target/26734] [4.2 Regression] GCC cannot bootstrap on IA64 HP-UX
--- Comment #9 from mkuvyrkov at gcc dot gnu dot org 2006-03-27 23:04 --- The patch for this bug is: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01589.html -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26734
[Bug java/26042] ICE in mark_reference_fields, at java/boehm.c:105
--- Comment #8 from tromey at gcc dot gnu dot org 2006-03-28 01:14 --- One curiosity I noticed while debugging is that in layout_type, class Two has size 128 (in bits). This value is incorrect. Once we reach the code to compute the GC descriptor, the size is 192. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26042
[Bug c/26894] New: On a 64 bit system the generated crosscompiler generates invalid assembly
Short synopsys:
---
You can not build a gcc for MCORE target on a 64-bit system. The bug is
identical for 4.0.2 and 4.1.0 versions of the gcc. The bug lies in the
actual MCORE crosscompiler; if it runs on a 64 bit system it handles
long long constants incorrectly. Minimal code to reproduce the bug
is given.
Long outputs from commands have been broken into short lines.
System (uname -a):
--
Linux linux 2.6.13-15-smp #1 SMP Tue Sep 13 14:56:15
UTC 2005 x86_64 x86_64 x86_64 GNU/Linux
Compiler (gcc -v):
--
Target: x86_64-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,f95,java,ada --disable-checking
--with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-java-awt=gtk
--disable-libjava-multilib --with-slibdir=/lib64 --with-system-zlib
--enable-shared --enable-__cxa_atexit --without-system-libunwind
--host=x86_64-suse-linux
Thread model: posix
gcc version 4.0.2 20050901 (prerelease) (SUSE Linux)
The bug:
Fresh download of gcc-4.1.0. Then:
~/GNU/gcc-mcore> ../gcc-4.1.0/configure --target=mcore-elf --with-gnu-as
--with-gnu-ld --enable-languages=c
Configure succeeds, typing make successfully builds xgcc.
It starts to build the libraries, and it fails:
/home/zoltan/GNU/gcc-mcore/./gcc/xgcc -B/home/zoltan/GNU/gcc-mcore/./gcc/
-B/usr/local/mcore-elf/bin/ -B/usr/local/mcore-elf/lib/
-isystem /usr/local/mcore-elf/include
-isystem /usr/local/mcore-elf/sys-include -O2 -O2 -g -O2
-DIN_GCC -DCROSS_COMPILE -DDONT_HAVE_STDIO -DDONT_HAVE_SETJMP
-Dinhibit_libc -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -isystem ./include
-O3 -DNO_FLOATLIB_FIXUNSDFSI -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED
-Dinhibit_libc -I. -I. -I../../gcc-4.1.0/gcc -I../../gcc-4.1.0/gcc/.
-I../../gcc-4.1.0/gcc/../include -I../../gcc-4.1.0/gcc/../libcpp/include
-DL_floatdisf -c ../../gcc-4.1.0/gcc/libgcc2.c -o libgcc/./_floatdisf.o
/tmp/ccdhETch.s: Assembler messages:
/tmp/ccdhETch.s:38: Error: operand must be absolute in range 1..32, not 53
make[3]: *** [libgcc/./_floatdisf.o] Error 1
make[3]: Leaving directory `/home/zoltan/GNU/gcc-mcore/gcc'
make[2]: *** [stmp-multilib] Error 2
make[2]: Leaving directory `/home/zoltan/GNU/gcc-mcore/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/home/zoltan/GNU/gcc-mcore'
make: *** [all] Error 2
Examining the assembler output that fails:
.file "libgcc2.c"
.section .debug_abbrev
.Ldebug_abbrev0:
.section .debug_info
.Ldebug_info0:
.section .debug_line
.Ldebug_line0:
.text
.Ltext0:
.import __floatsidf
.import __muldf3
.import __adddf3
.import __truncdfsf2
.section .rodata.cst8
.align 3
.LC0:
.long 0
.long 1106247680
.text
.align 1
.export __floatdisf
.type __floatdisf, @function
__floatdisf:
.LFB2:
.LM1:
.LVL0:
subisp,32
stw r15,(sp)
stw r13,(sp,4)
stw r12,(sp,8)
stw r11,(sp,12)
stw r10,(sp,16)
stw r9,(sp,20)
stw r8,(sp,24)
mov r12,r2
mov r13,r3
.LM2:
bmaski r4,53 <- THIS IS THE ERRONEOUS INSN
movir5,0
cmplt r4,r4
addcr4,r2
addcr5,r3
bmaski r7,22 // 4194303 0x3f
and so on
The C code in the library (libgcc2.c), which actually gets compiled,
looks like this:
if (DF_SIZE < DI_SIZE
&& DF_SIZE > (DI_SIZE - DF_SIZE + SF_SIZE))
{
if (! (- ((DWtype) 1 << DF_SIZE) < u
&& u < ((DWtype) 1 << DF_SIZE)))
{
if ((UDWtype) u & (REP_BIT - 1))
{
u &= ~ (REP_BIT - 1);
u |= REP_BIT;
}
}
}
After running through the preprocessor ( with xgcc -E ) the actual C code looks
like this:
#pragma GCC visibility pop
# 44 "../../gcc-4.1.0/gcc/libgcc2.c" 2
# 1352 "../../gcc-4.1.0/gcc/libgcc2.c"
SFtype
__floatdisf (DItype u)
{
# 1378 "../../gcc-4.1.0/gcc/libgcc2.c"
if (53 < ((4 * 8) * 2)
&& 53 > (((4 * 8) * 2) - 53 + 24))
{
if (! (- ((DItype) 1 << 53) < u /* THIS GENERATES THE ERROR */
&& u < ((DItype) 1 << 53)))
{
if ((UDItype) u & (((UDItype) 1 << (((4 * 8) * 2) - 53)) - 1))
{
u &= ~ (((UDItype) 1 << (((4 * 8) * 2) - 53)) - 1);
u |= ((UDItype) 1 << (((4 * 8) * 2) - 53));
}
}
Further examination reveals a bug in xgcc itself, the following very short
code fragment generates the erroneous assembly insn:
long long XgccBug( long long a )
{
return( a & 0x1LL );
}
results in the following (erroneous) assembly code:
[Bug libfortran/26890] SIZE parameter interacts with same variable in IO list character length specification.
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-03-28 01:43 --- I will look into this if you would like. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26890
[Bug c++/26886] missing warning for no return statement in function returning non-void
--- Comment #1 from bangerth at dealii dot org 2006-03-28 01:49 ---
It warns whenever foo:test1 is first compiled (i.e. on first use). If, for
example, you add this code
--
int main ()
{
foo f;
return f.test1();
}
--
then you get the warning you are expecting:
g/x> c++ -Wreturn-type -c x.cc
x.cc: In function `int test2()':
x.cc:17: warning: control reaches end of non-void function
x.cc: In member function `int foo::test1()':
x.cc:10: warning: control reaches end of non-void function
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC||bangerth at dealii dot org
Status|UNCONFIRMED |RESOLVED
Resolution||WONTFIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26886
[Bug fortran/26889] libfortran build fails with: object requires TLS, but TLS failed to initialize
--- Comment #10 from quanah at stanford dot edu 2006-03-28 01:59 --- I rebuilt gmp with: --build=sparc-sun-solaris2.8 and then rebuilt MPFR, and then rebuilt gcc 4.0.3. On Solaris 8, it is still dying, with: /afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_58/gcc/gfortran -B/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_58/gcc/ -B/usr/pubsw/sparc-sun-solaris2.8/bin/ -B/usr/pubsw/sparc-sun-solaris2.8/lib/ -isystem /usr/pubsw/sparc-sun-solaris2.8/include -isystem /usr/pubsw/sparc-sun-solaris2.8/sys-include -I . -Wall -fno-repack-arrays -fno-underscoring -c ../../../../gcc-4.0.3/libgfortran/intrinsics/selected_int_kind.f90 -fPIC -DPIC -o .libs/selected_int_kind.o :0: internal compiler error: Segmentation Fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[2]: *** [selected_int_kind.lo] Error 1 make[2]: Leaving directory `/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_58/sparc-sun-solaris2.8/libgfortran' make[1]: *** [all] Error 2 make[1]: Leaving directory `/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_58/sparc-sun-solaris2.8/libgfortran' make: *** [all-target-libgfortran] Error 2 ldd shows no issues with f951 or gfortran: solaris8-build:/afs/ir/src/pubsw/languages/gcc-4.0.3> ldd ../gcc-build/sun4x_58/gcc/gfortran libintl.so.3 => /usr/pubsw/lib/libintl.so.3 libiconv.so.2 => /usr/pubsw/lib/libiconv.so.2 libc.so.1 => /usr/lib/libc.so.1 libgcc_s.so.1 => /usr/pubsw/lib/libgcc_s.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 /usr/platform/SUNW,UltraAX-i2/lib/libc_psr.so.1 solaris8-build:/afs/ir/src/pubsw/languages/gcc-4.0.3> ldd ../gcc-build/sun4x_58/gcc/f951 libgmp.so.3 => /usr/pubsw/lib/libgmp.so.3 libintl.so.3 => /usr/pubsw/lib/libintl.so.3 libiconv.so.2 => /usr/pubsw/lib/libiconv.so.2 libc.so.1 => /usr/lib/libc.so.1 libgcc_s.so.1 => /usr/pubsw/lib/libgcc_s.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 /usr/platform/SUNW,UltraAX-i2/lib/libc_psr.so.1 I'm guessing Solaris 9 will still fail, too. It just hasn't gotten as far as Solaris 8 yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug target/26894] On a 64 bit system the generated crosscompiler generates invalid assembly
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26894
[Bug pch/26895] New: Bug mangling function name inside unnamed namespace, with pch
There seems to be a bug in the name mangling of a function inside a unnamed
namespace (using g++ 4.1.0), when the compilation unit uses a precompiled
header which contains another unnamed namespace. This is better demonstrated
with the following setup:
pch.h:
namespace { void inside_pch(){} }
test1.cpp:
#include "pch.h"
namespace { void test(){} }
int main() {}
test2.cpp:
#include "pch.h"
namespace { void test(){} }
Showing the bug:
g++ pch.h
g++ -o test1.o -c test1.cpp
g++ -o test2.o -c test2.cpp
g++ -o test test1.o test2.o
test2.o: In function `(anonymous namespace)::inside_pch()':
test2.cpp:(.text+0x0): multiple definition of `(anonymous
namespace)::inside_pch()'
test1.o:test1.cpp:(.text+0x0): first defined here
test2.o: In function `(anonymous namespace)::test()':
test2.cpp:(.text+0x6): multiple definition of `(anonymous namespace)::test()'
test1.o:test1.cpp:(.text+0x6): first defined here
collect2: ld returned 1 exit status
nm test1.o shows:
U __gxx_personality_v0
000c T main
T _ZN34_GLOBAL__N_pch.h__ECAA0BAE10inside_pchEv
0006 T _ZN34_GLOBAL__N_pch.h__ECAA0BAE4testEv
nm test2.o shows:
U __gxx_personality_v0
T _ZN34_GLOBAL__N_pch.h__ECAA0BAE10inside_pchEv
0006 T _ZN34_GLOBAL__N_pch.h__ECAA0BAE4testEv
While the incorrect mangling of unnamed namespace inside a pch is a
longstanding bug, function test, both in test1.cpp and test2.cpp used to be
mangled correctly, at least with g++ 3.4.5.
Doing the same with g++ 3.4.5, we have as result the following error message:
test2.o: In function `(anonymous namespace)::inside_pch()':
test2.cpp:(.text+0x0): multiple definition of `(anonymous
namespace)::inside_pch()'
test1.o:test1.cpp:(.text+0x0): first defined here
collect2: ld returned 1 exit status
This time, nm test1.o returns:
000c T main
T _ZN34_GLOBAL__N_pch.h__7F4453F410inside_pchEv
0006 T _ZN38_GLOBAL__N_test1.cpp__6EC548D94testEv
and nm test2.o
T _ZN34_GLOBAL__N_pch.h__7F4453F410inside_pchEv
0006 T _ZN38_GLOBAL__N_test2.cpp__D5E9623F4testEv:
I hope this information helps.
--
Summary: Bug mangling function name inside unnamed namespace,
with pch
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: pch
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rodolfo at rodsoft dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26895
[Bug pch/26895] Bug mangling function name inside unnamed namespace, with pch
--- Comment #1 from rodolfo at rodsoft dot org 2006-03-28 02:44 --- There's an extra colon, which is a typo. The line that reads 0006 T _ZN38_GLOBAL__N_test2.cpp__D5E9623F4testEv: Should be 0006 T _ZN38_GLOBAL__N_test2.cpp__D5E9623F4testEv Sorry for the inconvenience. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26895
[Bug pch/26895] Bug mangling function name inside unnamed namespace, with pch
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-28 03:06 --- The summary on PR 10591 is wrong (but I am not going to change it back). *** This bug has been marked as a duplicate of 10591 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26895
[Bug c++/10591] use ODR rules to make C++ objects not be TREE_PUBLIC
--- Comment #21 from pinskia at gcc dot gnu dot org 2006-03-28 03:06 --- *** Bug 26895 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10591
[Bug tree-optimization/26797] [4.2 Regression] ACATS c35507m cd2a23e cxh1001 failures
--- Comment #8 from kenner at vlsi1 dot ultra dot nyu dot edu 2006-03-28 03:56 --- Subject: Re: [4.2 Regression] ACATS c35507m cd2a23e cxh1001 failures I don't know how it goes through gigi and the BE but the check system__unsigned_types__unsigned!(A) in 4 .. 5 must not go away. May be the front-end is wrong in using function c35507m__char as input type for the parameter though. Looks like the same bug that Gigi doesn't currently use VIEW_CONVERT_EXPR for this type of Unchecked_Conversion. So already on my plate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug libfortran/26890] SIZE parameter interacts with same variable in IO list character length specification.
--- Comment #2 from paulthomas2 at wanadoo dot fr 2006-03-28 04:08 --- Subject: Re: SIZE parameter interacts with same variable in IO list character length specification. jvdelisle at gcc dot gnu dot org wrote: >--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-03-28 01:43 >--- >I will look into this if you would like. > > Yes, indeed - you are the expert, which was why I CC'd you All the best, Paul PS I suppose that the library zeros the variable pointed too by SIZE. This then leads to the calculation that the destination has zero length and that nothing should be read? I guess a copy of SIZE is needed to work with an that it should be written back on exiting the library? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26890
[Bug middle-end/22524] fold (or the front-ends) produces UNARY (BIT_NOT_EXPR) tree with mismatch types
--- Comment #6 from sayle at gcc dot gnu dot org 2006-03-28 05:01 --- Subject: Bug 22524 Author: sayle Date: Tue Mar 28 05:01:27 2006 New Revision: 112438 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112438 Log: PR middle-end/22524 * fold-const.c (fold_binary) : Call fold_convert to cast BIT_NOT_EXPR operand to the correct type. Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22524
[Bug fortran/26889] libfortran build fails with: object requires TLS, but TLS failed to initialize
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2006-03-28 06:33 --- > I rebuilt gmp with: > > --build=sparc-sun-solaris2.8 > > and then rebuilt MPFR, and then rebuilt gcc 4.0.3. On Solaris 8, it is still > dying, with: Please post the exact configure line and command line. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug fortran/26889] libfortran build fails with: object requires TLS, but TLS failed to initialize
--- Comment #12 from quanah at stanford dot edu 2006-03-28 07:21 ---
For GMP (4.1.4 and 4.2, I've tried both versions):
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by configure, which was
generated by GNU Autoconf 2.52. Invocation command line was
$ ../../configure --datadir=${prefix}/lib --libexecdir=${prefix}/lib
--sharedstatedir=${prefix}/lib --prefix=/usr/pubsw --build=sparc-sun-solaris2.8
For MPFR:
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by MPFR configure 2.2.0, which was
generated by GNU Autoconf 2.59. Invocation command line was
$ ../../configure --datadir=${prefix}/lib --libexecdir=${prefix}/lib
--sharedstatedir=${prefix}/lib --prefix=/usr/pubsw --enable-thread-safe
--with-gnu-ld --with-gmp=/usr/pubsw
For GCC:
# The gcc driver likes to know the arguments it was configured with.
TOPLEVEL_CONFIGURE_ARGUMENTS=../../gcc-4.0.3/configure --datadir=$${prefix}/lib
--libexecdir=$${prefix}/lib --sharedstatedir=$${prefix}/lib --prefix=/usr/pub
sw --enable-threads --with-gnu-as --with-as=/usr/pubsw/bin/as --with-gnu-ld
--with-ld=/usr/pubsw/bin/ld --with-libintl-prefix=/usr/pubsw
--with-libiconv-prefix=/usr/pubsw --enable-libada
--enable-languages=c,c++,f95,java,objc,ada
--Quanah
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug fortran/26889] libfortran build fails with: object requires TLS, but TLS failed to initialize
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2006-03-28 07:24 --- And the command line for the compiler? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug fortran/26889] libfortran build fails with: object requires TLS, but TLS failed to initialize
--- Comment #14 from quanah at stanford dot edu 2006-03-28 07:26 --- For building GCC, I execute: cd ../gcc-build/@sys && make CFLAGS='-O' \ LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' 2>&1 | tee -a makeLOG (@sys is an AFS thing, it translates to sun4x_58 or sun4x_59 in this case, depending on the OS). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug fortran/26889] libfortran build fails with: object requires TLS, but TLS failed to initialize
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2006-03-28 07:28 --- > For building GCC, I execute: > > cd ../gcc-build/@sys && make CFLAGS='-O' \ > LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' 2>&1 | tee > -a makeLOG Use 'make bootstrap' instead of 'make'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug fortran/26889] libfortran build fails with: object requires TLS, but TLS failed to initialize
--- Comment #16 from quanah at stanford dot edu 2006-03-28 07:33 --- I will try "make bootstrap", but I note: "make" worked fine with gcc-3.4.x, gcc-3.3.x, gcc-2.9x etc. And for i386 and amd64 it worked just fine, too, for gcc 4.0.3 with these same versions of GMP and MPFR to build fortran. Is this a solaris specific issue? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug fortran/26889] libfortran build fails with: object requires TLS, but TLS failed to initialize
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2006-03-28 07:46
---
> "make" worked fine with gcc-3.4.x, gcc-3.3.x, gcc-2.9x etc.
Yes, but it's wrong up to (and including) 4.1.x. We only guarantee that the
compiler correctly compiles itself ("bootstraps"), not that it is correctly
compiled by other compilers at random optimization levels.
> Is this a solaris specific issue?
No, this has always been documented:
@section Building a native compiler
For a native build issue the command @samp{make bootstrap}. This
will build the entire GCC system, which includes the following steps:
@itemize @bullet
@item
Build host tools necessary to build the compiler such as texinfo, bison,
gperf.
@item
Build target tools for use by the compiler such as binutils (bfd,
binutils, gas, gprof, ld, and opcodes)
if they have been individually linked
or moved into the top level GCC source tree before configuring.
@item
Perform a 3-stage bootstrap of the compiler.
@item
Perform a comparison test of the stage2 and stage3 compilers.
@item
Build runtime libraries using the stage3 compiler from the previous step.
@end itemize
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
