[Bug driver/44273] New: Using -save-temps and @file should also save the intermediate @file used by the driver.
When you compile anything using @file support, the driver assumes @file (at_file_supplied is true) is allowed and may pass options to the linker via @file using a *temporary* file. When -save-temps is also used, the temporary @file passed to the linker should also be saved. Saving the temporary @file passed to the linker allows a developer to re-run just the collect2/ld command. On trunk this means that gcc/gcc.c (create_at_file) should honour the save_temps_flag, saving the temporary @file for later analysis or use. -- Summary: Using -save-temps and @file should also save the intermediate @file used by the driver. Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: carlos at codesourcery dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu arm-none-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44273
[Bug target/44261] New: Multiplying -1 by NaN is not valid.
The following testcase is an example of code used in a glibc testcase. I'm
trying hard to shake out the bugs in the glibc testsuite for debian, and one
testsuite failure looks like a compiler issue.
The expected behaviour is for the testcase to print the raw IEEE754 value of
-NAN.
The observed behaviour, when -DALT is on the command line, is that the testcase
prints the incorrect raw value e.g. NAN.
GCC 4.4.3 in debian doesn't compile this code correctly.
cat >> tst-mul-nan.c <
#include
#ifdef ALT
volatile double nanval;
#else
#define nanval NAN
#endif
int
main ()
{
#ifdef ALT
nanval = NAN;
#endif
printf ("0x%llx\n", -nanval);
return 0;
}
EOF
gcc -g3 -O0 -save-temps -o test-mul-nan-OK test-mul-nan.c; ./test-mul-nan-OK
0xfff7
This is the correct result e.g. -NAN. In the correct case the compiler has
already computer -NAN and it's loaded directly from the local symbol e.g.
.LC1:
.word -524289
.word -1
This is the case that is not working correctly:
gcc -g3 -O0 -save-temps -DALT -o test-mul-nan-NG test-mul-nan.c;
./test-mul-nan-NG
0x7ff7
That result is not -NAN, it is NAN. This is incorrect.
In the incorrect compilation the compiler loads NAN from a local constant:
.LC0:
.word 2146959359
.word -1
This is 0x7ff7 e.g. NAN.
Then it loads a 64-bit double -1.0.
.LC2:
.word -1074790400
.word 0
In the incorrect case the compiler tries to multiply -1.0 by NAN to get a
result of -NAN.
addil LR'nanval-$global$,%r27
copy %r1,%r19
ldo RR'nanval-$global$(%r19),%r19
fldds 0(%r19),%fr23
ldil LR'.LC2,%r19
ldo RR'.LC2(%r19),%r19
fldds 0(%r19),%fr22
fmpy,dbl %fr23,%fr22,%fr22
This is not going to work because -1.0 times NAN is NAN, and the sign of the
input will be ignored.
See: PA-RISC 2.0 Architecture, Floating Coprocessor 8-23 "Operations With
NaNs", and 8-24 "Sign Bit" can be referenced for information on NANs.
After the multiplication fr22 still contains NAN, and that is what is printed
instead of the expected result of -NAN.
John David Anglin indicates:
This is a bug.
The code should xor the sign bit when doing negation. The existing code
doesn't work for NANs. I'll try to fix negdf2 and negsf2.
The problem is PA1.1 doesn't have a fneg instruction, so the above takes a bit
of work to implement. You will get the correct result if you specify
-march=2.0.
Unfortunately I can't use -march=2.0 in this case, the C library has to work on
PA1.1 class systems.
--
Summary: Multiplying -1 by NaN is not valid.
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carlos at codesourcery dot com
GCC build triplet: hppa-linux-gnu
GCC host triplet: hppa-linux-gnu
GCC target triplet: hppa-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44261
[Bug libstdc++/39491] [4.2/4.3 regression] symbol __signb...@glibcxx_3.4 in libstdc++ exported
--- Comment #32 from carlos at codesourcery dot com 2009-04-29 15:07 --- No, you are absolutely right and the tree dumps confirm it. I thought it might be possible to trigger a reference by using the right flags, but to no avail, the compiler always folds the if-then-else to __signbit. This proves to me that no program could have ever created a reference to __signbitl unless they specifically called __signbitl, which is a but in the application. I now agree with Benjamin that this is a [4.2/4.3 regression]. Notes: * I am using -fno-builtins to avoid the compiler builtins from being used for signbit[fl]. * I would never want libstdc++ to ever provide a default symbol for __signbitl, only a compat one, but this is now moot since we proved no program could ever reference __signbitl. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39491
[Bug libstdc++/39491] [4.2/4.3 regression] symbol __signb...@glibcxx_3.4 in libstdc++ exported
--- Comment #28 from carlos at codesourcery dot com 2009-04-28 20:57 --- Exporting a non-default versioned symbol is useless since new programs won't be able to link against that definition. Did 4.2/4.3 export a global default symbol for __signbitl? If we did export a global default symbol for __signbitl then we must continue to export it. The current glibc math.h signbit macro will evaluate to __signbitl if passed a long dobule type, and therefore correct programs using the signbit macro may have ended up referencing __signbitl from libstdc++. Please comment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39491
[Bug libstdc++/39491] [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++ not exported anymore
--- Comment #26 from carlos at codesourcery dot com 2009-04-24 20:41 --- Action items left: 1) Checkin a patch to libc-ports to define __signbitl as an alias of __signbit on hppa. * Done: http://sourceware.org/ml/glibc-cvs/2009-q2/msg00277.html 2) Someone please add a stub to libstdc++ for __signb...@glibcxx_3.4 that calls __signbitl in glibc. 3) Wait for Jakub to get his patch into glibc core. 4) Enable __NO_LONG_DOUBLE_MATH for hppa (different from NO_LONG_DOUBLE and long-double-fcts = no). #1, #3, and #4 are things I can work on. Can someone please do #2? When #1 and #2 are done we can consider *this* issue closed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39491
[Bug libstdc++/39491] [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++ not exported anymore
--- Comment #25 from carlos at codesourcery dot com 2009-04-24 20:31 --- Jakub's patch works for me on HPPA, and correctly exports the *l prototypes with __NO_LONG_DOUBLE_MATH set. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39491
[Bug libstdc++/39491] [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++ not exported anymore
--- Comment #18 from carlos at codesourcery dot com 2009-04-22 22:42 --- Subject: Re: [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++ not exported anymore >> * Original submitter is incorrect, there has never been a >> __signb...@glibcxx_3.4 symbol, and there should not be one now? > > The symbol is present in libstdc++.so.6.0.9 and libstdc++.so.6.0.10, > but not in libstdc++.so.6.0.8 or libstdc++.so.6.0.11. If that's the case, then libstdc++ is to blame, and Benjamin's hackish patch should be reviewed and checked in. >> * I have changed the glibc hppa-linux-gnu port to define >> __NO_LONG_DOUBLE_MATH, >> and therefore the signbit macro, even in the abscense of optimization, will >> always return a valid signbit function based on the type size. > > I'm not convinced this is a good idea at this point. As far as I know, > it is ok to have the same size for double and long double. However, > they are distinct types. Perhaps I wasn't as clear as I should have been. The glibc port for hppa has always been configured never to build any long double code, and has always assumed that long double is not a distinct type. From glibc's perspective there is no such thing as having double and long double with the same size, there is only a configuration where double exists and all the long double functions alias to their double equivalents. The hppa port sets long-double-fcts = no in glibc and this causes all the aliases to be created, otherwise you'd never be able to link anything that used `l' ending math functions. Defining __NO_LONG_DOUBLE_MATH is just another step in the right direction to avoid using long double functions, and use the double functions instead. The upside is that, if and when, long double on hppa becomes the 128-bit quad long double, we can just follow the tried-and-tested procedure to migrate the glibc math routines. Cheers, Carlos. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39491
[Bug libstdc++/39491] [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++ not exported anymore
--- Comment #16 from carlos at codesourcery dot com 2009-04-22 18:33 --- So what is required to close this issue? * Original submitter is incorrect, there has never been a __signb...@glibcxx_3.4 symbol, and there should not be one now? * glibc on hppa-linux-gnu has never had a __signbitl symbol. * I have changed the glibc hppa-linux-gnu port to define __NO_LONG_DOUBLE_MATH, and therefore the signbit macro, even in the abscense of optimization, will always return a valid signbit function based on the type size. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39491
[Bug libstdc++/39491] [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++ not exported anymore
--- Comment #11 from carlos at codesourcery dot com 2009-04-21 20:16 --- Yes, if gcc does not determine that "sizeof (x) == sizeof (double)" then it would have to emit code for the if-then-else statement and this would create a reference to an undefined __signbitl. Has this ever happened? I've never seen it. At present glibc does not create an long double alias for the double __signbit function, but for the sake of correctness it probably should. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39491
[Bug driver/35532] Native GCC no longer searches $prefix/lib for startfiles when run from $objdir
--- Comment #14 from carlos at codesourcery dot com 2008-04-02 21:52 --- Using the sysroot flags is the solution for Greg's scenario. In fact I would say it makes his job easier. I'm looking for a test case that doesn't mangle GCC's configure files, and is broken with no easy alternative. Do we have one? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532
[Bug driver/35532] Native GCC no longer searches $prefix/lib for startfiles when run from $objdir
--- Comment #12 from carlos at codesourcery dot com 2008-04-02 19:20 --- Paolo, What's the test-case? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532
[Bug middle-end/35705] [4.3/4.4 Regression] Symbol address check eliminated by C frontend.
--- Comment #14 from carlos at codesourcery dot com 2008-03-28 11:39 --- With the patch in comment #9, a glibc cvs head build completes successfully. The test results show some regressions, but this is almost always the case when switching to a new gcc branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35705
[Bug middle-end/35705] [4.3/4.4 Regression] Symbol address check eliminated by C frontend.
--- Comment #13 from carlos at codesourcery dot com 2008-03-28 00:14 --- Dave, I tested the patch you posted in comment #9, and I have no regressions on hppa-linux (C/C++), and it fixes my testcase. I haven't done a full all-languages bootstrap and test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35705
[Bug middle-end/35705] [4.3/4.4 Regression] Symbol address check eliminated by C frontend.
--- Comment #5 from carlos at codesourcery dot com 2008-03-26 15:28 --- Jakub, Would changing FUNCTION_BOUNDARY to something less than a word alignment have disastrous results e.g. unaligned function start addresses? Functions should continue to be aligned at word boundaries. The address of a function has nothing to do with the location of the actual function code. In this case the address of the function is an OPD, and such an address requires special bits to be set. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35705
[Bug middle-end/35705] [4.3/4.4 Regression] Symbol address check eliminated by C frontend.
--- Comment #3 from carlos at codesourcery dot com 2008-03-26 13:34 --- Dave, What do you think of the attached regression test? Is this the right way to test for this behaviour? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35705
[Bug middle-end/35705] [4.3/4.4 Regression] Symbol address check eliminated by C frontend.
--- Comment #2 from carlos at codesourcery dot com 2008-03-26 13:33 --- Created an attachment (id=15381) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15381&action=view) Regression test for bitwise operations on PLABEL32 address. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35705
[Bug c/35705] New: Regression: Symbol address check eliminated by C frontend.
Problem
The C frontend in GCC 4.3.1 appears to assume that the address of a function
pointer is always aligned, and optimizes away certain bitwise operations. This
breaks hppa-linux whose function pointers are either an OPD with a certain bit
set, or a plain function pointer. In GCC 4.3 hppa-linux can no longer check to
see if a function address is an OPD or not.
Background
~~~
The hppa-linux ABI supports non-OPD and OPDs. The difference is that OPDs' have
bit 2 set to 1.
The following testcase shows the change in behaviour between gcc-4_2-branch and
gcc-4_3-branch.
cat >> foo.c <
#include
int main (void) {
printf ("&printf = %x\n", (unsigned long)&printf);
if (((unsigned long) &printf) & 3)
{
printf ("printf is an OPD (PLABEL32)\n");
}
return 0;
}
EOF
[EMAIL PROTECTED]:~/fsrc/gcc-work$
/usr/local/tools/bin/hppa-linux-gcc-4.2.4 -o foo foo.c
[EMAIL PROTECTED]:~/fsrc/gcc-work$ ./foo
&printf = 119ea
printf is a PLABEL32
[EMAIL PROTECTED]:~/fsrc/gcc-work$
/usr/local/tools/bin/hppa-linux-gcc-4.3.1 -o foo foo.c
[EMAIL PROTECTED]:~/fsrc/gcc-work$ ./foo
&printf = 119ea
GCC 4.3, even at -O0, reduces "((unsigned long) &printf) & 3)" to "0".
~~~ foo.c.003t.original ~~~
;; Function main (main)
;; enabled by -tree-original
{
printf ((const char * restrict) (char *) "&printf = %x\n", (long
unsigned int) printf);
if (0)
{
printf ((const char * restrict) (char *) "printf is a PLABEL32\n");
}
return 0;
}
~~~
If the if condition is reduced to "0" as early as 003t.original, does
that mean it's the C frontend fault?
This issue is breaks glibc's detection of PLABEL32 symbols during startup
relocation processing. It also likely breaks unwind code in libjava.
Casting a pointer to an integer type is implementation defined, so the above
change is certainly a regression.
Why this didn't show up in the testing is another issue. Perhaps we just don't
have a test for this (I can correct that pretty easily).
Any ideas how to fix this? Pointers to the change that changed the behaviour?
--
Summary: Regression: Symbol address check eliminated by C
frontend.
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carlos at codesourcery dot com
GCC build triplet: hppa-linux
GCC host triplet: hppa-linux
GCC target triplet: hppa-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35705
[Bug driver/35532] Native GCC no longer searches $prefix/lib for startfiles when run from $objdir
--- Comment #10 from carlos at codesourcery dot com 2008-03-24 17:25
---
Greg,
I've gone through your DIY instructions. Very well done. Using the sysroot
infrastructure is definitely the way forward for you. Looking at your existing
DIY instructions you probably want to:
1. Create a "Construct sysroot" step before the first stage gcc (3.5), this
will include creating $sysroot/usr/include.
2. Install the kernel headers (3.6) as part of the "Construct sysroot" step, or
as the next step.
You might want to verify that this is still needed:
~~~
echo "
/* Remove /usr/include from end of include search path. */
#undef STANDARD_INCLUDE_DIR
#define STANDARD_INCLUDE_DIR 0" >> gcc/config/${DL_HEADER}
~~~
in step (3.10).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532
[Bug driver/35532] Native GCC no longer searches $prefix/lib for startfiles when run from $objdir
--- Comment #6 from carlos at codesourcery dot com 2008-03-14 13:26 --- Greg, As a workaround can you try using all of the sysroot framework? Configure with --with-sysroot=/mnt/foo and --with-build-sysroot=/mnt/foo. Build with LDFLAGS_FOR_TARGET="--sysroot=/mnt/foo" and CPPFLAGS_FOR_TARGET="--sysroot=/mnt/foo". I'm reading through the DIY instructions right now to make sense of your bootstrap process. -- carlos at codesourcery dot com changed: What|Removed |Added CC| |carlos at codesourcery dot | |com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532
[Bug driver/35532] Native GCC no longer searches $prefix/lib for startfiles when run from $objdir
--- Comment #4 from carlos at codesourcery dot com 2008-03-11 19:21 --- Greg, The example you describe looks an awful lot like a cross-compile. Is there anything preventing you from configuring with --enable-build-sysroot=/tmp/foo? Could you also describe your original build process in detail? Please don't think of this as an issue between a relocated or un-relocated compiler. GCC took the kitchen sink approach to search directories, and the patch in question rooted out exactly which directories are needed and which are not. Now that we've cleaned up the search directories, you are going to have to prove why other build processes are *not* usable in your particular scenario. I won't accept "It used to build and now it doesn't." By building gcc you become a gcc developer, not a user, and there is no guarantee that the gcc build process will not change over time. I look forward to the sordid details of your build problem :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532
[Bug driver/17621] Add option to have GCC not search $(prefix)
--- Comment #18 from carlos at codesourcery dot com 2006-12-21 04:23 --- This is fixed in 4.3. If I understand correctly the PR should be closed and the "Target Milestone" marked as 4.3? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17621
[Bug c/30242] [4.3 Regression] internal error in gcc break compilation
--- Comment #4 from carlos at codesourcery dot com 2006-12-20 16:05 --- Bob Rossi <[EMAIL PROTECTED]> and I were working on this issue last night on [EMAIL PROTECTED] http://gcc.gnu.org/ml/gcc-help/2006-12/msg00279.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30242
[Bug c/30242] [4.3 Regression] internal error in gcc break compilation
--- Comment #3 from carlos at codesourcery dot com 2006-12-20 16:01 --- Created an attachment (id=12828) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12828&action=view) Only relocate paths which start with the configured prefix. This fixes the boostrap failure for i686-mingw32. I have bootstrapped x86_64-unknown-linug-gnu with thie patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30242
[Bug driver/17621] Add option to have GCC not search $(prefix)
--- Comment #17 from carlos at codesourcery dot com 2006-12-07 21:10 --- Eric, All of my patches are now on mainline. The compiler and cpp should no longer search in the configured prefix. Have you tested mainline? There may be a couple of lurking spec file reads that try the configured prefix first. Cheers, Carlos. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17621
[Bug driver/17621] Add option to have GCC not search $(prefix)
--- Comment #16 from carlos at codesourcery dot com 2006-10-13 19:40 --- 1. Relocated compiler should not search configured prefix. http://gcc.gnu.org/ml/gcc/2006-10/msg00280.html 2. Remove 'NONE' from computed paths http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00096.html 3. Relocated cpp should not search configured prefix. http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00708.html These three patches should prevent the compile from searching the configured prefix for *all* types of files. Eric, your comments are appreciated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17621
[Bug driver/17621] Add option to have GCC not search $(prefix)
--- Comment #14 from carlos at codesourcery dot com 2006-10-05 08:33 --- GCC_EXEC_PREFIX does not control the search directories for header files. Could you verify that your target actually compiles before applying the patches? Both gcc and cpp need to be taught taught not to search the configured prefix. The patch I provided only the first step. The second step is to improve cpp. I will post a new set of patches for this on the weekend. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17621
[Bug driver/17621] Add option to have GCC not search $(prefix)
--- Comment #11 from carlos at codesourcery dot com 2006-08-22 21:02 --- Created an attachment (id=12115) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12115&action=view) When relocated do not add paths that contain the configured prefix. Thanks for adding me to the CC. A relocated compiler should never search the configured prefix for programs, libraries or start files. A relocated compiler searching for files in the configured prefix is troublesome. The configured prefix may contain a conflicting toolchain, or a slow network path. The old behaviour of searching the conifgured prefix is not what users expect from a relocated toolchain. Consider 3 types of paths: 1. Relocated paths. 2. Configured prefix paths. 3. Well known system paths. The type 1 and type 3 paths are always added to our search lists. The type 2 paths are only added if the compiler is installed at the configured prefix. This patch groups the 3 path types logically in gcc/gcc.c, and adds the paths based on the wether the compiler is relocated or unrelocated. Could you test this patch out and tell me if it helps? There is a caveat, running 'make -k check' from the object directory may not work. In certain cases, bare-metal targets for example, contains the required start files to build and run the tests. I have an additional patch for this, but it is still in testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17621
[Bug c/26774] [4.0/4.1/4.2 Regression] Out of memory compiling 9-line Delta-reduced Linux kernel driver msp3400.c
--- Comment #6 from carlos at codesourcery dot com 2006-04-04 15:01 --- I'll submit the patch to gcc-patches and check it in when approved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26774
[Bug c/26774] [4.0/4.1/4.2 Regression] Out of memory compiling 9-line Delta-reduced Linux kernel driver msp3400.c
--- Comment #5 from carlos at codesourcery dot com 2006-04-04 15:00 --- Created an attachment (id=11201) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11201&action=view) Fix parser error handling The patch fixes this issue. No regressions on i686-pc-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26774
