[Bug target/29337] -mfpmath=387 doesn't use fistp for double-to-integer conversion
--- Comment #8 from uros at kss-loka dot si 2006-10-05 07:08 --- > try -O2 -msse2, you get: > _Z8todoubledd: > subl$12, %esp > fldl24(%esp) > faddl 16(%esp) > fstpl (%esp) > movsd (%esp), %xmm0 > addl$12, %esp > cvttsd2si %xmm0, %eax > ret > > > Though I think the movsd should not be there but that is a different > issue. This is PR 19398. I have a patch that adds a bunch of peephole2 patterns to address this particular issue. The patch is already approved and waits for stage1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29337
[Bug c++/29348] Ambiguous warning with -Weffc++
--- Comment #4 from federico dot carminati at cern dot ch 2006-10-05 07:44
---
Subject: Re: Ambiguous warning with -Weffc++
Thanks for your answer. However, if I just code in the following way
int f(a lhc) {
if (lhs) return TRUE;
else if g() return TRUE;
return FALSE
}
I am not always evaluating both arguments, but the warning will still
be there. Or am I missing something? Bes,t
Federico Carminati
CERN-PH
1211 Geneva 23
Switzerland
Tel: +41 22 76 74959
Fax: +41 22 76 79480
Mobile: +41 76 487 4843
On 5 Oct 2006, at 07:18, pinskia at gcc dot gnu dot org wrote:
>
>
> --- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-05
> 05:18 ---
> (In reply to comment #2)
>> Subject: Re: Ambiguous warning with -Weffc++
>>
>> First of all a user can implement the correct behaviour, evaluating
>> just the first member and returning if true, continuing if false.
>> Second, the compiler tells me that I am evaluating the two members
>> when it has no way to tell this just by looking at the declaration of
>> the operator. So the warning is at best not justified when referring
>> only to the declaration, at worst wrong.
>
> You are incorrect thinking the user can implement the old behavior
> here as the
> compiler needs to evaluate it to pass to the function.
>
> And example about this is talking about:
> struct a {
> bool operator||(const a&);
> //operator bool();
> };
>
> a g();
>
> int f(a lhs)
> {
> return lhs || g();
> }
>
> In the non user defined case, lhs is evaulated and if that is true,
> we don't
> call g() at all. In the user defined case, both lhs and g() are
> evaulated as
> we need to call lhs.operator|| with the argument of the value of g().
>
> What it means by both arguments, it means both the left hand side
> (this) and
> the right hand side, the argument to the member operator. This is
> the correct
> warning and just from the sound of it, you don't understand how the
> builtin
> operator|| works or how having an user declared operator|| can work
> without
> evaulating both sides.
>
>
> --
>
> pinskia at gcc dot gnu dot org changed:
>
>What|Removed |Added
> --
> --
> Status|UNCONFIRMED |RESOLVED
> Resolution||INVALID
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29348
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
> You reported the bug, or are watching the reporter.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29348
[Bug fortran/27900] ICE using intrinsics as arguments
--- Comment #6 from pault at gcc dot gnu dot org 2006-10-05 07:45 --- (In reply to comment #5) > FX, > > When the len in "call sub(len)" is resolved, it is never given its correct > > return type, which leads to the ICE. I still don't understand why the > > implicit > > none is doing this on us... Paul, any idea? > > > ..bother, yes I was onto this a while back. I will consult my notes and > come back to you. I got severely stuck for some reason that I do not recall. > Paul I am glad to see that you are pursuing that one. I nearly bust my head on it my notes indicate that I had a fix that broke everything else; no details, so not much help I'm afraid. I think that you had better take it that I got nowhere! The bug that involves INDEX (PR???) is clearer. The mechanism, in trans-decl(gfc_get_extern_function_decl), for handling intrinsics simply does not allow that number of arguments. I tried to extend it by looking at isym->resolve.f1 and f2. It seemed to work but I did not have time to work on it. I saw the correspondence on comp.lang.fortran about this. I note that INDEX is explicitly allowable as an actual argument. That said, there is no mention in 13.13 of the optional argument BACK. Is that intentional, do you think? Since you are actively working on this, I have reassigned it to you. I hope that's OK? Best regards Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot org AssignedTo|pault at gcc dot gnu dot org|fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27900
[Bug target/29347] i386 mode switching clobbers fp exception handling bits
--- Comment #2 from uros at kss-loka dot si 2006-10-05 07:51 --- (In reply to comment #0) > The mode switching for floating point rounding that the i386 backend does > does not actually place mode switches, but rather the calculation of values > used for mode switches. Not only does that defeat the purpose of doing > lazy code motion of the mode switches themselves (this problem could easily > be remedied by handling the actual mode switches as a separate entity), > it also leads to information in the floating point control register being > clobbered if the user changes it (e.g. with feenableexcept: > http://www.gnu.org/software/libc/manual/html_node/Control-Functions.html) > between the calculation of the value used for a mode switch, and the point > where a mode switch actually takes place. > Please note, that gcc i386 description is missing FP control register definition, so x86_fnstcw_1 and x86_fldcw_1 patterns are totally wrong - they handle control register, not status register. After that, we can add correct clobber to x87 FP->int instructions. Regarding mode-switching values calculation: please note that x87 arithmetic instructions depend on control word. Currently, this is "solved" by setting and restoring control word just before/after "fist" instruction, otherwise (use (reg:HI FPCW_REG)) has to be added to all affected instructions. I think that it has to be added anyway, if fesetround() is to be used. Some time ago, I had a patch that added FPCW_REG to i386.h, I'll look if I can still found it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29347
[Bug fortran/27900] ICE using intrinsics as arguments
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-10-05 08:05 --- (In reply to comment #6) > I am glad to see that you are pursuing that one. I nearly bust my head on it > my notes indicate that I had a fix that broke everything else; no details, so > not much help I'm afraid. I think that you had better take it that I got > nowhere! Well, this is really about the resolution scheme, which I still don't fully understand, so I'm in the dark here too. I'll give it a longer shot over the next week-end. > The bug that involves INDEX (PR???) is clearer. The mechanism, in > trans-decl(gfc_get_extern_function_decl), for handling intrinsics simply does > not allow that number of arguments. I tried to extend it by looking at > isym->resolve.f1 and f2. It seemed to work but I did not have time to work on > it. That bug is fixed by my submitted patch about INTRINSICS (http://gcc.gnu.org/ml/fortran/2006-10/msg00022.html). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27900
[Bug fortran/27588] -fbounds-check should catch substring out of range accesses
--- Comment #5 from patchapp at dberlin dot org 2006-10-05 08:07 --- Subject: Bug number PR27588 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00234.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27588
[Bug pch/29353] New: ICE: testsuite failure with max-unswitch-insns=1000 max-unswitch-level=4 max-aliased-vops=10000
When I bootstrap gcc with the commands given below I get a testsuite failure in libstdc++-v3/testsuite/25_algorithms/rotate/1.cc It might be a pch problem, since that ice does not occur if I compile the testsuite file without using any library Michael Cieslinski Command to build and test gcc: export CFLAGS="-O3 --param max-unswitch-insns=1000 \ --param max-unswitch-level=4 --param max-aliased-vops=1" export CXXFLAGS=$CFLAGS ../gcc-4.2-20060930/configure --prefix=/usr/local/gcc42d --program-suffix=42d \ --with-arch=opteron --enable-languages=c,c++ --enable-__cxa_atexit \ --disable-nls --enable-threads=posix --disable-multilib --enable-checking make -j4 bootstrap make check -j -k output in libstdc++.log: Executing on host: /srv/cie019/gcc/gcc42d/obj/./gcc/g++ -shared-libgcc -B/srv/cie019/gcc/gcc42d/obj/./gcc -nostdinc++ -L/srv/cie019/gcc/gcc42d/obj/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/srv/cie019/gcc/gcc42d/obj/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/usr/local/gcc42d/x86_64-unknown-linux-gnu/bin/ -B/usr/local/gcc42d/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/gcc42d/x86_64-unknown-linux-gnu/include -isystem /usr/local/gcc42d/x86_64-unknown-linux-gnu/sys-include -g -O2 -D_GLIBCXX_ASSERT -ffunction-sections -fdata-sections -fmessage-length=0 -O3 --param max-unswitch-insns=1000 --param max-unswitch-level=4 --param max-aliased-vops=1 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/srv/cie019/gcc/gcc42d/obj/x86_64-unknown-linux-gnu/ libstdc++-v3/include/x86_64-unknown-linux-gnu -I/srv/cie019/gcc/gcc42d/obj/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/srv/cie019/gcc/gcc42d/gcc-4.2-20060930/libstdc++-v3/libsupc++ -I/srv/cie019/gcc/gcc42d/gcc-4.2-20060930/libstdc++-v3/include/backward -I/srv/cie019/gcc/gcc42d/gcc-4.2-20060930/libstdc++-v3/testsuite/util testsuite_abi.o testsuite_allocator.o testsuite_character.o testsuite_hooks.o twister_rand_gen.o verified_cmd_line_input.o prog_bar.o elapsed_timer.o /srv/cie019/gcc/gcc42d/gcc-4.2-20060930/libstdc++-v3/ testsuite/25_algorithms/rotate/1.cc -include bits/stdc++.h -lm -o ./1.exe(timeout = 600) /srv/cie019/gcc/gcc42d/obj/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/stl_algo.h: In function 'void std::__rotate(_RandomAccessIterator, _RandomAccessIterator, _RandomAccessIterator, std::random_access_iterator_tag) [with _RandomAccessIterator = __gnu_test::random_access_iterator_wrapper]': /srv/cie019/gcc/gcc42d/obj/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/stl_algo.h:1833: internal compiler error: in compare_name_with_value, at tree-vrp.c:3561 Please submit a full bug report, with preprocessed source if appropriate. -- Summary: ICE: testsuite failure with max-unswitch-insns=1000 max- unswitch-level=4 max-aliased-vops=1 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pch AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: micis at gmx dot de GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29353
[Bug tree-optimization/29333] Jump threading getting in the way of PHI-OPT
--- Comment #3 from roberto dot costa at st dot com 2006-10-05 08:15 --- I tested what happens if the first PHI-OPT pass is moved right before the first VRP pass in gcc/passes.c It looks like PHI-OPT should be run both before and after VRP and DOM. The example reported shows that, when PHI-OPT is run after VRP and DOM, it misses some MAX_EXPR and MIN_EXPR generation. gcc/testsuite/gcc.dg/tree-ssa/phi-opt-5.c shows that, when PHI-OPT anticipates VRP and DOM, it misses some MAX_EXPR and MIN_EXPR generation as well. Should an additional PHI-OPT pass be added before VRP and DOM? (In this case, a few testsuite examples should also be changed in order to consider what happens after PHI-OPT2 instead of PHI-OPT1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29333
[Bug driver/17621] Add option to have GCC not search $(prefix)
--- Comment #14 from carlos at codesourcery dot com 2006-10-05 08:33 --- GCC_EXEC_PREFIX does not control the search directories for header files. Could you verify that your target actually compiles before applying the patches? Both gcc and cpp need to be taught taught not to search the configured prefix. The patch I provided only the first step. The second step is to improve cpp. I will post a new set of patches for this on the weekend. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17621
[Bug target/28307] [4.1/4.2 Regression] pthread functions in libgcc not weak any more on Tru64 UNIX
--- Comment #5 from markus dot schoepflin at comsoft dot de 2006-10-05 08:49 --- (In reply to comment #3) > With the attached patch, at least the unmodified boehm-gc 6.7 tested > successfully. I stumbled accross this bug when investigating why the boost thread library tests started to fail from 4.1.0 onwards on this platform. I can confirm that the suggested patch fixes things in such a way, that the regression tests for the boost thread library pass sucessfully when testing with 4.1.1. Please note that the patch didn't apply cleanly to 4.1.1, but I was able to apply it manually. -- markus dot schoepflin at comsoft dot de changed: What|Removed |Added CC||markus dot schoepflin at ||comsoft dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28307
[Bug libstdc++/29354] New: Error when seeking on an ostringstream
The function seekp(pos_type) fails on an empty stream,
even when the target position is the value returned
by tellp.
---
#include
#include
#include
int
main()
{
std::ios::pos_type const
err = std::ios::pos_type( std::ios::off_type( -1 ) ) ;
std::ostringstream os ;
std::ios::pos_type pos = os.tellp() ;
if ( pos == err ) {
std::cout << "tell failed" << std::endl ;
} else {
os.seekp( pos ) ;
if ( ! os ) {
std::cout << "seek failed" << std::endl ;
}
}
return 0 ;
}
---
Outputs "seek failed". According to the standard,
seekp() calls seekpos() in stringbug, which can
only fail (here) if the position is invalide.
And tellp() cannot return an invalide position
other than -1 (correctly casted).
--
Summary: Error when seeking on an ostringstream
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jkanze at cheuvreux dot com
GCC build triplet: sparc-sun-solaris2.8
GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29354
[Bug libstdc++/29354] Error when seeking on an ostringstream
--- Comment #1 from pcarlini at suse dot de 2006-10-05 09:28 --- Ok, thanks for the report. The issue is the following: tellp() calls pubseekoff, whereas seekp() calls pubseekpos. Since we are implementing the resolution of DR 453, which allows pubseekoff to not fail when the stream is empty, we have to adjust consistently seekpos also to not fail. -- 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-10-05 09:28:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29354
[Bug tree-optimization/29290] [4.1 Regression] SPEC CPU2000 178.galgel ICE using -O3 -ftree-loop-linear
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-10-01 02:08:01 |2006-10-05 10:02:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29290
[Bug driver/17621] Add option to have GCC not search $(prefix)
--- Comment #15 from eweddington at cso dot atmel dot com 2006-10-05 12:49 --- (In reply to comment #14) > GCC_EXEC_PREFIX does not control the search directories for header files. > Could > you verify that your target actually compiles before applying the patches? In the test that I did, is I relocated the toolchain on my machine but I also had the original configured prefix available. In this case the toolchain correctly found and built a test program including system header files. When I made the configure prefix directory unavailable (renaming it), then the toolchain failed because it couldn't find the system header files. The toolchain has worked in the past with version 3.4.x, but with a different patch. HTH Eric -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17621
[Bug target/28924] x86 sync builtins fail for char and short memory operands
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-09-01 14:39:25 |2006-10-05 12:57:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28924
[Bug c++/29356] New: typedef name denoting unnamed class should have external linkage
In this code:
typedef class
{
public:
void m();
} C;
void
C::m()
{
}
void
f()
{
C c;
c.m();
}
// { dg-final { scan-assembler "(.globl|.global)\[ \t]+[_]+ZN1C1mEv" } }
C is a typedef name which accroding to 7.1.3 is used to denote the unnamed
class. 3.5 ; 4, 3rd item, specifies that this name has external linkage.
Hence, 3.5 ; 5 specifies that C::m ( __ZN1C1mEv) should have external linkage.
However, gcc fails to emit the .global directive for this symbol.
--
Summary: typedef name denoting unnamed class should have external
linkage
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: link-failure
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29356
[Bug c++/29356] typedef name denoting unnamed class should have external linkage
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-05 14:25 --- I think *** This bug has been marked as a duplicate of 7221 *** -- 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=29356
[Bug c++/7221] wrong linkage in member functions of typedef-named classes
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-05 14:25 --- *** Bug 29356 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||amylaar at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7221
[Bug tree-optimization/29353] ICE: testsuite failure with max-unswitch-insns=1000 max-unswitch-level=4 max-aliased-vops=10000
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-05 14:30 --- As far as I can tell this has nothing to do with PCH. >It might be a pch problem, since that ice does not occur if I compile the > testsuite file without using any library What do you mean by this? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|pch |tree-optimization Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29353
[Bug debug/28980] [4.0/4.1 Regression] ICE in loc_descriptor_from_tree_1 with -g
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-10-05 14:33 --- Subject: Bug 28980 Author: pinskia Date: Thu Oct 5 14:33:46 2006 New Revision: 117456 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117456 Log: 2006-10-05 Andrew Pinski <[EMAIL PROTECTED]> PR debug/28980 * dwarf2out.c (loc_descriptor_from_tree_1): Handle FUNCTION_DECL. 2006-10-05 Andrew Pinski <[EMAIL PROTECTED]> PR debug/28980 * gcc.c-torture/compile/debugvlafunction-1.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/compile/debugvlafunction-1.c - copied unchanged from r116939, trunk/gcc/testsuite/gcc.c-torture/compile/debugvlafunction-1.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/dwarf2out.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28980
[Bug debug/28980] [4.0 Regression] ICE in loc_descriptor_from_tree_1 with -g
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-10-05 14:34 --- Fixed in 4.1 also. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1 Regression] ICE in |[4.0 Regression] ICE in |loc_descriptor_from_tree_1 |loc_descriptor_from_tree_1 |with -g |with -g http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28980
[Bug target/28701] [4.1/4.2 regression] ABI test failures building libstdc++ on a glibc-2.4 based system
--- Comment #10 from debian-gcc at lists dot debian dot org 2006-10-05 15:13 --- are other patches than r111381 (trunk) required for a backport of long-double-128 to the 4.1 branch? Matthias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28701
[Bug target/27287] [4.1 Regression] returning constant double
--- Comment #41 from dje at gcc dot gnu dot org 2006-10-05 15:18 --- Subject: Bug 27287 Author: dje Date: Thu Oct 5 15:18:18 2006 New Revision: 117458 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117458 Log: Backport from mainline 2006-09-11 Guenter Roeck <[EMAIL PROTECTED]> David Edelsohn <[EMAIL PROTECTED]> PR target/27287 * config/rs6000/spe.md (frob_df_di): Remove %H. (frob_di_df): Remove %H. Change evmergelo to mr. (frob_di_df_2): Remove %H. Change evldd to two loads. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/rs6000/spe.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
<$rstr7-19b>
<$rstr7-19b>
[Bug target/28701] [4.1/4.2 regression] ABI test failures building libstdc++ on a glibc-2.4 based system
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-10-05 15:40 --- This looks related to PR 26926. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||26926 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28701
[Bug testsuite/27221] g++.dg/ext/alignof2.C fails on powerpc-darwin (and powerpc-aix)
-- 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 |2006-10-05 15:41:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27221
[Bug target/27968] gcc emits (undefined) ffreep opcode which is not understood by Solaris' /usr/ccs/bin/as when tuning for Athlon or Opteron CPUs
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-05 15:44 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27968
[Bug target/27287] [4.1 Regression] returning constant double
--- Comment #42 from pinskia at gcc dot gnu dot org 2006-10-05 15:47 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
[Bug bootstrap/28400] install-driver is missing $(exeext) from gcc-$(version)
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-05 15:48 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|other |bootstrap Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-05 15:48:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28400
[Bug inline-asm/29357] New: inline asm %c0 template form not documented
the form %c0, as in asm ( "movl $42, %c0(%1)" : : "i"(offsetof(...)), "r"(...) : "memory" ); is not documented. -- Summary: inline asm %c0 template form not documented Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: inline-asm AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: avi at argo dot co dot il GCC build triplet: N/A GCC host triplet: N/A GCC target triplet: N/A http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29357
[Bug inline-asm/29357] inline asm %c0 template form not documented
--- Comment #1 from avi at argo dot co dot il 2006-10-05 16:05 --- Created an attachment (id=12384) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12384&action=view) proposed documentation patch I don't have a coypright assignment, but most of this is copied verbatim from the internals documentation. I added three lines. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29357
[Bug libstdc++/11953] _REENTRANT defined when compiling non-threaded code.
--- Comment #41 from debian-gcc at lists dot debian dot org 2006-10-05 16:06 --- the patch was applied in the redhat/gcc-4_1-branch, not in the gcc-4_1-branch. either the target milestone should be changed or the bug reopened. Matthias -- debian-gcc at lists dot debian dot org changed: What|Removed |Added CC||debian-gcc at lists dot ||debian dot org, gdr at gcc ||dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11953
[Bug fortran/27900] ICE using intrinsics as arguments
--- Comment #8 from paulthomas2 at wanadoo dot fr 2006-10-05 16:17 --- Subject: Re: ICE using intrinsics as arguments FX >That bug is fixed by my submitted patch about INTRINSICS >(http://gcc.gnu.org/ml/fortran/2006-10/msg00022.html). > > > > I'll review it tomorrow - I am going to give gfortran a break tonight! Whilst I am about it, I will put my thinking cap on about PR27900, whilst I am about it. At lunchtime, I made an automatic loop reverser for the scalarizer. It works fine but breaks other cases. A very promising start for one hour's work though (I have been cogitating about this for some weeks, I must admit.). A. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27900
[Bug fortran/28415] 4.2.0 ICE when using automatic array and -fno-automatic
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||10/msg00258.html Status|NEW |ASSIGNED Last reconfirmed|2006-07-18 08:44:59 |2006-10-05 16:43:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28415
[Bug libgcj/29324] add wait handling hook
--- Comment #5 from daney at gcc dot gnu dot org 2006-10-05 17:02 --- Another idea: In the SIGCHLD signal handler record the pid of the process that exited. Then look it up in the pidToProcess map. If it belongs to the libgcj runtime, then do waitpid(pid, ...) on it. Otherwise ignore it assuming it belongs to code external to libgcj. It would be nice if we could call into libgcj from the signal handler, but I don't think that we can. :( You could get even fancier and chain the SIGCHLD signal handler to any handler that may have been previously installed. We would expect the same of external code that installed a SIGCHLD handler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29324
[Bug c/29358] New: Warning issued two times with snprintf
The following snipped of code compiled with -Wall emits two times the same
warning :
#include
#include
#include
int main(void)
{
uint32_t foo = 42;
char bar[] = "bla";
char *buffer = malloc(10);
snprintf(buffer, 10, "%lu %s\n", foo, bar);
free(buffer);
return 0;
}
gcc -Wall bug.c
bug.c: In function 'main':
bug.c:11: warning: format '%lu' expects type 'long unsigned int', but argument
4 has type 'uint32_t'
bug.c:11: warning: format '%lu' expects type 'long unsigned int', but argument
4 has type 'uint32_t'
I tried on several flavors (4.0.3, 4.0.4, 4.1.2), the result is the same. If
sprintf is used instead of snprintf, the warning is emitted only one time.
Tests were made on x68 platforms with gcc for x86 and mipsel
--
Summary: Warning issued two times with snprintf
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pf dot hugues at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29358
[Bug c/29358] Warning issued two times with snprintf
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-05 17:07 --- uint32_t is unsigned int on those targets and this is not a bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29358
[Bug c/29358] Warning issued two times with snprintf
--- Comment #2 from joseph at codesourcery dot com 2006-10-05 17:10 --- Subject: Re: Warning issued two times with snprintf On Thu, 5 Oct 2006, pinskia at gcc dot gnu dot org wrote: > uint32_t is unsigned int on those targets and this is not a bug. Did you read the bug report? The problem is that the warning is issued twice when it should be issued once. I'd guess that the issue that that the system header declares the function with a format attribute, and such an attribute is also built in, and the duplicate attributes don't get eliminated properly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29358
[Bug c/29358] Warning issued two times with snprintf
--- Comment #3 from pf dot hugues at gmail dot com 2006-10-05 17:11 --- I don't contest the warning, but why is it printed 2 times ?! -- pf dot hugues at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29358
[Bug c/29358] Warning issued two times with snprintf
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-05 17:15 --- (gdb) p debug_tree (function) SI size unit size align 32 symtab 0 alias set -1 attributes value chain chain >>> chain value > chain value chain arg-types chain chain >>> pointer_to_this > unsigned SI size unit size align 32 symtab 0 alias set -1> constant invariant arg 0 addressable used nothrow public external in_system_header built-in decl_3 decl_5 SI defer-output file /home/a pinski/src/gcc-3c/gcc-4.1-build/install/ppu/sysroot//usr/include/stdio.h line 353 built-in BUILT_IN_NORMAL:BUILT_IN_SNPRINTF attributes >> $4 = void (gdb) p debug_generic_expr(0xb7d4c4c8) format printf, 3, 4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29358
[Bug middle-end/29358] Warning issued two times with snprintf
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-05 17:17 --- (In reply to comment #2) > Did you read the bug report? The problem is that the warning is issued > twice when it should be issued once. Woops, I am too tried > > I'd guess that the issue that that the system header declares the function > with a format attribute, and such an attribute is also built in, and the > duplicate attributes don't get eliminated properly. That is what it looks like from debug_tree output. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29358
[Bug libgcj/29324] add wait handling hook
-- daney at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |daney at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-10-02 18:39:54 |2006-10-05 17:24:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29324
[Bug fortran/28415] 4.2.0 ICE when using automatic array and -fno-automatic
--- Comment #4 from patchapp at dberlin dot org 2006-10-05 17:32 --- Subject: Bug number PR fortran/28415 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00258.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28415
[Bug fortran/19260] & not required when splitting a token in continuation
--- Comment #9 from patchapp at dberlin dot org 2006-10-05 17:34 --- Subject: Bug number PR19260 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00255.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19260
[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
--- Comment #2 from kargl at gcc dot gnu dot org 2006-10-05 17:54 ---
(In reply to comment #0)
>
> 1. Whether a certain minimum version of GMP/MPFR is required to avoid known
> bugs, etc.
See my recent patch to toplevel configure.in. THe minimum required
versions should be gmp-4.1.x and mpfr-2.2.0.
> 2. Whether we should include GMP/MPFR in the svn archive like we do for intl
> and zlib.
I think that gmp and mpfr would need to be imported into GCC. If you read the
gmp webpage, it often contains warnings about using newer versions of GCC to
gmp because of bugs.
> 3. Whether GMP/MPFR works on all the platforms/configurations that GCC
> supports. Are we ready to require a GMP/MPFR port for every port of GCC?
>
> 4. If we don't do #2 and there is no system GMP/MPFR or the system lib is too
> old, or if we trip over #3 and can't have GMP/MPFR, then what? Do we require
> the user to go get/port it, or silently eliminate this optimization during the
> build process?
I could be mistaken, but I believe one can configure gmp for a generic library
that does not use any machine (ie., cpu) specific assembly.
If you haven't read fortran/{arith.c,simplify.c}, then I'd suggest
that you take a look to see what gmp/mpfr can do.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
[Bug c++/29359] New: bad relocation section name `' in .o causes segv of ld.
I have been encountering the following problem for several weeks. I compile and create few c++ shared libraries (can happen with just one, so it has nothing to do with the number). I then attempt to link a program and I get the following type of segv during the link step: collect2: ld terminated with signal 11 [Segmentation fault] /usr/bin/ld: build/x86-64.linux/gcc64/cc-g/subscribeClient.o: bad relocation section name `' It happens with both -O2 and -g compiled code (although it is a bit more frequent with -g code). In addition, usually if it happens with -O2 code then it will work fine when I compiled with -g (or vice-versa). I will attach a test case with a README file that shows how to reproduce. -- Summary: bad relocation section name `' in .o causes segv of ld. Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jmbnyc at gmail dot com GCC build triplet: gcc version 4.1.1 20060525 (Red Hat 4.1.1-1) GCC host triplet: Redhat FC5: 2.6.17-1.2187_FC5 GCC target triplet: x86_64 GNU/Linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29359
[Bug c++/29359] bad relocation section name `' in .o causes segv of ld.
--- Comment #1 from jmbnyc at gmail dot com 2006-10-05 18:18 --- Created an attachment (id=12385) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12385&action=view) gzip'd tar file with README that shows how to reproduce -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29359
[Bug c++/29359] bad relocation section name `' in .o causes segv of ld.
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-05 18:18 --- *** This bug has been marked as a duplicate of 29244 *** *** This bug has been marked as a duplicate of 29244 *** -- 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=29359
[Bug c++/29244] bad relocation section name
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-05 18:18 --- *** Bug 29359 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29244
[Bug c++/29359] bad relocation section name `' in .o causes segv of ld.
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-05 18:19 --- Didn't I already tell you to post this to binutils? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29359
[Bug c++/29359] bad relocation section name `' in .o causes segv of ld.
--- Comment #4 from jmbnyc at gmail dot com 2006-10-05 18:23 --- (In reply to comment #3) > Didn't I already tell you to post this to binutils? > yes you did and I did what you asked. However, I now believe that the problem is with the compiler. I also came up with a test case that demonstrates the problem. This is new info and why it should not be considered a duplicate. At the orig post I did not have a test case to demonstrate the problem. This problem is causing me great pain. Every time I change code, I get this problem and thus I can't get anything accomplished. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29359
[Bug c++/29359] bad relocation section name `' in .o causes segv of ld.
--- Comment #5 from jmbnyc at gmail dot com 2006-10-05 18:27 --- Subject: Re: bad relocation section name `' in .o causes segv of ld. Look, I am not trying to be a jerk, but this new filing has a test case associated with it (another thing that you asked for). In addition, I took your advice and filed the bug with binutils. However, I now believe that the problem is with gcc and not ld. You based your judgement on the segv coming from ld. If you look at the test and come to the same conclusion then I will not bother you again. This problem is causing me great pain. Every time I change code, I get this problem and thus I can't get anything accomplished. /JMB On 5 Oct 2006 18:19:30 -, pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-05 18:19 > --- > Didn't I already tell you to post this to binutils? > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29359 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. > You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29359
[Bug c++/29359] bad relocation section name `' in .o causes segv of ld.
--- Comment #6 from jmbnyc at gmail dot com 2006-10-05 18:41 --- This bug might be a duplicate as you suggest but (my fault for opening new instead of updating original) it is not 'resolved'. On the original post you said to report to binutils because you suggested the bug was not in the compiler. However, I now believe that the bug is in the compiler. I attached a test case with a README on how to reproduce. If you look at this, I think you will see that it is the compiler that produces bad output that ld chokes on. If you disagree with that assertion then please tell me. -- jmbnyc at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29359
[Bug middle-end/29359] bad relocation section name `' in .o causes segv of ld.
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-05 18:48 --- > If you disagree with that assertion then please tell me. Yes I do disagree because GCC only produces a .s file which then binutils assembles and links. Then again you are using a GCC and binutils that were modified by Redhat which mean you should report it to them first. If you try a FSF GCC and binutils and it fails, then you should report it to us but only after you have tried. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c++ |middle-end Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29359
[Bug middle-end/29359] bad relocation section name `' in .o causes segv of ld.
--- Comment #8 from jmbnyc at gmail dot com 2006-10-05 18:48 --- Subject: Re: bad relocation section name `' in .o causes segv of ld. One last comment. From the below, I think it is clear that the compiler is the problem. If I compile with -g then I get the problem, however if I compile without -g then I don't get the problem. Perhaps I am wrong, but it appears that -g is producing .o that gives ld a problem. [EMAIL PROTECTED] bugs]$ /usr/bin/g++ -ftemplate-depth-64 -Wno-ctor-dtor-privacy -Wreturn-type -D_GNU_SOURCE -fPIC -m64 -D_REENTRANT -D_GNU_SOURCE -D__USE_GNU -I. -I.. -o SPTest.o -c SPTest.i [EMAIL PROTECTED] bugs]$ g++ -g -L. -o SPTest.1 SPTest.o -lutil_gcc64 -lstdc++ -lrt -lpthread [EMAIL PROTECTED] bugs]$ /usr/bin/g++ -g -ftemplate-depth-64 -Wno-ctor-dtor-privacy -Wreturn-type -D_GNU_SOURCE -fPIC -m64 -D_REENTRANT -D_GNU_SOURCE -D__USE_GNU -I. -I.. -o SPTest.o -c SPTest.i [EMAIL PROTECTED] bugs]$ g++ -g -L. -o SPTest.1 SPTest.o -lutil_gcc64 -lstdc++ -lrt -lpthread collect2: ld terminated with signal 11 [Segmentation fault] /usr/bin/ld: SPTest.o: bad relocation section name `' /usr/bin/ld: SPTest.o: bad relocation section name `' /usr/bin/ld: SPTest.o: bad relocation section name `' On 10/5/06, Jeffrey M. Birnbaum <[EMAIL PROTECTED]> wrote: > Look, I am not trying to be a jerk, but this new filing has a test > case associated with it (another thing that you asked for). In > addition, I took your advice and filed the bug with binutils. However, > I now believe that the problem is with gcc and not ld. You based your > judgement on the segv coming from ld. If you look at the test and come > to the same conclusion then I will not bother you again. > > This problem is causing me great pain. Every time I change code, I get > this problem > and thus I can't get anything accomplished. > > /JMB > > On 5 Oct 2006 18:19:30 -, pinskia at gcc dot gnu dot org > <[EMAIL PROTECTED]> wrote: > > > > > > --- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-05 18:19 > > --- > > Didn't I already tell you to post this to binutils? > > > > > > -- > > > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29359 > > > > --- You are receiving this mail because: --- > > You are on the CC list for the bug, or are watching someone who is. > > You reported the bug, or are watching the reporter. > > > > > -- > /JMB > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29359
[Bug middle-end/29359] bad relocation section name `' in .o causes segv of ld.
--- Comment #9 from jmbnyc at gmail dot com 2006-10-05 18:51 --- Subject: Re: bad relocation section name `' in .o causes segv of ld. Fair enough. I did report it to them, but never heard back. Uli Drepper is going to try to help me get to the right people. He has also offered to look at the .s file to see if he see anything suspicious. /JMB On 5 Oct 2006 18:48:06 -, pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-05 18:48 > --- > > If you disagree with that assertion then please tell me. > Yes I do disagree because GCC only produces a .s file which then binutils > assembles and links. > Then again you are using a GCC and binutils that were modified by Redhat which > mean you should report it to them first. If you try a FSF GCC and binutils > and > it fails, then you should report it to us but only after you have tried. > > > -- > > pinskia at gcc dot gnu dot org changed: > >What|Removed |Added > > Status|UNCONFIRMED |RESOLVED > Component|c++ |middle-end > Resolution||INVALID > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29359 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. > You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29359
[Bug inline-asm/23200] [4.0/4.1/4.2 regression] rejects "i"(&var + 1)
--- Comment #25 from stsp at users dot sourceforge dot net 2006-10-05 19:29 --- > "i"(&var) of course can't work with -fpic, I tried it on an x86_64 today, and it seems to work. If I use -m32, then it doesn't. Why? > it would only work at the expense > of text relocations, but those are not allowed on some architectures and > highly undesirable on the rest of architectures. Is this to always keep the .text section r/o? > In position independent code, > &var typically means you need to load that address from global offset table So, as I understand your answer, the relocation at dynamic-link time is not implemented at all (even on the arches where it is possible)? > into a register, and a register of course can't satisfy "i" constraint. Thanks for the hint. It looks like the things like "a"(&var) do work with -fpic, which should be fine for my needs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200
[Bug c++/29360] New: temporary to which static storage duration reference is bound destroyed too early
According to 12.2 ; 5, in the following code:
int count;
class C
{
public:
int i;
C() : i(1) { ++count;}
C(const C &c) : i(c.i) { ++count;}
~C() { --count;}
};
int
f ()
{
static const C &c = C();
return c.i;
}
int
main ()
{
int i = f ();
return count < i;
}
the temporary to which the reference c is bound in f should persist till
the program exits. However, although it is only initialized once (as it
ought to), it is destroyed each time the function f returns.
--
Summary: temporary to which static storage duration reference is
bound destroyed too early
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29360
[Bug c/29361] New: Code seg faults
I have some code which when compiled: Using gcc 4.0.3(ubuntu 4.0.3-lubuntu5) I have no problems. Using gcc version 4.1.0 (SUSE Linux) and -O2 or -O3, I have no problems. HOWEVER, using no compile flags, the code seg faults. Is it worth generating a small test case and test data file? -- Summary: Code seg faults Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dmccullough at hpti dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29361
[Bug c++/28301] [4.0/4.1 regression] ICE with broken specialization
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-10-05 19:58 --- Fixed on mainline by Lee's patch for PR27667. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 regression] ICE|[4.0/4.1 regression] ICE |with broken specialization |with broken specialization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28301
[Bug c++/29021] [4.2 regression] ICE on invalid use of "*" in template
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-10-05 20:31 --- The bug is actually only a 4.2 regression as it only affected mainline (sorry for the incorrect info). Yes, indeed "affected" and not "affects": The bug has been fixed by Mark's patch for PR 29105. Since the backtraces of the bugs are the same, I'm marking this PR as a duplicate. *** This bug has been marked as a duplicate of 29105 *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE Summary|[4.0/4.1/4.2 regression] ICE|[4.2 regression] ICE on |on invalid use of "*" in|invalid use of "*" in |template|template Target Milestone|4.0.4 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29021
[Bug c++/29105] [4.2 Regression] segfault in add_candidates with a non template base class and a template member function
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-10-05 20:31 --- *** Bug 29021 has been marked as a duplicate of this bug. *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29105
[Bug middle-end/29361] Code seg faults
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-05 20:36 --- well a testcase is needed to reproduce the problem in the first place anyways so yes a testcase. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29361
[Bug c++/29360] temporary to which static storage duration reference is bound destroyed too early
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-05 20:38 --- *** This bug has been marked as a duplicate of 20416 *** -- 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=29360
[Bug c++/20416] Incorrect lifetime for temporary with static const reference
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-05 20:38 --- *** Bug 29360 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||amylaar at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20416
[Bug libgcj/29362] New: NullPointerException in gnu.xml.transform.TransformerImpl.strip(libgcj.so.7rh)
The new FC6 eclipse cdt generates a java.lang.NullPointerException everytime it tries to save the .cdtproject project file. This occurs when changes are made to a CDT project. For example, adding a new source folder causes the error. I have isolated the problem to a stand-alone testcase which reads in a current .cdtproject file to prime the information, then goes about the actions taken by the save call. -bash-3.1$ java CDescription Exception in thread "main" java.lang.NullPointerException at gnu.xml.transform.TransformerImpl.strip(libgcj.so.7rh) at gnu.xml.transform.TransformerImpl.strip(libgcj.so.7rh) at gnu.xml.transform.TransformerImpl.strip(libgcj.so.7rh) at gnu.xml.transform.TransformerImpl.strip(libgcj.so.7rh) at gnu.xml.transform.TransformerImpl.transform(libgcj.so.7rh) at CDescription.getAsXml(CDescription.java:93) at CDescription.run(CDescription.java:99) at CDescription.main(CDescription.java:113) -- Summary: NullPointerException in gnu.xml.transform.TransformerImpl.strip(libgcj.so.7rh) Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jjohnstn at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29362
[Bug libgcj/29362] NullPointerException in gnu.xml.transform.TransformerImpl.strip(libgcj.so.7rh)
--- Comment #1 from jjohnstn at redhat dot com 2006-10-05 20:48 --- Created an attachment (id=12386) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12386&action=view) Testcase that exhibits problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29362
[Bug middle-end/29359] bad relocation section name `' in .o causes segv of ld.
--- Comment #10 from drow at gcc dot gnu dot org 2006-10-05 20:49 --- FYI, the testcase does not build with my system g++ 4.1.2; remove the "static" from 'extern "C" static'. The result does not choke my system's binutils, i.e. it links successfully. If I use the provided .s file instead of compiling the .i file, it again links successfully. Therefore, I conclude that this is a bug in the linker (or possibly assembler) on your platform, and there is no bug in GCC. This is the same conclusion Andrew came to, except that I actually looked at the bug. Andrew, again I need to ask you to be more polite to bug submitters. You shouldn't need to be reminded of this so often! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29359
[Bug middle-end/29359] bad relocation section name `' in .o causes segv of ld.
--- Comment #11 from jmbnyc at gmail dot com 2006-10-05 20:57 --- Subject: Re: bad relocation section name `' in .o causes segv of ld. Thanks for looking at it. Uli Drepper helped me to look at the asm and conclude (just about one hour ago) that indeed the problem is with "as". It clearly screws up with symbols names. Uli tried with binutils from FC6 and does not get the problem. Also, thanks for pointing out the extern "C" thing. I moved some code around and left that in which was not good. I am going to try to upgrade to the binutils with FC6 and hope that it solves the problem. I would file a report with the "as" guys. BTW, I know that you guys are busy, so thanks for taking a look. This problem has been killing my development. /JMB On 5 Oct 2006 20:49:45 -, drow at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #10 from drow at gcc dot gnu dot org 2006-10-05 20:49 --- > FYI, the testcase does not build with my system g++ 4.1.2; remove the "static" > from 'extern "C" static'. The result does not choke my system's binutils, > i.e. > it links successfully. > > If I use the provided .s file instead of compiling the .i file, it again links > successfully. Therefore, I conclude that this is a bug in the linker (or > possibly assembler) on your platform, and there is no bug in GCC. This is the > same conclusion Andrew came to, except that I actually looked at the bug. > > Andrew, again I need to ask you to be more polite to bug submitters. You > shouldn't need to be reminded of this so often! > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29359 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. > You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29359
[Bug c++/27720] ICE with initialization of invalid variable
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-10-05 21:00 --- Fixed on mainline by Lee's patch for PR26938. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27720
[Bug libgcj/29362] NullPointerException in gnu.xml.transform.TransformerImpl.strip(libgcj.so.7rh)
--- Comment #2 from jjohnstn at redhat dot com 2006-10-05 21:12 --- Created an attachment (id=12387) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12387&action=view) sample cdtproject file that is used by test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29362
[Bug fortran/24398] invalid module file gives weird error
--- Comment #8 from pault at gcc dot gnu dot org 2006-10-05 21:20 --- Created an attachment (id=12388) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12388&action=view) A fix for this PR This checks for the presence of "GFORTRAN module" as the first utterances in the .mod file. The error message on this not being so is evident in the patch and is even understandable. *sigh* Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24398
[Bug xml/29362] NullPointerException in gnu.xml.transform.TransformerImpl.strip(libgcj.so.7rh)
--- Comment #3 from mark at gcc dot gnu dot org 2006-10-05 22:01 --- Confirmed with classpath CVS: $ /usr/local/jamvm/bin/jamvm CDescription java.lang.NullPointerException at gnu.xml.transform.TransformerImpl.strip(TransformerImpl.java:452) at gnu.xml.transform.TransformerImpl.strip(TransformerImpl.java:459) at gnu.xml.transform.TransformerImpl.strip(TransformerImpl.java:459) at gnu.xml.transform.TransformerImpl.strip(TransformerImpl.java:459) at gnu.xml.transform.TransformerImpl.transform(TransformerImpl.java:330) at CDescription.getAsXml(CDescription.java:93) at CDescription.run(CDescription.java:99) at CDescription.main(CDescription.java:113) -- mark at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|libgcj |xml Ever Confirmed|0 |1 Product|gcc |classpath Last reconfirmed|-00-00 00:00:00 |2006-10-05 22:01:37 date|| Version|4.1.1 |unspecified http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29362
[Bug xml/29362] NullPointerException in gnu.xml.transform.TransformerImpl.strip(libgcj.so.7rh)
--- Comment #4 from tromey at gcc dot gnu dot org 2006-10-05 22:03 --- Also happens with gcc svn head. I was also going to CC dog :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29362
[Bug c++/28346] [4.0 regression] ICE creating pointer-to-reference-member
--- Comment #7 from reichelt at gcc dot gnu dot org 2006-10-05 23:28
---
Because of Jason's patch for PR 28346 the code is now wrongly accepted
on the 4.0 branch. With a slightly different testcase I can still
trigger the ICE, though:
==
bool b;
template struct A
{
int& i;
A();
~A() { b = (&A::i == &A::i); }
};
A<0> a;
==
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28346
[Bug c++/28346] [4.0 regression] ICE creating pointer-to-reference-member
--- Comment #8 from reichelt at gcc dot gnu dot org 2006-10-05 23:29 --- I meant Jason's patch for PR 26696, of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28346
[Bug c++/29363] New: [4.2 regression] ICE throwing undeclared object
The following invalid code snippet triggers an ICE on mainline:
==
template void foo()
{
throw A();
struct A {} a;
}
template void foo<0>();
==
bug.cc: In function 'void foo()':
bug.cc:3: error: there are no arguments to 'A' that depend on a template
parameter, so a declaration of 'A' must be available
bug.cc:3: error: (if you use '-fpermissive', G++ will accept your code, but
allowing the use of an undeclared name is deprecated)
bug.cc: In function 'void foo() [with int = 0]':
bug.cc:7: instantiated from here
bug.cc:3: error: 'A' was not declared in this scope
bug.cc: At global scope:
bug.cc: In instantiation of 'foo() [with int = 0]::A':
bug.cc:4: instantiated from 'void foo() [with int = 0]'
bug.cc:7: instantiated from here
bug.cc:4: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
--
Summary: [4.2 regression] ICE throwing undeclared object
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, 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=29363
[Bug fortran/28415] 4.2.0 ICE when using automatic array and -fno-automatic
--- Comment #5 from gregory dot fruth at aero dot org 2006-10-06 00:04 --- The patch works perfectly in 4.2.0(svn). My application now builds and runs successfully under gfortran. Thanks, Jakub! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28415
[Bug fortran/29364] New: No error given if using a non-defined type in a type definition
If one compiles - module test implicit none type epot_t integer :: c type(nonexist),pointer :: l end type epot_t end module test - no error (and no warning) is shown. If one removes the keyword "pointer", the error message "Derived type at (1) has not been previously defined" is shown. Expected: Also for pointers, such a message is shown! (ifort, g95, NAG f95 all give an error.) -- Summary: No error given if using a non-defined type in a type definition Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29364
[Bug fortran/15441] RRSPACING broken for denormals
--- Comment #9 from kargl at gcc dot gnu dot org 2006-10-06 00:33 ---
I have a patch, but it requires libm to have ldexp{f,l}.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |kargl at gcc dot gnu dot org
|dot org |
Status|REOPENED|ASSIGNED
Last reconfirmed|2004-05-14 17:32:55 |2006-10-06 00:33:10
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15441
[Bug fortran/25850] real kind=16 failures on powerpc-darwin
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2006-10-06
01:20 ---
The last work on this by Andrew was to propose the code fragment
below for remapping the functions...
static void
darwin_patch_builtin (int fncode)
{
tree fn = built_in_decls[fncode];
const char *newname;
if (!fn)
return;
sym = DECL_ASSEMBLER_NAME (fn);
newname = alloca (IDENTIFIER_LENGTH (sym)+9);
strcpy (newname, IDENTIFIER_POINTER (sym));
strcat (newname, "$LDBL128");
sym = get_identifier (newname);
SET_DECL_ASSEMBLER_NAME (fn, sym);
fn = implicit_built_in_decls[fncode];
if (fn)
SET_DECL_ASSEMBLER_NAME (fn, sym);
}
Mike Stump provide a list of functions to be remapped...
___svfscanf$LDBL128 _fmal$LDBL128 _strtold_l$LDBL128
___svfscanf_l$LDBL128 _fmaxl$LDBL128 _swprintf$LDBL128
___vfprintf$LDBL128 _fminl$LDBL128 _swprintf_l$LDBL128
___vfwprintf$LDBL128_fmodl$LDBL128 _swscanf$LDBL128
___vfwscanf$LDBL128 _fprintf$LDBL128_swscanf_l$LDBL128
_acoshl$LDBL128 _fprintf_l$LDBL128 _syslog$LDBL128
_acosl$LDBL128 _frexpl$LDBL128 _tanhl$LDBL128
_asinhl$LDBL128 _fscanf$LDBL128 _tanl$LDBL128
_asinl$LDBL128 _fscanf_l$LDBL128 _tgammal$LDBL128
_asl_log$LDBL128_fwprintf$LDBL128 _truncl$LDBL128
_asl_vlog$LDBL128 _fwprintf_l$LDBL128 _vasprintf$LDBL128
_asprintf$LDBL128 _fwscanf$LDBL128_vasprintf_l$LDBL128
_asprintf_l$LDBL128 _fwscanf_l$LDBL128 _verr$LDBL128
_atan2l$LDBL128 _hypotl$LDBL128 _verrc$LDBL128
_atanhl$LDBL128 _ilogbl$LDBL128 _verrx$LDBL128
_atanl$LDBL128 _ldexpl$LDBL128 _vfprintf$LDBL128
_cabsl$LDBL128 _lgammal$LDBL128_vfprintf_l$LDBL128
_cacoshl$LDBL128_llrintl$LDBL128_vfscanf$LDBL128
_cacosl$LDBL128 _llroundl$LDBL128 _vfscanf_l$LDBL128
_cargl$LDBL128 _log10l$LDBL128 _vfwprintf$LDBL128
_casinhl$LDBL128_log1pl$LDBL128 _vfwprintf_l$LDBL128
_casinl$LDBL128 _log2l$LDBL128 _vfwscanf$LDBL128
_catanhl$LDBL128_logbl$LDBL128 _vfwscanf_l$LDBL128
_catanl$LDBL128 _logl$LDBL128 _vprintf$LDBL128
_cbrtl$LDBL128 _lrintl$LDBL128 _vprintf_l$LDBL128
_ccoshl$LDBL128 _lroundl$LDBL128_vscanf$LDBL128
_ccosl$LDBL128 _modfl$LDBL128 _vscanf_l$LDBL128
_ceill$LDBL128 _nanl$LDBL128 _vsnprintf$LDBL128
_cexpl$LDBL128 _nearbyintl$LDBL128 _vsnprintf_l$LDBL128
_cimagl$LDBL128 _nextafterl$LDBL128 _vsprintf$LDBL128
_clogl$LDBL128 _nexttoward$LDBL128 _vsprintf_l$LDBL128
_conjl$LDBL128 _nexttowardf$LDBL128_vsscanf$LDBL128
_copysignl$LDBL128 _nexttowardl$LDBL128_vsscanf_l$LDBL128
_coshl$LDBL128 _powl$LDBL128 _vswprintf$LDBL128
_cosl$LDBL128 _printf$LDBL128 _vswprintf_l$LDBL128
_cpowl$LDBL128 _printf_l$LDBL128 _vswscanf$LDBL128
_cprojl$LDBL128 _remainderl$LDBL128 _vswscanf_l$LDBL128
_creall$LDBL128 _remquol$LDBL128_vsyslog$LDBL128
_csinhl$LDBL128 _rintl$LDBL128 _vwarn$LDBL128
_csinl$LDBL128 _roundl$LDBL128 _vwarnc$LDBL128
_csqrtl$LDBL128 _scalblnl$LDBL128 _vwarnx$LDBL128
_ctanhl$LDBL128 _scalbnl$LDBL128_vwprintf$LDBL128
_ctanl$LDBL128 _scanf$LDBL128 _vwprintf_l$LDBL128
_erfcl$LDBL128 _scanf_l$LDBL128_vwscanf$LDBL128
_erfl$LDBL128 _sinhl$LDBL128 _vwscanf_l$LDBL128
_err$LDBL128_sinl$LDBL128 _warn$LDBL128
_errc$LDBL128 _snprintf$LDBL128 _warnc$LDBL128
_errx$LDBL128 _snprintf_l$LDBL128 _warnx$LDBL128
_exp2l$LDBL128 _sprintf$LDBL128_wcstold$LDBL128
_expl$LDBL128 _sprintf_l$LDBL128 _wcstold_l$LDBL128
_expm1l$LDBL128 _sqrtl$LDBL128 _wprintf$LDBL128
_fabsl$LDBL128 _sscanf$LDBL128 _wprintf_l$LDBL128
_fdiml$LDBL128 _sscanf_l$LDBL128 _wscanf$LDBL128
_floorl$LDBL128 _strtold$LDBL128_wscanf_l$LDBL128
and Geoff mentioned...
You also need to be sure to test macos_version_min. If you're compiling to
target < 10.3.9, then you need to make sure to use the original version of at
least printf and the other variadic functions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25850
[Bug libfortran/29302] nan_inf_fmt.f90 segfaults on Darwin PPC starting with Xcode 2.4
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2006-10-06 01:32 --- Geoff, This bug is also radar://4759173. I've been asked to... Please debug and produce a small self-contained (that is, not including gfortran) testcase showing what goes wrong. Could you expand in that radar report on what you suspect is causing this? Jack -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29302
[Bug c++/28349] [4.0 regression] ICE with "undefined" va_arg and references
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-10-06 02:48 --- Fixed also on the 4.1 branch now. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.1.2 4.2.0 Summary|[4.0/4.1 regression] ICE|[4.0 regression] ICE with |with "undefined" va_arg and |"undefined" va_arg and |references |references http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28349
[Bug c++/28349] [4.0 regression] ICE with "undefined" va_arg and references
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-06 02:51 --- Subject: Bug 28349 Author: pinskia Date: Fri Oct 6 02:51:33 2006 New Revision: 117479 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117479 Log: 2006-10-05 Andrew Pinski <[EMAIL PROTECTED]> PR C++/28349 * call.c (build_x_va_arg): Remove the reference type from the type before creating the pointer type. 2006-10-05 Andrew Pinski <[EMAIL PROTECTED]> PR c++/28349 * testsuite/g++.dg/warn/var-args1.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/warn/var-args1.C - copied unchanged from r116577, trunk/gcc/testsuite/g++.dg/warn/var-args1.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/call.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28349
[Bug fortran/25850] real kind=16 failures on powerpc-darwin
--- Comment #7 from kargl at gcc dot gnu dot org 2006-10-06 03:04 ---
(In reply to comment #6)
> The last work on this by Andrew was to propose the code fragment
> below for remapping the functions...
>
> static void
> darwin_patch_builtin (int fncode)
> {
> }
It is unclear to me where you intend to put this function.
If it is in the gfortran frontend, I will outright reject
the patch and lobby to have it removed if anyone applies.
> Mike Stump provide a list of functions to be remapped...
(Over 150 functions to remap).
You got to be kidding. Apple has no long double library
support, and so you plan to remap the functions just to
compile REAL(16) programs. I fear that this is going to
lead to too many superfluous bug reports. If anything,
in trans-types.h, the inclusion of REAL(16) shoudl be
disabled for darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25850
Re: [Bug fortran/25850] real kind=16 failures on powerpc-darwin
On Fri, 2006-10-06 at 03:04 +, kargl at gcc dot gnu dot org wrote: > It is unclear to me where you intend to put this function. > If it is in the gfortran frontend, I will outright reject > the patch and lobby to have it removed if anyone applies. It should be in darwin.c in the back-end. C also has the same issue. -- Pinski
[Bug fortran/25850] real kind=16 failures on powerpc-darwin
--- Comment #8 from pinskia at physics dot uc dot edu 2006-10-06 03:06 --- Subject: Re: real kind=16 failures on powerpc-darwin On Fri, 2006-10-06 at 03:04 +, kargl at gcc dot gnu dot org wrote: > It is unclear to me where you intend to put this function. > If it is in the gfortran frontend, I will outright reject > the patch and lobby to have it removed if anyone applies. It should be in darwin.c in the back-end. C also has the same issue. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25850
[Bug fortran/24398] invalid module file gives weird error
--- Comment #9 from kargl at gcc dot gnu dot org 2006-10-06 03:08 --- Paul, I read the patch, and think that you can commit it. gfortran certainly can't recover for a mangled module. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24398
[Bug c++/29363] [4.2 regression] ICE throwing undeclared object
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-06 03:51 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.2.0 Known to work||4.1.2 Last reconfirmed|-00-00 00:00:00 |2006-10-06 03:51:36 date|| Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29363
[Bug target/25850] real kind=16 failures on powerpc-darwin
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2006-10-06 03:53 --- Andrew, Could you flesh out the code fragment a bit so it is clearer exactly how you intended to hook this into darwin.c? Also, if you could just show how you were going to handle the table of symbols for just a couple of the entries? This would really help get the ball rolling on this PR again. Jack -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25850
[Bug tree-optimization/29330] [4.2 Regression] -O -ftree-loop-linear --> virtual memory exhausted
--- Comment #5 from robert dot wilhelm at gmx dot net 2006-10-06 04:36 --- valgrind output: ==6316== Invalid read of size 4 ==6316==at 0x8598C55: compute_all_dependences (tree-data-ref.c:3975) ==6316== Address 0x44C0D20 is 0 bytes inside a block of size 20 free'd ==6316==at 0x40052ED: realloc (vg_replace_malloc.c:306) ==6316==by 0x86634B1: xrealloc (xmalloc.c:179) ==6316== ==6316== Invalid read of size 4 ==6316==at 0x8598C7A: compute_all_dependences (lambda.h:227) ==6316== Address 0x44C0D20 is 0 bytes inside a block of size 20 free'd ==6316==at 0x40052ED: realloc (vg_replace_malloc.c:306) ==6316==by 0x86634B1: xrealloc (xmalloc.c:179) -- robert dot wilhelm at gmx dot net changed: What|Removed |Added CC||robert dot wilhelm at gmx ||dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29330
[Bug target/25850] real kind=16 failures on powerpc-darwin
--- Comment #10 from mrs at apple dot com 2006-10-06 05:46 --- > Apple has no long double library support This is false. What we don't have is symbol versioning and the `normal' names refer to an abi different long double, 8 bytes as I recall. The impact to the fortran frontend should be 2 lines of code, if that. The impact to the darwin.c file will be larger. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25850
[Bug c++/29365] New: Unnecessary anonymous namespace warnings
How to reproduce: g++ -c foo.C Compiling the attached code using g++-4.2 generates the warning foo.C:11: warning: 'foo::bar' has a base '::gazonk' whose type uses the anonymous namespace I fail to see why this construct should be warned about -- Summary: Unnecessary anonymous namespace warnings Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at magfr dot user dot lysator dot liu dot se 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=29365
[Bug c++/29365] Unnecessary anonymous namespace warnings
--- Comment #1 from gcc at magfr dot user dot lysator dot liu dot se 2006-10-06 06:09 --- Created an attachment (id=12389) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12389&action=view) foo.C - testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365
