[Bug c++/26448] unnecessary namespace-alias ambiguity
--- Comment #2 from emilp at mac dot com 2006-03-08 08:45 ---
But isn't this problem already solved for the using directive. The code below
compiles fine and works as expected. In fact, in the days of gcc 3, using
could be used for namespaces and behaved exactly the way I would prefer.
namespace lib1
{
typedef int integer;
}
namespace lib2
{
using lib1::integer;
}
using namespace lib1;
using namespace lib2;
int main()
{
integer val = 0;
return val;
}
It seems limiting to introduce new (and often obscure) ambiguities when using
namespace aliases, the very problem namespaces are meant to alleviate...
E.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26448
[Bug bootstrap/24382] ORIGINAL_LD_FOR_TARGET has bizarre value
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-03-08 09:29 --- Confirmed on gcc mailing-list. -- fxcoudert 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-03-08 09:29:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24382
[Bug target/22097] libgfortran build failure on mips-sgi-irix6.5
--- Comment #19 from fxcoudert at gcc dot gnu dot org 2006-03-08 09:51 --- This was fixed on rev. 110700 for trunk, and later backported to 4.1. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to fail|4.1.0 4.2.0 | Known to work||4.2.0 4.1.0 Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22097
[Bug middle-end/24998] [4.2 Regression] Build failure: undefined symbol __floatunsitf
--- Comment #25 from fxcoudert at gcc dot gnu dot org 2006-03-08 09:55 --- (In reply to comment #23) I think MIPS16, FRV and US_SOFTWARE_GOFAST still need fixing. (The last quite likely by removing US_SOFTWARE_GOFAST support.) Adding the maintainers of all those in Cc list. I don't know what US_SOFTWARE_GOFAST, but from the last sentence quoted above, it looks like I don't really want to know :) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||rsandifo at gcc dot gnu dot ||org, aoliva at gcc dot gnu ||dot org, aldyh at gcc dot ||gnu dot org, echristo at gcc ||dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug target/23301] [4.0/4.1/4.2 Regression] sys/ucontext.h missing on powerpc-*-darwin5.*
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-03-08 09:57 --- (In reply to comment #4) Interesting darwin-fallback.c got the fix: 2005-03-25 Geoffrey Keating [EMAIL PROTECTED] * config/rs6000/darwin-fallback.c: Don't include ucontext.h. Use our own structure definitions. But not the host-darwin.c :). Well, Ccing Geoffrey might make it propagate :) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||geoffk at gcc dot gnu dot ||org Last reconfirmed|2005-08-10 00:18:09 |2006-03-08 09:57:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23301
[Bug target/26600] [4.1/4.2 Regression] internal compiler error: in push_reload, at reload.c:1303
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-03-08 10:18 --- For mainline, this is a dup of 26449. For 4.1.0 I can reproduce this: #1 0x08493eae in push_reload (in=0x4023a4b8, out=0x40241280, inloc=0x40244a84, outloc=0x40229be0, class=NO_REGS, inmode=V4SImode, outmode=TImode, strict_low=0, optional=0, opnum=0, type=RELOAD_OTHER) at /space/rguenther/src/svn/gcc-4_1-branch/gcc/reload.c:1302 gcc_assert (class != NO_REGS || (optional != 0 type == RELOAD_FOR_OUTPUT)); (gdb) call debug_rtx (in) (const_vector:V4SI [ (const_int 9633 [0x25a1]) (const_int 9633 [0x25a1]) (const_int 9633 [0x25a1]) (const_int 9633 [0x25a1]) ]) (gdb) call debug_rtx (out) (reg:TI 23 xmm2) this problem may be latent on the mainline (so I make it depend on 26449). This is a regression in that we didn't ICE here for 4.0, but we didn't do any vectorization there either. So, who's the reload expert for vector stuff ;) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||26449 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | Keywords||ice-on-valid-code, ssemmx Last reconfirmed|-00-00 00:00:00 |2006-03-08 10:18:34 date|| Summary|internal compiler error: in |[4.1/4.2 Regression] |push_reload, at |internal compiler error: in |reload.c:1303 |push_reload, at ||reload.c:1303 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26600
[Bug target/26600] [4.1/4.2 Regression] internal compiler error: in push_reload, at reload.c:1303
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-08 10:40 ---
(gdb) call debug_rtx(*outloc)
(subreg:TI (reg:V4SI 23 xmm2 [99]) 0)
(but of course it looks like NO_REGS doesn't make any sense for this reload)
(gdb) up
#2 0x0849b343 in find_reloads (insn=0x402401b8, replace=0, ind_levels=0,
live_known=1, reload_reg_p=0x87f5a00)
at /space/rguenther/src/svn/gcc-4_1-branch/gcc/reload.c:3953
3953operand_reloadnum[goal_alternative_matched[i]]
(gdb) call debug_rtx (insn)
(insn 58 57 59 2 (set (subreg:TI (reg:V4SI 23 xmm2 [99]) 0)
(lshiftrt:TI (subreg:TI (reg:V4SI 96) 0)
(const_int 32 [0x20]))) 711 {sse2_lshrti3} (nil)
(nil))
and we call push_reload with in
(subreg:TI (const_vector:V4SI [
(const_int 9633 [0x25a1])
(const_int 9633 [0x25a1])
(const_int 9633 [0x25a1])
(const_int 9633 [0x25a1])
]) 0)
Looking at reload.c:1018 I don't feel like wanting to dig further ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26600
[Bug bootstrap/24382] ORIGINAL_LD_FOR_TARGET has bizarre value
--- Comment #6 from rmathew at gcc dot gnu dot org 2006-03-08 11:40 --- (In reply to comment #5) Confirmed on gcc mailing-list. Reconfirmed with the GCC 4.1.0 release tarballs for C (core) and C++ (g++). In addition to using --with-ld, one has to also use a relative path to the configure script instead of an absolute path for the bootstrap to work. -- rmathew at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-03-08 09:29:10 |2006-03-08 11:40:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24382
[Bug java/26603] New: compiler crashes segmentation fault
when compiling
class A{
class B{}
}
class C extends A.B{}
with
gcj -S
compiler crashes
author of report
Marek Warpechowski [EMAIL PROTECTED]
--
Summary: compiler crashes segmentation fault
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: salwicki at MIMUW dot EDU dot PL
GCC build triplet: gcj 4.0.2 from ubuntu repository
GCC host triplet: amd64 kubuntu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26603
[Bug c++/26604] New: primitive type initialisation in array allocation
the code:
class A{
public:
A(int i){}
};
int main(){
A *a=new A[10](2);
int *p=new int[10](3);
}
--
2 problems:
1. This code compiles with g++ -Wall -ansi (no warning)
put I think that array initialisation is
forbidden in ANSI (the compilation failed with
--pedantic)
2. For the array a, elements are correctly
constructed with A::A(2). For p, values
in the array are not equals to 3 ! (copy
constructor is not call for primitive types)
Regards
Julien Allali.
--
Summary: primitive type initialisation in array allocation
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: allali at univ-mlv dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26604
[Bug target/26600] [4.1/4.2 Regression] internal compiler error: in push_reload, at reload.c:1303
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-08 12:39 --- So it looks like this is HWI bug really, if a target needs to support TImode in any shape or form, HWI should be set to 64bits no questions asked. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC host triplet||32bits Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26600
[Bug libstdc++/25409] STL mt_allocator crash in global construcutor
--- Comment #3 from neil at fnxweb dot com 2006-03-08 12:41 --- Was it compiled up to use mt_allocator? I won't have the time to check again for a short while. If it's considered a good idea to use -pthreads, then it ought really to have it's info-page entry updated to not make it platform specific. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25409
[Bug middle-end/26561] [4.2 Regression] ACATS failures c34004a, c46033a and cxg2024 at -O0
--- Comment #6 from belyshev at depni dot sinp dot msu dot ru 2006-03-08 12:46 --- This bug prevents emacs from working, it says M-x is undefined. -- belyshev at depni dot sinp dot msu dot ru changed: What|Removed |Added Severity|normal |critical Last reconfirmed|2006-03-05 21:39:54 |2006-03-08 12:46:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26561
[Bug c++/26604] primitive type initialisation in array allocation
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-08 12:50 --- This works for me by rejecting with -Wall -ansi: pc64:~ ~/gcc-4.0/bin/gcc t2.cc -W -Wall -ansi t2.cc:3: warning: unused parameter i t2.cc: In function int main(): t2.cc:7: error: ISO C++ forbids initialization in array new t2.cc:8: error: ISO C++ forbids initialization in array new t2.cc:7: warning: unused variable a t2.cc:8: warning: unused variable p pc64:~ ~/gcc-4.1/bin/gcc t2.cc -W -Wall -ansi t2.cc:3: warning: unused parameter i t2.cc: In function int main(): t2.cc:7: error: ISO C++ forbids initialization in array new t2.cc:8: error: ISO C++ forbids initialization in array new t2.cc:7: warning: unused variable a t2.cc:8: warning: unused variable p pc64:~ ~/checkin/bin/gcc t2.cc -W -Wall -ansi t2.cc:3: warning: unused parameter i t2.cc: In function int main(): t2.cc:7: error: ISO C++ forbids initialization in array new t2.cc:8: error: ISO C++ forbids initialization in array new t2.cc:7: warning: unused variable a t2.cc:8: warning: unused variable p - What is the output of gcc -v? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26604
[Bug java/26603] ICE on invalid using non static inner class as base class outside the class
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-08 12:59 --- This is invalid code as you cannot use A.B outside of A as it is not a static inner class. Confirmed, not a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|gcj 4.0.2 from ubuntu | |repository | GCC host triplet|amd64 kubuntu | Keywords||ice-on-invalid-code Known to fail||3.0.4 3.2.3 3.4.0 4.0.0 ||4.1.0 4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-03-08 12:59:57 date|| Summary|compiler crashes|ICE on invalid using non |segmentation fault|static inner class as base ||class outside the class http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26603
[Bug java/26603] ICE on invalid using non static inner class as base class outside the class
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-08 13:00 --- This is a dup of bug 18130. *** This bug has been marked as a duplicate of 18130 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26603
[Bug java/18130] ICE when static class extends inner class
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-08 13:00 --- *** Bug 26603 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||salwicki at MIMUW dot EDU ||dot PL http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18130
[Bug c++/26605] New: enable_if + using troubles
EDG-based compilers accept (in strict mode) accept this:
templatetypename T
struct is_void
{ static const bool value = false; };
template
struct is_voidvoid
{ static const bool value = true; };
templatetypename, bool
struct enable_if { };
templatetypename T
struct enable_ifT, true
{ typedef T type; };
namespace one
{
templatetypename T
typename enable_ifdouble, is_voidT::value::type
fun(T);
}
namespace two
{
using one::fun;
templatetypename T
typename enable_ifdouble, !is_voidT::value::type
fun(T);
}
/
paolo:~/Work g++ -c reduced.cc
reduced.cc:29: error: 'templateclass T typename enable_ifdouble, (!
is_voidT::value)::type two::fun(T)' conflicts with previous using
declaration 'templateclass T typename enable_ifdouble,
is_voidT::value::type one::fun(T)'
--
Summary: enable_if + using troubles
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pcarlini at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26605
[Bug c++/26605] using + templates troubles
--- Comment #1 from pcarlini at suse dot de 2006-03-08 13:57 ---
Actually, the issue seems much simpler:
namespace one
{
templatetypename T
void
fun(T);
}
using one::fun;
templatetypename T
void
fun(T);
paolo:~/Work g++ -c reduced2.cc
reduced2.cc:12: error: 'templateclass T void fun(T)' conflicts with previous
using declaration 'templateclass T void one::fun(T)'
--
pcarlini at suse dot de changed:
What|Removed |Added
Summary|enable_if + using troubles |using + templates troubles
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26605
[Bug c++/26605] using + templates troubles
--- Comment #2 from pcarlini at suse dot de 2006-03-08 14:01 --- Likely a duplicate of c++/21682, but simpler testcase ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26605
[Bug c++/26605] using + templates troubles
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-08 14:07 --- (In reply to comment #2) Likely a duplicate of c++/21682, but simpler testcase ;) I don't know how that and comment #1 are valid code as in both cases the arguments will be the same so you should get an error about ambiguous functions. Now the one in comment #0 is slightly different as the enable if causes a specific function to be selected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26605
[Bug c++/26605] using + templates troubles
--- Comment #4 from pcarlini at suse dot de 2006-03-08 14:11 --- (In reply to comment #3) (In reply to comment #2) Likely a duplicate of c++/21682, but simpler testcase ;) I don't know how that and comment #1 are valid code as in both cases the arguments will be the same so you should get an error about ambiguous functions. Not so early, I think, because T is unknown. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26605
[Bug c++/26605] using + templates troubles
--- Comment #5 from pcarlini at suse dot de 2006-03-08 14:15 --- (In reply to comment #4) I don't know how that and comment #1 are valid code as in both cases the arguments will be the same so you should get an error about ambiguous functions. Not so early, I think, because T is unknown. And, by the way, this one already compiles: templatetypename T void fun(T); templatetypename T void fun(T); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26605
[Bug c++/26605] using + templates troubles
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-03-08 14:21 --- (In reply to comment #5) And, by the way, this one already compiles: But that names the same function, it is just like: int f(void); int f(void); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26605
[Bug c++/26605] using + templates troubles
--- Comment #7 from pcarlini at suse dot de 2006-03-08 14:24 --- (In reply to comment #6) (In reply to comment #5) And, by the way, this one already compiles: But that names the same function, it is just like: int f(void); int f(void); No, it's not the same, because we are dealing with the templates. I'm going to study the standard (maybe you can also do that ;) but we have an hard fact: both g++ and EDG accept the version without using, only g++ rejects that with using. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26605
[Bug libgcj/13130] GC shouldn't have to scan .data section
--- Comment #2 from aph at gcc dot gnu dot org 2006-03-08 14:35 --- I've started some experimental work on this at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-abi-experimental-branch. Initial improvements in grabage collection time are encouraging, but there are some problems with poor code quality. (In particular, accesses to items in the constant pool are now doubly-indirect: class$-constants[n].) Before merging this work to trunk I intend to do some benchmarking and and fix any performance regressions I find. -- aph at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aph at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13130
[Bug libgcj/23495] java.lang.String.equals is suboptimal
--- Comment #11 from greenrd at gcc dot gnu dot org 2006-03-08 14:39 --- Sorry, I can't submit patches to libjava because I'm tainted (except for the packages that are new in Mustang, which I haven't seen). Even though this is a small change, I prefer to err on the side of caution. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23495
[Bug c++/26605] using + templates troubles
--- Comment #8 from pcarlini at suse dot de 2006-03-08 14:56 --- (In reply to comment #7) No, it's not the same, because we are dealing with the templates. I'm going to study the standard (maybe you can also do that ;) but we have an hard fact: both g++ and EDG accept the version without using, only g++ rejects that with using. In my opinion, 14.8.3 is sufficient to say that the simple snippets in Comments #1 and #5 should both compile (only #5 is already ok on GCC): only when a call to the name is written template argument deduction takes place, separately for each function template, then overload resolution is performed (which would of course fails, in the examples), no earlier checks should be carried out. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-08 14:56:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26605
[Bug c++/26352] ICE
--- Comment #7 from bangerth at dealii dot org 2006-03-08 14:57 --- (In reply to comment #6) We don't use pre-compiled headers ourselves. Any precompiles are third-party or standard library, and actually I was unaware that they were used. Can you tell me the files that the header contained? Then I can identify where we got them and might be able to get un-precompiled versions. All I can say is that in your log file I see the command line /mnt/export/home/ivan/gcc/bin/../libexec/gcc/i686-pc-linux-gnu/4.0.2/cc1plus -fpreprocessed powersetTest.ii -quiet -dumpbase powersetTest.cc -mtune=pentiumpro -auxbase powersetTest -g -O0 -version -o powersetTest.s Since I don't have your sources (and don't want to), I can't help you search further. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26352
[Bug c++/26448] unnecessary namespace-alias ambiguity
--- Comment #3 from bangerth at dealii dot org 2006-03-08 14:59 --- I didn't make up the rules, so you're barking up the wrong tree :-) But the difference between using directives for names and namespace aliases is that a using directive is final: it imports a name into the present namespace. The namespace alias provides an alternative name for a namespace, but the namespace name it points to may itself be an alias, which means that the compiler may have to walk a fairly long chain of aliases until it finally finds the original. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26448
[Bug libgcj/24183] xmlj code not properly built
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-08 15:03 --- Subject: Bug 24183 Author: tromey Date: Wed Mar 8 15:03:48 2006 New Revision: 111844 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111844 Log: PR libgcj/24183: * native/jni/xmlj/Makefile.in: Rebuilt. * native/jni/xmlj/Makefile.am (nativelib_LTLIBRARIES): Renamed (reverted local patch). Modified: trunk/libjava/classpath/ChangeLog.gcj trunk/libjava/classpath/native/jni/xmlj/Makefile.am trunk/libjava/classpath/native/jni/xmlj/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24183
[Bug libgcj/24183] xmlj code not properly built
--- Comment #3 from tromey at gcc dot gnu dot org 2006-03-08 15:05 --- Fixed. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24183
[Bug middle-end/20477] [4.0] Remove used label when optimizing.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-08 15:11 --- This turns out to be a dup of bug 25251 which was fixed for sure for 4.1.0. *** This bug has been marked as a duplicate of 25251 *** -- 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=20477
[Bug tree-optimization/25251] [4.1 only] NIST Failure - FM013.f at -O2
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-03-08 15:11 --- *** Bug 20477 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||wf_cs at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25251
[Bug bootstrap/21037] [4.0 RC1] Bootstrap failure (ld: TOC overflow)
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-08 15:12 --- Fixed for 4.1.0 for sure so closing as fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21037
[Bug target/23728] [4.0 regression] [m68k] ICE (Segmentation fault) building python
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Priority|P2 |P3 Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23728
[Bug rtl-optimization/24132] gcc-4.0.1 never finishes with aggressive optimization options
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-03-08 15:13 --- Any news on the testcase? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24132
[Bug ada/24880] [4.0/4.1/4.2 regression] (Ada) Conversion of user-defined integer type with Size fixed causes crashes
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 Last reconfirmed|2005-11-15 20:22:08 |2006-03-08 15:16:10 date|| Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24880
[Bug target/25440] [4.0 only] failure in gcc.dg/tls/pr24428.c with -fpic/-fPIC on x86_64
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25440
[Bug ada/23836] [4.0/4.1/4.2 Regression] Invalid code generated when accessing packed arrays / aliasing
--- Comment #5 from charlet at gcc dot gnu dot org 2006-03-08 15:16 --- Nothing particularly critical in this PR, we've got plenty of other more worrisome failures to look at. Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23836
[Bug tree-optimization/25449] [4.0] endless loop in nbench neural net with -ftree-loop-linear
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-08 15:17 --- Is there a testcase other than just compile and run nbench with -ftree-loop-linear? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25449
[Bug tree-optimization/20773] [4.0 Regression] ICE: SEGV building jar file
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P5 Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20773
[Bug c++/26448] unnecessary namespace-alias ambiguity
--- Comment #4 from emilp at mac dot com 2006-03-08 15:23 --- I did come on a bit strong, didn't I? Sorry about that, I'm just a bit frustrated since it used to work better in the gcc 3 series :-) Do you have a suggestion as to where I could continue this discussion? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26448
[Bug c++/26448] unnecessary namespace-alias ambiguity
--- Comment #5 from bangerth at dealii dot org 2006-03-08 15:26 --- (In reply to comment #4) I did come on a bit strong, didn't I? Sorry about that, I'm just a bit frustrated since it used to work better in the gcc 3 series :-) Oh, don't worry. I put a smiley to my remark, just in case you didn't notice :-) Do you have a suggestion as to where I could continue this discussion? There's pretty much only a single route for you, and that is through the relevant C++ standards committees. A pretty daunting task, if you ask me. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26448
[Bug ada/24822] make[2]: *** [ada/einfo.h] Error 1
--- Comment #8 from charlet at gcc dot gnu dot org 2006-03-08 15:27 --- Given that 4.1.0 has been released and issue is fixed there, closing this PR. Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24822
[Bug bootstrap/26547] bootstrap failure on darwin: assembler rejects stfiwx instructions
--- Comment #2 from mikpe at csd dot uu dot se 2006-03-08 15:51 ---
I downloaded and installed cctools-590.12, and that did indeed solve the
gcc-4.1.0 bootstrap problem.
However, today I discovered that the newer cctools break gcc-3.4.x.
A zero-sized global variable, e.g. struct { } unused;, gets translated
into a .comm _unused,1 by gcc-4, but gcc-3.4 generates .comm _unused,0.
The latter worked with the old cctools, but the newer ones mistreat it
as an unresolved reference leading to linkage errors.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26547
[Bug bootstrap/24130] 3.4.3 Bootstrap failed on AIX 5.3
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-08 15:52 --- People have bootstraped and tested on AIX 5.3 without any troubles before and after this patch has been filed? What command are you using to bootstrap GCC? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24130
[Bug bootstrap/26547] bootstrap failure on darwin: assembler rejects stfiwx instructions
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-08 15:57 ---
(In reply to comment #2)
However, today I discovered that the newer cctools break gcc-3.4.x.
A zero-sized global variable, e.g. struct { } unused;, gets translated
into a .comm _unused,1 by gcc-4, but gcc-3.4 generates .comm _unused,0.
The latter worked with the old cctools, but the newer ones mistreat it
as an unresolved reference leading to linkage errors.
Actually the old cctools was broken and should have treated it as an unresolved
symbol.
And that was fixed in 4.0.0 by me by
http://gcc.gnu.org/ml/gcc-patches/2004-06/msg01477.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26547
[Bug libstdc++/25815] [4.1 regression] libstdc++ testsuite: ext/pb_assoc/example/erase_if.cc execution test
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25815
[Bug tree-optimization/24609] [4.1/4.2 regression] Same value duplicated in two different registers
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24609
[Bug ada/25844] [4.1/4.2 regression] Ada ICE (Regression) on overloaded renames
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25844
[Bug middle-end/22207] Spurious 'might be used uninitialized' warnings in STL headers with -O2
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-08 16:06 --- Fixed in 4.0.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22207
[Bug libstdc++/25815] ext/pb_assoc/example/erase_if.cc execution test
--- Comment #10 from pcarlini at suse dot de 2006-03-08 16:08 --- Hardly a regression, considering that ext/pb_assoc has been released for the first time in 4.1.0 ;) -- pcarlini at suse dot de changed: What|Removed |Added Summary|[4.1 regression] libstdc++ |ext/pb_assoc/example/erase_i |testsuite: |f.cc execution test |ext/pb_assoc/example/erase_i| |f.cc execution test | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25815
[Bug bootstrap/26500] [4.2 Regression] info/gfortran.info is no longer being installed
--- Comment #5 from bonzini at gnu dot org 2006-03-08 16:11 --- patch committed -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26500
[Bug bootstrap/26500] [4.2 Regression] info/gfortran.info is no longer being installed
--- Comment #4 from bonzini at gnu dot org 2006-03-08 16:10 --- Subject: Bug 26500 Author: bonzini Date: Wed Mar 8 16:10:44 2006 New Revision: 111845 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111845 Log: 2006-03-08 Paolo Bonzini [EMAIL PROTECTED] PR bootstrap/26500 * Makefile.in (dvi, html, install-info): Invoke the corresponding language hook targets. * ada/Make-lang.in, cp/Make-lang.in, objc/Make-lang.in, objcp/Make-lang.in: Create stub rules for dvi, html, install-info if language hook targets were missing. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/ada/Make-lang.in trunk/gcc/cp/Make-lang.in trunk/gcc/objc/Make-lang.in trunk/gcc/objcp/Make-lang.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26500
[Bug c++/26605] using + function templates troubles
--- Comment #9 from pcarlini at suse dot de 2006-03-08 16:20 ---
The below also works already (can make for an useful if ugly workaround, in
some cases, e.g., c++/21682):
namespace one
{
templatetypename T
void
fun(T);
}
namespace two
{
templatetypename T
void
fun(T);
}
using one::fun;
using two::fun;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26605
[Bug c++/26604] primitive type initialisation in array allocation
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-03-08 16:25 --- All 3.4.0 accept the code. Fixed with the new C++ parser. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to fail||3.3.6 Known to work||3.4.0 Resolution||FIXED Target Milestone|--- |3.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26604
[Bug libgcj/12740] Stack trace infrastructure improvements
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-08 16:30 --- Isn't this fixed in 4.1? -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12740
[Bug c++/26604] primitive type initialisation in array allocation
--- Comment #3 from allali at univ-mlv dot fr 2006-03-08 16:30 --- (In reply to comment #2) All 3.4.0 accept the code. Fixed with the new C++ parser. I've checked and you're right. Is there a way to have array elements initialized by a specific constructor in g++ 3.4 (to get the example work)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26604
[Bug libgcj/21891] must audit libgcj for required SecurityManager calls
-- gbenson at redhat dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |gbenson at redhat dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-09-26 00:51:42 |2006-03-08 16:30:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21891
[Bug libgcj/21891] must audit libgcj for required SecurityManager calls
--- Comment #3 from gbenson at redhat dot com 2006-03-08 16:32 --- See http://people.redhat.com/gbenson/throwpoint-report.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21891
[Bug tree-optimization/26406] [4.2 Regression] Forwardprop does harm for VRP to figure out if a point is non zero
--- Comment #16 from law at redhat dot com 2006-03-08 16:43 --- C++ version of the problems in 26344. Fixing 26344 will fix this bug as well. *** This bug has been marked as a duplicate of 26344 *** -- law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26406
[Bug testsuite/26344] [4.2 Regression] three testsuite failures in gcc.dg/tree-ssa/
--- Comment #12 from law at redhat dot com 2006-03-08 16:43 --- *** Bug 26406 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26344
[Bug c++/26448] unnecessary namespace-alias ambiguity
--- Comment #6 from emilp at mac dot com 2006-03-08 16:47 --- I'm considering filing a defect report (for a standard clarification) to the commitee but I would like to make sure I'm not climbing any trees here... In your first reply you said My understanding is that this code is in fact invalid..., which part of the C++ standard did you base this on? I'm just wondering because section 7.3.2 seems not to mention any lookup rules at all? Am I missing something obvious? E. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26448
[Bug c++/26448] unnecessary namespace-alias ambiguity
--- Comment #7 from bangerth at dealii dot org 2006-03-08 17:21 --- (In reply to comment #6) I'm considering filing a defect report (for a standard clarification) to the commitee but I would like to make sure I'm not climbing any trees here... In your first reply you said My understanding is that this code is in fact invalid..., which part of the C++ standard did you base this on? I don't have the time to look that up right now, but you should look this up in the name lookup section. It should say that there is an ambiguity if a matching name is found in two namespaces. Note that a namespace a=b; declaration introduces a new namespace. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26448
[Bug ada/18859] [4.0/4.1/4.2 Regression] ACATS ICE c37305a at -O0: in tree_low_cst, at tree.c:3839
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2006-03-08 17:53 --- Created an attachment (id=10992) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10992action=view) Reduced C testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18859
[Bug middle-end/18859] [4.0/4.1/4.2 Regression] ACATS ICE c37305a at -O0: in tree_low_cst, at tree.c:3839
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2006-03-08 17:55 --- This is a middle-end problem: ~/eric gcc t.c t.c: In function 'foo': t.c:5: warning: empty range specified t.c:3: internal compiler error: in tree_low_cst, at tree.c:4423 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Component|ada |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18859
[Bug ada/18859] [4.0/4.1/4.2 Regression] ACATS ICE c37305a at -O0: in tree_low_cst, at tree.c:3839
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-03-08 17:56 --- Hmm, if I change the reduced testcase from 0 ... -1 to -1 ... 0, it works for the C testcase. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |ada http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18859
[Bug other/23541] all error messages produce segfault
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2006-03-08 18:10 --- Created an attachment (id=10993) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10993action=view) Naive fix. It tweaks 4 (really 3) C source files and is sufficient to overcome the problem. But it's probably not the canonical fix as the GNU gettext package (from which the toolchain edition of libintl is borrowed) is not affected; not sure why... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23541
[Bug middle-end/25815] [4.1 regression] ext/pb_assoc/example/erase_if.cc execution test
--- Comment #11 from hp at gcc dot gnu dot org 2006-03-08 18:35 --- Uh, make no mistake, this *is* a regression; see the original description. There's a revision before which this test worked and a revision after which it does not work. This happened in 4.1 era, so it's a 4.1 regression. Whether or not the code that the ext/pb_assoc test is *intended* to test is part of any gcc release is not central; it has no bearing on whether the behavior is a regression. It'd be like saying whether miscompilation of a piece of code being a regression depends on whether that code was part of the gcc release that miscompiled it. I changed the PR component to a historically more probable one, to avoid blaming libstdc++, as it seems that's an conclusion you're trying to avoid. -- hp at gcc dot gnu dot org changed: What|Removed |Added Component|libstdc++ |middle-end Summary|ext/pb_assoc/example/erase_i|[4.1 regression] |f.cc execution test |ext/pb_assoc/example/erase_i ||f.cc execution test http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25815
[Bug libgcj/12740] Stack trace infrastructure improvements
--- Comment #3 from mckinlay at redhat dot com 2006-03-08 18:36 --- Yes. This is fixed in GCC 4.1. -- mckinlay at redhat dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12740
[Bug middle-end/25815] [4.1 regression] ext/pb_assoc/example/erase_if.cc execution test
--- Comment #12 from pcarlini at suse dot de 2006-03-08 18:45 --- (In reply to comment #11) I changed the PR component to a historically more probable one, to avoid blaming libstdc++, as it seems that's an conclusion you're trying to avoid. Agreed, *as a miscompilation*, can be a regression. And, yes, I'm trying to avoid that conclusion, because, really, the chances that something show up in the libstdc++ side, without some help from you, a reduced testcase of sort, are close to zero, given the evidence we have got to date. Again, in my opinion, in such cases, it would be better to have available in Bugzilla an unclassified component. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25815
[Bug c/26607] New: Illegal inlined assembler on config/rs6000/darwin-ldouble.c
Gcc cannot process in-lined assembler, when configured for powerpc-gnuspe target (Note: that target does not have float point registers, but it has float point sinstructions that operates on the general purpose registers). ra8797:/local/gnu_toolchain/build_area/obj_gcc_gcc-trunk_e500v1/gcc /local/gnu_toolchain/build_area/obj_gcc_gcc-trunk_e500v1/./gcc/xgcc -B/local/gnu_toolchain/build_area/obj_gcc_gcc-trunk_e500v1/./gcc/ -B/local/gnu_toolchain/install-gcc-trunk-20060308-e500v1/powerpc-unknown-linux-gnuspe/bin/ -B/local/gnu_toolchain/install-gcc-trunk-20060308-e500v1/powerpc-unknown-linux-gnuspe/lib/ -isystem /local/gnu_toolchain/install-gcc-trunk-20060308-e500v1/powerpc-unknown-linux-gnuspe/include -isystem /local/gnu_toolchain/install-gcc-trunk-20060308-e500v1/powerpc-unknown-linux-gnuspe/sys-include -O2 -O2 -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -specs=ldblspecs -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I -I../../gcc-trunk/gcc -I../../gcc-trunk/gcc/ -I../../gcc-trunk/gcc/../include -I../../gcc-trunk/gcc/../libcpp/include -I../../gcc-trunk/gcc/../libdecnumber -I../libdecnumber -fPIC -mstrict-align -fvisibility=hidden -DHIDE_EXPORTS -c ../../gcc-trunk/gcc/config/rs6000/darwin-ldouble.c -o libgcc/./darwin-ldouble.o --save-temps -v Reading specs from /local/gnu_toolchain/build_area/obj_gcc_gcc-trunk_e500v1/./gcc/specs Reading specs from /local/gnu_toolchain/build_area/obj_gcc_gcc-trunk_e500v1/./gcc/ldblspecs Target: powerpc-unknown-linux-gnuspe Configured with: ../gcc-trunk/configure --prefix=/local/gnu_toolchain/install-gcc-trunk-20060308-e500v1 --with-local-prefix=/local/gnu_toolchain/install-gcc-trunk-20060308-e500v1 --enable-languages=c,c++ --enable-threads --target=powerpc-unknown-linux-gnuspe Thread model: posix gcc version 4.2.0 20060308 (experimental) /local/gnu_toolchain/build_area/obj_gcc_gcc-trunk_e500v1/./gcc/cc1 -E -quiet -v -I. -I -I../../gcc-trunk/gcc -I../../gcc-trunk/gcc/ -I../../gcc-trunk/gcc/../include -I../../gcc-trunk/gcc/../libcpp/include -I../../gcc-trunk/gcc/../libdecnumber -I../libdecnumber -iprefix /temp/gnu_toolchain/build_area/obj_gcc_gcc-trunk_e500v1/gcc/../lib/gcc/powerpc-unknown-linux-gnuspe/4.2.0/ -isystem /local/gnu_toolchain/build_area/obj_gcc_gcc-trunk_e500v1/./gcc/include -D__unix__ -D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux -D__linux -Asystem=linux -Asystem=unix -Asystem=posix -DIN_GCC -DCROSS_COMPILE -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -DHIDE_EXPORTS -isystem /local/gnu_toolchain/install-gcc-trunk-20060308-e500v1/powerpc-unknown-linux-gnuspe/include -isystem /local/gnu_toolchain/install-gcc-trunk-20060308-e500v1/powerpc-unknown-linux-gnuspe/sys-include -isystem ./include ../../gcc-trunk/gcc/config/rs6000/darwin-ldouble.c -mstrict-align -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -fPIC -fPIC -fvisibility=hidden -fworking-directory -O2 -O2 -O2 -fpch-preprocess -o darwin-ldouble.i ignoring nonexistent directory /local/gnu_toolchain/install-gcc-trunk-20060308-e500v1/powerpc-unknown-linux-gnuspe/include ignoring duplicate directory ./include ignoring nonexistent directory /temp/gnu_toolchain/build_area/obj_gcc_gcc-trunk_e500v1/gcc/../lib/gcc/powerpc-unknown-linux-gnuspe/4.2.0/include ignoring nonexistent directory /temp/gnu_toolchain/build_area/obj_gcc_gcc-trunk_e500v1/gcc/../lib/gcc/powerpc-unknown-linux-gnuspe/4.2.0/../../../../powerpc-unknown-linux-gnuspe/sys-include ignoring nonexistent directory /temp/gnu_toolchain/build_area/obj_gcc_gcc-trunk_e500v1/gcc/../lib/gcc/powerpc-unknown-linux-gnuspe/4.2.0/../../../../powerpc-unknown-linux-gnuspe/include ignoring duplicate directory /local/gnu_toolchain/install-gcc-trunk-20060308-e500v1/lib/gcc/powerpc-unknown-linux-gnuspe/4.2.0/../../../../powerpc-unknown-linux-gnuspe/sys-include ignoring nonexistent directory /local/gnu_toolchain/install-gcc-trunk-20060308-e500v1/lib/gcc/powerpc-unknown-linux-gnuspe/4.2.0/../../../../powerpc-unknown-linux-gnuspe/include ignoring nonexistent directory -I../../gcc-trunk/gcc #include ... search starts here: #include ... search starts here: . ../../gcc-trunk/gcc/ ../../gcc-trunk/gcc/../include ../../gcc-trunk/gcc/../libcpp/include ../../gcc-trunk/gcc/../libdecnumber ../libdecnumber /local/gnu_toolchain/build_area/obj_gcc_gcc-trunk_e500v1/./gcc/include /local/gnu_toolchain/install-gcc-trunk-20060308-e500v1/powerpc-unknown-linux-gnuspe/sys-include /local/gnu_toolchain/install-gcc-trunk-20060308-e500v1/lib/gcc/powerpc-unknown-linux-gnuspe/4.2.0/include End of search list. /local/gnu_toolchain/build_area/obj_gcc_gcc-trunk_e500v1/./gcc/cc1 -fpreprocessed darwin-ldouble.i -quiet -dumpbase darwin-ldouble.c -mstrict-align -auxbase-strip libgcc/./darwin-ldouble.o -g -g -O2 -O2 -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold
[Bug tree-optimization/26608] New: address of local variables are said to escape even though it is obvious they don't
Testcase:
int *d1;
int g(int *b)
{
d1 = b;
}
int f(int a, int b, int c)
{
int i, j;
int *d;
if (a)
d = i;
else
d = j;
i = 2;
j = 3;
g(b);
if (i!=2)
link_error();
if (j!=3)
link_error();
return *d;
}
int main(void)
{
f(1, 2,3);
return 0;
}
This should link with optimize but right now i and j are said to be call
clobbered for some reason.
--
Summary: address of local variables are said to escape even
though it is obvious they don't
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: missed-optimization, alias
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26608
[Bug target/26607] Illegal inlined assembler on config/rs6000/darwin-ldouble.c
--- Comment #1 from edmar at freescale dot com 2006-03-08 19:01 --- Created an attachment (id=10994) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10994action=view) Intermediate file for reported bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26607
[Bug target/26607] [4.2 Regression] Illegal inlined assembler on config/rs6000/darwin-ldouble.c
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC host triplet|x86_64-unknown-linux-gnu| Summary|Illegal inlined assembler on|[4.2 Regression] Illegal |config/rs6000/darwin- |inlined assembler on |ldouble.c |config/rs6000/darwin- ||ldouble.c Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26607
[Bug libgomp/26165] Cannot find libgomp.spec after 'make install' on x86_64 and ppc64
--- Comment #1 from aldyh at gcc dot gnu dot org 2006-03-08 19:05 --- I can reproduce the runtime error, but not the compile error. pantani:/tmp/2$ type gcc gcc is /tmp/2/bin/gcc pantani:/tmp/2$ gcc a.c -fopenmp pantani:/tmp/2$ ./a.out ./a.out: error while loading shared libraries: libgomp.so.1: cannot open shared object file: No such file or directory pantani:/tmp/2$ uname -a Linux pantani 2.6.11-1.1369_FC4smp #1 SMP Thu Jun 2 23:16:33 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux Diego, is this still an issue on mainline? I can look into the runtime error, though. -- aldyh at gcc dot gnu dot org changed: What|Removed |Added CC||aldyh at gcc dot gnu dot org AssignedTo|unassigned at gcc dot gnu |aldyh at gcc dot gnu dot org |dot org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26165
[Bug libgomp/26165] Cannot find libgomp.spec after 'make install' on x86_64 and ppc64
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-08 19:07 --- Subject: Re: Cannot find libgomp.spec after 'make install' on x86_64 and ppc64 --- Comment #1 from aldyh at gcc dot gnu dot org 2006-03-08 19:05 --- I can reproduce the runtime error, but not the compile error. pantani:/tmp/2$ type gcc gcc is /tmp/2/bin/gcc pantani:/tmp/2$ gcc a.c -fopenmp pantani:/tmp/2$ ./a.out ./a.out: error while loading shared libraries: libgomp.so.1: cannot open shared object file: No such file or directory pantani:/tmp/2$ uname -a Linux pantani 2.6.11-1.1369_FC4smp #1 SMP Thu Jun 2 23:16:33 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux Diego, is this still an issue on mainline? I can look into the runtime error, though. The runtime issue is most likey just not having the correct path in LD_LIBRARY_PATH. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26165
Re: [Bug libgomp/26165] Cannot find libgomp.spec after 'make install' on x86_64 and ppc64
--- Comment #1 from aldyh at gcc dot gnu dot org 2006-03-08 19:05 --- I can reproduce the runtime error, but not the compile error. pantani:/tmp/2$ type gcc gcc is /tmp/2/bin/gcc pantani:/tmp/2$ gcc a.c -fopenmp pantani:/tmp/2$ ./a.out ./a.out: error while loading shared libraries: libgomp.so.1: cannot open shared object file: No such file or directory pantani:/tmp/2$ uname -a Linux pantani 2.6.11-1.1369_FC4smp #1 SMP Thu Jun 2 23:16:33 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux Diego, is this still an issue on mainline? I can look into the runtime error, though. The runtime issue is most likey just not having the correct path in LD_LIBRARY_PATH. -- Pinski
[Bug target/26607] [4.2 Regression] Illegal inlined assembler on config/rs6000/darwin-ldouble.c
--- Comment #2 from edmar at freescale dot com 2006-03-08 19:10 --- Same error observed on gcc-4_1-branch 20060308 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26607
[Bug target/26607] [4.1/4.2 Regression] Illegal inlined assembler on config/rs6000/darwin-ldouble.c
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |blocker Summary|[4.2 Regression] Illegal|[4.1/4.2 Regression] Illegal |inlined assembler on|inlined assembler on |config/rs6000/darwin- |config/rs6000/darwin- |ldouble.c |ldouble.c Target Milestone|4.2.0 |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26607
[Bug target/26607] [4.1/4.2 Regression] Illegal inlined assembler on config/rs6000/darwin-ldouble.c
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-08 19:11 --- This was caused by the 128bit long doubles patches (well really caused by a secondary patch to work around a code gen issue). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||amodra at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26607
[Bug libgcj/18266] SIGSEGV in GC_register_finalizer_inner ()
--- Comment #14 from tromey at gcc dot gnu dot org 2006-03-08 19:27 --- I've been looking into this a bit. The current problem I see is that the heavyweight lock stuff relies on the GC. This won't interact well with the current code in natReference.cc, as those data structures are not scanned. Also, I do think that both calls to _Jv_RegisterFinalizer in Reference::create are problematic. The first call registers a finalizer for the Reference, the second for the referent. But, there is nothing preventing a subclass of Reference from having a finalizer; or from user code acquiring a heavy lock on a Reference object. So, all cases have to be handled here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18266
[Bug c++/26352] ICE
--- Comment #8 from igodard at pacbell dot net 2006-03-08 19:29 --- Well I was really surprised to see this -fpreprocessed option in the -v output, so I did a little digging. It seems that this option is set by the driver whenever -save-temps is set. It does not come from my command line. Try it: compile something -v, and then compile the same thing -v -save-temps and the first -v will not have -fpreprocessed and the second one will. The bug report instructions say to run with -save-temps so I do. You might ask internally why the driver sets these when the user asks for -save-temps. I think the generated -fpreprocessed is irrelevant to the bug, because it will be set on every compile that produces a .ii file for you and I've put in a few of those :-) Ivan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26352
[Bug tree-optimization/26609] New: may aliasing set is set too large
Testcase:
int h(int *);
struct a1
{
int i[2];
};
void link_error();
int f(struct a1 a, int i,int *c)
{
int b;
void *g = a.i[i];
*(int*)g = 1;
h(b);
if (a.i[i] !=1)
link_error();
return b+c[i*2];
}
---
# VUSE b_19;
# VUSE SFT.3_20;
# VUSE SFT.4_21;
D.1996_14 = *D.1995_13;
That is very imprecise and actually stays throught the whole compiling.
This is a reduced testcase from tramp3d, the void* comes from inlining inplace
operator new.
--
Summary: may aliasing set is set too large
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: missed-optimization, memory-hog, compile-time-hog
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26609
Re: [Bug tree-optimization/26608] New: address of local variables are said to escape even though it is obvious they don't
On Wed, 2006-03-08 at 18:59 +, pinskia at gcc dot gnu dot org wrote:
Testcase:
int *d1;
int g(int *b)
{
d1 = b;
}
int f(int a, int b, int c)
{
int i, j;
int *d;
if (a)
d = i;
else
d = j;
i = 2;
j = 3;
g(b);
if (i!=2)
link_error();
if (j!=3)
link_error();
return *d;
}
int main(void)
{
f(1, 2,3);
return 0;
}
This should link with optimize but right now i and j are said to be call
clobbered for some reason.
What does the dump say.
My guess is that it believes that they are returned from the call, even
though they are not.
[Bug tree-optimization/26608] address of local variables are said to escape even though it is obvious they don't
--- Comment #1 from dberlin at gcc dot gnu dot org 2006-03-08 19:44 ---
Subject: Re: New: address of local variables
are said to escape even though it is obvious they don't
On Wed, 2006-03-08 at 18:59 +, pinskia at gcc dot gnu dot org wrote:
Testcase:
int *d1;
int g(int *b)
{
d1 = b;
}
int f(int a, int b, int c)
{
int i, j;
int *d;
if (a)
d = i;
else
d = j;
i = 2;
j = 3;
g(b);
if (i!=2)
link_error();
if (j!=3)
link_error();
return *d;
}
int main(void)
{
f(1, 2,3);
return 0;
}
This should link with optimize but right now i and j are said to be call
clobbered for some reason.
What does the dump say.
My guess is that it believes that they are returned from the call, even
though they are not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26608
[Bug tree-optimization/26609] may aliasing set is set too large
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-08 19:44 --- Also this bug which is most likely what is causing there to be too many VOPS in the current representation which is why I added memory-hog and compile-time-hog to the keywords. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26609
[Bug tree-optimization/26608] address of local variables are said to escape even though it is obvious they don't
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-08 19:47 ---
Variable: i, UID 1520, int, is aliased, is addressable, default def: i_3
Variable: j, UID 1521, int, is aliased, is addressable, default def: j_5
Variable: b, UID 1516, int, is aliased, is addressable, call clobbered (,
passed to call )
Variable: SMT.30, UID 1569, int, is addressable, call clobbered (, passed to
call ), may aliases: { i j b }
Hmm, it does not say why i and j are thought to be call clobbered but it looks
like it is because the SMT is call clobbered.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26608
[Bug awt/22163] scrollbars appear and disappear
--- Comment #1 from langel at redhat dot com 2006-03-08 20:51 --- Created an attachment (id=10995) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10995action=view) roll mouse over text area and choice box -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22163
[Bug tree-optimization/26609] may aliasing set is set too large
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-08 21:24 --- Hmm, looking at this again, it looks really like PR 23086. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||23086 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26609
[Bug libfortran/25378] [Fortran 2003] maxloc for all-false mask
--- Comment #2 from pault at gcc dot gnu dot org 2006-03-08 21:44 ---
I have a patch which is just now regtesting. It does the obvious:
set initial index = 0
if (the max/min condition is met or index = 0)
{
set index to the current position
update the value for comparison
}
This has been done in trans-intrinsic.c and in the library. Have updated the
present testcases; I do not see a need for any more.
Will submit in the morning.
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=25378
[Bug target/26610] New: [3.4 only] ICE: unable to find a register to spill in class `FLOAT_REGS'
This bug is very similar to http://gcc.gnu.org/PR21616 but is not fixed with
the patch associated with that bug. Using the latest 3_4 branch code, I'm
seeing the following ICE (compiles fine using GCC 3.3.3 and 4.1):
[EMAIL PROTECTED] ./install-3_4/bin/gcc -v -Os -m64 -c -msoft-float
-mminimal-toc raid6int8.i
Reading specs from
/home/bergner/install-3_4/lib/gcc/powerpc64-linux/3.4.6/specs
Configured with: /home/bergner/gcc-20060308-3_4/configure
--target=powerpc64-linux --host=powerpc64-linux --build=powerpc64-linux
--with-cpu=default32 --enable-threads=posix --enable-shared
--enable-languages=c --disable-checking --prefix=/home/bergner/install-3_4
Thread model: posix
gcc version 3.4.6
/home/bergner/install-3_4/libexec/gcc/powerpc64-linux/3.4.6/cc1 -fpreprocessed
raid6int8.i -quiet -dumpbase raid6int8.i -m64 -msoft-float -mminimal-toc
-auxbase raid6int8 -Os -version -o /tmp/cc83eiKe.s
GNU C version 3.4.6 (powerpc64-linux)
compiled by GNU C version 3.3.3 (SuSE Linux).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
raid6int8.i: In function `raid6_int8_gen_syndrome':
raid6int8.i:134: error: unable to find a register to spill in class
`FLOAT_REGS'
raid6int8.i:134: error: this is the insn:
(insn:HI 622 624 643 5 (set (mem:DI (plus:DI (reg/v/f:DI 122 [ p ])
(reg/v:DI 66 ctr [orig:124 d ] [124])) [9 S8 A64])
(reg/v:DI 129 [ wp0 ])) 320 {*movdi_internal64} (nil)
(expr_list:REG_DEAD (reg/v:DI 129 [ wp0 ])
(nil)))
raid6int8.i:134: confused by earlier errors, bailing out
--
Summary: [3.4 only] ICE: unable to find a register to spill in
class `FLOAT_REGS'
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bergner at vnet dot ibm dot com
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=26610
[Bug target/26610] [3.4 only] ICE: unable to find a register to spill in class `FLOAT_REGS'
--- Comment #1 from bergner at vnet dot ibm dot com 2006-03-08 22:03 --- Created an attachment (id=10997) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10997action=view) Reduced test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26610
[Bug target/26610] [3.4 only] ICE: unable to find a register to spill in class `FLOAT_REGS'
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-08 22:07 --- 3.4.6 is frozen and 3.4.x is now retired. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26610
[Bug awt/22163] scrollbars appear and disappear
--- Comment #2 from langel at redhat dot com 2006-03-08 22:18 --- Created an attachment (id=10998) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10998action=view) problem is caused because of the drawImage call in paint. updated test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22163
[Bug target/26607] [4.1/4.2 Regression] Illegal inlined assembler on config/rs6000/darwin-ldouble.c
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-08 22:21 --- I should had looked into this one. This is what I was afraid of when this idea 128bits long double went it. It was not the optimization which I thought was applied but instead just the compiling of darwin-ldouble.c on powerpc-linux-gnuspe which caused it: 2006-01-27 David Edelsohn [EMAIL PROTECTED] Alan Modra [EMAIL PROTECTED] * config/rs6000/t-ppccomm (LIB2FUNCS_EXTRA): Add darwin-ldouble.c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26607
[Bug c++/26605] using + function templates troubles
--- Comment #10 from mmitchel at gcc dot gnu dot org 2006-03-08 22:28
---
I think the code in Comment #1 is unambiguously invalid.
7.3.3/11 says says that a function declaration in namespace scope may not match
the declaration of a function introduced by a using declaration; i.e., the
following:
namespace N { void f(); };
using N::f;
void f();
is invalid. Making the functions templates does not change that. That
paragraph also makes clear that the code in Comment #9 is valid. I don't see
any DRs that suggest changes in this area.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26605
[Bug libgomp/26611] New: openmp gomp ICE at gimplify.c:4257
I consistently get the following ICE on this C++ code. omp_harness.cpp:39: internal compiler error: in omp_add_variable, at gimplify.c:4257 The code is not legit and there are several errors but this is because I have cut down a larger program. I am using the gomp-branch and gcc -v reports: Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gomp-20050608-branch/configure --prefix=/local_scratch/owe043/gcc_gomp Thread model: posix gcc version 4.2.0-gomp-20050608-branch 20060216 (experimental) (merged 20060216) The command line I used to compile was: g++ -save-temps -fopenmp omp_harness.cpp -- Summary: openmp gomp ICE at gimplify.c:4257 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bowie dot owens at csiro dot au GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26611
[Bug libgomp/26611] openmp gomp ICE at gimplify.c:4257
--- Comment #1 from bowie dot owens at csiro dot au 2006-03-08 22:34 --- Created an attachment (id=10999) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10999action=view) preprocessed output from save-temps that triggers ICE GZIP compressed to make it within the size limit. Will try and make a smaller example that doesn't involve valarray or iostreams. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26611
