[Bug ada/20270] [4.1 Regression] Link error: unsatisfied symbols

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-02 00:44 --- *** Bug 20271 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20270

[Bug ada/20270] [4.1 Regression] Link error: unsatisfied symbols

--- Additional Comments From danglin at gcc dot gnu dot org 2005-03-02 00:50 --- I believe that this was introduced bt the following: -TOOLS_FLAGS_TO_PASS= \ -"CC=$(CC)" \ -"CFLAGS=$(CFLAGS)" \ - "LDFLAGS=$(LDFLAGS)"\ -"ADAFLAG

[Bug target/18723] [C] gcc 3.4.4 zeroes inline function argument with "-O2 -march=pentium4"

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-02 00:54 --- If -fno-strict-aliasing fixes the problem, then you have an aliasing problem in the source. So closing as invalid. -- What|Removed |Added ---

[Bug c/20272] New: AltiVec vector instructions fail unless compiled with -force_cpusubtype_ALL

On MacOS 10.3, when I compile Altivec programs that use certain builtins, in particular the vec_ste() function, specifying -faltivec and/or -mcpu=7400, gcc-4.1-20050227 gives me the following error: /var/tmp//ccpZcozX.s:16:lvx vector instruction is optional for the PowerPC (not allowed without

[Bug c/20272] AltiVec vector instructions fail unless compiled with -force_cpusubtype_ALL

--- Additional Comments From stevenj at alum dot mit dot edu 2005-03-02 01:43 --- Created an attachment (id=8308) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8308&action=view) preprocessed test case the test case's preprocessed source doesn't seem to be showing up properly in th

[Bug target/20272] AltiVec vector instructions fail unless compiled with -force_cpusubtype_ALL

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-02 01:52 --- This works for me with a non modified source. I get the following in the asm which makes it works: .machine ppc7400 Are you sure that you running with the latested cctools and not with a modifed

[Bug c/8927] Gcc give error for wrong line of C code.

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-02 02:50 --- Subject: Bug 8927 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-02 02:50:26 Modified files: gcc: ChangeLog c-decl.c c-parser.c c-tree.h

[Bug c/8927] Gcc give error for wrong line of C code.

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-02 02:53 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED

[Bug c/8927] Gcc give error for wrong line of C code.

--- Additional Comments From joseph at codesourcery dot com 2005-03-02 02:56 --- Subject: Re: Gcc give error for wrong line of C code. On Wed, 2 Mar 2005, pinskia at gcc dot gnu dot org wrote: > Fixed. > > -- >What|Removed |Added > ---

[Bug libgcj/20273] New: LinkedHashMap breaks linked list when access() is called

File: gcc/libjava/java/util/LinkedHashMap.java CVS Version: 1.6 When using "accessOrder"-based sorting in LinkedHashMap, the linked list appears to become broken after calling get(). I believe that this is due to a missing line in the access() function. I believe that the following line needs to b

[Bug c/8927] Gcc give error for wrong line of C code.

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-02 02:59 --- (In reply to comment #9) > In 4.1.0, not 4.0.0. Slip of the fingers. I was so used to closing bugs as fixed for 4.0.0. -- What|Removed |Added

[Bug libgcj/20273] LinkedHashMap breaks linked list when access() is called

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-02 03:17 --- Do you have a testcase? -- What|Removed |Added CC|

[Bug libgcj/20273] LinkedHashMap breaks linked list when access() is called

--- Additional Comments From soleger at nc dot rr dot com 2005-03-02 03:34 --- Created an attachment (id=8309) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8309&action=view) Java test case for LinkedHashMapEntry.access() bug Simply compile and run the class with gcj. The expected

[Bug libgcj/20273] LinkedHashMap breaks linked list when access() is called

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-02 03:40 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW E

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

-- Bug 5900 depends on bug 19619, which changed state. Bug 19619 Summary: LAPACK optimisation error http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19619 What|Old Value |New Value

[Bug fortran/19619] LAPACK optimisation error

--- Additional Comments From billingd at gcc dot gnu dot org 2005-03-02 03:56 --- Gone away. Probably fixed by complex division algorithm change. -- What|Removed |Added

[Bug target/20272] AltiVec vector instructions fail unless compiled with -force_cpusubtype_ALL

--- Additional Comments From stevenj at alum dot mit dot edu 2005-03-02 04:16 --- (In reply to comment #2) > You need at least cctools 528.5 to have this work correctly. Ah, thanks, I just saw http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01222.html ...yes, when I install cctools 528.5 t

[Bug target/20272] AltiVec vector instructions fail unless compiled with -force_cpusubtype_ALL

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-02 04:20 --- Ok, closing as will works for me. Note this is also documented in the documention of installation. Also if you compiled with C++ you would recieve an error because a need for a new relocate which is wha

[Bug debug/20268] g++ generates incomplete debug information for given testcase with optimization

--- Additional Comments From dberlin at gcc dot gnu dot org 2005-03-02 04:49 --- Debug output for inlining, etc, isn't actually driven by the callgraph, so yes, it can get out of sync with reality (it's not supposed to, but it does). In particular, it is possible we are missing some in

[Bug middle-end/20274] New: -fvisibility=hidden has no effect on calling undefined function

bash-3.00$ cat x.c #if 1 extern void foo (); #else extern void foo () __attribute__((visibility ("hidden"))); #endif void bar () { foo (); } bash-3.00$ ./xgcc -B./ -fPIC -O2 x.c -S -fvisibility=hidden bash-3.00$ more x.s .file "x.c" .text .p2align 4,,15 .globl bar

[Bug middle-end/20274] -fvisibility=hidden has no effect on calling undefined function

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-02 05:18 --- Seems like someone forgot to apply the visibility to the undefined functions, though that might be on purpose. -- What|Removed |Added --

[Bug middle-end/20274] -fvisibility=hidden has no effect on calling undefined function

--- Additional Comments From hjl at lucon dot org 2005-03-02 06:46 --- If it is on purpose, it should be documented, something like -fvisibility=hidden can be used to access the global data/function defined in the same file as if they are local. It may make -fvisibility=hidden less useful

[Bug c++/20275] New: Mandatory inlining of templetized class member fails for no reason

Compiling following code get error below. Once I remove template<> from class R it inlines fine. Yuri --- begin code --- #define inline __attribute__ ((__always_inline__)) template struct R { inline void R::r(int& c); }; template inline void R::r(int& c) { } class BB {}; void f(R *rr) { i

[Bug c++/20275] Mandatory inlining of templetized class member fails for no reason

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-02 06:53 --- Yes there is a reason, this is just a bug in gcc :). In fact a regression from 3.3.x. But is fixed already in 4.0.0. This is a dup of bug 14950. *** This bug has been marked as a duplicate of 14950 ***

[Bug c++/14950] [3.4 Regression] [non unit-at-a-time] always_inline does not mix with templates and -O0

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-02 06:53 --- *** Bug 20275 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug regression/20276] New: 64bit target uses __adddi3

I just tried out a CVS copy of gcc and found problems with the following code: long foo() { long int word; word += 2147483647UL; return word; } When compiled as 64bit uses the __adddi3 helper function: mflr 0 li 4,-1 rldicl 4,4,0,33 std 0,1

[Bug target/20276] [4.1 Regression] 64bit PPC target uses __adddi3

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-02 07:20 --- Confirmed, this is a very very recent regression. It worked with 20050225 but not with 20050301. Note my 20050225 was right after 4.0.0 branched and nothing much has changed on the branch yet. This only

[Bug c/20260] gcc-3.4.3 crashes with a segmentation fault when compiling gtk+-2.6.3 on Linux.

--- Additional Comments From tomdkat at comcast dot net 2005-03-02 07:29 --- Well, I re-built gcc-3.4.3 and recompiled gtk 2.6.3 just fine. Maybe I had a bad gtk installation previously? Go figure. Sorry for wasting your time. :) Peace... -- http://gcc.gnu.org/bugzilla/show_bug.

[Bug c/20277] New: -mcpu=power4 vs. -maltivec

Since 3.4.x, you can't use both -mcpu=power4 and -maltivec on ppc targets. This is critical that it's fixed before 4.0 as the linux kernel will rely on this. It's currently using -mcpu=970 as a workaround since it has one file using -maltivec (the RAID6 code), but this workaround isn't suitable for

[Bug target/20277] [3.4/4.0/4.1 Regression] -mcpu=power4 vs. -maltivec

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-02 07:36 --- Confirmed, a regression from 3.3.3 and happens on all ppc targets. And a patch here: . -- What|Removed |Added ---

[Bug java/5537] Error compiling simple bytecode with jsr

--- Additional Comments From rmathew at gcc dot gnu dot org 2005-03-02 07:54 --- (In reply to comment #13) > What's the take on this bug? Can indirect-dispatch be made the default in the > foreseable future? Can the old verifier be fixed? > > I'm now running nightly builds of gcj on the

<    1   2