--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P5
Target Milestone|4.2.0 |4.1.0
--- Comment #25 from pinskia at gcc dot gnu dot org 2005-10-13 19:57
---
Moving to 4.2 as sh-linux-gnu is not a primary/secondary target.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
What|Removed |Added
Target Milestone|4.0.2 |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
--
What|Removed |Added
CC|zack at codesourcery dot com|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617
--
What|Removed |Added
Severity|critical|normal
Target Milestone|--- |4.0.2
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-04-06
19:32 ---
(In reply to comment #17)
Subject: Re: [4.0/4.1 regression] shared SH libgcc is
exporting too many symbols
joern dot rennecke at st dot com [EMAIL PROTECTED] writes:
[LIB1FUNCS_ST]
Won't this
--- Additional Comments From zack at codesourcery dot com 2005-04-06 20:03
---
Subject: Re: [4.0/4.1 regression] shared SH libgcc is
exporting too many symbols
amylaar at gcc dot gnu dot org [EMAIL PROTECTED] writes:
I just had a look, and actually there appears to be no variable
--- Additional Comments From joern dot rennecke at st dot com 2005-03-29
11:54 ---
Subject: Re: [4.0/4.1 regression] shared SH libgcc is exporting too many
symbols
kkojima at gcc dot gnu dot org wrote:
--- Additional Comments From kkojima at gcc dot gnu dot org 2005-03-25
--- Additional Comments From kkojima at gcc dot gnu dot org 2005-03-29
12:43 ---
joern dot rennecke at st dot com [EMAIL PROTECTED] wrote:
Does it, actually? The mulsi3_call-1 pattern is only used for SH1 code.
Ah, you are right. Sorry for my mess.
--
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-03-24
17:01 ---
This is a wrong-code regression, and, as such, it's a critical bug for 4.0,
except that SH is not a primary or secondary platform. As such, SH bugs should
never have a target milestone; they should just
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-03-24
17:05 ---
Dan points out that Joern was probably referring to Andrew's downgrade, rather
than Zack's comment, when speaking about seriousness.
I'm not sure what prompted Andrew to make that change, but I certainly
--- Additional Comments From schwab at suse dot de 2005-03-24 17:31 ---
Subject: Re: shared SH libgcc is exporting too many
symbols
Joern RENNECKE [EMAIL PROTECTED] writes:
! #define FUNC(X) .type X,@function .hidden X
^^
--- Additional Comments From joern dot rennecke at st dot com 2005-03-24
18:06 ---
Subject: Re: [4.0/4.1 regression] shared SH libgcc is exporting too many
symbols
schwab at suse dot de wrote:
! #define FUNC(X) .type X,@function .hidden X
--- Additional Comments From joern dot rennecke at st dot com 2005-03-24
18:17 ---
Subject: Re: shared SH libgcc is exporting too many symbols
zack at codesourcery dot com wrote:
--- Additional Comments From zack at codesourcery dot com 2005-03-24
16:06 ---
Subject: Re:
--- Additional Comments From zack at codesourcery dot com 2005-03-24 18:46
---
Subject: Re: [4.0/4.1 regression] shared SH libgcc is
exporting too many symbols
joern dot rennecke at st dot com [EMAIL PROTECTED] writes:
Almost all the symbols in config/sh/lib1funcs.asm are
--- Additional Comments From mrs at apple dot com 2005-03-24 19:36 ---
Subject: Re: shared SH libgcc is exporting too many symbols
On Mar 24, 2005, at 8:30 AM, Joern RENNECKE wrote:
! #if 1 /* ??? The export list mechanism is broken, everything that
is not
! hidden is
--- Additional Comments From joern dot rennecke at st dot com 2005-03-24
21:08 ---
Subject: Re: shared SH libgcc is exporting too many symbols
Mike Stump wrote:
Could you add a reference to the PR in the code, as the next person
to play with this will find it useful.
Done.
--- Additional Comments From joern dot rennecke at st dot com 2005-03-24
21:25 ---
Subject: Re: [4.0/4.1 regression] shared SH libgcc is exporting too many
symbols
zack at codesourcery dot com wrote:
You may want to consider use of LIB1FUNCS_ST instead of LIB1FUNCS, so
that the
--- Additional Comments From kkojima at gcc dot gnu dot org 2005-03-24
22:48 ---
I thought that mklibgcc makes such functions hidden if SHLIB_LINK
was defined. In my daily build of sh4-unknown-linux-gnu, all
movstr* and movmem* are hidden:
...
6: 0050 4 FUNC
--
What|Removed |Added
CC|geoffk at geoffk dot org|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617
--- Additional Comments From zack at codesourcery dot com 2005-03-24 22:54
---
Subject: Re: [4.0/4.1 regression] shared SH libgcc is
exporting too many symbols
joern dot rennecke at st dot com [EMAIL PROTECTED] writes:
[LIB1FUNCS_ST]
Won't this have the effect that any of the
--- Additional Comments From joern dot rennecke at st dot com 2005-03-24
23:49 ---
Subject: Re: [4.0/4.1 regression] shared SH libgcc is exporting too many
symbols
kkojima at gcc dot gnu dot org wrote:
--- Additional Comments From kkojima at gcc dot gnu dot org 2005-03-24
--- Additional Comments From zack at codesourcery dot com 2005-03-24 23:54
---
Subject: Re: [4.0/4.1 regression] shared SH libgcc is
exporting too many symbols
joern dot rennecke at st dot com [EMAIL PROTECTED] writes:
So you are saying this needs to list only to-be-excluded
--- Additional Comments From kkojima at gcc dot gnu dot org 2005-03-25
00:30 ---
joern dot rennecke at st dot com [EMAIL PROTECTED] wrote:
FWIW, __mulsi3 should also not be exported, although that is not a
regression.
For the efficiency, yes. Unfortunately, it causes the binary
25 matches
Mail list logo
