[Bug rtl-optimization/71496] Two picbase loads created for libjava code on powerpc-darwin after rev 228022.

2017-03-27 Thread tobias.netzel at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71496

Tobias Netzel  changed:

   What|Removed |Added

 CC||tobias.netzel at googlemail 
dot co
   ||m

--- Comment #6 from Tobias Netzel  ---
This fix seems to have had an unwanted sideeffect:
When not compiling with -fno-PIC or -mdynamic-no-pic the compiler for any
compiled function unconditionally saves and restores R31 from/to the stack even
when it's not touched at all.

I've verified that gcc 4.2 (Apple's version), gcc 4.9 and 5.4 don't do that.
But while gcc 4.9 and 5.4 do unconditionally save and restore R31 when -pg is
passed, Apple's gcc 4.2 doesn't even do it then.

Appearantly the interpretation of what Apple meant with the sentence "This
cannot happen with -fPIC because the PIC register (R31) is always "used" in the
sense checked by the consistency check." might need to be revised.

[Bug objc/55572] New: -fobjc-direct-dispatch is not really implemented

2012-12-03 Thread tobias.netzel at googlemail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55572



 Bug #: 55572

   Summary: -fobjc-direct-dispatch is not really implemented

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: objc

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: tobias.net...@googlemail.com





Created attachment 28858

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28858

Implementations for _objc_msgSend_Fast and _objc_assign_ivar_Fast



The switch causes the compiler to generate calls to builtins named

"_objc_msgSend_Fast" and "_objc_assign_ivar_Fast" but an implementation is

missing. Reading the comments those builtins were never meant to be implemented

but in Apple's PowerPC version of gcc those calls were replaced with simple

branch instructions to the hardcoded addresses 0xFFFEFF00 or 0xFFFEFEC0.



Now to me it seems there are two possibilites:

- do it the way Apple intented it to be done - maximum performance

- provide implementations for the builtins in the static libgcc



I tried the latter by simply adding the object file resulting from the attached

assembler code to the static libgcc using the "ar" command. That turns out to

work, although there's one additional branch instruction needed (and maybe

address loading instructions also).

In case that latter way is the preferred solution, the code that adds the call

to the builtin functions should be cleaned up.



I had this problem using gcc 4.7.2 but I'm quite sure this bug has been there

since -fobjc-direct-dispatch was merged from Apple's gcc branch.

Would be nice to have that corrected in the final version of gcc 4.6!


[Bug target/47997] gcc on macosx: "ld: warning: -fwritable-strings not compatible with literal CF/NSString"

2011-09-08 Thread tobias.netzel at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47997

--- Comment #25 from Tobias Netzel  
2011-09-08 16:27:21 UTC ---
As for me the patch does what it is expected to do; no more linker warnings
when linking objective-c code. I didn't notice anything that might be broken by
it.


[Bug target/47997] gcc on macosx: "ld: warning: -fwritable-strings not compatible with literal CF/NSString"

2011-07-20 Thread tobias.netzel at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47997

--- Comment #19 from Tobias Netzel  
2011-07-20 21:53:16 UTC ---
(In reply to comment #18)
> Iain, I'm thinking we should do your code unconditionally for darwin10 and
> later.  In darwin10.h, we put:

To me it seems that specifying LINKER_PEDANTICALLY_WANTS_CSTRING would only do
the same thing as passing -mconstant-cfstrings to gcc. And passing
-mconstant-cfstrings doesn't change anything in my case.
The only thing that helps in my case is the first patch.
You should also be aware that one can build and use (I do) the linker from
darwin10 in earlier versions of the OS.


[Bug target/47997] gcc on macosx: "ld: warning: -fwritable-strings not compatible with literal CF/NSString"

2011-07-20 Thread tobias.netzel at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47997

Tobias Netzel  changed:

   What|Removed |Added

 CC||tobias.netzel at googlemail
   ||dot com

--- Comment #16 from Tobias Netzel  
2011-07-20 20:53:38 UTC ---
Forgot to mention that there weren't any warnings with the 1st (unaccepted)
patch applied.


[Bug target/47997] gcc on macosx: "ld: warning: -fwritable-strings not compatible with literal CF/NSString"

2011-07-20 Thread tobias.netzel at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47997

--- Comment #15 from Tobias Netzel  
2011-07-20 20:51:12 UTC ---
Created attachment 24800
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24800
sample objective-c code that still causes the warning

Said warning does still occur when linking many Objective-C and Objective-C++
files from the mozilla codebase.
The attached sample code and playing a little with it reveals the following
behaviour of gcc:
(to be compiled as follows: "gcc main.m -framework Foundation")
- the strings "Me", "Myself", "I", "Three", "a", "b", "c", "d", "e", "f" and ""
are put into (__TEXT,__const) -> warning
- the strings "One", "Two", "You" and "foo" are put into (__TEXT,__cstring) ->
no warning
- when adding more strings to "NSMutableArray *mutable" or to the
initialization of "NSArray *arr", all strings that have a length other than
three characters are put into (__TEXT,__const) (-> warning) and all strings of
exactly three characters are put into (__TEXT,__cstring) (-> no warning)
- when there's only one string in (__TEXT,__const) there is no warning!