--- Comment #9 from pinskia at gcc dot gnu dot org 2006-04-03 07:06 ---
(In reply to comment #8)
> It's interesting it's working in gcc then...
Not really as we emulate what the weakref asm op does with weak and alias.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26966
--- Comment #10 from kgardas at objectsecurity dot com 2006-04-03 07:08
---
Subject: Re: linking of C++ app fail on OpenBSD 3.9 due
POSIX threading unresolved symbols
Small addition to previous post. Although .weakref is not supported, .weak
is:
$ cat /tmp/weak-conftest.s
.w
--- Comment #5 from stigge at antcom dot de 2006-04-03 07:12 ---
It's not that we need special casing for a certain language: The TP robot is
generally broken (doesn't respond to translator's requests). I reported it
there several times, to no avail.
--
http://gcc.gnu.org/bugzilla/s
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-04-03 07:21
---
Wait a minute, libstdc++ is being built only as a static library looking at the
error message from comment #0. But that should not really.
Can you try an objective-C compiling for me to see if it is just libstdc+
We ICE on the air Polyhedron test with -march=pentium4 -ffast-math
-funroll-loops -O3 -ftree-vectorize:
/space/rguenther/tramp3d/pb05/lin/source/air.f90: In function bound:
/space/rguenther/tramp3d/pb05/lin/source/air.f90:1119: internal compiler error:
in fold_convert, at fold-const.c:2089
#1 0
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-03 07:54 ---
The simplest solution looks like to punt on vector types in
interpret_rhs_modify_expr.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26996
--- Comment #12 from kgardas at objectsecurity dot com 2006-04-03 08:01
---
Subject: Re: linking of C++ app fail on OpenBSD 3.9 due
POSIX threading unresolved symbols
Sorry, I've enabled only c++ for this build and I would prefer not to
rebuild if possible, since c/c++ took about 4-
--- Comment #3 from pluto at agmk dot net 2006-04-03 08:07 ---
(In reply to comment #0)
> (...) This is as expected: they are not used by
> any actual code, so there is no need to emit debug info for them.
so, what for is the -feliminate-unused-debug-symbols?
--
http://gcc.gnu.org
The program below reports the following compiler errors:
bug.cpp:17: error: expected primary-expression before '*' token
bug.cpp:17: error: expected primary-expression before ')' token
bug.cpp:17: error: expected `;' before 'malloc'
which seem to refer to the first occurence of identifier "t"
on
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-04-03 09:12
---
With the patch we now can no longer figure out the number of iterations of the
inner loop, because we have an exit condition of i1D.1522_6 != 2147483647 now!?
Which we cannot simplify against i1D.1522_6 >= 0 (I wil
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-04-03 09:19
---
Hmm, this cannot be simplified.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26939
--- Comment #4 from spop at gcc dot gnu dot org 2006-04-03 09:59 ---
Subject: Bug 26992
Author: spop
Date: Mon Apr 3 09:59:38 2006
New Revision: 112635
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112635
Log:
PR bootstrap/26992
* tree-scalar-evolution.c (compu
Bootstrap fails because we have
Starting program: /abuild/rguenther/obj/prev-gcc/cc1 -quiet -v
-I../../trunk/libdecnumber -I. -I../../trunk/libdecnumber -I. -iprefix
/abuild/rguenther/obj/prev-gcc/../lib/gcc/ia64-unknown-linux-gnu/4.2.0/
-isystem /abuild/rguenther/obj/./prev-gcc/include
../../trun
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-03 10:17 ---
Created an attachment (id=11187)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11187&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26998
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-03 10:17 ---
Jeff messed with VRP, so I guess he may have a clue.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Trying to workaround the ia64 bootstrap problem with --disable-libdecnumber
causes
gcc -c -DUSE_LIBUNWIND_EXCEPTIONS -g -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I.
-I../../tru
On the testcases below GCC marks even instantiated templates
with the currently pushed visibility, in case of the first testcase
that's hidden (anonymous namespace) and in the third testcase hidden as well
(namespace with visibility attribute).
But the template really wasn't declared as hidden and
--- Comment #1 from jakub at gcc dot gnu dot org 2006-04-03 11:11 ---
Created an attachment (id=11188)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11188&action=view)
firsttest.C
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27000
--- Comment #2 from jakub at gcc dot gnu dot org 2006-04-03 11:11 ---
Created an attachment (id=11189)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11189&action=view)
secondtest.C
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27000
--- Comment #3 from jakub at gcc dot gnu dot org 2006-04-03 11:12 ---
Created an attachment (id=11190)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11190&action=view)
thirdtest.C
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27000
--- Comment #4 from jakub at gcc dot gnu dot org 2006-04-03 11:18 ---
I'd say we should remember template's visibility and use that during
instantiation, rather than the currently pushed visibility.
The question is if we want to do that for all template instantiations, or have
cases whe
--- Comment #24 from bonzini at gnu dot org 2006-04-03 11:20 ---
Subject: Bug 19653
Author: bonzini
Date: Mon Apr 3 11:20:07 2006
New Revision: 112637
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112637
Log:
2005-08-08 Paolo Bonzini <[EMAIL PROTECTED]>
Dale Joha
--- Comment #25 from bonzini at gnu dot org 2006-04-03 11:20 ---
fixed on mainline.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
The following code snippet causes an ICE on x86_64-unknown-linux-gnu
when compiled with "-fschedule-insns -fstack-protector-all".
This happens since 4.1.0 when -fstack-protector-all was introduced.
=
int foo(int i)
{
i /=
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-03 11:25 ---
Also fails on x86_64
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Sum
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-03 11:26 ---
Created an attachment (id=11191)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11191&action=view)
patch that may be needed to trigger the problem
This patch is what I am trying to bootstrap/regtest.
--
ht
The following Fortran code snippet causes an ICE (segfault) when compiled
with "-fipa-pta -O":
==
subroutine BAR()
call FOO (0)
end subroutine BAR
==
--
Summary: ICE with -fipa-pta whe
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-03 11:33 ---
Note we have NEGATE_EXPR where X has VR of
(gdb) print vr0
$4 = {type = VR_ANTI_RANGE, min = 0x2a95891b40, max = 0x2a95891b40,
equiv = 0xf73b20}
(same min/max!) Also,
if (code == NEGATE_EXPR
&& !TYPE_U
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-04-03 11:35 ---
Something like
Index: tree-vrp.c
===
*** tree-vrp.c (revision 112634)
--- tree-vrp.c (working copy)
*** extract_range_from_unary_expr (va
unsigned int
foo (unsigned int x)
{
unsigned int r = x;
while (--x)
r *= x;
return r;
}
unsigned long long
bar (unsigned long long x)
{
unsigned long long r = x;
while (--x)
r *= x;
return r;
}
extern void abort (void);
int
main (void)
{
if (foo (5) != 120 || bar (5) != 120
--- Comment #3 from green at redhat dot com 2006-04-03 13:02 ---
Azureus users on FC5 see this as well (gcj 4.1.0). Here's a slightly
different stack trace.
[12:31:21.648] {stderr} DEBUG::Mon Apr 03 12:31:21 GMT
2006::com.aelitis.azureus.core.networkmanager.VirtualChannelSelector::sel
--- Comment #25 from bonzini at gnu dot org 2006-04-03 13:37 ---
Subject: Bug 26830
Author: bonzini
Date: Mon Apr 3 13:37:07 2006
New Revision: 112639
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112639
Log:
2006-04-03 Paolo Bonzini <[EMAIL PROTECTED]>
PR tree-opti
--- Comment #26 from bonzini at gnu dot org 2006-04-03 13:40 ---
compile-time should be fixed on 4.1 (richard, could you confirm). spinning a
separate bug for the salias memory hog problems.
zdenek wanted to investigate manual SSA update of real operands for 4.2
--
bonzini at gnu d
spinning a separate bug from PR26830. we are creating a lot of field memory
tags, each of which is present in a 900-argument phi, which causes us to use
more memory than 4.0.
to some extent this is unavoidable, but I wonder if we could throttle things
down a bit?
--
Summary: [4.1/4.
--- Comment #27 from rakdver at gcc dot gnu dot org 2006-04-03 14:16
---
With a bit simplified testcase (my computer does not have enough memory for
this one), we spend 30% of compile time in rewrite_update_phi_arguments.
However, only 1.6% (less then 1% of compile time) of the
rewrite_
--- Comment #8 from aph at gcc dot gnu dot org 2006-04-03 14:31 ---
Subject: Bug 26858
Author: aph
Date: Mon Apr 3 14:31:56 2006
New Revision: 112640
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112640
Log:
2006-04-03 Andrew Haley <[EMAIL PROTECTED]>
PR java/26858
--- Comment #1 from dberlin at gcc dot gnu dot org 2006-04-03 14:37 ---
Subject: Re: New: [4.1/4.2 Regression]
Insane amount of memory needed at -O1 and above because of salias
On Mon, 2006-04-03 at 13:43 +, bonzini at gnu dot org wrote:
> spinning a separate bug from PR26
--- Comment #2 from rguenther at suse dot de 2006-04-03 14:39 ---
Subject: Re: [4.1/4.2 Regression] Insane amount
of memory needed at -O1 and above because of salias
On Mon, 3 Apr 2006, dberlin at dberlin dot org wrote:
> On Mon, 2006-04-03 at 13:43 +, bonzini at gnu dot org wrot
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-03 14:59 ---
This option should not exist, try --disable-libcpp and you will get even
worse.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26999
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-04-03 15:02 ---
The patch is bogus, but the problem in the source looks still valid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26998
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-03 15:04 ---
I bet you can reproduce this with using "#pragma GCC visibility", without
namespaces. Related to PR 26984.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-03 15:06 ---
This is the normal problem of using specific registers for multiplication on
x86 and x86_64 so running out of registers is easy :).
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from aph at gcc dot gnu dot org 2006-04-03 15:22 ---
Subject: Bug 26858
Author: aph
Date: Mon Apr 3 15:22:21 2006
New Revision: 112641
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112641
Log:
2006-04-03 Andrew Haley <[EMAIL PROTECTED]>
PR java/26858
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-03 15:22 ---
I still say x86 should be using HWI of 64bits anyways.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-03 15:34 ---
types are not expressions though.
It is not incorrect but just misleading.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pavel dot petrovic at gmail dot com 2006-04-03 16:03
---
(In reply to comment #1)
> types are not expressions though.
sure, but I wouldn't mind that, the compiler complains
about expression, not about type. isn't typecasting
an expression after all?
> It is not inc
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-03 16:16 ---
In fact this is a latent bug shown by:
/* { dg-do compile } */
/* { dg-require-visibility "" } */
/* { dg-final { scan-not-hidden "_ZN1SIiED1Ev" } } */
/* { dg-final { scan-not-hidden "_ZN1SIiEC1ERKi" } } */
templat
--- Comment #28 from rguenth at gcc dot gnu dot org 2006-04-03 16:20
---
I confirm, that with -fno-tree-salias -O1 4.1.1 is on-par with -O1 4.0.3. So
all remaining compile-time/memory problems are due to extra virtual operands.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
--- Comment #6 from orion at cora dot nwra dot com 2006-04-03 16:24 ---
Hmm, tried adding -save-temps to my flags so that I could collect .s and .i
files, but it appears that the segfault also goes away. Removing -save-temps
indeed goes back to the previous behavior. Removing -pipe has
--- Comment #29 from rakdver at gcc dot gnu dot org 2006-04-03 16:31
---
(In reply to comment #27)
> With a bit simplified testcase (my computer does not have enough memory for
> this one), we spend 30% of compile time in rewrite_update_phi_arguments.
> However, only 1.6% (less then 1%
--- Comment #7 from patchapp at dberlin dot org 2006-04-03 16:45 ---
Subject: Bug number PR26763
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00082.html
--
http://gcc.gnu.org/bugzilla/sh
I am using gcc 3.4.3 on solais 10.
g++ -v:
Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/specs
Configured with: /builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure
--prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as
--with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-lan
--- Comment #1 from boris dot breidenbach at physik dot uni-erlangen dot de
2006-04-03 16:51 ---
Created an attachment (id=11192)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11192&action=view)
buggy code with comments
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27005
--- Comment #2 from boris dot breidenbach at physik dot uni-erlangen dot de
2006-04-03 16:52 ---
Created an attachment (id=11193)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11193&action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27005
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-04-03 16:52 ---
(In reply to comment #6)
> I believe c-common.c:pointer_int_sum is wrong in relying on pointer overflow
> during conversion of the integer offset to an unsigned pointer. I'm sending
> a patch that fixes this for com
--- Comment #9 from rguenther at suse dot de 2006-04-03 16:59 ---
Subject: Re: [4.1 Regression] wrong final value
of induction variable calculated
On Mon, 3 Apr 2006, rakdver at gcc dot gnu dot org wrote:
> (In reply to comment #6)
> > I believe c-common.c:pointer_int_sum is wrong in
--- Comment #3 from boris dot breidenbach at physik dot uni-erlangen dot de
2006-04-03 17:00 ---
(In reply to comment #0)
Maybe I should say, that I am using an Opteron system. I ran the code on
an linux-operton box and it showed the same behaviour.
On gcc version 3.4.4 20050314 (prer
--- Comment #10 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-04-03 17:22 ---
Subject: Re: [4.1 Regression] wrong final value of induction variable
calculated
> > (In reply to comment #6)
> > > I believe c-common.c:pointer_int_sum is wrong in relying on pointer
> > >
--- Comment #4 from tromey at gcc dot gnu dot org 2006-04-03 17:28 ---
I happened to try this out this weekend.
I don't see an ICE in build_java_check_indexed_type
(with 4.0, 4.1 and head). Now I see:
+ gcj -c --classpath=jakarta-poi.jar joone-engine.jar -o joone-engine.o
org/joone/log
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-03 17:35 ---
Fixed in 4.0.0 at least so closing as 3.4.x is not being updated anymore.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-04-03 17:42 ---
Just a note here, we really always want to deal with a + CST and not worry
about if CST is negative or not, I had a patch to do but there was a testsuite
regression because of VRP, see PR 25148. In fact currently we
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26991
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-03 17:45 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-03 17:50 ---
From:
http://gcc.gnu.org/ml/gcc-testresults/2006-04/msg00107.html
FAIL: g++.dg/ext/visibility/anon1.C scan-hidden private_extern[
\\t_]*_?_ZN.*1fEv
So we have a testsuite failure also :).
--
http://gcc.gnu.org
--- Comment #4 from rittle at latour dot labs dot mot dot com 2006-04-03
17:57 ---
Subject: Re: FreeBSD 5 support for libjava
In article <[EMAIL PROTECTED]>,
"gerald at pfeifer dot com"<[EMAIL PROTECTED]> writes:
> --- Comment #3 from gerald at pfeifer dot com 2006-04-03 04:58 -
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-03 18:16 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
When compiling the following code with -O0 -maltivec:
typedef union
{
int i[4];
__attribute__((altivec(vector__))) int v;
} vec_int4;
int main (void)
{
vec_int4 i1;
i1.v = (__attribute__((altivec(vector__))) int){31, 31, 31, 31};
printf ("%d\n", i1.i[0]);
return 0;
}
the output
This function always returns 1, but gcc misses the optimization:
int foo(unsigned char x)
{
return (x+1) != 0;
}
fold-const.c converts the comparison to "x != -1", but that's it.
shorten_compare() in c-common.c would optimize it, but it doesn't get called.
fold-const.c has similar code on lin
gcc version 3.3, Apple build 1495, ppc-darwin.
command-line: gcc -O3 file.c
output: 1 2 0 0 5 6 0 0 9 10 0 0 13 14 0 0 17 18
command-line: gcc -O0 file.c
output: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Compile and run the following file with optimization < O2. The output is a list
of intege
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-03 18:59 ---
x+1 can wrap so try x be UINT_MAX.
In fact x != -1 is valid for unsigned as -1 is casted to unsigned and you get
UINT_MAX :).
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-03 19:02 ---
Report this bug to Apple since this is Apple's GCC that has been heavly
modified.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27008
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-03 19:10 ---
This worked in 4.0.2, by just loading the constant via memory so this is a
regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-03 19:17 ---
Confirmed, this is definitely wrong but we can do better than disabling this
for odd vectors I think. Adding 1 to them should work.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from joseph at codesourcery dot com 2006-04-03 19:22 ---
Subject: Re: Missed optimization of comparison with 'limited
range'
On Mon, 3 Apr 2006, pinskia at gcc dot gnu dot org wrote:
> x+1 can wrap so try x be UINT_MAX.
Wrong. The test uses *unsigned char*. In the n
--- Comment #3 from trt at acm dot org 2006-04-03 19:22 ---
Since x is unsigned char, default promotions apply and x+1 will be a signed
integer in the range 1..256
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27007
--- Comment #4 from dberlin at gcc dot gnu dot org 2006-04-03 19:44 ---
Subject: Re: Missed optimization of comparison with 'limited
range'
On Mon, 2006-04-03 at 19:22 +, trt at acm dot org wrote:
>
> --- Comment #3 from trt at acm dot org 2006-04-03 19:22 ---
> S
--- Comment #6 from pault at gcc dot gnu dot org 2006-04-03 19:44 ---
The patch fixes the problem by bolting the context to the floor and putting
concrete on it. The first gfc_evaluate_now prevents the error and the second
gets us a consistent result.
Should I detect that the first arg
--- Comment #5 from jsm28 at gcc dot gnu dot org 2006-04-03 19:51 ---
Bug should not have been closed, reopening.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from tromey at gcc dot gnu dot org 2006-04-03 19:54 ---
This patch is ok by me if someone wants to check it in.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23829
--- Comment #2 from dcorbit at connx dot com 2006-04-03 20:00 ---
Subject: RE: GCC 4.1.0 Won't build on Mingw. Complainst about no % in format
The attached makefile is from the gcc-4.1.0 directory.
> -Original Message-
> From: pinskia at gcc dot gnu dot org [mailto:[EMAIL PRO
This is with SUSE 10.1b9's gcc-fortran-4.1.0-10
~> gfortran -c fleur.F
fleur.F: In function MAIN__:
fleur.F:1: fatal error: gfc_todo: Not Implemented: Scalarization of
non-elemental intrinsic: __transfer1
compilation terminated.
Stripped-down test case:
-
PROGR
--
Summary: building profiledboor
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amonakov at gm
--
Summary: building profiledboort
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amonakov at g
--- Comment #7 from pault at gcc dot gnu dot org 2006-04-03 21:00 ---
PS Hmmm. I now cannot obtain the fault with an unpatched version, in spite of
provoking it today, repeatedly, on both FC3 and Cygwin Curiouser and
curiouser.
Cancel that thought - it is still there; it just doesn
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-03 21:01 ---
This was just fixed last week :).
*** This bug has been marked as a duplicate of 17298 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #22 from pinskia at gcc dot gnu dot org 2006-04-03 21:01
---
*** Bug 27009 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-03 21:02 ---
*** This bug has been marked as a duplicate of 27011 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-03 21:02 ---
*** Bug 27010 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27011
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-03 21:05 ---
So what is wrong?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-03 21:08 ---
I had meant the Makefile inside the gcc subdirectory :).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26959
--- Comment #7 from orion at cora dot nwra dot com 2006-04-03 21:13 ---
Looks like adding -save-temps to the flags breaks the configure check for
-fPIC, so the code be built with -save-temps that worked also did not have
-fPIC (perhaps that is a clue). Trick was to remove -pipe when usi
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-04-03 21:13 ---
>From looking at the debugger a little bit, the inlininer is not remapping the
CONST_DECL correctly. I might look at this more if I get some time.
--
pinskia at gcc dot gnu dot org changed:
What|
--- Comment #3 from amonakov at gmail dot com 2006-04-03 21:25 ---
(In reply to comment #2)
> So what is wrong?
>
Oh, sorry for the mess. Shame on me.
Building profiledbootstrap with checking enabled produces ICEing compiler (make
profiledbootstrap stops trying to compile crtsuff.c)
--- Comment #4 from hjl at lucon dot org 2006-04-03 21:54 ---
If -frandom-seed=0 is required for -fprofile-use to work correctly, why not
add it automatically for -fprofile-use?
--
hjl at lucon dot org changed:
What|Removed |Added
-
This program:
void foo(void)
{
int x __attribute__((visibility("hidden")));
}
makes no sense and should produce a compilation error.
--
Summary: visibility attribute should not be permitted on local
variables
Product: gcc
Version: 4.2.0
This program:
void foo(void)
{
int x __attribute__((visibility("hidden")));
}
makes no sense and should produce a compilation error.
--
Summary: visibility attribute should not be permitted on local
variables
Product: gcc
Version: 4.2.0
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-03 22:05 ---
This is all recorded under PR 22313.
*** This bug has been marked as a duplicate of 22313 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #33 from pinskia at gcc dot gnu dot org 2006-04-03 22:05
---
*** Bug 27011 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-03 22:05 ---
*** Bug 27013 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27012
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-03 22:05 ---
*** This bug has been marked as a duplicate of 27012 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
1 - 100 of 131 matches
Mail list logo
