On Mar 3, 2023, Alexandre Oliva wrote:
> Hello, Florian,
> On Mar 3, 2023, Florian Weimer wrote:
>> * Alexandre Oliva via Gcc-patches:
>>> +// Make sure it's not optimized out, not even with LTO.
>>> +asm ("" : : "rm" (depend));
>> If the m constraint is used, this may never emit the
Hello, Florian,
On Mar 3, 2023, Florian Weimer wrote:
> * Alexandre Oliva via Gcc-patches:
>> +// Make sure it's not optimized out, not even with LTO.
>> +asm ("" : : "rm" (depend));
> If the m constraint is used, this may never emit the symbol name and
> thus not create a reference af
* Alexandre Oliva via Gcc-patches:
> +// Make sure it's not optimized out, not even with LTO.
> +asm ("" : : "rm" (depend));
If the m constraint is used, this may never emit the symbol name and
thus not create a reference after all.
On Mar 3, 2023, Jonathan Wakely wrote:
> On Fri, 3 Mar 2023 at 18:12, Jonathan Wakely wrote:
>> And those expressions aren't ever optimized away as unused?
> Oh, I missed that they're called after casting them
*nod*
> That would be UB to call them through the wrong pointer type, so the
> co
On Fri, 3 Mar 2023 at 18:12, Jonathan Wakely wrote:
>
>
> On Fri, 3 Mar 2023 at 17:47, Alexandre Oliva wrote:
>
>> On Mar 3, 2023, Jonathan Wakely wrote:
>>
>> > On Fri, 3 Mar 2023 at 09:33, Jonathan Wakely
>> wrote:
>> >> Jakub previously suggested doing this for PR 61841, which was a simila
On Fri, 3 Mar 2023 at 17:47, Alexandre Oliva wrote:
> On Mar 3, 2023, Jonathan Wakely wrote:
>
> > On Fri, 3 Mar 2023 at 09:33, Jonathan Wakely wrote:
> >> Jakub previously suggested doing this for PR 61841, which was a similar
> >> problem with pthread_create:
> >>
> >> __asm ("" : : "r" (&pt
On Mar 3, 2023, Jonathan Wakely wrote:
> On Fri, 3 Mar 2023 at 09:33, Jonathan Wakely wrote:
>> Jakub previously suggested doing this for PR 61841, which was a similar
>> problem with pthread_create:
>>
>> __asm ("" : : "r" (&pthread_create)); would not be optimized away.
>>
>>
>> That would
On Fri, 3 Mar 2023 at 09:33, Jonathan Wakely wrote:
>
>
> On Fri, 3 Mar 2023 at 08:20, Alexandre Oliva via Libstdc++ <
> libstd...@gcc.gnu.org> wrote:
>
>> On Feb 17, 2023, Jonathan Wakely wrote:
>>
>> > The proper fix is to ensure the program has a non-weak reference to
>> > pthread_join withou
On Fri, 3 Mar 2023 at 08:20, Alexandre Oliva via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> On Feb 17, 2023, Jonathan Wakely wrote:
>
> > The proper fix is to ensure the program has a non-weak reference to
> > pthread_join without extra help (or use a recent glibc where it always
> > works).
>
>
On Feb 17, 2023, Jonathan Wakely wrote:
> The proper fix is to ensure the program has a non-weak reference to
> pthread_join without extra help (or use a recent glibc where it always
> works).
Indeed! How about this? Regstrapped on x86_64-linux-gnu, also tested
on arm-vx7r2 (gcc-12); verified
On Fri, 17 Feb 2023, 06:40 Alexandre Oliva via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
>
> Ref: https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570617.html
>
> Bernd Edlinger reported that the 95989.cc
> test fails without pthread_join at the end of main,
Yes, but that doesn't mean we wan
Ref: https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570617.html
Bernd Edlinger reported that the 95989.cc
test fails without pthread_join at the end of main, but pthread_join
is no good for a test that doesn't require pthreads.
This patch adds a __gthread_join call instead.
Regstrapped on
12 matches
Mail list logo
