[Bug bootstrap/37079] cannot find -lgcc_s
--- Comment #4 from jay dot krell at cornell dot edu 2008-08-17 08:51
---
Subject: RE: cannot find -lgcc_s
Let's dissect the output a bit:
Word wrap plus laziness => I didn't look closely before.
-Wl,-rpath -Wl,/usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1
-Wl,-rpath
-Wl,/usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1
-L/obj/gcc.1/sparc64-sun-solaris2.10/sparc64-sun-solaris2.10/./ld
-L/usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1
-L/usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1/../../../../sparc64-sunsolaris2.10/lib/sparcv9
-L/usr/local/sparc64-sun-solaris2.10/sys-root/lib/sparcv9
-L/usr/local/sparc64-sun-solaris2.10/sys-root/usr/lib/sparcv9
-L/usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1/../../../../sparc64-sun-solaris2.10/lib
-L/usr/local/sparc64-sun-solaris2.10/sys-root/lib
-L/usr/local/sparc64-sun-solaris2.10/sys-root/usr/lib
vs. the workaround:
Directory = Prefix + "/lib/gcc/sparc64-sun-solaris2.10/" + GccVersion
Run(".", "mkdir -p " + Directory)
Run(Directory, "-ln -s sparcv9/libgcc_s.so libgcc_s.so")
Run(Directory, "-ln -s sparcv9/libgcc_s.so.1 libgcc_s.so.1")
Therefore:
The "biarch" paths are not being applied to the "gcc .libs" paths.
/usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1
but not
/usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1/sparcv9
both for -Wl,-rpath and -L.
This IS reasonable, since the tools were built with -disable-multilib, BUT
the .libs were in fact put in sparcv9 -- at least the .so files.
(I find all the dot-dots a pain to read! I understand relocatable, and
symlinks, but still..)
They are being applied to the "system .libs" paths.
sys-root/lib/sparcv9 and sys-root/usr/lib/sparcv9.
Could be that .so file placement is not so flexible? Because they aren't
really supposed to be placed here anyway? You know, it is very up to me
where to place .a files, but .so files maybe more important to adhere
to strict standards, since they are used at runtime?
Also not shown is -enable-version-specific-runtimes or such, whatever
I saw Cygwin using.
It SEEMS the fix is now almost obvious.
That multilib suffixes need to be applied to more prefixes.
Or alter the directory structure otherwise, via configure.
I should also try without -enable-rpath I guess.
Thank you for attention to the bug,
- Jay
> Date: Sat, 16 Aug 2008 22:36:55 +
> Subject: [Bug bootstrap/37079] cannot find -lgcc_s
> To: [EMAIL PROTECTED]
> From: [EMAIL PROTECTED]
>
>
>
> --- Comment #3 from pinskia at gcc dot gnu dot org 2008-08-16 22:36
> ---
> What happens if you just use --with-build-sysroot= ? without saying the
> --with-sysroot?
>
>
> --
>
> pinskia at gcc dot gnu dot org changed:
>
> What |Removed |Added
>
> Component|c |bootstrap
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37079
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37079
[Bug bootstrap/37079] cannot find -lgcc_s
--- Comment #5 from jay dot krell at cornell dot edu 2008-08-17 08:52
---
Subject: RE: cannot find -lgcc_s
Subject line reminded me: Also I -disable-bootstrap.
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: [Bug bootstrap/37079] cannot find -lgcc_s
> Date: Sun, 17 Aug 2008 08:50:44 +
>
>
> Let's dissect the output a bit:
> Word wrap plus laziness => I didn't look closely before.
>
>
> -Wl,-rpath -Wl,/usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1
> -Wl,-rpath
> -Wl,/usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1
> -L/obj/gcc.1/sparc64-sun-solaris2.10/sparc64-sun-solaris2.10/./ld
> -L/usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1
> -L/usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1/../../../../sparc64-sunsolaris2.10/lib/sparcv9
> -L/usr/local/sparc64-sun-solaris2.10/sys-root/lib/sparcv9
> -L/usr/local/sparc64-sun-solaris2.10/sys-root/usr/lib/sparcv9
> -L/usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1/../../../../sparc64-sun-solaris2.10/lib
> -L/usr/local/sparc64-sun-solaris2.10/sys-root/lib
> -L/usr/local/sparc64-sun-solaris2.10/sys-root/usr/lib
>
>
> vs. the workaround:
>
>
> Directory = Prefix + "/lib/gcc/sparc64-sun-solaris2.10/" + GccVersion
> Run(".", "mkdir -p " + Directory)
> Run(Directory, "-ln -s sparcv9/libgcc_s.so libgcc_s.so")
> Run(Directory, "-ln -s sparcv9/libgcc_s.so.1 libgcc_s.so.1")
>
>
> Therefore:
>
>
>
> The "biarch" paths are not being applied to the "gcc .libs" paths.
> /usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1
> but not
> /usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1/sparcv9
>
>
> both for -Wl,-rpath and -L.
> This IS reasonable, since the tools were built with -disable-multilib, BUT
> the .libs were in fact put in sparcv9 -- at least the .so files.
>
>
> (I find all the dot-dots a pain to read! I understand relocatable, and
> symlinks, but still..)
>
> They are being applied to the "system .libs" paths.
> sys-root/lib/sparcv9 and sys-root/usr/lib/sparcv9.
>
>
> Could be that .so file placement is not so flexible? Because they aren't
> really supposed to be placed here anyway? You know, it is very up to me
> where to place .a files, but .so files maybe more important to adhere
> to strict standards, since they are used at runtime?
>
>
> Also not shown is -enable-version-specific-runtimes or such, whatever
> I saw Cygwin using.
>
>
> It SEEMS the fix is now almost obvious.
> That multilib suffixes need to be applied to more prefixes.
> Or alter the directory structure otherwise, via configure.
>
>
> I should also try without -enable-rpath I guess.
>
>
> Thank you for attention to the bug,
> - Jay
>
>
>
>
>> Date: Sat, 16 Aug 2008 22:36:55 +
>> Subject: [Bug bootstrap/37079] cannot find -lgcc_s
>> To: [EMAIL PROTECTED]
>> From: [EMAIL PROTECTED]
>>
>>
>>
>> --- Comment #3 from pinskia at gcc dot gnu dot org 2008-08-16 22:36
>> ---
>> What happens if you just use --with-build-sysroot= ? without saying the
>> --with-sysroot?
>>
>>
>> --
>>
>> pinskia at gcc dot gnu dot org changed:
>>
>> What |Removed |Added
>>
>> Component|c |bootstrap
>>
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37079
>>
>> --- You are receiving this mail because: ---
>> You reported the bug, or are watching the reporter.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37079
[Bug c++/37142] [4.2/4.3/4.4 Regression] ICE: in dependent_type_p, at cp/pt.c:15585
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-08-17 09:28 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.2.4 4.3.1 Known to work||4.1.2 Last reconfirmed|-00-00 00:00:00 |2008-08-17 09:28:13 date|| Summary|[4.2/4.3 Regression] ICE: in|[4.2/4.3/4.4 Regression] |dependent_type_p, at|ICE: in dependent_type_p, at |cp/pt.c:15585 |cp/pt.c:15585 Target Milestone|--- |4.2.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37142
[Bug tree-optimization/35972] [4.4 Regression] load-PRE missed opportunities without SFTs
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-08-17 10:20 ---
Hm, I have a patch that makes PRE phi-translation use the oracle, but still
the testcase is not optimized because for
struct Loc { int x[1]; };
int foo (int i, int b)
{
struct Loc IND;
if (b)
IND.x[0] = i;
else
IND.x[0] = i;
return IND.x[0];
}
PRE doesn't do anything either (instead this case looks like something
FRE can handle with the patch I have for PR23094).
But the patch handles
struct Loc { int x[2]; };
int foo (int i, int j, int b)
{
struct Loc IND;
if (b)
{
IND.x[0] = i;
IND.x[1] = 1;
}
else
{
IND.x[0] = j;
IND.x[1] = 0;
}
return IND.x[0];
}
I suspect that the original testcase was handled by DOM, which also lacks
support from the alias-oracle. Hmm, checking with 4.3 it doesn't do anything
for the testcase - not even the PRE opportunity for IND.x[2]. So
eventually this was something done by LIM, as the testcase was placed
inside a loop? ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35972
[Bug ada/15807] Legal program runs incorrectly, RM 3.10.2(3,29)
--- Comment #3 from sam at gcc dot gnu dot org 2008-08-17 10:56 --- This appears to have been fixed in SVN trunk. -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15807
[Bug tree-optimization/35972] [4.4 Regression] load-PRE missed opportunities without SFTs
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-08-17 10:57 --- In theory elminate should handle these case, but even though phi-translation reveals that the value of the load is available in bb 5 we do not update avail-out if we do not end up doing an insertion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35972
[Bug tree-optimization/35972] [4.4 Regression] load-PRE missed opportunities without SFTs
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-08-17 11:18
---
And I have a patch to fix regular insertion. Which means PRE now produces
foo (int i, int j, int k, int b)
{
int prephitmp.12;
int pretmp.11;
struct Loc IND;
int D.1922;
int D.1921;
int D.1920;
int D.1919;
int D.1918;
int D.1916;
:
if (b_1(D) != 0)
goto ;
else
goto ;
:
IND.x[0] = i_2(D);
IND.x[1] = j_3(D);
D.1916_5 = k_4(D) + -1;
IND.x[2] = D.1916_5;
goto ;
:
IND.x[0] = i_2(D);
IND.x[1] = j_3(D);
IND.x[2] = k_4(D);
:
# prephitmp.12_20 = PHI
D.1919_6 = i_2(D);
D.1920_7 = j_3(D);
D.1922_9 = prephitmp.12_20;
D.1921_8 = D.1920_7 + D.1919_6;
D.1918_10 = D.1921_8 + D.1922_9;
return D.1918_10;
}
for the original testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35972
[Bug tree-optimization/23094] store ccp, or store copy prop misses an optimization
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-08-17 11:26 --- The store-ccp testcase in comment #10 is fixed by the patch for PR35972. Still the requested optimization is also performed by DOM. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23094
[Bug c++/29363] [4.2/4.3/4.4 regression] ICE throwing undeclared object
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29363
[Bug ada/15808] Illegal program not detected, RM 3.9.3(10)
-- sam at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-12-13 14:04:45 |2008-08-17 12:23:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15808
[Bug fortran/35840] ICE for character expression in I/O specifier
--- Comment #3 from tobi at gcc dot gnu dot org 2008-08-17 12:43 --- I've not had the time to finish this, and now I don't remember the details of my analysis. Sorry, unassigning myself. -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org AssignedTo|tobi at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35840
[Bug ada/17732] Legal program rejected, RM 4.1.3(7)
--- Comment #2 from sam at gcc dot gnu dot org 2008-08-17 12:58 --- This appears to be fixed in SVN trunk and GCC 4.3.1. -- sam at gcc dot gnu dot org changed: What|Removed |Added CC||sam at gcc dot gnu dot org Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17732
[Bug ada/21327] gnat_ugn.texi invalid @direntry
-- sam at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-09-11 11:10:44 |2008-08-17 13:16:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21327
[Bug ada/22164] GNAT rejects matching parameter in generic instantiation as non-matching
--- Comment #5 from sam at gcc dot gnu dot org 2008-08-17 13:19 --- This appears to be fixed in SVN trunk. -- sam at gcc dot gnu dot org changed: What|Removed |Added CC||sam at gcc dot gnu dot org Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22164
[Bug ada/23389] subtype declared in generic child can't be used, same subtype elsewhere works
--- Comment #1 from sam at gcc dot gnu dot org 2008-08-17 13:22 --- This appears to be fixed in GCC 4.3.1. -- sam at gcc dot gnu dot org changed: What|Removed |Added CC||sam at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED GCC build triplet| i686-pc-cygwin |i686-pc-cygwin Resolution||FIXED Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23389
[Bug ada/30827] [Ada] GNAT.compiler_version problem for official releases?
-- sam at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-08-17 14:17:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30827
[Bug ada/34251] Illegal program not detected - component of type with limited public and nonlimited private view
--- Comment #3 from sam at gcc dot gnu dot org 2008-08-17 14:29 --- This appears to have been fixed in GCC 4.3.1. -- sam at gcc dot gnu dot org changed: What|Removed |Added CC||sam at gcc dot gnu dot org Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34251
[Bug c++/37143] New: ICE in gcc-4.4-20080815 snapshot
Do not see a place to attach the bug.i - email me perhaps. [EMAIL PROTECTED]:/opt/src/mkvtk-5.0.4/build$ /usr/local/gcc/bin/c++ -v -save-temps -o nada -Wno-deprecated -O3 -fPIC -c bug.i Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.4-20080815/configure --with-gmp=/usr/local/gmp --with-mpfr=/usr/local/mpfr --prefix=/usr/local/gcc-4.4-20080815 Thread model: posix gcc version 4.4.0 20080815 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'nada' '-Wno-deprecated' '-O3' '-fPIC' '-c' '-shared-libgcc' '-mtune=generic' /usr/local/gcc-4.4-20080815/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/cc1plus -fpreprocessed bug.i -quiet -dumpbase bug.i -mtune=generic -auxbase-strip nada -O3 -Wno-deprecated -version -fPIC -o bug.s GNU C++ (GCC) version 4.4.0 20080815 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.4.0 20080815 (experimental), GMP version 4.2.3, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: e4d46bb3061d41774b06ab83aa9f8ae2 /opt/src/mkvtk-5.0.4/VTK/Graphics/vtkModelMetadata.cxx: In member function void vtkModelMetadata::ExtractSidesFromSideSetData(vtkModelMetadataSTLCloak*, vtkModelMetadata*): /opt/src/mkvtk-5.0.4/VTK/Graphics/vtkModelMetadata.cxx:3481: internal compiler error: in compare_values_warnv, at tree-vrp.c:1031 -- Summary: ICE in gcc-4.4-20080815 snapshot Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jeffrey dot donner at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37143
[Bug c++/37143] ICE in gcc-4.4-20080815 snapshot
--- Comment #1 from jeffrey dot donner at gmail dot com 2008-08-17 14:54 --- Created an attachment (id=16079) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16079&action=view) -E of vtk 5.0.4's Graphics/vtkModelMetadata.cxx -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37143
[Bug tree-optimization/37101] [4.2/4.3 Regression] wrong code: tree vectorizer omits bogus movq/movlps construct
--- Comment #10 from uros at gcc dot gnu dot org 2008-08-17 14:58 --- Subject: Bug 37101 Author: uros Date: Sun Aug 17 14:57:00 2008 New Revision: 139178 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139178 Log: PR target/37101 * config/i386/sse.md (vec_concatv2di): Remove movlps alternative. (*vec_concatv2di_rex64_sse): Ditto. testsuite/ChangeLog: PR target/37101 * gcc.target/i386/pr37101.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/pr37101.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/i386/sse.md branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37101
[Bug c++/37142] [4.2/4.3/4.4 Regression] ICE: in dependent_type_p, at cp/pt.c:15585
--- Comment #3 from chris dot fairles at gmail dot com 2008-08-17 15:06 --- Mainline also fails on target x86_64-unknown-linux-gnu: gcc version 4.4.0 20080814 (experimental) (GCC) internal compiler error: in dependent_type_p, at cp/pt.c:15888 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37142
[Bug middle-end/36983] Trunk 138207 miscompiles 172.mgrid on x86-64
--- Comment #7 from hjl dot tools at gmail dot com 2008-08-17 15:34 --- Revision 139171 works for me at -O3 -ffast-math on Linux/Intel64. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36983
[Bug c++/35321] [4.2/4.3/4.4 regression] ICE with invalid use of __builtin_offsetof
--- Comment #2 from paolo dot carlini at oracle dot com 2008-08-17 15:40 --- Paolo, can you have a quick look to this one? Seems indeed in the same ball park of PR28573, which you fixed. Is it just matter of handling TARGET_EXPR the same way of CALL_EXPR in fold_offsetof_1? (passes testing for me...) -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||paolo at gcc dot gnu dot ||org, bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35321
[Bug c++/35321] [4.2/4.3/4.4 regression] ICE with invalid use of __builtin_offsetof
--- Comment #3 from bonzini at gnu dot org 2008-08-17 16:05 --- Indeed, it's just that this operator[] throws. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35321
[Bug c++/35321] [4.2/4.3/4.4 regression] ICE with invalid use of __builtin_offsetof
--- Comment #4 from paolo dot carlini at oracle dot com 2008-08-17 16:17 --- Ok, thanks, I'll submit a patchlet. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35321
[Bug java/36847] [4.4 Regression]: FAIL: StackTrace2 -O3 execution - source compiled test
--- Comment #2 from hjl dot tools at gmail dot com 2008-08-17 16:37 --- Fixed by revision 138840. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36847
[Bug middle-end/36983] Trunk 138207 miscompiles 172.mgrid on x86-64
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-08-17 16:49 --- Still broken for me with -O3 -ffast-math -funroll-loops -fpeel-loops. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36983
[Bug middle-end/36983] [4.4 Regression] Trunk 138207 miscompiles 172.mgrid on x86-64
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|Trunk 138207 miscompiles|[4.4 Regression] Trunk |172.mgrid on x86-64 |138207 miscompiles 172.mgrid ||on x86-64 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36983
[Bug c++/37143] [4.4 Regression] ICE in gcc-4.4-20080815 snapshot
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-08-17 16:53 --- Maybe a duplicate of PR37104. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Summary|ICE in gcc-4.4-20080815 |[4.4 Regression] ICE in gcc- |snapshot|4.4-20080815 snapshot Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37143
[Bug middle-end/36983] [4.4 Regression] Trunk 138207 miscompiles 172.mgrid on x86-64
--- Comment #9 from hjl dot tools at gmail dot com 2008-08-17 17:16 --- (In reply to comment #8) > Still broken for me with -O3 -ffast-math -funroll-loops -fpeel-loops. > It is the same as PR 35418. My suggestion at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35418#c8 works for me with -O3 -ffast-math -funroll-loops -fpeel-loops. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36983
[Bug target/37101] [4.2 Regression] wrong code: tree vectorizer omits bogus movq/movlps construct
--- Comment #11 from ubizjak at gmail dot com 2008-08-17 17:24 --- Fixed for 4.3.2. -- ubizjak at gmail dot com changed: What|Removed |Added Severity|critical|normal Component|tree-optimization |target Priority|P3 |P2 Summary|[4.2/4.3 Regression] wrong |[4.2 Regression] wrong code: |code: tree vectorizer omits |tree vectorizer omits bogus |bogus movq/movlps construct |movq/movlps construct http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37101
[Bug fortran/37129] Problems with access='direct', recl=1 I/O
--- Comment #5 from burnus at gcc dot gnu dot org 2008-08-17 17:59 --- For completeness, I tested the program with a couple of compilers, which all generated a run-time error message: - Intel ifort 10 and 11beta - Sun Studio 12 sunf95 - g95 - Portland pgf77 7.1 - Open64 openf95 - Pathscale 3.1 pathf90 Thus I'm wondering whether it makes really sense to support it with -std=legacy; on the other hand, I don't see off hand how this can break things and thus g77's behaviour with -std=legacy might be possible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37129
[Bug fortran/37083] Formatted read of line without trailing new-line fails (Windows; CR-LF issue?)
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-08-17 19:03 --- This is not platform specific. g77 runs this test case without error. gfortran is attempting to read a default formatted width and when it attempts to read the next character after the last digit of the third line it does hit the EOF. For the input file i used: 1.2 2.3 3.4 Since the End-Of_Record marker is missing, I am not sure what is valid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37083
[Bug fortran/37083] Formatted read of line without trailing new-line fails
--- Comment #3 from burnus at gcc dot gnu dot org 2008-08-17 19:21 --- Confirm. As Jerry pointed out it is not restricted to Windows. I created my test case using: printf '1.2\n2.3\n3.4' > input Fortran test case: REAL :: a, b, c OPEN(UNIT=10,FILE='input',access='stream',form='unformatted') write(10) '1.2'//achar(10)//'2.2'//achar(10)//'3.' call fputc(10,'3') close(10) open(unit=10,file='input',form='formatted') READ(10,*) a, b, c PRINT*, a*b*c END The printf-generated test file works with g77, g95, NAG f95, ifort, sunf95 and openf95. (Strictly speaking the standard presumably allows the gfortran behaviour, nevertheless it should be fixed.) -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i586-pc-mingw32 | GCC host triplet|winXP 32bit | GCC target triplet|winXP 32bit | Last reconfirmed|-00-00 00:00:00 |2008-08-17 19:21:10 date|| Summary|Formatted read of line |Formatted read of line |without trailing new-line |without trailing new-line |fails (Windows; CR-LF |fails |issue?) | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37083
[Bug libstdc++/37144] New: A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp causes invalid memory access on Linux/ia32 and Linux/Intel64. You can see it by adding -D_GLIBCXX_DEBUG to ext/pb_ds/regression/trie_data_map_rand.cc: bash-3.2$ /export/build/gnu/gcc-work/build-x86_64-linux/./gcc/g++ -shared-libgcc -B/export/build/gnu/gcc-work/build-x86_64-linux/./gcc -nostdinc++ -L/export/build/gnu/gcc-work/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libstdc++-v3/src -L/export/build/gnu/gcc-work/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs -B/usr/gcc-4.4-work/x86_64-unknown-linux-gnu/bin/ -B/usr/gcc-4.4-work/x86_64-unknown-linux-gnu/lib/ -isystem /usr/gcc-4.4-work/x86_64-unknown-linux-gnu/include -isystem /usr/gcc-4.4-work/x86_64-unknown-linux-gnu/sys-include -m32 -g -O2 -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/export/build/gnu/gcc-work/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/export/build/gnu/gcc-work/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libstdc++-v3/include -I/export/gnu/src/gcc-work/gcc/libstdc++-v3/libsupc++ -I/export/gnu/src/gcc-work/gcc/libstdc++-v3/include/backward -I/export/gnu/src/gcc-work/gcc/libstdc++-v3/testsuite/util -Wl,--gc-sections /export/gnu/src/gcc-work/gcc/libstdc++-v3/testsuite/ext/pb_ds/regression/trie_data_map_rand.cc -DPB_DS_REGRESSION ./libtestc++.a -lm -m32 -o ./trie_data_map_rand.exe -D_GLIBCXX_DEBUG bash-3.2$ ./trie_data_map_rand.exe /export/build/gnu/gcc-work/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp:213: typename __gnu_pbds::detail::pat_trie_data_::node_pointer __gnu_pbds::detail::pat_trie_data_::recursive_copy_node(typename Allocator::rebind::other::const_pointer) [with Key = __gnu_pbds::test::basic_type, Mapped = __gnu_pbds::test::basic_type, Node_And_It_Traits = __gnu_pbds::detail::trie_traits<__gnu_pbds::test::basic_type, __gnu_pbds::test::basic_type, __gnu_pbds::string_trie_e_access_traits<__gnu_pbds::test::basic_type, 'a', 'd', false, __gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type> >, __gnu_pbds::null_trie_node_update, __gnu_pbds::pat_trie_tag, __gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type> >, Allocator = __gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type>]: Assertion 'child_i > 1' failed. Aborted bash-3.2$ -- Summary: A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destruct or_fn_imps.hpp Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug middle-end/37135] [4.3/4.4 Regression] code size increase for bit-fields assignment
--- Comment #2 from etienne_lorrain at yahoo dot fr 2008-08-17 19:31
---
It is not related to bitfields, this also show the problem:
struct color { unsigned char red, green, blue, transparent; } cur_color;
static const struct color mycolor = { 200, 10, 30, 0 };
void fct(void)
{
cur_color = mycolor;
}
with gcc-4.3.1 cur_color is initialised with 4 "movb" (so address is encoded 4
times)
and with gcc-4.2 with a 32 bits constant and a single "movl".
It seems to be the old problem of gcc not having a "write combining" pass
(converting consecutive byte/word writes into single double word writes), and
the "fix" of defining an intermediate variable is no more working.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37135
[Bug tree-optimization/36792] [4.4 Regression] Revision 137631 causes many failures
--- Comment #8 from hjl dot tools at gmail dot com 2008-08-17 19:33 --- Intermittent failures: FAIL: ext/pb_ds/regression/trie_data_map_rand.cc execution test FAIL: ext/pb_ds/regression/trie_no_data_map_rand.cc execution test is due to PR 37144. -- hjl dot tools at gmail dot com changed: What|Removed |Added BugsThisDependsOn||37144 Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36792
[Bug fortran/37129] Problems with access='direct', recl=1 I/O
--- Comment #6 from kargl at gcc dot gnu dot org 2008-08-17 19:53 --- (In reply to comment #4) > I agree there is legacy g77 behavior involved here. I did a test here, and a > very simple patch will enable this feature. At least for the test case I get > the exact same results as g77. I just disable this check for RECL=1 and > std=legacy. > > I am leary about doing this sort of thing and would like to here from others > on > the team s far as doing this. > Given Tobias' findings with other compilers and the fact that this extension is not documented in the g77 manual (well at least I can't find it documented), I'm inclined to state that the code is invalid and g77 has a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37129
[Bug tree-optimization/37145] New: [4.4 Regression] XFAILs from PRE rewrite
We still would have FAIL: gcc.dg/tree-ssa/ssa-fre-7.c scan-tree-dump-times fre "Inserted pretmp" 1 FAIL: gcc.dg/tree-ssa/ssa-fre-7.c scan-tree-dump-times fre "Replaced a.u.f with pretmp" 3 FAIL: gcc.dg/tree-ssa/ssa-fre-7.c scan-tree-dump-times fre "Replaced a.u.k with j" 1 FAIL: gcc.dg/tree-ssa/ssa-fre-7.c scan-tree-dump fre "= VIEW_CONVERT_EXPR\\(j_" FAIL: gcc.dg/tree-ssa/ssa-fre-7.c scan-tree-dump optimized "return j" FAIL: gcc.dg/tree-ssa/ssa-fre-8.c scan-tree-dump-times fre "Replaced u.f with pretmp" 2 FAIL: gcc.dg/tree-ssa/ssa-fre-8.c scan-tree-dump-times fre "Inserted pretmp" 2 FAIL: gcc.dg/tree-ssa/ssa-fre-9.c scan-tree-dump-times fre "Eliminated: 1" 2 FAIL: gcc.dg/tree-ssa/ssa-fre-9.c scan-tree-dump-times fre "Insertions: 1" 2 FAIL: gcc.dg/tree-ssa/ssa-pre-15.c scan-tree-dump optimized "= 0;" but they were XFAILed with URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138005 Log: 2008-07-20 Daniel Berlin <[EMAIL PROTECTED]> * gcc.dg/tree-ssa/ssa-fre-7.c: XFAIL. * gcc.dg/tree-ssa/ssa-fre-8.c: Ditto. * gcc.dg/tree-ssa/ssa-fre-9.c: Ditto. * gcc.dg/tree-ssa/ssa-fre-13.c: Ditto. * gcc.dg/tree-ssa/ssa-fre-14.c: Ditto. * gcc.dg/tree-ssa/ssa-fre-17.c: Ditto. * gcc.dg/tree-ssa/ssa-pre-15.c: Ditto. * gcc.dg/tree-ssa/loadpre1.c: PASS. -- Summary: [4.4 Regression] XFAILs from PRE rewrite Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: missed-optimization, xfail Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37145
[Bug tree-optimization/37145] [4.4 Regression] XFAILs from PRE rewrite
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-08-17 20:08 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-08-17 20:08:17 date|| Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37145
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #1 from hjl dot tools at gmail dot com 2008-08-17 20:59 --- It also happens in gcc 4.3.2: lake:pts/1[303]> /export/build/gnu/gcc-4.3/build-x86_64-linux/./gcc/g++ -shared-libgcc -B/export/build/gnu/gcc-4.3/build-x86_64-linux/./gcc -nostdinc++ -L/export/build/gnu/gcc-4.3/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/export/build/gnu/gcc-4.3/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/usr/gcc-4.3/x86_64-unknown-linux-gnu/bin/ -B/usr/gcc-4.3/x86_64-unknown-linux-gnu/lib/ -isystem /usr/gcc-4.3/x86_64-unknown-linux-gnu/include -isystem /usr/gcc-4.3/x86_64-unknown-linux-gnu/sys-include -g -O2 -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/export/build/gnu/gcc-4.3/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/export/build/gnu/gcc-4.3/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/export/gnu/src/gcc-4.3/gcc/libstdc++-v3/libsupc++ -I/export/gnu/src/gcc-4.3/gcc/libstdc++-v3/include/backward -I/export/gnu/src/gcc-4.3/gcc/libstdc++-v3/testsuite/util -Wl,--gc-sections /export/gnu/src/gcc-4.3/gcc/libstdc++-v3/testsuite/ext/pb_ds/regression/trie_data_map_rand.cc -DPB_DS_REGRESSION ./libtestc++.a -lm -D_GLIBCXX_DEBUG lake:pts/1[304]> ./a.out /export/build/gnu/gcc-4.3/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp:213: typename __gnu_pbds::detail::pat_trie_data_::node_pointer __gnu_pbds::detail::pat_trie_data_::recursive_copy_node(typename Allocator::rebind::other::const_pointer) [with Key = __gnu_pbds::test::basic_type, Mapped = __gnu_pbds::test::basic_type, Node_And_It_Traits = __gnu_pbds::detail::trie_traits<__gnu_pbds::test::basic_type, __gnu_pbds::test::basic_type, __gnu_pbds::string_trie_e_access_traits<__gnu_pbds::test::basic_type, 'a', 'd', false, __gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type> >, __gnu_pbds::null_trie_node_update, __gnu_pbds::pat_trie_tag, __gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type> >, Allocator = __gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type>]: Assertion 'child_i > 1' failed. [1]13605 abort ./a.out -- hjl dot tools at gmail dot com changed: What|Removed |Added Version|4.4.0 |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #2 from hjl dot tools at gmail dot com 2008-08-17 21:19 ---
include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
doesn't look right:
PB_DS_CLASS_T_DEC
typename PB_DS_CLASS_C_DEC::node_pointer
PB_DS_CLASS_C_DEC::
recursive_copy_node(const_node_pointer p_other_nd)
{
...
size_type child_i = 0;
...
--child_i; // What if child_i == 0?
_GLIBCXX_DEBUG_ASSERT(child_i > 1);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #3 from hjl dot tools at gmail dot com 2008-08-17 21:49 --- Created an attachment (id=16081) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16081&action=view) A patch With this patch, I got bash-3.2$ /export/build/gnu/gcc-4.3/build-x86_64-linux/./gcc/g++ -shared-libgcc -B/export/build/gnu/gcc-4.3/build-x86_64-linux/./gcc -nostdinc++ -L/export/build/gnu/gcc-4.3/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/export/build/gnu/gcc-4.3/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/usr/gcc-4.3/x86_64-unknown-linux-gnu/bin/ -B/usr/gcc-4.3/x86_64-unknown-linux-gnu/lib/ -isystem /usr/gcc-4.3/x86_64-unknown-linux-gnu/include -isystem /usr/gcc-4.3/x86_64-unknown-linux-gnu/sys-include -g -O2 -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/export/build/gnu/gcc-4.3/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/export/build/gnu/gcc-4.3/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/export/gnu/src/gcc-4.3/gcc/libstdc++-v3/libsupc++ -I/export/gnu/src/gcc-4.3/gcc/libstdc++-v3/include/backward -I/export/gnu/src/gcc-4.3/gcc/libstdc++-v3/testsuite/util -Wl,--gc-sections /export/gnu/src/gcc-4.3/gcc/libstdc++-v3/testsuite/ext/pb_ds/regression/trie_data_map_rand.cc -DPB_DS_REGRESSION ./libtestc++.a -lm -D_GLIBCXX_DEBUG -O0 bash-3.2$ ./a.out /export/build/gnu/gcc-4.3/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/include/ext/pb_ds/detail/pat_trie_/internal_node.hpp:314: typename __gnu_pbds::detail::pat_trie_internal_node::node_pointer __gnu_pbds::detail::pat_trie_internal_node::get_child_node(typename E_Access_Traits::const_iterator, typename E_Access_Traits::const_iterator, typename Allocator::rebind::other::const_pointer) [with Type_Traits = __gnu_pbds::detail::types_traits<__gnu_pbds::test::basic_type, __gnu_pbds::test::basic_type, __gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type>, false>, E_Access_Traits = __gnu_pbds::detail::synth_e_access_traits<__gnu_pbds::detail::types_traits<__gnu_pbds::test::basic_type, __gnu_pbds::test::basic_type, __gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type>, false>, false, __gnu_pbds::string_trie_e_access_traits<__gnu_pbds::test::basic_type, 'a', 'd', false, __gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type> > >, Metadata = __gnu_pbds::detail::null_node_metadata, Allocator = __gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type>]: Assertion 'i < arr_size' failed. Aborted bash-3.2$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #4 from hjl dot tools at gmail dot com 2008-08-17 21:51 --- The failure is random due to the random test. If you fix the random seed, the failure will be more reproducible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug fortran/37083] Formatted read of line without trailing new-line fails
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-08-17 22:04 --- I have a patch testing. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-08-17 19:21:10 |2008-08-17 22:04:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37083
[Bug c++/37143] [4.4 Regression] ICE in VRP with the auto-vectorizer
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-08-18 03:33 ---
It is definitely related to that other PR. Here is a reduced testcase:
void
f(int NumberOfSideSets, int *ssNumDFperSide, float *ssDF)
{
int i;
float *newssDF = __null;
int *newssNumDF = new int [NumberOfSideSets];
int numNewDF = 0;
int ii=0;
for (i=0; i 0)
newssDF = new float [numNewDF];
int nextDF = 0;
int ndf = ssNumDFperSide[ii];
for (i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=37143
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #5 from hjl dot tools at gmail dot com 2008-08-18 04:20 --- valgrind also reports Conditional jump or move depends on uninitialised value(s) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
