[Bug c/36024] Incorrect function name in linking error
--- Comment #3 from ashutosh dot nema at nechclst dot in 2008-04-24 06:55 --- Hi Richard, I agree because its a linking issue but the suggestion preposed by you is not working -Wl,--no-demangle to avoid demangling symbols. when i use -Wl,--no-demangle with gcc it again raise the same message I think its related with reserved identifiers used by gcc. thats why gcc mangle its name. Dont you think there should be some name backtracking feature should be added in gcc to give correct name to the user after name mangling. i am unaware this feature. If some feature is available in gcc then can you please help me regarding this (In reply to comment #1) Because the linker demangles symbols and __ct__3abcFv is the mangled form of abc::__ct(void). Note this is a linker issue and if at all should be filed with the binutils bugzilla. You can use -Wl,--no-demangle to avoid demangling symbols. -- ashutosh dot nema at nechclst dot in changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36024
[Bug target/36015] [4.3/4.4 Regression] -mregparm and fn decls without arguments
--- Comment #5 from jakub at gcc dot gnu dot org 2008-04-24 07:00 --- Subject: Bug 36015 Author: jakub Date: Thu Apr 24 06:59:55 2008 New Revision: 134621 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134621 Log: PR target/36015 * config/i386/i386.c (init_cumulative_args): Don't pass anything in registers for -m32 only if stdarg_p (fntype). * gcc.dg/pr36015.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr36015.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36015
[Bug target/36015] [4.3/4.4 Regression] -mregparm and fn decls without arguments
--- Comment #6 from jakub at gcc dot gnu dot org 2008-04-24 07:04 --- Subject: Bug 36015 Author: jakub Date: Thu Apr 24 07:03:38 2008 New Revision: 134622 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134622 Log: PR target/36015 * config/i386/i386.c (init_cumulative_args): Don't pass anything in registers for -m32 only if stdarg_p (fntype). * gcc.dg/pr36015.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pr36015.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/i386/i386.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36015
[Bug target/36015] [4.3/4.4 Regression] -mregparm and fn decls without arguments
--- Comment #7 from jakub at gcc dot gnu dot org 2008-04-24 07:07 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36015
[Bug target/35982] [4.4 regression] ICE while building mplayer on ppc with -O3 -ffast-math -mcpu=970
--- Comment #6 from jakub at gcc dot gnu dot org 2008-04-24 07:14 --- Fixed on the 4.3 branch, but not on the trunk yet. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.3.0 |4.3.0 4.4.0 Known to work|4.1.2 4.2.3 |4.1.2 4.2.3 4.3.1 Summary|[4.3 regression] ICE while |[4.4 regression] ICE while |building mplayer on ppc with|building mplayer on ppc with |-O3 -ffast-math -mcpu=970 |-O3 -ffast-math -mcpu=970 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35982
[Bug c++/35678] [4.3/4.4 Regression] partial template specialization ICE in dependent_type_p, at cp/pt.c:15539
--- Comment #5 from jakub at gcc dot gnu dot org 2008-04-24 07:16 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35678
[Bug target/35982] [4.4 regression] ICE while building mplayer on ppc with -O3 -ffast-math -mcpu=970
--- Comment #7 from irar at il dot ibm dot com 2008-04-24 07:30 --- (In reply to comment #6) Fixed on the 4.3 branch, but not on the trunk yet. Yes, I'm going to do this during the next couple of hours. Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35982
[Bug c++/13402] Wrong default value for uninitialized pointer-to-member
--- Comment #3 from s__nakayama at infoseek dot jp 2008-04-24 08:05 --- (In reply to comment #2) The program has undefined semantics. By 12.1/5, the default constructor of B initializes the pointer as if it was default initialized as if a user specified constructor had an empty initializer list. 12.6.2/4 treats the case of members not listed in the initializer list, and says that POD types (e.g. pointers to members) are not initialized at all. I.e., the given program has undefined behavior. I doubt this. By 8.5/6, object of static storage duration shall be zero-initialized. And, a implicit default constructor doesn't overwrite the value of the member. -- s__nakayama at infoseek dot jp changed: What|Removed |Added CC||s__nakayama at infoseek dot ||jp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13402
[Bug other/36030] Throwing exceptions in multiple threads leads to spinning in call to _Unwind_Find_FDE
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-04-24 08:27 ---
This is a bug in your glibc. Current glibc has
__dl_iterate_phdr (int (*callback) (struct dl_phdr_info *info,
size_t size, void *data), void *data)
{
struct link_map *l;
struct dl_phdr_info info;
int ret = 0;
/* Make sure we are alone. */
__rtld_lock_lock_recursive (GL(dl_load_lock));
__libc_cleanup_push (cancel_handler, 0);
...
so it is already properly locked.
Which glibc version do you use? You should probably report this as a bug
to your vendor.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36030
[Bug fortran/35892] gfortran lost memory blocks
--- Comment #18 from george at gcc dot gnu dot org 2008-04-24 08:29 --- I've investigated the PR code further. The relevant parts of the code are structured like so: module mod integer aa, bb common /oof/ aa,bb contains subroutine sub i = max(0,aa-1) print *, i, aa, bb end subroutine sub subroutine subb common /oof/ ic,id print *, ic, id end subroutine subb end module program test use mod common /oof/ ii,jj ii = 42 jj = ii / 2 print *, ii, jj call sub call subb end program test (A main program isn't in the PR, but I added one for debugging.) The COMMON appears both in the module scope, and in the local scope of one of the procedures in the module. When the storage layout is made for the COMMON at module scope, the decls get thrown away too early if they are chained to the (non-existent) procedure scope; further references to those identifiers in procedure sub are in peril. Chaining the decls to the global scope for module-scope COMMON seems to be appropriate here and fixes the segfault for the PR code. I will rework the patch to include this case. There is still the outstanding problem of lost memory blocks unrelated to the original patch. Any further progress on that? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35892
[Bug libstdc++/36032] -fno-exceptions breaks simple if-statement.
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-24 08:33 --- These defines are supposed to make libstdc++ work with -fno-exceptions, you are not really supposed to use -fno-exceptions with a program that uses exceptions ... of course a diagnostic would be nice here, instead of silently generating completely unexpected code. Without including iostream you'd see t.C: In function 'int main()': t.C:4: error: exception handling disabled, use -fexceptions to enable so a fix would be to prevent these defines from leaking out to the user program. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||3.3.6 4.3.0 Last reconfirmed|-00-00 00:00:00 |2008-04-24 08:33:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36032
[Bug ada/32181] Legal program executes incorrectly, RM 3.4(27)
--- Comment #5 from sam at gcc dot gnu dot org 2008-04-24 08:36 --- Ahn Vo: Pak2.Eq is *the same* as Pak1.Eq, that's the whole point. Thus both consider only T1 aspects of the objects. What you say would be true if the code had been: package Pak1 is type T1 is tagged null record; function Eq(X, Y: T1) return Boolean renames =; end Pak1; package Pak2 is type T2 is new Pak1.T1 with record F1: Integer; end record; function Eq(X, Y: T2) return Boolean renames =; -- This line added end Pak2; But there is no such line in the original example. In the original example, Pak2.Eq is *not* the = operator on T2, it is the = operator on T1 objects. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32181
[Bug libstdc++/36032] -fno-exceptions breaks simple if-statement.
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-04-24 08:40 --- *** This bug has been marked as a duplicate of 25191 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36032
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #40 from pinskia at gcc dot gnu dot org 2008-04-24 08:40 --- *** Bug 36032 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||gcc-bugzilla at contacts dot ||eelis dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #41 from pinskia at gcc dot gnu dot org 2008-04-24 08:42
---
I'd rather you work around this in objective-c or objective c++.
Well guess what, it is more than an objective-c or objective C++ issue as PR
36032 had a good example for why, it can produce wrong code:
#include iostream
int main()
{
if(true) try {} catch(int) {}
else std::cout bla\n;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug target/35982] [4.4 regression] ICE while building mplayer on ppc with -O3 -ffast-math -mcpu=970
--- Comment #8 from irar at gcc dot gnu dot org 2008-04-24 09:22 --- Subject: Bug 35982 Author: irar Date: Thu Apr 24 09:21:55 2008 New Revision: 134624 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134624 Log: PR tree-optimization/35982 * tree-vect-analyze.c (vect_check_interleaving): Check that the interleaved data-refs are of the same type. Added: trunk/gcc/testsuite/gcc.dg/vect/fast-math-pr35982.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-analyze.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35982
[Bug fortran/35892] gfortran lost memory blocks
--- Comment #19 from KnowlesPJ at Cardiff dot ac dot uk 2008-04-24 09:34 --- As the originator of this report, I just wanted to add a context comment in case it is helpful. This construction (common declared both in the module and in subroutines (contained or external)) is horrible, but one of our developers has found it to be the only reasonable way of dragging in a dusty deck. Although the compiler crash was reported, this is not our main interest, since the compiler seems to crash only with -g. Without -g, at any optimization level, we are getting wrong numbers at run time. Abstracting that from the 1.5 million line code for a reasonable test case to report will not be easy, so we are hoping that the fix to the compiler crash will be the silver bullet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35892
[Bug tree-optimization/36033] New: Non-optimal vectorization of interleaved data of different types
With the fix of pr35982, interleaved data of different types (of the same size) can be vectorized only as a collection of single-element strided accesses, causing redundant misaligned loads. Better solution for such cases will be to perform all the vector loads and extraction operations as if the data-refs were of the same type, and then convert the extracted elements to the correct type if necessary (before performing any operations on the extracted elements). The testcase is gcc.dg/vect/fast-math-pr35982.c. -- Summary: Non-optimal vectorization of interleaved data of different types Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: irar at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36033
[Bug target/35982] [4.4 regression] ICE while building mplayer on ppc with -O3 -ffast-math -mcpu=970
--- Comment #9 from irar at il dot ibm dot com 2008-04-24 09:40 --- Fixed. I opened pr36033 to get rid off the redundant loads. Ira -- irar at il dot ibm dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35982
[Bug ada/32181] Legal program executes incorrectly, RM 3.4(27)
--- Comment #6 from ludovic at ludovic-brenta dot org 2008-04-24 09:55 --- (In reply to comment #4) Anh Vo, you are perfectly right up to a point: Pak1.Eq returns True and Pak2.Eq returns False, therefore comparing the two results yields False. Where you are wrong is where you think Pak2.Eq is correct in returning False. This is the bug. Pak2.Eq should return True. To explain another way: ARM 3.4(27) defines precisely the behaviour of a call to an inherited subprogram. Pak2.Eq is inherited and not overridden, so 3.4(27) applies. Per ARM 3.4(27), calling Pak2.Eq (Z1, Z2) is by definition equivalent to calling Pak1.Eq (Pak1.T1 (Z1), Pak1.T1 (Z2)) Therefore the two calls must yield the same result (i.e. True). The test case shows clearly that this is not the case, i.e. GNAT has a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32181
[Bug rtl-optimization/36008] [4.3/4.4 Regression] Function produces wrong results when inlined.
--- Comment #11 from jakub at gcc dot gnu dot org 2008-04-24 09:33 ---
extern void abort (void);
int g[48][3][3];
void __attribute__ ((noinline))
bar (int x[3][3], int y[3][3])
{
static int i;
if (x != g[i + 8] || y != g[i++])
abort ();
}
static inline void __attribute__ ((always_inline))
foo (int x[][3][3])
{
int i;
for (i = 0; i 8; i++)
#ifdef GOOD
bar (x[i + 8], x[i]);
#else
{
int k = i + 8;
bar (x[k], x[k - 8]);
}
#endif
}
int
main ()
{
foo (g);
return 0;
}
with -DGOOD doesn't fail at any optimization level, without it fails again with
-O2 -funroll-loops, -O3 etc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36008
[Bug rtl-optimization/36006] [4.4 regression] invalid rtl sharing with -O2
--- Comment #6 from ubizjak at gmail dot com 2008-04-24 10:24 --- (In reply to comment #4) I am set up for running the testsuite on x86_64-pc-mingw32, however it takes several days to complete. Is there a reduced set of tests that I can run? I have set up a crosscompiler to x86_64-pc-mingw32, and although I'm not able to regression test runtime tests, the patch fixed the failure for this target. As far as regression test is concerned, it is enough to run it on linux, since we are fixing target-independent stuff. So, fixed for mainline. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36006
[Bug tree-optimization/36008] [4.3/4.4 Regression] Function produces wrong results when inlined.
--- Comment #12 from jakub at gcc dot gnu dot org 2008-04-24 09:59 --- This is actually a tree optimization issue. In optimized dump without -DGOOD we have: bar (g[0][0] + 288, g[0][0]); bar (g[0][0] + 324, g[1][0]); bar (g[0][0] + 360, g[2][0]); bar (g[0][0] + 396, g[3][0]); bar (g[1][0], g[4][0]); bar (g[0][0] + 468, g[5][0]); bar (g[0][0] + 504, g[6][0]); bar (g[0][0] + 540, g[7][0]); note the bogus first argument for 5th bar call, should have been g[0][0] + 432 aka g[12][0]. In *.reassoc2 we have for the 4th and 5th bar calls: i_73 = i_56 + 1; k_80 = i_73 + 8; D.1588_81 = (long unsigned int) k_80; D.1589_82 = D.1588_81 * 36; D.1590_83 = D.1589_82 + -288; D.1591_84 = g + D.1590_83; D.1592_85 = (*D.1591_84)[0]; D.1594_86 = g[0][0] + D.1589_82; bar (D.1594_86, D.1592_85); i_90 = i_73 + 1; k_97 = i_90 + 8; D.1588_98 = (long unsigned int) k_97; D.1589_99 = D.1588_98 * 36; D.1590_100 = D.1589_99 + -288; D.1591_101 = g + D.1590_100; D.1592_102 = (*D.1591_101)[0]; D.1594_103 = g[0][0] + D.1589_99; bar (D.1594_103, D.1592_102); which looks correct, but in *.vrp2: i_73 = 3; k_80 = 11; D.1588_81 = 11; D.1589_82 = 396; D.1590_83 = 108; D.1591_84 = g[3]; D.1592_85 = (*D.1591_84)[0]; D.1594_86 = g[0][0] + 396; bar (D.1594_86, D.1592_85); i_90 = 4; k_97 = 12; D.1588_98 = 12; D.1589_99 = 432; D.1590_100 = 144; D.1591_101 = g[4]; D.1592_102 = (*D.1591_101)[0]; D.1594_103 = g[1][0]; bar (g[1][0], D.1592_102); which is wrong. So to me this looks like vrp bug. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Component|rtl-optimization|tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36008
[Bug tree-optimization/36034] New: [4.3/4.4 Regression] wrong code vectorizing unrolled loop
The following testcase, reduced from gfortran.dg/array_1.f90, aborts if
vectorization is enabled. The test() function is miscompiled.
double x[5][10] = { { 10, 11, 12, 13, 14, 15, -1, -1, -1, -1 },
{ 21, 22, 23, 24, 25, 26, -1, -1, -1, -1 },
{ 32, 33, 34, 35, 36, 37, -1, -1, -1, -1 },
{ 43, 44, 45, 46, 47, 48, -1, -1, -1, -1 },
{ 54, 55, 56, 57, 58, 59, -1, -1, -1, -1 } };
double tmp[5][6];
void __attribute__((noinline))
test (void)
{
int i, j;
for (i = 0; i 5; ++i)
{
tmp[i][0] = x[i][0];
tmp[i][1] = x[i][1];
tmp[i][2] = x[i][2];
tmp[i][3] = x[i][3];
tmp[i][4] = x[i][4];
tmp[i][5] = x[i][5];
}
}
extern void abort (void);
int main()
{
int i, j;
test();
for (i = 0; i 5; ++i)
for (j = 0; j 6; ++j)
if (tmp[i][j] == -1)
abort ();
return 0;
}
--
Summary: [4.3/4.4 Regression] wrong code vectorizing unrolled
loop
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-code
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=36034
[Bug tree-optimization/36034] [4.3/4.4 Regression] wrong code vectorizing unrolled loop
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||irar at il dot ibm dot com Known to fail||4.3.0 4.4.0 Known to work||4.2.3 Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36034
[Bug tree-optimization/36034] [4.3/4.4 Regression] wrong code vectorizing unrolled loop
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-24 11:20 --- This blocks adding the early unrolling pass (because then gfortran.dg/array_1.f90 fails at -O3). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||34265 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36034
[Bug tree-optimization/36034] [4.3/4.4 Regression] wrong code vectorizing unrolled loop
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-24 11:27 --- bb 2: vect_px.14_32 = (vector double *) x; vect_px.9_31 = vect_px.14_32; vect_ptmp.24_42 = (vector double *) tmp; vect_ptmp.19_43 = vect_ptmp.24_42; bb 3: # SMT.20_50 = PHI SMT.20_58(4), SMT.20_51(D)(2) # ivtmp.26_48 = PHI ivtmp.26_49(4), 0(2) # ivtmp.25_44 = PHI ivtmp.25_45(4), vect_ptmp.19_43(2) # ivtmp.15_35 = PHI ivtmp.15_36(4), vect_px.9_31(2) # tmp_34 = PHI tmp_57(4), tmp_23(D)(2) # VUSE x_24(D), SMT.10_52(D) vect_var_.16_37 = *ivtmp.15_35; ivtmp.15_38 = ivtmp.15_35 + 16; # VUSE x_24(D), SMT.10_52(D) vect_var_.17_39 = *ivtmp.15_38; ivtmp.15_40 = ivtmp.15_38 + 16; # VUSE x_24(D), SMT.10_52(D) vect_var_.18_41 = *ivtmp.15_40; # tmp_53 = VDEF tmp_34 # SMT.20_54 = VDEF SMT.20_50 *ivtmp.25_44 = vect_var_.16_37; ivtmp.25_46 = ivtmp.25_44 + 16; # tmp_55 = VDEF tmp_53 # SMT.20_56 = VDEF SMT.20_54 *ivtmp.25_46 = vect_var_.17_39; ivtmp.25_47 = ivtmp.25_46 + 16; # tmp_57 = VDEF tmp_55 # SMT.20_58 = VDEF SMT.20_56 *ivtmp.25_47 = vect_var_.18_41; ivtmp.15_36 = ivtmp.15_40 + 16; ivtmp.25_45 = ivtmp.25_47 + 16; ivtmp.26_49 = ivtmp.26_48 + 1; if (ivtmp.26_49 5) goto bb 4; else goto bb 5; bb 4: goto bb 3; the final increment for ivtmp.15_36 is wrong -- it should be 48. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36034
[Bug tree-optimization/36008] [4.3/4.4 Regression] Function produces wrong results when inlined.
--- Comment #13 from jakub at gcc dot gnu dot org 2008-04-24 11:29 --- Created an attachment (id=15524) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15524action=view) gcc43-pr36008.patch Fix I'm bootstrapping/regtesting ATM. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36008
[Bug tree-optimization/36034] [4.3/4.4 Regression] wrong code vectorizing unrolled loop
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-04-24 11:44 ---
Testcase with 1d arrays (like produced by fortran):
double x[50] = { 10, 11, 12, 13, 14, 15, -1, -1, -1, -1,
21, 22, 23, 24, 25, 26, -1, -1, -1, -1,
32, 33, 34, 35, 36, 37, -1, -1, -1, -1,
43, 44, 45, 46, 47, 48, -1, -1, -1, -1,
54, 55, 56, 57, 58, 59, -1, -1, -1, -1 };
double tmp[30];
void __attribute__((noinline))
test (void)
{
int i, j;
for (i = 0; i 5; ++i)
{
tmp[i*6] = x[i*10];
tmp[i*6+1] = x[i*10+1];
tmp[i*6+2] = x[i*10+2];
tmp[i*6+3] = x[i*10+3];
tmp[i*6+4] = x[i*10+4];
tmp[i*6+5] = x[i*10+5];
}
}
extern void abort (void);
int main()
{
int i, j;
test();
for (i = 0; i 5; ++i)
for (j = 0; j 6; ++j)
if (tmp[i*6+j] == -1)
abort ();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36034
[Bug tree-optimization/36034] [4.3/4.4 Regression] wrong code vectorizing unrolled inner loop (SLP)
--- Comment #4 from irar at il dot ibm dot com 2008-04-24 12:24 ---
(In reply to comment #2)
the final increment for ivtmp.15_36 is wrong -- it should be 48.
Right. We are not supposed to vectorize this at all, since SLP currently
doesn't support loads with gaps.
Here is a possible fix:
Index: tree-vect-analyze.c
===
--- tree-vect-analyze.c (revision 134161)
+++ tree-vect-analyze.c (working copy)
@@ -2226,11 +2226,16 @@ vect_analyze_group_access (struct data_r
/* Check that the size of the interleaving is equal to STEP for stores,
i.e., that there are no gaps. */
- if (!DR_IS_READ (dr) dr_step != count_in_bytes)
+ if (dr_step != count_in_bytes)
{
- if (vect_print_dump_info (REPORT_DETAILS))
-fprintf (vect_dump, interleaved store with gaps);
- return false;
+ if (DR_IS_READ (dr))
+slp_impossible = true;
+ else
+{
+ if (vect_print_dump_info (REPORT_DETAILS))
+fprintf (vect_dump, interleaved store with gaps);
+ return false;
+}
}
/* Check that STEP is a multiple of type size. */
I'll not be able to test and submit it till Sunday.
Ira
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-04-24 12:24:56
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36034
[Bug testsuite/36035] New: [4.4 Regression]: FAIL: gcc.dg/vect/vect-vfa-slp.c
On Linux/ia32 and Linux/x86-64, revision 134542 gives FAIL: gcc.dg/vect/vect-vfa-slp.c scan-tree-dump-times vect Vectorizing an unaligned access 2 Revision 134539 is OK. It may be related to revision 134540 http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01607.html -- Summary: [4.4 Regression]: FAIL: gcc.dg/vect/vect-vfa-slp.c Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite 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=36035
[Bug testsuite/36035] [4.4 Regression]: FAIL: gcc.dg/vect/vect-vfa-slp.c
--- Comment #1 from hjl dot tools at gmail dot com 2008-04-24 12:45 ---
Revision 134540 adds a new line which fails on Linux/x86:
Index: gcc.dg/vect/vect-vfa-slp.c
===
--- gcc.dg/vect/vect-vfa-slp.c (revision 134500)
+++ gcc.dg/vect/vect-vfa-slp.c (working copy)
@@ -52,5 +52,6 @@ main (void)
return 0;
}
-/* { dg-final { scan-tree-dump-times vectorized 1 loops 1 vect } } */
+/* { dg-final { scan-tree-dump-times vectorized 1 loops 1 vect { xfail
vect_no_align } } } */
+/* { dg-final { scan-tree-dump-times Vectorizing an unaligned access 2
vect { xfail vect_no_align } } } */
/* { dg-final { cleanup-tree-dump vect } } */
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Summary|[4.4 Regression]: FAIL: |[4.4 Regression]: FAIL:
|gcc.dg/vect/vect-vfa-slp.c |gcc.dg/vect/vect-vfa-slp.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36035
[Bug tree-optimization/36034] [4.3/4.4 Regression] wrong code vectorizing unrolled inner loop (SLP)
--- Comment #5 from rguenther at suse dot de 2008-04-24 12:55 --- Subject: Re: [4.3/4.4 Regression] wrong code vectorizing unrolled inner loop (SLP) On Thu, 24 Apr 2008, irar at il dot ibm dot com wrote: --- Comment #4 from irar at il dot ibm dot com 2008-04-24 12:24 --- (In reply to comment #2) the final increment for ivtmp.15_36 is wrong -- it should be 48. Right. We are not supposed to vectorize this at all, since SLP currently doesn't support loads with gaps. Here is a possible fix: Thanks. I am testing the patch now. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36034
[Bug rtl-optimization/36006] [4.4 regression] invalid rtl sharing with -O2
--- Comment #7 from nightstrike at gmail dot com 2008-04-24 14:21 --- (In reply to comment #6) (In reply to comment #4) I am set up for running the testsuite on x86_64-pc-mingw32, however it takes several days to complete. Is there a reduced set of tests that I can run? I have set up a crosscompiler to x86_64-pc-mingw32, and although I'm not able to regression test runtime tests, the patch fixed the failure for this target. As far as regression test is concerned, it is enough to run it on linux, since we are fixing target-independent stuff. So, fixed for mainline. Ok, thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36006
[Bug tree-optimization/36034] [4.3/4.4 Regression] wrong code vectorizing unrolled inner loop (SLP)
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-04-24 14:22 --- Subject: Bug 36034 Author: rguenth Date: Thu Apr 24 14:21:45 2008 New Revision: 134628 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134628 Log: 2008-04-24 Ira Rosen [EMAIL PROTECTED] Richard Guenther [EMAIL PROTECTED] PR tree-optimization/36034 * tree-vect-analyze.c (vect_analyze_group_access): SLP is incapable of dealing with loads with gaps. * gcc.c-torture/execute/pr36034-1.c: New testcase. * gcc.c-torture/execute/pr36034-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr36034-1.c trunk/gcc/testsuite/gcc.c-torture/execute/pr36034-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-analyze.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36034
[Bug middle-end/36036] New: gcc emits warnings/notes from system headers.
attached tarball contains small boost-1.35 based source and preprocessed file. $ make ii /local/devel/toolchain43/x86_64-gnu-linux/bin/x86_64-gnu-linux-g++ -c \ -pthread -Wall -O2 --save-temps \ -isystem ~/dvm/trunk/buildenv/linux/gcc-4.3/64/STLport-5.1.5/include/stlport \ -isystem ~/dvm/trunk/buildenv/linux/gcc-4.3/64/boost-stdc++-1.35.0/include \ 2.cpp /ahome/pawels/dvm/trunk/buildenv/linux/gcc-4.3/64/boost-stdc++-1.35.0/include/boost/lexical_cast.hpp: In function 'Target boost::detail::lexical_cast(typename boost::call_traitsSource::param_type, CharT*, size_t) [with Target = int, Source = stlp_std::basic_stringchar, stlp_std::char_traitschar, stlp_std::allocatorchar , bool Unlimited = false, CharT = boost::lexical_cast::char_type]': /ahome/pawels/dvm/trunk/buildenv/linux/gcc-4.3/64/boost-stdc++-1.35.0/include/boost/lexical_cast.hpp:1147: warning: 'result' may be used uninitialized in this function /ahome/pawels/dvm/trunk/buildenv/linux/gcc-4.3/64/boost-stdc++-1.35.0/include/boost/lexical_cast.hpp:1147: note: 'result' was declared here -isystem should suppress all this magic diagnostics for boost headers. ps). you can locate the 'result' by searching '# 1146' in .ii file. gcc-4.3-20080417. -- Summary: gcc emits warnings/notes from system headers. Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net GCC target triplet: x86_64-gnu-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36036
[Bug middle-end/36036] gcc emits warnings/notes from system headers.
--- Comment #1 from pluto at agmk dot net 2008-04-24 14:37 --- Created an attachment (id=15525) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15525action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36036
[Bug middle-end/36037] New: [4.4 regression] segfault in gt_ggc_mx_dw_loc_descr_struct
Downloading the code at
http://www.pci.unizh.ch/vandevondele/tmp/all_cp2k_gfortran.f90.gz,
uncompressing it and compiling it with mainline GCC on x86_64-linux at -O2 -g
gives:
Program received signal SIGSEGV, Segmentation fault.
0x0053f99d in gt_ggc_mx_dw_loc_descr_struct (x_p=0x2aaae3061fa0)
at ./gt-dwarf2out.h:214
warning: Source file is more recent than executable.
214 if (ggc_test_and_set_mark (x))
(gdb) p x
$1 = (struct dw_loc_descr_struct * const) 0x2aaae3061fa0
(gdb) p *x
$2 = {dw_loc_next = 0x0, dw_loc_opc = DW_OP_ne, dw_loc_oprnd1 = {
val_class = dw_val_class_unsigned_const, v = {val_addr = 0x0,
val_offset = 0, val_loc_list = 0x0, val_loc = 0x0, val_int = 0,
val_unsigned = 0, val_long_long = {hi = 0, low = 0}, val_vec = {
array = 0x0, length = 0, elt_size = 0}, val_die_ref = {die = 0x0,
external = 0}, val_fde_index = 0, val_str = 0x0, val_lbl_id = 0x0,
val_flag = 0 '\0', val_file = 0x0}}, dw_loc_oprnd2 = {
val_class = dw_val_class_unsigned_const, v = {val_addr = 0x0,
val_offset = 0, val_loc_list = 0x0, val_loc = 0x0, val_int = 0,
val_unsigned = 0, val_long_long = {hi = 0, low = 0}, val_vec = {
array = 0x0, length = 0, elt_size = 0}, val_die_ref = {die = 0x0,
external = 0}, val_fde_index = 0, val_str = 0x0, val_lbl_id = 0x0,
val_flag = 0 '\0', val_file = 0x0}}, dw_loc_addr = 0}
(gdb) bt
#0 0x0053f99d in gt_ggc_mx_dw_loc_descr_struct (x_p=0x2aaae3061fa0)
at ./gt-dwarf2out.h:214
#1 0x0053f9b5 in gt_ggc_mx_dw_loc_descr_struct (x_p=0x2aaae3061f50)
at ./gt-dwarf2out.h:216
#2 0x0053f9b5 in gt_ggc_mx_dw_loc_descr_struct (x_p=0x2aaae3061f00)
at ./gt-dwarf2out.h:216
#3 0x0053f9b5 in gt_ggc_mx_dw_loc_descr_struct (x_p=0x2aaae3061eb0)
at ./gt-dwarf2out.h:216
#4 0x0053fd03 in gt_ggc_mx_VEC_dw_attr_node_gc (
x_p=value optimized out) at ./gt-dwarf2out.h:96
#5 0x0053fd4d in gt_ggc_mx_die_struct (x_p=0x2aaae305c8a0)
at ./gt-dwarf2out.h:361
#6 0x0047ed4d in gt_ggc_mx_lang_tree_node (x_p=value optimized out)
at ./gt-fortran-f95-lang.h:325
#7 0x0047e9db in gt_ggc_mx_lang_tree_node (x_p=value optimized out)
at ./gt-fortran-f95-lang.h:333
The exact command-line used is ./f951 -fmem-report all_cp2k_gfortran.f90 -O2
-g. Probably a middle-end or garbage collection issue as it goes fine with
-O0.
I'm not sure whether this passes for GCC 4.3.0, but I know it used to pass
before 4.4 was branched off.
--
Summary: [4.4 regression] segfault in
gt_ggc_mx_dw_loc_descr_struct
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
GCC build triplet: x86_64-unknown-linux-gnu
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=36037
[Bug libstdc++/35968] nth_element fails to meet its complexity requirements
--- Comment #5 from roger at eyesopen dot com 2008-04-24 15:01 --- Well, I've now had time to read the Barriato, Hofri et al. 2002 paper, and the bad news is that such an approximate median selection algorithm can't be used to guarantee an O(N) worst-case std::nth_element implementation. It could be used in an implementation to guess a good pivot, but the quality of this median, i.e. how approximate it is, doesn't meet the necessary criterion to ensure an O(N) worst case. You'd still need a fallback method with guaranteed bounds or an exact median in order to achieve O(N). i.e. it could help improve the average case performance, but doesn't help with the worst case. For the mathematically inclined, in order to achieve an O(N) worst-case performance, you need to guarantee a constant fraction of elements can be eliminated at each level of the recursion. In comment #4, Steven fixates on just as long as N/2 elements are reduced each time round, but the equations for sum of geometric series show that doing better than any constant fraction guarantees O(N) worst case. Hence even if you only guarantee that you can eliminate 10% each round, you still achieve O(N) worst-case. Hence you need a method that provides an approximate median that worst-case can guarantee elimination of say 10% of elements from consideration. This is why approximate medians offer some utility over exact medians if they can be found faster. Unfortunately, the method of Battiato referenced in comment #1 doesn't provide such a constant fraction guarantee. An analysis shows that at each round, it can only eliminate (2^n-1)/3^n of the elements in its worst case, where n is log_3(N). By hand, naming the ranks 0..N-1, when N=3, the true median at rank 1 is selected. For N=9, the elements at rank 3,4 or 5 may be considered as a median, i.e. 1/3 eliminated. For N=27, the elements between ranks 8 and 20 may be returned as the median, i.e. 7/27 eliminated. In the limit, as N tends towards infinity (and n tends to infinity), the eliminated fraction (2^n-1)/3^n tends to zero unbounded. i.e. the larger the input size the less useful is the worst-case median. The poor quality of the median is lamented by the authors in the penultimate paragraph of section 4.1 of the paper. They then go on to show that statistically such a worst-case is rare, but unfortunately even a rare worst case breaks the C++ standard libraries O(N) constraint. This Achilles heel is already well documented in the algorithmic complexity community. The Blum, Floyd, Pratt, Rivest and Trarjan paper [BFRT73] and the Floyd and Rivest paper [FR75] analyse the issues with median-of-k-medians, and show that k=5 is the lowest value capable of guaranteed fractional worst case. i.e. they already consider and reject the algorithm given in the cited work (k=3) for the purpose of exact median finding. Anyway, I hope you find this interesting. There will always be efficient methods for finding approximate medians. The question is how efficient vs. how approximate. Many quicksort implementation select the first element as a pivot, an O(1) method for selecting an extremely approximate median! Statistically over all possible input orders, this first element will on average partition the input array at the median, with some variance. It's not that the paper is wrong or incorrect; it does what it describes in finding a statistically good approximate median very efficiently with excellent worst case performance. Unfortunately for the problem we need to solve, which is not the problem the paper's authors were attempting to solve, we need a better approximation perhaps using a more complex implementation. Anyway, thanks again for the reference. I'd not come across it before and really enjoyed reading it. Let me know if you spot a flaw in my reasoning above. Dr Roger Sayle, Ph.D. Computer Science -- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35968
[Bug c/28575] misleading __builtin_choose_expr documentation error
--- Comment #3 from vincent at vinc17 dot org 2008-04-24 15:04 --- Is there any reason why this hasn't been fixed yet? (The trunk still has the error. And I'm asking this because there's only one word to change.) -- vincent at vinc17 dot org changed: What|Removed |Added CC||vincent at vinc17 dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28575
[Bug tree-optimization/36034] [4.3/4.4 Regression] wrong code vectorizing unrolled inner loop (SLP)
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-04-24 15:18 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36034
[Bug tree-optimization/36034] [4.3/4.4 Regression] wrong code vectorizing unrolled inner loop (SLP)
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-04-24 15:19 --- Subject: Bug 36034 Author: rguenth Date: Thu Apr 24 15:18:19 2008 New Revision: 134631 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134631 Log: 2008-04-24 Ira Rosen [EMAIL PROTECTED] Richard Guenther [EMAIL PROTECTED] PR tree-optimization/36034 * tree-vect-analyze.c (vect_analyze_group_access): SLP is incapable of dealing with loads with gaps. * gcc.c-torture/execute/pr36034-1.c: New testcase. * gcc.c-torture/execute/pr36034-2.c: Likewise. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/pr36034-1.c - copied unchanged from r134628, trunk/gcc/testsuite/gcc.c-torture/execute/pr36034-1.c branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/pr36034-2.c - copied unchanged from r134628, trunk/gcc/testsuite/gcc.c-torture/execute/pr36034-2.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/tree-vect-analyze.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36034
[Bug ada/32181] Legal program executes incorrectly, RM 3.4(27)
--- Comment #7 from anhvofrcaus at gmail dot com 2008-04-24 15:37 --- Samuel and Ludovic, You both are right that GNAT has a bug, and the original test code was a good one. In fact, Pak2.Eq(Z1, Z2) would return True if GNAT worked correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32181
[Bug target/27234] no way to stop gcc from mucking with the incoming argument stack on ia32
--- Comment #19 from hubicka at gcc dot gnu dot org 2008-04-24 16:05 --- I am going to make patch that will with preserve-stack attribute in addition to inhibitting libcall also put REG_EQUIV notes on a copy instead of argument register itself that should be sufficient to prevent reload from re-using the slot. I think we need to add a temporary register with REG_EQUIV note that will be copypropagated if argument is read only (or to read only parts) so rematerialization works. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27234
[Bug tree-optimization/36008] [4.3/4.4 Regression] Function produces wrong results when inlined.
--- Comment #14 from jakub at gcc dot gnu dot org 2008-04-24 16:08 --- Subject: Bug 36008 Author: jakub Date: Thu Apr 24 16:08:11 2008 New Revision: 134634 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134634 Log: PR tree-optimization/36008 * fold-const.c (try_move_mult_to_index): If s == NULL, divide the original op1, rather than delta by step. * gcc.c-torture/execute/20080424-1.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/20080424-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36008
[Bug tree-optimization/36008] [4.3/4.4 Regression] Function produces wrong results when inlined.
--- Comment #15 from jakub at gcc dot gnu dot org 2008-04-24 16:20 --- Subject: Bug 36008 Author: jakub Date: Thu Apr 24 16:19:22 2008 New Revision: 134636 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134636 Log: PR tree-optimization/36008 * fold-const.c (try_move_mult_to_index): If s == NULL, divide the original op1, rather than delta by step. * gcc.c-torture/execute/20080424-1.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/20080424-1.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/fold-const.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36008
[Bug c++/35758] [4.3/4.4 Regression] vector_size attribute lost in function arguments for templates
--- Comment #17 from jakub at gcc dot gnu dot org 2008-04-24 16:30 --- Subject: Bug 35758 Author: jakub Date: Thu Apr 24 16:29:40 2008 New Revision: 134639 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134639 Log: PR c++/35758 * c-common.c (handle_vector_size_attribute): Call lang_hooks.types.reconstruct_complex_type instead of reconstruct_complex_type. * config/rs6000/rs6000.c (rs6000_handle_altivec_attribute): Likewise. * config/spu/spu.c (spu_handle_vector_attribute): Likewise. * langhooks.h (struct lang_hooks_for_types): Add reconstruct_complex_type hook. * langhooks-def.h (LANG_HOOKS_RECONSTRUCT_COMPLEX_TYPE): Define. (LANG_HOOKS_FOR_TYPES_INITIALIZER): Add it. * cp-tree.h (cp_reconstruct_complex_type): New prototype. * cp-objcp-common.h (LANG_HOOKS_RECONSTRUCT_COMPLEX_TYPE): Define. * decl2.c (is_late_template_attribute): Only make vector_size late tmpl attribute if argument is type or value dependent. (cp_reconstruct_complex_type): New function. * g++.dg/ext/vector14.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/vector14.C Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/spu/spu.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-objcp-common.h trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl2.c trunk/gcc/langhooks-def.h trunk/gcc/langhooks.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35758
[Bug c++/35758] [4.3/4.4 Regression] vector_size attribute lost in function arguments for templates
--- Comment #18 from jakub at gcc dot gnu dot org 2008-04-24 16:32 --- Subject: Bug 35758 Author: jakub Date: Thu Apr 24 16:31:59 2008 New Revision: 134640 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134640 Log: PR c++/35758 * c-common.c (handle_vector_size_attribute): Call lang_hooks.types.reconstruct_complex_type instead of reconstruct_complex_type. * config/rs6000/rs6000.c (rs6000_handle_altivec_attribute): Likewise. * config/spu/spu.c (spu_handle_vector_attribute): Likewise. * langhooks.h (struct lang_hooks_for_types): Add reconstruct_complex_type hook. * langhooks-def.h (LANG_HOOKS_RECONSTRUCT_COMPLEX_TYPE): Define. (LANG_HOOKS_FOR_TYPES_INITIALIZER): Add it. * cp-tree.h (cp_reconstruct_complex_type): New prototype. * cp-objcp-common.h (LANG_HOOKS_RECONSTRUCT_COMPLEX_TYPE): Define. * decl2.c (is_late_template_attribute): Only make vector_size late tmpl attribute if argument is type or value dependent. (cp_reconstruct_complex_type): New function. * g++.dg/ext/vector14.C: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/ext/vector14.C Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/c-common.c branches/gcc-4_3-branch/gcc/config/rs6000/rs6000.c branches/gcc-4_3-branch/gcc/config/spu/spu.c branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/cp-objcp-common.h branches/gcc-4_3-branch/gcc/cp/cp-tree.h branches/gcc-4_3-branch/gcc/cp/decl2.c branches/gcc-4_3-branch/gcc/langhooks-def.h branches/gcc-4_3-branch/gcc/langhooks.h branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35758
[Bug tree-optimization/36008] [4.3/4.4 Regression] Function produces wrong results when inlined.
--- Comment #16 from jakub at gcc dot gnu dot org 2008-04-24 16:32 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36008
[Bug testsuite/36035] [4.4 Regression]: FAIL: gcc.dg/vect/vect-vfa-slp.c
--- Comment #2 from sje at gcc dot gnu dot org 2008-04-24 16:37 --- Subject: Bug 36035 Author: sje Date: Thu Apr 24 16:37:05 2008 New Revision: 134641 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134641 Log: PR testsuite/36035 * gcc.dg/vect/vect-vfa-slp.c: Remove bad check. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect-vfa-slp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36035
[Bug libstdc++/35954] [4.3/4.4 Regression] cannot build from read-only source tree
--- Comment #4 from bkoz at gcc dot gnu dot org 2008-04-24 16:56 --- Fixed on trunk and gcc-4_3-branch -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35954
[Bug libstdc++/35597] libstdc++ -ffunction-sections -fdata-sections disabled on AIX
--- Comment #7 from bkoz at gcc dot gnu dot org 2008-04-24 16:58 --- Second ping. David, I'm setting the target milestone to 4.3.1 for this. Can you please check in your patch to gcc-4_3-branch? -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35597
[Bug libstdc++/35969] GLIBCXX_DEBUG: list::merge triggers bad assert
--- Comment #7 from paolo at gcc dot gnu dot org 2008-04-24 17:03 --- Subject: Bug 35969 Author: paolo Date: Thu Apr 24 17:03:13 2008 New Revision: 134642 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134642 Log: 2008-04-24 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/35969 * include/debug/list (merge): Use _M_transfer_iter, consistently with the splice members. * testsuite/23_containers/list/operations/35969.cc: New. * testsuite/23_containers/list/operators: Rename to testsuite/23_containers/list/operations. Added: trunk/libstdc++-v3/testsuite/23_containers/list/operations/ - copied from r134503, trunk/libstdc++-v3/testsuite/23_containers/list/operators/ trunk/libstdc++-v3/testsuite/23_containers/list/operations/35969.cc Removed: trunk/libstdc++-v3/testsuite/23_containers/list/operators/ Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/debug/list -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35969
[Bug libstdc++/35942] Self Reference In Dynamic Linked Library builds for building Cross-Compiler
--- Comment #1 from bkoz at gcc dot gnu dot org 2008-04-24 17:04 --- Since there is no 4.3.1 release, only 4.3.0, can I assume you mean 4.3.0 for the Reported Against field? libtool issues should be fixed in libtool if possible, and not hacked around in src/Makefile.am. Editing src/Makefile.in is incorrect, as this is a generated file. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Summary|Self Reference In Dinamic |Self Reference In Dynamic |Linked Library builds for |Linked Library builds for |building Cross-Compiler |building Cross-Compiler http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35942
[Bug libstdc++/35969] GLIBCXX_DEBUG: list::merge triggers bad assert
--- Comment #8 from pcarlini at suse dot de 2008-04-24 17:05 --- Fixed for 4.4.0. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35969
[Bug libstdc++/35029] problem with -prefer-pic in comparing stages 2 and 3
--- Comment #4 from bkoz at gcc dot gnu dot org 2008-04-24 17:09 --- Closing as one month without updates, problem report with pre-release compiler. If you can reproduce this with 4.3.0 or current 4_3-branch, please re-open. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35029
[Bug libstdc++/34015] warning in backward_warning.h is illegible
--- Comment #7 from bkoz at gcc dot gnu dot org 2008-04-24 17:27 --- The goal for warnings should be to use an attribute on the specific class or function in question, not on a per-file basis. Unfortunately this does not work at the moment. So, the backwards_warning.h file has been adjusted to make it a bit more clear as to what is going on, and what should be used for deprecated items. Therefore I would like to close or suspend this PR if submitter agrees. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34015
[Bug driver/35916] problem running GCC under Vista with relocated directory
--- Comment #8 from bartoldeman at users dot sourceforge dot net 2008-04-24 17:41 --- I submitted a patch to MinGW to work around the problem (in crt1.o and crt2.o): http://sourceforge.net/tracker/index.phpfunc=detailaid=1951037group_id=2435atid=302435 -- bartoldeman at users dot sourceforge dot net changed: What|Removed |Added CC||bartoldeman at users dot ||sourceforge dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35916
[Bug tree-optimization/36038] New: miscompiled loop in perlbmk for -Os
Test 253.perlbmk from SPEC CPU2000 gets wrong answers with current trunk on powerpc64-unknown-linux-gnu when compiled with -m64 -Os due to wrong code generated for this loop: while (--count) *dst-- = *src--; where dst and src are of type struct sv **. I'll attach a simplified testcase in which dst and src are of type long long *. The failure begins with this patch: http://gcc.gnu.org/viewcvs?view=revrev=133102 r133102 | rguenth | 2008-03-11 09:36:51 + (Tue, 11 Mar 2008) -- Summary: miscompiled loop in perlbmk for -Os Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janis at gcc dot gnu dot org GCC target triplet: powerpc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36038
[Bug tree-optimization/36038] miscompiled loop in perlbmk for -Os
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36038
[Bug tree-optimization/36038] [4.4 Regression] miscompiled loop in perlbmk for -Os
--- Comment #1 from janis at gcc dot gnu dot org 2008-04-24 17:57 --- Created an attachment (id=15526) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15526action=view) test case This testcase fails with current trunk on powerpc64-linux: elm3b187% /opt/gcc-nightly/trunk/bin/gcc -Os -m64 36038.c a.out expected: 0 1 2 3 4 4 5 6 7 9 got: 0 1 2 3 4 5 6 7 7 9 Aborted -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36038
[Bug libstdc++/35597] libstdc++ -ffunction-sections -fdata-sections disabled on AIX
--- Comment #8 from dje at gcc dot gnu dot org 2008-04-24 17:59 --- Subject: Bug 35597 Author: dje Date: Thu Apr 24 17:59:01 2008 New Revision: 134644 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134644 Log: PR libstdc++/35597 * toplev.c (process_options): Remove -ffunction-sections debugging warning. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/toplev.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35597
[Bug libstdc++/35597] libstdc++ -ffunction-sections -fdata-sections disabled on AIX
--- Comment #9 from dje at gcc dot gnu dot org 2008-04-24 18:06 --- Well, I did not receive your second ping. But I was traveling and had been planning to check it in today. -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35597
[Bug c++/35758] vector_size attribute lost in function arguments for templates
--- Comment #19 from jakub at gcc dot gnu dot org 2008-04-24 18:48 --- With the changes checked in, I believe there is no regression anymore, but using vector_size, altivec or spu_vector attributes on template parameters will still do bad and unexpected things. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3/4.4 Regression]|vector_size attribute lost |vector_size attribute lost |in function arguments for |in function arguments for |templates |templates | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35758
[Bug fortran/35892] gfortran lost memory blocks
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2008-04-24 19:05 --- The part that was causing the crash has been reverted. Can you try with current latest trunk version 4.4.0 and see if it really is the silver bullet? and report back here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35892
[Bug fortran/35892] gfortran lost memory blocks
--- Comment #21 from jvdelisle at gcc dot gnu dot org 2008-04-24 19:10 --- Reply to comment #18. I have not had time to dig further on these memory issues. I think after George has a revamped patch in, I will explore some more on this. We are probably just not freeing some memory after it is used. (I hope) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35892
[Bug c++/36012] Wrong initialization in operator new.
--- Comment #3 from s__nakayama at infoseek dot jp 2008-04-24 19:39 --- Sorry, my code is undefined. By 12.1/7, member of foo is not initialized. I -- s__nakayama at infoseek dot jp changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36012
[Bug fortran/35959] Recursive function with allocatable array
--- Comment #10 from michael dot baudin at gmail dot com 2008-04-24 19:55 --- Subject: Re: Recursive function with allocatable array Thank you for fixing the bug. Michaël On Sun, Apr 20, 2008 at 12:32 AM, pault at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #9 from pault at gcc dot gnu dot org 2008-04-19 22:32 --- Fixed on trunk and 4.3. Thanks for the report. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35959
[Bug target/34163] 10% performance regression since Nov 1 on Polyhedron's NF on AMD64
--- Comment #7 from ubizjak at gmail dot com 2008-04-24 19:56 --- Created an attachment (id=15527) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15527action=view) x86_64 asm dump of trisolve procedure (genereated without the patch) All the difference is in trisolve procedure (attached). The performance will be 10% better, if trisolve in the dump is substituted with attached function. I'm using -O2 -funroll-loops. BTW: There are two loops in this asm (.L3 and .L5). In current asm, suspicious parts are: movsd 16(%r9), %xmm6 mulsd 16(%r8), %xmm6 and mulsd -16(%rdx), %xmm0 mulsd -16(%r11), %xmm0 That is - loads from different addresses that are not present in non-patched asm. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34163
[Bug libstdc++/35887] stl parallel includes installed for --disable-libgomp
--- Comment #2 from bkoz at gcc dot gnu dot org 2008-04-24 21:10 --- Mine. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-24 21:10:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35887
[Bug libstdc++/35942] Self Reference In Dynamic Linked Library builds for building Cross-Compiler
--- Comment #2 from bkoz at gcc dot gnu dot org 2008-04-24 21:28 --- instead of AC_LIBTOOL_DLOPEN AM_PROG_LIBTOOL AC_SUBST(enable_shared) AC_SUBST(enable_static) libgomp/acinclude.m4 has sinclude(../libtool.m4) dnl The lines below arrange for aclocal not to bring an installed dnl libtool.m4 into aclocal.m4, while still arranging for automake to dnl add a definition of LIBTOOL to Makefile.in. ifelse(,,,[AC_SUBST(LIBTOOL) AC_DEFUN([AM_PROG_LIBTOOL]) AC_DEFUN([AC_LIBTOOL_DLOPEN]) AC_DEFUN([AC_PROG_LD]) ]) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35942
[Bug regression/36039] New: -ftree-vectorize aborts on simple integer multiply vectorization
The attached source when compiled with -O2 and -ftree-vectorize aborts with a gcc internal compiler error. It aborts in expand_simple_binop which is given VEC_SELECT as the code to expand. Both GCC 4.1 and GCC 4.3 compiles this fine, and expand_simple_binop is not called for the VEC_SELECT case in 4.3. Here is a debug trace: The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /data-gold1/fsf-build/gcc-4_2-branch/gcc/cc1 -O2 -ftree-vectorize bug.c vectorized_mult_vector_sign_int Analyzing compilation unitPerforming interprocedural optimizations Assembling functions: vectorized_mult_vector_sign_int Breakpoint 3, During symbol reading, incomplete CFI data; unspecified registers (e.g., rax) at 0x6a8437. During symbol reading, incomplete CFI data; unspecified registers (e.g., rdx) at 0x6a8437. During symbol reading, incomplete CFI data; unspecified registers (e.g., rcx) at 0x6a8437. During symbol reading, incomplete CFI data; unspecified registers (e.g., rbx) at 0x6a8437. During symbol reading, incomplete CFI data; unspecified registers (e.g., rsi) at 0x6a8437. During symbol reading, incomplete CFI data; unspecified registers (e.g., rdi) at 0x6a8437. During symbol reading, incomplete CFI data; unspecified registers (e.g., rbp) at 0x6a8437. During symbol reading, incomplete CFI data; unspecified registers (e.g., r8) at 0x6a8437. During symbol reading, incomplete CFI data; unspecified registers (e.g., r9) at 0x6a8437. During symbol reading, incomplete CFI data; unspecified registers (e.g., r10) at 0x6a8437. During symbol reading, incomplete CFI data; unspecified registers (e.g., r11) at 0x6a8437. During symbol reading, incomplete CFI data; unspecified registers (e.g., r12) at 0x6a8437. During symbol reading, incomplete CFI data; unspecified registers (e.g., r13) at 0x6a8437. During symbol reading, incomplete CFI data; unspecified registers (e.g., r14) at 0x6a8437. During symbol reading, incomplete CFI data; unspecified registers (e.g., r15) at 0x6a8437. expand_simple_binop (mode=DImode, code=PLUS, op0=0x2f76e540, op1=0x2f76e520, target=0x0, unsignedp=1, methods=OPTAB_LIB_WIDEN) at /proj/gcc/fsf-src/gcc-4_2-branch/gcc/optabs.c:1156 (gdb) c Continuing. Breakpoint 3, expand_simple_binop (mode=SImode, code=PLUS, op0=0x2f76e720, op1=0x2f76e700, target=0x0, unsignedp=1, methods=OPTAB_LIB_WIDEN) at /proj/gcc/fsf-src/gcc-4_2-branch/gcc/optabs.c:1156 (gdb) c Continuing. Breakpoint 3, expand_simple_binop (mode=V2SImode, code=VEC_SELECT, op0=0x2f777ae0, op1=0x2f76c640, target=0x0, unsignedp=1, methods=OPTAB_LIB_WIDEN) at /proj/gcc/fsf-src/gcc-4_2-branch/gcc/optabs.c:1156 (gdb) c Continuing. Breakpoint 1, fancy_abort (file=0x8eaf60 /proj/gcc/fsf-src/gcc-4_2-branch/gcc/optabs.c, line=1157, function=0x8eaee0 expand_simple_binop) at /proj/gcc/fsf-src/gcc-4_2-branch/gcc/diagnostic.c:640 (gdb) r The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /data-gold1/fsf-build/gcc-4_2-branch/gcc/cc1 -O2 -ftree-vectorize bug.c vectorized_mult_vector_sign_int Analyzing compilation unitPerforming interprocedural optimizations Assembling functions: vectorized_mult_vector_sign_int Breakpoint 3, During symbol reading, incomplete CFI data; unspecified registers (e.g., rax) at 0x6a8437. During symbol reading, incomplete CFI data; unspecified registers (e.g., rdx) at 0x6a8437. During symbol reading, incomplete CFI data; unspecified registers (e.g., rcx) at 0x6a8437. During symbol reading, incomplete CFI data; unspecified registers (e.g., rbx) at 0x6a8437. During symbol reading, incomplete CFI data; unspecified registers (e.g., rsi) at 0x6a8437. During symbol reading, incomplete CFI data; unspecified registers (e.g., rdi) at 0x6a8437. During symbol reading, incomplete CFI data; unspecified registers (e.g., rbp) at 0x6a8437. During symbol reading, incomplete CFI data; unspecified registers (e.g., r8) at 0x6a8437. During symbol reading, incomplete CFI data; unspecified registers (e.g., r9) at 0x6a8437. During symbol reading, incomplete CFI data; unspecified registers (e.g., r10) at 0x6a8437. During symbol reading, incomplete CFI data; unspecified registers (e.g., r11) at 0x6a8437. During symbol reading, incomplete CFI data; unspecified registers (e.g., r12) at 0x6a8437. During symbol reading, incomplete CFI data; unspecified registers (e.g., r13) at 0x6a8437. During symbol reading, incomplete CFI data; unspecified registers (e.g., r14) at 0x6a8437. During symbol reading, incomplete CFI data; unspecified registers (e.g., r15) at 0x6a8437. expand_simple_binop (mode=DImode, code=PLUS, op0=0x2f76e540, op1=0x2f76e520, target=0x0, unsignedp=1, methods=OPTAB_LIB_WIDEN) at /proj/gcc/fsf-src/gcc-4_2-branch/gcc/optabs.c:1156 (gdb) c Continuing. Breakpoint 3, expand_simple_binop (mode=SImode, code=PLUS, op0=0x2f76e720, op1=0x2f76e700, target=0x0, unsignedp=1, methods=OPTAB_LIB_WIDEN) at
[Bug regression/36039] -ftree-vectorize aborts on simple integer multiply vectorization
--- Comment #1 from gnu at the-meissners dot org 2008-04-24 21:49 --- Created an attachment (id=15528) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15528action=view) This is the test case that fails. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36039
[Bug fortran/35156] [patch] Deprecate -Mdir
--- Comment #1 from dfranke at gcc dot gnu dot org 2008-04-24 22:01 --- Updated patch: http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01871.html -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35156
[Bug c/36040] New: Using %rsi instead of %esi for a u32 in generated code
I've recently run into a problem with some linux KVM code that may be a bug in
gcc-4.3.0. I'm building the KVM modules on Fedora 9 x86_64, with gcc --version
reporting:
[EMAIL PROTECTED] kvm-userspace]# gcc --version
gcc (GCC) 4.3.0 20080416 (Red Hat 4.3.0-7)
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
The code in question is as follows:
static int svm_get_msr(struct kvm_vcpu *vcpu, unsigned ecx, u64 *data)
{
struct vcpu_svm *svm = to_svm(vcpu);
switch (ecx) {
...
case MSR_K7_EVNTSEL0:
case MSR_K7_EVNTSEL1:
case MSR_K7_EVNTSEL2:
case MSR_K7_EVNTSEL3:
printk(KERN_ALERT ecx is 0x%lx\n, ecx);
/*
* only support writing 0 to the performance counters for now
* to make Windows happy. Should be replaced by a real
* performance counter emulation later.
*/
if (data != 0)
goto unhandled;
break;
default:
unhandled:
return kvm_set_msr_common(vcpu, ecx, data);
}
return 0;
}
The *intent* of the code is to call kvm_set_msr_common if and only if our
MSR_K7_EVNTSEL{0,3} case statement fired, and data was not 0; otherwise we
should just break out of here and return 0. Unfortunately, that's not what's
actually happening; what's happening is that we are calling
kvm_set_msr_common(), regardless of the state of data.
Disassembling the code around here with objdump -Sr shows this:
1803: 81 fe 02 01 00 c0 cmp$0xc102,%esi
1809: 74 6c je 1877 svm_set_msr+0xf4
180b: 0f 82 f1 01 00 00 jb 1a02 svm_set_msr+0x27f
1811: 8d 86 00 00 ff 3f lea0x3fff(%rsi),%eax
1817: 83 f8 03cmp$0x3,%eax
181a: 0f 87 e2 01 00 00 ja 1a02 svm_set_msr+0x27f
1820: e9 d8 01 00 00 jmpq 19fd svm_set_msr+0x27a
What you can see for the first cmp here, we properly use the unsigned ecx
argument, which is a 32-bit quantity in %esi (based on the x86_64 calling
convention). However, when we make it down to the lea instruction, we actually
use %rsi, which seems wrong, since it seems like there could be garbage in the
upper 32-bits of the register, causing the resulting ja to fire erroneously.
I have a test case at http://people.redhat.com/clalance/rsi-test-case.tar.bz2 ;
unfortunately I was never able to reproduce the unexpected behavior in this
userland testcase, but if you compile that code and look at the disassembly,
you can see the problem.
The flags used to compile the code is in the tarball above, but just for
completeness they are:
-Wp,-MD,/root/testcase.o.d -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Os
-fno-stack-protector -m64 -mtune=generic -mno-red-zone -mcmodel=kernel
-funit-at-a-time -maccumulate-outgoing-args -pipe -Wno-sign-compare
-fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow
-fno-omit-frame-pointer -fno-optimize-sibling-calls -g
-Wdeclaration-after-statement -Wno-pointer-sign
--
Summary: Using %rsi instead of %esi for a u32 in generated code
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: clalance at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36040
[Bug target/36040] Using %rsi instead of %esi for a u32 in generated code
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-24 22:26 --- Using %rsi some times is ok, as the 32bit instructions zero extend the values into the extended registers. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36040
[Bug tree-optimization/36039] [4.2 Regression] -ftree-vectorize aborts on simple integer multiply vectorization
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|regression |tree-optimization Known to fail||4.1.0 Known to work||4.3.0 4.4.0 Summary|-ftree-vectorize aborts on |[4.2 Regression] -ftree- |simple integer multiply |vectorize aborts on simple |vectorization |integer multiply ||vectorization Target Milestone|--- |4.2.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36039
[Bug libstdc++/35887] stl parallel includes installed for --disable-libgomp
--- Comment #3 from bkoz at gcc dot gnu dot org 2008-04-24 23:31 --- Subject: Bug 35887 Author: bkoz Date: Thu Apr 24 23:30:10 2008 New Revision: 134649 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134649 Log: 2008-04-24 Benjamin Kosnik [EMAIL PROTECTED] PR libstdc++/35887 * configure.ac: Add default argument to GLIBCXX_ENABLE_PARALLEL. Move atomic warnings to GLIBCXX_ENABLE_ATOMIC_BUILTINS. * acinclude.m4 (GLIBCXX_ENABLE_PARALLEL): Check for --disable-libgomp. (GLIBCXX_ENABLE_ATOMIC_BUILTINS): Add warning information. * configure: Regenerate. * include/Makefile.am (parallel_headers): Make conditional on ENABLE_PARALLEL. * include/Makefile.in: Regenerate. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/configure trunk/libstdc++-v3/configure.ac trunk/libstdc++-v3/include/Makefile.am trunk/libstdc++-v3/include/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35887
[Bug libstdc++/35887] stl parallel includes installed for --disable-libgomp
--- Comment #4 from bkoz at gcc dot gnu dot org 2008-04-24 23:35 --- Fixed on trunk, gcc-4_3-branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35887
[Bug libstdc++/35922] std::unordered_map missing in debug mode
--- Comment #4 from bkoz at gcc dot gnu dot org 2008-04-24 23:35 --- Fixed. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35922
[Bug libstdc++/35887] stl parallel includes installed for --disable-libgomp
--- Comment #5 from bkoz at gcc dot gnu dot org 2008-04-24 23:36 --- Subject: Bug 35887 Author: bkoz Date: Thu Apr 24 23:35:22 2008 New Revision: 134650 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134650 Log: 2008-04-24 Benjamin Kosnik [EMAIL PROTECTED] PR libstdc++/35887 * configure.ac: Add default argument to GLIBCXX_ENABLE_PARALLEL. * acinclude.m4 (GLIBCXX_ENABLE_PARALLEL): Check for --disable-libgomp. * configure: Regenerate. * include/Makefile.am (parallel_headers): Make conditional on ENABLE_PARALLEL. * include/Makefile.in: Regenerate. Modified: branches/gcc-4_3-branch/libstdc++-v3/ChangeLog branches/gcc-4_3-branch/libstdc++-v3/acinclude.m4 branches/gcc-4_3-branch/libstdc++-v3/configure branches/gcc-4_3-branch/libstdc++-v3/configure.ac branches/gcc-4_3-branch/libstdc++-v3/include/Makefile.am branches/gcc-4_3-branch/libstdc++-v3/include/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35887
[Bug libstdc++/35922] std::unordered_map missing in debug mode
--- Comment #5 from bkoz at gcc dot gnu dot org 2008-04-24 23:36 --- Ack! Wrong bug. But, I accept and re-open. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35922
[Bug libstdc++/35922] std::unordered_map missing in debug mode
-- bkoz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|REOPENED|ASSIGNED Last reconfirmed|2008-04-13 15:17:10 |2008-04-24 23:36:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35922
[Bug libstdc++/35887] stl parallel includes installed for --disable-libgomp
--- Comment #6 from bkoz at gcc dot gnu dot org 2008-04-24 23:37 --- Fixed. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35887
[Bug libstdc++/35968] nth_element fails to meet its complexity requirements
--- Comment #6 from bkoz at gcc dot gnu dot org 2008-04-24 23:39 --- Can I re-classify this as an enhancement? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35968
Invite
Hello, Ezt a levelet azert kapod mert 'MurvaiP' nevu tagunk szeretne meghivni tagjaink koze. O mar minden bizonnyal ismertetett a dolgok mikentjenek a hogyanjarol, de azert elkuldjuk mi is az adatokat. Tehat eloszor is a lenyeg, a tartalomrol: A site pillanatnyi tartalmat a kovetkezo 48 oraban barmikor megtekintheted az alabbi cimen, (utanna megszunik es uj meghivot kell kerned): http://list.subshark.net A jelenleg valaszthato dijcsomagok es a hozzajuk tartozo letoltesi sebessegek: - 2000ft: 133Kbyte/sec - 2500ft: 200kbyte/sec - 3000ft: 600kbyte/sec - 5000ft: 1250kbyte/sec Minden csomag atalanydijas, ami azt jelenti hogy egy befizetes 30 napos elerest biztosit az adott sebesseggel napi 24 oraban. Nincs semmilyen letoltesi korlat. Elofizetesi lehetosegek: - Atutalas - Postai csekken torteno befizetes, amin keresztul anonimitast is tudunk szamodra biztositani. - Keszpenzbefizetes bankban - SMSben nem lehet elofizetni :) Ha visszaigazolod elofizetesi szandekod az [EMAIL PROTECTED] email cimen, elkuldjuk szamodra az elofizeteshez szukseges informaciokat. Amennyiben megsem kivanod igenybe venni a szolgaltatast, semmi teendod, egyszeruen torold a levelet. Ha nem jon valasz a meghivo egy het utan torlodik. Ennyi a lenyeg, ha egyeb kerdesed lenne irj a fenti email cimre, es/vagy fordulj a teged ajanlo tagunkhoz. Udvozlettel: Subshark team. -- Ha ezt a levelet elozetes egyeztetes nelkul kaptad, tehat nem kertel meghivot, plz jelezd ezt nekunk. (Klikk ide: http://list.subshark.net/report.php?name=MurvaiP )
[Bug c/36041] New: Speed up builtin_popcountll
The current __builtin_popcountll (and likely __builtin_popcount) are fairly
slow as compared to a simple, short C version derived from what can be found in
Knuth's recent publications. The following short function is about 3x as fast
as the __builtin version, which runs counter to the idea that __builtin_XXX
provides access to implementations that are exemplars for a given platform.
unsigned int popcount64(unsigned long long x)
{
x = (x 0xULL) + ((x 1) 0xULL);
x = (x 0xULL) + ((x 2) 0xULL);
x = (x 0x0F0F0F0F0F0F0F0FULL) + ((x 4) 0x0F0F0F0F0F0F0F0FULL);
return (x * 0x0101010101010101ULL) 56;
}
This version has the additional benefit that it omits the lookup table that the
current builtin version uses.
I measured the above function vs. __builtin_popcountll with a loop like the
following:
t1 = clock();
for (j = 0; j 100; j++)
for (i = 0; i 1024; i++)
pt = popcount64(data[i]);
t2 = clock();
printf(popcount64 = %d clocks\n, t2 - t1);
...where data[] is a u64 that's preinitialized.
I'll attach the exact source I used, which also includes two other possible
implementations of popcountll.
--
Summary: Speed up builtin_popcountll
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: intvnut at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
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=36041
[Bug c/36041] Speed up builtin_popcountll
--- Comment #1 from intvnut at gmail dot com 2008-04-25 00:36 --- Created an attachment (id=15529) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15529action=view) Popcount sample implementations These implementations are derived from insights in Henry S. Warren's Hacker's Delight and Knuth's recent fascicle regarding boolean tips and tricks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36041
[Bug middle-end/36041] Speed up builtin_popcountll
--- Comment #2 from intvnut at gmail dot com 2008-04-25 00:39 --- When run on my Opteron 280 system, the four separate implementations give the following run times: popcount64_1 = 1313 clocks popcount64_2 = 648 clocks popcount64_3 = 374 clocks popcount64_4 = 549 clocks As one can see, the popcount64_3 implementation is over 3.5x the speed of the __builtin_popcountll implementation. -- intvnut at gmail dot com changed: What|Removed |Added CC||intvnut at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36041
[Bug libstdc++/29367] pb_ds hash containers vs. _GLIBCXX_DEBUG
--- Comment #4 from bkoz at gcc dot gnu dot org 2008-04-25 01:03 --- Fixed. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29367
[Bug fortran/35673] ldist-1.f90 fails on amd64/FC8 with latest trunk
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-04-25 01:48 --- I think this is fixed. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35673
[Bug c/36042] New: cast from const void * into void * produces a warning
I created the following test code:
int x;
inline myfun (void*m)
{
x = *(int *)m;
}
int
bar (const void *p)
{
myfun ((void *)p);
}
If I compile it as:
gcc -c test.c
I don't get a warning. However:
gcc -O -c test.c
produces the following:
test.c: In function bar:
test.c:9: warning: passing argument 1 of myfun discards qualifiers from
pointer target type
It seems that this error is affected by inlining of myfun. I checked the gcc
head version and warning does not appear there. 4.1.2 also does not have it.
--
Summary: cast from const void * into void * produces a
warning
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nenad at intrepid dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36042
[Bug fortran/35993] [4.3/4.4 regression] wrong answer for PRODUCT with scalar mask
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-04-25 04:36 --- I am working on this. -- 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-04-20 21:02:20 |2008-04-25 04:36:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35993
[Bug c/36042] cast from const void * into void * produces a warning
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-25 05:09 --- Fixed in 4.3.0 already, almost won't be fixed in 4.2.x. *** This bug has been marked as a duplicate of 29478 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36042
[Bug middle-end/29478] [4.2 Regression] optimization generates warning for casts
--- Comment #31 from pinskia at gcc dot gnu dot org 2008-04-25 05:09 --- *** Bug 36042 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||nenad at intrepid dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29478
[Bug other/36030] Throwing exceptions in multiple threads leads to spinning in call to _Unwind_Find_FDE
--- Comment #5 from an at atrn dot org 2008-04-25 05:27 --- Which glibc version do you use? As per description it's FreeBSD 7's (aka STABLE) libc who's ld.so implementation uses gcc's glibc-specific unwinding. You should probably report this as a bug to your vendor. Done with patch to fix it. http://www.freebsd.org/cgi/query-pr.cgi?pr=123062 Thanks for the clarification. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36030
