[Bug target/27308] Compiler generates incorrect code when calling a function with the result of an inline function as parameter
--- Comment #6 from Eric dot Doenges at betty-tv dot com 2006-04-26 06:26
---
Unfortunately, removing the __asm__ ("r0") from __r0 does not circumvent the
problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27308
[Bug fortran/27304] gfortran: Warn/abort when format in write does not fit passed arguments
--- Comment #4 from tobias dot burnus at physik dot fu-berlin dot de 2006-04-26 06:22 --- Subject: Re: gfortran: Warn/abort when format in write does not fit passed arguments > I wonder if this is a case of illegal code. Intel errors on "infinite > format". Well, current g95, ifort 9/9.1, pgf95 6.0, pathscale and NAG f95 regard it as such and abort the execution or (NAG, today's g95) error on compilation. In the 2004-05 "Fortran 2003" draft (10.3) I find: "If an input/output list specifies at least one effective list item, at least one data edit descriptor shall exist in the format specification." For the compile-time I thus would really regard it as error. What the best behaviour for the run time is, is however debatable. (Abort [most compilers], ignore [g77, gfortran], ignore & warn [no compiler?].) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27304
Typecast bug
It is gcc 4.1.0, --target=arm-elf compiled on an Intel platform and GNU/Linux. The following construct: void *p; ((char *)p)++; makes the compiler to issue an error message, namely "invalid lvalue in increment" The ((char *)p) construct is perfectly valid object, a char pointer which can be lvalue and rvalue alike. For some reason gcc 4.1.0 (and 4.0.2 as well) treats ((SOME_TYPE *)p) as if it could not be an lvalue; older versions treat the expression (as expected) as if p was a pointer to SOME_TYPE instead of to void. This is true even if -std=c89 is specified, and according to the old ANSI standard the above construct most definitely is a valid lvalue. Best Regards, Zoltan
[Bug fortran/27304] gfortran: Warn/abort when format in write does not fit passed arguments
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-04-26 04:10 --- I am not sure (emphasis on not sure) I agree with this. But I can explain what it is doing. It is correctly printing out the letter 'n' then its looking for the first data item and finds the integer in the list, it reverts on the format statement, performs it and then its done because there are no more data items. At least its logical. :) I wonder if this is a case of illegal code. Intel errors on "infinite format". In other words it keeps reverting looking for a format specifier. gfortran is format driven until there is no more data. g77 exactly matches gfortran in behavior. We should check the standard. Is it required that there is a data format specifier? If not, then this could be an enhancement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27304
[Bug target/26961] [4.0/4.1/4.2 Regression] ICE simplify_subreg:3813
--- Comment #7 from sayle at gcc dot gnu dot org 2006-04-26 03:21 --- Subject: Bug 26961 Author: sayle Date: Wed Apr 26 03:20:56 2006 New Revision: 113266 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113266 Log: PR target/26961 * fold-const.c (fold): When converting "A ? B : C" into either "A op B" or "A op C", we may need to convert A to the type of B and C. * gcc.dg/fold-cond-1.c: New test case. * gcc.dg/pr26961-1.c: Likewise. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/fold-cond-1.c branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/pr26961-1.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/fold-const.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26961
[Bug java/10894] Wildcard import statements not resolved
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-04-26 02:44 --- *** Bug 27280 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||michele at focuseek dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10894
[Bug java/27280] gcj cannot import inner classes using a wildcard import
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-26 02:44 --- *** This bug has been marked as a duplicate of 10894 *** -- 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=27280
[Bug debug/21391] [4.0/4.1/4.2 Regression] referencing a type via a cast does not emit it for debug (feliminate-unused-debug-types)
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-26 02:40 --- Did I mention this fails on powerpc-darwin? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21391
[Bug middle-end/27321] Compare against constant infinity fails with IBM long double format
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-26 02:27 --- This works in the mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27321
[Bug middle-end/27321] New: Compare against constant infinity fails with IBM long double format
Test code:
long double x = __builtin_infl();
int main() {
int r = x == __builtin_infl();
return r ? 0 : 1;
}
Commands to reproduce:
gcc -mlong-double-128 tc.c
./a.out && echo ok || echo fail
No problem with -mlong-double-64.
Cause:
GCC first transforms (x == infinity) to (x > long_double_max_val).
The maximum value returned by real_maxval is encoded as infinity due
to rounding in encode_ibm_extended. This does not happen with the
LDBL_MAX declared in system headers because one of the bits is
cleared.
Potential fix:
--- real.c.orig 2005-09-19 12:56:24.0 -0400
+++ real.c 2006-04-25 21:18:32.0 -0400
@@ -2205,6 +2205,8 @@ real_maxval (REAL_VALUE_TYPE *r, int sig
np2 = SIGNIFICAND_BITS - fmt->p * fmt->log2_b;
memset (r->sig, -1, SIGSZ * sizeof (unsigned long));
clear_significand_below (r, np2);
+ if (REAL_MODE_FORMAT_COMPOSITE_P (mode))
+ clear_significand_bit (r, SIGNIFICAND_BITS - fmt->pnan - 1);
}
--
Summary: Compare against constant infinity fails with IBM long
double format
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dvdfrdmn at users dot sf dot net
GCC target triplet: powerpc-apple-darwin8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27321
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #94 from pinskia at gcc dot gnu dot org 2006-04-26 02:13 --- *** Bug 26846 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||laszlo dot szakony at ||philips dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug c++/26846] hidden visibility of static member in class derived from hash_map changes to default visibility
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-26 02:13 --- Oh, if you had put how you involved gcc in the comments instead of in build script, I would have seen what the problem is. Anyways this is a dup of bug 19664. The problem is the libstdc++'s headers don't have push/pop of the visibility. *** This bug has been marked as a duplicate of 19664 *** -- 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=26846
[Bug driver/27314] ld can't find libgfortran.so.1 on x86-64
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-04-26 00:56 --- My experiance has been that if you have gfortran installed from a distribution such as Fedora and you build your own later version of gfortran from source and you do not configure the later version to install in its own place and you do not set LD_LIBRARY_PATH to point to that place, you will get this error. It tries to use the libary from the distribution which is typically 4.0.x and gives that error. Try: export LD_LIBRARY_PATH=/scr_bar/johan/local/lib Also I am not sure about using commas in the compile command to separate things. Maybe use -rpath /scr_bar.johan/local/lib without that comma in between. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27314
[Bug rtl-optimization/26855] [4.2 Regression] ICE in add_deps_for_def with -fmodulo-sched -maltivec
--- Comment #2 from janis at gcc dot gnu dot org 2006-04-25 23:49 --- The patch that introduced this failure also causes the same ICE in several SPEC CPU2000 programs on powerpc64-linux for "-O2 -fmodulo-sched" with either -m32 or -m64. I haven't tried the patch that was supposed to fix the reported bug, http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01642.html, or the follow-up smaller patches which don't seem to have been reviewed yet. I'm willing to test the proposed patch(es), including building SPEC CPU2000 with multiple sets of options and running the small, test input. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26855
[Bug target/27319] C++ class object destructors are not called for static class objects in a shared library when dlclose is called.
--- Comment #4 from hbd_bugreports at earthlink dot net 2006-04-25 23:46 --- Subject: Re: C++ class object destructors are not called for static class objects in a shared library when dlclose is called. pinskia at gcc dot gnu dot org wrote: >--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-25 22:14 >--- >(In reply to comment #2) > > >>Subject: Re: C++ class object destructors are not called >> for static class objects in a shared library when dlclose is called. >>So You are telling me this is not a gcc problem but a limitation in >>CYGWIN. (I'm not really surprised.) >>... In which case I resort to my work-around of eliminating static class >>objects declared in the body of functions that will be used in the >>shared library. >>Thanks for the prompt reply, >>Harry Dellicker >> >> > > >No, it is a GCC bug but it is hard to get fixed really as you need to implement >an __cxa_atexit for Windows. Now Cygwin could implement __cxa_atexit but that >does not help other windows targets. > > > > Ok, thanks for the clarification. ...But, for now, I guess I still have to resort to my workaround. :-( At least I do have a workaround. Harry -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27319
[Bug libmudflap/26864] multithreaded mudflap not working
--- Comment #5 from pr2345 at gmail dot com 2006-04-25 23:29 --- The man page/online manual also needs a small clarification. It only mentions the libmudflap library and not libmudflapth. I assume a multithreaded program should link with -lmudflapth instead of -lmudflap? Should I create a separate bug report for this, or can you take care of it in the same one? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26864
[Bug target/27319] C++ class object destructors are not called for static class objects in a shared library when dlclose is called.
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-25 22:14 --- (In reply to comment #2) > Subject: Re: C++ class object destructors are not called > for static class objects in a shared library when dlclose is called. > So You are telling me this is not a gcc problem but a limitation in > CYGWIN. (I'm not really surprised.) > ... In which case I resort to my work-around of eliminating static class > objects declared in the body of functions that will be used in the > shared library. > Thanks for the prompt reply, > Harry Dellicker No, it is a GCC bug but it is hard to get fixed really as you need to implement an __cxa_atexit for Windows. Now Cygwin could implement __cxa_atexit but that does not help other windows targets. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27319
[Bug target/27319] C++ class object destructors are not called for static class objects in a shared library when dlclose is called.
--- Comment #2 from hbd_bugreports at earthlink dot net 2006-04-25 22:07 --- Subject: Re: C++ class object destructors are not called for static class objects in a shared library when dlclose is called. So You are telling me this is not a gcc problem but a limitation in CYGWIN. (I'm not really surprised.) ... In which case I resort to my work-around of eliminating static class objects declared in the body of functions that will be used in the shared library. Thanks for the prompt reply, Harry Dellicker pinskia at gcc dot gnu dot org wrote: >--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 21:31 >--- >Yes, this is a target specific issue. If the target does not support atexit, >this is what will happen. > > > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27319
[Bug fortran/27320] New: ICE with -fdump-parse-tree after error
This ICE happens after the error message with $ cat gen.f90 module generic interface foo module procedure foo_real end interface foo contains subroutine foo_real(a) real :: a end subroutine foo_real end module generic program main use generic call foo(1) end program main $ gfortran -fdump-parse-tree gen.f90 Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4) procedure name = generic symtree: foo Ambig 0 symbol foo (UNKNOWN 0)(PROCEDURE UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC) Generic interfaces: foo_real symtree: generic Ambig 0 symbol generic (UNKNOWN 0)(MODULE UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC) symtree: foo_real Ambig 0 symbol foo_real (UNKNOWN 0)(PROCEDURE UNKNOWN-INTENT UNKNOWN-ACCESS MODULE-PROC SUBROUTINE) Formal arglist: a CONTAINS Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4) procedure name = foo_real symtree: foo_real Ambig 0 from namespace generic symtree: a Ambig 0 symbol a (REAL 4)(VARIABLE UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC DUMMY) In file gen.f90:12 call foo(1) 1 Error: Generic subroutine 'foo' at (1) is not an intrinsic subroutine Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4) procedure name = MAIN__ symtree: generic Ambig 0 symbol generic (UNKNOWN 0)(MODULE UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC USE-ASSOC) symtree: MAIN__ Ambig 0 symbol MAIN__ (UNKNOWN 0)(PROCEDURE UNKNOWN-INTENT PUBLIC UNKNOWN-PROC SUBROUTINE) symtree: foo Ambig 0 symbol foo (UNKNOWN 0)(PROCEDURE UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC USE-ASSOC) Generic interfaces: foo_real symtree: foo_real Ambig 0 symbol foo_real (UNKNOWN 0)(PROCEDURE UNKNOWN-INTENT UNKNOWN-ACCESS MODULE-PROC USE-ASSOC SUBROUTINE) Formal arglist: a Formal namespace Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4) procedure name = foo_real symtree: @0 Ambig 0 symbol a (REAL 4)(VARIABLE UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC DUMMY USE-ASSOC) symtree: main Ambig 0 symbol main (UNKNOWN 0)(PROGRAM UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC) gen.f90:3: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: ICE with -fdump-parse-tree after error Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27320
[Bug rtl-optimization/26725] [4.2 Regression] ICE in check_reg_live, at haifa-sched.c:4645 with -O2 on ia64
--- Comment #6 from rsandifo at gcc dot gnu dot org 2006-04-25 21:36 --- Patch applied to trunk. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26725
[Bug c++/27279] [4.0/4.1/4.2 regression] ICE with invalid constructor declaration
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||04/msg00930.html Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-25 21:35:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27279
[Bug c++/27278] [4.0/4.1/4.2 regression] ICE with invalid operator declaration
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||04/msg00929.html Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2006-04-25 21:34:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27278
[Bug rtl-optimization/26725] [4.2 Regression] ICE in check_reg_live, at haifa-sched.c:4645 with -O2 on ia64
--- Comment #5 from rsandifo at gcc dot gnu dot org 2006-04-25 21:34 --- Subject: Bug 26725 Author: rsandifo Date: Tue Apr 25 21:34:48 2006 New Revision: 113257 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113257 Log: gcc/ PR rtl-optimization/26725 * cfgrtl.c (rtl_redirect_edge_and_branch_force): Set the source block's BB_DIRTY flag. gcc/testsuite/ * gcc.c-torture/compile/pr26725.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr26725.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgrtl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26725
[Bug c++/27309] [4.0/4.1/4.2 regression] ICE on invalid constructor definition
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 21:32 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-25 21:32:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27309
[Bug ada/26678] "GNAT BUG DETECTED" when compiling AWS.
--- Comment #9 from george dot chapman at lmco dot com 2006-04-25 21:32 --- *** Bug 27186 has been marked as a duplicate of this bug. *** -- george dot chapman at lmco dot com changed: What|Removed |Added CC||george dot chapman at lmco ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26678
[Bug ada/27186] GNAT BUG DETECTED with Booch Components Set_Test_Support
--- Comment #8 from george dot chapman at lmco dot com 2006-04-25 21:32 --- *** This bug has been marked as a duplicate of 26678 *** -- george dot chapman at lmco dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27186
[Bug target/27319] C++ class object destructors are not called for static class objects in a shared library when dlclose is called.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 21:31 --- Yes, this is a target specific issue. If the target does not support atexit, this is what will happen. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Status|UNCONFIRMED |NEW Component|c++ |target Ever Confirmed|0 |1 GCC host triplet|CYGWIN (Current version), | |Win 2k | GCC target triplet||win32 Last reconfirmed|-00-00 00:00:00 |2006-04-25 21:31:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27319
[Bug ada/27186] GNAT BUG DETECTED with Booch Components Set_Test_Support
--- Comment #7 from george dot chapman at lmco dot com 2006-04-25 21:31 --- I agree. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27186
[Bug target/27282] [4.2 regression] ICE in final_scan_insn, at final.c:2448 - could not split insn
--- Comment #10 from janis at gcc dot gnu dot org 2006-04-25 21:16 --- A regression hunt of trunk on powerpc-linux using mini.c with -O2 identified: http://gcc.gnu.org/viewcvs?view=rev&rev=109016 r109016 | bonzini | 2005-12-23 16:07:53 + (Fri, 23 Dec 2005) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27282
[Bug libgomp/25865] [4.2 Regression] libgomp incorrectly detects support for TLS
--- Comment #6 from rth at gcc dot gnu dot org 2006-04-25 21:03 --- Fixed, or if not, moved the point of failure out of libgomp. -- rth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25865
[Bug libgomp/25865] [4.2 Regression] libgomp incorrectly detects support for TLS
--- Comment #5 from rth at gcc dot gnu dot org 2006-04-25 20:58 --- Subject: Bug 25865 Author: rth Date: Tue Apr 25 20:58:25 2006 New Revision: 113256 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113256 Log: PR libgomp/25865 * configure.ac: Use GCC_CHECK_TLS. * acinclude.m4 (LIBGOMP_CHECK_TLS): Remove. * Makefile.in, aclocal.m4, configure: Regenerate. Modified: trunk/libgomp/ChangeLog trunk/libgomp/Makefile.in trunk/libgomp/acinclude.m4 trunk/libgomp/aclocal.m4 trunk/libgomp/configure trunk/libgomp/configure.ac trunk/libgomp/testsuite/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25865
[Bug libgomp/25865] [4.2 Regression] libgomp incorrectly detects support for TLS
-- rth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-02-02 23:45:50 |2006-04-25 20:54:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25865
[Bug c++/27319] New: C++ class object destructors are not called for static class objects in a shared library when dlclose is called.
For C++ classes of any type, the class destructor fails to be called under the
following circumstances in the CYGWIN environment (not a problem in linux):
1) A static object of a class is declared within the body of a function which
is part of a shared library.
2) The shared library is loaded with dlopen, the function in question is
called, then the shared library is unloaded with dlclose.
Sample code:
// -
// File mymain.C
// -
#include
using namespace std;
#include
extern "C" void printit();
int main()
{
void * LibraryHandle = dlopen("./mylib.sl", RTLD_LAZY);
if(LibraryHandle)
{
void (*Printit)() = ( void (*)() )dlsym(LibraryHandle, "printit");
(*Printit)();
cout<<"Close library"<
extern "C" void printit();
class KStr
{
public:
KStr(const char*);
~KStr();
char StrBuf[20];
};
KStr::KStr(const char*Str)
{
strcpy(StrBuf, Str);
}
KStr::~KStr()
{
cout
[Bug tree-optimization/22525] tree based value profiling (-fprofile-use) produces mismatch types in conditional
--- Comment #7 from brett dot albertson at stratech dot com 2006-04-25 19:29 --- (In reply to comment #6) > Fixed. > After this patch was applied onto trunk, the following test started failing on Solaris x86: FAIL: gcc.dg/tree-prof/val-prof-2.c scan-tree-dump n \+ \-1 All the other val-prof-2.c tests PASS. Any ideas? Brett Albertson -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22525
[Bug middle-end/27313] Does not emit conditional moves for stores
--- Comment #3 from dwarak dot rajagopal at amd dot com 2006-04-25 19:07
---
Yes this is true. The example I posted was a simplest case where it fails.
Below mmight be a typical case where you have to do two stores.
int cmov(int* A ,int B ,int C ,int* D ,int* E ,int F ,int g) {
int k,f;
for (k = 1; k <= 1000; k++) {
A[k] = B+C;
D[k] = C; /* D[k] may alias with A[k] */
g = D[k-1] + E[k-1];
if (g > A[k]) A[k]=g; /* This is not converted to cmov*/
f += g;
}
return f;
}
In this case, you cannot reduce the number of stores (becasue D[k] may alias
with A[k]) but you still want the if conversion to take place. I think it is
good to have a mechanism to track if a memory is already been written in ifcvt.
I'm not sure how it can be done at this level though.
-Dwarak
(In reply to comment #2)
> The other way of getting this is to have the code converted so there is only
> one store instead of two:
>
> int cmov(int* A ,int B ,int C ,int* D ,int* E ,int F ,int g) {
> int k,f;
> for (k = 1; k <= 1000; k++) {
> int t = B+C;
> g = D[k-1] + E[k-1];
> if (g > t) t=g; /* This is not converted to cmov*/
> A[K] = t;
> f += g;
> }
> return f;
> }
> Which is most likely better anyways as one it is smaller.
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27313
[Bug c/27301] [4.0/4.1/4.2 Regression] ICE on convoluted inline asm with "m" (statement expression and vla)
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-25 18:47 ---
Hmm, interesting, we have a TARGET_EXPR before gimplifying:
__asm__ __volatile__(""::"m" TARGET_EXPR - 1)];
} struct struct
{
char x[0:(unsigned int) ((int) SAVE_EXPR - 1)];
};
struct
{
char x[0:(unsigned int) ((int) SAVE_EXPR - 1)];
} * p = (struct
{
char x[0:(unsigned int) ((int) SAVE_EXPR - 1)];
} *) ptr;
Which might be the real issue.
The C++ front-end rejects this code as a VLA type is invalid even for GNU C++.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|inline-asm |c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27301
[Bug inline-asm/27301] [4.0/4.1/4.2 Regression] ICE on convoluted inline asm with "m" (statement expression and vla)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 18:41 --- Confirmed, the ICE is at least a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.1.0 4.0.0 4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-04-25 18:41:51 date|| Summary|ICE on convoluted inline asm|[4.0/4.1/4.2 Regression] ICE |with "m" (statement |on convoluted inline asm |expression and vla) |with "m" (statement ||expression and vla) Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27301
[Bug fortran/27318] gfortran should warn if a interface does not match
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 18:39 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-25 18:39:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27318
[Bug driver/27314] ld can't find libgfortran.so.1 on x86-64
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-25 18:38 --- You must be doing something wrong as I know this works for me and many other people. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27314
[Bug middle-end/27313] Does not emit conditional moves for stores
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-25 18:38 ---
The other way of getting this is to have the code converted so there is only
one store instead of two:
int cmov(int* A ,int B ,int C ,int* D ,int* E ,int F ,int g) {
int k,f;
for (k = 1; k <= 1000; k++) {
int t = B+C;
g = D[k-1] + E[k-1];
if (g > t) t=g; /* This is not converted to cmov*/
A[K] = t;
f += g;
}
return f;
}
Which is most likely better anyways as one it is smaller.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27313
[Bug target/27308] Compiler generates incorrect code when calling a function with the result of an inline function as parameter
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27308
[Bug fortran/27304] gfortran: Warn/abort when format in write does not fit passed arguments
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-25 18:33 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-25 18:33:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27304
[Bug middle-end/27310] ICE in duplicate_eh_regions
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 18:32 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-25 18:32:51 date|| Summary|ICE in duplicate_eh_regions |ICE in duplicate_eh_regions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27310
[Bug c++/27309] [4.0/4.1/4.2 regression] ICE on invalid constructor definition
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27309
[Bug c++/27292] [4.2 regression] ICE on casts on bitfields
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27292
[Bug middle-end/27302] Fold does not fold (i < j) == (j > i) to 1
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 18:31 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-25 18:31:38 date|| Summary|Fold does not fold i < j == |Fold does not fold (i < j) |j > i to 1 |== (j > i) to 1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27302
[Bug c++/27316] ICE with two ill-placed #pragma omp parallel
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 18:29 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-25 18:29:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27316
[Bug c++/27315] ICE with ill-placed #pragma omp parallel
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 18:28 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-25 18:28:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27315
[Bug fortran/27318] New: gfortran should warn if a interface does not match
Test case: -- module test implicit none interface subroutine hello(n) integer :: n end subroutine hello end interface end module test subroutine hello(n) integer, intent(in) :: n integer :: i do i = 1,n; print *, 'hello'; end do end subroutine hello -- In the interface, "n" is implicitly "intent(inout)". gfortran -Wall does not warn, NAG f95 does: Error: test3.f90: Inconsistent INTERFACE block for procedure HELLO from TEST Argument N (no. 1) has a different INTENT [f95 error termination] -- Summary: gfortran should warn if a interface does not match Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27318
[Bug fortran/27317] :0: internal compiler error: Illegal instruction
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 17:43 --- This is the not form for support for binaries. We only support GCC which was been compiled by your self. -- 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=27317
[Bug driver/27314] ld can't find libgfortran.so.1 on x86-64
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 17:41 --- This works for me and many other people. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Component|fortran |driver http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27314
[Bug middle-end/27313] Does not emit conditional moves for stores
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 17:38 --- Confirmed, if cvt should have a way to track if a memory write has happened. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |middle-end Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-25 17:38:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27313
[Bug tree-optimization/27299] [4.1 Regression] vectorizer generates aligned accesses to unaligned memory
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-25 17:35 --- (In reply to comment #5) > Yes, but the problem appears with -O1 which has -fno-strict-aliasing. Now > whether -fno-strict-aliasing makes the testcase valid is another question ;) Nope, unaligned access is different from strict aliasing. With the cast to uint64_t* you say the alignment is correct for that type. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27299
[Bug target/27303] crash at unalign access
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-25 17:28 --- We need a testcase to go any further. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27303
[Bug other/14704] -static-libgcc option appears non-functional under Solaris
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-25 17:25 --- *** Bug 27276 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||jkanze at cheuvreux dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14704
[Bug driver/27276] Option -static-libgcc doesn't work
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 17:25 --- Read PR 14704. *** This bug has been marked as a duplicate of 14704 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27276
[Bug c++/26846] hidden visibility of static member in class derived from hash_map changes to default visibility
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26846
[Bug fortran/27304] gfortran: Warn/abort when format in write does not fit passed arguments
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de
2006-04-25 17:24 ---
Post scriptum:
I actually see two bugs here:
(a) for static format strings, the test should be done at the compile time
(possibly also for c = '(''n'')'; write(*,c) n )
-> see NAG compiler
(b) for dynamically created format strings, I think one should "crash" with a
meaningful error message. At least that is what ifort, g95, NAG and pgf95 do. I
like the error message of g95:
---
At line 5 of file test.f90 (Unit 6)
Fortran runtime error: Exhausted data descriptors in format
('n')
---
(other wording in NAG f95: "No data edit descriptor in tail of format
specification after reversion" [and no line number])
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27304
[Bug middle-end/25776] [4.2 Regression] ICE in cgraph after error at -O1 and above
--- Comment #8 from aldot at gcc dot gnu dot org 2006-04-25 17:00 --- Created an attachment (id=11334) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11334&action=view) fix typo in errormessage in verify_cgraph_node() Just as a sidenote.. There is a typo in the error message in comment #1. The attached patch fixes this on the 4.1 branch and on trunk. Please apply, TIA. 2006-04-25 Bernhard Fischer <[EMAIL PROTECTED]> * cgraphunit.c (verify_cgraph_node): Fix typo s/predecesors/predecessors/ in error message. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25776
[Bug target/27287] loading 0 constant causes an ICE (freescale's messy targets)
--- Comment #3 from eliot at sonic dot net 2006-04-25 16:44 --- (In reply to comment #2) > Can you try a snapshot of 4.1.1 and/or the mainline? > i tried mainline. same crash. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
[Bug fortran/27317] New: :0: internal compiler error: Illegal instruction
C:\Program Files\gfortran\bin>gfortran -v ch0701.f90 Driving: gfortran -v ch0701.f90 -lgfortranbegin -lgfortran Using built-in specs. Target: i686-pc-mingw32 Configured with: ../gcc/configure --prefix=/mingw --enable-languages=c,fortran - -with-gmp=/home/coudert/local --disable-nls --with-ld=/mingw/bin/ld --with-as=/m ingw/bin/as --disable-werror --enable-bootstrap --enable-threads=win32 --with-wi n32-nlsapi=unicode Thread model: win32 gcc version 4.2.0 20060425 (experimental) c:/program files/gfortran/bin/../libexec/gcc/i686-pc-mingw32/4.2.0/f951.exe ch0 701.f90 -quiet -dumpbase ch0701.f90 -mtune=generic -auxbase ch0701 -version -I c :/program files/gfortran/bin/../lib/gcc/i686-pc-mingw32/4.2.0/finclude -o C:\DOC UME~1\Leroux\LOCALS~1\Temp/ccgN.s GNU F95 version 4.2.0 20060425 (experimental) (i686-pc-mingw32) compiled by GNU C version 4.2.0 20060425 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 :0: internal compiler error: Illegal instruction Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. I downloaded and installed the latest 'native window' installer. It seems not working. Leroux. -- Summary: :0: internal compiler error: Illegal instruction Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: leroux at cameca dot com GCC build triplet: GNU F95 version 4.2.0 20060425 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27317
[Bug c++/27316] New: ICE with two ill-placed #pragma omp parallel
The following invalid code snippet causes an ICE when compiled with -fopenmp:
===
struct A {};
struct B : A
#pragma omp parallel
{};
struct B : A
#pragma omp parallel
{};
===
bug.cc:4: error: '#pragma' is not allowed here
bug.cc:5: error: expected unqualified-id before '{' token
bug.cc:7: internal compiler error: in xref_basetypes, at cp/decl.c:9696
Please submit a full bug report, [etc.]
--
Summary: ICE with two ill-placed #pragma omp parallel
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored, openmp
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27316
[Bug c++/27315] New: ICE with ill-placed #pragma omp parallel
The following invalid code snippet causes an ICE when compiled with -fopenmp:
===
struct A
#pragma omp parallel
{
template void foo();
};
template void A::foo<0>();
===
bug.cc:2: error: '#pragma' is not allowed here
bug.cc:7: error: invalid use of incomplete type 'struct A'
bug.cc:1: error: forward declaration of 'struct A'
bug.cc:7: internal compiler error: tree check: expected tree that contains
'decl common' structure, have 'error_mark' in do_decl_instantiation, at
cp/pt.c:11209
Please submit a full bug report, [etc.]
--
Summary: ICE with ill-placed #pragma omp parallel
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored, openmp
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27315
[Bug fortran/27314] New: ld can't find libgfortran.so.1 on x86-64
Red Hat Enterprise Linux WS release 3 (Taroon Update 6) on Opteron: bar [10:08:42] /baz > cat foo.f90 program foo end program foo bar [10:10:01] /baz > gfortran foo.f90 -Wl,-rpath,/scr_bar/johan/local/lib -o foo bar [10:10:24] /baz > ./foo ./foo: error while loading shared libraries: libgfortran.so.1: cannot open shared object file: No such file or directory bar [10:10:27] /baz > which gfortran /scr_bar/johan/local/bin/gfortran bar [10:10:35] /baz > gfortran -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/scr_bar/johan/local --with-gmp=/scr_bar/johan/local --with-mpfr=/scr_bar/johan/local --enable-languages=c,c++,fortran Thread model: posix gcc version 4.1.0 bar [10:10:43] /baz > strings foo | grep bar /scr_bar/johan/local/lib bar [10:11:01] /baz > ls -l /scr_bar/johan/local/lib/libgfortran.so.1 lrwxrwxrwx1 johanresearch 20 Apr 25 09:36 /scr_bar/johan/local/lib/libgfortran.so.1 -> libgfortran.so.1.0.0* bar [10:11:16] /baz > which ld /usr/bin/ld bar [10:12:04] /baz > ld -v GNU ld version 2.14.90.0.4 20030523 bar [10:12:06] /baz > -- Summary: ld can't find libgfortran.so.1 on x86-64 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dr dot johan at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27314
[Bug target/27282] [4.2 regression] ICE in final_scan_insn, at final.c:2448 - could not split insn
--- Comment #9 from dje at gcc dot gnu dot org 2006-04-25 16:09 --- By the way, while Andrew and my patch does produce correct code, it reverts to the original behavior of the constant propagating into the AND between life2 and lreg, not between life1 and combine. Somehow combine is able to form the AND with the wrong constant that does not match the pattern but cannot form the AND with the correct, sign-extended constant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27282
[Bug c++/27312] excessive stack use for automatic object on stack
--- Comment #2 from avi at argo dot co dot il 2006-04-25 15:57 --- But why 24? gcc could place the object in any of the 12 bytes needed for stack alignment. I don't see any reason why the empty object needs to be aligned to more than a byte boundary. What am I missing? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27312
[Bug tree-optimization/15911] VRP/DOM does not like TRUTH_AND_EXPR
--- Comment #26 from rguenth at gcc dot gnu dot org 2006-04-25 15:55 --- Created an attachment (id=11333) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11333&action=view) updated patch This is a cleanup of the patch by Jeff, bootstrapped and regtested on x86_64-unknown-linux-gnu. ca11011 fails for me with the patch, all other languages are fine. I left the basic structure of the patch as it is reasonable. Compile-time / memory checking will be done soon. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Attachment #11259|0 |1 is obsolete|| AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15911
[Bug c++/27312] excessive stack use for automatic object on stack
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-25 15:48 --- The empty class has a size of 1. And yes, the ABI requires to preserve stack alignment. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27312
[Bug c/27313] New: Does not emit conditional moves for stores
int cmov(int* A ,int B ,int C ,int* D ,int* E ,int F ,int g) {
int k,f;
for (k = 1; k <= 1000; k++) {
A[k] = B+C;
g = D[k-1] + E[k-1];
if (g > A[k]) A[k]=g; /* This is not converted to cmov*/
f += g;
}
return f;
}
In the above code, the if-then statement is not converted to conditional move.
It fails for "noce_mem_write_may_trap_or_fault_p ()" condition in "ifcvt.c" as
it thinks that there is a chance for A[k] access to trap.
The fact here is that in this case, A[k] will never trap because the A[k] is
already been written once along the path from Entry to the "A[k] = g". So it is
safe to convert it to a cmov statement. Though there might be two extra moves
(mem to reg and vice versa) statement, it is still better to avoid the branch
especially if it is unpredictable data like for the eg above.
There is a typical case like this in Spec 2006 456.hmmer benchmark. Using
contional moves will make the code faster by 13%-17%.
-Dwarak
--
Summary: Does not emit conditional moves for stores
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dwarak dot rajagopal at amd dot com
GCC build triplet: x86_64
GCC host triplet: x86_64
GCC target triplet: x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27313
[Bug c/27308] Compiler generates incorrect code when calling a function with the result of an inline function as parameter
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-25 15:45 ---
__res should be allocated to the same register as __r0 due to the '0'
constraint which tells gcc to use the same register as for "=r" (__res).
Whoops - I obviously meant to remove the __asm__("r0") from the __r0
variable... But maybe it works vice-versa, too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27308
[Bug target/27282] [4.2 regression] ICE in final_scan_insn, at final.c:2448 - could not split insn
--- Comment #8 from roger at eyesopen dot com 2006-04-25 15:41 --- Grr. David's patch is also good. Perhaps better if we follow the usual protocol of posting patches to gcc-patches *after* bootstrap and regression testing, for review and approval. Posting untested patch fragments to bugzilla without ChangeLog entries and asking for preapproval etc... seems to, in this instance at least, demonstrate why GCC has the contribution protocols that it has. Thanks to David for catching this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27282
[Bug target/27282] [4.2 regression] ICE in final_scan_insn, at final.c:2448 - could not split insn
--- Comment #7 from dje at watson dot ibm dot com 2006-04-25 15:21 --- Subject: Re: [4.2 regression] ICE in final_scan_insn, at final.c:2448 - could not split insn The patch may be necessary, but does not fix the testcase. The testcase needs the patch that Andrew originally tested: Index: combine.c === --- combine.c (revision 113239) +++ combine.c (working copy) @@ -8210,7 +8209,8 @@ simplify_and_const_int (rtx x, enum mach return tem; if (!x) -x = simplify_gen_binary (AND, GET_MODE (varop), varop, GEN_INT (constop)); +x = simplify_gen_binary (AND, GET_MODE (varop), varop, +gen_int_mode (constop, mode)); if (GET_MODE (x) != mode) x = gen_lowpart (mode, x); return x; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27282
[Bug c++/27312] New: excessive stack use for automatic object on stack
compiling the following
--start-code
struct X {
void g();
};
void g();
void f()
{
X x;
x.g();
g();
}
--end-code-
yields (with -O2)
subl$24, %esp
in the prologue. without the empty class only 12 bytes are subtracted,
presumably to preserve stack alignment.
this is wasteful of stack space.
--
Summary: excessive stack use for automatic object on stack
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: avi at argo dot co dot il
GCC build triplet: x86_64-redhat-linux
GCC host triplet: x86_64-redhat-linux
GCC target triplet: i386-redhat-linux (with -m32)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27312
[Bug c/27308] Compiler generates incorrect code when calling a function with the result of an inline function as parameter
--- Comment #4 from Eric dot Doenges at betty-tv dot com 2006-04-25 14:43
---
Removing the __asm__ ("r0") from __res works around the bug - but then I cannot
depend on gcc
always allocating r0 for __res, can I ? I found no other way to tell gcc which
registers it must use.
I'm assuming this is a bug in gcc, not the asm constraint, because the same
code works flawlessly with
gcc-3.4.3.
As to simplifying the testcase - storing the result of BIOS_ContainerUsage to
memory generates correct
code regardless of wether __res is forced to r0 or not, making it worthless as
a test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27308
[Bug c/27308] Compiler generates incorrect code when calling a function with the result of an inline function as parameter
--- Comment #3 from Eric dot Doenges at betty-tv dot com 2006-04-25 14:37 --- Storing the result to memory generates correct code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27308
[Bug tree-optimization/27299] [4.1 Regression] vectorizer generates aligned accesses to unaligned memory
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-04-25 14:29 --- Changing the function to take both arguments as uint8_t* fixes the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27299
[Bug tree-optimization/27299] [4.1 Regression] vectorizer generates aligned accesses to unaligned memory
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-25 14:27 --- Yes, but the problem appears with -O1 which has -fno-strict-aliasing. Now whether -fno-strict-aliasing makes the testcase valid is another question ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27299
[Bug target/25514] [m68k] internal consistency failure
--- Comment #4 from rsandifo at gcc dot gnu dot org 2006-04-25 14:23
---
This issue is related to PR22002. I have a patch.
A slightly-more reduced testcase is:
struct node { struct node *next; int value; };
struct node *current_node, global_list;
void
bar (void)
{
struct node *node, *next;
node = current_node;
next = node->next;
if (node != &global_list)
current_node = next;
else
{
node = global_list.next;
global_list.value = node->value;
global_list.next = node->next;
}
foo (node);
}
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2006-02-02 19:32:25 |2006-04-25 14:23:53
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25514
[Bug tree-optimization/27299] [4.1 Regression] vectorizer generates aligned accesses to unaligned memory
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-04-25 14:23 --- Richard, you confirmed this. But to me this looks like the code is violating the aliasing rules (which would mean that the PR in invalid): *(uint64_t *)dest = *(uint64_t *)src; but uint8_t *dest const uint8_t *src -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, reichelt at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27299
[Bug target/27282] [4.2 regression] ICE in final_scan_insn, at final.c:2448 - could not split insn
--- Comment #6 from roger at eyesopen dot com 2006-04-25 14:09 ---
Paolo's fix looks good to me. The bugzilla PR shows that this is a 4.2
regression, probably due to the more aggressive RTL optimizations on mainline.
So I'll preapprove Paolo's fix for mainline (please post the version you
commit and a new testcase when you commit it).
As for 4.1, do we have an example of a failure or wrong code generation
against the branch? I can't tell from bugzilla whether this is safely
latent in 4.0 and 4.1, or just hasn't been investigated there yet
("known to work" is blank, but the summary only lists [4.2]).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27282
[Bug libmudflap/26446] Running large program compiled with mudflap aborts even before reaching main()
--- Comment #5 from walter dot zimmer at dlr dot de 2006-04-25 14:05 --- > The link-time wrapping of malloc is designed precisely so that other > uninstrumented libraries that call malloc by name still get registered in the > libmudflap runtime. That way, pointers from these libraries may make their > way > to an instrumented routine, and be used without error. Good idea. Seems to work with g77, but not with gfortran. Is there maybe any known project which uses both g++ and gfortran and still works with mudflap? > Does MUDFLAP_OPTIONS=-trace-calls produce anything? Well, it doesn't seem to reach the point where it evaluates MUDFLAP_OPTIONS, as even MUDFLAP_OPTIONS="-help" doesn't work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26446
[Bug libstdc++/17373] std::set::erase(const_iterator) doesn't output error on compilation
--- Comment #7 from pcarlini at suse dot de 2006-04-25 13:33 --- Yes, we are simply implementing the resolution of DR 103: set<>::iterator is a constant iterator type -- pcarlini at suse dot de changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17373
[Bug middle-end/27310] New: ICE in duplicate_eh_regions
The following testcase causes a segfault in duplicate_eh_regions
when compiled with "-fopenmp -O":
==
struct A
{
~A();
};
struct B
{
A a1, a2;
};
void foo()
{
A x1, x2;
#pragma omp parallel
B b;
}
==
Reduced from Martin's testcase in PR 26084.
--
Summary: ICE in duplicate_eh_regions
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored, openmp
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27310
[Bug libstdc++/17373] std::set::erase(const_iterator) doesn't output error on compilation
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-04-25 13:23 ---
template
class set
{
...
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// DR 103. set::iterator is required to be modifiable,
// but this allows modification of keys.
typedef typename _Rep_type::const_iteratoriterator;
typedef typename _Rep_type::const_iteratorconst_iterator;
typedef typename _Rep_type::const_reverse_iteratorreverse_iterator;
typedef typename _Rep_type::const_reverse_iterator
const_reverse_iterator;
all iterators are const...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17373
[Bug libstdc++/17373] std::set::erase(const_iterator) doesn't output error on compilation
--- Comment #5 from falk at debian dot org 2006-04-25 13:20 --- (In reply to comment #4) > The standard doesn't mention set::erase with "iterator" argument, only with > "const_iterator". erm. the other way round, of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17373
[Bug libstdc++/17373] std::set::erase(const_iterator) doesn't output error on compilation
--- Comment #4 from falk at debian dot org 2006-04-25 13:19 --- The standard doesn't mention set::erase with "iterator" argument, only with "const_iterator". Maybe it is legal for g++ to allow it anyway (even if I cannot find anything in the standard allowing it at the moment), but other compilers don't, so it is a rather useless extension. So I'll reopen this bug. -- falk at debian dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17373
[Bug c++/27309] New: [4.0/4.1/4.2 regression] ICE on invalid constructor definition
The following invalid testcase causes an ICE since GCC 4.0.0:
=
struct A
{
int i;
A() i() {} // missing colon
};
struct B
{
A a;
};
B b;
=
bug.cc:4: error: expected ';' before 'i'
bug.cc:5: error: expected `;' before '}' token
bug.cc:12: internal compiler error: vector VEC(tree,base) index domain error,
in locate_ctor at cp/method.c:885
Please submit a full bug report, [etc.]
Btw, the code also caused GCC 2.95.x and 3.0.x to crash.
--
Summary: [4.0/4.1/4.2 regression] ICE on invalid constructor
definition
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27309
[Bug c/27308] Compiler generates incorrect code when calling a function with the result of an inline function as parameter
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-25 12:49 ---
This is probably a problem with the inline asm constraints. Try removing the
__asm__("r0") from the __res variable. Also try simplifying the testcase by
storing the result of BIOS_ContainerUsage(1) to memory rather than calling
printf.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27308
[Bug inline-asm/27305] Compiler generates incorrect code when calling functions
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-25 12:38 --- *** This bug has been marked as a duplicate of 27308 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27305
[Bug c/27308] Compiler generates incorrect code when calling a function with the result of an inline function as parameter
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-25 12:38 --- *** Bug 27305 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27308
[Bug c/27308] New: Compiler generates incorrect code when calling a function with the result of an inline function as parameter
Consider the following code:
typedef unsigned int UINT32;
typedef unsigned char BOOL;
#define __SWI_BIOS_ContainerUsage 1234
#define __swicall1(type,name,type1,arg1) \
static inline type name(type1 arg1) { \
register long __r0 __asm__ ("r0") = (long)arg1; \
register long __res __asm__ ("r0"); \
__asm__ __volatile__ ("swi\t%2\n\t" \
: "=r" (__res)
\
: "0" (__r0), "i" (__SWI_##name)\
: "r1", "r2", "r3", "ip", "lr", "cc",
\
"memory");
\
return((type)__res);
\
}
__swicall1(UINT32,BIOS_ContainerUsage,BOOL,verbose);
int sprintf(char *p, const char *frmt, ...);
void testme(char *tmp)
{
sprintf(tmp, " %d%% Containers\n", BIOS_ContainerUsage(1));
sprintf(tmp, " %d%% Containers\n", 2 * BIOS_ContainerUsage(1));
}
For the first call to sprintf, gcc generates the following assembler code:
mov r0, #1
swi #1234
ldr r5, .L3
mov r0, r4
mov r1, r5
mov r2, r4
bl sprintf
This is clearly wrong, since r2 should hold the result of the swi (which is
returned in r0). For the
second call to sprintf, gcc generates correct code:
mov r0, #1
swi #1234
mov r2, r0, asl #1
mov r1, r5
mov r0, r4
ldmfd sp!, {r4, r5, lr}
b sprintf
--
Summary: Compiler generates incorrect code when calling a
function with the result of an inline function as
parameter
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Eric dot Doenges at betty-tv dot com
GCC host triplet: powerpc-apple-darwin8.5.0
GCC target triplet: arm-elf-unknown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27308
[Bug c/21920] alias violating
--- Comment #93 from rguenth at gcc dot gnu dot org 2006-04-25 12:21 --- *** Bug 27306 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||kalas at unicontrols dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug c++/27306] while and (type *&)variable++ causes never ending loop
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-25 12:21 --- .. to close as dup of PR21920. *** This bug has been marked as a duplicate of 21920 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27306
[Bug c++/27306] while and (type *&)variable++ causes never ending loop
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-25 12:20 --- Oh, this is just an aliasing issue. Reopening... -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27306
[Bug c++/27306] while and (type *&)variable++ causes never ending loop
--- Comment #2 from falk at debian dot org 2006-04-25 12:19 --- It's a valid C++ fragment. However, this code accesses "ptr", which is of type void*, via an lvalue of type U16*. This is undefined behavior, so there is no gcc bug here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27306
[Bug c++/27306] while and (type *&)variable++ causes never ending loop
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-25 12:15 --- This is not a valid testcase, or even expression. I guess it's invalid anyway because of operator precedence. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27306
[Bug inline-asm/27305] Compiler generates incorrect code when calling functions
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-25 12:11 --- Considering it. What happens? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c |inline-asm http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27305
[Bug target/27303] crash at unalign access
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-25 12:07 --- Look at the assembly output of gcc (-S) and see if there is an appropriate alignment directive before the entry for AMLogging in the bss section. If there is, the assembler/linker are at fault. Otherwise please attach a testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27303
[Bug tree-optimization/27299] [4.1 Regression] vectorizer generates aligned accesses to unaligned memory
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-25 11:55 --- mainline doesn't do vectorization here: /tmp/t.c:12: note: === vect_analyze_dependences === /tmp/t.c:12: note: not vectorized: can't determine dependence between *src.1_24 and *dest.0_23 /tmp/t.c:12: note: bad data dependence. while 4.1 peels for alignment (wrongly). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27299
[Bug target/27303] crash at unalign access
--- Comment #2 from mehmet dot ekici at alcatel dot com dot tr 2006-04-25 11:49 --- (In reply to comment #1) > First, gcc 3.4.3 is no longer in active maintainance, the oldest still > maintained version is 4.0.3. Second, please read the bugreporting guidelines > and provide a testcase for the problem. Third, this may be as well a linker > or > assembler bug (or missing feature). Would you please tell me how I can localize the problem if it is ld or gcc ? -- mehmet dot ekici at alcatel dot com dot tr changed: What|Removed |Added CC||mehmet dot ekici at alcatel ||dot com dot tr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27303
