[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2005-11-12 08:17 --- > The patch from comment 14 seems to be working fine without any other changes. > I have bootstrapped and am currently running the testsuite. Looks OK so far. Zack's patch for 4.x doesn't work as-is for 3.4.x because the multilib logic has changed in mklibgcc.in. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug libstdc++/24712] [4.0 Regression] Accidental ABI change between 4.0.1 and 4.0.2?
--- Comment #6 from debian-gcc at lists dot debian dot org 2005-11-12 09:33 --- (In reply to comment #2) > I gather therefore that Debian > is building GCC passing --enable-libstdcxx-allocator=mt, something absolutely > not obvious and not trivial in its consequences. Correct. That decision was based on a discussion on libstdc++ in April 2004. Please see http://gcc.gnu.org/ml/libstdc++/2005-11/msg00171.html for an open question. Matthias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24712
[Bug java/24572] [4.0 regression] ICE in gimplify_expr, at gimplify.c:3983
--- Comment #4 from debian-gcc at lists dot debian dot org 2005-11-12 09:35 --- works with HEAD 2005 -- debian-gcc at lists dot debian dot org changed: What|Removed |Added Keywords||ice-on-valid-code Known to fail||4.0.3 Known to work||4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24572
[Bug libstdc++/24800] tr1::mem_fn returns a function object that does not inherit from std::unary_function/binary_function
--- Comment #3 from pcarlini at suse dot de 2005-11-12 11:27 --- (In reply to comment #2) > As for the original bug report: it's easy to verify by inspecting the source > that _Mem_fn has no base class as required. I beg to disagree. Have you really checked the actual versions of it for member function taking no argument and taking one argument? If I do that in the straightforward way, that is looking at the -E output, the expected bases are there. In other terms, functional_iterate.h looks fine to me. > Hope this gives you what you need. Well, to date, not really, to be honest. I would appreciate a decently sized testcase (eventually, what are we going to put in the testsuite, otherwise?!?) or at least reaching a minimum of consensus about the matter by looking at the sources... Thanks in advance for your help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24800
[Bug libstdc++/24800] tr1::mem_fn returns a function object that does not inherit from std::unary_function/binary_function
--- Comment #4 from doug dot gregor at gmail dot com 2005-11-12 11:33 --- This is not a bug. TR1 3.5 refers to member function pointers, not member data pointers as in the submitted test case. mem_fn has no result_type for member data pointers because the constness of the result type depends on the constness of the argument type; use result_of to get the appropriate result type given the argument type. See also TR1 DR 10.24 "Mem_fn result_type for pointer to data member". -- doug dot gregor at gmail dot com changed: What|Removed |Added CC||doug dot gregor at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24800
[Bug target/24743] NaN or correct result after divrp with 3 FPU registers
--- Comment #3 from sraa at kse dot nl 2005-11-12 12:07 --- We found out that the stackpointer was unbalanced at a given point. Via a small program in assembly wich reads the stackpointer that I placed at suspicious points in the code I found a function that didn't restore the stackpointer correctly. This function was of type float and returned a float but this result was not assigned to any variable... So this has to be it. I know this for sure on monday since the production has stopped now and I cannot test it. Example of the false code: partijlocmut_kg(geleverd1); /* returns a float . */ Instead of: geleverd1 = partijlocmut_kg(geleverd1); So a Sun hadn't this problem because the stack is managed differently and the floating point calculations are done by the software instead of a FPU with using of the stack registers. Or has something smart or by coincidence to return the float to a register anyhow. I think it returned the value to the parameter with which the function was called. Otherwise the software wouldn't have worked. If our software was written, in ANSI-C, with correct prototyping of functions, the compiler would have been able to signal the error. Unfortunalely it isn't. But now we know how to seatch or what we have to do. The cause for my problems was not a buggy OS or compiler but just bad written code. -- sraa at kse dot nl changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24743
[Bug libstdc++/24803] tr1::reference_wrapper and pointers to member functions
--- Comment #1 from pcarlini at suse dot de 2005-11-12 12:45 --- Doug, can you look a bit into this one too? Thanks! -- pcarlini at suse dot de changed: What|Removed |Added CC||doug dot gregor at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24803
[Bug libstdc++/24803] tr1::reference_wrapper and pointers to member functions
--- Comment #2 from doug dot gregor at gmail dot com 2005-11-12 13:23
---
I don't know how to classify this. The basic problem is one that isn't
really solveable without rvalue references: you can't pass a literal
(e.g., 0) into the operator() of a reference_wrapper or any other
function object in TR1, because the arguments are accepted by
T&. Strictly speaking, this is not a bug.
However, there are several ways that we could make this work, because
John is doing some very sensible things here [*]. Some ideas are:
(1) Strong-arm a C++ front-end guru into implementing rvalue references,
then use them in the TR1 function objects. Heck, we'll need 'em
for C++0x anyway :)
(2) When we know the argument types (e.g., when the T in reference_wrapper
is a function pointer, member function pointer, or class that is derived
from unary_function or binary_function), we could inject operator()
overloads that have precise type signatures, e.g.,
T::result_type operator()(T::argument_type const&);
That's really messy and would require quite a bit of refactoring in
reference_wrapper to get right.
(3) Provide variants of operator() that accept "const T&" arguments in
addition to those that accept "T&" arguments. This makes
bind/mem_fn/reference_wrapper easier to use, but the number of overloads
blows up exponentially. Since we've already run into compilation time
issues, we'd have stop doing this once we hit four to five
arguments (then we get the "I just added one more argument and
everything blew up!" bug reports).
(4) Strong-arm a C++ front-end guru into allowing the conversion
operator (operator T&() const) to actually work for function
call expressions, making most of reference_wrapper::operator()
magically go away. (Peter Dimov has suggested this before, but
it hasn't really worked its way through the committee).
(1) is the forward-looking solution; (2) and (3) are hacks that could
make the code even uglier (ick!). (4) only fixes the problem for
reference_wrapper. At this point, I favor (1) strongly, but I'm not in
a position to strong-arm nor am I in a position to implement rvalue
references myself.
[*] One thing in the code that perhaps shouldn't work is passing the
literal 0 as the argument to
reference_wrapper::operator()
That means that we need to be able to realize that it's a literal 0
(tricky, messy, but doable; see the construction-from-literal-zero
trick in tr1::function<>) and then convert that to a NULL test_type*.
I don't think John meant to test that, and I don't really think we
should care if it's broken.
A slightly simplified version of John's test case that does work
properly follows. Replace any of null_tt, null_ttc, or zero in the
calls to reference_wrapper objects to trigger compiler errors.
#include
struct test_type
{
int member();
int cmember()const;
int member2(char);
int cmember2(char)const;
};
struct functor1 : public std::unary_function
{
double operator()(int)const;
};
struct functor2 : public std::binary_function
{
double operator()(int, char)const;
};
template
void verify_return_type(T, T)
{
}
int main()
{
test_type* null_tt = 0;
const test_type* null_ttc = 0;
int zero;
std::tr1::reference_wrapper* pr1;
verify_return_type((*pr1)(0), double());
std::tr1::reference_wrapper* pr2;
verify_return_type((*pr2)(0), double());
std::tr1::reference_wrapper* pr3;
verify_return_type((*pr3)(null_tt), int());
std::tr1::reference_wrapper* pr4;
verify_return_type((*pr4)(null_ttc), int());
std::tr1::reference_wrapper* pr5;
verify_return_type((*pr5)(zero), double());
std::tr1::reference_wrapper* pr1b;
verify_return_type((*pr1b)(0,0), double());
std::tr1::reference_wrapper* pr2b;
verify_return_type((*pr2b)(0,0), double());
std::tr1::reference_wrapper* pr3b;
verify_return_type((*pr3b)(null_tt,zero), int());
std::tr1::reference_wrapper* pr4b;
verify_return_type((*pr4b)(null_ttc), int());
std::tr1::reference_wrapper* pr5b;
verify_return_type((*pr5b)(zero,zero), double());
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24803
[Bug libstdc++/24803] tr1::reference_wrapper and pointers to member functions
--- Comment #3 from pcarlini at suse dot de 2005-11-12 13:27 --- Hi Doug. First thing to do, before actually studying your extremely useful and detailed reply (THANKS), is adding Howard in CC... -- pcarlini at suse dot de changed: What|Removed |Added CC||hhinnant at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24803
[Bug libstdc++/24818] New: tr1::reference_wrapper improperly calls nullary function objects
tr1::reference_wrapper::operator()() should not dereference get() before calling the function object, because get() returns a reference (not a pointer). -- Summary: tr1::reference_wrapper improperly calls nullary function objects Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doug dot gregor at gmail dot com 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=24818
[Bug libstdc++/24818] tr1::reference_wrapper improperly calls nullary function objects
--- Comment #1 from doug dot gregor at gmail dot com 2005-11-12 13:31 --- Created an attachment (id=10225) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10225&action=view) Mainline (4.1.0) patch to test and fix this problem The fix is trivial. The changes to the test case cause failures that are fixed by the patch to ref_wrap_iterate.h. All of the tr1/3_function_objects tests still pass on i686-pc-linux-gnu. 2005-11-12 Douglas Gregor <[EMAIL PROTECTED]> * include/tr1/ref_wrap_iterate.h (reference_wrapper::operator()()): Don't dereferene the result of get() before calling it; it's already a reference. * testsuite/tr1/3_function_objects/reference_wrapper/invoke.cc: Test nullary calls to reference_wrappers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24818
[Bug libstdc++/24818] tr1::reference_wrapper improperly calls nullary function objects
--- Comment #2 from pcarlini at suse dot de 2005-11-12 13:33 --- Thanks a lot. I will take care of applying the patch asap. -- 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 |2005-11-12 13:33:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24818
[Bug regression/24819] New: glibc math tests miscompiled with gcc-4.1
make check fails with -O2 on powerpc64-linux and powerpc-linux with gcc-4.1 Works ok with gcc-4.0, and also with 4.1 and -O1. ppc64: make[2]: *** [/usr/src/packages/BUILD/glibc-2.3/cc-nptl/math/test-float.out] Error 1 make[2]: *** [/usr/src/packages/BUILD/glibc-2.3/cc-nptl/math/test-double.out] Error 1 make[2]: *** [/usr/src/packages/BUILD/glibc-2.3/cc-nptl/math/test-ifloat.out] Error 1 make[2]: *** [/usr/src/packages/BUILD/glibc-2.3/cc-nptl/math/test-idouble.out] Error 1 make[1]: *** [math/tests] Error 2 ppc: make[2]: *** [/usr/src/packages/BUILD/glibc-2.3/cc-nptl/math/test-float.out] Error 1 make[1]: *** [math/tests] Error 2 (make check runs without -k on ppc, the failure rate might be the same as on ppc64). Will post details and possible a testcase, later. -- Summary: glibc math tests miscompiled with gcc-4.1 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: olh at suse dot de GCC build triplet: powerpc-linux GCC host triplet: powerpc-linux GCC target triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24819
[Bug regression/24819] glibc math tests miscompiled with gcc-4.1
--- Comment #1 from olh at suse dot de 2005-11-12 14:07 --- Created an attachment (id=10226) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10226&action=view) pr24819-failure.txt make check errors on powerpc-linux -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24819
[Bug libstdc++/24595] std::tr1::get_deleter not declared
--- Comment #6 from gcc-bugzilla at kayari dot org 2005-11-12 14:12 --- Created an attachment (id=10227) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10227&action=view) alternative fix This is a fixed version of the previous patch that passes tests on linux-x86_64. This patch makes all specialisations of get_deleter friends, not just the ones where _Tp == _Tp1 ... but that's probably not a big deal. -- gcc-bugzilla at kayari dot org changed: What|Removed |Added Attachment #10194|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24595
[Bug target/24475] gcc.dg/tls/pr24428.c execution test and gcc.dg/tls/pr24428-2.c execution test fail on IA32
--- Comment #4 from joseph at codesourcery dot com 2005-11-12 14:24 ---
Subject: Re: gcc.dg/tls/pr24428.c execution test and
gcc.dg/tls/pr24428-2.c execution test fail on IA32
On Thu, 10 Nov 2005, jakub at gcc dot gnu dot org wrote:
> Does even a trivial __thread using program break fail at runtime?
> __thread int thr;
> int main (void) { return thr; }
Yes, it segfaults on the system in question; it also seems to segfault
with more recent glibc configured with --without-tls.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24475
[Bug ada/18434] [4.0/4.1 Regression] Ada: cannot build gnattools on Tru64 UNIX V5.1B
--- Comment #15 from debian-gcc at lists dot debian dot org 2005-11-12 14:59 --- workaround works with 4.0.3 on alpha-linux as well, 4.1 build currently fails in stage3 Matthias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18434
[Bug tree-optimization/24819] [4.1 Regression] glibc math tests miscompiled with gcc-4.1
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Component|regression |tree-optimization Keywords||wrong-code Summary|glibc math tests miscompiled|[4.1 Regression] glibc math |with gcc-4.1|tests miscompiled with gcc- ||4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24819
[Bug middle-end/24819] [4.1 Regression] glibc math tests miscompiled with gcc-4.1
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-12 15:31 --- Waiting for a testcase. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|tree-optimization |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24819
[Bug middle-end/24819] [4.1 Regression] glibc math tests miscompiled with gcc-4.1
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24819
[Bug c/23397] Compilation Ghostscript gs_init.c file failed on mipsel-linux machine
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-12 15:36 --- No feedback in 3 months (T-3 days). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23397
[Bug middle-end/23785] [4.1 Regression] 197.parser performance drop
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P3 Summary|197.parser performance drop |[4.1 Regression] 197.parser ||performance drop Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23785
[Bug ada/18434] [4.0/4.1 Regression] Ada: cannot build gnattools on Tru64 UNIX V5.1B
--- Comment #16 from laurent at guerby dot net 2005-11-12 16:11 --- Arnaud has a patch for this issue on trunk and a better workaround patch for 4.0. Could you post your stage3 failure? -- laurent at guerby dot net changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |charlet at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18434
[Bug middle-end/24820] New: [4.1 regression] SEGV in integer_valued_real_p at gcc/builtins.c:6711
// Compile this with -O2 -ffast-math to get segfault
double floor (double);
double bar (double sum)
{
int i;
for (i = 0; i < 256; i++)
sum += floor (0.5 + (i - 128));
return sum;
}
--
Summary: [4.1 regression] SEGV in integer_valued_real_p at
gcc/builtins.c:6711
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: belyshev at depni dot sinp dot msu dot ru
GCC target triplet: x86_64-*-*, i?86-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24820
[Bug middle-end/24820] [4.1 regression] SEGV in integer_valued_real_p at gcc/builtins.c:6711
--- Comment #1 from laurent at guerby dot net 2005-11-12 16:36 --- confirmed on x86_64-linux gcc version 4.1.0 2005 (experimental) z.c: In function 'bar': z.c:3: internal compiler error: tree check: expected class 'expression', have 'constant' (real_cst) in integer_valued_real_p, at builtins.c:6710 -- laurent at guerby dot net changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-12 16:36:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24820
[Bug bootstrap/24821] New: [4.1 regression] [alpha-linux] ada bootstrap error in stage3
trunk 2005, configured for alpha-linux-gnu Matthias stage1/xgcc -Bstage1/ -B/usr/lib/gcc-snapshot/alpha-linux-gnu/bin/ -c -O2 -gnatpg -gnata -g -O1 -fno-inline \ -I- -I. -Iada -I../../src/gcc/ada ../../src/gcc/ada/a-except.adb -o ada/a-except.o :0: warning: 'const' attribute directive ignored :0: warning: 'nothrow' attribute directive ignored :0: warning: 'nothrow' attribute directive ignored :0: warning: 'const' attribute directive ignored :0: warning: 'nothrow' attribute directive ignored :0: warning: 'const' attribute directive ignored :0: warning: 'nothrow' attribute directive ignored :0: warning: 'const' attribute directive ignored :0: warning: 'nothrow' attribute directive ignored :0: warning: 'const' attribute directive ignored :0: warning: 'nothrow' attribute directive ignored :0: warning: 'const' attribute directive ignored :0: warning: 'nothrow' attribute directive ignored :0: warning: 'const' attribute directive ignored :0: warning: 'nothrow' attribute directive ignored :0: warning: 'const' attribute directive ignored :0: warning: 'nothrow' attribute directive ignored :0: warning: 'const' attribute directive ignored :0: warning: 'nothrow' attribute directive ignored :0: warning: 'const' attribute directive ignored :0: warning: 'nothrow' attribute directive ignored :0: warning: 'const' attribute directive ignored :0: warning: 'nothrow' attribute directive ignored :0: warning: 'const' attribute directive ignored :0: warning: 'nothrow' attribute directive ignored :0: warning: 'const' attribute directive ignored :0: warning: 'nothrow' attribute directive ignored :0: warning: 'const' attribute directive ignored :0: warning: 'nothrow' attribute directive ignored :0: warning: 'const' attribute directive ignored :0: warning: 'nothrow' attribute directive ignored :0: warning: 'const' attribute directive ignored :0: warning: 'nothrow' attribute directive ignored :0: warning: 'const' attribute directive ignored :0: warning: 'nothrow' attribute directive ignored :0: warning: 'const' attribute directive ignored :0: warning: 'nothrow' attribute directive ignored :0: warning: 'const' attribute directive ignored :0: warning: 'nothrow' attribute directive ignored :0: warning: 'const' attribute directive ignored :0: warning: 'nothrow' attribute directive ignored :0: warning: 'const' attribute directive ignored :0: warning: 'nothrow' attribute directive ignored :0: warning: 'const' attribute directive ignored :0: warning: 'nothrow' attribute directive ignored :0: warning: 'const' attribute directive ignored :0: warning: 'nothrow' attribute directive ignored :0: warning: 'const' attribute directive ignored :0: warning: 'nothrow' attribute directive ignored :0: warning: 'const' attribute directive ignored :0: warning: 'nothrow' attribute directive ignored :0: warning: 'const' attribute directive ignored :0: warning: 'nothrow' attribute directive ignored :0: warning: 'const' attribute directive ignored :0: warning: 'nothrow' attribute directive ignored :0: warning: 'nothrow' attribute directive ignored :0: warning: 'nothrow' attribute directive ignored +===GNAT BUG DETECTED==+ | 4.1.0 2005 (experimental) (alpha-unknown-linux-gnu) GCC error: | | tree check: expected class | | Error detected at a-except.adb:1387:1| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:380 make[4]: *** [ada/a-except.o] Error 1 make[4]: Leaving directory `/home/doko/gcc/snap/gcc-snapshot-2005/build/gcc'make[3]: *** [stage2_build] Error 2 make[3]: Leaving directory `/home/doko/gcc/snap/gcc-snapshot-2005/build/gcc'make[2]: *** [bootstrap] Error 2 -- Summary: [4.1 regression] [alpha-linux] ada bootstrap error in stage3 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org GCC host triplet: alpha-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24821
[Bug ada/18434] [4.0/4.1 Regression] Ada: cannot build gnattools on Tru64 UNIX V5.1B
--- Comment #17 from debian-gcc at lists dot debian dot org 2005-11-12 16:41 --- (In reply to comment #16) > Arnaud has a patch for this issue on trunk and a better workaround patch for > 4.0. > > Could you post your stage3 failure? actually, it's a stage2 failure, files as PR24821 Matthias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18434
[Bug ada/24822] New: make[2]: *** [ada/einfo.h] Error 1
(cd ada/bldtools/sinfo; gnatmake -q xsinfo ; ./xsinfo ../../sinfo.h ) mkdir -p ada/bldtools/einfo cp -p ../../gcc/gcc/ada/einfo.ads ../../gcc/gcc/ada/einfo.adb ../../gcc/gcc/ada/ xeinfo.adb ada/bldtools/einfo (cd ada/bldtools/einfo; gnatmake -q xeinfo ; ./xeinfo ../../einfo.h ) raised STORAGE_ERROR : stack overflow or erroneous memory access make[2]: *** [ada/einfo.h] Error 1 # gdb-6.3 xeinfo GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "hppa2.0w-hp-hpux11.11"... (gdb) r ../../einfo.h Starting program: /mnt/gnu/gcc-3.3/objdir/gcc/ada/bldtools/einfo/xeinfo ../../einfo.h Program received signal SIGSEGV, Segmentation fault. 0x00060db8 in system__finalization_implementation__get_deep_controller () (gdb) disass 0x00060d98 0x00060dd8 Dump of assembler code from 0x60d98 to 0x60dd8: 0x00060d98 : copy r31,rp 0x00060d9c : b,l 0x22920 ,rp 0x00060da0 : ldo -2f8(sp),r26 0x00060da4 : nop 0x00060da8 : stw rp,-14(,sp) 0x00060dac : stw,ma r4,40(,sp) 0x00060db0 : copy r26,r4 0x00060db4 : stw r3,-3c(,sp) 0x00060db8 : ldw 0(,r26),r3 0x00060dbc : b,l 0x2eef0 ,rp 0x00060dc0 : copy r3,r26 ---Type to continue, or q to quit--- 0x00060dc4 : cmpib,=,n -2,ret0,0x60dec 0x00060dc8 : cmpib,= 0,ret0,0x60dd8 0x00060dcc : ldi 0,r19 0x00060dd0 : cmpib,>= 0,ret0,0x60e28 0x00060dd4 : add,l r4,ret0,r19 End of assembler dump. (gdb) p/x $r26 $1 = 0x0 (gdb) bt #0 0x00060db8 in system__finalization_implementation__get_deep_controller () #1 0x00060f7c in system__finalization_implementation__deep_tag_attach () #2 0x00015594 in _ada_xeinfo () #3 0xf0dc in main () The segmentation fault is caused by system__finalization_implementation__deep_tag_attach () calling system__finalization_implementation__get_deep_controller () with a zero first argument. I used gcc 4.0.2 as the bootstrap compiler. I believe that the error doesn't occur when gcc-3.4.4 is used. -- Summary: make[2]: *** [ada/einfo.h] Error 1 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa*-*-hpux* GCC host triplet: hppa*-*-hpux* GCC target triplet: hppa*-*-hpux* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24822
[Bug bootstrap/24821] [4.1 regression] [alpha-linux] ada bootstrap error in stage3
--- Comment #1 from laurent at guerby dot net 2005-11-12 16:51 --- Likely to be the same problem than mips/powerpc. Note there's a negatively reviewed patch that solves this problem. *** This bug has been marked as a duplicate of 22533 *** -- laurent at guerby dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24821
[Bug ada/22533] [4.1 regression] ICE in get_base_var
--- Comment #25 from laurent at guerby dot net 2005-11-12 16:51 --- *** Bug 24821 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22533
[Bug middle-end/24820] [4.1 regression] SEGV in integer_valued_real_p at gcc/builtins.c:6711
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24820
[Bug middle-end/24820] [4.1 regression] SEGV in integer_valued_real_p at gcc/builtins.c:6711
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-12 16:58 --- integer_valued_real_p is missing a break or something. Looking more into it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24820
[Bug middle-end/24820] [3.4/4.0/4.1 regression] SEGV in integer_valued_real_p at gcc/builtins.c:6711
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-12 17:03 --- This is a latent bug from 2003 (3.4 time frame): * builtins.c (integer_valued_real_p): New function to test if a floating point expression has an integer valued result. (fold_trunc_transparent_mathfn): Optimize foo(foo(x)) as foo(x) where foo is an integer rounding function. Similarly, optimize foo(bar(x)) as bar(x), and foo((double)(int)x) as (double)(int)x when both foo and bar are integer rounding functions and we don't need to honor errno. (fold_builtin_trunc, fold_builtin_floor, fold_builtin_ceil): New functions to fold trunc, floor and ceil. (fold_builtin): Use fold_builtin_trunc to fold BUILT_IN_TRUNC*, fold_builtin_floor to fold BUILT_IN_FLOOR* and fold_builtin_ceil to fold BUILT_IN_CEIL*. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||sayle at gcc dot gnu dot org Known to work||3.3.3 Summary|[4.1 regression] SEGV in|[3.4/4.0/4.1 regression] |integer_valued_real_p at|SEGV in |gcc/builtins.c:6711 |integer_valued_real_p at ||gcc/builtins.c:6711 Target Milestone|4.1.0 |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24820
[Bug middle-end/24703] [GOMP] Unable to compile OpenMP program with omp parallel for schedule(dynamic) directive
--- Comment #3 from dnovillo at gcc dot gnu dot org 2005-11-12 17:47 --- Testing new patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24703
[Bug libstdc++/24800] tr1::mem_fn returns a function object that does not inherit from std::unary_function/binary_function
--- Comment #5 from john at johnmaddock dot co dot uk 2005-11-12 17:53 --- Thanks for the clarification Doug: having re-read the text, the issues list, and scratched my head for a while I agree with you. I'll update the Boost test case appropriately. Feel free to close this one down as invalid (it appears I don't have permission to do that). Regards, John. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24800
[Bug middle-end/24820] [3.4/4.0/4.1 regression] SEGV in integer_valued_real_p at gcc/builtins.c:6711
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-12 18:27 --- I will take care of this one, it is a simple matter of a break missing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24820
[Bug rtl-optimization/24823] New: [4.1 Regression] ICE
We ICE building lapack on x86_64 with /usr/lib64/gcc/x86_64-suse-linux/4.1.0/f951 zlatmr.f -ffixed-form -quiet -dumpbase zlatmr.f -mtune=k8 -auxbase zlatmr -O3 -version -funroll-all-loops -o /tmp/cclbQYB1.s zlatmr.min.f:69: internal compiler error: in insert_save, at caller-save.c:719 -- Summary: [4.1 Regression] ICE Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org GCC target triplet: x86_64-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24823
[Bug libstdc++/24803] tr1::reference_wrapper and pointers to member functions
--- Comment #4 from john at johnmaddock dot co dot uk 2005-11-12 18:32 --- Doug's right: according to 3.4p4 passing an rvalue results in implementation defined behaviour. So you can support it or not as you wish. I'll update the Boost test case accordingly. However... I predict that that I won't be the first to try and pass an rvalue through a call-wrapper :-) Regards, John. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24803
[Bug rtl-optimization/24823] [4.1 Regression] ICE
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-12 18:32 --- Created an attachment (id=10228) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10228&action=view) reduced testcase testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24823
[Bug rtl-optimization/24823] [4.1 Regression] ICE
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-12 18:40 --- This is a recent regression. This worked with PR 20051106 but not with 2005. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical Summary|[4.1 Regression] ICE|[4.1 Regression] ICE Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24823
[Bug libstdc++/24803] tr1::reference_wrapper and pointers to member functions
--- Comment #5 from hhinnant at apple dot com 2005-11-12 19:02 ---
> (1) Strong-arm a C++ front-end guru into implementing rvalue references,
> then use them in the TR1 function objects. Heck, we'll need 'em
> for C++0x anyway :)
At the risk of being reckless. Yes... well, more like YES!!! ;-)
I know very little about gcc at this point. But if the feature is implemented
under a pragma (say rvalue_refs), default off, and if library code can test the
pragma (at the preprocessor level), then we could really move forward (let the
puns lie where they may). N1855 went through core review in Mont Tremblant.
There were several good suggestions on rewording the proposed words, but
absolutely nothing against the functionality or even the syntax. That doesn't
mean the syntax is set in concrete. But it does mean the mud is firming up.
(I am guessing) It will take effort now for N1855 to not be accepted as is, or
pretty darn close to it. The lwg also voiced no complaints and indeed strong
support for N1856 - N1862. Almost irritation that I was taking up committee
time with this stuff again (just do it!).
If the language and library work goes under a pragma, default off, we can do
the following:
1. Code like (for reference_wrapper):
#ifdef _GCC_MOVE
operator()(T1&& t1) const {return (*data_)(std::forward(t1));}
#else
operator()(T1& t1) const {return (*data_)(t1);}
#endif
2. When bug reports like this come in, say "try turning on rvalue reference"
(give instructions for doing that).
3. If the syntax or functionality of the language changes, we are relatively
free to change the compiler/lib, documenting as appropriate, since this is not
default behavior, and should be documented as an extension - which could change
in the future.
4. When it becomes standard, we set the pragma to default on.
Dealing with bugs like this via hacks is more work than doing it right with
rvalue reference.
So who are going to get? I'd love to do it. But I'm slightly worse than a
newbie in this area. I could write language tests for it though. I also
wouldn't mind following someone more experienced just for my own education.
How about Russell Yanofsky?
http://russ.hn.org/rref/
It would be best if one did not have to recompile libstdc++ when flipping this
pragma. In order to achieve that you have to be committed to keeping as much
out of the binary lib as possible. To date the direction of libstdc++ has been
just the opposite.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24803
[Bug c++/24824] New: ICE: in build_abbrev_table, at dwarf2out.c:6427 with -feliminate-dwarf2-dups
g++ ICE with error message:
test.cc:24: internal compiler error: in build_abbrev_table, at dwarf2out.c:6427
Please submit a full bug report,
g++ call: g++ -c -gdwarf-2 -feliminate-dwarf2-dups test.cc -o test.o
testcase:
---8X--
namespace N {
struct I {};
template
struct _V_base {
I _impl;
};
template
struct V : _V_base<_Tp> {
using _V_base<_Tp>::_impl;
};
} // namespace N
struct S {};
struct T {
T();
N::V _l;
};
T::T() {}
---X8--
ICE with:
gcc version 4.1.0 20051104 (experimental)
gcc version 4.1.0 20051110 (experimental)
OK with:
gcc version 3.4.4 [FreeBSD] 20050518 (system compiler)
gcc version 3.4.4 20050513 (prerelease)
gcc version 3.5.0 20040712 (experimental)
gcc version 4.0.2
--
Summary: ICE: in build_abbrev_table, at dwarf2out.c:6427 with -
feliminate-dwarf2-dups
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wanderer at rsu dot ru
GCC build triplet: i386-unknown-freebsd6.0
GCC host triplet: i386-unknown-freebsd6.0
GCC target triplet: i386-unknown-freebsd6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24824
[Bug c++/24824] ICE: in build_abbrev_table, at dwarf2out.c:6427 with -feliminate-dwarf2-dups
--- Comment #1 from wanderer at rsu dot ru 2005-11-12 19:04 --- Created an attachment (id=10229) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10229&action=view) testcase source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24824
[Bug debug/24824] [4.1 Regression] ICE: in build_abbrev_table, at dwarf2out.c:6427 with -feliminate-dwarf2-dups
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-12 19:09 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i386-unknown-freebsd6.0 | GCC host triplet|i386-unknown-freebsd6.0 | GCC target triplet|i386-unknown-freebsd6.0 |i?86-*-* with dwarf2 Keywords||ice-on-valid-code Known to fail||4.1.0 Known to work||3.4.0 3.3.3 4.0.0 Last reconfirmed|-00-00 00:00:00 |2005-11-12 19:09:06 date|| Summary|ICE: in build_abbrev_table, |[4.1 Regression] ICE: in |at dwarf2out.c:6427 with - |build_abbrev_table, at |feliminate-dwarf2-dups |dwarf2out.c:6427 with - ||feliminate-dwarf2-dups Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24824
[Bug rtl-optimization/24823] [4.1 Regression] ICE
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-12 19:10 --- Confirmed. 106665 works, 106727 fails -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24823
[Bug rtl-optimization/24823] [4.1 Regression] ICE
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-12 19:12:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24823
[Bug libfortran/24787] [libfortran] SCAN is broken
--- Comment #3 from kargl at gcc dot gnu dot org 2005-11-12 19:16 --- Subject: Bug 24787 Author: kargl Date: Sat Nov 12 19:16:40 2005 New Revision: 106828 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106828 Log: PR libfortran/24787 * intrinsics/string_intrinsics.c (string_scan): Off by one; Fix typos in nearby comment. * gfortran.dg/scan_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/scan_1.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/string_intrinsics.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24787
[Bug c/20318] RFE: add attribute to specify that a function never returns NULL
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-12 19:26 --- I have a patch already. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|dnovillo at gcc dot gnu dot |pinskia at gcc dot gnu dot |org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20318
[Bug libfortran/24787] [libfortran] SCAN is broken
--- Comment #4 from kargl at gcc dot gnu dot org 2005-11-12 19:48 --- Subject: Bug 24787 Author: kargl Date: Sat Nov 12 19:48:25 2005 New Revision: 106830 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106830 Log: PR libgfortran/24787 * gfortran.dg/scan_1.f90: New test. * intrinsics/string_intrinsics.c (string_scan): Off by one; Fix typos in nearby comment. Added: branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/scan_1.f90 Modified: branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/libgfortran/ChangeLog branches/gcc-4_0-branch/libgfortran/intrinsics/string_intrinsics.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24787
[Bug libfortran/24787] [libfortran] SCAN is broken
--- Comment #5 from kargl at gcc dot gnu dot org 2005-11-12 19:50 --- Fixed on mainline and 4.0.x -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24787
[Bug c++/19476] Missed null checking elimination with new
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-12 20:05 --- This is an easy extension on top of PR 20318. Mine. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|dnovillo at gcc dot gnu dot |pinskia at gcc dot gnu dot |org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19476
[Bug java/24242] Redundant null pointer checks generated on refrerences returned by new operator.
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-12 20:06 --- Will look into marking _Jv_AllocObjectNoFinalizer with the non zero attribute which is added with PR 20318. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24242
[Bug java/21856] null pointer check elimination
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-12 20:08 --- Mine. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|dnovillo at gcc dot gnu dot |pinskia at gcc dot gnu dot |org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21856
[Bug java/24242] Redundant null pointer checks generated on refrerences returned by new operator.
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-12 20:09 --- This is actually a dup of bug 21856. *** This bug has been marked as a duplicate of 21856 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24242
[Bug java/21856] null pointer check elimination
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-12 20:09 --- *** Bug 24242 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||daney at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21856
[Bug c++/24761] [4.0/4.1 Regression] templates and inline-asm and "+"
--- Comment #6 from jakub at gcc dot gnu dot org 2005-11-12 20:42 --- Subject: Bug 24761 Author: jakub Date: Sat Nov 12 20:42:23 2005 New Revision: 106831 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106831 Log: PR c++/24761 * pt.c (tsubst_copy_asm_operands): New function. (tsubst_expr) : Use it. * g++.dg/template/asm1.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/asm1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24761
[Bug c++/24761] [4.0/4.1 Regression] templates and inline-asm and "+"
--- Comment #7 from jakub at gcc dot gnu dot org 2005-11-12 20:43 --- Subject: Bug 24761 Author: jakub Date: Sat Nov 12 20:43:27 2005 New Revision: 106832 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106832 Log: PR c++/24761 * pt.c (tsubst_copy_asm_operands): New function. (tsubst_expr) : Use it. * g++.dg/template/asm1.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/template/asm1.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/pt.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24761
[Bug c++/24780] [4.0/4.1 Regression] ICE set_mem_attributes_minus_bitpos
--- Comment #8 from jakub at gcc dot gnu dot org 2005-11-12 20:44 --- Subject: Bug 24780 Author: jakub Date: Sat Nov 12 20:44:55 2005 New Revision: 106833 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106833 Log: PR c++/24780 * typeck.c (complete_type): Set TYPE_NEEDS_CONSTRUCTING and TYPE_HAS_NONTRIVIAL_DESTRUCTOR flags for all variants of array type. * g++.dg/opt/pr24780.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/pr24780.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24780
[Bug c++/24780] [4.0/4.1 Regression] ICE set_mem_attributes_minus_bitpos
--- Comment #9 from jakub at gcc dot gnu dot org 2005-11-12 20:45 --- Subject: Bug 24780 Author: jakub Date: Sat Nov 12 20:45:47 2005 New Revision: 106834 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106834 Log: PR c++/24780 * typeck.c (complete_type): Set TYPE_NEEDS_CONSTRUCTING and TYPE_HAS_NONTRIVIAL_DESTRUCTOR flags for all variants of array type. * g++.dg/opt/pr24780.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/opt/pr24780.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/typeck.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24780
[Bug java/24825] New: Standard runtime methods that are known to not return null should not trigger null checks.
As pointed out in this thread: http://gcc.gnu.org/ml/java/2005-11/msg00124.html Once we have the capability to annotate methods as returning 'not null', we have a win if standard runtime methods are so annotated as appropiate. -- Summary: Standard runtime methods that are known to not return null should not trigger null checks. Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: daney at gcc dot gnu dot org BugsThisDependsOn: 20318 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24825
[Bug testsuite/16230] Spurious test failures with --disable-static
--- Comment #3 from andreast at gcc dot gnu dot org 2005-11-12 21:06 --- The other languages like g++, gfortran, obj-c++ and objc should be fixed with this patch which is applied on trunk. http://gcc.gnu.org/ml/gcc-cvs/2005-11/msg00503.html So, the question is now, can you reproduce this one for libgcj? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16230
[Bug target/24826] New: Incorrect default options
At some point between 4.0 and 4.1 the mechanism for option handling was changed over to the new style using the .opt file but the default setting of quickcall seems to have been lost in the process. adding the following 2 lines into h8300.c #undef TARGET_DEFAULT_TARGET_FLAGS #define TARGET_DEFAULT_TARGET_FLAGS (MASK_QUICKCALL) immediately before the line struct gcc_target targetm = TARGET_INITIALIZER; appears to fix the problem allthough I am not sure that this is completely the correct way to do this. -- Summary: Incorrect default options Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mlist at ml-solutions dot co dot uk GCC host triplet: i686-pc-cygwin GCC target triplet: h8300-hitachi-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24826
[Bug target/24826] [4.1 Regression] Incorrect default options
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||kazu at gcc dot gnu dot org Priority|P3 |P5 Summary|Incorrect default options |[4.1 Regression] Incorrect ||default options Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24826
[Bug c++/24761] [4.0/4.1 Regression] templates and inline-asm and "+"
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-12 22:13 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24761
[Bug c++/24780] [4.0/4.1 Regression] ICE set_mem_attributes_minus_bitpos
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-12 22:14 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24780
[Bug java/24825] Standard runtime methods that are known to not return null should not trigger null checks.
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-12 22:14 --- Confirmed, this one is harder than the new operator. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-12 22:14:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24825
[Bug libfortran/24584] Segfault when reading empty string in namelist file
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2005-11-12 22:22 --- Subject: Bug 24584 Author: jvdelisle Date: Sat Nov 12 22:22:53 2005 New Revision: 106838 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106838 Log: 2005-11-12 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/24699, 24700, 24719, 24785 * io/transfer.c (read_sf): Remove incorrect statement that was clearing bytes_left. (formatted_transfer_scalar): Add handling of end-of-record condition, setting values correctly to backup. Handle x format when doing non-advancing write. (st_read): Initialize current_record. PR libgfortran/24584 * io/list_read.c (free_saved): Set saved_used to zero. Modified: branches/gcc-4_0-branch/libgfortran/ChangeLog branches/gcc-4_0-branch/libgfortran/io/list_read.c branches/gcc-4_0-branch/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24584
[Bug libfortran/24699] READ with T format specifier fails on end-of-record condition
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2005-11-12 22:22 --- Subject: Bug 24699 Author: jvdelisle Date: Sat Nov 12 22:22:53 2005 New Revision: 106838 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106838 Log: 2005-11-12 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/24699, 24700, 24719, 24785 * io/transfer.c (read_sf): Remove incorrect statement that was clearing bytes_left. (formatted_transfer_scalar): Add handling of end-of-record condition, setting values correctly to backup. Handle x format when doing non-advancing write. (st_read): Initialize current_record. PR libgfortran/24584 * io/list_read.c (free_saved): Set saved_used to zero. Modified: branches/gcc-4_0-branch/libgfortran/ChangeLog branches/gcc-4_0-branch/libgfortran/io/list_read.c branches/gcc-4_0-branch/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24699
[Bug libfortran/24719] [4.1 Regression] Nonadvancing read does not read more than 1 line
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2005-11-12 22:31 --- Subject: Bug 24719 Author: jvdelisle Date: Sat Nov 12 22:31:18 2005 New Revision: 106839 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106839 Log: 2005-11-12 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/24719 *gfortran.dg/read_noadvance.f90: New test. PR libgfortran/24699 *gfortran.dg/fmt_t_2.f90: New test. PR libgfortran/24785 *gfortran.dg/read_x_eor.f90: New test. PR libgfortran/24584 *gfortran.dg/namelist_empty.f90: Rename test. *gfortran.dg/f77/1832.f: Backport from 4.1. Added: branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/fmt_t_2.f90 branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/namelist_empty.f90 branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/read_noadvance.f90 branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/read_x_eor.f90 Modified: branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/g77/1832.f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24719
[Bug libfortran/24785] X edit descriptor lost with ADVANCE="NO"
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2005-11-12 22:31 --- Subject: Bug 24785 Author: jvdelisle Date: Sat Nov 12 22:31:18 2005 New Revision: 106839 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106839 Log: 2005-11-12 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/24719 *gfortran.dg/read_noadvance.f90: New test. PR libgfortran/24699 *gfortran.dg/fmt_t_2.f90: New test. PR libgfortran/24785 *gfortran.dg/read_x_eor.f90: New test. PR libgfortran/24584 *gfortran.dg/namelist_empty.f90: Rename test. *gfortran.dg/f77/1832.f: Backport from 4.1. Added: branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/fmt_t_2.f90 branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/namelist_empty.f90 branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/read_noadvance.f90 branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/read_x_eor.f90 Modified: branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/g77/1832.f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24785
[Bug libfortran/24699] READ with T format specifier fails on end-of-record condition
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2005-11-12 22:31 --- Subject: Bug 24699 Author: jvdelisle Date: Sat Nov 12 22:31:18 2005 New Revision: 106839 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106839 Log: 2005-11-12 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/24719 *gfortran.dg/read_noadvance.f90: New test. PR libgfortran/24699 *gfortran.dg/fmt_t_2.f90: New test. PR libgfortran/24785 *gfortran.dg/read_x_eor.f90: New test. PR libgfortran/24584 *gfortran.dg/namelist_empty.f90: Rename test. *gfortran.dg/f77/1832.f: Backport from 4.1. Added: branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/fmt_t_2.f90 branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/namelist_empty.f90 branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/read_noadvance.f90 branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/read_x_eor.f90 Modified: branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/g77/1832.f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24699
[Bug libfortran/24584] Segfault when reading empty string in namelist file
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2005-11-12 22:31 --- Subject: Bug 24584 Author: jvdelisle Date: Sat Nov 12 22:31:18 2005 New Revision: 106839 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106839 Log: 2005-11-12 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/24719 *gfortran.dg/read_noadvance.f90: New test. PR libgfortran/24699 *gfortran.dg/fmt_t_2.f90: New test. PR libgfortran/24785 *gfortran.dg/read_x_eor.f90: New test. PR libgfortran/24584 *gfortran.dg/namelist_empty.f90: Rename test. *gfortran.dg/f77/1832.f: Backport from 4.1. Added: branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/fmt_t_2.f90 branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/namelist_empty.f90 branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/read_noadvance.f90 branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/read_x_eor.f90 Modified: branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/g77/1832.f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24584
[Bug middle-end/24827] New: FAIL: gcc.dg/attr-weakref-1.c
Executing on host: /test/gnu/gcc-3.3/objdir/gcc/xgcc -B/test/gnu/gcc-3.3/objdir/ gcc/ /test/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.dg/attr-weakref-1.c -O2 -fno-show -column /test/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.dg/attr-weakref-1a.c -lm -o ./attr-weakref-1.exe(timeout = 300) ld: Unsatisfied symbol "wf1" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wf6" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wf9" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wv1" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wv6" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wv9" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wf10" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wf11" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wf12" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wf13" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wf14" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wv10" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wv11" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wv12" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wv13" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wv14" in file /var/tmp//ccNG756H.o 16 errors. collect2: ld returned 1 exit status compiler exited with status 1 output is: ld: Unsatisfied symbol "wf1" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wf6" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wf9" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wv1" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wv6" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wv9" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wf10" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wf11" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wf12" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wf13" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wf14" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wv10" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wv11" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wv12" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wv13" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wv14" in file /var/tmp//ccNG756H.o 16 errors. collect2: ld returned 1 exit status FAIL: gcc.dg/attr-weakref-1.c (test for excess errors) Excess errors: ld: Unsatisfied symbol "wf1" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wf6" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wf9" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wv1" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wv6" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wv9" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wf10" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wf11" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wf12" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wf13" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wf14" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wv10" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wv11" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wv12" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wv13" in file /var/tmp//ccNG756H.o ld: Unsatisfied symbol "wv14" in file /var/tmp//ccNG756H.o WARNING: gcc.dg/attr-weakref-1.c compilation failed to produce executable -- Summary: FAIL: gcc.dg/attr-weakref-1.c Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa64-hp-hpux11.11 GCC host triplet: hppa64-hp-hpux11.11 GCC target triplet: hppa64-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24827
[Bug target/24626] [4.1 Regression] internal compiler error: verify_flow_info failed
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-11-12 23:03 --- works with 3.3, so a regression. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.0 Known to work||3.3.3 Summary|internal compiler error:|[4.1 Regression] internal |verify_flow_info failed |compiler error: ||verify_flow_info failed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626
[Bug libfortran/24699] READ with T format specifier fails on end-of-record condition
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2005-11-12 23:13 --- Fixed in 4.0.3 and 4.1 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24699
[Bug libfortran/24700] Bad write after backing up from end of file
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2005-11-12 23:13 --- Fixed in 4.0.3 and 4.1. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24700
[Bug libfortran/24719] [4.1 Regression] Nonadvancing read does not read more than 1 line
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2005-11-12 23:20 --- Fixed in 4.0.3 and 4.1 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24719
[Bug libfortran/24785] X edit descriptor lost with ADVANCE="NO"
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2005-11-12 23:21 --- Fixed in 4.0.3 and 4.1 . -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24785
[Bug libfortran/24584] Segfault when reading empty string in namelist file
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2005-11-12 23:22 --- Fixed in 4.0.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24584
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2005-11-12 23:29 --- With my last patch () that I am currently commiting, the list of unimplemented intrinsics is now: Access, fcn, Check file accessibility. ChMod,sub, Change file modes. FSeek,fcn, Position file (low-level). GMTime, fcn, Convert time to GMT time info. IDate,sub, Get local time info. Int2, fcn, Convert to `INTEGER(KIND=6)' value truncated to whole number. Int8, fcn, Convert to `INTEGER(KIND=2)' value truncated to whole number. ITime,sub, Get local time of day. Long, fcn, Conversion to `INTEGER(KIND=1)' (archaic). LShift, fcn, Left-shift bits LStat,sub and fcn, Get file information. LTime,sub, Convert time to local time info. MClock, fcn, Get number of clock ticks for process. MClock8, fcn, Get number of clock ticks for process. RShift, fcn, Right-shift bits. Short,fcn, Convert to `INTEGER(KIND=6)' value truncated to whole number. I plan to work on ACCESS and CHMOD (I already have them half-implemented in one of my trees) and FSEEK is though to get (it has a label as optional argument, which I don't know how to handle). GMTIME, IDATE, ITIME, LSTAT and LTIME need some library part and should be easy, if someone wants to have a go at them, feel free! -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2005-01-06 14:49:20 |2005-11-12 23:29:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug fortran/20244] internal compiler error: in fold_convert, at fold-const.c:2003
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-12 23:43 --- (In reply to comment #8) > I got the same ICE with one of the SPEC2006 candidate benchmarks on > x86_64-linux-gnu. Was this before or after my fix for PR 18157 went in? Because this and that bug had the same ICE but are really different bugs. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||aj at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20244
[Bug fortran/24828] New: Z and negative integers
$ cat z.f
program z
i = Z'80203040'
if (i .ne. Z'80203040') call abort
end
$ gfortran z.f
$ ./a.out
Aborted
$ g77 z.f
$ ./a.out
$
This is a signedness/cast issue. .t02.original shows:
int4 i;
i = 080203040;
if ((int8) i != 080203040)
{
_gfortran_abort ();
}
else
{
(void) 0;
}
(And why is hexadecimal shown as 0 in the dump?)
--
Summary: Z and negative integers
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
OtherBugsDependingO 19292
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24828
[Bug fortran/24828] Z and negative integers
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-12 23:53 --- (In reply to comment #0) > (And why is hexadecimal shown as 0 in the dump?) Because that means TREE_OVERFLOW is set for some reason. Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-12 23:53:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24828
[Bug libfortran/23419] unformatted complex I/O with kind=10
--- Comment #9 from tkoenig at gcc dot gnu dot org 2005-11-12 23:56 --- Yes, this is fixed for mainline. Great! -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23419
[Bug java/24825] Standard runtime methods that are known to not return null should not trigger null checks.
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-13 00:16 --- The way we can mark the function/function type is in build_method_invocation, we have to change how BUILD_APPEND calls build_method_invocation and add a new argument or something like that (we build the real call expression later on). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24825
[Bug c++/19476] Missed null checking elimination with new
--- Comment #5 from sabre at nondot dot org 2005-11-13 01:24 --- Is this safe? People can define their own operator new's, some of which may return null... -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19476
[Bug tree-optimization/21488] [4.0/4.1 regression] Not copy propagating single-argument PHIs causes out-of-ssa coalescing failure
--- Comment #13 from steven at gcc dot gnu dot org 2005-11-13 01:38 --- Doesn't happen anymore on current mainline. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21488
[Bug middle-end/19207] Suggestion for speeding up data flow analysis
--- Comment #1 from steven at gcc dot gnu dot org 2005-11-13 01:41 --- IIUC, this is one of the things that's being worked on in the dataflow-branch. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19207
[Bug tree-optimization/19590] IVs with the same evolution not eliminated
--- Comment #2 from steven at gcc dot gnu dot org 2005-11-13 01:43 --- This hasn't been addressed yet in r106784. -- steven at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2005-09-21 01:43:19 |2005-11-13 01:43:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19590
[Bug c++/19476] Missed null checking elimination with new
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-13 02:10 --- (In reply to comment #5) > Is this safe? People can define their own operator new's, some of which may > return null... Yes because the normal operator new guarante not to return NULL by the C++ standard. And if it returns a NULL that is undefined behavior, it should be throwing an exception when memory could not be allocated (there is a nonthrow version which can and will return NULL). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19476
[Bug c++/19476] Missed null checking elimination with new
--- Comment #7 from sabre at nondot dot org 2005-11-13 02:13 --- > Yes because the normal operator new guarante not to return NULL by the C++ > standard. Sure. > And if it returns a NULL that is undefined behavior, it should be > throwing an exception when memory could not be allocated (there is a nonthrow > version which can and will return NULL). Sure, fine, but you need not be calling the default/normal operator new. I can define an overload for operator new in a different translation unit, or even by dynamically loading a library with a different one. This is similar to replacing malloc. AFAICT, the C++ std does not say that the replacement operator new may not return null. -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19476
[Bug c++/19476] Missed null checking elimination with new
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-13 02:24 --- (In reply to comment #7) >From 3.7.3/3: Any allocation and/or deallocation functions defined in a C++ program shall conform to the sematics specified in 3.7.3.1 and 3.7.3.2. --- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19476
[Bug rtl-optimization/24810] [4.1 Regression] mov + mov + testl generated instead of testb
--- Comment #2 from dann at godzilla dot ics dot uci dot edu 2005-11-13
02:47 ---
Simplified testcase:
struct cpuinfo_x86 {
unsigned char x86;
unsigned char x86_vendor;
unsigned char x86_model;
unsigned char x86_mask;
char wp_works_ok;
char hlt_works_ok;
char hard_math;
char rfu;
int cpuid_level;
unsigned long x86_capability[7];
} __attribute__((__aligned__((1 << (7);
struct task_struct;
extern void foo (struct task_struct *tsk);
extern void bar (struct task_struct *tsk);
extern struct cpuinfo_x86 boot_cpu_data;
static inline __attribute__((always_inline)) int
constant_test_bit(int nr, const volatile unsigned long *addr)
{
return ((1UL << (nr & 31)) & (addr[nr >> 5])) != 0;
}
void
restore_fpu(struct task_struct *tsk)
{
if (constant_test_bit(24, boot_cpu_data.x86_capability))
foo (tsk);
else
bar (tsk);
}
The generated code for this simplified tescase shows one additional issue:
restore_fpu:
movl%eax, %edx
movlboot_cpu_data+12, %eax ; edx could be used here
testl $16777216, %eax ; and here
je .L2
movl%edx, %eax ; then all the mov %eax, %edx and mov %edx, %eax
jmp foo ; instructions could be eliminated.
.p2align 4,,7
.L2:
movl%edx, %eax
jmp bar
--
dann at godzilla dot ics dot uci dot edu changed:
What|Removed |Added
Summary|mov + mov + testl generated |[4.1 Regression] mov + mov +
|instead of testb|testl generated instead of
||testb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24810
[Bug c++/19476] Missed null checking elimination with new
--- Comment #9 from sabre at nondot dot org 2005-11-13 02:51 --- yup, you're right. Great! -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19476
[Bug libobjc/24829] New: libobjc testsuite failures
Running /test/gnu/gcc-3.3/gcc/gcc/testsuite/objc.dg/dg.exp ...
FAIL: objc.dg/bitfield-1.m (test for excess errors)
FAIL: objc.dg/bitfield-1.m execution test
FAIL: objc.dg/bitfield-3.m (test for excess errors)
FAIL: objc.dg/bitfield-3.m execution test
FAIL: objc.dg/bitfield-5.m (test for excess errors)
FAIL: objc.dg/bitfield-5.m execution test
FAIL: objc.dg/call-super-1.m (test for excess errors)
FAIL: objc.dg/call-super-1.m execution test
FAIL: objc.dg/call-super-3.m (test for excess errors)
FAIL: objc.dg/call-super-3.m execution test
FAIL: objc.dg/category-1.m (test for excess errors)
FAIL: objc.dg/category-1.m execution test
FAIL: objc.dg/defs.m (test for excess errors)
FAIL: objc.dg/defs.m execution test
FAIL: objc.dg/desig-init-1.m (test for excess errors)
FAIL: objc.dg/desig-init-1.m execution test
FAIL: objc.dg/encode-1.m (test for excess errors)
FAIL: objc.dg/encode-1.m execution test
FAIL: objc.dg/encode-2.m (test for excess errors)
FAIL: objc.dg/encode-2.m execution test
FAIL: objc.dg/encode-3.m (test for excess errors)
FAIL: objc.dg/encode-3.m execution test
FAIL: objc.dg/encode-4.m (test for excess errors)
FAIL: objc.dg/encode-4.m execution test
FAIL: objc.dg/func-ptr-1.m (test for excess errors)
FAIL: objc.dg/func-ptr-1.m execution test
FAIL: objc.dg/func-ptr-2.m (test for excess errors)
FAIL: objc.dg/func-ptr-2.m execution test
FAIL: objc.dg/method-10.m (test for excess errors)
FAIL: objc.dg/method-10.m execution test
FAIL: objc.dg/method-13.m (test for excess errors)
FAIL: objc.dg/method-13.m execution test
FAIL: objc.dg/method-3.m (test for excess errors)
FAIL: objc.dg/method-3.m execution test
FAIL: objc.dg/proto-lossage-3.m (test for excess errors)
FAIL: objc.dg/proto-lossage-3.m execution test
FAIL: objc.dg/proto-qual-1.m (test for excess errors)
FAIL: objc.dg/proto-qual-1.m execution test
FAIL: objc.dg/sizeof-1.m (test for excess errors)
FAIL: objc.dg/sizeof-1.m execution test
FAIL: objc.dg/stret-1.m (test for excess errors)
FAIL: objc.dg/stret-1.m execution test
FAIL: objc.dg/super-class-3.m (test for excess errors)
FAIL: objc.dg/super-class-3.m execution test
FAIL: objc.dg/type-size-2.m (test for excess errors)
FAIL: objc.dg/type-size-2.m execution test
FAIL: objc.dg/type-stream-1.m (test for excess errors)
FAIL: objc.dg/type-stream-1.m execution test
FAIL: objc.dg/va-meth-1.m (test for excess errors)
FAIL: objc.dg/va-meth-1.m execution test
Running /test/gnu/gcc-3.3/gcc/gcc/testsuite/objc.dg/special/special.exp ...
FAIL: objc.dg/special/unclaimed-category-1.m unclaimed-category-1a.o (test for
e
xcess errors)
FAIL: objc.dg/special/unclaimed-category-1.m unclaimed-category-1a.o execution
t
est
Executing on host: /test/gnu/gcc-3.3/objdir/gcc/xgcc
-B/test/gnu/gcc-3.3/objdir/
gcc/ /test/gnu/gcc-3.3/gcc/gcc/testsuite/objc.dg/bitfield-1.m
-I/test/gnu/gcc
-3.3/gcc/gcc/testsuite/../../libobjc
-L/test/gnu/gcc-3.3/objdir/hppa64-hp-hpux11
.11/./libobjc/.libs -lobjc -lm -o ./bitfield-1.exe(timeout = 300)
ld: (Warning) Unsatisfied symbol "pthread_create" in file
/test/gnu/gcc-3.3/objd
ir/hppa64-hp-hpux11.11/./libobjc/.libs/libobjc.sl
ld: (Warning) Unsatisfied symbol "pthread_attr_init" in file
/test/gnu/gcc-3.3/o
bjdir/hppa64-hp-hpux11.11/./libobjc/.libs/libobjc.sl
2 warnings.
Symbols from
/test/gnu/gcc-3.3/objdir/hppa64-hp-hpux11.11/./libobjc/.libs/libobj
c.sl.1:
[Index]Value SizeType Bind O ShndxName
...
[742]| 0| 0|FUNC |GLOB |0|
UNDEF|pthread_attr_in
...
[593]| 0| 0|FUNC |GLOB |0| UNDEF|pthread_create
We have in sys/pthread.h:
#ifdef __lint
extern int pthread_attr_init(pthread_attr_t *);
#else /* ! __lint */
extern int __pthread_attr_init_system(pthread_attr_t *attr);
#ifdef __cplusplus
inline int pthread_attr_init(
#else /* !__cplusplus */
static int pthread_attr_init(
#endif /* !__cplusplus */
pthread_attr_t *attr)
{ return(__pthread_attr_init_system(attr)); }
#endif /* ! __lint */
and
#ifdef __lint
extern int pthread_create(pthread_t *tid,
const pthread_attr_t *attr,
void *(*start_routine)(void *),
void *arg);
#else /* ! __lint */
extern int __pthread_create_system(pthread_t *tid,
const pthread_attr_t *attr,
void *(*start_routine)(void *),
void *arg);
#ifdef __cplusplus
inline int pthread_create(
#else /* !__cplusplus */
static int pthread_create(
#endif /* !__cplusplus */
pthread_t *tid,
const pthread_attr_t *attr,
void *(*start_routine)(void *),
void *arg)
{ return(__pthread_create_syste
[Bug other/24829] libobjc testsuite failures
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-13 03:25 --- Is this a regression? If this is a regression, was this caused by: 2005-11-09 Alexandre Oliva <[EMAIL PROTECTED]> PR other/4372 * gthr-dce.h, gthr-posix.h, gthr-posix95.h, gthr-solaris.h, gthr-tpf.h: Define __gthrw. For all identifiers that might be weak, introduce weakrefs or non-weak aliases with __gthrw, and prefix all uses with __ghtrw. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|libobjc |other http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24829
[Bug other/24829] libobjc testsuite failures
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-13 03:32 --- Subject: Re: libobjc testsuite failures > Is this a regression? If this is a regression, was this caused by: Yes, things were ok on 2005-11-07. > 2005-11-09 Alexandre Oliva <[EMAIL PROTECTED]> > > PR other/4372 > * gthr-dce.h, gthr-posix.h, gthr-posix95.h, gthr-solaris.h, > gthr-tpf.h: Define __gthrw. For all identifiers that might > be weak, introduce weakrefs or non-weak aliases with __gthrw, > and prefix all uses with __ghtrw. This is probably the cause. gcc.dg/attr-weakref-1.c also fails on this target. I'm using GNU as and HP ld. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24829
[Bug middle-end/24827] FAIL: gcc.dg/attr-weakref-1.c
--- Comment #1 from danglin at gcc dot gnu dot org 2005-11-13 03:46 --- Also fails on hppa2.0w-hp-hpux11.11. So, probably fails on all hppa*-*-hpux* targets. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24827
[Bug c/24830] New: Duplicate constructors with -fmudflap
The only way I know how to reproduce this is with -fmudflap, but that's only because *C* code doesn't normally generate constructors. With -fmudflap, each of the mudflap constructors are run twice. An objdump run on the object files shows two ctor sections, one named ".ctor" and one named ".ctor.65436". default_named_section_asm_out_constructor() is being called twice from cgraph_build_static_cdtor(), once directly, and once indirectly. The first (indirect) call is here: #0 default_named_section_asm_out_constructor (symbol=0xb7a5a660, priority=65535) at ../../gcc-4.0.2.bounds/gcc/varasm.c:1133 #1 0x0805b237 in c_expand_body (fndecl=0xb7a45dec) at ../../gcc-4.0.2.bounds/gcc/c-decl.c:6634 #2 0x0832f012 in cgraph_expand_function (node=0xb7a45f30) at ../../gcc-4.0.2.bounds/gcc/cgraphunit.c:835 #3 0x0832f0f5 in cgraph_assemble_pending_functions () at ../../gcc-4.0.2.bounds/gcc/cgraphunit.c:307 #4 0x0832f78a in cgraph_finalize_function (decl=0xb7a45dec, nested=0 '\0') at ../../gcc-4.0.2.bounds/gcc/cgraphunit.c:399 #5 0x083309ae in cgraph_build_static_cdtor (which=73 'I', body=0xb7a5a660, priority=99) at ../../gcc-4.0.2.bounds/gcc/cgraphunit.c:1901 #6 0x080941a2 in mudflap_finish_file () at ../../gcc-4.0.2.bounds/gcc/tree-mudflap.c:1374 #7 0x082eea55 in toplev_main (argc=3081086560, argv=0xbfb75a84) at ../../gcc-4.0.2.bounds/gcc/toplev.c:1050 The second (direct) call is here: #0 default_named_section_asm_out_constructor (symbol=0xb7a5a660, priority=99) at ../../gcc-4.0.2.bounds/gcc/varasm.c:1133 #1 0x08330997 in cgraph_build_static_cdtor (which=73 'I', body=0xb7a5a660, priority=99) at ../../gcc-4.0.2.bounds/gcc/cgraphunit.c:1911 #2 0x080941a2 in mudflap_finish_file () at ../../gcc-4.0.2.bounds/gcc/tree-mudflap.c:1374 #3 0x082eea55 in toplev_main (argc=3081086560, argv=0xbfb75a84) at ../../gcc-4.0.2.bounds/gcc/toplev.c:1050 The first call looks wrong, as it is not being passed the correct priority. --Doug. -- Summary: Duplicate constructors with -fmudflap Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dgraham at nortel dot com 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=24830
[Bug other/24829] libobjc testsuite failures
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-13 04:07 --- Alexandre could you look into this one and PR 24827? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24829
