[Bug bootstrap/39150] Configure scripts have no 64-Bit Solaris defined (only i386-solaris*).
--- Comment #3 from rob1weld at aol dot com 2009-02-13 08:36 --- Here is another person who makes the same complaint (with a patch): http://hackage.haskell.org/trac/ghc/ticket/2951 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39150
[Bug middle-end/39157] Code that compiles fine in 1GB of memory with 4.1.2 requires 20GB in 4.2.* and higher
--- Comment #21 from jakub at gcc dot gnu dot org 2009-02-13 09:17 --- To answer 2), I bet fwprop would suffer the same problem, but fwprop is disabled at -O1, LICM is not. I can try it today. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39157
[Bug bootstrap/39150] Configure scripts have no 64-Bit Solaris defined (only i386-solaris*).
--- Comment #4 from rob1weld at aol dot com 2009-02-13 09:11 --- Googling for amd64-pc-solaris2.11 gives a few hits. Googling for x86_64-pc-solaris2.11 gives a dozen hits. That is not many. Perhaps there is 'no such word'. It seems there are a few others who discovered this problem: http://osdir.com/ml/linux.debian.devel.dpkg.bugs/2006-04/msg00106.html http://gcc.gnu.org/ml/gcc/2004-12/msg00461.html http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?msg=47;bug=1191 Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39150
[Bug target/39175] New: ICE while compiling qt-4.5.0-rc1
/* { dg-options -O2 -m32 -fvisibility=hidden -msecure-plt -fpic } */
__attribute__((noinline)) int
foo (int x)
{
return x;
}
int foo (int x);
int
bar (int x)
{
return foo (x);
}
ICEs on the
if (DEFAULT_ABI == ABI_V4 flag_pic)
{
gcc_assert (!TARGET_SECURE_PLT);
return \b %...@plt\;
}
else
return \b %z1\;
assertion in sibcall_value_nonlocal_sysv.
--
Summary: ICE while compiling qt-4.5.0-rc1
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39175
[Bug target/38134] [4.4 Regression] speed regression with many loop invariants
--- Comment #14 from bonzini at gnu dot org 2009-02-13 09:57 --- It seems to me that it would help to have a postreload LIM pass that would concentrate on loop-invariant memory accesses that are as cheap or cheaper than loading back a spill. These would be excluded from the current (non-strict) LIM. Is it crazy? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38134
[Bug target/38134] [4.4 Regression] speed regression with many loop invariants
--- Comment #15 from steven at gcc dot gnu dot org 2009-02-13 10:03 --- Re. Comment #14 No, this is not crazy. It is called postreload-gcse. But it is a stupid pass that doesn't handle all cases it ought to handle. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38134
[Bug fortran/39171] Misleading warning for negative character length
--- Comment #1 from burnus at gcc dot gnu dot org 2009-02-13 10:34 --- For completeness, the F2003 standard has in 4.4.4 Character type The length is a type parameter; its value is greater than or equal to zero. and later If the character length parameter value evaluates to a negative value, the length of character entities declared is zero. Thus len=-1 is valid and equivalent to len=0. The warning is OK in my opinion as I cannot see any reason why one would like to have it negative at compile-time (init expression). (Maybe generated code/preprocessor expressions, but even then a warning might be helpful.) Whether the warning should be on by default or only with -W... is another question. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39171
[Bug target/39175] ICE while compiling qt-4.5.0-rc1
--- Comment #1 from jakub at gcc dot gnu dot org 2009-02-13 10:36 --- The problem is in the redundant prototype after function. First the foo FUNCTION_DECL is created, afterwards finish_function calls c_determine_visibility on it which changes its visibility from default to hidden. After this make_decl_rtl is called, determines the function binds locally and sets SYMBOL_FLAG_LOCAL|SYMBOL_FLAG_FUNCTION. Then merge_decls is called, which in turn clears visibility (sets it back to default) and calls make_decl_rtl to update the flags. At this point targetm.binds_local_p returns false, as it at that point has default visibility, so changes DECL_RTL's flags to SYMBOL_FLAG_FUNCTION alone. Then finish_decl calls c_determine_visibility again and sets it back to hidden visibility. But nothing afterwards calls make_decl_rtl again to update the symbol flags again. To fix this, IMHO either c_determine_visibility and C++ determine_visibility need to if (((TREE_CODE (decl) == VAR_DECL TREE_STATIC (decl)) || TREE_CODE (decl) == FUNCTION_DECL) DECL_RTL_SET_P (decl)) make_decl_rtl (decl); if it changed the visibility, or merge_decls/duplicate_decls would need to determine visibility. I'll try the former. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39175
[Bug middle-end/39157] Code that compiles fine in 1GB of memory with 4.1.2 requires 20GB in 4.2.* and higher
--- Comment #22 from rguenther at suse dot de 2009-02-13 11:06 --- Subject: Re: Code that compiles fine in 1GB of memory with 4.1.2 requires 20GB in 4.2.* and higher On Thu, 12 Feb 2009, lucier at math dot purdue dot edu wrote: --- Comment #19 from lucier at math dot purdue dot edu 2009-02-12 20:51 --- Subject: Re: Code that compiles fine in 1GB of memory with 4.1.2 requires 20GB in 4.2.* and higher On Thu, 2009-02-12 at 16:52 +, rguenth at gcc dot gnu dot org wrote: --- Comment #16 from rguenth at gcc dot gnu dot org 2009-02-12 16:52 --- Actually for PR26854 it is just one loop that is detected, covering all of the function (with approx. 56000 basic blocks and one basic-block that has edges to all other basic blocks in the loop). Richard: I'm wondering if you could look at a smaller file that's generated in a somewhat different way. At http://www.math.purdue.edu/~lucier/bugzilla/8/ there's a file _num.i.gz that I think should have smaller (nested) loops than the entire file, for example, from the label ___L189__23__23_bignum_2e__2a_: at line 50031 to just before label ___L190__23__23_bignum_2e__2a_: at line 50105. Moving loop invariants out of this loop might help if it detected as a loop, but I don't know how to check whether it is. Perhaps you might check and report whether this small loop is treated as a loop or whether, again, the entire function is the only loop detected. Yes, there are several small loops detected for this testcase (139 in total, including one large with the computed goto). Btw, thanks for the smaller testcase. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39157
[Bug middle-end/39157] Code that compiles fine in 1GB of memory with 4.1.2 requires 20GB in 4.2.* and higher
--- Comment #23 from rguenth at gcc dot gnu dot org 2009-02-13 11:08 --- Lemme close this bug as a dup of the one marked as regression. *** This bug has been marked as a duplicate of 26854 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39157
[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines
--- Comment #85 from rguenth at gcc dot gnu dot org 2009-02-13 11:08 --- *** Bug 39157 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug libstdc++/39168] Incorrect interpretation of CHAR_MAX inside grouping string in monetary and numeric facets.
--- Comment #7 from tsyvarev at ispras dot ru 2009-02-13 11:21 --- (In reply to comment #4) I'm not sure I understand your rationale or I agree that this is a bug. IIUC, string(1, CHAR_MAX) indicates that groups may be of arbitrary length, which includes 123,456 This behavior is the same regardless of whether char is a signed or unsigned type. Arbitrary length is not quite correct here - 123,456 violates grouping, given with string(1, CHAR_MAX). Standard use term unlimited length, which means(as I understand) that all other digits should incorporate in only one group - only 123456 is correct. (In reply to comment #6) Actually, libstdc++ stores 123456, which is indeed fine, and sets failbit | eofbit, failbit exactly because of the issue discussed here. The thing is that, according to the standard, CHAR_MAX should be treats similar as -1. But implementation treats string(1, -1) as no grouping at all, and stops read, when has encountered symbol ','. So only 123 is accumulated. This behaviour seems correct for me (though standard treats only string() as no grouping at all, 22.2.2.1.2, p8). So with string(1, CHAR_MAX) only 123 should be accumulated, not 123,456. In other words, test is passed when CHAR_MAX is replaced with -1. Inside grouping string, CHAR_MAX means same as -1(according to the standard). So test should be passed with original text. The same is about the second test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39168
[Bug libstdc++/39168] Incorrect interpretation of CHAR_MAX inside grouping string in monetary and numeric facets.
--- Comment #8 from paolo dot carlini at oracle dot com 2009-02-13 11:31 --- (In reply to comment #7) Standard use term unlimited length, which means(as I understand) that all other digits should incorporate in only one group - only 123456 is correct. I don't read that anywhere in the Standard. The thing is that, according to the standard, CHAR_MAX should be treats similar as -1. But implementation treats string(1, -1) as no grouping at all, and stops read, when has encountered symbol ','. So only 123 is accumulated. This behaviour seems correct for me (though standard treats only string() as no grouping at all, 22.2.2.1.2, p8). So with string(1, CHAR_MAX) only 123 should be accumulated, not 123,456. No, no, it is not correct, it is a bug in the current implementation. See where bool discard is defined, in Stage 2. (1, -1) (or (1, CHAR_MAX)) are not special, are normal groupings, that must be enforced. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39168
[Bug target/39175] ICE while compiling qt-4.5.0-rc1
--- Comment #2 from jakub at gcc dot gnu dot org 2009-02-13 11:33 --- Created an attachment (id=17292) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17292action=view) gcc44-pr39175.patch Patch I'm going to bootstrap/regtest. -- 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|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39175
[Bug libstdc++/39168] Incorrect interpretation of CHAR_MAX inside grouping string in monetary and numeric facets.
--- Comment #9 from paolo dot carlini at oracle dot com 2009-02-13 11:39 --- In other terms, as usual about those matters, Martin is right ;) Only he has got a wrong data point about libstdc++, he believes we are setting eofbit. Thanks anyway for pointing our attention to this CHAR_MAX issue, I'm going to fix it together with the bool discard thing (and its consequences). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39168
[Bug libfortran/39176] New: [4.4 Regression] -static and -fopenmp and io causes segfault
I noticed this running mixed mpi/openmp on a system that required an executable without dynamics libraries. Don't know if the Fortran IO is supposed to be thread safe (i.e. serialized thread safe), but this seems to work without -static. It also appears to work with 4.3.1 but not 4.4 (trunk) cat test.f90 !$OMP PARALLEL !$OMP CRITICAL write(6,*) Hello world !$OMP END CRITICAL !$OMP END PARALLEL write(6,*) Done! END gfortran -static -fopenmp test.f90 ./a.out Segmentation fault gdb ./a.out GNU gdb 6.4 Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as x86_64-suse-linux...Using host libthread_db library/lib64/libthread_db.so.1. (gdb) run Starting program: /data/vondele/omptest/a.out Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x0040642f in get_external_unit (n=6, do_create=1) at /data/vondele/gcc_trunk/gcc/libgfortran/../gcc/gthr-posix.h:704 #2 0x00404c01 in data_transfer_init (dtp=0x7fff047208c0, read_flag=0) at /data/vondele/gcc_trunk/gcc/libgfortran/io/transfer.c:1828 #3 0x004003d6 in MAIN__.omp_fn.0 () #4 0x0040032c in MAIN__ () #5 0x0040042c in main (argc=1, argv=0x7fff04720fa8) at /data/vondele/gcc_trunk/gcc/libgfortran/fmain.c:21 (gdb) -- Summary: [4.4 Regression] -static and -fopenmp and io causes segfault Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39176
[Bug libfortran/39176] [4.4 Regression] -static and -fopenmp and io causes segfault
--- Comment #4 from jakub at gcc dot gnu dot org 2009-02-13 12:35 --- It is glibc specific, on the other hand it isn't particularly -fopenmp related. I guess easiest will be if glibc stops shipping libpthread.a. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39176
[Bug target/39175] ICE while compiling qt-4.5.0-rc1
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-13 12:44 --- This also ICEs on the 4.3 branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39175
[Bug fortran/36703] ICE (segfault) in reduce_binary0 (arith.c:1778)
--- Comment #3 from pault at gcc dot gnu dot org 2009-02-13 12:53 --- The patch for 36703 also fixes this fellow. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-02-12 09:19:21 |2009-02-13 12:53:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36703
[Bug libstdc++/39168] Incorrect interpretation of CHAR_MAX inside grouping string in monetary and numeric facets.
--- Comment #10 from tsyvarev at ispras dot ru 2009-02-13 13:41 --- (In reply to comment #8) (In reply to comment #7) Standard use term unlimited length, which means(as I understand) that all other digits should incorporate in only one group - only 123456 is correct. I don't read that anywhere in the Standard. Could you clarify this a bit? Do you mean that when reading 123,456 with string(1, -1), failbit shouldn't be set? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39168
[Bug libstdc++/39168] Incorrect interpretation of CHAR_MAX inside grouping string in monetary and numeric facets.
--- Comment #11 from paolo dot carlini at oracle dot com 2009-02-13 13:43 --- (In reply to comment #10) Do you mean that when reading 123,456 with string(1, -1), failbit shouldn't be set? Right, as Martin said. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39168
[Bug libgomp/39176] -static and -fopenmp and io causes segfault
--- Comment #5 from jv244 at cam dot ac dot uk 2009-02-13 14:01 --- (In reply to comment #4) It is glibc specific, on the other hand it isn't particularly -fopenmp related. I guess easiest will be if glibc stops shipping libpthread.a. but if -fopenmp automatically adds -lpthread maybe it should do it in the 'proper' way if -static is also on the command line (eventually bailing out if libpthread.a can not be found)? Note, e.g. a warning is produced for similar issues already, e.g. I see: /home/u1/vondele/gcc_trunk/build/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../lib64/libgfortran.a(getlog.o): In function `_gfortran_getlog': /home/u1/vondele/gcc_trunk/gcc/libgfortran/intrinsics/getlog.c:82: warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking let me reopen the bug, removing the regression marker, and as an enhancement. I think that a warning, or adding -lpthread in the 'proper' way if -static will save many other users from loosing time on this one. -- jv244 at cam dot ac dot uk changed: What|Removed |Added Severity|normal |enhancement Status|RESOLVED|UNCONFIRMED Component|libfortran |libgomp Resolution|INVALID | Summary|[4.4 Regression] -static and|-static and -fopenmp and io |-fopenmp and io causes |causes segfault |segfault| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39176
[Bug target/39162] Gcc doesn't warn __m256 when -mavx isn't used
--- Comment #3 from hjl at gcc dot gnu dot org 2009-02-13 14:34 --- Subject: Bug 39162 Author: hjl Date: Fri Feb 13 14:34:00 2009 New Revision: 144157 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144157 Log: gcc/ 2009-02-13 H.J. Lu hongjiu...@intel.com PR target/39162 * config/i386/i386.c (type_natural_mode): Add a new argument. Return the original mode and warn ABI change if vector size is 32byte. (function_arg_advance): Updated. (function_arg): Likewise. (ix86_function_value): Likewise. (ix86_return_in_memory): Likewise. (ix86_sol10_return_in_memory): Likewise. (ix86_gimplify_va_arg): Likewise. (function_arg_32): Don't warn ABX ABI change here. (function_arg_64): Likewise. gcc/testsuite/ 2009-02-13 H.J. Lu hongjiu...@intel.com PR target/39162 * gcc.target/i386/pr39162.c: New. Added: trunk/gcc/testsuite/gcc.target/i386/pr39162.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39162
[Bug fortran/39178] Generate main() rather than using a main in libgfortran/fmain.c
--- Comment #1 from burnus at gcc dot gnu dot org 2009-02-13 14:57 --- s/MAIN_/MAIN__/g * * * Intel's solution is to link for_main-o, but that is not as elegant as for ifort *.o one needs to specify -nofor-main if there is a non-fortran C The last line should read: 'if there is a non-fortran main()'. * * * Regarding MAIN__: - gdb assumes that this is the main function for Fortran programs; as gfortran now sets main_program_symbol this might be not an issue. - For stepping through the code, having a separate MAIN_ avoids that the user enters libgfortran for the initialization, which can be a bit confusing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39178
[Bug libstdc++/39168] Incorrect interpretation of CHAR_MAX inside grouping string in monetary and numeric facets.
--- Comment #12 from tsyvarev at ispras dot ru 2009-02-13 15:04 --- Let's consider the following situation (seems lifelike to me). Suppose one needs a representation of numbers in which only the last 3 digits are separated from all other digits (grouped), like 1234,567 or 1234567,890. Other separators shouldn't appear. Grouping string \003 doesn't fit for this purpose as it separates all 3-digits groups: 1,234,567. Before this PR, I thought that \003\177 is sufficient for this purpose. But, as I understand now, the representations like 12,34,567 are acceptable in this case, which is not what I would like to have. Could you suggest which grouping string should be used to do such number representation? Or is this unachievable? I investigated locale support in POSIX, such number representation is achieved there with \003\177. It seems strange for me that similar mechanism is not work with C++ locales. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39168
[Bug libstdc++/39168] Incorrect interpretation of CHAR_MAX inside grouping string in monetary and numeric facets.
--- Comment #13 from paolo dot carlini at oracle dot com 2009-02-13 15:11 --- (In reply to comment #12) Could you suggest which grouping string should be used to do such number representation? Or is this unachievable? Actually \003\176 seems perfectly practical to me. In particular considering the actual size of real numbers. I investigated locale support in POSIX, such number representation is achieved there with \003\177. It seems strange for me that similar mechanism is not work with C++ locales. POSIX seems a good point, probably you should have mentioned it much earlier. Let's hear Martin again, then. Certainly, however, I'm concerned about having a behavior different from all the other implementations mentioned by Martin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39168
[Bug fortran/39178] Generate main() rather than using a main in libgfortran/fmain.c
--- Comment #2 from burnus at gcc dot gnu dot org 2009-02-13 15:11 ---
Note: Moving main() to f951 will break programs which assume that MAIN__ will
be called, compile e.g. the following program with gcc:
---
#include stdio.h
int MAIN__( int argc, char* argv[] )
{printf(argc is %i:0 %s\n, argc,argv[0]);
printf(argc is %i:1 %s\n, argc,argv[1]);
return(0);}
---
and link it with gfortran. If you run it, MAIN__ will be executed and by some
magic the arguments are passed to MAIN__. (That the arguments are available is
a complete puzzle to me.) -- Found in c.l.f thread linked above.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39178
[Bug libstdc++/39168] Incorrect interpretation of CHAR_MAX inside grouping string in monetary and numeric facets.
--- Comment #14 from paolo dot carlini at oracle dot com 2009-02-13 15:21 --- If I understand correctly, in order to implement the POSIX behavior for C++, assuming we want it, the Standard should be clarified to explain that values = 0 or CHAR_MAX are different in that do no admit repetitions, thus saying explicitly that such group is effectively the last, arbitrarily long, one. I must say, that is what we would do when formatting anyway. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39168
[Bug tree-optimization/36054] bad code generation with -ftree-vectorize
--- Comment #21 from d dot g dot gorbachev at gmail dot com 2009-02-13 15:25 --- Created an attachment (id=17293) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17293action=view) precompiled source The same issue with GCC 4.3.3 (i686-pc-linux-gnu). C source: http://svn.savannah.gnu.org/viewvc/*checkout*/trunk/kqemu.c?root=qemurevision=6338content-type=text%2Fplain cc1 -O3 -march=pentium4 kqemu.c Offending asm code: kqemu_cpu_exec: ... movl8(%ebp), %ebx ... .L96: movdqa (%ebx), %xmm0 // segmentation fault -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36054
[Bug libstdc++/39168] Incorrect interpretation of CHAR_MAX inside grouping string in monetary and numeric facets.
--- Comment #15 from tsyvarev at ispras dot ru 2009-02-13 15:38 --- (In reply to comment #14) If I understand correctly, in order to implement the POSIX behavior for C++, assuming we want it, the Standard should be clarified to explain that values = 0 or CHAR_MAX are different in that do no admit repetitions, thus saying explicitly that such group is effectively the last, arbitrarily long, one. Yes, I meen exactly this. Also, current implementation follows this strategy - accroding to the tests, and according to it's source code. So it is strange for me, that the standard for num_get::do_get() say, that only string() is indicator of no grouping at all. While string(1,-1) and string(1,CHAR_MAX) also force number representation to have only one group. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39168
[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines
--- Comment #86 from lucier at math dot purdue dot edu 2009-02-13 15:40 --- Subject: Re: [4.3/4.4 Regression] Inordinate compile times on large routines It's unfortunate that the discussion from 39157 will be somewhat hard to find now that that bug is closed. Steven wrote in a comment for 39157: It's not like there will not be any loop invariant code motion (LICM) at all anymore if the RTL LICM pass is disabled. There is an LICM pass on GIMPLE, and there is also PRE for GIMPLE (and lazy code motion for RTL but I think it disables itself for your test case). The RTL LICM pass mostly cleans up after expand, i.e. moves things that are not exposed in GIMPLE. This is mostly just address calculations. The loop in _num.i that I mentioned in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39157#c19 is the loop in PR 33928 that is no longer fully optimized after Paolo (and you, I guess, your name is on the patch) added PRE and disabled some optimizations in CSE, and what is no longer optimized in that loop are address calculations. I don't know whether those address calculations fall under LICM, the only point I'm trying to make right now is that address calculations are no longer optimized as much as they were before http://gcc.gnu.org/viewcvs?root=gccview=revrev=118475 and address calculations are an important class of calculations to optimize. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug c++/39179] New: Wrong code in c++ for const members initialized in external file
It seems so that for optimization levels one or higher, gcc produces wrong code
for the two test files below.
If I compile the same test with -O or -Os everything works fine.
On taking a look into produced assembly, it seems that it wrongly assumes the
assert alway have to raise.
File 1: t1.cpp
//class.h
struct K {
static const unsigned k;
};
#include assert.h
int main() {
assert ( K::k == 1 );
return 1;
}
File 2: t2.cpp
struct K {
static const unsigned k;
};
//class.cpp
const unsigned K::k = 1;
Then compile both file g++ -o tst t1.cpp t2.cpp -O2
--
Summary: Wrong code in c++ for const members initialized in
external file
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ktietz at gcc dot gnu dot org
GCC target triplet: x86_64-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
[Bug libstdc++/39168] Incorrect interpretation of CHAR_MAX inside grouping string in monetary and numeric facets.
--- Comment #16 from paolo dot carlini at oracle dot com 2009-02-13 15:49 --- (In reply to comment #15) (In reply to comment #14) If I understand correctly, in order to implement the POSIX behavior for C++, assuming we want it, the Standard should be clarified to explain that values = 0 or CHAR_MAX are different in that do no admit repetitions, thus saying explicitly that such group is effectively the last, arbitrarily long, one. Yes, I meen exactly this. Also, current implementation follows this strategy - according to the tests, and according to it's source code. Yes, I know that ;) And I also know that implementing the exact behaviour you want would be trivial and would bring consistency between signed and unsigned char platforms. Probably we want to implement it anyway in v3, but that doesn't mean by itself that it's obviously the only meaningful interpretation of the standard if so many other implementations differ, as pointed out by Martin. Thus let's be clear about that with Martin and probably at the same time also take actions to open a DR for C++0x. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39168
[Bug target/39082] union with long double doesn't follow x86-64 psABI
--- Comment #6 from hjl dot tools at gmail dot com 2009-02-13 15:51 --- I checked gcc 3.4.6. The bug is there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39082
[Bug libgcj/38685] classmap.db is zero bytes long in 64 bit directory
--- Comment #8 from rob1weld at aol dot com 2009-02-13 15:55 --- In revision 144149 we have this: # gcc/xgcc -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../gcc_trunk/configure --build=i386-pc-solaris2.11 --target=i386-pc-solaris2.11 --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared --disable-static --enable-multilib --enable-decimal-float --with-long-double-128 --with-included-gettext --enable-stage1-checking --enable-checking=release --with-tune=k8 --with-cpu=k8 --with-arch=k8 --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local --without-ppl Thread model: posix gcc version 4.4.0 20090213 (experimental) [trunk revision 144149] (GCC) # gmake ... ./gcj-dbtool -n classmap.db || touch classmap.db /bin/sh: line 1: 20225: Memory fault(coredump) cp classpath/tools/tools.zip libgcj-tools-4.4.0.jar [CTRL-C] # My fix: /usr/local/bin/gcj-dbtool -n classmap.db || touch classmap.db Result: # ls -lrtA /usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava | tail -rwxr-xr-x 1 root root4223 Feb 13 07:15 gnative2ascii -rwxr-xr-x 1 root root4191 Feb 13 07:15 gorbd -rwxr-xr-x 1 root root4191 Feb 13 07:15 grmid -rwxr-xr-x 1 root root4211 Feb 13 07:15 gserialver -rwxr-xr-x 1 root root4211 Feb 13 07:15 gtnameserv drwxr-xr-x 2 root root 89 Feb 13 07:15 .libs -rwxr-xr-x 1 root root4221 Feb 13 07:15 gc-analyze -rw-r--r-- 1 root root 1166776 Feb 13 07:15 libgcj-tools-4.4.0.jar -rw--- 1 root root 74276701 Feb 13 07:19 core -rw-r--r-- 1 root root 1441792 Feb 13 07:20 classmap.db Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38685
[Bug target/36222] x86 fails to optimize out __v4si - __m128i move
--- Comment #10 from hjl dot tools at gmail dot com 2009-02-13 15:57 --- Fixed. Gcc 4.4.0 revision 144128 generates: foo2: movd%edi, %xmm0 movd%esi, %xmm1 movd%edx, %xmm2 punpckldq %xmm0, %xmm1 movd%ecx, %xmm0 punpckldq %xmm2, %xmm0 punpcklqdq %xmm1, %xmm0 ret .size foo2, .-foo2 -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36222
[Bug target/30961] [4.2 regression] redundant reg/mem stores/moves
--- Comment #37 from hjl dot tools at gmail dot com 2009-02-13 16:00 --- Gcc 4.4.0 revision 144128 generates: .globl convert .type convert, @function convert: movl%edi, -4(%rsp) movss -4(%rsp), %xmm0 ret .size convert, .-convert .p2align 4,,15 .globl load .type load, @function load: movzwl (%rdi), %eax ret .size load, .-load -- hjl dot tools at gmail dot com changed: What|Removed |Added Known to work|3.4.6 4.3.0 |3.4.6 4.3.0 4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30961
[Bug tree-optimization/33928] [4.3/4.4 Regression] 30% performance slowdown in floating-point code caused by r118475
--- Comment #44 from bonzini at gnu dot org 2009-02-13 16:05 --- A simplified (local, noncascading) fwprop not using UD chains would not be hard to do... Basically, at -O1 use FOR_EACH_BB/FOR_EACH_BB_INSN instead of walking the uses, keep a (regno, insn) map of pseudos (cleared at the beginning of every basic block), and use that info instead of UD chains in use_killed_between... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
[Bug tree-optimization/33928] [4.3/4.4 Regression] 30% performance slowdown in floating-point code caused by r118475
--- Comment #45 from lucier at math dot purdue dot edu 2009-02-13 16:09 --- Subject: Re: [4.3/4.4 Regression] 30% performance slowdown in floating-point code caused by r118475 On Fri, 2009-02-13 at 16:05 +, bonzini at gnu dot org wrote: --- Comment #44 from bonzini at gnu dot org 2009-02-13 16:05 --- A simplified (local, noncascading) fwprop not using UD chains would not be hard to do... Basically, at -O1 use FOR_EACH_BB/FOR_EACH_BB_INSN instead of walking the uses, keep a (regno, insn) map of pseudos (cleared at the beginning of every basic block), and use that info instead of UD chains in use_killed_between... As noted in comment 42, enabling FWPROP on this test case does not fix the performance problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
[Bug target/39149] Typo in i386.c
--- Comment #3 from hjl dot tools at gmail dot com 2009-02-13 17:31 --- (In reply to comment #2) See the comment: ... Remove this code in GCC 3.2 or later. But given the bogus warning message, we may never remove it :-). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39149
[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines
--- Comment #90 from lucier at math dot purdue dot edu 2009-02-13 17:37 --- Subject: Re: [4.3/4.4 Regression] Inordinate compile times on large routines On Fri, 2009-02-13 at 16:54 +, bonzini at gnu dot org wrote: --- Comment #87 from bonzini at gnu dot org 2009-02-13 16:54 --- The problem is that -O1 was never meant to give very fast code. I'm not looking for very fast code, I'm looking for code that doesn't get 30% slower from one SVN revision number to the next. You are using it only because our throttling of expensive passes is insufficient. I am using -O1 because code of this type compiled with -O2 runs significantly more slowly than code of this type compiled with -O1. I have never used -O2 on this type of code. Fixing that has two sides, as done in PR39157's discussion: 1) disabling more passes at -O1, 2) establishing some parameters to throttle down passes at -O2. I don't see that (1) and (2) form the main strategy to fix that, it seems that understanding the existing optimizations that are being disabled in preference for new ones is a good start. And generally ensuring that -O1 code doesn't get significantly slower while compile times get significantly higher. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines
--- Comment #91 from lucier at math dot purdue dot edu 2009-02-13 17:43 --- Subject: Re: [4.3/4.4 Regression] Inordinate compile times on large routines On Fri, 2009-02-13 at 17:37 +, lucier at math dot purdue dot edu wrote: --- Comment #90 from lucier at math dot purdue dot edu 2009-02-13 17:37 --- Subject: Re: [4.3/4.4 Regression] Inordinate compile times on large routines On Fri, 2009-02-13 at 16:54 +, bonzini at gnu dot org wrote: --- Comment #87 from bonzini at gnu dot org 2009-02-13 16:54 --- The problem is that -O1 was never meant to give very fast code. I'm not looking for very fast code, I'm looking for code that doesn't get 30% slower from one SVN revision number to the next. Sorry, this comment refers to PR 33928, not this PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug target/39149] Typo in i386.c
--- Comment #4 from hjl dot tools at gmail dot com 2009-02-13 17:44 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00657.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||02/msg00657.html Target Milestone|4.4.0 |4.3.4 Version|4.4.0 |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39149
[Bug libgcj/39180] New String constructors need to be implemented in local copy of java.lang.String
--- Comment #1 from gnu_andrew at member dot fsf dot org 2009-02-13 17:45 --- Created an attachment (id=17294) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17294action=view) Preliminary patch, has issues with the returned string reading from the wrong memory location Preliminary implementation. The method works as expected, but for some reason the returned string is not pointing to the characters. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39180
[Bug target/39149] Typo in i386.c
--- Comment #5 from hjl at gcc dot gnu dot org 2009-02-13 17:48 --- Subject: Bug 39149 Author: hjl Date: Fri Feb 13 17:48:20 2009 New Revision: 144160 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144160 Log: 2009-02-13 H.J. Lu hongjiu...@intel.com PR target/39149 * config/i386/i386.c (override_options): Correct warning messages for -malign-loops, -malign-jumps and -malign-functions. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39149
[Bug libgcj/39180] New String constructors need to be implemented in local copy of java.lang.String
--- Comment #2 from tromey at gcc dot gnu dot org 2009-02-13 17:54 --- This line looks fishy: + boffset = cbuf-position(); boffset is a byte offset from the start of 'data' to the first character. So, you probably need to multiply by sizeof(jchar) and also add in the size of the array header. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39180
[Bug c/39182] New: ICE in gen_add2_insn, at optabs.c:4884
We get this error multiple places in the RTEMS code base. m32c-rtems4.10-gcc --pipe -mcpu=m32cm --pipe -DHAVE_CONFIG_H -I.. -I../../../lib/include -D__RTEMS_INSIDE__ -Wall -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -fasm -g -O2 -mcpu=m32cm -MT src/libsapi_a-ioregisterdriver.o -MD -MP -MF src/.deps/libsapi_a-ioregisterdriver.Tpo -c -o src/libsapi_a-ioregisterdriver.o `test -f 'src/ioregisterdriver.c' || echo '../../../../../rtems/cpukit/sapi/'`src/ioregisterdriver.c ../../../../../rtems/cpukit/sapi/src/ioregisterdriver.c: In function 'rtems_io_register_driver': ../../../../../rtems/cpukit/sapi/src/ioregisterdriver.c:92: internal compiler error: in gen_add2_insn, at optabs.c:4884 -- Summary: ICE in gen_add2_insn, at optabs.c:4884 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joel at gcc dot gnu dot org GCC target triplet: m32c-rtems http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39182
[Bug c/39182] ICE in gen_add2_insn, at optabs.c:4884
--- Comment #1 from joel at gcc dot gnu dot org 2009-02-13 18:50 --- Created an attachment (id=17295) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17295action=view) preprocessed test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39182
[Bug c/39182] ICE in gen_add2_insn, at optabs.c:4884
--- Comment #2 from joel at gcc dot gnu dot org 2009-02-13 18:52 --- WORKS: m32c-rtems4.10-gcc -mcpu=m32cm j.c -c FAILS: m32c-rtems4.10-gcc -mcpu=m32cm j.c -O1 -c FAILS: m32c-rtems4.10-gcc -mcpu=m32cm j.c -O2 -c -- joel at gcc dot gnu dot org changed: What|Removed |Added Component|target |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39182
[Bug c++/39070] [4.3/4.4 regression] ICE with typeof() (... and __decltype)
--- Comment #7 from jason at gcc dot gnu dot org 2009-02-13 19:14 --- Subject: Bug 39070 Author: jason Date: Fri Feb 13 19:14:07 2009 New Revision: 144161 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144161 Log: PR c++/39070 * semantics.c (finish_call_expr): Change koenig_p parm to int. If -1, don't set KOENIG_LOOKUP_P but do keep hidden candidates. * cp-tree.h: Adjust prototype. * pt.c (tsubst_copy_and_build) [CALL_EXPR]: Pass -1. Added: trunk/gcc/testsuite/g++.dg/cpp0x/decltype16.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39070
[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign
--- Comment #19 from jakub at gcc dot gnu dot org 2009-02-13 19:15 --- Created an attachment (id=17296) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17296action=view) Unsuccessful attempt to avoid stack realignment for DImode and for DFmode at -Os Just for the record, here is an unsuccessful attempt to avoid stack realignment just because of DImode for -m32 or because of DFmode at -m32 -Os. This patch unfortunately caused a handful regressions, like 20020220-1.c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137
[Bug target/39181] [4.4 Regression] complex int arguments cause ICE
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39181
[Bug other/39183] New: valgrind find problems in as
I just tried to compile the Linux kernel 2.6.28.5 with the GNU C compiler version 4.4 snapshot 20090206, using the valgrind debugging tool. The compiler said as --gdwarf2 -V -Qy --64 -o arch/x86/ia32/ia32entry.o ia32entry.s ==4085== Conditional jump or move depends on uninitialised value(s) ==4085==at 0x41D56E: (within /usr/bin/as) ==4085==by 0x405DC4: (within /usr/bin/as) ==4085==by 0x5976585: (below main) (in /lib64/libc-2.9.so) File ia32entry.s attached. $ as -v GNU assembler version 2.19 (x86_64-suse-linux) using BFD version (GNU Binutils; openSUSE 11.1) 2.19 -- Summary: valgrind find problems in as Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39183
[Bug tree-optimization/33928] [4.3/4.4 Regression] 30% performance slowdown in floating-point code caused by r118475
--- Comment #48 from bonzini at gnu dot org 2009-02-13 20:09 --- Subject: Re: [4.3/4.4 Regression] 30% performance slowdown in floating-point code caused by r118475 Yes. I don't see why the optimizations in CSE, which were relatively cheap and which were effective for this case, needed to be disabled when FWPROP was added without, evidently, understanding why FWPROP does not do what CSE was already doing. Just to mention it, fwprop saved 3% of compile time. That's not cheap. It was also tested with SPEC and Nullstone on several architectures. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
[Bug other/39183] valgrind find problems in as
--- Comment #1 from dcb314 at hotmail dot com 2009-02-13 20:10 --- Created an attachment (id=17297) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17297action=view) pre-processed assembly language code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39183
[Bug other/39183] valgrind find problems in as
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-02-13 20:11 --- As is not part of GCC project, report it to binutils project, http://sourceware.org/bugzilla/ -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39183
[Bug libgomp/39176] -static and -fopenmp and io causes segfault
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-02-13 20:18 --- Not a gcc bug so closing as invalid. That warning comes from glibc anyways. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39176
[Bug other/39183] valgrind find problems in as
--- Comment #3 from hjl dot tools at gmail dot com 2009-02-13 20:19 --- FWIW, I can't reproduce it with the current binutils in CVS. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39183
[Bug target/39182] ICE in gen_add2_insn, at optabs.c:4884
--- Comment #3 from dj at redhat dot com 2009-02-13 20:28 --- Fails with m32c-elf in 4.3.4 also. Note: does NOT fail in 4.4/trunk -- dj at redhat dot com changed: What|Removed |Added CC||dj at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-13 20:28:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39182
[Bug c/39184] New: ICE in tree_low_cst, at tree.c:4976
ICE at -O1 and -02. Target specific error message at -O0. But even that would be more helpful if it told what the actual limit was. $ avr-rtems4.10-gcc -mmcu=avr25 -O2 j.c -c ../../../../../rtems/cpukit/telnetd/des.c: In function 'des_init': ../../../../../rtems/cpukit/telnetd/des.c:274: internal compiler error: in tree_low_cst, at tree.c:4976 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. $ avr-rtems4.10-gcc -mmcu=avr25 -O0 j.c -c ../../../../../rtems/cpukit/telnetd/des.c:87: error: size of variable 'des_f' is too large -- Summary: ICE in tree_low_cst, at tree.c:4976 Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joel at gcc dot gnu dot org GCC target triplet: avr-rtems4.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39184
[Bug c/39184] ICE in tree_low_cst, at tree.c:4976
--- Comment #1 from joel at gcc dot gnu dot org 2009-02-13 20:54 --- Created an attachment (id=17298) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17298action=view) preprocessed test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39184
[Bug libgomp/39176] -static and -fopenmp and io causes segfault
--- Comment #7 from jv244 at cam dot ac dot uk 2009-02-13 21:00 --- (In reply to comment #6) Not a gcc bug so closing as invalid. The gcc 'bug' is that -fopenmp -static should link to pthreads as -Wl,--whole-archive -lpthread -Wl,--no-whole-archive, if that is required, or error out if that is not possible. The current way of just adding -lpthread and hoping it is correct (even in the presence of -static) is leading to wrong code. -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39176
[Bug libgomp/39176] -static and -fopenmp and io causes segfault
--- Comment #8 from jakub at gcc dot gnu dot org 2009-02-13 21:10 --- This is not a gcc bug, glibc either should not ship libpthread.a at all or mv libpthread.a libpthreadx.a; gcc -r -nostdlib -o libpthread.a --whole-archive libpthreadx.a; rm libpthreadx.a I'll try the latter in Fedora soon. In any case, users really shouldn't use -static except for a few system recovery tools, see http://people.redhat.com/drepper/no_static_linking.html -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39176
[Bug fortran/36528] Cray pointer to function mishandled
--- Comment #3 from pault at gcc dot gnu dot org 2009-02-13 21:12 --- Subject: Bug 36528 Author: pault Date: Fri Feb 13 21:12:34 2009 New Revision: 144164 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144164 Log: 2009-02-13 Paul Thomas pa...@gcc.gnu.org PR fortran/36703 PR fortran/36528 * trans-expr.c (gfc_conv_function_val): Stabilize Cray-pointer function references to ensure that a valid expression is used. (gfc_conv_function_call): Pass Cray pointers to procedures. 2009-02-13 Paul Thomas pa...@gcc.gnu.org PR fortran/36528 * gfortran.dg/cray_pointers_8.f90: New test. PR fortran/36703 * gfortran.dg/cray_pointers_9.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/cray_pointers_8.f90 trunk/gcc/testsuite/gfortran.dg/cray_pointers_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36528
[Bug fortran/36703] ICE (segfault) in reduce_binary0 (arith.c:1778)
--- Comment #4 from pault at gcc dot gnu dot org 2009-02-13 21:12 --- Subject: Bug 36703 Author: pault Date: Fri Feb 13 21:12:34 2009 New Revision: 144164 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144164 Log: 2009-02-13 Paul Thomas pa...@gcc.gnu.org PR fortran/36703 PR fortran/36528 * trans-expr.c (gfc_conv_function_val): Stabilize Cray-pointer function references to ensure that a valid expression is used. (gfc_conv_function_call): Pass Cray pointers to procedures. 2009-02-13 Paul Thomas pa...@gcc.gnu.org PR fortran/36528 * gfortran.dg/cray_pointers_8.f90: New test. PR fortran/36703 * gfortran.dg/cray_pointers_9.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/cray_pointers_8.f90 trunk/gcc/testsuite/gfortran.dg/cray_pointers_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36703
[Bug c/39185] New: ICE in gen_rtx_SUBREG, at emit-rtl.c:773
$ h8300-rtems4.10-gcc -O1 -msx -c j.c ../../../../../rtems/cpukit/libnetworking/netinet/in_cksum.c: In function 'in_cksum': ../../../../../rtems/cpukit/libnetworking/netinet/in_cksum.c:118: internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:773 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Fails at -O2, -O1. Works at -O0. -- Summary: ICE in gen_rtx_SUBREG, at emit-rtl.c:773 Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joel at gcc dot gnu dot org GCC target triplet: h8300-rtems http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39185
[Bug c/39185] ICE in gen_rtx_SUBREG, at emit-rtl.c:773
--- Comment #1 from joel at gcc dot gnu dot org 2009-02-13 21:17 --- Created an attachment (id=17299) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17299action=view) preprocessed test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39185
[Bug target/39185] ICE in gen_rtx_SUBREG, at emit-rtl.c:773
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-02-13 21:20 --- Most likely related to PR 33163 and PR 32739. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39185
[Bug c++/39070] [4.3/4.4 regression] ICE with typeof() (... and __decltype)
--- Comment #8 from jason at gcc dot gnu dot org 2009-02-13 21:53 --- Subject: Bug 39070 Author: jason Date: Fri Feb 13 21:53:38 2009 New Revision: 144166 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144166 Log: PR c++/39070 * semantics.c (finish_call_expr): Change koenig_p parm to int. If -1, don't set KOENIG_LOOKUP_P but do keep hidden candidates. * cp-tree.h: Adjust prototype. * pt.c (tsubst_copy_and_build) [CALL_EXPR]: Pass -1. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/cpp0x/decltype16.C - copied unchanged from r144161, trunk/gcc/testsuite/g++.dg/cpp0x/decltype16.C Modified: branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/cp-tree.h branches/gcc-4_3-branch/gcc/cp/pt.c branches/gcc-4_3-branch/gcc/cp/semantics.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39070
[Bug rtl-optimization/38034] Unnecssary register move
--- Comment #2 from hjl dot tools at gmail dot com 2009-02-13 21:58 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00674.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||sje at cup dot hp dot com URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||02/msg00674.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38034
[Bug target/38056] Missed tail calls on ia64
--- Comment #4 from sje at gcc dot gnu dot org 2009-02-13 21:59 --- Subject: Bug 38056 Author: sje Date: Fri Feb 13 21:59:32 2009 New Revision: 144168 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144168 Log: PR target/38056 * config/ia64/ia64.c (ia64_function_ok_for_sibcall): Check TARGET_CONST_GP. * gcc.target/ia64/sibcall-opt-1.c: New test. * gcc.target/ia64/sibcall-opt-2.c: New test. Added: trunk/gcc/testsuite/gcc.target/ia64/sibcall-opt-1.c trunk/gcc/testsuite/gcc.target/ia64/sibcall-opt-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/ia64/ia64.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38056
[Bug fortran/38259] Add version number to .mod file
--- Comment #5 from burnus at gcc dot gnu dot org 2009-02-13 22:16 --- Subject: Bug 38259 Author: burnus Date: Fri Feb 13 22:16:20 2009 New Revision: 144169 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144169 Log: 2009-02-13 Mikael Morin mikael.mo...@tele2.fr PR fortran/38259 * module.c (gfc_dump_module,gfc_use_module): Add module version number. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38259
[Bug fortran/38259] Add version number to .mod file
--- Comment #6 from burnus at gcc dot gnu dot org 2009-02-13 22:17 --- FIXED on the trunk (4.4.0). -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38259
[Bug bootstrap/39186] New: Configury incorrect for 64-bit Targets on Solaris
I decided to re-build binutils and try the Target x86_64-pc-solaris2.11 that is suggested to be available to us in this post: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39150#c1 The attempt with Sun's Linker did not work so I tried with Binutils. # isainfo -k amd64 # uname -a SunOS opensolaris 5.11 snv_106 i86pc i386 i86pc # gcc/xgcc -v Using built-in specs. Target: x86_64-pc-solaris2.11 Configured with: ../gcc_trunk/configure --build=i386-pc-solaris2.11 --target=x86_64-pc-solaris2.11 --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared --disable-static --enable-multilib --enable-decimal-float --with-long-double-128 --with-included-gettext --enable-stage1-checking --enable-checking=release --with-tune=k8 --with-cpu=k8 --with-arch=k8 --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local --without-ppl Thread model: posix gcc version 4.4.0 20090213 (experimental) [trunk revision 144162] (GCC) # as --version GNU assembler (GNU Binutils) 2.19.1 # ld --version GNU ld (GNU Binutils) 2.19.1 The Build breaks here: # gmake ... cp gcj gcj-cross gmake[2]: Leaving directory `/usr/share/src/gcc_build/gcc' Configuring in ./gnattools configure: creating cache ./config.cache checking for a BSD-compatible install... /usr/bin/ginstall -c checking build system type... i386-pc-solaris2.11 checking host system type... i386-pc-solaris2.11 checking target system type... x86_64-pc-solaris2.11 checking whether ln -s works... yes checking for i386-pc-solaris2.11-gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed updating cache ./config.cache configure: creating ./config.status config.status: creating Makefile Checking multilib configuration for libgcc... Configuring in x86_64-pc-solaris2.11/libgcc configure: creating cache ./config.cache checking for --enable-version-specific-runtime-libs... no checking for a BSD-compatible install... /usr/bin/ginstall -c checking for gawk... gawk checking build system type... i386-pc-solaris2.11 checking host system type... x86_64-pc-solaris2.11 checking for x86_64-pc-solaris2.11-ar... /usr/local/x86_64-pc-solaris2.11/bin/ar checking for x86_64-pc-solaris2.11-lipo... x86_64-pc-solaris2.11-lipo checking for x86_64-pc-solaris2.11-nm... /usr/share/src/gcc_build/./gcc/nm checking for x86_64-pc-solaris2.11-ranlib... /usr/local/x86_64-pc-solaris2.11/bin/ranlib checking for x86_64-pc-solaris2.11-strip... /usr/local/x86_64-pc-solaris2.11/bin/strip checking whether ln -s works... yes checking for x86_64-pc-solaris2.11-gcc... /usr/share/src/gcc_build/./gcc/xgcc -B/usr/share/src/gcc_build/./gcc/ -B/usr/local/x86_64-pc-solaris2.11/bin/ -B/usr/local/x86_64-pc-solaris2.11/lib/ -isystem /usr/local/x86_64-pc-solaris2.11/include -isystem /usr/local/x86_64-pc-solaris2.11/sys-include checking for suffix of object files... configure: error: in `/usr/share/src/gcc_build/x86_64-pc-solaris2.11/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. gmake[1]: *** [configure-target-libgcc] Error 1 gmake[1]: Leaving directory `/usr/share/src/gcc_build' gmake: *** [all] Error 2 ... The ../gcc_build/x86_64-pc-solaris2.11/libgcc/config.log file says: ... xgcc: '-V' must come at the start of the command line configure:2396: $? = 1 configure:2415: /usr/share/src/gcc_build/./gcc/xgcc -B/usr/share/src/gcc_build/./gcc/ -B/usr/local/x86_64-pc-solaris2.11/bin/ -B/usr/local/x86_64-pc-solaris2.11/lib/ -isystem /usr/local/x86_64-pc-solaris2.11/include -isystem /usr/local/x86_64-pc-solaris2.11/sys-include -o conftest -g -O2 conftest.c 5 /var/tmp//ccMDaqTx.s: Assembler messages: /var/tmp//ccMDaqTx.s:35: Error: cannot represent relocation type BFD_RELOC_64 /var/tmp//ccMDaqTx.s:36: Error: cannot represent relocation type BFD_RELOC_64 /var/tmp//ccMDaqTx.s:44: Error: cannot represent relocation type BFD_RELOC_64 /var/tmp//ccMDaqTx.s:45: Error: cannot represent relocation type BFD_RELOC_64 /var/tmp//ccMDaqTx.s:123: Error: cannot represent relocation type BFD_RELOC_64 configure:2418: $? = 1 configure:2590: checking for suffix of object files ... The command being used is: /usr/share/src/gcc_build/./gcc/xgcc -B/usr/share/src/gcc_build/./gcc/ -B/usr/local/x86_64-pc-solaris2.11/bin/ -B/usr/local/x86_64-pc-solaris2.11/lib/ -isystem /usr/local/x86_64-pc-solaris2.11/include -isystem /usr/local/x86_64-pc-solaris2.11/sys-include -o conftest -g -O2 conftest.c -- If I change that by adding -v --save-temps and using it on a 'hello world'.c I get: # /usr/share/src/gcc_build/./gcc/xgcc -B/usr/share/src/gcc_build/./gcc/ -B/usr
[Bug target/39186] Configury incorrect for 64-bit Targets on Solaris
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-13 23:54 --- the -X86_64 option is not being passed to as which is a bug in the specs. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|bootstrap |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39186
[Bug c++/39187] New: G++ doesn't use string literal in inline function
[...@gnu-6 936]$ cat x.cc
#include foo.h
const char *
x (void)
{
return f ();
}
[...@gnu-6 936]$ cat y.cc
#include stdio.h
#include foo.h
extern const char *x (void);
int
main ()
{
printf (%p, %p\n, x (), f ());
return 0;
}
[...@gnu-6 936]$ cat foo.h
inline const char *
f ()
{
static const char *p = Itanium C++ ABI;
return p;
}
[...@gnu-6 936]$ cat x.s
.file x.cc
.section.text._Z1fv,axG,@progbits,_Z1fv,comdat
.p2align 4,,15
.weak _Z1fv
.type _Z1fv, @function
_Z1fv:
movq_ZZ1fvE1p(%rip), %rax
ret
.size _Z1fv, .-_Z1fv
.text
.p2align 4,,15
.globl _Z1xv
.type _Z1xv, @function
_Z1xv:
movq_ZZ1fvE1p(%rip), %rax
ret
.size _Z1xv, .-_Z1xv
.weak _ZZ1fvE1p
.section.rodata.str1.1,aMS,@progbits,1
.LC0:
.string Itanium C++ ABI
Both x.s and y.s have a string:
.string Itanium C++ ABI
It should be put in string literal as specified in C++ ABI:
http://www.codesourcery.com/public/cxx-abi/abi.html#mangling
so that only one copy will be in the executable/DSO.
--
Summary: G++ doesn't use string literal in inline function
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
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=39187
[Bug c++/39187] G++ doesn't use string literal in inline function
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-14 00:11 --- Except the C++ standard has a defect against this area, see PR 12056 which is still opened the last time I looked. *** This bug has been marked as a duplicate of 12056 *** -- 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=39187
[Bug c++/12056] [DR 397] string literal in extern inline function not unique
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-02-14 00:11 --- *** Bug 39187 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12056
[Bug c++/39188] New: G++ doesn't handle static anonymous union right
-- Summary: G++ doesn't handle static anonymous union right Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ 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=39188
[Bug c++/39188] G++ doesn't handle static anonymous union right
--- Comment #1 from hjl dot tools at gmail dot com 2009-02-14 00:38 ---
[...@gnu-6 936]$ cat x.cc
#include foo.h
int *
x (void)
{
return f ();
}
[...@gnu-6 936]$ cat y.cc
#include stdio.h
#include foo.h
extern int *x (void);
int
main ()
{
printf (%p, %p\n, x (), f ());
return 0;
}
[...@gnu-6 936]$ cat foo.h
inline int *
f ()
{
static union
{
const char *p;
int i;
};
return i;
}
[...@gnu-6 936]$ g++ x.cc y.cc -O2
[...@gnu-6 936]$ ./a.out
0x600a38, 0x600a40
[...@gnu-6 936]$ nm x.o | c++filt
W f()
T x()
b f()::p
U __gxx_personality_v0
f()::p should be global and linkonce.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39188
[Bug c++/12056] [DR 397] string literal in extern inline function not unique
--- Comment #5 from hjl dot tools at gmail dot com 2009-02-14 00:56 --- FWIW, it isn't a problem with GNU linker when all files are compiled with the same version of gcc since linker can merge identical strings with gcc help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12056
[Bug target/39186] Configury incorrect for 64-bit Targets on Solaris
--- Comment #2 from rob1weld at aol dot com 2009-02-14 01:19 --- A quick hack in ../gcc_trunk/libgcc/configure (line 2065) to add -m64 to the 'ac_compile' and 'ac_link' lines will allow the build to proceed through libgcc to libgcov where it then fails due to an issue unrelated to this Bug. Once I get the 'Build Path' constructed I'll go back and make correct patches to the correct files. Andrew: the -X86_64 option is not being passed to as which is a bug in the specs. I am glad I am not the only one who sees there is something needing fixing in order for all (most) Platforms to compile with a 'similar logic method' (to the extent possible). I don't like to see parts of the Build getting skipped when they could easily work the same as they do on another Platform. A big part of Porting is to get a 'similar' program on different Platforms. Some Software Manufacturers make 'nearly identical versions' on quite different Platforms will well received results. I can appreciate that we are not striving for identical but we ought to avoid having 100 dozen ways of building gcc as a result of having a half dozen ways of asking how it is to be built (for each HTB). Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39186
[Bug fortran/39189] New: Improvement in handling COMMON'ed pointers to allocatable arrays
When using perverted technique like: SUBROUTINE A INTEGER, ALLOCATABLE, DIMENSION(:), TARGET :: ARRAY INTEGER, POINTER, DIMENSION(:) :: ARRAY_PTR COMMON /AP/ ARRAY_PTR !for later use in another sub ALLOCATE(ARRAY(10)) ARRAY = 10 ARRAY_PTR = ARRAY END SUBROUTINE A SUBROUTINE B INTEGER, POINTER, DIMENSION(:) :: ARRAY_PTR COMMON /AP/ ARRAY_PTR !for later use in another sub print *, ARRAY_PTR(1) END SUBROUTINE one can figure out, that ARRAY will be free'd after finishing subroutine A (because it was not SAVE'd). But gfortran still allows to play such a trick. I think it would be nice to see warning in such case (pointing to data that will be lost after this scope) -- Summary: Improvement in handling COMMON'ed pointers to allocatable arrays Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: boldin dot pavel at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39189
[Bug target/39186] Configury incorrect for 64-bit Targets on Solaris
--- Comment #3 from rob1weld at aol dot com 2009-02-14 02:06 --- The next issue is here: ../gcc_trunk/gcc/unwind-dw2.c and ../gcc_trunk/gcc/unwind-dw2-fde.c, etc ... ../../../../gcc_trunk/libgcc/../gcc/gthr-posix.h:44:21: error: pthread.h: No such file or directory ../../../../gcc_trunk/libgcc/../gcc/gthr-posix.h:45:20: error: unistd.h: No such file or directory In file included from ../../.././gcc/gthr-default.h:1, from ../../../../gcc_trunk/libgcc/../gcc/gthr.h:165, from ../../../../gcc_trunk/libgcc/../gcc/unwind-dw2.c:42: ../../../../gcc_trunk/libgcc/../gcc/gthr-posix.h:47: error: expected =, ,, ;, asm or __attribute__ before __gthread_t I built that one file manually by adding -I/usr/include to the list of include directories, that allowed it to find pthread.h and unistd.h. I tried adding -I/usr/include into the Makefile in ../gcc_build/x86_64-pc-solaris2.11/amd64/libgcc like this: # Specify the directories to be searched for header files. # Both . and srcdir are used, in that order, # so that *config.h will be found in the compilation # subdirectory rather than in the source directory. # -I$(@D) and -I$(srcdir)/$(@D) cause the subdirectory of the file # currently being compiled, in both source trees, to be examined as well. INCLUDES = -I. -I$(@D) -I$(gcc_objdir) \ -I$(srcdir) -I$(srcdir)/$(@D) -I$(srcdir)/../gcc \ -I$(srcdir)/../include $(DECNUMINC) -I/usr/include That works for a while but when I get here: /usr/share/src/gcc_build/./gcc/xgcc -v -B/usr/share/src/gcc_build/./gcc/ -B/usr/local/x86_64-pc-solaris2.11/bin/ -B/usr/local/x86_64-pc-solaris2.11/lib/ -isystem /usr/local/x86_64-pc-solaris2.11/include -isystem /usr/local/x86_64-pc-solaris2.11/sys-include -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -DNATIVE_CROSS -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -isystem ./include -I. -I/usr/share/src/gcc_build/x86_64-pc-solaris2.11/amd64/libgcc -I../../gcc_trunk/gcc -I../../gcc_trunk/gcc//usr/share/src/gcc_build/x86_64-pc-solaris2.11/amd64/libgcc -I../../gcc_trunk/gcc/../include -I./../intl -I../../gcc_trunk/gcc/../libcpp/include -I/usr/local/include -I/usr/local/include -I../../gcc_trunk/gcc/../libdecnumber -I../../gcc_trunk/gcc/../libdecnumber/dpd -I../libdecnumber -g -O2 -m64 -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize -Dinhibit_libc -c ../../gcc_trunk/gcc/crtstuff.c -DCRT_BEGIN --save-temps -o /usr/share/src/gcc_build/x86_64-pc-solaris2.11/amd64/libgcc/crtbegin.o I get this: ... /usr/local/bin/as -v -I. -I/usr/share/src/gcc_build/x86_64-pc-solaris2.11/amd64/libgcc -I../../gcc_trunk/gcc -I../../gcc_trunk/gcc//usr/share/src/gcc_build/x86_64-pc-solaris2.11/amd64/libgcc -I../../gcc_trunk/gcc/../include -I./../intl -I../../gcc_trunk/gcc/../libcpp/include -I/usr/local/include -I/usr/local/include -I../../gcc_trunk/gcc/../libdecnumber -I../../gcc_trunk/gcc/../libdecnumber/dpd -I../libdecnumber -V -Qy --64 -s -o /usr/share/src/gcc_build/x86_64-pc-solaris2.11/amd64/libgcc/crtbegin.o crtstuff.s GNU assembler version 2.19.1 (i386-pc-solaris2.11) using BFD version (GNU Binutils) 2.19.1 crtstuff.s: Assembler messages: crtstuff.s:91: Error: suffix or operands invalid for `pop' crtstuff.s:92: Error: Incorrect register `%rdx' used with `l' suffix .p2align 4,,15 .type frame_dummy, @function frame_dummy: .LFB4: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 movl$__register_frame_info_bases, %eax /APP / 354 ../../gcc_trunk/gcc/crtstuff.c 1 call.LPR53 .LPR53: popl%rdx addl$_GLOBAL_OFFSET_TABLE_+[.-.LPR53],%rdx / 0 2 /NO_APP Line 91:popl%rdx Line 92:addl$_GLOBAL_OFFSET_TABLE_+[.-.LPR53],%rdx Tossing an -m32 into the end of the xgcc ... command will compile without errors. Thus, I conclude that the -m32 for gcc (which does produce an --64 for the assembler) is somehow giving us 32 bit code instead of 64 bit. Investigating ... Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39186
[Bug target/39186] Configury incorrect for 64-bit Targets on Solaris
--- Comment #4 from rob1weld at aol dot com 2009-02-14 02:08 --- Correction, should have said: -Thus, I conclude that the -m32 for +Thus, I conclude that the -m64 for -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39186
[Bug target/39186] Configury incorrect for 64-bit Targets on Solaris
--- Comment #5 from rob1weld at aol dot com 2009-02-14 02:48 ---
I forced that 32 bit and continued, failing here:
T=`${PWDCMD-pwd}`/ \
cd ../../.././gcc \
gmake GCC_FOR_TARGET=/usr/share/src/gcc_build/./gcc/xgcc
-B/usr/share/src/gcc_build/./gcc/ -B/usr/local/x86_64-pc-solaris2.11/bin/
-B/usr/local/x86_64-pc-solaris2.11/lib/ -isystem
/usr/local/x86_64-pc-solaris2.11/include -isystem
/usr/local/x86_64-pc-solaris2.11/sys-include \
MULTILIB_CFLAGS=-g -O2 -m64 \
T=$T \
T_TARGET=${T}crtbegin.o ${T}crtend.o ${T}gmon.o \
T_TARGET
gmake[5]: Entering directory `/usr/share/src/gcc_build/gcc'
/usr/share/src/gcc_build/./gcc/xgcc -B/usr/share/src/gcc_build/./gcc/
-B/usr/local/x86_64-pc-solaris2.11/bin/ -B/usr/local/x86_64-pc-solaris2.11/lib/
-isystem /usr/local/x86_64-pc-solaris2.11/include -isystem
/usr/local/x86_64-pc-solaris2.11/sys-include -O2 -g -O2 -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -DNATIVE_CROSS -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition
-isystem ./include -I.
-I/usr/share/src/gcc_build/x86_64-pc-solaris2.11/amd64/libgcc
-I../../gcc_trunk/gcc
-I../../gcc_trunk/gcc//usr/share/src/gcc_build/x86_64-pc-solaris2.11/amd64/libgcc
-I../../gcc_trunk/gcc/../include -I./../intl
-I../../gcc_trunk/gcc/../libcpp/include -I/usr/local/include
-I/usr/local/include -I../../gcc_trunk/gcc/../libdecnumber
-I../../gcc_trunk/gcc/../libdecnumber/dpd -I../libdecnumber -g -O2 -m64 -g0
-finhibit-size-directive -fno-inline-functions -fno-exceptions
-fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize
-Dinhibit_libc \
-c ../../gcc_trunk/gcc/crtstuff.c -DCRT_END \
-o /usr/share/src/gcc_build/x86_64-pc-solaris2.11/amd64/libgcc/crtend.o
gmake[5]: *** No rule to make target
`/usr/share/src/gcc_build/x86_64-pc-solaris2.11/amd64/libgcc/gmon.o', needed by
`T_TARGET'. Stop.
gmake[5]: Leaving directory `/usr/share/src/gcc_build/gcc'
gmake[4]: *** [gcc-extra-parts] Error 2
gmake[4]: Leaving directory
`/usr/share/src/gcc_build/x86_64-pc-solaris2.11/amd64/libgcc'
gmake[3]: *** [multi-do] Error 1
gmake[3]: Leaving directory
`/usr/share/src/gcc_build/x86_64-pc-solaris2.11/libgcc'
gmake[2]: *** [all-multi] Error 2
gmake[2]: Leaving directory
`/usr/share/src/gcc_build/x86_64-pc-solaris2.11/libgcc'
gmake[1]: *** [all-target-libgcc] Error 2
gmake[1]: Leaving directory `/usr/share/src/gcc_build'
gmake: *** [all] Error 2
If I run locate this is the partial output:
# slocate gmon.o
...
/usr/local/lib/gcc/i386-pc-solaris2.11/4.4.0/amd64/gmon.o
/usr/local/lib/gcc/i386-pc-solaris2.11/4.4.0/gmon.o
/usr/share/src/gcc_build/gcc/amd64/gmon.o
/usr/share/src/gcc_build/gcc/gmon.o
/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libgcc/gmon.o
/usr/share/src/gcc_build/i386-pc-solaris2.11/libgcc/gmon.o
/usr/share/src/gcc_build/prev-gcc/amd64/gmon.o
/usr/share/src/gcc_build/prev-gcc/gmon.o
/usr/share/src/gcc_build/prev-i386-pc-solaris2.11/amd64/libgcc/gmon.o
/usr/share/src/gcc_build/prev-i386-pc-solaris2.11/libgcc/gmon.o
/usr/share/src/gcc_build/stage1-gcc/amd64/gmon.o
/usr/share/src/gcc_build/stage1-gcc/gmon.o
/usr/share/src/gcc_build/stage1-i386-pc-solaris2.11/amd64/libgcc/gmon.o
/usr/share/src/gcc_build/stage1-i386-pc-solaris2.11/libgcc/gmon.o
Fortunately I am not _really_ cross compiling so I can cheat and
simply copy a 'gmon.o' where I need it. IF someone were actually
cross-compiling the scripts would be too broken to work for them.
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39186
[Bug target/39186] Configury incorrect for 64-bit Targets on Solaris
--- Comment #6 from rob1weld at aol dot com 2009-02-14 03:39 --- I wonder if I discovered a regression ... If I compile with gcc version 4.4.0 20090213 (experimental) [trunk revision 144149] it produces a little of 32-bit code that is not going to get compiled with all the -m64 and --64's on the command lines (and NO '32' stuff). I end up with this error: /usr/local/bin/as -v -I. -I/usr/share/src/gcc_build/x86_64-pc-solaris2.11/amd64/libgcc -I../../gcc_trunk/gcc -I../../gcc_trunk/gcc//usr/share/src/gcc_build/x86_64-pc-solaris2.11/amd64/libgcc -I../../gcc_trunk/gcc/../include -I./../intl -I../../gcc_trunk/gcc/../libcpp/include -I/usr/local/include -I/usr/local/include -V -Qy --64 -s -o /usr/share/src/gcc_build/x86_64-pc-solaris2.11/amd64/libgcc/crtbegin.o crtstuff.s GNU assembler version 2.19.1 (i386-pc-solaris2.11) using BFD version (GNU Binutils) 2.19.1 crtstuff.s: Assembler messages: crtstuff.s:106: Error: suffix or operands invalid for `pop' crtstuff.s:107: Error: Incorrect register `%rdx' used with `l' suffix If I compile with gcc version 4.0.2 it says this: ../../gcc_trunk/gcc/crtstuff.c:0: sorry, unimplemented: 64-bit mode not compiled in That is a more helpful error message, now to investigate if it is true. # /opt/csw/gcc4/bin/gcc -v Reading specs from /opt/csw/gcc4/lib/gcc/i386-pc-solaris2.8/4.0.2/specs Target: i386-pc-solaris2.8 Configured with: ../sources/gcc-4.0.2/configure --prefix=/opt/csw/gcc4 --with-local-prefix=/opt/csw --with-gnu-as --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix --enable-shared --enable-multilib --enable-nls --with-included-gettext --with-libiconv-prefix=/opt/csw --with-x --enable-java-awt=xlib --with-system-zlib --enable-languages=c,c++,f95,java,objc,ada Thread model: posix gcc version 4.0.2 Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39186
[Bug target/39186] Configury incorrect for 64-bit Targets on Solaris
--- Comment #7 from rob1weld at aol dot com 2009-02-14 04:17 ---
I grepped for CRT_GET_RFIB_DATA and found a definition at the tail of:
/usr/share/src/gcc_trunk/gcc/config/frv/frv.h .
Here is ../gcc_trunk/gcc/crtstuff.c :
static void __attribute__((used))
frame_dummy (void)
{ ...
and the error:
/usr/local/bin/as -v -I.
-I/usr/share/src/gcc_build/x86_64-pc-solaris2.11/amd64/libgcc
-I../../gcc_trunk/gcc
-I../../gcc_trunk/gcc//usr/share/src/gcc_build/x86_64-pc-solaris2.11/amd64/libgcc
-I../../gcc_trunk/gcc/../include -I./../intl
-I../../gcc_trunk/gcc/../libcpp/include -I/usr/local/include
-I/usr/local/include -I../../gcc_trunk/gcc/../libdecnumber
-I../../gcc_trunk/gcc/../libdecnumber/dpd -I../libdecnumber -V -Qy --64 -s -o
/usr/share/src/gcc_build/x86_64-pc-solaris2.11/amd64/libgcc/crtbegin.o
crtstuff.s
GNU assembler version 2.19.1 (i386-pc-solaris2.11) using BFD version (GNU
Binutils) 2.19.1
crtstuff.s: Assembler messages:
crtstuff.s:91: Error: suffix or operands invalid for `pop'
crtstuff.s:92: Error: Incorrect register `%rdx' used with `l' suffix
Here is a (likely incorrect) modification:
#define CRT_GET_RFIB_DATA(dbase) \
({ extern void *_GLOBAL_OFFSET_TABLE_; (dbase) = _GLOBAL_OFFSET_TABLE_; })
static void __attribute__((used))
frame_dummy (void)
{ ...
but no error messages ... So the existing definition (if I can locate it)
is borked and hardwired 32 bit. It could be a file created by a script
or a static (non-created) file. Slowly I inch forward ...
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39186
[Bug target/39186] Configury incorrect for 64-bit Targets on Solaris
--- Comment #8 from rob1weld at aol dot com 2009-02-14 04:36 --- (In reply to comment #7) ... Slowly I inch forward ... and go back ... /usr/local/bin/ld: /usr/share/src/gcc_build/./gcc/amd64/crtbegin.o: relocation R_X86_64_32 against `__DTOR_END__' can not be used when making a shared object; recompile with -fPIC We need to build 'crtbegin.o' using '-fPIC' - works. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39186
[Bug c++/39070] [4.3/4.4 regression] ICE with typeof() (... and __decltype)
--- Comment #9 from jason at gcc dot gnu dot org 2009-02-14 05:42 --- Fixed in 4.3 and 4.4. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39070
[Bug c/39190] New: gcc 4.4.0 20090214 - Use of -v and --save-temps alters gcc operation
I am trying to derive a minimal Testcase for a Bug found in:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39186
d# gcc/xgcc -v
Using built-in specs.
Target: x86_64-pc-solaris2.11
Configured with: ../gcc_trunk/configure --build=i386-pc-solaris2.11
--target=x86_64-pc-solaris2.11
--enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared
--disable-static --enable-multilib --enable-decimal-float
--with-long-double-128 --with-included-gettext --enable-stage1-checking
--enable-checking=release --with-tune=k8 --with-cpu=k8 --with-arch=k8
--with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld
--with-ld=/usr/local/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local
--without-ppl
Thread model: posix
gcc version 4.4.0 20090214 (experimental) [trunk revision 144177] (GCC)
I discovered this Bug while compiling 'crtbegin.c' so the code and
the gcc compile options are entirely derived from these (and not
as minimal a Testcase as I would like).
--
We will use this C source code:
# cat test_gcc_assembler.c
/* FIXME: Including auto-host is incorrect, but until we have
identified the set of defines that need to go into auto-target.h,
this will have to do. */
#include auto-host.h
#undef gid_t
#undef pid_t
#undef rlim_t
#undef ssize_t
#undef uid_t
#undef vfork
#include tconfig.h
#include tsystem.h
#include coretypes.h
//#include tm.h
#include unwind-dw2-fde.h
extern unsigned char __EH_FRAME_BEGIN__[];
/* Used by crtstuff.c to initialize the base of data-relative relocations.
These are GOT relative on x86, so return the pic register. */
#ifdef __PIC__
#define CRT_GET_RFIB_DATA(BASE) \
{ \
register void *ebx_ __asm__(ebx); \
BASE = ebx_;\
}
#else
#define CRT_GET_RFIB_DATA(BASE) \
__asm__ (call\t.LPR%=\n \
.LPR%=:\n\t\
pop{l}\t%0\n\t \
/* Due to a GAS bug, this cannot use EAX. That encodes \
smaller than the traditional EBX, which results in the\
offset being off by one. */ \
add{l}\t{$_GLOBAL_OFFSET_TABLE_+[.-.LPR%=],%0 \
|%0,_GLOBAL_OFFSET_TABLE_+(.-.LPR%=)} \
: =d(BASE))
#endif
static void __attribute__((used))
frame_dummy (void)
{
static struct object object;
#ifdef CRT_GET_RFIB_DATA
void *tbase, *dbase;
tbase = 0;
CRT_GET_RFIB_DATA (dbase);
if (__register_frame_info_bases)
__register_frame_info_bases (__EH_FRAME_BEGIN__, object, tbase, dbase);
#else
if (__register_frame_info)
__register_frame_info (__EH_FRAME_BEGIN__, object);
#endif /* CRT_GET_RFIB_DATA */
}
--
We will compile two ways:
1. With -v --save-temps added to the gcc command line.
2. Without anything added to the gcc command line.
The Original command to compile crtbegin.c (and create crtbegin.s) is:
/usr/share/src/gcc_build/./gcc/xgcc -B/usr/share/src/gcc_build/./gcc/
-B/usr/local/x86_64-pc-solaris2.11/bin/ -B/usr/local/x86_64-pc-solaris2.11/lib/
-isystem /usr/local/x86_64-pc-solaris2.11/include -isystem
/usr/local/x86_64-pc-solaris2.11/sys-include -O2 -g -O2 -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -DNATIVE_CROSS -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition
-isystem ./include -I.
-I/usr/share/src/gcc_build/x86_64-pc-solaris2.11/amd64/libgcc
-I../../gcc_trunk/gcc
-I../../gcc_trunk/gcc//usr/share/src/gcc_build/x86_64-pc-solaris2.11/amd64/libgcc
-I../../gcc_trunk/gcc/../include -I./../intl
-I../../gcc_trunk/gcc/../libcpp/include -I/usr/local/include
-I/usr/local/include -I../../gcc_trunk/gcc/../libdecnumber
-I../../gcc_trunk/gcc/../libdecnumber/dpd -I../libdecnumber -g -O2 -m64 -g0
-finhibit-size-directive -fno-inline-functions -fno-exceptions
-fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize
-Dinhibit_libc \
-c ../../gcc_trunk/gcc/crtstuff.c -DCRT_BEGIN \
-o /usr/share/src/gcc_build/x86_64-pc-solaris2.11/amd64/libgcc/crtbegin.o
and it was giving these errors:
/var/tmp//ccqMaidK.s: Assembler messages:
/var/tmp//ccqMaidK.s:91: Error: suffix or operands invalid for `pop'
/var/tmp//ccqMaidK.s:92: Error: Incorrect register `%rdx' used with `l' suffix
gmake[5]: ***
[/usr/share/src/gcc_build/x86_64-pc-solaris2.11/amd64/libgcc/crtbegin.o] Error
1
gmake[5]: Leaving directory `/usr/share/src/gcc_build/gcc'
gmake[4]: *** [gcc-extra-parts] Error 2
gmake[4]: Leaving directory
`/usr/share/src/gcc_build/x86_64-pc-solaris2.11/amd64/libgcc'
gmake[3]: *** [multi-do] Error 1
gmake[3]: Leaving directory
`/usr/share/src/gcc_build/x86_64-pc-solaris2.11/libgcc'
gmake[2]: *** [all-multi] Error 2
gmake[2]: Leaving directory
`/usr/share/src/gcc_build/x86_64-pc-solaris2.11/libgcc'
