IS IT A BUG ????
Hi,
The following is the program to print magic squares.I`m getting
wierd output when i remove the printf statement printf(a) from the
code. The required output is obtained by simply substituting that by
putchar('\0'). I would be very glad if someone can let me know.
Please kindly help me regarding this.
Expecting an early rep,
Srujan.K.V.S
//This is a simple program to design magic squares.
//A magic square is an arangment of numbers of numbers from 1 to n^2 such
// that any row, diagonal or column sums to the same. This program wil
//work for only odd sized squares
#includestdio.h
#includestdlib.h
#includemath.h
main() {
int n,x=1,i,j,k,p,r,t;
scanf(%d,n);
printf(%d\n,n);
p=n*n;
int a[n][n];
for(i=0;in;i++)
for(j=0;jn;j++)
a[i][j]=0;
i=0;j=(n-1)/2;
a[i][j]=1;// starting 1 int the first row central column. :)
//We try to put the next number in the top left diagonal square
//from the recent numbered square.
//If we have already numbered , we then number the square just
//below it.
for(k=1;kp;k++)
{
if((i-1)0j!=0a[n-1][j-1]==0) i=n;
if((j-1)0i!=0a[i-1][n-1]==0) j=n;
if(i==0j==0a[n-1][n-1]==0)
{
i=n;j=n;
}
x++;
if(a[i-1][j-1]==0)
{
//The following printf statement if removed is
alering the output when n=5
printf(a);
a[i-1][j-1]=x;
i=i-1;
j=j-1;
}
else
{
if((i+1)(n-1)) i=-1;
a[i+1][j]=x;
i=i+1;
j=j;
}
}
for(i=0;in;i++)
{
for(j=0;jn;j++)
printf(%4d \t,a[i][j]);
printf(\n);
}
}
*
[Bug fortran/24100] New: gfortran cannot compile data statement
Not sure whether this is in the standard or an extentions to it, but it works
with all fortran compilers I
have access to and it fails with gfortran
$ cat bug.f EOF
program bug
parameter (maxdim=5)
dimension a(maxdim,maxdim)
data ((a(j,k),k=1,j),j=1,maxdim) /
+ 1, 2, 3, 4, 5, 6, 7, 8,
+ 9, 10, 11, 12, 13, 14, 15 /
character*20 fmt
*
write(fmt,'(''('',i2.2,''(1x,f5.2))'')') maxdim
do j=1,maxdim
print fmt, (a(j,k),k=1,maxdim)
enddo
end
EOF
$ gfortran -o bug bug.f
In file bug.f:4
data ((a(j,k),k=1,j),j=1,maxdim) /
1
Error: Variable 'j' at (1) cannot appear in an initialization expression
--
Summary: gfortran cannot compile data statement
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: federico dot carminati at cern dot ch
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: Darwin 8.2.0 powerpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24100
[Bug fortran/24100] gfortran cannot compile data statement
-- What|Removed |Added CC||alfredo dot ferrari at cern ||dot ch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24100
[Bug target/22497] A register is wasted in simple vectorised loops
--- Additional Comments From uros at kss-loka dot si 2005-09-28 08:14 --- The problem was fixed by the patch for PR 18463: http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01159.html -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22497
[Bug target/22497] A register is wasted in simple vectorised loops
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22497
[Bug fortran/24092] ICE in trans-types.c for nested derived types
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-09-28 09:21:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24092
[Bug tree-optimization/23835] [4.1 Regression] case where gcc 4.1.0 -O3 compile takes two times longer earlier versions
--- Additional Comments From jaffe at broad dot mit dot edu 2005-09-28 09:45 --- That's an improvement! Still, here are the stats again, updated for 4.1.0: Compile time in seconds for test.ii: -O0 -O1-O2 -O3 3.4.3 5.659 9.515 13.811 14.779 4.1.0 5.829 16.398 24.618 27.066 % gcc -v Using built-in specs. Target: ia64-unknown-linux-gnu Configured with: ../configure --prefix=/wga1/gcc --enable-checking=release Thread model: posix gcc version 4.1.0 20050926 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23835
[Bug c/24101] New: Segfault with preprocessed source
This testcase segfaults for c and c++. --cut here-- # 1 /usr/local/lib/gcc/i686-pc-linux-gnu/4.1.0/include/stddef.h 1 3 4 --cut here-- gcc express-min.i In file included from express-min.i:1: /usr/local/lib/gcc/i686-pc-linux-gnu/4.1.0/include/stddef.h:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. This behaviour is quite annoying: if delta tool is used to minimize a preprocessed file that segfaults, it always produces this kind of one-line minimized testcase. -- Summary: Segfault with preprocessed source Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uros at kss-loka dot si CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24101
[Bug c/24101] [3.4/4.0/4.1 Regression] Segfault with preprocessed source
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-28 12:56 --- Confirmed, backtrace: #0 0x0804bc76 in fe_file_change (new_map=0xa30cce4) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/c-lex.c:236 #1 0x080997a5 in cb_file_change (pfile=0xa303928, new_map=0xa30cce4) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/c-opts.c:1405 #2 0x084f04f3 in _cpp_do_file_change (pfile=0xa303928, reason=LC_ENTER, to_file=0xa30e720 /usr/local/lib/gcc/i686-pc-linux-gnu/4.1.0/include/stddef.h, file_line=1, sysp=2) at /home/peshtigo/pinskia/src/gnu/gcc/src/libcpp/directives.c:921 #3 0x084f03e8 in do_linemarker (pfile=0xa303928) at /home/peshtigo/pinskia/src/gnu/gcc/src/libcpp/directives.c:903 #4 0x084efafd in _cpp_handle_directive (pfile=0xa303928, indented=0) at /home/peshtigo/pinskia/src/gnu/gcc/src/libcpp/directives.c:430 #5 0x084f609b in read_original_filename (pfile=0xa303928) at /home/peshtigo/pinskia/src/gnu/gcc/src/libcpp/init.c:506 #6 0x084f6015 in cpp_read_main_file (pfile=0xa303928, fname=0xbfff8c42 t.i) at /home/peshtigo/pinskia/src/gnu/gcc/src/libcpp/init.c:480 #7 0x0809a0db in c_common_post_options (pfilename=0x86373a8) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/c-opts.c:1046 : Search converges between 2004-02-01-trunk (#445) and 2004-03-01-trunk (#446). : Search converges between 2004-02-02-3.4 (#1) and 2004-03-01-3.4 (#2). -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-invalid-code, ||monitored Known to fail||3.4.0 4.0.0 4.1.0 Known to work||3.3.3 Last reconfirmed|-00-00 00:00:00 |2005-09-28 12:56:06 date|| Summary|Segfault with preprocessed |[3.4/4.0/4.1 Regression] |source |Segfault with preprocessed ||source Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24101
[Bug fortran/24100] gfortran cannot compile data statement
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-28 13:24 --- *** This bug has been marked as a duplicate of 23232 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24100
[Bug fortran/23232] DATA implied DO variables
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-28 13:24 --- *** Bug 24100 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||federico dot carminati at ||cern dot ch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23232
[Bug rtl-optimization/24102] New: floatdisf2_internal2 broken
The floatdisf2_internal2 is broken since 2004-11-26, which will result in broken rounding for float casts. long long l = (((1L 24) + 1) 29) + 1; float f = (float)l; will eg. lead to f=9007199254740992.00 instead of f=9007200328482816.00 If I'm not mistaken, rs6000.md:5239 should read (const_int 2) instead of (const_int 3). -- Summary: floatdisf2_internal2 broken Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mikael dot vidstedt at bea dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24102
[Bug rtl-optimization/24102] floatdisf2_internal2 broken
--- Additional Comments From mikael dot vidstedt at bea dot com 2005-09-28 13:34 --- This is on AIX/PowerPC. If there is anything else you need to know, please just ask. -- What|Removed |Added GCC target triplet||powerpc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24102
[Bug target/24102] [3.4/4.0/4.1 Regression] floatdisf2_internal2 broken
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-28 13:38 --- Caused by: PR rtl-optimization/16356 * config/rs6000/rs6000.md (floatdisf2_internal2): Rewrite with separate output register and one less jump. Enable for powerpc64. (floatdisf2): Adjust for above. -- What|Removed |Added CC||amodra at gcc dot gnu dot ||org Component|rtl-optimization|target GCC target triplet|powerpc |powerpc64-*-* Keywords||wrong-code Known to fail||4.0.0 4.1.0 3.4.4 Known to work||3.4.3 Summary|floatdisf2_internal2 broken |[3.4/4.0/4.1 Regression] ||floatdisf2_internal2 broken Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24102
internal compiler error: in simple_cst_equal, at tree.c:3367
Hello,
I've got this strange internal error in gcc:
internal compiler error: in simple_cst_equal, at tree.c:3367
I'm attaching the test code - trivial, no includes.
$ gcc test_ice_in_simple_cst_equal.cpp
test_ice_in_simple_cst_equal.cpp:25: internal compiler error: in
simple_cst_equal, at tree.c:3367
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
$ gcc -v
Reading specs from
/nfsroot/usr/bin/../lib/gcc-lib/i486-slackware-linux/3.3.4/specs
Configured with: ../gcc-3.3.4/configure --prefix=/usr --enable-shared
--enable-threads=posix --enable-__cxa_atexit --disable-checking
--with-gnu-ld --verbose --target=i486-slackware-linux
--host=i486-slackware-linux
Thread model: posix
gcc version 3.3.4
I don't have a gcc 3.4 or greater at hand now. Can anyone test this code
against a newer gcc and report a bug normal way if confirmed?
Thanks.
Best regards,
Alexander Stepanov
SoftMine Corp., Software Developer
Tel.: (1-212)-400-7584
(7-921)-636-1976
E-mail: [EMAIL PROTECTED]
Web: www.softminecorp.com
union foo {
unsigned long dword;
struct {
int a : 1;
int b : 2;
int c : 13;
int d : 16;
} bar;
};
typedef union foo foobar;
class A {
public:
A(foobar f = ((foobar) {bar: {1,2,4,8}}));
~A() {};
};
class B : public A {
public:
B(foobar f = ((foobar) {bar: {1,2,4,8}}));
~B() {};
};
B::B(foobar f) : A(f)
{
};
[Bug c++/24103] New: [3.4 Regression]
The following C++ code ICES in simple_cst_equal:
union foo {
unsigned long dword;
struct {
int a : 1;
int b : 2;
int c : 13;
int d : 16;
} bar;
};
typedef union foo foobar;
class A {
public:
A(foobar f = ((foobar) {bar: {1,2,4,8}}));
~A() {};
};
class B : public A {
public:
B(foobar f = ((foobar) {bar: {1,2,4,8}}));
~B() {};
};
B::B(foobar f) : A(f)
{
};
From
http://gcc.gnu.org/ml/gcc-bugs/2005-09/msg03492.html
--
Summary: [3.4 Regression]
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: minor
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24103
[Bug c++/24103] [3.4 Regression] ICE in simple_cst_equal
-- What|Removed |Added Known to fail||3.4.0 3.0.4 3.3.3 Known to work||2.95.3 4.0.0 4.1.0 Summary|[3.4 Regression]|[3.4 Regression] ICE in ||simple_cst_equal Target Milestone|--- |3.4.5 Version|4.1.0 |3.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24103
Re: internal compiler error: in simple_cst_equal, at tree.c:3367
On Sep 28, 2005, at 10:09 AM, Alexander Stepanov wrote: Hello, I've got this strange internal error in gcc: I don't have a gcc 3.4 or greater at hand now. Can anyone test this code against a newer gcc and report a bug normal way if confirmed? I filed it as PR 24103: http://gcc.gnu.org/PR24103. It works in 4.0.0, the mainline and 2.95.3 but not in 3.4.0. -- Pinski
[Bug c++/24103] [3.4 Regression] ICE in simple_cst_equal
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-28 14:10 --- Confirmed, because this is a forwarded bug. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail|3.4.0 3.0.4 3.3.3 |3.4.0 3.0.4 3.3.3 3.4.5 Last reconfirmed|-00-00 00:00:00 |2005-09-28 14:10:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24103
[Bug preprocessor/7976] pasting xxx and xxx does not give a valid preprocessing token
--- Additional Comments From planta at planta dot de 2005-09-28 14:35 --- Subject: AW: macro definition Stopp blaming us!!! Remove us immediatelly from cc List. Thx! -Ursprüngliche Nachricht- Von:pinskia at gcc dot gnu dot org [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 28. September 2005 06:06 An: planta Betreff:[Bug preprocessor/7976] macro definition --- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-28 04:05 --- *** Bug 12607 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7976
[Bug preprocessor/7976] pasting xxx and xxx does not give a valid preprocessing token
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-09-28 14:40 --- As requested in comment #17 -- What|Removed |Added CC|planta at planta dot de | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7976
[Bug c++/16782] Accepts qualified member function declaration in class
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-28 14:50 --- Subject: Bug 16782 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-28 14:50:18 Modified files: gcc/cp : decl.c ChangeLog gcc/testsuite : ChangeLog gcc/testsuite/g++.old-deja/g++.law: static-mem5.C gcc/testsuite/g++.old-deja/g++.mike: p8154.C Added files: gcc/testsuite/g++.dg/parse: qualified4.C Log message: PR c++/16782 * decl.c (grokdeclarator): Always pedwarn about overqualified member names. PR c++/16782 * g++.dg/parse/qualified4.C: New test. * g++.old-deja/g++.law/static-mem5.C: Use -w -fpermissive. * g++.old-deja/g++.mike/p8154.C: Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gccr1=1.1428r2=1.1429 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4904r2=1.4905 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.6110r2=1.6111 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/qualified4.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.old-deja/g++.law/static-mem5.C.diff?cvsroot=gccr1=1.3r2=1.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.old-deja/g++.mike/p8154.C.diff?cvsroot=gccr1=1.3r2=1.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16782
[Bug c++/16782] Accepts qualified member function declaration in class
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-28 14:51 --- Fixed in 4.1.0. -- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16782
[Bug c++/16782] Accepts qualified member function declaration in class
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-28 15:13 --- Fixed in 4.1.0. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16782
[Bug target/24102] [3.4/4.0/4.1 Regression] floatdisf2_internal2 broken
--- Additional Comments From amodra at bigpond dot net dot au 2005-09-28 15:54 --- Uhh, yes, it's a typo. The (const_int 3) in floatdisf2_internal2 should indeed be (const_int 2). -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-09-28 15:54:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24102
[Bug tree-optimization/22488] [4.1 Regression] push_fields_onto_fieldstack calculates offset incorrectly
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-28 15:57 --- If so, are those fields of A in B really *there*, at those offsets from the beginning of type B? Sort of. Because B would otherwise need a virtual table pointer, it just uses the one in A. So, there is a vptr at offset zero from the start of B. However, there's no actual A object at the same address as B because A is a virtual base. There's certainly no A::i at offset four from the start of B, for example. The layout you had posted in the bug matches the offsets when we process the type A field of C, but not the type A field of type B. Ugh. We create two versions of class types: the complete class type and the as-base type. (Look for CLASSTYPE_AS_BASE.) The as-base type does not include virtual bases, and the B field in C should have the B-as-base type, not the complete B type. The B-as-base type does not have the A parts. In fact, if you look at layout_class_type, and, in particular, build_base_field, you'll see it does use the as-base type. However, at the end of layout_class_type, we have: /* Now that we're done with layout, give the base fields the real types. */ and that installs the complete type. Jason added this in 2004: + 2004-04-30 Jason Merrill [EMAIL PROTECTED] + + Refer to base members using COMPONENT_REFs where possible. + * class.c (build_simple_base_path): New fn. + (build_base_path): Use it for non-virtual base references. + (layout_class_type): Change base fields to their real type + after layout is done. I think this is a hack so that later, when we use the COMPONENT_REFs, we don't have to cast from the as-base type back to the nominal C++ type. (Of course, this would also be cleaner with a real C++-lowering pass.) However, I think the right thing is to have the cast; as you've discovered, Jason's approach is lying about what's really there. Jason? -- What|Removed |Added CC||jason at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22488
[Bug target/24102] [3.4/4.0/4.1 Regression] floatdisf2_internal2 broken
--- Additional Comments From amodra at bigpond dot net dot au 2005-09-28 16:01 --- Bootstrapping the obvious fix. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24102
[Bug middle-end/17886] variable rotate and long long rotate should be better optimized
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-28 16:24 --- I am working on a patch to improve the rotation of long long by a constant. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17886
[Bug tree-optimization/24059] [4.1 Regression] ICE expand_expr_real_1 with -ftree-vectorize -O2
--- Additional Comments From janis187 at us dot ibm dot com 2005-09-28 16:25 --- A regression hunt identified this patch from rth: http://gcc.gnu.org/ml/gcc-cvs/2005-04/msg00765.html -- What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24059
[Bug middle-end/23714] [4.1 Regression] ICE in expand_assignment
--- Additional Comments From janis187 at us dot ibm dot com 2005-09-28 16:27 --- A regression hunt identified this patch from steven: http://gcc.gnu.org/ml/gcc-cvs/2005-06/msg00294.html -- What|Removed |Added CC||steven at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23714
[Bug c++/21383] [3.4/4.0/4.1 Regression] Crash when finding a_templated_func
--- Additional Comments From janis187 at us dot ibm dot com 2005-09-28 16:28 --- A regression hunt identified this patch from nathan: http://gcc.gnu.org/ml/gcc-cvs/2003-08/msg00349.html -- What|Removed |Added CC||nathan at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21383
[Bug fortran/17737] ICE when variable appears in two data statements
--- Additional Comments From segalemb at usp dot br 2005-09-28 16:32 --- (In reply to comment #5) *** Bug 23884 has been marked as a duplicate of this bug. *** Bug 23884 is not a duplicate of this bug, because there is no repeated data statements in module.F -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17737
[Bug c++/22352] [3.4/4.0/4.1 Regression] ICE in lookup_member
--- Additional Comments From janis187 at us dot ibm dot com 2005-09-28 16:41 --- A regression hunt identified this patch from [EMAIL PROTECTED]: http://gcc.gnu.org/ml/gcc-cvs/2003-10/msg00694.html -- What|Removed |Added CC||lerdsuwa at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22352
[Bug tree-optimization/23396] [4.1 Regression] profiledbootstrap is broken (again)
--- Additional Comments From hubicka at gcc dot gnu dot org 2005-09-28 16:48 --- x86 profiledbootstrap passed for me with mainline -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23396
[Bug c++/23730] [4.0/4.1 Regression] ICE instead of reporting a call to a non-existent member function
--- Additional Comments From janis187 at us dot ibm dot com 2005-09-28 16:48 --- A regression hunt identified these patches from nathan (the second adds a change missed in the first one): http://gcc.gnu.org/ml/gcc-cvs/2004-07/msg00663.html http://gcc.gnu.org/ml/gcc-cvs/2004-07/msg00664.html -- What|Removed |Added CC||nathan at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23730
[Bug target/23302] [4.1 Regression] extra move generated on x86
--- Additional Comments From hubicka at gcc dot gnu dot org 2005-09-28 16:51 --- The actual problem here is that from combine's point of view the two alternatives (lea preceeded by loads, or add with memory operand followed by shift) looks equivalent and previously the shorter sequence was purely choosed by luck because combine followed the right edge first. It is not quite possible to solve this by combine's splitting mechanizm as the number of instruction don't change before the read-modify instructions are broken up. While it might be probably possible to design peephole or combiner insn patter I am tempted to close this and PR 23303 as WONTFIX as it seems to me we was optimizing this by pure luck and the patch seems to have overall positive effect on code size... Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23302
[Bug target/23302] [4.1 Regression] extra move generated on x86
--- Additional Comments From hubicka at gcc dot gnu dot org 2005-09-28 16:52 --- The actual problem here is that from combine's point of view the two alternatives (lea preceeded by loads, or add with memory operand followed by shift) looks equivalent and previously the shorter sequence was purely choosed by luck because combine followed the right edge first. It is not quite possible to solve this by combine's splitting mechanizm as the number of instruction don't change before the read-modify instructions are broken up. While it might be probably possible to design peephole or combiner insn patter I am tempted to close this and PR 23303 as WONTFIX as it seems to me we was optimizing this by pure luck and the patch seems to have overall positive effect on code size... Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23302
[Bug libstdc++/22309] mt allocator doesn't pthread_key_delete its keys
--- Additional Comments From Woebbeking at web dot de 2005-09-28 17:16 --- Subject: Re: mt allocator doesn't pthread_key_delete its keys On Tuesday 27 September 2005 16:43, jakub at gcc dot gnu dot org wrote: If you are compiling with -fvisibility*, then the problem is PR libstdc++/22482, not this one. I compile with -fvisibility=hidden -fvisibility-inlines-hidden, but I get no linker errors. And as noted export GLIBCXX_FORCE_NEW=1 prevents the crash. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22309
[Bug tree-optimization/23853] [4.1 regression] ICE: in tree_low_cst, at tree.c:4270
--- Additional Comments From janis187 at us dot ibm dot com 2005-09-28 17:24 --- A regression hunt identified the following patch from [EMAIL PROTECTED]: http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00537.html -- What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23853
[Bug target/23302] [4.1 Regression] extra move generated on x86
--- Additional Comments From dann at godzilla dot ics dot uci dot edu 2005-09-28 17:29 --- (In reply to comment #2) While it might be probably possible to design peephole or combiner insn patter I am tempted to close this and PR 23303 as WONTFIX as it seems to me we was optimizing this by pure luck and the patch seems to have overall positive effect on code size... IMHO closing these bugs as WONTFIX is not the right thing to do. This is clearly a missed optimization opportunity. The fact that it worked by chance before your (overall good) patch does not make fixing this issue less desirable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23302
[Bug java/24018] [meta-bug] Patches that should be applied to 4.0 branch
--- Additional Comments From debian-gcc at lists dot debian dot org 2005-09-28 17:35 --- (In reply to comment #5) PR 19870. Although these patches are largeish, they have been tested in HEAD for some time and should be pretty safe. They are needed for OO.org. A naive backport doesn't work, see the thread starting at http://gcc.gnu.org/ml/java/2005-09/msg00118.html Matthias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24018
[Bug tree-optimization/23853] [4.1 regression] ICE: in tree_low_cst, at tree.c:4270
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-28 18:05 --- Patch posted long time ago, but still unreviewed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23853
[Bug middle-end/23971] [4.0/4.1 Regression] synth_mult running amok
--- Additional Comments From tsv at solvo dot ru 2005-09-28 18:07 --- Retested in idle machine: patch1 -O2 -mcpu=ev4 - 7 minutes patch2 -O2 -mcpu=ev4 - 1.30 minutes patch1 -O2 -mcpu=ev5 - 30 secs patch2 -O2 -mcpu=ev5 - 13.6 secs It does make a difference. :) Thank you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23971
[Bug c/24106] New: x86_64 -fPIC code gen bug (extern/static linkage confusion)
With this testcase:
int foo (int (*cb)(void)) { return (*cb)(); }
static int callback(void) { return 0; }
int main (void)
{
int callback (void);
return foo (callback);
}
On x86_64 with -fPIC, the address of callback as passed to foo is incorrect.
If callback isn't static, it works (through the GOT). If the declaration of
callback is removed it works (computes the address as %rip minus something). As
written, it does a failed combination of the two. The result is that instead of
passing callback's address, it loads the first 8 bytes at callback's address and
passes those. (It also erroneously claims callback is unused, but I'm guessing
that's a side-effect.)
The code is questionable, but my reading of the standard says it's legal and
that callback is still static after the (implicitly extern) declaration.
% gcc-3.4.4 -O2 -fPIC -Wall -save-temps -o bug bug.c
bug.c:2: warning: 'callback' defined but not used
% gcc-3.4.4 -v
Reading specs from /usr/local/lib/gcc/x86_64-pc-linux-gnu/3.4.4/specs
Configured with: /tmp/src/gcc-3.4.4/configure --enable-languages=c,c++
--enable-version-specific-runtime-libs --disable-shared --enable-threads
--with-gnu-as --with-gnu-ld --with-pic --host=x86_64-pc-linux-gnu
Thread model: posix
gcc version 3.4.4
[I bootstrapped this 3.4.4; it also fails with stock 3.4.3 from RedHat.]
--
Summary: x86_64 -fPIC code gen bug (extern/static linkage
confusion)
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mcoiley at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24106
[Bug c/24106] x86_64 -fPIC code gen bug (extern/static linkage confusion)
--- Additional Comments From mcoiley at yahoo dot com 2005-09-28 18:49 --- [Not sure how I managed to enter it twice. Sorry.] *** This bug has been marked as a duplicate of 24097 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24106
[Bug c/24097] [3.4 Regression] x86_64 -fPIC code gen bug (extern/static linkage confusion)
--- Additional Comments From mcoiley at yahoo dot com 2005-09-28 18:49 --- *** Bug 24106 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24097
[Bug testsuite/24107] New: gcc.dg/20050922-1.c relies in stdint.h
The testcase gcc.dg/20050922-1.c relies on the header stdint.h, which is not provided by GCC. This causes it to fail on systems such as hppa2.0w-hp-hpux11.11 which have inttypes.h but not stdint.h. The simplest fix would be to define uint32_t locally in the testcase, along the lines of #if __INT_MAX__ == 2147483647 typedef unsigned int uint32_t; #else typedef unsigned long uint32_t; #endif (not tested). -- Summary: gcc.dg/20050922-1.c relies in stdint.h Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24107
[Bug fortran/20903] types shouldn't propagate into interfaces
--- Additional Comments From pault at gcc dot gnu dot org 2005-09-28 18:59 --- (In reply to comment #3) This is resolved by http://gcc.gnu.org/ml/fortran/2005-09/msg00438.html Paul T Bull twaddle! This is wrong, whoever you are. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20903
[Bug target/24108] New: gcc.dg/vect/vect-76.c scan-tree-dump-times vectorized 1 loops 1 fails
FAIL: gcc.dg/vect/vect-76.c scan-tree-dump-times vectorized 1 loops 1 appeared on ia64-hp-hpux11.23 between 20050920 and 20050924, for both -milp32 and -mlp64. (This precise test within vect-76.c appears to be a new test, i.e. there wasn't previously a PASS: gcc.dg/vect/vect-76.c scan-tree-dump-times vectorized 1 loops 1 line.) The results of vect-76.c are: PASS: gcc.dg/vect/vect-76.c (test for excess errors) PASS: gcc.dg/vect/vect-76.c execution test XPASS: gcc.dg/vect/vect-76.c scan-tree-dump-times vectorized 3 loops 1 FAIL: gcc.dg/vect/vect-76.c scan-tree-dump-times vectorized 1 loops 1 XFAIL: gcc.dg/vect/vect-76.c scan-tree-dump-times Vectorizing an unaligned access 2 while on 20050920 they were: PASS: gcc.dg/vect/vect-76.c (test for excess errors) PASS: gcc.dg/vect/vect-76.c execution test PASS: gcc.dg/vect/vect-76.c scan-tree-dump-times vectorized 3 loops 1 PASS: gcc.dg/vect/vect-76.c scan-tree-dump-times Vectorizing an unaligned access 0 -- Summary: gcc.dg/vect/vect-76.c scan-tree-dump-times vectorized 1 loops 1 fails Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24108
[Bug testsuite/24107] gcc.dg/20050922-1.c relies in stdint.h
-- What|Removed |Added BugsThisDependsOn||448 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24107
[Bug tree-optimization/22488] [4.1 Regression] push_fields_onto_fieldstack calculates offset incorrectly
--- Additional Comments From jason at redhat dot com 2005-09-28 19:39 --- Subject: Re: [4.1 Regression] push_fields_onto_fieldstack calculates offset incorrectly mmitchel at gcc dot gnu dot org wrote: I think this is a hack so that later, when we use the COMPONENT_REFs, we don't have to cast from the as-base type back to the nominal C++ type. (Of course, this would also be cleaner with a real C++-lowering pass.) However, I think the right thing is to have the cast; as you've discovered, Jason's approach is lying about what's really there. Jason? My intent was to use COMPONENT_REFs where it's close enough to the truth, and casts where it isn't. The middle/back end produced significantly better code for COMPONENT_REFs than casts when I made the change, particularly with aliasing; I'm not sure if it's gotten any better since then. And besides, my approach isn't lying at all about this testcase; since there's only one appearance of the virtual base, it appears exactly where the field lists say it will. Daniel agreed that the problem is in his code. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22488
[Bug tree-optimization/22488] [4.1 Regression] push_fields_onto_fieldstack calculates offset incorrectly
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-09-28 20:16 --- Subject: Re: [4.1 Regression] push_fields_onto_fieldstack calculates offset incorrectly On Wed, 2005-09-28 at 19:39 +, jason at redhat dot com wrote: --- Additional Comments From jason at redhat dot com 2005-09-28 19:39 --- Subject: Re: [4.1 Regression] push_fields_onto_fieldstack calculates offset incorrectly mmitchel at gcc dot gnu dot org wrote: I think this is a hack so that later, when we use the COMPONENT_REFs, we don't have to cast from the as-base type back to the nominal C++ type. (Of course, this would also be cleaner with a real C++-lowering pass.) However, I think the right thing is to have the cast; as you've discovered, Jason's approach is lying about what's really there. Jason? My intent was to use COMPONENT_REFs where it's close enough to the truth, and casts where it isn't. The middle/back end produced significantly better code for COMPONENT_REFs than casts when I made the change, particularly with aliasing; I'm not sure if it's gotten any better since then. And besides, my approach isn't lying at all about this testcase; since there's only one appearance of the virtual base, it appears exactly where the field lists say it will. Daniel agreed that the problem is in his code. No, it actually isn't. I sent mark a followup mail, that didn't get put into the bug report for some reason. The type looks like this: Main type of var: C First field of C: field of type B ( field_decl 0x40212ebc D.1814 type record_type 0x40212170 B ... chain field_decl 0x40212b24 x) First field of B : _vptr.B ( field_decl 0x40212450 _vptr.B ... chain type_decl 0x401eec98) Second field of B: type_decl ( type_decl 0x401eec98 B ... chain field_decl 0x40212564 D.1781) Third field of B: field of type A ( field_decl 0x40212564 D.1781 ... chain NULL) Second field of C: field of type X (field_decl 0x40212b24 x type record_type 0x4020e844 X ... chain type_decl 0x401eee38 C) Third field of C: type_decl (type_decl 0x401eee38 C ... chain field_decl 0x4021605c D.1817) Fourth field of C: field of type A (field_decl 0x4021605c D.1817 type record_type 0x4020e9b4 A .. chain NULL) This causes us to walk type A twice (once as the third field of B, once as the fourth field of C), and where we get the offsets wrong, since we process the fields of type A twice. I don't see why type A appears in type C except through type B Is this because of virtual inheritance? If so, are those fields of A in B really *there*, at those offsets from the beginning of type B? The layout you had posted in the bug matches the offsets when we process the type A field of C, but not the type A field of type B. IE type A appears in two places. It's the first place that screws us up. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22488
[Bug c++/22618] [3.4/4.0/4.1 Regression] Template non-type arguments break class access protection
--- Additional Comments From janis187 at us dot ibm dot com 2005-09-28 20:25 --- A regression hunt identified this patch from mmitchel: http://gcc.gnu.org/ml/gcc-cvs/2003-07/msg00404.html -- What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22618
[Bug c++/21685] [3.4/4.0/4.1 Regression] Internal compiler error on invalid code
--- Additional Comments From janis187 at us dot ibm dot com 2005-09-28 20:27 --- A regression hunt identified this patch from mmitchel: http://gcc.gnu.org/ml/gcc-cvs/2004-02/msg00117.html -- What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21685
[Bug tree-optimization/22488] [4.1 Regression] push_fields_onto_fieldstack calculates offset incorrectly
--- Additional Comments From mark at codesourcery dot com 2005-09-28 20:28 --- Subject: Re: [4.1 Regression] push_fields_onto_fieldstack calculates offset incorrectly jason at redhat dot com wrote: And besides, my approach isn't lying at all about this testcase; since there's only one appearance of the virtual base, it appears exactly where the field lists say it will. Daniel agreed that the problem is in his code. What I meant by lying (an admittedly overly contentious choice of word) was that the field for B-in-C is marked as having the complete B type due to the code at the end of layout_class_type. However, the A virtual base isn't located in that B; it's located after the data members of C. So, the base field for B is incorrect. I agree that using COMPONENT_REFs is good, but I think that the FIELD_DECL for B should have the as-base type. Then, when you actually form the COMPONENT_REF, you should do the equivalent of: *(complete B*)c.b_base That will give the expression the correct type from the front-end's point of view, but not result in inaccuracy with respect to the TYPE_FIELDS for C. Obviously, we need to make sure that B-as-base complete-B are in the same alias set. (It might be even better just to have the front end consider B-as-base and complete-B as the same type, so that the expression could have the more-accurate B-as-base type. But, that would be a huge change to the front end, so I think we have no choice but to use the complete-B type for an expression like *(B*)c.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22488
[Bug c++/21685] [3.4/4.0/4.1 Regression] Internal compiler error on invalid code
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21685
[Bug c/24109] New: [4.0 Regression] -fno-unit-at-a-time failure with compound literals
The PR23190 fix on gcc-4_0-branch introduced a regression, which leads
to not being able to load some Linux kernel modules which abuse compound
literals.
Short testcase:
extern void abort (void);
struct A { int i; int j; };
struct B { struct A *a; struct A *b; };
struct C { struct B *c; struct A *d; };
struct C e = { (struct B) { (struct A) { 1, 2 }, (struct A) { 3, 4 } },
(struct A) { 5, 6 } };
int
main (void)
{
if (e.c-a-i != 1 || e.c-a-j != 2)
abort ();
if (e.c-b-i != 3 || e.c-b-j != 4)
abort ();
if (e.d-i != 5 || e.d-j != 6)
abort ();
return 0;
}
At -O0, -O1 or say -Os -fno-unit-at-a-time, this results in undefined
__compound_literal.[01] symbols.
The problem doesn't reproduce on HEAD, which has the PR23190 fix as well.
--
Summary: [4.0 Regression] -fno-unit-at-a-time failure with
compound literals
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,mark at codesourcery dot
com,rth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24109
[Bug fortran/24110] New: INTERVAL: Error: Unclassifiable statement
$ cat test.f95 INTERVAL(4):: X = [2,3] END $ gfortran -c test.f95 In file 2.f95:1 INTERVAL(4):: X = [2,3] 1 Error: Unclassifiable statement at (1) $ gfortran -v Using built-in specs. Target: powerpc64-linux Configured with: /home/gccbuild/gcc_mline_anoncvs/gcc/configure --prefix=/opt/gcc-nightly/mline-20050922 --build=powerpc64-linux --host=powerpc64-linux --target=powerpc64-linux --with-cpu=default32 --with-as=/opt/gcc-nightly/mline-20050922/bin/as --with-ld=/opt/gcc-nightly/mline-20050922/bin/ld --enable-threads=posix --enable-shared --enable-__cxa_atexit --enable-languages=c,c++,f95,java,objc,obj-c++ --enable-checking --with-mpfr=/opt/gcc-nightly/mline-20050922 Thread model: posix gcc version 4.1.0 20050922 (experimental) -- Summary: INTERVAL: Error: Unclassifiable statement Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24110
[Bug tree-optimization/22488] [4.1 Regression] push_fields_onto_fieldstack calculates offset incorrectly
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-09-28 20:34 --- Subject: Re: [4.1 Regression] push_fields_onto_fieldstack calculates offset incorrectly On Wed, 2005-09-28 at 20:29 +, mark at codesourcery dot com wrote: --- Additional Comments From mark at codesourcery dot com 2005-09-28 20:28 --- Subject: Re: [4.1 Regression] push_fields_onto_fieldstack calculates offset incorrectly jason at redhat dot com wrote: And besides, my approach isn't lying at all about this testcase; since there's only one appearance of the virtual base, it appears exactly where the field lists say it will. Daniel agreed that the problem is in his code. What I meant by lying (an admittedly overly contentious choice of word) was that the field for B-in-C is marked as having the complete B type due to the code at the end of layout_class_type. However, the A virtual base isn't located in that B; it's located after the data members of C. So, the base field for B is incorrect. If you give me guys a way to detect this case from the middle end, i'm happy to say Don't walk this structure, it's not really there. :) I agree that using COMPONENT_REFs is good, but I think that the FIELD_DECL for B should have the as-base type. Then, when you actually form the COMPONENT_REF, you should do the equivalent of: *(complete B*)c.b_base That will give the expression the correct type from the front-end's point of view, but not result in inaccuracy with respect to the TYPE_FIELDS for C. Obviously, we need to make sure that B-as-base complete-B are in the same alias set. (It might be even better just to have the front end consider B-as-base and complete-B as the same type, so that the expression could have the more-accurate B-as-base type. But, that would be a huge change to the front end, so I think we have no choice but to use the complete-B type for an expression like *(B*)c.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22488
[Bug tree-optimization/22488] [4.1 Regression] push_fields_onto_fieldstack calculates offset incorrectly
--- Additional Comments From mark at codesourcery dot com 2005-09-28 20:40 --- Subject: Re: [4.1 Regression] push_fields_onto_fieldstack calculates offset incorrectly dberlin at dberlin dot org wrote: And besides, my approach isn't lying at all about this testcase; since there's only one appearance of the virtual base, it appears exactly where the field lists say it will. Daniel agreed that the problem is in his code. What I meant by lying (an admittedly overly contentious choice of word) was that the field for B-in-C is marked as having the complete B type due to the code at the end of layout_class_type. However, the A virtual base isn't located in that B; it's located after the data members of C. So, the base field for B is incorrect. If you give me guys a way to detect this case from the middle end, i'm happy to say Don't walk this structure, it's not really there. :) I don't think there's anyway to do that reliably. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22488
[Bug target/24111] New: [3.4 4.0 4.1 regression] cannot handle identifiers with '$' character
[forwarded from http://bugs.debian.org/327849] Matthias On arm only, gcc cannot handle C identifiers like: static void L1__GET_$ENVIRONMENT__defmacro() reporting: gcc -g -Wall -DVOL=volatile -fsigned-char -pipe -pg -g -mlong-calls -I/home/camm/gcl-2.6.7/o -c gcl_defmacro.c In file included from gcl_defmacro.c:3: gcl_defmacro.h:2: error: stray '$' in program gcl_defmacro.h:2: error: syntax error before 'ENVIRONMENT__defmacro' gcl_defmacro.h:2: warning: type defaults to 'int' in declaration of 'ENVIRONMENT__defmacro' gcl_defmacro.h:2: warning: data definition has no type or storage class gcl_defmacro.h:67: error: stray '$' in program gcl_defmacro.h:67: error: 'L1__GET_' undeclared here (not in a function) gcl_defmacro.h:67: error: syntax error before 'ENVIRONMENT__defmacro' gcl_defmacro.c:7: error: stray '$' in program gcl_defmacro.c:7: error: syntax error before 'ENVIRONMENT__defmacro' gcl_defmacro.c:8: warning: return type defaults to 'int' gcl_defmacro.c: In function 'ENVIRONMENT__defmacro': gcl_defmacro.c:61: warning: 'return' with no value, in function returning non-void gcl_defmacro.c:63: warning: control reaches end of non-void function make: *** [gcl_defmacro.o] Error 1 Phil Blundell [EMAIL PROTECTED] I haven't investigated this issue at all, but at a first guess I would say this is caused by the patches to support the new ARM EABI (in which all identifiers containing $ are reserved). We should probably back out that change in Debian, at least for the time being. so should this handled in the distribution, or upstream? -- Summary: [3.4 4.0 4.1 regression] cannot handle identifiers with '$' character Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org CC: gcc-bugs at gcc dot gnu dot org,pb at gcc dot gnu dot org GCC target triplet: arm-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24111
Re: gfortran says to submit bug report
On Sep 28, 2005, at 4:53 PM, Joe Koski wrote: While attempting to compile the NIST FDS4 code (f90 based) I get the following error and a request to submit a bug report: jakoski$ gfortran -c -O3 -ffixed-form -fno-underscoring mods.f mods.f: In function 'lpcoef': mods.f:5099: error: unrecognizable insn: (insn 613 612 614 22 (set (reg:DF 729) (subreg:DF (mem/s:DC (plus:SI (reg/f:SI 114 virtual-stack-vars) (const_int 56112 [0xdb30])) [1413 equiv.1.cm+32 S16 A64]) 8)) -1 (nil) (nil)) mods.f:5099: internal compiler error: in extract_insn, at recog.c:2082 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. The compiler that I am using (and can get) is: Joe-Koskis-Computer:~/Fortran_Compiles/fds_test_compile_gfortran/ compiler error jakoski$ gfortran -v Using built-in specs. Target: powerpc-apple-darwin7.9.0 Configured with: ../gcc/configure --enable-languages=c++,f95 Thread model: posix gcc version 4.1.0 20050517 (experimental) Can you try a new compiler as the one which you are using is more than 4 months old and I think this has already been fixed. Thanks, Andrew Pinski
[Bug middle-end/24109] [4.0 Regression] non unit-at-a-time failure with compound literals
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-28 21:08 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|c |middle-end Ever Confirmed||1 Keywords||wrong-code Known to fail||4.0.2 Known to work||4.1.0 4.0.0 Last reconfirmed|-00-00 00:00:00 |2005-09-28 21:08:17 date|| Summary|[4.0 Regression] -fno-unit- |[4.0 Regression] non unit- |at-a-time failure with |at-a-time failure with |compound literals |compound literals Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24109
[Bug target/24111] [3.4 4.0 4.1 regression] cannot handle identifiers with '$' character
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-28 21:11 --- Does -fdollars-in-identifiers work? There is most likely a bug saying why this is not default for arm but I have not looked. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24111
[Bug libfortran/24112] New: Reopening file with STATUS='OLD' doesn't work
Consider the following: ! Test reopening with io status='old' ! First create a test file: touch foo program iostatus open (1, file='foo', status='old') open (1, file='foo', status='old') end program iostatus According to the standard (F2003 draft, section 9.4.5, page 181): A STATUS= specifier with a value of OLD is always allowed when the file to be connected to the unit is the same as the file to which the unit is connected. However, gfortran claims: At line 5 of file iostatus.f90 Fortran runtime error: Cannot change STATUS parameter in OPEN statement -- Summary: Reopening file with STATUS='OLD' doesn't work Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jblomqvi at cc dot hut dot fi CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24112
[Bug testsuite/24107] gcc.dg/20050922-1.c relies in stdint.h
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-28 21:23 --- I could swore there were other testcases which included stdint.h but there is not. Anyways, your definition of int32_t is wrong for some targets. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24107
[Bug c/24101] [3.4/4.0/4.1 Regression] Segfault with preprocessed source
-- What|Removed |Added Target Milestone|4.0.2 |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24101
[Bug target/24102] [3.4/4.0/4.1 Regression] floatdisf2_internal2 broken
-- What|Removed |Added Target Milestone|4.0.2 |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24102
[Bug testsuite/24107] gcc.dg/20050922-1.c relies in stdint.h
--- Additional Comments From joseph at codesourcery dot com 2005-09-28 21:29 --- Subject: Re: gcc.dg/20050922-1.c relies in stdint.h On Wed, 28 Sep 2005, pinskia at gcc dot gnu dot org wrote: I could swore there were other testcases which included stdint.h but there is not. Anyways, your definition of int32_t is wrong for some targets. It's not meant to be correct everywhere, simply to be more widely functional than the present testcase. You could of course check __INT_MAX__, __LONG_MAX__, __SHRT_MAX and __SCHAR_MAX__ and conditionally run a trivial program if none of those is correct - what you can't do is mark the test UNSUPPORTED based on preprocessor conditionals if a 32-bit type is unavailable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24107
[Bug tree-optimization/23853] [4.1 regression] ICE: in tree_low_cst, at tree.c:4270
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-28 21:30 --- Subject: Bug 23853 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-28 21:30:41 Modified files: gcc: ChangeLog tree-vect-analyze.c Log message: 2005-09-28 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/23853 * tree-vect-analyze.c (vect_compute_data_ref_alignment): Use host_integerp to verify misalignment value. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.10039r2=2.10040 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-vect-analyze.c.diff?cvsroot=gccr1=2.36r2=2.37 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23853
[Bug tree-optimization/23853] [4.1 regression] ICE: in tree_low_cst, at tree.c:4270
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-28 21:30 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23853
[Bug bootstrap/21335] [meta-bug] bootstrap fails with -ftree-vectorize
-- Bug 21335 depends on bug 23853, which changed state. Bug 23853 Summary: [4.1 regression] ICE: in tree_low_cst, at tree.c:4270 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23853 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21335
[Bug tree-optimization/23396] [4.1 Regression] profiledbootstrap is broken (again)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-28 21:31 --- Hmm, this works with --enable-checking=yes, trying --enable-checking=release soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23396
[Bug target/24111] [3.4 4.0 4.1 regression] cannot handle identifiers with '$' character
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-28 21:42 --- Actually it looks like this was introduced by the fix for PR 9209 which solves the issue that we were allowing dollars even on targets which it should not be accepting them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24111
[Bug target/24111] [3.4/4.0/4.1 regression] cannot handle identifiers with '$' character
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-28 21:47 --- ./config/arm/aout.h:#define DOLLARS_IN_IDENTIFIERS 0 Hmm: arm*-*-linux*) # ARM GNU/Linux with ELF tm_file=dbxelf.h elfos.h linux.h arm/elf.h arm/linux-gas.h arm/linux-elf.h arm/aout.h arm/ arm.h Why are we including aout.h here. Looks like a lot of the arm targets do that which is just wrong. Even arm-elf does. -- What|Removed |Added Summary|[3.4 4.0 4.1 regression]|[3.4/4.0/4.1 regression] |cannot handle identifiers |cannot handle identifiers |with '$' character |with '$' character http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24111
[Bug target/24111] [3.4/4.0/4.1 regression] cannot handle identifiers with '$' character
--- Additional Comments From debian-gcc at lists dot debian dot org 2005-09-28 21:48 --- (In reply to comment #1) Does -fdollars-in-identifiers work? There is most likely a bug saying why this is not default for arm but I have not looked. it does, at least for the compiler, didn't try to link. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24111
[Bug libgcj/24051] [4.1 Regression]: libjava failed to configure
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-09-28 22:09 --- Same problem on s390(x)-ibm-linux. B.t.w. isn't the real problem that the CXX that comes out of the configure machinery is simply incorrect? I.e. it should be something like xgcc -x c++ instead of just xgcc ... However, I don't follow the configure machinery enough to understand why this comes about, sorry. -- What|Removed |Added CC||uweigand at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24051
[Bug fortran/24110] INTERVAL: Error: Unclassifiable statement
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-28 23:20 --- What exactly is the problem? AFAIK, the program is not valid Fortran 95. What to you expect the compiler to do? -- What|Removed |Added Summary|INTERVAL: Error:|INTERVAL: Error: |Unclassifiable statement|Unclassifiable statement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24110
[Bug tree-optimization/23396] [4.1 Regression] profiledbootstrap is broken (again)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-28 23:59 --- Fixed or at least I cannot reproduce it any more. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23396
[Bug rtl-optimization/24069] [4.1 Regression] ice during feedback stage of profiledbootstrap on powerpc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-29 00:13 --- On powerpc-darwin, I was able to profiledbootstrap so this most likely 64bit related. By the way how did you configure gcc? -- What|Removed |Added Summary|ice during feedback stage of|[4.1 Regression] ice during |profiledbootstrap on powerpc|feedback stage of ||profiledbootstrap on powerpc Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24069
[Bug target/24102] [3.4/4.0/4.1 Regression] floatdisf2_internal2 broken
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-29 00:21 --- Subject: Bug 24102 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-29 00:16:16 Modified files: gcc: ChangeLog gcc/config/rs6000: rs6000.md Log message: PR target/24102 * config/rs6000/rs6000.md (floatdisf2_internal2): Correct range check for numbers that need no bit twiddle. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.10042r2=2.10043 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.md.diff?cvsroot=gccr1=1.411r2=1.412 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24102
[Bug target/24102] [3.4/4.0/4.1 Regression] floatdisf2_internal2 broken
--- Additional Comments From bangerth at dealii dot org 2005-09-29 00:25 --- How about the other branches? W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24102
[Bug target/24102] [3.4/4.0 Regression] floatdisf2_internal2 broken
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-29 00:51 --- (In reply to comment #6) How about the other branches? 4.0 is frozen right now and you really don't want a 3.4.5 (which sounds like will be released before 4.0.3) to have a fix before 4.0.x has it. -- What|Removed |Added Known to fail|4.0.0 4.1.0 3.4.4 |4.0.0 3.4.4 Known to work|3.4.3 |3.4.3 4.1.0 Summary|[3.4/4.0/4.1 Regression]|[3.4/4.0 Regression] |floatdisf2_internal2 broken |floatdisf2_internal2 broken http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24102
[Bug middle-end/24109] [4.0 Regression] non unit-at-a-time failure with compound literals
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-29 01:36 --- Retargeting at 4.0.3. -- What|Removed |Added Target Milestone|4.0.2 |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24109
FW: Complier not giving warning/error in this scenario.. Please help..
Hello All, I am trying to compile the file with the following code. Originally it was: if ((erc = pk_val(pline, pkt, mp, PKT_CLEAR, PK_LOCAL)) By accident I saved the file with the following code. if ((erc = (pline, pkt, mp, PKT_CLEAR, PK_LOCAL)) By accident pk_val_call got deleted and when I complied the above code using the options cc -c -g, it got compiled successfully. I tried removing -g also. Even then it gave success. Is this a problem with the compiler? Is there a fix for this that I can use. Appreciate your help. Regards Soujanya
RE: Complier not giving warning/error in this scenario.. Please h elp..
No, it's not a problem with the compiler. When you remove the function name,
the code is still valid.
For example:
int main() {
int a;
a = (1,2,3,4);
printf(%d\n, a);
}
[EMAIL PROTECTED]:~$ gcc t.c
[EMAIL PROTECTED]:~$ ./a.out
4
See 6.5.17 Comma operator of the C Standard for more information
Regards,
Ryan Mansfield
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Soujanya Gundlapalli
Sent: Wednesday, September 28, 2005 11:06 PM
To: [EMAIL PROTECTED]
Cc: gcc-bugs@gcc.gnu.org
Subject: FW: Complier not giving warning/error in this scenario.. Please
help..
Hello All,
I am trying to compile the file with the following code.
Originally it was:
if ((erc = pk_val(pline, pkt, mp, PKT_CLEAR, PK_LOCAL))
By accident I saved the file with the following code.
if ((erc = (pline, pkt, mp, PKT_CLEAR, PK_LOCAL))
By accident pk_val_call got deleted and when I complied the above code
using the options
cc -c -g, it got compiled successfully. I tried removing -g also. Even
then it gave success. Is this a problem with the compiler? Is there a
fix for this that I can use.
Appreciate your help.
Regards
Soujanya
[Bug tree-optimization/21550] [4.0/4.1 Regression] i686 floating point performance 33% slower than gcc 3.4.3
-- What|Removed |Added GCC target triplet|i686-pc-linux-gnu |i686-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21550
[Bug middle-end/17886] variable rotate and long long rotate should be better optimized
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-29 03:31 --- Subject: Bug 17886 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-29 03:31:27 Modified files: gcc: ChangeLog expmed.c optabs.c gcc/config/i386: i386.md Log message: PR 17886 * expmed.c (expand_shift): Move logic to reverse rotation direction when rotating by constants ... * optabs.c (expand_binop): ... here. * config/i386/i386.md (rotrdi3): Handle 32-bit mode. (ix86_rotrdi3): New pattern. (rotldi3): Handle 32-bit mode. (ix86_rotldi3): New pattern. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.10044r2=2.10045 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/expmed.c.diff?cvsroot=gccr1=1.236r2=1.237 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/optabs.c.diff?cvsroot=gccr1=1.294r2=1.295 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.md.diff?cvsroot=gccr1=1.656r2=1.657 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17886
[Bug middle-end/20983] [4.0/4.1 Regression] varargs functions force va_list variable to stack unnecessarily
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-29 03:37 --- Hmm, I think the same problem is on powerpc. There is an extra store to -40(r1). -- What|Removed |Added GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu |i686-*-* Summary|[4.0/4.1regression] varargs |[4.0/4.1 Regression] varargs |functions force va_list |functions force va_list |variable to stack |variable to stack |unnecessarily |unnecessarily http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20983
[Bug target/23451] [3.4/4.0/4.1 regression] Redundant reloading from stack frame
-- What|Removed |Added GCC target triplet|i486-linux |i486-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23451
[Bug middle-end/23150] 20050713-1.c fails on arm-none-eabi with -O2 or -Os.
--- Additional Comments From kazu at gcc dot gnu dot org 2005-09-29 04:47 --- This turned out to be a bug in calls.c. Changing to middle-end. -- What|Removed |Added Component|target |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23150
[Bug target/24102] [3.4/4.0 Regression] floatdisf2_internal2 broken
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-29 04:49 --- Subject: Bug 24102 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-09-29 04:48:45 Modified files: gcc: ChangeLog gcc/config/rs6000: rs6000.md Log message: PR target/24102 * config/rs6000/rs6000.md (floatdisf2_internal2): Correct range check for numbers that need no bit twiddle. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=2.2326.2.917r2=2.2326.2.918 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.md.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.284.4.19r2=1.284.4.20 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24102
[Bug rtl-optimization/17935] Two consecutive movzbl are generated
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-29 03:47 --- (In reply to comment #6) I think there is another optimization opportunity regarding movzbl following andl. I think that is that the tracer pass runs late which causes the movzbl to be there late. -- What|Removed |Added Severity|minor |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17935
[Bug target/24102] [3.4/4.0 Regression] floatdisf2_internal2 broken
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-29 04:43 --- Subject: Bug 24102 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-09-29 04:43:44 Modified files: gcc: ChangeLog gcc/config/rs6000: rs6000.md Log message: PR target/24102 * config/rs6000/rs6000.md (floatdisf2_internal2): Correct range check for numbers that need no bit twiddle. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.436r2=2.7592.2.437 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.md.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.350.2.5r2=1.350.2.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24102
[Bug rtl-optimization/17387] Redundant instructions in loop optimization
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-29 03:44 --- New patch was posted: http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01769.html -- What|Removed |Added GCC target triplet|x86_64-*-linux-gnu |x86_64-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17387
[Bug middle-end/17886] variable rotate and long long rotate should be better optimized
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-29 03:52 --- Here is the current status for the four functions in Andi's testcase, with f2 changed to use 32 - y so that it is a proper rotation: * f still generates a complex code sequence, but I'm not sure how much better we can do. Our code sequence doesn't look a lot worse than the sequence generated by icc 9.0, at first glance. We could try something like: if %ecx 31: mov %eax, %ebx shldl $31, %edx, %eax shldl $31, %ebx, %edx %ecx -= 31 if %ecx 31: mov %eax, %ebx shldl $31, %edx, %eax shldl $31, %ebx, %edx %ecx -= 31 if %ecx != 0: mov %eax, %ebx shldl %cl, %edx, %eax shldl %cl, %ebx, %edx but, that doesn't seem clearly better than what we presently generate. * f2 uses the roll instruction, which appears optimal. * f3 uses two shdl instructions, which appears optimal. * f4 uses the rorl instruction, which appears optimal. For all of f2 and f3, it looks like we generate code better than you get with icc 9.0. I have no plans to work on this further, for the time being, but I'll not close out the PRt; someone else might want to try to attack the code generated for the variable rotation case. Or, if people are satisfied, we can close the PR. -- What|Removed |Added AssignedTo|mark at codesourcery dot com|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17886
[Bug target/24102] floatdisf2_internal2 broken
--- Additional Comments From amodra at bigpond dot net dot au 2005-09-29 04:51 --- Fixed all active branches -- What|Removed |Added Status|ASSIGNED|RESOLVED Known to work|3.4.3 4.1.0 |3.4.3 4.1.0 4.0.3 3.4.5 Resolution||FIXED Summary|[3.4/4.0 Regression]|floatdisf2_internal2 broken |floatdisf2_internal2 broken | Target Milestone|4.0.3 |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24102
[Bug target/21588] x86 machine builtins do not have any const/pure attributes set
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-29 04:12 --- Making this depend on the need a new ra bug. -- What|Removed |Added BugsThisDependsOn||18427 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21588
[Bug target/23150] 20050713-1.c fails on arm-none-eabi with -O2 or -Os.
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kazu at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23150
[Bug middle-end/17886] variable rotate and long long rotate should be better optimized
--- Additional Comments From dank at kegel dot com 2005-09-29 04:36 --- Thanks - I'll try to get this benchmarked on a semi-real app. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17886
