[Bug c/109507] Optimizer creates incorrect program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109507 Aran Clauson changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #4 from Aran Clauson --- Disregard.
[Bug c/109507] New: Optimizer creates incorrect program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109507 Bug ID: 109507 Summary: Optimizer creates incorrect program Product: gcc Version: 12.1.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: aran at 100acres dot us Target Milestone: --- Created attachment 54854 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54854&action=edit Example program. The attached program should print 0 and does with optimization level zero (0). However, with optimization at any non-zero value (e.g., g, s, 1, 2) it prints 1. This is on an Intel I7-2600. The code that the optimizer writes reduces to a single test instruction that checks if x is less or equal to zero. However, this is incorrect for the most negative number. To reproduce compile the attached file with -O0 and with -O1.
[Bug ada/41321] Ada runtime not initializing fpu (finit)
--- Comment #1 from aran at 100acres dot us 2009-09-09 16:40 --- Created an attachment (id=18556) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18556&action=view) Adds __amd64__ to conditional code This includes asm("finit") for amd64 targets on NetBSD -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41321
[Bug ada/41321] New: Ada runtime not initializing fpu (finit)
The function __gnat_init_float doesn't call asm("finit") when compiled on NetBSD for x86_64. It looks like Win32, Interix, emx, Lynx, FreeBSD, and OpenBDS have the same problem, but this is unconfirmed. -- Summary: Ada runtime not initializing fpu (finit) Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aran at 100acres dot us GCC build triplet: x86_64-unknown-netbsd5.99.16 GCC host triplet: x86_64-unknown-netbsd5.99.16 GCC target triplet: x86_64-unknown-netbsd5.99.16 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41321
[Bug fortran/39571] Compiler crash with "GNU MP: Cannot reallocate memory"
--- Comment #11 from aran at 100acres dot us 2009-03-30 16:51 --- (In reply to comment #9) My mistake, I printed the operands to mpz_pow_ui and got gfc_arith_power: op1 = 2 gfc_arith_power: power = 2147483647 When I call mpz_pow_ui from c with these arguments, I get GNU MP: Cannot reallocate memory (old_size=4 new_size=268435472) This is obviously not a fortran bug. -- aran at 100acres dot us changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39571
[Bug fortran/39571] Compiler crash with "GNU MP: Cannot reallocate memory"
--- Comment #10 from aran at 100acres dot us 2009-03-29 00:50 --- (In reply to comment #9) > > What happens when you compile the following: > > #include > #include > int main(void) { > unsigned int u = 268435472u; > mpz_t x; > mpz_init(x); > mpz_set_ui(x, 2); > mpz_out_str (stdout, 10, x); > printf(" %u\n", u); > mpz_pow_ui (x, x, u); > mpz_clear(x); > return 0; > } > rmme[0]$./a.out 2 268435472 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39571
[Bug fortran/39571] Compiler crash with "GNU MP: Cannot reallocate memory"
--- Comment #7 from aran at 100acres dot us 2009-03-28 23:19 --- > NetBSD seems to be using jemalloc. which is the memory allocator > from FreeBSD. Perhaps, your memory is defective. > Where would this be? I can't find jemalloc in the fortran directory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39571
[Bug target/39570] cabs and cabsf are named differently on NetBSD 5
--- Comment #9 from aran at 100acres dot us 2009-03-28 19:38 --- (In reply to comment #8) > Symbol versioning, obviously. > Yep, that would have worked. Thanks for the clue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39570
[Bug target/39570] cabs and cabsf are named differently on NetBSD 5
--- Comment #7 from aran at 100acres dot us 2009-03-28 18:13 --- (In reply to comment #5) > Another fix is to #undef TARGET_C99_FUNCTIONS as obviously netbsd is another > OS without a clue ... > Please explain how an OS with a clue would handle this problem. Older binaries that use the pre-c99 complex structure links to the existing linker symbols, cabs and cabsf. Changing the meaning of these symbols to the c99 meaning would break these legacy programs. It seems cluefull to decorate these symbols with __c99_ and provide a rename in the header. What would be a better solution? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39570
[Bug fortran/39571] Compiler crash with "GNU MP: Cannot reallocate memory"
--- Comment #5 from aran at 100acres dot us 2009-03-28 04:46 --- gmp-4.2.4 passes all test. mpfr-2.4.0 pass all except the tsprintf tests where my version returns 1.899347461279296875e+07 and the test expects 1,899347461279296875e+07 (notice the decimal point is a period instead of a comma). Considering that gmp is being told to raise 2 to the 268435472nd power, I don't think any system's allocator would work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39571
[Bug fortran/39570] cabs and cabsf are named differently on NetBSD 5
--- Comment #4 from aran at 100acres dot us 2009-03-28 01:34 --- Subject: Re: cabs and cabsf are named differently on NetBSD 5 What is beyond me is how darwin_patch_builtings gets called. It looks like it is called from rs6000.c in rs6000_init_builtins via the macro SUBTARGET_INIT_BUILTINS. i386.c doesn't appear to have this infrastructure. I am not familiar enough with gcc internals to know what the impacts might be on other platforms if I start making changes here. Also, these renames are only for NetBSD 5. How do I detect the os version. The darwin example uses darwin_macosx_version_min. Is there a NetBSD analog? Aran On Friday 27 March 2009 18:02:48 steven at gcc dot gnu dot org wrote: > --- Comment #3 from steven at gcc dot gnu dot org > 2009-03-28 01:02 --- Completely beyond you, how? > > What gcc does for darwin (and this is a hack, mind you), > is basically replace the standard C99 builtins with > darwin-specific ones. You have to do the same for > NetBSD. > > See the following files in gcc/config/: > * darwin.c > * darwin-ppc-ldouble-patch.def > > The code in darwin_patch_builtin() changes the assembler > name of the builtin function to a custom, darwin-specific > version. E.g. cabsl has a PATCH_BUILTIN defines, so its > DECL_NAME is the normal cabls name but its assembler name > becomes _cabsl_$LDBL128. > > You need to do something similar (but probably less ugly) > for NetBSD to make this work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39570
[Bug fortran/39571] Compiler crash with "GNU MP: Cannot reallocate memory"
--- Comment #3 from aran at 100acres dot us 2009-03-28 01:09 --- I chased this to airth.c line 1054: mpz_pow_ui (result->value.integer, op1->value.integer, power); The variable power is 268435472. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39571
[Bug fortran/39571] Compiler crash with "GNU MP: Cannot reallocate memory"
--- Comment #2 from aran at 100acres dot us 2009-03-28 01:05 --- gmp-4.2.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39571
[Bug fortran/39571] New: Compiler crash with "GNU MP: Cannot reallocate memory"
Compiling program test print *, 2**huge(0) end program test cause gfortran to crash with: GNU MP: Cannot reallocate memory (old_size=4 new_size=268435472) f951: internal compiler error: Abort trap -- Summary: Compiler crash with "GNU MP: Cannot reallocate memory" Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aran at 100acres dot us GCC build triplet: i386-unknown-netbsdelf5.99.7 GCC host triplet: i386-unknown-netbsdelf5.99.7 GCC target triplet: i386-unknown-netbsdelf5.99.7 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39571
[Bug fortran/39570] cabs and cabsf are named differently on NetBSD 5
--- Comment #2 from aran at 100acres dot us 2009-03-28 00:23 --- I really tried looking at Darwin's fix to the built-in problem, but that is completely beyond me. Any suggestions would be very nice. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39570
[Bug fortran/39570] cabs and cabsf are named differently on NetBSD 5
--- Comment #1 from aran at 100acres dot us 2009-03-28 00:22 --- Created an attachment (id=17552) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17552&action=view) Grungy little patch. This is a dirty hack for NetBSD 5.x only. It is not intended to be applied to the main source. However, if you are running NetBSD 5.x and just want it fixed, here is the patch for you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39570
[Bug fortran/39570] New: cabs and cabsf are named differently on NetBSD 5
On NetBSD 5.0, cabs and cabsf, defined in complex.h, are renames of __c99_cabs and __c99_cabsf. The build-in definitions in f95-lang.c specifically name "cabs" and "cabsf". On NetBSD 5.0, these are provided for compatibility and emit a linker warning when linking. This causes 7000 or so tests to fail. -- Summary: cabs and cabsf are named differently on NetBSD 5 Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aran at 100acres dot us GCC build triplet: i386-unknown-netbsdelf5.99.7 GCC host triplet: i386-unknown-netbsdelf5.99.7 GCC target triplet: i386-unknown-netbsdelf5.99.7 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39570
[Bug target/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_
--- Comment #12 from aran at 100acres dot us 2009-03-24 15:49 --- Subject: Re: stddef.h assumes machinee/ansi.h defines _ANSI_H_ Joseph, The fixincludes changes fix another issue. Should I create a new bug and reference that bug in the e-mail or just describe the problem in the e-mail? Aran On Tuesday 24 March 2009 6:22:25 joseph at codesourcery dot com wrote: > --- Comment #10 from joseph at codesourcery dot com > 2009-03-24 13:22 --- Subject: Re: stddef.h assumes > machinee/ansi.h defines _ANSI_H_ > > On Tue, 24 Mar 2009, aran at 100acres dot us wrote: > > This is a combination of the other two patches. GCC's > > version of stddef.h is still installed and fixed for > > NetBSD. The copy of sys/types.h is not installed. > > Once you have finished testing, please send the patch > with ChangeLog entries and a self-contained explanation > to gcc-patches as described in contribute.html. > > Do not include the diffs to the generated file fixincl.x; > the person committing it will need to regenerate it using > a current autogen version (which would keep GPLv3 notices > there rather than wrongly substituting GPLv2 notices). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38182
[Bug target/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_
--- Comment #9 from aran at 100acres dot us 2009-03-24 06:16 --- Created an attachment (id=17528) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17528&action=view) Removes problematic fixincludes and defines _ANSI_H in stddef.h This is a combination of the other two patches. GCC's version of stddef.h is still installed and fixed for NetBSD. The copy of sys/types.h is not installed. -- aran at 100acres dot us changed: What|Removed |Added Attachment #16724|0 |1 is obsolete|| Attachment #17333|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38182
[Bug c++/39426] Gcc parser problems on default template arguments
--- Comment #1 from aran at 100acres dot us 2009-03-10 22:56 --- A typedef is an effective workaround -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39426
[Bug c++/39426] New: Gcc parser problems on default template arguments
The gcc incorrectly parses the template arguments for default values in member functions. Here is an example: template class B { }; class A { public: void foo( B x = B() ) { } }; Gcc 4.3.3 emits the following: 9: error: expected ',' or '...' before '>' token 9: error: wrong number of template arguments (1, should be 2) :2: error: provided for 'template class B' :9: error: default argument missing for parameter 2 of 'void A::foo(B, int)' -- Summary: Gcc parser problems on default template arguments Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aran at 100acres dot us GCC build triplet: i386-unknown-netbsdelf5.99.7 GCC host triplet: i386-unknown-netbsdelf5.99.7 GCC target triplet: i386-unknown-netbsdelf5.99.7 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39426
[Bug ada/37309] Ada tasking is not implemented on NetBSD
--- Comment #8 from aran at 100acres dot us 2009-03-02 20:13 --- Created an attachment (id=17390) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17390&action=view) Gcc 4.3.3 build patch This patch fixes the header problems that prevent GCC 4.3.3 from compiling on NetBSD. This also remove the GCC's copies of sys/types.h and cdecl.h. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37309
[Bug ada/37309] Ada tasking is not implemented on NetBSD
--- Comment #7 from aran at 100acres dot us 2009-03-02 20:09 --- Created an attachment (id=17388) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17388&action=view) Gcc 4.3.3 Ada runtime patch for NetBSD 5.0 This patch implements the Ada runtime for NetBSD 5.99. It requires the NetBSD patch that makes GCC compile. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37309
[Bug testsuite/39353] Linker warning causing tests to fail (960218 and 20030913)
--- Comment #1 from aran at 100acres dot us 2009-03-02 19:42 --- Created an attachment (id=17387) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17387&action=view) Rename glob to Glob. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39353
[Bug testsuite/39353] New: Linker warning causing tests to fail (960218 and 20030913)
The global variable glob clashes with the compatibility NetBSD libc function with the same name. The linker emits a warning that causes the test case to fail. The included patch renames glob to Glob in both tests -- Summary: Linker warning causing tests to fail (960218 and 20030913) Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aran at 100acres dot us GCC build triplet: i386-unknown-netbsdelf5.99.7 GCC host triplet: i386-unknown-netbsdelf5.99.7 GCC target triplet: i386-unknown-netbsdelf5.99.7 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39353
[Bug target/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_
--- Comment #3 from aran at 100acres dot us 2009-02-19 21:46 --- Created an attachment (id=17333) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17333&action=view) Removes gcc's version of both stddef.h and sys/types.h This patch removes gcc's version of stddef.h and the "fixed" version of sys/types.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38182
[Bug c/38182] New: stddef.h assumes machinee/ansi.h defines _ANSI_H_
GCC fails on NetBSD 5.x because stddef.h assumes that machine/ansi.h defines _ANSI_H_ as its code guard. This prevents the definition of size_t. -- Summary: stddef.h assumes machinee/ansi.h defines _ANSI_H_ Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aran at 100acres dot us GCC build triplet: i386-unknown-netbsdelf5.99.02 GCC host triplet: i386-unknown-netbsdelf5.99.02 GCC target triplet: i386-unknown-netbsdelf5.99.02 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38182
[Bug c/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_
--- Comment #1 from aran at 100acres dot us 2008-11-19 20:32 --- Created an attachment (id=16724) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16724&action=view) Patch for stddef.h This patch ensures that _ANSI_H_ is defined after including machine/ansi.h. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38182
[Bug target/35655] [m68hc11] Segmentation fault when compiling libgcc2.c
--- Comment #2 from aran at 100acres dot us 2008-10-12 20:24 --- I got the same error at a different point. /home/aran/projects/gcc/current/build/./gcc/xgcc -B/home/aran/projects/gcc/current/build/./gcc/ -B/usr/local/opt/gcc-4.4/i386-unknown-netbsdelf4.99.72/bin/ -B/usr/local/opt/gcc-4.4/i386-unknown-netbsdelf4.99.72/lib/ -isystem /usr/local/opt/gcc-4.4/i386-unknown-netbsdelf4.99.72/include -isystem /usr/local/opt/gcc-4.4/i386-unknown-netbsdelf4.99.72/sys-include -g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I../../../netbsd/libgcc -I../../../netbsd/libgcc/. -I../../../netbsd/libgcc/../gcc -I../../../netbsd/libgcc/../include -DHAVE_CC_TLS -o _powisf2.o -MT _powisf2.o -MD -MP -MF _powisf2.dep -DL_powisf2 -c ../../../netbsd/libgcc/../gcc/libgcc2.c \ -fvisibility=hidden -DHIDE_EXPORTS ../../../netbsd/libgcc/../gcc/libgcc2.c: In function '__powisf2': ../../../netbsd/libgcc/../gcc/libgcc2.c:1743: internal compiler error: Segmentation fault Using: gcc -v Using built-in specs. Target: i386-unknown-netbsdelf4.99.72 Configured with: ../netbsd/configure --prefix=/usr/local/opt/gcc-4.4 --enable-threads --enable-tls --with-cpu=prescott --disable-nls --with-mpfr-lib=/usr/local/lib --with-gmp-lib=/usr/local/lib --enable-languages=c,ada,c++,fortran,java Thread model: posix gcc version 4.4.0 20081002 (experimental) (GCC) -- aran at 100acres dot us changed: What|Removed |Added CC| |aran at 100acres dot us http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35655
[Bug ada/37309] Ada tasking is not implemented on NetBSD
--- Comment #6 from aran at 100acres dot us 2008-10-03 14:53 --- There is a typo in the last path. Apply this after the above. --- orig/gcc/ada/s-osinte-netbsd.adb2008-10-03 07:50:29.0 -0700 +++ netbsd/gcc/ada/s-osinte-netbsd.adb 2008-10-02 19:35:38.0 -0700 @@ -46,7 +46,7 @@ package body System.OS_Interface is type int_ptr is access all int; function internal_errno return int_ptr; - pragma Import (C, internal_errno, "__error"); + pragma Import (C, internal_errno, "__errno"); begin return (internal_errno.all); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37309
[Bug ada/37309] Ada tasking is not implemented on NetBSD
--- Comment #5 from aran at 100acres dot us 2008-10-03 01:51 --- Created an attachment (id=16457) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16457&action=view) Same fixes, but work Final fixes. Sorry for the repeated posts. -- aran at 100acres dot us changed: What|Removed |Added Attachment #16456|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37309
[Bug ada/37309] Ada tasking is not implemented on NetBSD
--- Comment #4 from aran at 100acres dot us 2008-10-02 23:06 --- Created an attachment (id=16456) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16456&action=view) NetBSD patch for SVN trunk Obsoletes both prior patches. Patch for SVN trunk. Adds other NetBSD support (e.g., signals and netinet). -- aran at 100acres dot us changed: What|Removed |Added Attachment #16176|0 |1 is obsolete|| Attachment #16444|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37309
[Bug ada/37309] Ada tasking is not implemented on NetBSD
--- Comment #3 from aran at 100acres dot us 2008-10-01 16:30 --- Created an attachment (id=16444) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16444&action=view) patch for svn trunk -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37309
[Bug ada/37309] Ada tasking is not implemented on NetBSD
--- Comment #1 from aran at 100acres dot us 2008-09-01 06:17 --- Created an attachment (id=16176) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16176&action=view) Patch and supporting files. The tar contains a patch for gcc/ada/Makefile.in and the necessary supporting files. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37309
[Bug ada/37309] New: Ada tasking is not implemented on NetBSD
Ada tasking is not implemented on NetBSD. -- Summary: Ada tasking is not implemented on NetBSD Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aran at 100acres dot us GCC build triplet: i686-pc-netbsdelf4.99.35 GCC host triplet: i686-pc-netbsdelf4.99.35 GCC target triplet: i686-pc-netbsdelf4.99.35 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37309
[Bug ada/34553] New: Unsafe calls to mktemp and tmpname
adaint.c calls mktemp (line 802) and tmpname (line 900). Both calls generate warnings when running gnatlink. ../gcc-4.2.2/configure --prefix=$PREFIX --enable-languages=c,ada,c++ In both cases, there are conditional compiles for the correct/safe function calls. The conditions (line 797 and 887) check for __FreeBSD__, but not __NetBSD__. I have added the check for __NetBSD__ in both places and tested for i386-pc-netbsdelf4.99.35. This changes stopped the warnings. -- Summary: Unsafe calls to mktemp and tmpname Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aran at 100acres dot us GCC build triplet: i386-pc-netbsdelf4.99.35 GCC host triplet: i386-pc-netbsdelf4.99.35 GCC target triplet: i386-pc-netbsdelf4.99.35 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34553