[Bug bootstrap/25842] New: Error in building libiberty
In file included from ../../gcc/libiberty/md5.c:40: ../../gcc/include/md5.h:83: warning: no semicolon at end of struct or union ../../gcc/include/md5.h:83: error: parse error before "ATTRIBUTE_ALIGNED_ALIGNOF" [ ... snip ... ] gmake[3]: *** [md5.o] Error 1 gmake[3]: Leaving directory `/tmp/gfortran-20060118/ibin/libiberty' gmake[2]: *** [all-stage1-libiberty] Error 2 gmake[2]: Leaving directory `/tmp/gfortran-20060118/ibin' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/tmp/gfortran-20060118/ibin' gmake: *** [all] Error 2 -- Summary: Error in building libiberty Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org GCC build triplet: powerpc64-unknown-linux-gnu GCC host triplet: powerpc64-unknown-linux-gnu GCC target triplet: powerpc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25842
[Bug target/17390] missing floating point compare optimization
--- Comment #8 from uros at kss-loka dot si 2006-01-18 09:50 --- (In reply to comment #7) > Hmm, I get (but that looks like different branch predictions): It looks that your default is -mtune=pentium. > _testf: > fldl4(%esp) > ftst > fnstsw %ax > testb $64, %ah > jne L10 > ftst > fnstsw %ax > fstp%st(0) > testb $69, %ah > jne L5 > fld1 > ret > .align 2,0x90 > L10: > fstp%st(0) > fldz > ret > L5: > fldsLC2 > ret With proposed patch, this code is compiled to (-O2 -ffast-math -mtune=pentium -fomit-frame-pointer): testf: fldl 4(%esp) ftst fnstsw %ax fstp %st(0) testb $64, %ah jne .L10 testb $69, %ah jne .L5 fld1 ret .p2align 4,,7 .L10: fldz ret .L5: flds .LC2 ret and for -mtune=i686: testf: fldl 4(%esp) ftst fnstsw %ax fstp %st(0) sahf je .L10 jbe .L5 fld1 ret .p2align 4,,7 .L10: fldz .p2align 4,,8 ret .L5: flds .LC2 .p2align 4,,4 ret BTW: I'll attach a patch, rediffed to current SVN. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17390
[Bug target/17390] missing floating point compare optimization
--- Comment #9 from uros at kss-loka dot si 2006-01-18 09:53 --- Created an attachment (id=10666) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10666&action=view) patch to SVN GCC: (GNU) 4.2.0 20060117 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17390
[Bug libstdc++/25824] --disable-hosted-libstdcxx causes build break in eh_globals.cc
--- Comment #3 from paolo at gcc dot gnu dot org 2006-01-18 11:22 --- Subject: Bug 25824 Author: paolo Date: Wed Jan 18 11:22:10 2006 New Revision: 109883 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109883 Log: 2006-01-18 Perry Smith <[EMAIL PROTECTED]> PR libstdc++/25823 PR libstdc++/25824 * libsupc++/eh_alloc.cc: Fix return type of memset declaration. * libsupc++/eh_globals.cc: If !_GLIBCXX_HOSTED declare malloc and free. 2006-01-18 Paolo Carlini <[EMAIL PROTECTED]> * include/ext/pb_assoc/detail/value_type_adapter/ value_type_adapter.hpp: Include . * include/ext/pb_assoc/detail/value_type_adapter/ it_value_type_traits.hpp (it_value_type_traits_<>::value_type_holder): Use tr1::aligned_storage and tr1::alignment_of. (it_value_type_traits_<>::buf_t): Remove. (it_value_type_traits_<>::make_valid, recast): Adjust. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/ext/pb_assoc/detail/value_type_adapter/it_value_type_traits.hpp trunk/libstdc++-v3/include/ext/pb_assoc/detail/value_type_adapter/value_type_adapter.hpp trunk/libstdc++-v3/libsupc++/eh_alloc.cc trunk/libstdc++-v3/libsupc++/eh_globals.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25824
[Bug libstdc++/25823] --disable-hosted-libstdcxx causes build break
--- Comment #9 from paolo at gcc dot gnu dot org 2006-01-18 11:22 --- Subject: Bug 25823 Author: paolo Date: Wed Jan 18 11:22:10 2006 New Revision: 109883 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109883 Log: 2006-01-18 Perry Smith <[EMAIL PROTECTED]> PR libstdc++/25823 PR libstdc++/25824 * libsupc++/eh_alloc.cc: Fix return type of memset declaration. * libsupc++/eh_globals.cc: If !_GLIBCXX_HOSTED declare malloc and free. 2006-01-18 Paolo Carlini <[EMAIL PROTECTED]> * include/ext/pb_assoc/detail/value_type_adapter/ value_type_adapter.hpp: Include . * include/ext/pb_assoc/detail/value_type_adapter/ it_value_type_traits.hpp (it_value_type_traits_<>::value_type_holder): Use tr1::aligned_storage and tr1::alignment_of. (it_value_type_traits_<>::buf_t): Remove. (it_value_type_traits_<>::make_valid, recast): Adjust. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/ext/pb_assoc/detail/value_type_adapter/it_value_type_traits.hpp trunk/libstdc++-v3/include/ext/pb_assoc/detail/value_type_adapter/value_type_adapter.hpp trunk/libstdc++-v3/libsupc++/eh_alloc.cc trunk/libstdc++-v3/libsupc++/eh_globals.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25823
[Bug libstdc++/25824] --disable-hosted-libstdcxx causes build break in eh_globals.cc
--- Comment #4 from pcarlini at suse dot de 2006-01-18 12:38 --- Target is 4.1.1, not suited for 4_0-branch, because of libstdc++/25472. -- pcarlini at suse dot de changed: What|Removed |Added Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25824
[Bug libstdc++/25824] --disable-hosted-libstdcxx causes build break in eh_globals.cc
-- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-18 12:38:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25824
[Bug libstdc++/25823] --disable-hosted-libstdcxx causes build break
--- Comment #10 from pcarlini at suse dot de 2006-01-18 12:39 --- Target is 4.1.1, not suited for 4_0-branch, because of libstdc++/25472. -- pcarlini at suse dot de changed: What|Removed |Added Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25823
[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2006-01-18 13:31 --- > I rebuilt with -O2 AND -g, and got the following trace. Notice the while-loop > in nscan, statements 1141 thru 1147 are four single statements. The "next" > trace by gdb shows them occuring multiple times. This should NOT be > happening. This may be another BUG, this time with 'gdb'. That is expected because -O2 seriously breaks the source code apart and reorders things. Use "nexti" in that case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791
[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2006-01-18 13:38 --- > Notice that 'nscan' expects 'scancb' in %l0, but it is ZERO. Better not trust GDB at -O2 on that one, it is easily fooled. > It does NOT contain the value in R1 (aka: r1). > (gdb) x/4bx &r1 > 0x2d6a0c : 0x000x310x170x80 That value is in %i0. > Notice the assembly code in NSCAN just before the 'call nscan' > at NSCAN+80. r1 never gets loaded into %l0. Therefore, it is > NOT passed to 'nscan' properly. The value is loaded into %o0 before 'call nscan' and end up in %i0 after the save register window instruction. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791
[Bug bootstrap/25842] Error in building libiberty
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-18 14:07 --- Hmm, ansidecl.h should have been included. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25842
[Bug fortran/25785] [4.1/4.2 Regression] gfortran - incorrectly issues an error on tests for optional arguments with assumed length
--- Comment #9 from dir at lanl dot gov 2006-01-18 14:20 --- Paul, I am sorry that I upset you. It was completely unintentional. Dale. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25785
[Bug ada/25844] New: ICE (Regression) on overloaded renames
Output of gcc -v: - Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.1-20060113/configure --disable-nls --enable-languages=c,ada --prefix=/disc/gbcc/home/chrisp/GNAT/koala/gcc4/native-20060113 --enable-libada Thread model: posix gcc version 4.1.0 20060113 (prerelease) -- gnatmake command entered and its output: [EMAIL PROTECTED] t]# gnatmake x-toolkit gcc -c x-toolkit.adb +===GNAT BUG DETECTED==+ | 4.1.0 20060113 (prerelease) (i686-pc-linux-gnu) Assert_Failure atree.adb:812| | Error detected at x-toolkit.ads:1369:7 | | 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. x-toolkit.adb x-toolkit.ads x.ads tgx.ads tgx-lists.ads x-resource_manager.ads x-data_resources.ads x-dtrs.ads x-toolkit_names.ads x-basics.ads x-toolkit-classes.ads compilation abandoned gnatmake: "x-toolkit.adb" compilation error -- Expected Behaviour: GNAT compiles x-toolkit.ad[bs] to .ali and .o Actual Behaviour: GNAT experiences an internal compiler error and presents the bug box given above. -- Summary: ICE (Regression) on overloaded renames Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: holmana at adsmr dot co dot za 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=25844
[Bug middle-end/25840] libjava is broken on Linux/x86-64
--- Comment #1 from hjl at lucon dot org 2006-01-18 14:40 --- See http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00924.html -- hjl at lucon dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-18 14:40:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25840
[Bug middle-end/25840] [4.2 Regression] libjava is broken on Linux/x86-64
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |major Keywords||wrong-code Summary|libjava is broken on|[4.2 Regression] libjava is |Linux/x86-64|broken on Linux/x86-64 Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25840
[Bug ada/25844] ICE (Regression) on overloaded renames
--- Comment #1 from holmana at adsmr dot co dot za 2006-01-18 14:34 --- Created an attachment (id=10669) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10669&action=view) Files listed in bugbox, concatenated (suitable for gnatchop) (gzipped) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25844
[Bug c++/25845] New: want optional warning for non-constant declarations that could be constant
Declaring variables and parameters as constants is a very useful feature that should be used as much as possible. Therefore it would be very useful to have an option to warn when something is not declared as constant eventhough it could be, at least in C++ and probably in other languages as well. -- Summary: want optional warning for non-constant declarations that could be constant Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sigra at home dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
[Bug c++/25845] want optional warning for non-constant declarations that could be constant
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-18 15:36 --- Can you give an example? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
[Bug target/25731] Complex values passed in wrong registers
--- Comment #1 from danglin at gcc dot gnu dot org 2006-01-18 15:45 --- Subject: Bug 25731 Author: danglin Date: Wed Jan 18 15:44:57 2006 New Revision: 109894 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109894 Log: PR target/25731 * config.gcc (hppa*-*-linux*, hppa[12]*-*-hpux10*, hppa*64*-*-hpux11*, hppa[12]*-*-hpux11*): Override default shared libgcc version for both sjlj and dwarf2 exception handling. * pa/t-hpux-shlib (SHLIB_SOVERSION): New make variable. Rework to allow overriding SHLIB_EXT and SHLIB_SOVERSION. * pa/pa.c (function_value): Treat complex and vector types as aggregates. (function_arg): Likewise. Only pass scalar floats in the floating point argument registers. * pa/t-slibgcc-dwarf-ver: New file. * pa/t-slibgcc-sjlj-ver: New file. * pa/t-slibgcc-elf-ver: Delete file. Added: trunk/gcc/config/pa/t-slibgcc-dwarf-ver trunk/gcc/config/pa/t-slibgcc-sjlj-ver Removed: trunk/gcc/config/pa/t-slibgcc-elf-ver Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/gcc/config/pa/pa.c trunk/gcc/config/pa/t-hpux-shlib -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25731
[Bug c++/25846] New: declaration scope of template members
I have a problem with template construction compiled by g++ 4.0.2 (SuSE Linux).
The compiler populate following error message:
"test.cpp:17: error: a m_pData was not declared in this scope"
Previous release g++ 3.3.3 works fine.
template class c1T
{
public:
c1T () { }
~c1T (){ }
operator T*() const { return m_pData; }
T *m_pData;
};
template class c1newT : public c1T
{
public:
c1newT () : c1T () { }
T* operator->() const { return m_pData; }
};
main ()
{
c1T hugo;
}
Thanks
--
Summary: declaration scope of template members
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vna at rts dot co dot at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25846
[Bug c++/12970] Strange class member access rules
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-01-18 16:06 --- *** Bug 25846 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||vna at rts dot co dot at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12970
[Bug c++/25846] declaration scope of template members
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-18 16:06 --- Please read http://gcc.gnu.org/gcc-3.4/changes.html. This is a dup of bug 12970. *** This bug has been marked as a duplicate of 12970 *** -- 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=25846
[Bug c++/25845] want optional warning for non-constant declarations that could be constant
--- Comment #2 from sigra at home dot se 2006-01-18 16:07 ---
Example 1:
{
int i = f();
do_something(i + 1, 7, 'h');
do_something_else(i % 3, 'e');
}
If i could be declared "const int", the compiler should warn.
Example 2:
float dra(float m, Panel & p) {
p.do_me(5);
return p.set_moad(m);
}
If m could be declared "const float", the compiler should warn.
Example 3:
{
char t = 2;
if (hej.is_double()) t *= 7;
std::cout << static_cast(t) << std::endl;
}
If "static_cast" would work, the compiler should warn.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
[Bug c++/25845] want optional warning for non-constant declarations that could be constant
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-18 16:13 --- I still don't understand what this warning is useful for? const does nothing when it comes to local variables except for not letting you touch it in other expressions. It does nothing for optimizations or anything else. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
[Bug c++/25845] want optional warning for non-constant declarations that could be constant
--- Comment #4 from pcarlini at suse dot de 2006-01-18 16:19 --- (In reply to comment #3) > const does nothing when it comes to local variables except for not letting you > touch it in other expressions. It does nothing for optimizations or anything > else. This last point is not obvious at all, in my opinion. Why not? In principle, certainly const-ness *can* help optimizers one way or the other. Is this just a current limitation? A design choice? Anything in the standard making that tricky? I would like to know more. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
[Bug c++/25845] want optional warning for non-constant declarations that could be constant
--- Comment #5 from sigra at home dot se 2006-01-18 16:25 --- (In reply to comment #3) > I still don't understand what this warning is useful for? > > const does nothing when it comes to local variables except for not letting > you touch it in other expressions. It does nothing for optimizations or > anything else. That is what const does for local variables. It is useful for preventing unintended modifications which can cause bugs. That is why the feature exists at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
[Bug target/25731] Complex values passed in wrong registers
--- Comment #2 from danglin at gcc dot gnu dot org 2006-01-18 16:30 --- Subject: Bug 25731 Author: danglin Date: Wed Jan 18 16:30:18 2006 New Revision: 109895 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109895 Log: PR target/25731 * config.gcc (hppa*-*-linux*, hppa[12]*-*-hpux10*, hppa*64*-*-hpux11*, hppa[12]*-*-hpux11*): Override default shared libgcc version for both sjlj and dwarf2 exception handling. * pa/t-hpux-shlib (SHLIB_SOVERSION): New make variable. Rework to allow overriding SHLIB_EXT and SHLIB_SOVERSION. * pa/pa.c (function_value): Treat complex and vector types as aggregates. (function_arg): Likewise. Only pass scalar floats in the floating point argument registers. * pa/t-slibgcc-dwarf-ver: New file. * pa/t-slibgcc-sjlj-ver: New file. * pa/t-slibgcc-elf-ver: Delete file. Added: branches/gcc-4_1-branch/gcc/config/pa/t-slibgcc-dwarf-ver branches/gcc-4_1-branch/gcc/config/pa/t-slibgcc-sjlj-ver Removed: branches/gcc-4_1-branch/gcc/config/pa/t-slibgcc-elf-ver Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config.gcc branches/gcc-4_1-branch/gcc/config/pa/pa.c branches/gcc-4_1-branch/gcc/config/pa/t-hpux-shlib -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25731
[Bug c++/25845] want optional warning for non-constant declarations that could be constant
--- Comment #7 from pcarlini at suse dot de 2006-01-18 16:32 ---
(In reply to comment #6)
> int f(const int *a, int *b)
> {
>*b = 1;
>return *a;
> }
>
> a and b can alias and there is no way around that at all because that is
> what the C++ standard says.
Interesting example. But what if the parameters cannot alias (e.g., different
types). What about the other cases mentioned in the PR (probably more important
to me)? No pointers involved at all?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
[Bug target/20754] ACATS cxg1005 fails at runtime on hppa-linux
--- Comment #13 from danglin at gcc dot gnu dot org 2006-01-18 16:34 --- Fixed by patches on 4.0, 4.1 and trunk. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20754
[Bug c++/25845] want optional warning for non-constant declarations that could be constant
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-18 16:29 ---
Subject: Re: want optional warning for non-constant declarations that could be
constant
On Jan 18, 2006, at 11:19 AM, pcarlini at suse dot de wrote:
> --- Comment #4 from pcarlini at suse dot de 2006-01-18 16:19
> ---
> (In reply to comment #3)
>> const does nothing when it comes to local variables except for not
>> letting you
>> touch it in other expressions. It does nothing for optimizations or
>> anything
>> else.
>
> This last point is not obvious at all, in my opinion. Why not? In
> principle,
> certainly const-ness *can* help optimizers one way or the other. Is
> this just a
> current limitation? A design choice? Anything in the standard making
> that
> tricky? I would like to know more.
int f(const int *a, int *b)
{
*b = 1;
return *a;
}
a and b can alias and there is no way around that at all because that is
what the C++ standard says.
-- Pinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
Re: [Bug c++/25845] want optional warning for non-constant declarations that could be constant
On Jan 18, 2006, at 11:19 AM, pcarlini at suse dot de wrote:
--- Comment #4 from pcarlini at suse dot de 2006-01-18 16:19
---
(In reply to comment #3)
const does nothing when it comes to local variables except for not
letting you
touch it in other expressions. It does nothing for optimizations or
anything
else.
This last point is not obvious at all, in my opinion. Why not? In
principle,
certainly const-ness *can* help optimizers one way or the other. Is
this just a
current limitation? A design choice? Anything in the standard making
that
tricky? I would like to know more.
int f(const int *a, int *b)
{
*b = 1;
return *a;
}
a and b can alias and there is no way around that at all because that is
what the C++ standard says.
-- Pinski
[Bug fortran/25785] [4.1/4.2 Regression] gfortran - incorrectly issues an error on tests for optional arguments with assumed length
--- Comment #10 from paulthomas2 at wanadoo dot fr 2006-01-18 16:45 --- Subject: Re: [4.1/4.2 Regression] gfortran - incorrectly issues an error on tests for optional arguments with assumed length Dale, > >I am sorry that I upset you. It was completely unintentional. > > > I upset myself; you were just the trigger! Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25785
[Bug target/25731] Complex values passed in wrong registers
--- Comment #3 from danglin at gcc dot gnu dot org 2006-01-18 17:02 --- Fixed in 4.1. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25731
[Bug middle-end/25840] [4.2 Regression] libjava is broken on Linux/x86-64
--- Comment #2 from ian at airs dot com 2006-01-18 17:04 --- I just reconfirmed that I don't see any problems running the libjava testsuite on i686-pc-linux-gnu. And I don't have access to any x86_64 systems. So I can't recreate this problem myself. The backtrace suggests that there is some problem in the crt0 file. Can you please try building crtbegin.o and crtend.o with -fno-unit-at-a-time and with -fno-toplevel-reorder. I changed the default from the former to the latter. There shouldn't be any significant differences between the two. If there are, please let me know. I'll try building a cross-compiler to x86_64-linux to try this myself. I may run into header file problems; I'll see. -- ian at airs dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ian at airs dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-01-18 14:40:59 |2006-01-18 17:04:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25840
[Bug middle-end/25840] [4.2 Regression] libjava is broken on Linux/x86-64
--- Comment #3 from ian at airs dot com 2006-01-18 17:39 --- Building a cross-compiler did not shed any light on the problem. Can anybody provide more information about what is going wrong? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25840
[Bug middle-end/25840] [4.2 Regression] libjava is broken on Linux/x86-64
--- Comment #4 from hjl at lucon dot org 2006-01-18 17:47 --- I rebuilt crt*.o* with -fno-toplevel-reorder -fno-unit-at-a-time and recreated lib*.so. I still have the same problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25840
[Bug middle-end/25840] [4.2 Regression] libjava is broken on Linux/x86-64
--- Comment #5 from hjl at lucon dot org 2006-01-18 18:48 --- I found this in my build log creating gcj-dbtool ./gcj-dbtool -n classmap.db || touch classmap.db creating gij /bin/sh: line 1: 17842 Segmentation fault ./gcj-dbtool -n classmap.db make[5]: Leaving directory `/export/build/gnu/gcc-next/build-x86_64-linux/x86_64-unknown-linux-gnu/libjava' Why doesn't libjava stop? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25840
[Bug ada/25844] [4.1/4.2 regression] Ada ICE (Regression) on overloaded renames
--- Comment #2 from laurent at guerby dot net 2006-01-18 18:49 --- With 4.0.2: $ gcc -c x-toolkit.adb x-toolkit.ads:590:04: this instantiation requires "Tgx.Lists (body)" x-toolkit.ads:590:04: but file "tgx-lists.adb" was not found With 4.1: $ gcc -c x-toolkit.adb +===GNAT BUG DETECTED==+ | 4.1.0 20060116 (prerelease) (i686-pc-linux-gnu) Assert_Failure atree.adb:812| | Error detected at x-toolkit.ads:1369:7 | With 4.2: $ gcc -c x-toolkit.adb +===GNAT BUG DETECTED==+ | 4.2.0 20060112 (experimental) (i686-pc-linux-gnu) Assert_Failure atree.adb:812| | Error detected at x-toolkit.ads:1369:7 | -- laurent at guerby dot net changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2006-01-18 18:49:05 date|| Summary|ICE (Regression) on |[4.1/4.2 regression] Ada ICE |overloaded renames |(Regression) on overloaded ||renames http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25844
[Bug fortran/20869] EXTERNAL and INTRINSIC cannot be used together
--- Comment #5 from pault at gcc dot gnu dot org 2006-01-18 18:55 --- Subject: Bug 20869 Author: pault Date: Wed Jan 18 18:55:01 2006 New Revision: 109899 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109899 Log: 2006-01-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/20869 PR fortran/20875 PR fortran/25024 * symbol.c (check_conflict): Add pointer valued elemental functions and internal procedures with the external attribute to the list of conflicts. (gfc_add_attribute): New catch-all function to perform the checking of symbol attributes for attribute declaration statements. * decl.c (attr_decl1): Call gfc_add_attribute for each of - (gfc_match_external, gfc_match_intent, gfc_match_intrinsic, gfc_match_pointer, gfc_match_dimension, gfc_match_target): Remove spurious calls to checks in symbol.c. Set the attribute directly and use the call to attr_decl() for checking. * gfortran.h: Add prototype for gfc_add_attribute. PR fortran/25785 * resolve.c (resolve_function): Exclude PRESENT from assumed size argument checking. Replace strcmp's with comparisons with generic codes. 2006-01-18 Paul Thomas <[EMAIL PROTECTED]> Steven G. Kargl <[EMAIL PROTECTED]> PR fortran/20869 * gfortran.dg/intrinsic_external_1.f90: New test. PR fortran/20875. * gfortran.dg/elemental_pointer_1.f90: New test. PR fortran/25024 * gfortran.dg/external_procedures_1.f90: New test. PR fortran/25785 gfortran.dg/assumed_present.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/assumed_present.f90 trunk/gcc/testsuite/gfortran.dg/elemental_pointer_1.f90 trunk/gcc/testsuite/gfortran.dg/external_procedures_1.f90 trunk/gcc/testsuite/gfortran.dg/intrinsic_external_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20869
[Bug fortran/25024] ICE with external declaration inside same procedure
--- Comment #2 from pault at gcc dot gnu dot org 2006-01-18 18:55 --- Subject: Bug 25024 Author: pault Date: Wed Jan 18 18:55:01 2006 New Revision: 109899 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109899 Log: 2006-01-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/20869 PR fortran/20875 PR fortran/25024 * symbol.c (check_conflict): Add pointer valued elemental functions and internal procedures with the external attribute to the list of conflicts. (gfc_add_attribute): New catch-all function to perform the checking of symbol attributes for attribute declaration statements. * decl.c (attr_decl1): Call gfc_add_attribute for each of - (gfc_match_external, gfc_match_intent, gfc_match_intrinsic, gfc_match_pointer, gfc_match_dimension, gfc_match_target): Remove spurious calls to checks in symbol.c. Set the attribute directly and use the call to attr_decl() for checking. * gfortran.h: Add prototype for gfc_add_attribute. PR fortran/25785 * resolve.c (resolve_function): Exclude PRESENT from assumed size argument checking. Replace strcmp's with comparisons with generic codes. 2006-01-18 Paul Thomas <[EMAIL PROTECTED]> Steven G. Kargl <[EMAIL PROTECTED]> PR fortran/20869 * gfortran.dg/intrinsic_external_1.f90: New test. PR fortran/20875. * gfortran.dg/elemental_pointer_1.f90: New test. PR fortran/25024 * gfortran.dg/external_procedures_1.f90: New test. PR fortran/25785 gfortran.dg/assumed_present.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/assumed_present.f90 trunk/gcc/testsuite/gfortran.dg/elemental_pointer_1.f90 trunk/gcc/testsuite/gfortran.dg/external_procedures_1.f90 trunk/gcc/testsuite/gfortran.dg/intrinsic_external_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25024
[Bug fortran/25785] [4.1/4.2 Regression] gfortran - incorrectly issues an error on tests for optional arguments with assumed length
--- Comment #11 from pault at gcc dot gnu dot org 2006-01-18 18:55 --- Subject: Bug 25785 Author: pault Date: Wed Jan 18 18:55:01 2006 New Revision: 109899 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109899 Log: 2006-01-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/20869 PR fortran/20875 PR fortran/25024 * symbol.c (check_conflict): Add pointer valued elemental functions and internal procedures with the external attribute to the list of conflicts. (gfc_add_attribute): New catch-all function to perform the checking of symbol attributes for attribute declaration statements. * decl.c (attr_decl1): Call gfc_add_attribute for each of - (gfc_match_external, gfc_match_intent, gfc_match_intrinsic, gfc_match_pointer, gfc_match_dimension, gfc_match_target): Remove spurious calls to checks in symbol.c. Set the attribute directly and use the call to attr_decl() for checking. * gfortran.h: Add prototype for gfc_add_attribute. PR fortran/25785 * resolve.c (resolve_function): Exclude PRESENT from assumed size argument checking. Replace strcmp's with comparisons with generic codes. 2006-01-18 Paul Thomas <[EMAIL PROTECTED]> Steven G. Kargl <[EMAIL PROTECTED]> PR fortran/20869 * gfortran.dg/intrinsic_external_1.f90: New test. PR fortran/20875. * gfortran.dg/elemental_pointer_1.f90: New test. PR fortran/25024 * gfortran.dg/external_procedures_1.f90: New test. PR fortran/25785 gfortran.dg/assumed_present.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/assumed_present.f90 trunk/gcc/testsuite/gfortran.dg/elemental_pointer_1.f90 trunk/gcc/testsuite/gfortran.dg/external_procedures_1.f90 trunk/gcc/testsuite/gfortran.dg/intrinsic_external_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25785
[Bug fortran/20875] elemental function may not be pointer valued
--- Comment #1 from pault at gcc dot gnu dot org 2006-01-18 18:55 --- Subject: Bug 20875 Author: pault Date: Wed Jan 18 18:55:01 2006 New Revision: 109899 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109899 Log: 2006-01-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/20869 PR fortran/20875 PR fortran/25024 * symbol.c (check_conflict): Add pointer valued elemental functions and internal procedures with the external attribute to the list of conflicts. (gfc_add_attribute): New catch-all function to perform the checking of symbol attributes for attribute declaration statements. * decl.c (attr_decl1): Call gfc_add_attribute for each of - (gfc_match_external, gfc_match_intent, gfc_match_intrinsic, gfc_match_pointer, gfc_match_dimension, gfc_match_target): Remove spurious calls to checks in symbol.c. Set the attribute directly and use the call to attr_decl() for checking. * gfortran.h: Add prototype for gfc_add_attribute. PR fortran/25785 * resolve.c (resolve_function): Exclude PRESENT from assumed size argument checking. Replace strcmp's with comparisons with generic codes. 2006-01-18 Paul Thomas <[EMAIL PROTECTED]> Steven G. Kargl <[EMAIL PROTECTED]> PR fortran/20869 * gfortran.dg/intrinsic_external_1.f90: New test. PR fortran/20875. * gfortran.dg/elemental_pointer_1.f90: New test. PR fortran/25024 * gfortran.dg/external_procedures_1.f90: New test. PR fortran/25785 gfortran.dg/assumed_present.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/assumed_present.f90 trunk/gcc/testsuite/gfortran.dg/elemental_pointer_1.f90 trunk/gcc/testsuite/gfortran.dg/external_procedures_1.f90 trunk/gcc/testsuite/gfortran.dg/intrinsic_external_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20875
[Bug fortran/20869] EXTERNAL and INTRINSIC cannot be used together
--- Comment #6 from pault at gcc dot gnu dot org 2006-01-18 18:56 --- Subject: Bug 20869 Author: pault Date: Wed Jan 18 18:56:43 2006 New Revision: 109900 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109900 Log: 2006-01-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/20869 PR fortran/20875 PR fortran/25024 * symbol.c (check_conflict): Add pointer valued elemental functions and internal procedures with the external attribute to the list of conflicts. (gfc_add_attribute): New catch-all function to perform the checking of symbol attributes for attribute declaration statements. * decl.c (attr_decl1): Call gfc_add_attribute for each of - (gfc_match_external, gfc_match_intent, gfc_match_intrinsic, gfc_match_pointer, gfc_match_dimension, gfc_match_target): Remove spurious calls to checks in symbol.c. Set the attribute directly and use the call to attr_decl() for checking. * gfortran.h: Add prototype for gfc_add_attribute. PR fortran/25785 * resolve.c (resolve_function): Exclude PRESENT from assumed size argument checking. Replace strcmp's with comparisons with generic codes. 2006-01-18 Paul Thomas <[EMAIL PROTECTED]> Steven G. Kargl <[EMAIL PROTECTED]> PR fortran/20869 * gfortran.dg/intrinsic_external_1.f90: New test. PR fortran/20875. * gfortran.dg/elemental_pointer_1.f90: New test. PR fortran/25024 * gfortran.dg/external_procedures_1.f90: New test. PR fortran/25785 gfortran.dg/assumed_present.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_present.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/elemental_pointer_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/external_procedures_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/intrinsic_external_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/decl.c branches/gcc-4_1-branch/gcc/fortran/gfortran.h branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/symbol.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20869
[Bug fortran/20875] elemental function may not be pointer valued
--- Comment #2 from pault at gcc dot gnu dot org 2006-01-18 18:56 --- Subject: Bug 20875 Author: pault Date: Wed Jan 18 18:56:43 2006 New Revision: 109900 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109900 Log: 2006-01-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/20869 PR fortran/20875 PR fortran/25024 * symbol.c (check_conflict): Add pointer valued elemental functions and internal procedures with the external attribute to the list of conflicts. (gfc_add_attribute): New catch-all function to perform the checking of symbol attributes for attribute declaration statements. * decl.c (attr_decl1): Call gfc_add_attribute for each of - (gfc_match_external, gfc_match_intent, gfc_match_intrinsic, gfc_match_pointer, gfc_match_dimension, gfc_match_target): Remove spurious calls to checks in symbol.c. Set the attribute directly and use the call to attr_decl() for checking. * gfortran.h: Add prototype for gfc_add_attribute. PR fortran/25785 * resolve.c (resolve_function): Exclude PRESENT from assumed size argument checking. Replace strcmp's with comparisons with generic codes. 2006-01-18 Paul Thomas <[EMAIL PROTECTED]> Steven G. Kargl <[EMAIL PROTECTED]> PR fortran/20869 * gfortran.dg/intrinsic_external_1.f90: New test. PR fortran/20875. * gfortran.dg/elemental_pointer_1.f90: New test. PR fortran/25024 * gfortran.dg/external_procedures_1.f90: New test. PR fortran/25785 gfortran.dg/assumed_present.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_present.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/elemental_pointer_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/external_procedures_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/intrinsic_external_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/decl.c branches/gcc-4_1-branch/gcc/fortran/gfortran.h branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/symbol.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20875
[Bug fortran/25785] [4.1/4.2 Regression] gfortran - incorrectly issues an error on tests for optional arguments with assumed length
--- Comment #12 from pault at gcc dot gnu dot org 2006-01-18 18:56 --- Subject: Bug 25785 Author: pault Date: Wed Jan 18 18:56:43 2006 New Revision: 109900 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109900 Log: 2006-01-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/20869 PR fortran/20875 PR fortran/25024 * symbol.c (check_conflict): Add pointer valued elemental functions and internal procedures with the external attribute to the list of conflicts. (gfc_add_attribute): New catch-all function to perform the checking of symbol attributes for attribute declaration statements. * decl.c (attr_decl1): Call gfc_add_attribute for each of - (gfc_match_external, gfc_match_intent, gfc_match_intrinsic, gfc_match_pointer, gfc_match_dimension, gfc_match_target): Remove spurious calls to checks in symbol.c. Set the attribute directly and use the call to attr_decl() for checking. * gfortran.h: Add prototype for gfc_add_attribute. PR fortran/25785 * resolve.c (resolve_function): Exclude PRESENT from assumed size argument checking. Replace strcmp's with comparisons with generic codes. 2006-01-18 Paul Thomas <[EMAIL PROTECTED]> Steven G. Kargl <[EMAIL PROTECTED]> PR fortran/20869 * gfortran.dg/intrinsic_external_1.f90: New test. PR fortran/20875. * gfortran.dg/elemental_pointer_1.f90: New test. PR fortran/25024 * gfortran.dg/external_procedures_1.f90: New test. PR fortran/25785 gfortran.dg/assumed_present.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_present.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/elemental_pointer_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/external_procedures_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/intrinsic_external_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/decl.c branches/gcc-4_1-branch/gcc/fortran/gfortran.h branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/symbol.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25785
[Bug fortran/25024] ICE with external declaration inside same procedure
--- Comment #3 from pault at gcc dot gnu dot org 2006-01-18 18:56 --- Subject: Bug 25024 Author: pault Date: Wed Jan 18 18:56:43 2006 New Revision: 109900 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109900 Log: 2006-01-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/20869 PR fortran/20875 PR fortran/25024 * symbol.c (check_conflict): Add pointer valued elemental functions and internal procedures with the external attribute to the list of conflicts. (gfc_add_attribute): New catch-all function to perform the checking of symbol attributes for attribute declaration statements. * decl.c (attr_decl1): Call gfc_add_attribute for each of - (gfc_match_external, gfc_match_intent, gfc_match_intrinsic, gfc_match_pointer, gfc_match_dimension, gfc_match_target): Remove spurious calls to checks in symbol.c. Set the attribute directly and use the call to attr_decl() for checking. * gfortran.h: Add prototype for gfc_add_attribute. PR fortran/25785 * resolve.c (resolve_function): Exclude PRESENT from assumed size argument checking. Replace strcmp's with comparisons with generic codes. 2006-01-18 Paul Thomas <[EMAIL PROTECTED]> Steven G. Kargl <[EMAIL PROTECTED]> PR fortran/20869 * gfortran.dg/intrinsic_external_1.f90: New test. PR fortran/20875. * gfortran.dg/elemental_pointer_1.f90: New test. PR fortran/25024 * gfortran.dg/external_procedures_1.f90: New test. PR fortran/25785 gfortran.dg/assumed_present.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_present.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/elemental_pointer_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/external_procedures_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/intrinsic_external_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/decl.c branches/gcc-4_1-branch/gcc/fortran/gfortran.h branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/symbol.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25024
[Bug java/25847] New: libjava build doesn't stop when there is a fatal error
While investigating PR 25840, I notice that when there is a fatal error during libjava build, build doesn't stop. I found this in my build log: creating gcj-dbtool ./gcj-dbtool -n classmap.db || touch classmap.db creating gij /bin/sh: line 1: 17842 Segmentation fault ./gcj-dbtool -n classmap.db make[5]: Leaving directory `/export/build/gnu/gcc-next/build-x86_64-linux/x86_64-unknown-linux-gnu/libjava' The problem is in libjava/Makefile.am: ## The .db file. This rule is only used for native builds, so it is ## safe to invoke gcj-dbtool. $(db_name): gcj-dbtool$(EXEEXT) ## In case it exists already. @rm -f $(db_name) ## We don't actually care if it fails -- if it does, just make an ## empty file. This is simpler than trying to discover when mmap is ## not available. ./gcj-dbtool -n $(db_name) || touch $(db_name) -- Summary: libjava build doesn't stop when there is a fatal error Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25847
[Bug fortran/20869] EXTERNAL and INTRINSIC cannot be used together
--- Comment #7 from pault at gcc dot gnu dot org 2006-01-18 18:57 --- Fixed on trunk and 4.1 -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20869
[Bug fortran/20875] elemental function may not be pointer valued
--- Comment #3 from pault at gcc dot gnu dot org 2006-01-18 18:58 --- Fixed on trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20875
[Bug fortran/25024] ICE with external declaration inside same procedure
--- Comment #4 from pault at gcc dot gnu dot org 2006-01-18 18:59 --- Fixed on trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25024
[Bug fortran/25785] [4.1/4.2 Regression] gfortran - incorrectly issues an error on tests for optional arguments with assumed length
--- Comment #13 from pault at gcc dot gnu dot org 2006-01-18 18:59 --- Fixed on trunk and 4.1 Thanks and sorry Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25785
[Bug java/25847] libjava build doesn't stop when there is a fatal error
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-18 19:00 --- Lets look: ## We don't actually care if it fails -- if it does, just make an ## empty file. This is simpler than trying to discover when mmap is ## not available. so what is the problem here? This is not really a major failure really. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25847
[Bug java/25847] libjava build doesn't stop when there is a fatal error
--- Comment #2 from hjl at lucon dot org 2006-01-18 19:14 --- It depends on what kind of failure. This "Segmentation fault" is due to a broken libgcj.so. It makes no senses to continue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25847
[Bug middle-end/25840] [4.2 Regression] libjava is broken on Linux/x86-64
--- Comment #6 from hjl at lucon dot org 2006-01-18 19:23 --- It looks like gcc puts some junks in .ctors section: [EMAIL PROTECTED] .libs]$ objdump -s -j .ctors libgcj.so.7 libgcj.so.7: file format elf64-x86-64 Contents of section .ctors: 190c000 190c010 60cdfe00 `... 190c020 48c7c00f 000f 0500 H... 190c030 0021 . .. 190c040 48c7c00f 000f 0500 H... 190c050 d03f0101 10605101 .?...`Q. 190c060 20605101 30605101 `Q.0`Q. 190c070 40605101 50605101 @`Q.P`Q. 190c080 60605101 70605101 ``Q.p`Q. 190c090 80605101 90605101 .`Q..`Q. 190c0a0 a0605101 .`Q. The "0500" entry is bogus. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25840
[Bug target/25281] [3.4/4.0 only] Request fix for Bug #23150 (aka Bug #24675) in gcc 3.4.x and gcc 4.0.x for arm arch.
--- Comment #3 from armcc2000 at yahoo dot com 2006-01-18 19:28 --- (In reply to comment #2) > > Kazu, does your patch for PR 23150 apply to 4.0? If so, would you please > test that change? I think we've tried that already. Patch applies to 4.0.2 without problems, but is doesn't seem to alter the bug. See comment #5 in bug #24675 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25281
[Bug c++/25845] want optional warning for non-constant declarations that could be constant
--- Comment #8 from sigra at home dot se 2006-01-18 19:29 ---
> On Jan 18, 2006, at 11:19 AM, pcarlini at suse dot de wrote:
>
> > --- Comment #4 from pcarlini at suse dot de 2006-01-18 16:19
> > ---
> > (In reply to comment #3)
> >> const does nothing when it comes to local variables except for not
> >> letting you
> >> touch it in other expressions. It does nothing for optimizations or
> >> anything
> >> else.
> >
> > This last point is not obvious at all, in my opinion. Why not? In
> > principle,
> > certainly const-ness *can* help optimizers one way or the other. Is
> > this just a
> > current limitation? A design choice? Anything in the standard making
> > that
> > tricky? I would like to know more.
>
>
> int f(const int *a, int *b)
> {
>*b = 1;
>return *a;
> }
>
> a and b can alias and there is no way around that at all because that is
> what the C++ standard says.
In this case the compiler should warn because a could be declared "const int *
const" and b could be declared "int * const".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
[Bug middle-end/25840] [4.2 Regression] libjava is broken on Linux/x86-64
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-18 19:30 ---
Hmm:
interpret.o: file format elf64-x86-64
Contents of section .ctors:
0010 48c7c00f 000f 05 H
prims.o: file format elf64-x86-64
Contents of section .ctors:
0010 48c7c00f 000f 05 H
Those are the two ctors might have caused this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25840
[Bug middle-end/25840] [4.2 Regression] libjava is broken on Linux/x86-64
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-01-18 19:31 --- Both prims.o and interpret.o are created from C++ code. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25840
Re: [Bug c++/25845] want optional warning for non-constant declarations that could be constant
> > int f(const int *a, int *b)
> > {
> >*b = 1;
> >return *a;
> > }
> >
> > a and b can alias and there is no way around that at all because that is
> > what the C++ standard says.
>
> In this case the compiler should warn because a could be declared "const int *
> const" and b could be declared "int * const".
That still does not change the fact that a could point to the same location as
b is pointing too.
-- Pinski
[Bug c++/25845] want optional warning for non-constant declarations that could be constant
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-01-18 19:33 ---
Subject: Re: want optional warning for non-constant declarations that could be
constant
> > int f(const int *a, int *b)
> > {
> >*b = 1;
> >return *a;
> > }
> >
> > a and b can alias and there is no way around that at all because that is
> > what the C++ standard says.
>
> In this case the compiler should warn because a could be declared "const int *
> const" and b could be declared "int * const".
That still does not change the fact that a could point to the same location as
b is pointing too.
-- Pinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
[Bug middle-end/25840] [4.2 Regression] libjava is broken on Linux/x86-64
--- Comment #9 from hjl at lucon dot org 2006-01-18 19:34 --- Looks at interpret.s .Ldebug_line0: .text .Ltext0: .section.ctors,"aw",@progbits .align 8 .quad _GLOBAL__I__Jv_soleInterpreterEngine #APP .byte 0 # Yes, this really is necessary .text is missing here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25840
[Bug libgcj/25840] [4.2 Regression] libjava is broken on Linux/x86-64
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-01-18 19:39 --- (In reply to comment #9) > Looks at interpret.s This is a bug in java-signal.h: # 61 "./include/java-signal.h" asm ( ".byte 0 # Yes, this really is necessary\n" ".align 16\n" "__" "restore_rt" ":\n" " movq $" "15" ", %rax\n" " syscall\n" ); There is no .text in the source in the first place so we were just getting lucky before. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |libgcj http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25840
[Bug libgcj/25840] [4.2 Regression] libjava is broken on Linux/x86-64
--- Comment #11 from hjl at lucon dot org 2006-01-18 19:48 --- I am testing this patch now: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01192.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25840
[Bug rtl-optimization/25848] New: missed-rtl-optimization
This C example:
int f1(int a)
{
int b = a*2;
return b+a;
}
---
Currently we produce:
_f1:
mr 0,3
slwi 3,3,1
add 3,3,0
extsw 3,0
blr
-
We should be able to produce:
_f1:
mr 0,3
slwi 3,3,1
add 3,0,3
blr
,so the "extsw" instruction should go out.
--
Summary: missed-rtl-optimization
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dtemirbulatov at gmail dot com
GCC target triplet: powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25848
[Bug libgcj/25840] [4.2 Regression] libjava is broken on Linux/x86-64
--- Comment #12 from hjl at gcc dot gnu dot org 2006-01-18 20:04 --- Subject: Bug 25840 Author: hjl Date: Wed Jan 18 20:04:50 2006 New Revision: 109909 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109909 Log: 2006-01-18 H.J. Lu <[EMAIL PROTECTED]> PR libgcj/25840 * include/x86_64-signal.h (RESTORE2): Add ".text\n". Modified: trunk/libjava/ChangeLog trunk/libjava/include/x86_64-signal.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25840
[Bug rtl-optimization/25848] missed-rtl-optimization
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-18 20:08 --- Hmm, I don't think so as slwi only acts on the lower 32bits so the upper 32bits have the same sign as before which might be invalid if the b+a overflows. Actually optimial is: _f1: slwi r0,r3,1 add r0,r0,r3 extsw r3,r0 blr No extra move. The extsw is to extend the return value to 64bits as required by the ABI. In fact I can think of different cases where this would cause issues. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work|3.4.5 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25848
[Bug bootstrap/25842] Error in building libiberty
--- Comment #2 from dj at redhat dot com 2006-01-18 20:23 --- Subject: Re: New: Error in building libiberty Fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25842
[Bug middle-end/23488] [4.1/4.2 Regression] GCSE load PRE does not work with non sets
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-01-18 20:26 --- Hmm, we actually produce better code on the mainline for my example in comment #2: _xtermEnvEncoding1: movl_result.1525, %edx movl$2, %eax pushl %ebp movl%esp, %ebp popl%ebp testl %edx, %edx cmovne _result.1525, %eax movl%eax, _result.1525 ret But that is does not fix the problem in comment #0. Load PRE on the tree level is not working because this is not an indirect reference to the variable. That is a known issue too. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|target |middle-end GCC target triplet|i686-pc-linux.-gnu |i686-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23488
[Bug c++/25845] want optional warning for non-constant declarations that could be constant
--- Comment #10 from gdr at cs dot tamu dot edu 2006-01-18 20:29 --- Subject: Re: New: want optional warning for non-constant declarations that could be constant "sigra at home dot se" <[EMAIL PROTECTED]> writes: | Declaring variables and parameters as constants is a very useful feature that | should be used as much as possible. Therefore it would be very useful to have | an option to warn when something is not declared as constant eventhough it | could be, at least in C++ and probably in other languages as well. Isn't this a task for lint-like tool? GCC isn't such thing. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
Re: [Bug c++/25845] want optional warning for non-constant declarations that could be constant
"sigra at home dot se" <[EMAIL PROTECTED]> writes: | std::cout << static_cast(t) << std::endl; | } | | If "static_cast" would work, the compiler should warn. given call-by-value, you must be joking. -- Gaby
[Bug c++/25845] want optional warning for non-constant declarations that could be constant
--- Comment #11 from gdr at cs dot tamu dot edu 2006-01-18 20:30 --- Subject: Re: want optional warning for non-constant declarations that could be constant "sigra at home dot se" <[EMAIL PROTECTED]> writes: | std::cout << static_cast(t) << std::endl; | } | | If "static_cast" would work, the compiler should warn. given call-by-value, you must be joking. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
Re: [Bug c++/25845] want optional warning for non-constant declarations that could be constant
"sigra at home dot se" <[EMAIL PROTECTED]> writes:
| --- Comment #8 from sigra at home dot se 2006-01-18 19:29 ---
| > On Jan 18, 2006, at 11:19 AM, pcarlini at suse dot de wrote:
| >
| > > --- Comment #4 from pcarlini at suse dot de 2006-01-18 16:19
| > > ---
| > > (In reply to comment #3)
| > >> const does nothing when it comes to local variables except for not
| > >> letting you
| > >> touch it in other expressions. It does nothing for optimizations or
| > >> anything
| > >> else.
| > >
| > > This last point is not obvious at all, in my opinion. Why not? In
| > > principle,
| > > certainly const-ness *can* help optimizers one way or the other. Is
| > > this just a
| > > current limitation? A design choice? Anything in the standard making
| > > that
| > > tricky? I would like to know more.
| >
| >
| > int f(const int *a, int *b)
| > {
| >*b = 1;
| >return *a;
| > }
| >
| > a and b can alias and there is no way around that at all because that is
| > what the C++ standard says.
|
| In this case the compiler should warn because a could be declared "const int *
| const" and b could be declared "int * const".
It does not make any sense to require the compiler to give a warning
in that case.
-- Gaby
[Bug c++/25845] want optional warning for non-constant declarations that could be constant
--- Comment #12 from gdr at cs dot tamu dot edu 2006-01-18 20:33 ---
Subject: Re: want optional warning for non-constant declarations that could be
constant
"sigra at home dot se" <[EMAIL PROTECTED]> writes:
| --- Comment #8 from sigra at home dot se 2006-01-18 19:29 ---
| > On Jan 18, 2006, at 11:19 AM, pcarlini at suse dot de wrote:
| >
| > > --- Comment #4 from pcarlini at suse dot de 2006-01-18 16:19
| > > ---
| > > (In reply to comment #3)
| > >> const does nothing when it comes to local variables except for not
| > >> letting you
| > >> touch it in other expressions. It does nothing for optimizations or
| > >> anything
| > >> else.
| > >
| > > This last point is not obvious at all, in my opinion. Why not? In
| > > principle,
| > > certainly const-ness *can* help optimizers one way or the other. Is
| > > this just a
| > > current limitation? A design choice? Anything in the standard making
| > > that
| > > tricky? I would like to know more.
| >
| >
| > int f(const int *a, int *b)
| > {
| >*b = 1;
| >return *a;
| > }
| >
| > a and b can alias and there is no way around that at all because that is
| > what the C++ standard says.
|
| In this case the compiler should warn because a could be declared "const int
*
| const" and b could be declared "int * const".
It does not make any sense to require the compiler to give a warning
in that case.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
[Bug c++/25845] want optional warning for non-constant declarations that could be constant
--- Comment #13 from sigra at home dot se 2006-01-18 20:41 --- > It does not make any sense to require the compiler to give a warning > in that case. Read the subject again: "optional" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
[Bug c++/25845] want optional warning for non-constant declarations that could be constant
--- Comment #14 from sigra at home dot se 2006-01-18 20:49 --- > Isn't this a task for lint-like tool? GCC isn't such thing. Are you sure? http://directory.fsf.org/GNU/gcc.html says: "GCC provides many levels of source code error checking traditionally provided by other tools (such as lint)" Since GCC is the tool that is best at reading and understanding the sourcecode, I assume that it is best suited for source code diagnosis. What tool are you thinking of for C++? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
[Bug fortran/18540] Jumping into blocks gives error rather than warning
--- Comment #18 from tobi at gcc dot gnu dot org 2006-01-18 20:54 --- Subject: Bug 18540 Author: tobi Date: Wed Jan 18 20:54:49 2006 New Revision: 109914 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109914 Log: PR fortran/18540 PR fortran/18937 * gfortran.h (BBT_HEADER): Move definition up. (gfc_st_label): Add BBT_HEADER, remove 'prev' and 'next'. * io.c (format_asterisk): Adapt initializer. * resolve.c (resolve_branch): Allow FORTRAN 66 cross-block GOTOs as extension. * symbol.c (compare_st_labels): New function. (gfc_free_st_label, free_st_labels, gfc_get_st_label): Convert to using balanced binary tree. * decl.c (match_char_length, gfc_match_old_kind_spec): Do away with 'cnt'. (warn_unused_label): Adapt to binary tree. * match.c (gfc_match_small_literal_int): Only set cnt if non-NULL. * primary.c (match_kind_param): Do away with cnt. Also converted the ChangeLog to use latin1 characters. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/io.c trunk/gcc/fortran/match.c trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18540
[Bug fortran/18937] quadratic behaviour with many label "spaghetti" code
--- Comment #8 from tobi at gcc dot gnu dot org 2006-01-18 20:54 --- Subject: Bug 18937 Author: tobi Date: Wed Jan 18 20:54:49 2006 New Revision: 109914 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109914 Log: PR fortran/18540 PR fortran/18937 * gfortran.h (BBT_HEADER): Move definition up. (gfc_st_label): Add BBT_HEADER, remove 'prev' and 'next'. * io.c (format_asterisk): Adapt initializer. * resolve.c (resolve_branch): Allow FORTRAN 66 cross-block GOTOs as extension. * symbol.c (compare_st_labels): New function. (gfc_free_st_label, free_st_labels, gfc_get_st_label): Convert to using balanced binary tree. * decl.c (match_char_length, gfc_match_old_kind_spec): Do away with 'cnt'. (warn_unused_label): Adapt to binary tree. * match.c (gfc_match_small_literal_int): Only set cnt if non-NULL. * primary.c (match_kind_param): Do away with cnt. Also converted the ChangeLog to use latin1 characters. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/io.c trunk/gcc/fortran/match.c trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18937
[Bug fortran/18937] quadratic behaviour with many label "spaghetti" code
--- Comment #9 from tobi at gcc dot gnu dot org 2006-01-18 21:07 --- The committed patch fixes only part of the problem, this is still a quadratic bottleneck. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18937
[Bug fortran/18540] Jumping into blocks gives error rather than warning
--- Comment #19 from tobi at gcc dot gnu dot org 2006-01-18 21:08 --- Fixed on the mainline. I will backport the cross-jumping part to 4.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18540
[Bug c++/25849] New: 8 byte memory leak using cerr with libpthread linked in
If you link in libpthread with a program that uses cerr, you leak 8 bytes of
memory (determined through Purify). I discovered this using a RHEL 3 WS box
and also had the same occur on a RHEL 4 AS box. This will not occur when you
use cout or clog in place of cerr, or if libpthread is not linked in.
Granted, 8 bytes is a small leak, but it still is a memory leak.
> cat test.cpp
#include
int main( int argc, char* argv[] )
{
std::cerr << "This is a message" << std::endl;
return 0;
}
> which purify
/usr/local/rational/releases/PurifyPlus.2003a.06.13.FixPack.0177/i386_linux2/bin/purify
> purify --version
Version 2003a.06.13 FixPack 0177 050331 Linux (32-bit)
> which g++
/app/gnu/gcc-4.0.1/bin/g++
> g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /gnu/gcc-4.0.1-src/configure --prefix=/gnu/gcc-4.0.1
Thread model: posix
gcc version 4.0.1
> uname -a
Linux testbox 2.6.9-11.ELsmp #1 SMP Fri May 20 18:26:27 EDT 2005 i686 i686 i386
GNU/Linux
> purify g++ -o test test.cpp -lpthread
Purify 2003a.06.13 FixPack 0177 050331 Linux (32-bit) (c) Copyright IBM Corp.
1992, 2005 All rights reserved.
Instrumenting: crtbegin.o cctQmZeb.o
libgcc.a
crtend.o Linking
> test
[from PurifyPlus window]
Purify: Searching for all memory leaks...
Memory leaked: 8 bytes (100%); potentially leaked: 0 bytes (0%)
MLK: 8 bytes leaked at 0x80b4c10
* This memory was allocated from:
malloc [rtlib.o]
__cxa_get_globals [eh_globals.cc:115]
std::uncaught_exception( void) [eh_catch.cc:138]
std::basic_ostream< char,std::char_traights< char>> & std::operator
<<>(std::basic_ostream< char,std::char_traits< char>>
&, char const *) [ostream:405]
main [ccz2Vq3m.o]
__libc_start_main [libc.so.6]
Purify Heap Analysis (combining supressed and unsupressed blocks)
BlocksBytes
Leaked 18
Potentially Leaked 00
In-Use 00
-
Total Allocated 18
Along with the memory leak, Purify reported two categories of uninitialized
memory reads (UMR) that are normally suppressed. I wouldn't usually report
these, but they seem to be related (I performed some mild editing).
UMR: Uninitialized memory read (2 times):
* This is occurring while in thread -1224099488:
__pthread_initialize_minimal [libpthread.so.0]
call_initialize_minimal [libpthread.so.0]
_init [libpthread.so.0]
_dl_init []
_dl_start_user []
* Reading 4 bytes from 0xbfffdaac on the stack of thread -1224099488.
* Address 0xbfffdaac is 168 bytes below frame pointer in function
__pthread_initialize_minimal.
* Command-line: test
UMR: Uninitialized memory read (128 times):
* This is occurring while in thread -1224099488:
__gconv_transform_internal_ascii [libc.so.6]
wctob [libc.so.6]
std::ctype< wchar_t>::_M_initialize_ctype( void)
[ctype_members.cc:246]
std::ctype< wchar_t>::ctype( unsigned) [ctype.cc:91]
std::locale::_Impl::_Impl( unsigned) [locale_init.cc:304]
std::locale::_S_initialize_once( void) [locale_init.cc:143]
* Reading 4 bytes from 0xbfffd904 on the stack of thread -1224099488.
* Address 0xbfffd904 is 84 bytes below frame pointer in function
wctob.
--
Summary: 8 byte memory leak using cerr with libpthread linked in
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: loizeaux1 at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25849
[Bug c++/25836] [3.4/4.0/4.1/4.2 Regression] G++ does not allow a conversion of templated types
--- Comment #4 from janis at gcc dot gnu dot org 2006-01-18 21:24 --- A regression hunt on powerpc-linux using the submitter's testcase identified the following very large patch: http://gcc.gnu.org/viewcvs?view=rev&rev=69130 r69130 | mmitchel | 2003-07-09 08:48:08 + (Wed, 09 Jul 2003) -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25836
[Bug libstdc++/25849] 8 byte memory leak using cerr with libpthread linked in
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-18 21:26 --- Can you first read: http://gcc.gnu.org/onlinedocs/libstdc++/debug.html#mem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25849
[Bug libstdc++/25849] 8 byte memory leak using cerr with libpthread linked in
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-18 21:30 --- Also looking at the code: void* v = std::malloc(sizeof(__cxa_eh_globals)); if (v == 0 || __gthread_setspecific(init._M_key, v) != 0) std::terminate(); This is a false postive as we do free it in eh_globals_dtor. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25849
[Bug target/24547] Branch cost of -Os is ignored
--- Comment #2 from hjl at lucon dot org 2006-01-18 21:45 --- 4.2 is fixed by http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01029.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24547
[Bug fortran/25850] New: gfortran - 8 testsuite failures on darwin
I cannot find were anyone else has submitted this as a bug - Test Run By dir on Wed Jan 18 13:21:27 2006 Native configuration is powerpc-apple-darwin8.4.0 === gfortran tests === Schedule of variations: unix Running target unix Using /usr/local/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/local/share/dejagnu/config/unix.exp as generic interface file for target. Using /Users/dir/gfortran/gcc/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /Users/dir/gfortran/gcc/gcc/testsuite/gfortran.dg/dg.exp ... FAIL: gfortran.dg/large_real_kind_2.F90 execution test FAIL: gfortran.dg/large_real_kind_2.F90 execution test FAIL: gfortran.dg/large_real_kind_2.F90 execution test FAIL: gfortran.dg/large_real_kind_2.F90 execution test FAIL: gfortran.dg/large_real_kind_2.F90 execution test FAIL: gfortran.dg/large_real_kind_2.F90 execution test FAIL: gfortran.dg/large_real_kind_2.F90 execution test FAIL: gfortran.dg/large_real_kind_2.F90 execution test Running /Users/dir/gfortran/gcc/gcc/testsuite/gfortran.dg/vect/vect.exp ... Running /Users/dir/gfortran/gcc/gcc/testsuite/gfortran.fortran-torture/compile/compile.exp ... Running /Users/dir/gfortran/gcc/gcc/testsuite/gfortran.fortran-torture/execute/execute.exp ... === gfortran Summary === # of expected passes11299 # of unexpected failures8 # of expected failures 7 # of unsupported tests 42 /Users/dir/gfortran/ibin/gcc/testsuite/gfortran/../../gfortran version 4.2.0 20060118 (experimental) make: [check-gfortran] Error 1 (ignored) [dranta:~/gfortran/ibin/gcc] dir% gfortran --v Using built-in specs. Target: powerpc-apple-darwin8.4.0 Configured with: ../gcc/configure --prefix=/Users/dir/gfortran --enable-languages=c,f95 Thread model: posix gcc version 4.2.0 20060118 (experimental) -- Summary: gfortran - 8 testsuite failures on darwin Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dir at lanl dot gov GCC host triplet: powerpc-apple-darwin8.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25850
[Bug fortran/25850] gfortran - 8 testsuite failures on darwin
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-18 21:51 --- Mine. All mine. -- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 GCC host triplet|powerpc-apple-darwin8.4.0 | GCC target triplet||powerpc-apple-darwin8.4.0 Last reconfirmed|-00-00 00:00:00 |2006-01-18 21:51:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25850
[Bug fortran/25850] gfortran - 8 testsuite failures on darwin
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-18 21:52 --- Part of this will be fixed by the patch for PR 25477. The other parts I submitted but I need to reply to the comments. There is two Fortran front-end parts so I am going to keep this as the fortran front-end bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||25477 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25850
[Bug c++/22136] [4.1/4.2 regression] Rejects old-style using declaration
--- Comment #16 from mmitchel at gcc dot gnu dot org 2006-01-18 21:55
---
I'm still wrestling with this PR.
As I suggested earlier, I turned off the caching of nested-name-specifiers
unless we're in the check_dependency_p case. However, that causes
g++.dg/parse/operator2.C to fail, for essentially the opposite reason.
On:
template B::C::operator typename B::Y::X() const { return
0;\
}
we cache the check_dependency_p lookup for B::C, which is "typename
B::C". As a result, we don't enter the scope of B::C when looking up
names in the type-specifier following the operator.
I think that we could fix that in cp_paser_conversion_function_id (by using
resolve_typename_type), but I'm afraid that it's not really safe to cache
either version of the nested-name-specifier lookup, and then return it for the
other case of check_dependency_p.
Still thinking.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22136
[Bug target/23504] 22_locale/money_get/get/char/5.cc fails on ppc-darwin7. because libstdc++ believes long double returns works
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-18 21:55 --- I am going to mark this as depending on PR 25477 for now. I am almost ready to submit the patch for PR 25477 again. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||25477 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23504
[Bug c++/22136] [4.1/4.2 regression] Rejects old-style using declaration
--- Comment #17 from mmitchel at gcc dot gnu dot org 2006-01-18 22:25
---
In retrospect, I wonder if we should be complaining about a using-declaration
in a template in the first place.
For example, is:
struct X { void f(); };
template
struct S : public T {
using X::f;
};
actually invalid?
Both EDG and G++ complain about this (saying that X is not a base class of
S), but should that matter at this stage?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22136
[Bug c++/25845] want optional warning for non-constant declarations that could be constant
--- Comment #15 from gdr at cs dot tamu dot edu 2006-01-18 22:35 --- Subject: Re: want optional warning for non-constant declarations that could be constant "sigra at home dot se" <[EMAIL PROTECTED]> writes: | > It does not make any sense to require the compiler to give a warning | > in that case. | | Read the subject again: "optional" That is beside the point. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
[Bug c++/25845] want optional warning for non-constant declarations that could be constant
--- Comment #16 from gdr at cs dot tamu dot edu 2006-01-18 22:37 --- Subject: Re: want optional warning for non-constant declarations that could be constant "sigra at home dot se" <[EMAIL PROTECTED]> writes: | > Isn't this a task for lint-like tool? GCC isn't such thing. | | Are you sure? yes, there many lint stuff best handled in dedicated tools. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
[Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?)
--- Comment #29 from mark at codesourcery dot com 2006-01-18 23:00 --- Subject: Re: [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?) I think that we should do as follows. Preserve the original value of maximum_field_alignment when doing #pragma pack. Then, for zero-width bitfields, we should align to the minimum of the original maximum_field_alignment and the otherwise natural alignment. The difference between this and the last proposed patch is that I don't think we should entirely ignore maximum_field_alignment for zero-width bitfields; if "long long" as a field will only have (say) 2-byte alignment on some embedded target where structure-packing is the default, then a "long long : 0;" bitfield should only force 4-byte alignment. However, that's an abstract argument; I'm not actually sure what existing practice was with older versions of GCC. Again, in the abstract, I think the example in Comment #12 ought to have size 8 on both IA32 and AMD64 architectures. I can't see any good justification for size 12, with a PCC_BITFIELD_TYPES_MATTER ABI. And, I think that the size of the structure with #pragma pack(1) ought to be the same as with __attribute__((packed)). So, my concern with the patch in Comment #12 is that it would ignore the pre-set maximum_field_alignment on targets with default structure packing; other than that, I think it looks fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?)
--- Comment #30 from steven at gcc dot gnu dot org 2006-01-18 23:08 --- We should at least avoid introducing a third variant of how we lay out these nasty zero-sized friends. People actually use them. For example Wine uses them to enforce compatible alignment and data layout with MS Windows datastructure. Wine has a bunch of #ifdefs spread around in its sources to make it work with the pre- and post-GCC 3.4 layout. Adding a third would drive those poor people nuts. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug c++/25845] want optional warning for non-constant declarations that could be constant
--- Comment #17 from sigra at home dot se 2006-01-18 23:23 --- There is some good advice at http://www.gotw.ca/publications/advice98.htm which says that one should be const-correct and use const whenever possible. (But I do not suggest using const for return values.) This feature request is intended to help in that task. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
[Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?)
--- Comment #31 from mark at codesourcery dot com 2006-01-18 23:28 --- Subject: Re: [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?) steven at gcc dot gnu dot org wrote: > --- Comment #30 from steven at gcc dot gnu dot org 2006-01-18 23:08 > --- > We should at least avoid introducing a third variant of how we lay out these > nasty zero-sized friends. People actually use them. For example Wine uses > them to enforce compatible alignment and data layout with MS Windows > datastructure. Wine has a bunch of #ifdefs spread around in its sources to > make it work with the pre- and post-GCC 3.4 layout. Adding a third would > drive > those poor people nuts. I agree -- but I don't think we're talking about a third variant. Michael's patch looks to me like it will restore the pre-3.4 behavior, which everyone agrees makes more sense. My issue with respect to maximum_field_alignment doesn't really apply to pre-4.0 toolchains, since they didn't have default structure packing for targets, AFAICT. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug tree-optimization/23282] [4.0 Regression] wrong results at -O on x86
--- Comment #15 from rakdver at gcc dot gnu dot org 2006-01-18 23:31 --- Subject: Bug 23282 Author: rakdver Date: Wed Jan 18 23:31:16 2006 New Revision: 109920 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109920 Log: PR tree-optimization/23282 * tree-chrec.c (chrec_fold_multiply_poly_poly): Associate chrecs correctly. PR tree-optimization/23282 * gcc.c-torture/execute/pr23282.c: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.c-torture/execute/pr23282.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/tree-chrec.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23282
[Bug other/1] Test of new GCC GNATS db.
--- Comment #7 from dharinih at yahoo dot com 2006-01-18 23:53 --- I am trying to build a cross compiler for host i686-pc-cygwin and target h8300-hms. I built binutils, bootstrap GCC and newlib successfully. ( using binutils-2.16, newlib-1.14.0 and gcc-3.4.4. When I build the final gcc using this configure command configure target=h8300-hms prefix=/usr/local --enable-languages=c,c++ --with-newlib --with-headers=../newlib-1.14.0/newlib/libc/include I get an internal compile error after about half hour of compiling in build_gcc/h8300-hms/h8300s/normal/libstdc++-v3/include/bits/locale_facets.tcc:702:internal compile error: in extract_inst, at recog.c:2083. I have tried to do the config without the --with-headers option and it always gets internal compile error at the same place. Can someone help me get past this. I have tried different versions of gcc code but always have some internal compile error at the last step. Thanks Dharini -- dharinih at yahoo dot com changed: What|Removed |Added CC||dharinih at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
[Bug c++/25845] want optional warning for non-constant declarations that could be constant
--- Comment #18 from gdr at cs dot tamu dot edu 2006-01-19 00:09 --- Subject: Re: want optional warning for non-constant declarations that could be constant "sigra at home dot se" <[EMAIL PROTECTED]> writes: | There is some good advice at that precisely prooves my point: it is a coding style issue best served by a deicated tool. We plenty of coding stule rules out there. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
[Bug rtl-optimization/25654] [4.0/4.1/4.2 Regression] RTL alias analysis unprepared to handle stack slot sharing
--- Comment #10 from hubicka at gcc dot gnu dot org 2006-01-19 00:14
---
My understanding of C type based aliasing rules always was that char, as an
exception, might alias with everything. Perhaps I lived in false belief for a
while, but at least -Wstrict-aliasing seems to think so:
ibm:~ # more t.c
char a[10];
short b[10];
main()
{
*(int *)a=5;
*(int *)b=5;
}
ibm:~ # gcc -O2 -Wstrict-aliasing t.c
t.c: In function main:
t.c:6: warning: dereferencing type-punned pointer will break strict-aliasing
rules
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25654
