Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34835
--- Comment #13 from hjl at lucon dot org 2008-01-16 20:17 ---
(In reply to comment #12)
> Created an attachment (id=14949)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14949&action=view) [edit]
> Patch to fix issue in Comment #8
>
> H.J, could you test if a
--- Comment #11 from hjl at lucon dot org 2008-01-16 18:23 ---
(In reply to comment #9)
>
> GNU ld version 2.17.50.0.3-6 20060715
>
Your linker doesn't issue the error since it is too old. See
http://sourceware.org/bugzilla/show_bug.cgi?id=4454
--
hjl at lucon d
--- Comment #8 from hjl at lucon dot org 2008-01-16 16:16 ---
It isn't fixed. The error went from as to ld:
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/
/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/tree-prof/bb-re
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #3 from hjl at lucon dot org 2008-01-13 16:31 ---
This bug may only happen when you compile for 32bit on 64bit host.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34769
--- Comment #2 from hjl at lucon dot org 2008-01-13 16:26 ---
Revision 131429 is the cause.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34769
--- Comment #1 from hjl at lucon dot org 2008-01-13 16:25 ---
Revision 131429:
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00367.html
--
hjl at lucon dot org changed:
What|Removed |Added
D
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34769
--- Comment #4 from hjl at lucon dot org 2008-01-08 18:24 ---
(In reply to comment #2)
> BTW: What happens if -mrecip is used to compile 481.wrf?
>
"-O2 -mrecip -ffast-math" miscompiles 481.wrf on Linux/Intel64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34709
--- Comment #3 from hjl at lucon dot org 2008-01-08 18:01 ---
(In reply to comment #2)
> (In reply to comment #1)
> > No idea if Uros has access to spec, so maybe you can quote the snippet where
> > rsqrtss is used from the assembly of 481.wrf?
>
> Unfortunatelly
--- Comment #11 from hjl at lucon dot org 2008-01-08 13:56 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00294.html
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #9 from hjl at lucon dot org 2008-01-07 22:57 ---
We are processing common block symbols which we have rejected/freed before.
This patch works for me:
Index: symbol.c
===
--- symbol.c(revision 131352
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
GCC target triplet: x86_64-linux
http
--- Comment #7 from hjl at lucon dot org 2008-01-07 04:57 ---
gfc_undo_symbols has
for (p = changed_syms; p; p = q)
{
q = p->tlink;
if (p->new)
{
/* Symbol was new. */
delete_symtree (&p->ns->sym_root, p->name);
--- Comment #3 from hjl at lucon dot org 2008-01-06 21:54 ---
Why didn't I see it with revision 131352?
--
hjl at lucon dot org changed:
What|Removed |
--- Comment #1 from hjl at lucon dot org 2008-01-06 21:47 ---
It may be introduced by the fix for bug 34658.
--
hjl at lucon dot org changed:
What|Removed |Added
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34693
oduct: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34690
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34689
--
hjl at lucon dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34612
--- Comment #8 from hjl at lucon dot org 2007-12-30 15:49 ---
Created an attachment (id=14844)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14844&action=view)
Dump files without -fipa-struct-reorg
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34534
--- Comment #7 from hjl at lucon dot org 2007-12-30 15:45 ---
(In reply to comment #4)
>
> So I wonder whether this test works correctly even without -fipa-struct-reorg.
> Would you please try to compile it with all other options (-O3 -fdump-ipa-all
> -fwhole-program -c
--- Comment #16 from hjl at lucon dot org 2007-12-29 16:20 ---
I think this is related to PR 34472 and PR 34534
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #1 from hjl at lucon dot org 2007-12-29 15:03 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2007-12/msg01161.html
--
hjl at lucon dot org changed:
What|Removed |Added
nedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34612
--- Comment #8 from hjl at lucon dot org 2007-12-28 01:23 ---
I believe revision 125030:
http://gcc.gnu.org/ml/gcc-cvs/2007-05/msg00730.html
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01061.html
is the cause.
--
hjl at lucon dot org changed:
What|Removed
--- Comment #5 from hjl at lucon dot org 2007-12-27 16:56 ---
Any update on this?
--
hjl at lucon dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from hjl at lucon dot org 2007-12-21 00:25 ---
I configured gcc with
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
\
--enable-shared \
--enable-threads=posix \
--enable-haifa
--- Comment #2 from hjl at lucon dot org 2007-12-20 17:45 ---
Created an attachment (id=14802)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14802&action=view)
Dump files
Starting program:
/export/build/gnu/gcc/build-ia64-linux/gcc/testsuite/gcc/a.out
Program received
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34539
ReportedBy: hjl at lucon dot org
GCC target triplet: ia64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34534
--- Comment #5 from hjl at lucon dot org 2007-12-20 00:15 ---
(In reply to comment #4)
> Thank you for debugging! Now I see approximately where it fails. Although I am
> not sure that the following patch solves the issue, please try it, and let me
> know whether it helps.
>
--- Comment #3 from hjl at lucon dot org 2007-12-18 03:09 ---
A proposal is posted at
http://gcc.gnu.org/ml/gcc/2007-12/msg00503.html
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #3 from hjl at lucon dot org 2007-12-17 19:08 ---
Valgrind reports:
==20091== Invalid read of size 8
==20091==at 0x964769: htab_traverse_noresize (hashtab.c:749)
==20091==by 0x747B6B: reorg_structs_drive (ipa-struct-reorg.c:3547)
==20091==by 0x584BF1
--- Comment #2 from hjl at lucon dot org 2007-12-17 19:04 ---
Created an attachment (id=14786)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14786&action=view)
Dump files.
Here are dump files. I think there may be some memory corruptions:
GGC heuristics: --param ggc-min
--- Comment #16 from hjl at lucon dot org 2007-12-17 07:01 ---
(In reply to comment #13)
>
>
> Now that we have ext/hash_map and ext/hash_set back (yes, SPEC2000
> eon still is broken, as it uses the removed iostream.h and other *.h
FWIW, I have 252.eon.gcc43.src.alt.ta
--- Comment #4 from hjl at lucon dot org 2007-12-15 22:05 ---
Where is __GCC_FLOAT_NOT_NEEDED documented? Is this a supported gcc macro?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34484
riority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34472
--- Comment #31 from hjl at lucon dot org 2007-12-14 04:23 ---
(In reply to comment #30)
> (In reply to comment #29)
>
> >
> > I am running SPEC CPU 2000/2006 now. I will report results when they are
> > finished.
> >
>
> They are finished. No re
--- Comment #30 from hjl at lucon dot org 2007-12-14 04:15 ---
(In reply to comment #29)
>
> I am running SPEC CPU 2000/2006 now. I will report results when they are
> finished.
>
They are finished. No regressions. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34427
--- Comment #29 from hjl at lucon dot org 2007-12-13 17:16 ---
(In reply to comment #28)
> Could someone confirm that gfortran (with no reverted patches) now works again
> with 481.wrf or with SPEC in general?
>
I am running SPEC CPU 2000/2006 now. I will report results when
--- Comment #24 from hjl at lucon dot org 2007-12-12 15:26 ---
(In reply to comment #23)
> > Tobias. do as you
> > please. We can either revert the original patch and get back to this
> > without
> > time pressure or proceed quickly.
> Maybe reverting and
--- Comment #21 from hjl at lucon dot org 2007-12-12 01:56 ---
(In reply to comment #18)
> Created an attachment (id=14736)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14736&action=view) [edit]
> Draft Patch
>
> Test patch. It seems to fix the REAL reading
--- Comment #7 from hjl at lucon dot org 2007-12-11 23:00 ---
This one is for "moved" header files. One can include different header files
for gcc 4.3. PR 33831 is for "removed" header files. I don't know if gcc
4.3 provides the identical functionality as the ol
--- Comment #15 from hjl at lucon dot org 2007-12-11 22:37 ---
We can change the last_char field to
#define MAX_LAST_STRING_LEN 8
char last_string[MAX_LAST_STRING_LEN];
int last_char_pos;
we can unget up to MAX_LAST_STRING_LEN chars.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #14 from hjl at lucon dot org 2007-12-11 22:31 ---
The current Inf/NAN I/O support is broken. Given a namelist input
&nl
foo = 5,
infinity1 = 1,
/
where foo is an array of 2 reals, we need to unget up to 8 chars (infinity).
If it can't be done with the curren
--- Comment #13 from hjl at lucon dot org 2007-12-11 21:06 ---
Also are inf/infinity/infbar/infinityfoo/nan/nanfoo valid variables?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34427
--- Comment #12 from hjl at lucon dot org 2007-12-11 20:58 ---
Revision 130708 is wrong. We can't do
if ((c == 'i' || c == 'I')
&& ((c = next_char (dtp)) == 'n' || c == 'N')
&& ((c = next_char (dtp)) == 'f&
--- Comment #11 from hjl at lucon dot org 2007-12-11 20:16 ---
[EMAIL PROTECTED] 34427]$ cat foo.f90
IMPLICIT NONE
real , DIMENSION(11) ::foo
integer :: isfflx
NAMELIST /nl/ foo
NAMELIST /nl/ isfflx
open (10, status="scratch")
write (10,*) " &nl"
--- Comment #9 from hjl at lucon dot org 2007-12-11 14:56 ---
Revision 130726 is OK after I reverted libgfortran to revision 130629.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34427
--- Comment #8 from hjl at lucon dot org 2007-12-11 14:18 ---
Revision 130726 failed after I backed out revisions 130629 and 130712.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34427
--- Comment #7 from hjl at lucon dot org 2007-12-11 14:03 ---
Revision 130707 is OK if I back out revision 130629.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34427
--- Comment #6 from hjl at lucon dot org 2007-12-11 13:46 ---
I saw it with revision 130726.
--
hjl at lucon dot org changed:
What|Removed |Added
Status
--- Comment #2 from hjl at lucon dot org 2007-12-10 23:49 ---
This regression was introduced between revision 130629 and 130712.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34427
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34427
everity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34413
--- Comment #2 from hjl at lucon dot org 2007-12-09 12:15 ---
The input data file has
(2.4E-1, 0.0E+0)
It is read by
COMPLEX*16 X
...
READ(10,*) X
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #1 from hjl at lucon dot org 2007-12-09 12:14 ---
Revision 130708
http://gcc.gnu.org/viewcvs/trunk/libgfortran/io/list_read.c?r1=130708&r2=130707&pathrev=130708
has
@@ -1136,6 +1141,13 @@
exp2:
if (!isdigit (c))
+{
+ if (c == 'i' || c
4.3 Regression] 168.wupwise in SPEC CPU 2000
miscompiled
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
Repo
gnedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34377
nu dot org
ReportedBy: hjl at lucon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34376
--- Comment #12 from hjl at lucon dot org 2007-11-30 08:56 ---
gcc.dg/tree-ssa/pr34244.c in
http://gcc.gnu.org/viewcvs?view=rev&revision=130527
has duplicated content.
--
hjl at lucon dot org changed:
What|Removed |A
--- Comment #9 from hjl at lucon dot org 2007-11-28 01:25 ---
Fixed in gcc 4.3.
--
hjl at lucon dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from hjl at lucon dot org 2007-11-27 13:20 ---
Revision 130371:
http://gcc.gnu.org/ml/gcc-cvs/2007-11/msg00566.html
is the cause.
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #1 from hjl at lucon dot org 2007-11-27 12:49 ---
This testcase doesn't work on Linux/x86-64.
--
hjl at lucon dot org changed:
What|Removed |
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34249
le, at
gimplify.c:4677
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
rtran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
BugsThisDependsOn: 34079
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34246
--- Comment #7 from hjl at lucon dot org 2007-11-27 02:36 ---
(In reply to comment #6)
> We have changed fastcall behavior from gcc 3.4 to 4.1. For
>
> ---
> #define FASTCALL __attribute((fastcall))
>
> double FASTCALL f_dii( double p1d, int p2i, int p3i ){ return
--- Comment #6 from hjl at lucon dot org 2007-11-26 23:19 ---
We have changed fastcall behavior from gcc 3.4 to 4.1. For
---
#define FASTCALL __attribute((fastcall))
double FASTCALL f_dii( double p1d, int p2i, int p3i ){ return p1d +
(double)p2
i + (double)p3i; }
inttest_x
--- Comment #1 from hjl at lucon dot org 2007-11-18 20:48 ---
Revision 130005 is
http://gcc.gnu.org/ml/gcc-cvs/2007-11/msg00197.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34144
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34144
--- Comment #5 from hjl at lucon dot org 2007-11-16 04:52 ---
The correct patch is at
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00885.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34001
--- Comment #4 from hjl at lucon dot org 2007-11-12 03:27 ---
>From "info gcc",
`fastcall'
On the Intel 386, the `fastcall' attribute causes the compiler to
pass the first argument (if of integral ty
--- Comment #13 from hjl at lucon dot org 2007-11-10 19:42 ---
Created an attachment (id=14526)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14526&action=view)
A patch
This patch seems to work.
--
hjl at lucon dot org changed:
What|
--- Comment #12 from hjl at lucon dot org 2007-11-10 19:17 ---
(In reply to comment #7)
> Created an attachment (id=14525)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14525&action=view) [edit]
> patch for 450.soplex
>
This patch is incomplete. I got
unitvect
--- Comment #11 from hjl at lucon dot org 2007-11-10 18:41 ---
(In reply to comment #10)
> Subject: Re: [4.3 Regression]: Revision 130040
> miscompiles 450.soplex
>
> On Sat, 10 Nov 2007, bonzini at gnu dot org wrote:
>
> > --- Comment #9 from bonzini at gn
ssigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
GCC target triplet: x86_64-unknown-linux-gnu
OtherBugsDependingO 33604
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34048
--- Comment #3 from hjl at lucon dot org 2007-11-09 17:34 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00531.html
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #2 from hjl at lucon dot org 2007-11-09 16:55 ---
From
http://msdn2.microsoft.com/en-us/library/6xa169sk(VS.80).aspx
"The first two DWORD or smaller arguments are passed in ECX and EDX registers;
all other arguments are passed right to left."
But it isn
--- Comment #1 from hjl at lucon dot org 2007-11-08 17:12 ---
I verified that it isn't fixed in gcc 4.3.0.
--
hjl at lucon dot org changed:
What|Removed |
--- Comment #34 from hjl at lucon dot org 2007-11-06 17:30 ---
An updated patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00273.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30961
--- Comment #43 from hjl at lucon dot org 2007-11-05 19:25 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00214.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
--- Comment #42 from hjl at lucon dot org 2007-11-05 14:18 ---
(In reply to comment #39)
> Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in
> discarded section
>
>
> On 04/11/2007, at 7:01 PM, hjl at lucon dot org wrote:
>
> >> -
--- Comment #38 from hjl at lucon dot org 2007-11-05 03:03 ---
(In reply to comment #37)
> (In reply to comment #35)
> >
> >
> > - What if the global variable references two or more strings?
>
> All local strings referenced by the global variable should be
--- Comment #37 from hjl at lucon dot org 2007-11-05 03:01 ---
(In reply to comment #35)
>
>
> - What if the global variable references two or more strings?
All local strings referenced by the global variable should be
in the same comdat group.
> - Won't this
--- Comment #36 from hjl at lucon dot org 2007-11-05 02:50 ---
The rules for the comdat group are
1. There should be no outside references to local symbols inside of the comdat
group.
2. All comdat groups with the same signature should have the identical set of
defined global symbols
--- Comment #34 from hjl at lucon dot org 2007-11-05 00:32 ---
(In reply to comment #33)
> (In reply to comment #32)
> >
> > What if you want to reference this string from somewhere that should
> > never be discarded, like a global variable?
> >
>
>
--- Comment #33 from hjl at lucon dot org 2007-11-05 00:22 ---
(In reply to comment #32)
>
> What if you want to reference this string from somewhere that should
> never be discarded, like a global variable?
>
Since the string is local, that global variable is defined
--- Comment #31 from hjl at lucon dot org 2007-11-04 14:40 ---
(In reply to comment #30)
> Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in
> discarded section
>
> On 03/11/2007, at 7:21 AM, hjl at lucon dot org wrote:
>
> > Local s
--- Comment #29 from hjl at lucon dot org 2007-11-03 14:21 ---
(In reply to comment #27)
>
> In this case, though, the contents of the linkonce section will never
> actually differ; and I believe in this case the offset is zero, so
> even if they did differ it woul
caused 1% slowdown on 200.sixtrack
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
GCC
--- Comment #25 from hjl at lucon dot org 2007-10-30 19:37 ---
Basically, you can't have a non-comdat section references a local symbol
in a comdat section.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
--- Comment #24 from hjl at lucon dot org 2007-10-30 19:36 ---
(In reply to comment #23)
> Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in
> discarded section
>
> On 30/10/2007, at 12:12 PM, hjl at lucon dot org wrote:
>
> > The pro
--- Comment #22 from hjl at lucon dot org 2007-10-30 19:12 ---
The problem is "typeinfo for (anonymous namespace)::t" in .rodata section
references "typeinfo name for (anonymous namespace)::t" in a comdat section.
When the comdat section is discarded, we got a
--- Comment #4 from hjl at lucon dot org 2007-10-28 16:48 ---
Fixed.
--
hjl at lucon dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from hjl at lucon dot org 2007-10-27 23:16 ---
If you run autoconf in libgcc, you will see the failure. See
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01652.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33926
: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33926
--- Comment #4 from hjl at lucon dot org 2007-10-23 14:24 ---
Revision 127629
http://gcc.gnu.org/ml/gcc-cvs/2007-08/msg00523.html
introduced this regression.
--
hjl at lucon dot org changed:
What|Removed |Added
1 - 100 of 1141 matches
Mail list logo
