[Bug objc/103639] [REGRESSION] GCC 11.2 (or even earlier) breaks switch case with break in fast enumeration loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103639
js-gcc at webkeks dot org changed:
What|Removed |Added
Keywords|wrong-code |
--- Comment #4 from js-gcc at webkeks dot org ---
Sure:
#import
int
main()
{
OFArray *array = [OFArray arrayWithObjects: @"a", @"b", nil];
int someVar = 0;
for (id object in array) {
switch (someVar) {
case 0:
OFLog(@"%@", object);
break;
}
OFLog(@"foo");
}
return 0;
}
Sorry, but something free-standing isn't possible as you need a collection
object. The same code should work with GNUstep by just replacing OF with NS.
[Bug objc/103639] [REGRESSION] GCC 11.2 (or even earlier) breaks switch case with break in fast enumeration loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103639 --- Comment #2 from js-gcc at webkeks dot org --- Oh, forgot to clarify in the example: Assume more than 1 object in the collection and someVar to be 0.
[Bug objc/103639] [REGRESSION] GCC 11.2 (or even earlier) breaks switch case with break in fast enumeration loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103639 js-gcc at webkeks dot org changed: What|Removed |Added CC||js-gcc at webkeks dot org --- Comment #1 from js-gcc at webkeks dot org --- Can confirm the same happens with 11.1.0. 10.2 seems to be fine.
[Bug objc/103639] New: [REGRESSION] GCC 11.2 (or even earlier) breaks switch case with break in fast enumeration loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103639
Bug ID: 103639
Summary: [REGRESSION] GCC 11.2 (or even earlier) breaks switch
case with break in fast enumeration loop
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
Assignee: unassigned at gcc dot gnu.org
Reporter: js-gcc at webkeks dot org
Target Milestone: ---
The following code is miscompiled by GCC 11.2.1. I don't know when this
started, but this is a regression and used to work just fine in older version:
for (id object in someCollection) {
switch (someVar) {
case 0:
puts("0");
break;
}
puts("this should print but doesn't");
}
The break breaks out of the for loop instead of the switch case.
Changing the code to this makes it work:
for (id object in someCollection) {
if (someVar == 0) {
puts("0");
break;
}
puts("this should print and does");
}
This worked just fine with older GCC versions and also works fine with all
versions of Clang.
[Bug objc/56870] New: @catch handler broken with SEH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56870
Bug #: 56870
Summary: @catch handler broken with SEH
Classification: Unclassified
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: js-...@webkeks.org
When trying to use ObjC exceptions with the new SEH support, the caught object
is not the ObjC object, but the _Unwind_Exception instead. Example:
@try {
id e = [Object new];
printf(@throw %p\n, e);
@throw e;
} @catch (id e) {
printf(@catch %p\n, e);
@throw e;
}
Expected behaviour: Both are the same pointer.
Observed behaviour: They differ.
Looking further into it, the second pointer is the pointer to the
_Unwind_Exception (I added debug code in objc_exception_throw that outputs the
pointer after the malloc. It is always the same that's received in the catch).
So it seems the generated landing pad for ObjC code is wrong when using SEH. I
think it is correct that the landing pad receives the _Unwind_Exception and not
the ObjC object. But the landing pad needs to get the ObjC exception out of the
_Unwind_Exception and give that back to the user instead of the
_Unwind_Exception, which the user should never see.
This seems to happen not only with 4.8, but also with 4.9.
I marked this bug as blocker, as 4.8 made SEH the default, effectively breaking
ObjC execptions on Windows.
[Bug objc/56870] @catch handler broken with SEH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56870 js-gcc at webkeks dot org changed: What|Removed |Added CC||js-gcc at webkeks dot org --- Comment #1 from js-gcc at webkeks dot org 2013-04-07 22:49:06 UTC --- Why was this lowered to normal? This is a regression, code that worked fine with GCC 4.7 now just crashes. It makes ObjC code that uses exceptions unusable, as it only crashes.
[Bug libobjc/36610] objc_msg_sendv is broken for targets which pass argument via registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36610 --- Comment #22 from js-gcc at webkeks dot org js-gcc at webkeks dot org 2011-06-14 14:02:05 UTC --- Nope, it's still using __builtin_apply.
[Bug libobjc/48314] Make the new symbols weak symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48314 --- Comment #2 from js-gcc at webkeks dot org js-gcc at webkeks dot org 2011-04-01 19:54:39 UTC --- Yeah, right, it is a bug to supply the symbols that libobjc has been missing for about 10 years, so that you can actually use basic ObjC1 stuff like @synchronize, which gcc always claimed to support… And it is a bug to provide them if libobjc has been dead for years… And it sure is a bug to not wait for the bug reports to be actually cared about after they have been ignored for years…/sarcasm Seriously, you can't assume that people just accept broken stuff for almost ten years and then when someone finally fixes them (thanks a lot for your work on the new libobjc, Nicola!) assume nobody did something to work around it in the meantime, after it was told countless times in bug reports that nobody cares.
[Bug c++/48394] New: ObjC exceptions cannot be caught in ObjC++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48394
Summary: ObjC exceptions cannot be caught in ObjC++
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: js-...@webkeks.org
When trying to catch an ObjC exception in ObjC++, the object you get is bogus.
For example, this crashes:
@try {
@throw [[OFObject alloc] init];
} @catch (id e) {
[e release];
}
Trying to printf(%p, …) the exception before the throw and in the catch shows
that the pointer differs, which should not happen. I had this bug in various
GCC versions from 4.2 up to 4.6. I suspect even earlier versions are affected.
It would be nice if even for older versions an update could be released,
because some platforms are still stuck with gcc 4.2 or 4.4.
[Bug objc/48376] New: gcc does not create an ivar for properties
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48376 Summary: gcc does not create an ivar for properties Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc AssignedTo: unassig...@gcc.gnu.org ReportedBy: js-...@webkeks.org When declaring a @property without declaring an ivar, gcc should automatically create the ivar. However, it outputs an error. Example: @interface Foo: Object @property (retain) id bar; @end
[Bug libobjc/48314] New: Make the new symbols weak symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48314 Summary: Make the new symbols weak symbols Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libobjc AssignedTo: unassig...@gcc.gnu.org ReportedBy: js-...@webkeks.org Hello, gcc 4.6 introduces a lot of new symbols like objc_setProperty, objc_sync_enter etc. Those are often already provided since they were always missing, but support for e.g. @synchronized was always there. This creates conflicts now when using gcc 4.6, thus I would suggest to make those weak symbols in 4.6.1.
[Bug bootstrap/47147] gcc 4.6 fails to compile on NetBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47147 --- Comment #11 from js-gcc at webkeks dot org js-gcc at webkeks dot org 2011-01-13 13:28:27 UTC --- Sorry for the late reply. Your patch worked fine.
[Bug libobjc/47031] libobjc uses mutexes for properties
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47031 --- Comment #8 from js-gcc at webkeks dot org js-gcc at webkeks dot org 2011-01-08 16:14:28 UTC --- Yeah, but Linux is just one of the many OSes supported by GCC. And I don't know of any other OS that uses futexes fors pthread mutexes. It would still be good to try a worst-case benchmark of spinlocks in the highly contended case. I am assuming the performance would be really really bad, but then I may just be wrong. ;-) As I said: I doubt it, as it's only 10 spins and then the control is given to another thread. Benchmarking Mutexes, Futexes and Spinlocks in the highligh contended case would be interesting. I guess all three are almost equal in this case, but differ a lot in the less contended case.
[Bug libobjc/47031] libobjc uses mutexes for properties
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47031 --- Comment #6 from js-gcc at webkeks dot org js-gcc at webkeks dot org 2011-01-07 18:43:15 UTC --- This means that, assuming that spinlocks are infinitely faster than mutexes, in the best possible conditions they would speed up the accessors (or, at least, the setter, but the getter should be the same) by a maximum of about 2x. That's a great speedup by the way, but it's important to keep in mind that the maximum speedup we can theoretically ever get for accessors is a 2x, not a 10x or 100x. ;-) That's interesting. Which compiler flags did you use? Did you try -fomit-framepointer? Did you do IMP caching or did you dispatch the method again all the time? With which flags did you build the rest runtime? Remember: The dispatch in the current implementation is not very efficient and the significance of this could change a lot once the dispatch is optimized. Anyway, the key problem is that spinlocks are more wasteful (and unpredictable ?) than mutexes if there is contention and if the ratio of active threads vs. active cores is not favourable. Well, not really: Usually, the lock is not held. If it is, you do a little trick: You spin 10 times and if you still could not get the lock, it's likely the current thread is blocking another thread from releasing the spinlock. Again, quite unlikely, as the spinlock is only held for an extremely short amount of time. However, if it happens that after 10 spins you still could not get the lock, you call sched_yield() to NOT waste resources. So, in the worst case, you waste 10 spins. That's basically 10 compares. That's nothing compared to a user/kernelspace switch, which is often 10 times more. Especially on architectures like SPARC64, this is extremely expensive. And it's extremely unlikely the OS gives control to another OS before the lock is released again. So, this almost never happens. So we can assume that almost always the spinlock is faster here. It is hard to see how you can guarantee anything about contention or ratio of active threads vs. active cores in that context. :-( See the explanation above and in the comment before. I listed all the situations that can happen there, including multicore and singlecore machines. I guess I'd feel a bit more confident if we were to experiment and benchmark the worst-case scenario of spinlocks ... ie, how bad can they really go compared to mutexes and how easy/hard it is for them to go bad in the case of accessors. If you give control to another thread after 10 spins, I doubt it will behave much worse than mutexes. And again, this is very unlikely to happen. But feel free to benchmark :). I'd be especially interested in benchmarks on platforms where context switches are cheap and benchmarks on platforms where context switches are extremely expensive. Anyway, I understand you think spinlocks will always be faster than mutexes in this case, because My guess is that usually the spinlock is not held, but the problem is that that is a guess, and it depends on how the accessors are used. ;-) Feel free to print Conflict! or something when that happens and try it in a realworld scenario ;). For the large list you created, I'm not sure what I should reply, because I'm not sure whether those are questions or if you regard them as facts and because I think I already commented most of it before. One thing though: (having 100s of threads is pretty common in server software where you are processing large numbers of indipendent requests simultaneously; This is considered bad design. Stuff like select(), epoll() etc. exists ;). You usually should have num_cores threads for best performance. But if the second thread is running on the same core, it will never make any progress during the spinning, and the first thread will waste CPU time before being suspended - in this case it will be slower and more CPU-wasteful than a mutex. See above about the maximum spin count and sched_yield(). * I also wonder, with all the CPUs that GCC support, if the GCC atomic builtins are efficient on all platforms; if on a platform the builtins require function calls they may actually make the spinlocks less attractive compared to mutexes (we can obviously work around this by using spinlocks on the two or three major platforms where we know they work well, and using mutexes on the other ones). Do you know of any architectures where GCC needs to call a method? I've seen GCC trying to call some methods for atomic ops - but this was always on architectures which didn't support atomic operations at all. What I do is that I check for atomic ops, then spinlocks in pthread and if that all fails fall back to mutexes. I would have no problem changing my mind and supporting the use of spinlocks if there is some evidence that they can't go *too* wrong ;-) I guess you you should just test hybrid spin locks where you give control to the kernel after
[Bug bootstrap/47147] gcc 4.6 fails to compile on NetBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47147 --- Comment #2 from js-gcc at webkeks dot org js-gcc at webkeks dot org 2011-01-03 16:13:14 UTC --- /home/js/gcc-trunk/configure --enable-long-long --disable-multilib --enable-threads --disable-symvers --enable-__cxa_atexit --enable-languages=c,c++,objc,obj-c++ --with-mpfr=/usr/local --with-mpc=/usr/local --with-gmp=/usr/local
[Bug libobjc/47031] libobjc uses mutexes for properties
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47031 --- Comment #3 from js-gcc at webkeks dot org js-gcc at webkeks dot org 2011-01-01 12:06:56 UTC --- The problem is that property accessors are basically general purpose routines that may be used in the most varied situations. It does not matter very much in which situation a property is used. To chose which type of lock you use, it's only important what is done while the lock is held. In this case, no call to the kernel-space is made at all and only a small operation is done. Switching to kernel-space for a mutex is already way more complex than what we do in the lock. If I'd have to guess, I'd say switching to kernel-space is at least 100 times more expensive than what we do. So, we have very little control or knowledge over when and how they are used -- Which we don't care about at all. * we don't know how many CPUs or cores the user has Does not really matter. If we have two cores, the spinlock can give control to another thread after 10 spins using sched_yield(). So, if we only have one core and one thread spins because it waits for another core to release the lock, then we waste at maximum 10 tries. This is the worst-case scenario. If we have more than one core, we most likely have another thread releasing the lock before it even spinned 10 times. So, no matter how many cores, it does not perform worse than a mutex (at least not in a measurable way), while on systems with many cores, it's a huge improvement. Plus changing a property is something that's so fast that we most likely will never encounter a locked spinlock. That'd only happen if the scheduler gave control to another thread before the property was changed. So, with spinlocks, in 99% of the cases, it's not even measurable. With mutexes, in 100% of the cases, it IS measurable. * we don't know how many threads the user is starting * we don't know how many threads are sharing a CPU or core We don't really care about them, I think. * we don't know how intensively the user is using the property accessors So, because we don't know how intensively the user is using properties, we will make them slow on purpose? Spinlocks are appropriate when certain conditions are met; but in this case, it seems impossible to be confident that these are met. Which conditions are not met in your opinion? Please list the conditions that you think are not met, as Apple clearly thinks they are all met. And so do I. A user may write a program with 3 or 4 threads running on his 1 CPU/core machine, which constantly read/write an atomic synthesized property to synchronize between themselves. Why not; but then, spinlocks would actually degrade performance instead of improving it. This is actually why you call sched_yield() after 10 spins. It prevents a thread from being stuck spinning while another thread could release the lock. Traditional locks may be slower if you a low contention case, but work consistently OK in all conditions. Yes, they are the same in all conditions because they are always more complex and slower ;). * spinlocks are better/faster if there is low contention and very little chance that two threads enter the critical region (inside the accessors) at the same time. This is the case here. * the difference in performance between mutexes and spinlocks only matters in the program performance if the accessors are called very often. If you init a lot of objects and those initialize let's say 30 variables using properties, then this means that 30 locks are retained and released, although no other thread could possibly access it. But still you do 30 userland-kernelspace-switches. For a single object! Now create 1000 objects. With spinlocks, there won't be a single userland-kernelspace-switch! Just to demonstrate that we are talking about something which really can make a huge difference… I think the percentages you list cannot be used at all, as we don't have applications just doing some math calculations and then quitting. We don't want something slow just because it might only be a small part of the program. We want everything to be as fast as possible. Otherwise it sums up and makes a crappy user experience for interactive applications. Apple demonstrated this quite well if you compare how crappy it felt a few years ago and how well it feels now that they started optimizing the small stuff as well. The only case where spinlocks really help is if the program spends lots of time calling accessors, and is not multi-threaded. In which case, the programmer could get a huge speed-up by simply declaring the properties non-atomic. Even in a threaded environment, it would make a huge difference. It's unlikely the lock is held. Only if it is held, you need some CPU time. But with Mutexes, each time you only check if the lock is held, you already switch to kernel-space. Would using spinlocks make accessors 2x faster ? 10x faster ? 10% faster ? My
[Bug bootstrap/47147] New: gcc 4.6 fails to compile on NetBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47147 Summary: gcc 4.6 fails to compile on NetBSD Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: js-...@webkeks.org /home/js/gcc-build/./prev-gcc/xgcc -B/home/js/gcc-build/./prev-gcc/ -B/usr/local/x86_64-unknown-netbsd5.1./bin/ -B/usr/local/x86_64-unknown-netbsd5.1./bin/ -B/usr/local/x86_64-unknown-netbsd5.1./lib/ -isystem /usr/local/x86_64-unknown-netbsd5.1./include -isystem /usr/local/x86_64-unknown-netbsd5.1./sys-include-c -DHAVE_CONFIG_H -g -O2 -gtoggle -I. -I/home/js/gcc-trunk/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic -fpic /home/js/gcc-trunk/libiberty/mempcpy.c -o pic/mempcpy.o; \ else true; fi /home/js/gcc-trunk/libiberty/mempcpy.c:35:36: error: unknown type name ‘size_t’ /home/js/gcc-trunk/libiberty/mempcpy.c:38:34: error: unknown type name ‘size_t’ Looking at the file, it includes stddef.h, which does define size_t on NetBSD: webkeks:/tmp$ cat test.c #include stddef.h size_t foo; webkeks:/tmp$ gcc -c test.c webkeks:/tmp$ So it seems that uding the build process, different headers are used which are broken.
[Bug libobjc/47012] nonatomic Properties behave wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47012 --- Comment #8 from js-gcc at webkeks dot org js-gcc at webkeks dot org 2010-12-21 11:26:37 UTC --- Hm, a mutex can be a real problem there, I guess. Accessors are used all the time, having a kernel lock each time will be a giant slowdown, especially as most of the time, the lock is not held anyway and if it is, it's only held for a very short period of time. I think this should be changed to spinlocks, even for 4.6. Should I create a bug report for that? If the problem is that we don't know whether we have a spinlock implementation on the system and would need to patch configure.ac and this is too much change before the release, we could just use gcc's __sync_bool_compare_and_swap, spin 10 times and if we still could not acquire our spinlock give control to another process using yield().
[Bug libobjc/47031] New: libobjc uses mutexes for properties
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47031 Summary: libobjc uses mutexes for properties Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libobjc AssignedTo: unassig...@gcc.gnu.org ReportedBy: js-...@webkeks.org In trunk, libobjc uses objc_mutex_t for properties. This means that each time you set a property, a lock in kernelspace is acquired, though most of the time there is not even a lock held and if it is only for a very short time. As properties are used quite often, spinlock should be used here, as locks will be a performance problem.
[Bug libobjc/47012] New: nonatimic Properties behave wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47012 Summary: nonatimic Properties behave wrong Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libobjc AssignedTo: unassig...@gcc.gnu.org ReportedBy: js-...@webkeks.org It seems nonatomic properties retain and autorelease the result, which is breaking existing code targeting the Apple runtime. This bug has been also in the GNUstep runtime and the Cocotron runtime, it seems this bug has been copied to the new GNU runtime now. The Apple doc says: If you specify nonatomic, then a synthesized accessor for an object property simply returns the value directly. http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocProperties.html I have written a property implementation which is known to be compatible to the Apple runtime which is quite short and I'd like to contribute. It is currently licensed under the QPL, but I plan to relicense it as GPL if you are interested. If you need a testcase, there is a test for properties included in ObjFW https://webkeks.org/hg/objfw, in src/PropertiesTests.m, which also fails. It works well with the Apple runtime and the included properties implementation in src/objc-properties.m - this is also the implementation I'd like to contribute. Let me know if you are interested. Direct links: Runtime I'd like to contribute: https://webkeks.org/hg/objfw/file/tip/src/objc_properties.m (Will relicense if there's interest!) Tests that fail: https://webkeks.org/hg/objfw/file/tip/tests/PropertiesTests.m
[Bug libobjc/47012] nonatomic Properties behave wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47012 --- Comment #2 from js-gcc at webkeks dot org js-gcc at webkeks dot org 2010-12-19 18:49:39 UTC --- Hi Nicola, yes, I do remember our talk at FOSDEM and I plan to attend it next year again, since I unfortunately could not attend it this year. Well, I guess it's not really like this because everyone felt this is better, I guess it is because Cocotron was the first to implement it (IIRC), then GNUstep looked how they solved it and now GCC looked how GNUstep solved it ;). I think it's not a bug, but intended, as not only the Apple runtime handles it like that, but the doc also says it's just a return. So the documented behaviour and the real behaviour are in sync, I guess the name nonatomic was just a bad choice and the real idea was to have a way to create a lightweight accessor which is mostly used internally. There are several hints that nonatomic is thought for internal use in the formulations used by Apple. Plus, if you care that much about performance that the spinlock is too much for you, then autoreleasing would definitely also be a problem for you ;). I mostly use nonatomic in some special cases like exceptions where the object which caused the exception should not be retained and autoreleased to prevent exception-loops (for example, if autorelease caused the exception to be thrown, that'd be a problem here). In the code you linked, is that objc_mutex_t a spinlock? If not, this might be performance problem. Speaking of performance and contributing: I wrote my own runtime some time ago. The lookup is twice as fast as in libobjc in my tests (with ASM enabled even more). Maybe we could work on merging that into libobjc on next FOSDEM? I mostly wrote my runtime because there weren't any changes in the GNU runtime for a long time and I was happy to see that things finally changed with gcc 4.6 :). If you want to have a look: https://webkeks.org/hg/objfw-rt (Hint: Thread-safety is still missing, though the data structure for the lookup only needs a write-lock and no read-lock and can still be read while it is written and it's also missing exceptions (copying the exception.c from GNU libobjc works)) I think it would be great to also work with the guys from Clang. I think it would only make sense to have the same runtime on all non-Apple systems, regardless of the compiler.
[Bug libobjc/47012] nonatomic Properties behave wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47012 --- Comment #6 from js-gcc at webkeks dot org js-gcc at webkeks dot org 2010-12-19 19:19:33 UTC --- Well, I did not plan to get that included in 4.6. If you are interested in optimizing the lookup: The lookup could be greatly improved if we also change the ABI, which is currently the limitation as the current ABI does not allow for coherent inline caching etc. This needs changes in the compiler, therefore I did not do that - maintaining a runtime AND patchset for two compilers really is too much work for a single person ;). I'd love to work on that, will you visit FOSDEM next year? If so, we could meet up there and hack on that :). I'd really love to reduce the extremely huge speed difference between the GNU runtime and the Apple runtime. At the moment, dispatch is more than 5 times faster with GNU (at least that's what I measured some time ago on Leopard, I guess with Snow Leopard it might be even more).
[Bug libobjc/39465] libobjc does not find classes of DLLs
--- Comment #15 from js-gcc at webkeks dot org 2009-12-20 00:31 --- After looking some more at the code, I might have an idea what's causing the issue: __objc_gnu_init calls __objc_exec_class on _OBJC_MODULES. Is it possible that this call is not made for some reason if you link your lib as a dll? That would mean the classes are never loaded into the runtime. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
[Bug inline-asm/42214] New: gcc generates broken code with -O=1 for x86_64 after an asm call
When using -O=1, gcc uses the wrong register for the inline assembly below. In
my actual usecase, it even does
bswap %eax
xorl %eax, %eax
so it instantly threw away the value. When using -m32, it seems to generate
correct code.
== CODE FILES ==
asgard:/tmp$ cat x.c
#include stdint.h
uint32_t
x()
{
return 0x11223344;
}
asgard:/tmp$ cat test.c
#include stdint.h
#include stdio.h
extern uint32_t x();
static inline __attribute__((always_inline))
bswap32(uint32_t i)
{
asm(bswap %0 : =q(i) : q(i));
return i;
}
int
main()
{
printf(%08X\n, bswap32(x()));
return 0;
}
== OUTPUT ==
asgard:/tmp$ gcc test.c x.c
asgard:/tmp$ ./a.out
44332211
asgard:/tmp$ gcc -O1 test.c x.c
asgard:/tmp$ ./a.out
381E625D
== ASSEMBLY OUTPUT (only important parts) ==
asgard:/tmp$ gcc -S test.c
asgard:/tmp$ cat test.s
[
]
movl$0, %eax
callx
movl%eax, -4(%rbp)
movl-4(%rbp), %eax
#APP
# 9 test.c 1
bswap %eax
# 0 2
#NO_APP
movl%eax, -4(%rbp)
movl-4(%rbp), %eax
movl%eax, %edx
movl$.LC0, %eax
movl%edx, %esi
movq%rax, %rdi
movl$0, %eax
callprintf
[
]
asgard:/tmp$ gcc -S -O1 test.c
asgard:/tmp$ cat test.s
[
]
movl$0, %eax
callx
#APP
# 9 test.c 1
bswap %edx
# 0 2
#NO_APP
movl$.LC0, %esi
movl$1, %edi
movl$0, %eax
call__printf_chk
[
]
--
Summary: gcc generates broken code with -O=1 for x86_64 after an
asm call
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: js-gcc at webkeks dot org
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42214
[Bug libobjc/39465] libobjc does not find classes of DLLs
--- Comment #14 from js-gcc at webkeks dot org 2009-07-16 21:16 --- Any comments? This is still very annoying and completely killing the ability to have plugins/bundles on win32. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
[Bug libobjc/39465] libobjc does not find classes of DLLs
--- Comment #12 from js-gcc at webkeks dot org 2009-06-09 19:17 ---
Any news? I even tried this now, which still produced an .a file:
../gcc-4.3.0-20080502/configure -v --prefix=/usr --libexecdir=/usr/lib \
--program-prefix=mingw32- --target=mingw32 --with-headers=/usr/mingw32/include
--disable-nls --enable-shared --enable-languages=objc
make configure-target-libobjc
make all-target-libobjc
make install-target-libobjc
Note the --enable-shared, which is _DEFINITELY_ being passed to configure
(quoting Makefile in builddir):
maybe-configure-target-libobjc: configure-target-libobjc
configure-target-libobjc:
@: $(MAKE); $(unstage)
@r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
echo Checking multilib configuration for libobjc...; \
$(SHELL) $(srcdir)/mkinstalldirs $(TARGET_SUBDIR)/libobjc ; \
$(CC_FOR_TARGET) --print-multi-lib
$(TARGET_SUBDIR)/libobjc/multilib.tmp 2 /dev/null ; \
if test -r $(TARGET_SUBDIR)/libobjc/multilib.out; then \
if cmp -s $(TARGET_SUBDIR)/libobjc/multilib.tmp
$(TARGET_SUBDIR)/libobjc/multilib.out; then \
rm -f $(TARGET_SUBDIR)/libobjc/multilib.tmp; \
else \
rm -f $(TARGET_SUBDIR)/libobjc/Makefile; \
mv $(TARGET_SUBDIR)/libobjc/multilib.tmp
$(TARGET_SUBDIR)/libobjc/multilib.out; \
fi; \
else \
mv $(TARGET_SUBDIR)/libobjc/multilib.tmp
$(TARGET_SUBDIR)/libobjc/multilib.out; \
fi; \
test ! -f $(TARGET_SUBDIR)/libobjc/Makefile || exit 0; \
$(SHELL) $(srcdir)/mkinstalldirs $(TARGET_SUBDIR)/libobjc ; \
$(NORMAL_TARGET_EXPORTS) \
echo Configuring in $(TARGET_SUBDIR)/libobjc; \
cd $(TARGET_SUBDIR)/libobjc || exit 1; \
case $(srcdir) in \
/* | [A-Za-z]:[\\/]*) topdir=$(srcdir) ;; \
*) topdir=`echo $(TARGET_SUBDIR)/libobjc/ | \
sed -e 's,\./,,g' -e 's,[^/]*/,../,g' `$(srcdir) ;; \
esac; \
srcdiroption=--srcdir=$${topdir}/libobjc; \
libsrcdir=$$s/libobjc; \
rm -f no-such-file || : ; \
CONFIG_SITE=no-such-file $(SHELL) $${libsrcdir}/configure \
$(TARGET_CONFIGARGS) --build=${build_alias} --host=${target_alias} \
--target=${target_alias} $${srcdiroption} \
|| exit 1
And TARGET_CONFIGARS is:
TARGET_CONFIGARGS = --cache-file=./config.cache --enable-multilib
--with-cross-host=i686-pc-linux-gnu '-v' '--prefix=/usr'
'--libexecdir=/usr/lib' '--with-headers=/usr/mingw32/include' '--disable-nls'
'--enable-shared' '--enable-languages=c,objc'
--program-transform-name='s,^,mingw32-,'
--with-target-subdir=$(TARGET_SUBDIR)
As you can see, --enable-shared is listed there, so libobjc's configure is
simply ignoring --enable-shared it seems.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
[Bug libobjc/39465] libobjc does not find classes of DLLs
--- Comment #13 from js-gcc at webkeks dot org 2009-06-09 19:27 --- Oh, for the record: cygwin now has gcc4 imported and they have libobjc as a shared .dll file. Using their dll, it works. So this means libobjc works with dll files if it is a dll file itself. But unfortunately, it's not possible to build it as a dll for mingw32 it seems. Still, I think there should be either both (.dll and .a) or the .a file should be able to load other dlls. Having only a .dll would mean that every app depends on libobjc.dll, which most likely no windows user will have. That's as if every C++ app would require gcc's libstdc++.dll on Windows. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
[Bug libobjc/39817] New: objc_msg_sendv crashes on AMD64
On AMD64, using objc_msg_sendv leads to a segfault. This is because libobjc uses __builtin_return in objc_msg_sendv, which is broken on AMD64. I'm not sure whether I should create another bug that it's broken on AMD64 or if I should just report it as a bug in libobjc. The workaround would be to use libffi in objc_msg_sendv. This bug renders libobjc pretty useless on AMD64, because forwarding is used a lot in objc and each time you forward something, it just crashes. This is the reason why I chose blocker as severity, it makes libobjc completely useless on AMD64. And I'm pretty sure this affects other architectures as well. The backtrace is: #0 0x00600c30 in _OBJC_SELECTOR_TABLE () #1 0x in ?? () If you change objc_msg_sendv to not use __builtin_return but instead return for example NULL, it works (though of course the return value is wrong). I really recommend getting this fixed for the next 4.3 release. Objc support is unusable as it is on AMD64 atm. I'm confused that none of the GNustep guys reported this before, but I remember that they're using libffi somewhere, so most likely they'll use it here as well. -- Summary: objc_msg_sendv crashes on AMD64 Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: libobjc AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: js-gcc at webkeks dot org GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39817
[Bug libobjc/39465] libobjc does not find classes of DLLs
--- Comment #8 from js-gcc at webkeks dot org 2009-04-06 19:41 --- Any news on this? Any way how I could compile libobjc as a shared library? Specifying --enable-shared breaks basically every library that gcc ships and I haven't found a way to only enable it for libobjc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
[Bug libobjc/39465] libobjc does not find classes of DLLs
--- Comment #10 from js-gcc at webkeks dot org 2009-04-06 21:39 --- What exactly do you mean by native build? Do you mean if I build a compiler to run on Linux and not on win32, but which targets win32? If so, yes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
[Bug libobjc/39465] libobjc does not find classes of DLLs
--- Comment #7 from js-gcc at webkeks dot org 2009-03-17 14:05 --- Since I wasn't able to get a cross tool chain running (and www.mingw.org doesn't seem to support that with the current gcc versions) Please have a look at the Portfiles I gave you a link to, they include all the stuff you need to know to build mingw32 with gccc 4.3 as a crosscompiler ;). It's a good idea to remove the libobjc.a and libobjc.la and include/objc headers that come with gcc (gcc -v for location) so that they are not accidentally found instead of the libobjc DLL that you will compile below. ... Yeah, that's exactly what Nicola Pero told me. The default is that there's only a libobjc.a on Win32, but that doesn't work. So GNUstep lets you compile a libobjc.dll and if you use that instead, it works. Well except that GNUstep is using a shared libobjc. Yeah, that should already do the trick. I'm going to throw in the towel here, but I don't believe your issue has to do with libobjc. I think your missing some flag or extra processing that gnustep-make might do for you dll or the program. That's what I thought first, too. But after talking to several GNUstep developers on FOSDEM, none of them was aware of any extra flags. They said all they did was recompile libobjc as a DLL and then it would work. I haven't seen any DllMain() in libobjc yet (though I have to admit I haven't really looked for it, only had a few libobjc sources open in the editor for various reasons, but never to look for DllMain), but it might be possible that there is some initialization code in DllMain() of libobjc.dll that does some initializing stuff that fixes it. But I also believe that statically linking (potentially different versions) of libobjc into different modules is error prone. I guess it would be OK, if you only have a single executable, but the constellation of the dll linking one version and the executable potentially linking another scares me... even if that itself is most likely not your issue either. I think the DLLs don't link to the static version of libobjc - at least, I hope so, as that'd be useless. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
[Bug libobjc/39465] libobjc does not find classes of DLLs
--- Comment #3 from js-gcc at webkeks dot org 2009-03-16 11:24 --- When the target is mingw32, it seems that libobjc is only built as a static library. This isn't a bad idea after all, because I guess no win32 user has a libobjc.so installed somewhere, so you would need to ship that file with every binary produced from ObjC-sources. I heard from the GNUstep guys that they had the same problem until they linked libobjc dynamically. But IMO, this is only a workaround - it should also work if libobjc is linked statically. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
[Bug libobjc/39465] libobjc does not find classes of DLLs
--- Comment #5 from js-gcc at webkeks dot org 2009-03-16 11:46 --- It would be hard to link to that discussion as that was IRL on FOSDEM in the GNUstep Dev Room :). I reported that bug once on the mingw32 list, but they wouldn't really care about it. After speaking to Nicola Pero on FOSDEM, I decided that it'd be best to file a bug for libobjc - and so I did :). For building mingw32 with gcc 4, you could have a look at these Port files I wrote: https://webkeks.org/hg/crux_ports/file/6062794869e8/mingw32-api https://webkeks.org/hg/crux_ports/file/6062794869e8/mingw32-binutils https://webkeks.org/hg/crux_ports/file/6062794869e8/mingw32-gcc https://webkeks.org/hg/crux_ports/file/6062794869e8/mingw32-runtime -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
