--- Comment #4 from razya at il dot ibm dot com 2007-06-06 06:44 ---
(In reply to comment #1)
> I get the same failure on powerpc64-linux-gnu.
I committed the patch yesterday.
ok to close the PR?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32146
gcc: c-parse.c: No such file or directory
gcc: no input files
make[2]: *** [c-parse.o] Error 1
make[2]: Leaving directory `/opt/gcc-buil/gcc'
make[1]: *** [stage1_build] Error 2
make[1]: Leaving directory `/opt/gcc-buil/gcc'
make: *** [bootstrap] Error 2
--
Summary: gcc version 4 buil
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-06-06 05:33
---
*** Bug 32228 has been marked as a duplicate of this bug. ***
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-06-06 05:33
---
This is a duplicate. fixed in 4.2 and 4.3
*** This bug has been marked as a duplicate of 31395 ***
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #169 from ian at airs dot com 2007-06-06 05:33 ---
What options are you using when you compile?
I don't see the symbol you mention, although I do see
_ZNK10ScalarCodeIN4Adv51Z13MomentumfluxZILi3clI5FieldI22UniformRectilinearMeshI10MeshTraitsILi3Ed21UniformRectilinearTag
--- Comment #26 from pluto at agmk dot net 2007-06-06 04:49 ---
(In reply to comment #25)
> (In reply to comment #24)
> > any news?
>
> I have (or had, since I seem to have lost it) a patch that will prevent the
> invalid warning for the template case, but it will effectively prevent th
--- Comment #1 from scovich at gmail dot com 2007-06-06 03:39 ---
Happens on x86_64-unknown-linux-gnu as well, for both 4.2.0 and 4.3 (20070605)
The problem is even worse for 128-bit arithmetic because it has to check two
registers (with associated branches) before making a decision
--- Comment #3 from dorit at il dot ibm dot com 2007-06-06 03:28 ---
(In reply to comment #1)
veclower expands things when it wrongly concludes that they are not supported
by the target in vecor mode. For demotion/promotion/conversion kinda operations
this may be because it does not che
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-06-06 03:15
---
The following output from both gfortran and Intel are identical and correct:
$ gfc pr32228.f90
$ ./a.out
onetwo&
three
onetwo
$ ifort pr32228.f90
$ ./a.out
onetwo&
three
onetwo
Th
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-06-06 02:13
---
While I am at it I will check thi sout.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-06-06 01:59
---
The problem is here in resolve.c:
static int
generic_sym (gfc_symbol *sym)
{
gfc_symbol *s;
if (sym->attr.generic ||
(sym->attr.intrinsic && gfc_generic_intrinsic (sym->name)))
return 1;
if (was
write(*, 1005) 'one', 'two', 'three'
write(*, 1005) 'one', 'two'
1005 FORMAT(TR5 , A , A:'&' )
end
should not print the '&' for the second write statement.
--
Summary: Formatted output error with colon (:) descriptor
Product: gcc
Version: 4.2.0
Statu
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-06-06 01:34
---
Confirmed. I will investigate a little.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31609
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-06-06 01:29
---
I will attempt this one.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2007-06-06 01:26
---
Lets give this some time to test on other platforms and see. If it works, we
can port to 4.2 to get rid of the irritant factor.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32057
--- Comment #23 from jvdelisle at gcc dot gnu dot org 2007-06-06 01:23
---
Fixed on trunk. Closing
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from jvdelisle at gcc dot gnu dot org 2007-06-06 01:21
---
Subject: Bug 18923
Author: jvdelisle
Date: Wed Jun 6 01:21:29 2007
New Revision: 125353
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125353
Log:
2007-06-05 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #1 from danglin at gcc dot gnu dot org 2007-06-06 00:55 ---
This is fixed in the 4.3.0 manual and should appear in the online manual
when it is generated.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2007-06-06 00:54
---
Subject: Bug 32057
Author: jvdelisle
Date: Wed Jun 6 00:54:30 2007
New Revision: 125352
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125352
Log:
2007-06-05 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #4 from zackw at panix dot com 2007-06-06 00:41 ---
Subject: Re: Duplicate work, missed optimizations for registration of static
destructors
It's better, but build_cleanup is still being called twice in the
non-__cxa_atexit case, and I can't tell whether there is any
extrem
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-06 00:30 ---
I think this was fixed by:
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg2.html
At least the non array part.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17422
--- Comment #2 from dberlin at gcc dot gnu dot org 2007-06-05 23:49 ---
And the memory usage before that revision was what?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32199
--- Comment #1 from danglin at gcc dot gnu dot org 2007-06-05 23:43 ---
This was introduced in revision 125227.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
-
libtool: compile: /test/gnu/gcc/objdir/./gcc/xgcc -shared-libgcc
-B/test/gnu/gc
c/objdir/./gcc -nostdinc++
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc+
+-v3/src -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs
-B/
opt/gnu/gcc/gcc-4.3.0/hppa2.0w-hp-hpux11.11/bin/
-B/opt/
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last re
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-05 23:22 ---
This was just a stupid mistake on my part with respect of
follow_ssa_edge_in_rhs and what rhs meant here :). (Well this part actually
originally comes from Zdenek but anyways I have a fix which reverts most of
the
--- Comment #16 from fxcoudert at gcc dot gnu dot org 2007-06-05 22:58
---
Fixed on mainline, no evidence of a regression on 4.2.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #40 from dberlin at gcc dot gnu dot org 2007-06-05 22:44
---
Subject: Re: [4.2 regression] miscompilation of sigc++-2.0 based code with
-fstrict-aliasing
On 5 Jun 2007 19:59:32 -, rguenther at suse dot de
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #39 from rguent
--- Comment #25 from spark at gcc dot gnu dot org 2007-06-05 22:37 ---
(In reply to comment #24)
> any news?
I have (or had, since I seem to have lost it) a patch that will prevent the
invalid warning for the template case, but it will effectively prevent the
valid warning for other tem
--- Comment #51 from manu at gcc dot gnu dot org 2007-06-05 22:30 ---
Subject: Bug 25241
Author: manu
Date: Tue Jun 5 22:30:24 2007
New Revision: 125347
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125347
Log:
2007-06-05 Manuel Lopez-Ibanez <[EMAIL PROTECTED]>
PR t
--- Comment #28 from manu at gcc dot gnu dot org 2007-06-05 22:25 ---
Subject: Bug 23479
Author: manu
Date: Tue Jun 5 22:25:27 2007
New Revision: 125346
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125346
Log:
2007-06-05 Joerg Wunsch <[EMAIL PROTECTED]>
PR preproce
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-05 22:01 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
Hi,
I found this missed optimization when looking into an ICE on the pointer_plus
branch.
For this code:
quantize_fs_dither (unsigned width, short *errorptr, int dir)
{
short bpreverr;
unsigned col;
for (col = width; col > 0; col--)
errorptr += dir;
errorptr[0] = (short) bpreverr;
}
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-05 21:36 ---
I forgot to mention this is on the pointer_plus branch, I will take a look at
it later.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
quantize_fs_dither (unsigned width, short *errorptr, int dir)
{
short bpreverr;
unsigned col;
for (col = width; col > 0; col--)
errorptr += dir;
errorptr[0] = (short) bpreverr;
}
SCCP goes funny for this (have not looked why yet).
--
Summary: ICE in alias.c with INDIRECT
--- Comment #168 from rguenther at suse dot de 2007-06-05 21:17 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
On Tue, 5 Jun 2007, ian at airs dot com wrote:
> --- Comment #167 from ian at airs dot com 2007-06-05 20:48 -
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-05 21:08 ---
> D.2098_70 = VIEW_CONVERT_EXPR({D.2094_66, D.2097_69});
is the problem. Now the question comes what types are D.2094_66?
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from ubizjak at gmail dot com 2007-06-05 21:04 ---
In _.101t.vect, we have:
vect_var_.36_43 = VEC_UNPACK_FLOAT_LO_EXPR < vect_vec_iv_.40_41 > ;
vect_var_.36_44 = VEC_UNPACK_FLOAT_HI_EXPR < vect_vec_iv_.40_41 > ;
D.2004_4 = (double) x_13;
vect_var_.41_46 = vect_c
--- Comment #167 from ian at airs dot com 2007-06-05 20:48 ---
Can you give me a .ii file for the performance regression, and point me at the
relevant function?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-05 20:39 ---
This patch is incorrect and just wrong, the C++ front-end should be catching
this before calling size_binop. Also the code is invalid so we should have an
error.
This patch also allows us to get around the ICE (but
--- Comment #2 from ubizjak at gmail dot com 2007-06-05 20:34 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL|
--- Comment #1 from uros at gcc dot gnu dot org 2007-06-05 20:24 ---
Subject: Bug 32215
Author: uros
Date: Tue Jun 5 20:23:58 2007
New Revision: 125343
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125343
Log:
PR tree-optimization/32215
* tree-vectorizer.c (sup
--- Comment #21 from jvdelisle at gcc dot gnu dot org 2007-06-05 20:23
---
Subject: Bug 18923
Author: jvdelisle
Date: Tue Jun 5 20:23:44 2007
New Revision: 125342
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125342
Log:
2007-06-05 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #3 from brolley at redhat dot com 2007-06-05 20:11 ---
Typo (sorry!)
"4.2 and 4.3" above should be "4.1 and 4.2"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31743
--- Comment #2 from brolley at redhat dot com 2007-06-05 20:09 ---
The macro invocation "TYPE_MODE (type)" causes the ICE when tree checking is
enabled because TREE_CODE_CLASS (type) is ERROR_MARK. Checking for this before
checking the tree and returning NULL_TREE allows the compiler to
--- Comment #39 from rguenther at suse dot de 2007-06-05 19:59 ---
Subject: Re: [4.2 regression] miscompilation of sigc++-2.0
based code with -fstrict-aliasing
On Tue, 5 Jun 2007, dberlin at dberlin dot org wrote:
> --- Comment #38 from dberlin at gcc dot gnu dot org 2007-06-05
--- Comment #1 from brolley at redhat dot com 2007-06-05 19:57 ---
Created an attachment (id=13659)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13659&action=view)
Proposed patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31743
--- Comment #38 from dberlin at gcc dot gnu dot org 2007-06-05 19:07
---
Subject: Re: [4.2 regression] miscompilation of sigc++-2.0 based code with
-fstrict-aliasing
On 5 Jun 2007 18:24:54 -, matz at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #37 from mat
--- Comment #4 from rob1weld at aol dot com 2007-06-05 18:54 ---
>> [EMAIL PROTECTED]
>> open_errors.f90 is testing for some OS dependent text in error messages. ...
>> I would very much appreciate if you could post the output from that program.
I'd be glad to help but I am not at that
--- Comment #37 from matz at gcc dot gnu dot org 2007-06-05 18:24 ---
> We are pointing to cell, and using that to access cell.i
No. We are pointing to cell.ii, and use that pointer to access cell.ii.i
(via in->i). Hence of course the points-to set of 'in' needs to include
cell.in.i (
--- Comment #36 from dberlin at gcc dot gnu dot org 2007-06-05 17:45
---
Subject: Re: [4.2 regression] miscompilation of sigc++-2.0 based code with
-fstrict-aliasing
On 5 Jun 2007 16:30:32 -, rguenther at suse dot de
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #35 from rguent
--- Comment #11 from tbm at cyrius dot com 2007-06-05 17:43 ---
Created an attachment (id=13658)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13658&action=view)
testcase
Here's another testcase. This one needs -O3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31037
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-05 17:40 ---
Fails in gfc_trans_assignment_1 with:
gcc_assert (lse.ss == gfc_ss_terminator
&& rse.ss == gfc_ss_terminator);
Works with: 2007-06-04-r125305
Fails with: 2007-06-05-r125327
The only Fortran p
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-06-05 17:38 ---
Some more information:
"Change the interpretation of backslashes in string literals from
“C-style” escape characters to a single backslash character. "
$> cat char.f90
character(len=1) :: c
DATA c / '\0' /
print *,
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC host trip
--- Comment #22 from rob1weld at aol dot com 2007-06-05 17:28 ---
I'm leaving the currect status of "RESOLVED FIXED" and I've changed this from
blocker to normal since for the past few days gcc does not break during the
make of libjava.
It would be good to use the same version of libtoo
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-05 17:27 ---
The error message is ok as you have the string "\" + "0", which does not fit
into a character(len=1) variable. bzero(4) contains "\", which is consistent
with several compilers.
-fbackslash implies that C-style contr
--- Comment #24 from pluto at agmk dot net 2007-06-05 17:26 ---
(In reply to comment #23)
> Confirmed. I'm working on a fix.
> This is due to template instantiations marked as anonymous.
any news?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365
--- Comment #11 from rob1weld at aol dot com 2007-06-05 17:22 ---
>> [EMAIL PROTECTED]
>> IEEE 754 does not discuss any of the functions you list above.
>> Comment #4 From Rob
>> That page is a report of the libc6 tests that are ran when the code is built
>> [EMAIL PROTECTED]
>> Compa
--- Comment #2 from richard-gccbugzilla at metafoo dot co dot uk
2007-06-05 17:21 ---
Points worthy of note:
1) The OP's code is legal (to my reading of the standard) but meaningless.
Private members in unnamed classes are legal, while private members in
anonymous unions are not. So te
I'm seeing the following ICE with current trunk. This was introduced at
some point between 20070131 (works) and 20070303 (ICE). This is on x86_64.
(sid)25015:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O
-ftree-vectorize
gmp-export.c
gmp-export.c: In function 'gmpz_export':
gmp-expo
--- Comment #6 from dcb314 at hotmail dot com 2007-06-05 16:51 ---
(In reply to comment #5)
> (In reply to comment #0)
> > Preprocessed source code attached. Flags -ftree-vectorize -Os -mno-sse
> > required.
> I don't see this with gcc 4.3 20070604. Do you still get this failure?
Hard
--- Comment #29 from hjl at lucon dot org 2007-06-05 16:45 ---
Here are SPEC CPU 2006 -O2 -ffast-math differences between revision
125281 without the second reassoc and revision 125281 on Intel64:
(r125281 w/o reassoc2 - r125281)/r125281
400.perlbench
--- Comment #35 from rguenther at suse dot de 2007-06-05 16:30 ---
Subject: Re: [4.2 regression] miscompilation of sigc++-2.0
based code with -fstrict-aliasing
On Tue, 5 Jun 2007, dberlin at dberlin dot org wrote:
> Subject: Re: [4.2 regression] miscompilation of sigc++-2.0 based co
This compiled with out a warning on older versions of gfortran. It does not
seem to like the '\0', but it says something else -
[dranta:~/tests/gfortran-D] dir% gfortran -c linlab.f
linlab.f:3.33:
data bzero /'0', '.', '0', '\0','0'/
--- Comment #166 from rguenth at gcc dot gnu dot org 2007-06-05 16:20
---
It causes a 10% performance regression for tramp3d. There appear to be no
significant changes in libstdc++ performance testing. "Fixing" tramp3d-v4
with the below patch cures the performance regression.
--- tra
--- Comment #34 from dberlin at gcc dot gnu dot org 2007-06-05 16:20
---
Subject: Re: [4.2 regression] miscompilation of sigc++-2.0 based code with
-fstrict-aliasing
On 5 Jun 2007 09:27:34 -, rguenth at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #30 from
ead model: posix
gcc version 4.3.0 20070605 (experimental)
/afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.3.0/cc1 -E
-lang-fortran -traditional-cpp -D_LANGUAGE_FORTRAN -quiet -v test.F90
-mtune=generic -o /tmp/ccdbfKTt.f95
ignoring nonexistent directory
"/afs/mpa/data/martin/ugcc/lib/
--- Comment #33 from rguenth at gcc dot gnu dot org 2007-06-05 15:57
---
Actually,
+ if (minoffset != 0)
must be changed to
+ if (minoffset != 0 && count != 0)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30252
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-05 15:54 ---
..(In reply to comment #3)
> We would like to propose a target of 3.4 if possible.
Anything before 4.1.x is no longer maintained. Also I don't remember the rules
for oversized bit-fields to confirm this is a bug or
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-06-05 15:53 ---
Note there were some changes to bitfield packing in 4.1.0 -- see PR22275.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32210
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-06-05 15:52 ---
I mean, what architecture are you testing on? Btw, all GCC older than 4.1.2
are
out of maintainance and will not be fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32210
--- Comment #3 from cjain at ca dot ibm dot com 2007-06-05 15:46 ---
We would like to propose a target of 3.4 if possible.
--
cjain at ca dot ibm dot com changed:
What|Removed |Added
-
--- Comment #2 from cjain at ca dot ibm dot com 2007-06-05 15:17 ---
(In reply to comment #1)
> for what target?
I tried the testcase on a SLES10 machine. Here is the output on sles9 with g++
3.3.3:
Here
Printing an object on 4 bytes
Byte 0 is 0
Byte 1 is 1
Byte 2 is 0
Byte 3 is 1
Finis
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-05 15:03 ---
for what target?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC
--- Comment #32 from rguenth at gcc dot gnu dot org 2007-06-05 15:01
---
Created an attachment (id=13657)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13657&action=view)
patch
Patch in testing. It makes sure to create fields for all addressable
components
(such as empty bases)
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-05 14:54 ---
*** Bug 32221 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32220
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-05 14:54 ---
*** This bug has been marked as a duplicate of 32220 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
While rebuilding one of my programs with the new version of gfortran, I hit
this error (This worked on an older version of gfortran)-
[dranta:~/tests] dir% gfortran -O3 -std=legacy -c ad78b.f
ad78b.f: In function 'derv':
ad78b.f:1: internal compiler error: in eliminate_temp_copies, at
tree-predcom
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
While rebuilding one of my programs with the new version of gfortran, I hit
this error (This worked on an older version of gfortran)-
[dranta:~/tests] dir% gfortran -O3 -std=legacy -c ad78b.f
ad78b.f: In function 'derv':
ad78b.f:1: internal compiler error: in eliminate_temp_copies, at
tree-predcom
--- Comment #4 from pluto at agmk dot net 2007-06-05 14:13 ---
(In reply to comment #2)
> f always will bind local ...
so, should gcc reject weak attribute in this (hidden visibility) case?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32219
--- Comment #3 from pluto at agmk dot net 2007-06-05 14:10 ---
(In reply to comment #2)
> Also you should be using -PIE when linking.
hmm, it doesn't work with int main();
$ gcc -s main.c -fpie -Wl,-pie
/usr/bin/ld: /usr/lib64/crt1.o: relocation R_X86_64_32S against
`__libc_csu_fini'
--- Comment #9 from malitzke at metronets dot com 2007-06-05 13:44 ---
Mr. Tobler
Thanks for pursuing this. For me. as a user, it is solved. My analysis, as an
outsider, points to the corruption, inadvertent chang, update malfunction of an
include file shared by the *.c files leading to
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-05 13:30 ---
f always will bind local ...
Also you should be using -PIE when linking.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32219
--- Comment #1 from pluto at agmk dot net 2007-06-05 12:53 ---
btw, imho the weak+hidden is not a valid combination.
such symbol can't be resolved in runtime because it doesn't exist
in elf rel.plt/rel.dyn tables. it can be resolved only during
linking several objects into one piece (e.g
--- Comment #31 from rguenth at gcc dot gnu dot org 2007-06-05 12:05
---
The problem in this PR is, that the structure we mess up points-to info has no
fields in its lower half, but only two varinfos (D.2860, offset 128 size 64
and D.2860.visited_, offset 192 size 64 -- the first one is
--- Comment #8 from andreast at gcc dot gnu dot org 2007-06-05 10:46
---
This is the commit causing this failure:
http://gcc.gnu.org/ml/gcc-cvs/2007-06/msg00052.html
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
-
Hello,
> >>>(parallel [
> >>> (set (pc)
> >>> (if_then_else (lt:SI (reg:SI 45)<---
> >>>(reg:SI 26))
> >>> (label_ref:HI 129)
> >>> (pc)))
> >>>
Hi Zdenek,
(parallel [
(set (pc)
(if_then_else (lt:SI (reg:SI 45)<---
(reg:SI 26))
(label_ref:HI 129)
(pc)))
(clobber (reg:SI 45))
following testcase causes gpf on i386.
$ cat exe.c
extern void f() __attribute__((weak,visibility("hidden")));
extern int puts( char const* );
int main()
{
f ? f() : puts( "f == null, skipped." );
return 0;
}
$ gcc exe.c -fPIE --save-temps -m32 -O1 && ./a.out
Segmentation fault
t
Hello,
> > I think that I have found a small bug in the loop invariant code.
> > The problem is exhibited when building newlib for the xstormy16-elf
> > toolchain although it may happen with other targets as well. The
> > problem occurs when an insn contains an r-value use of a register
>
--- Comment #30 from rguenth at gcc dot gnu dot org 2007-06-05 09:27
---
See this testcase (reduced from spec2k6 dealII by Micha):
struct I {
int ix;
struct II {
int j,i;
void *ptr;
} ii;
};// inner;
struct O : public I {
// int x;
int y;
};
static int g
> > I think that I have found a small bug in the loop invariant code.
> > The problem is exhibited when building newlib for the xstormy16-elf
> > toolchain although it may happen with other targets as well. The
> > problem occurs when an insn contains an r-value use of a register
> > that is
Hello,
> I think that I have found a small bug in the loop invariant code.
> The problem is exhibited when building newlib for the xstormy16-elf
> toolchain although it may happen with other targets as well. The
> problem occurs when an insn contains an r-value use of a register
> that
Hi Zdenek, Hi Daniel, Hi Geoff,
I think that I have found a small bug in the loop invariant code.
The problem is exhibited when building newlib for the xstormy16-elf
toolchain although it may happen with other targets as well. The
problem occurs when an insn contains an r-value use of a r
I'm getting the following segfault on IA-64 with current 4.2 and 4.3.
This goes back at least to 20060721 - I don't have anything older to
test here at the moment. I don't see this segfault on x86_64.
Unfortunately I don't have a working gdb on ia-64 at the moment so
I cannot supply a backtrace.
The following valid program ends up in a segfault at the UNPACK function call
with gfortran 4.3.0 20070605 (experimental binaries from gcc site):
program bug_report
implicit none
integer,parameter:: rp = kind(1.d0),na = 6
real(rp),allocatable:: hhe(:,:,:),hhc(:,:,:),dv(:)
integer:: nhh,ndv
nhh = 0
100 matches
Mail list logo
