: 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
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 #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-reorg.c
--- 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 dot org changed
--- 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=14949action=view) [edit]
Patch to fix issue in Comment #8
H.J, could you test if attached patch fixes
: 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 #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
--- 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 #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 #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 #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 no... does this patch help
--- 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
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 #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
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
: 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
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
--- 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
--- 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 |Added
--- 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);
p-refs
--
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 #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 -combine -fipa-type
--- 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=14844action=view)
Dump files without -fipa-struct-reorg
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34534
--- 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
--- 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
: 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 #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 #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
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
--- 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=14802action=view)
Dump files
Starting program:
/export/build/gnu/gcc/build-ia64-linux/gcc/testsuite/gcc/a.out
Program received signal
--- 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 #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.
Thank you
ReportedBy: hjl at lucon dot org
GCC target triplet: ia64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34534
--- 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=14786action=view)
Dump files.
Here are dump files. I think there may be some memory corruptions:
GGC heuristics: --param ggc-min-expand=100
--- 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 #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 #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.tar.bz2, which works
--- 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
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 #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 #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 #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 regressions. Thanks.
SPEC CPU 2000/2006
--- 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 #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 #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 #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 #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
write (10,*) foo = 5, 5, 5
--- 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' || c == 'F'))
{
...
if (nml_bad_return (dtp, c))
return 0
--- 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 #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 #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 old one. One may needs more
--- 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=14736action=view) [edit]
Draft Patch
Test patch. It seems to fix the REAL reading part. I run out of time
: 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
--- 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
.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
ReportedBy: hjl at lucon
--- 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=130708r2=130707pathrev=130708
has
@@ -1136,6 +1141,13 @@
exp2:
if (!isdigit (c))
+{
+ if (c == 'i' || c == 'I' || c == 'n' || c
--- 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
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
ReportedBy: hjl at lucon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34376
at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34377
--- 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=revrevision=130527
has duplicated content.
--
hjl at lucon dot org changed:
What|Removed |Added
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
, 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
http
: 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
--- 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 |Added
--- 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 #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 #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 #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 p1d +
(double)p2
i
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 #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
--- 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 type) in the register ECX
--- 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 gnu dot org 2007-11-10 18:10
--- 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=14525action=view) [edit]
patch for 450.soplex
This patch is incomplete. I got
unitvector.cc: In member
--- 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=14526action=view)
A patch
This patch seems to work.
--
hjl at lucon dot org changed:
What|Removed
--- 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't clear
--- 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
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 #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 |Added
--- 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 #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:
- Won't this cause the global variable
--- 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 #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 symbols should only be referenced
--- 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 in
the same file
--- 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?
Since the string is local, that global
--- 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 #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 cause the global variable
--- 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
in the same comdat group
--- 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 would not matter. Perhaps
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 #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 problem. Can we put
typeinfo
--- 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 problem is typeinfo for (anonymous
--- 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 #4 from hjl at lucon dot org 2007-10-28 16:48 ---
Fixed.
--
hjl at lucon dot org changed:
What|Removed |Added
Status|UNCONFIRMED
: 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 #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
--- Comment #3 from hjl at lucon dot org 2007-10-21 21:41 ---
I believe all those header files should be restored unless we have a very
good reason to break libstdc++ API.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
--- Comment #1 from hjl at lucon dot org 2007-10-21 21:45 ---
I believe we should add those deleted ext/xxx header files with
#warning __FILE__ is deprecated
#include backward/xxx
if we want to move ext/xxx to backward/xxx. It is never a good idea to break
the existing C
breaks libstc++ API
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
http://gcc.gnu.org
1 - 100 of 1133 matches
Mail list logo
