--- 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
--- 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
--- 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/msg000
--- 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
--- 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
--- 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. Cre
ty: 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
--- 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
--- 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
--- 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
--- 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.gn
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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 de
--- 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
g -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 triple
: 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
--- 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.
--
--- 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
--- 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
--- 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-
--- 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
--- 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
29 matches
Mail list logo
