On 07/29/2016 01:31 PM, Bernd Edlinger wrote:
On 07/29/16 19:28, Jeff Law wrote:
On 07/26/2016 09:48 AM, Bernd Edlinger wrote:
Richard, this was the latest version of the patch:
https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01481.html
Are you OK with my clean-up of the presumably dead functi
On 07/29/16 19:28, Jeff Law wrote:
> On 07/26/2016 09:48 AM, Bernd Edlinger wrote:
>
>> Richard, this was the latest version of the patch:
>> https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01481.html
>>
>>
>> Are you OK with my clean-up of the presumably dead function names,
>> or would you like to
On 07/26/2016 09:48 AM, Bernd Edlinger wrote:
Richard, this was the latest version of the patch:
https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01481.html
Are you OK with my clean-up of the presumably dead function names,
or would you like to keep the quirks in special_function_p for now
and ju
On Tue, 19 Jul 2016, Bernd Edlinger wrote:
> It is however not possible to remove the special handling by name
> altogether, because the glibc does not add the return_twice function
> attribute on _setjmp, __sigsetjmp and getcontext until today; a glibc
> BZ is filed at: https://sourceware.org/bug
On 07/22/16 14:49, Bernd Edlinger wrote:
>
> Hmm, cough...
>
> Boot-strap and reg-test was OK, but...
>
> I just noticed that the new built-ins do not quite work as expected.
>
> First with C++ there is no warning in this example although the
> parameters are different:
>
> cat test2.C
> extern "C"
On 07/22/16 14:28, Richard Biener wrote:
> On Thu, 21 Jul 2016, Bernd Edlinger wrote:
>
>> Hi,
>>
>> based on the discussion here, I have updated my patch again...
>>
>> This is the rest of the patch, which removes outdated function names,
>> and creates built-in definitions for vfork, getcontext
On 07/21/16 23:57, Bernd Edlinger wrote:
> Hi,
>
> based on the discussion here, I have updated my patch again...
>
> This is the rest of the patch, which removes outdated function names,
> and creates built-in definitions for vfork, getcontext, savectx.
> These built-ins have the return_twice attr
On Fri, Jul 22, 2016 at 02:28:15PM +0200, Richard Biener wrote:
> As DEF_EXT_LIB_BUILTIN won't have any effect with -std=c99 for example
> I don't think having the builtins helps much. I think we have
Well, -std=gnu11 is the default, so it will help.
Jakub
On Thu, 21 Jul 2016, Bernd Edlinger wrote:
> Hi,
>
> based on the discussion here, I have updated my patch again...
>
> This is the rest of the patch, which removes outdated function names,
> and creates built-in definitions for vfork, getcontext, savectx.
> These built-ins have the return_twice
Hi,
based on the discussion here, I have updated my patch again...
This is the rest of the patch, which removes outdated function names,
and creates built-in definitions for vfork, getcontext, savectx.
These built-ins have the return_twice attribute but not the
leaf attribute, because we do not r
On 07/21/16 17:17, Jeff Law wrote:
> It's possible the issue came up building the SunOS/Solaris kernel --
> circa 1992 I was loosely involved in a project that was bringing up that
> kernel on non-Sun hardware. And that fits my recollection of when
> savectx support went into GCC.
>
> jeff
Yes.
On Wed, Jul 20, 2016 at 1:02 PM, Eric Botcazou wrote:
>> Very few targets continue to use SJLJ eh (perhaps just cygwin/mingw).
>> *But* I think the Ada front-end explicitly uses SJLJ EH, so if you want
>> to get some smoke testing, the Ada testsuite is probably the place to go.
>
> Right, the Ada
On 07/21/2016 09:07 AM, Bernd Edlinger wrote:
On 07/21/16 14:08, Richard Biener wrote:
On Thu, 21 Jul 2016, Bernd Edlinger wrote:
On 07/21/16 13:35, Richard Biener wrote:
On Thu, 21 Jul 2016, Bernd Edlinger wrote:
On 07/21/16 13:25, Bernd Schmidt wrote:
On 07/21/2016 01:16 PM, Jakub Jeli
On 07/21/16 14:08, Richard Biener wrote:
> On Thu, 21 Jul 2016, Bernd Edlinger wrote:
>
>> On 07/21/16 13:35, Richard Biener wrote:
>>> On Thu, 21 Jul 2016, Bernd Edlinger wrote:
>>>
On 07/21/16 13:25, Bernd Schmidt wrote:
>
>
> On 07/21/2016 01:16 PM, Jakub Jelinek wrote:
>> O
On Thu, 21 Jul 2016, Bernd Edlinger wrote:
> On 07/21/16 13:35, Richard Biener wrote:
> > On Thu, 21 Jul 2016, Bernd Edlinger wrote:
> >
> >> On 07/21/16 13:25, Bernd Schmidt wrote:
> >>>
> >>>
> >>> On 07/21/2016 01:16 PM, Jakub Jelinek wrote:
> On Thu, Jul 21, 2016 at 11:04:48AM +, Bern
On 07/21/16 13:35, Richard Biener wrote:
> On Thu, 21 Jul 2016, Bernd Edlinger wrote:
>
>> On 07/21/16 13:25, Bernd Schmidt wrote:
>>>
>>>
>>> On 07/21/2016 01:16 PM, Jakub Jelinek wrote:
On Thu, Jul 21, 2016 at 11:04:48AM +, Bernd Edlinger wrote:
> bool
> +gimple_alloca_call_p (
On Thu, 21 Jul 2016, Bernd Edlinger wrote:
> On 07/21/16 13:25, Bernd Schmidt wrote:
> >
> >
> > On 07/21/2016 01:16 PM, Jakub Jelinek wrote:
> >> On Thu, Jul 21, 2016 at 11:04:48AM +, Bernd Edlinger wrote:
> >>> bool
> >>> +gimple_alloca_call_p (const gimple *stmt)
> >>> +{
> >>> + tree fnd
On 07/21/16 13:25, Bernd Schmidt wrote:
>
>
> On 07/21/2016 01:16 PM, Jakub Jelinek wrote:
>> On Thu, Jul 21, 2016 at 11:04:48AM +, Bernd Edlinger wrote:
>>> bool
>>> +gimple_alloca_call_p (const gimple *stmt)
>>> +{
>>> + tree fndecl;
>>> +
>>> + if (!is_gimple_call (stmt))
>>> +return
On Thu, 21 Jul 2016, Bernd Edlinger wrote:
> On 07/21/16 13:16, Jakub Jelinek wrote:
> > On Thu, Jul 21, 2016 at 11:04:48AM +, Bernd Edlinger wrote:
> >> bool
> >> +gimple_alloca_call_p (const gimple *stmt)
> >> +{
> >> + tree fndecl;
> >> +
> >> + if (!is_gimple_call (stmt))
> >> +ret
On 07/21/16 13:16, Jakub Jelinek wrote:
> On Thu, Jul 21, 2016 at 11:04:48AM +, Bernd Edlinger wrote:
>> bool
>> +gimple_alloca_call_p (const gimple *stmt)
>> +{
>> + tree fndecl;
>> +
>> + if (!is_gimple_call (stmt))
>> +return false;
>> +
>> + fndecl = gimple_call_fndecl (stmt);
>> +
On 07/21/2016 01:16 PM, Jakub Jelinek wrote:
On Thu, Jul 21, 2016 at 11:04:48AM +, Bernd Edlinger wrote:
bool
+gimple_alloca_call_p (const gimple *stmt)
+{
+ tree fndecl;
+
+ if (!is_gimple_call (stmt))
+return false;
+
+ fndecl = gimple_call_fndecl (stmt);
+ if (fndecl && DECL_BU
On Thu, Jul 21, 2016 at 11:04:48AM +, Bernd Edlinger wrote:
> bool
> +gimple_alloca_call_p (const gimple *stmt)
> +{
> + tree fndecl;
> +
> + if (!is_gimple_call (stmt))
> +return false;
> +
> + fndecl = gimple_call_fndecl (stmt);
> + if (fndecl && DECL_BUILT_IN_CLASS (fndecl) == BUILT
On 07/21/16 09:09, Richard Biener wrote:
> On Wed, 20 Jul 2016, Bernd Edlinger wrote:
>
>> On 07/20/16 20:08, Richard Biener wrote:
>>> On July 20, 2016 6:54:48 PM GMT+02:00, Bernd Edlinger
>>> wrote:
But I think that alloca just should not be recognized by name any
more.
>>>
>>> I
On Wed, 20 Jul 2016, Bernd Edlinger wrote:
> On 07/20/16 20:08, Richard Biener wrote:
> > On July 20, 2016 6:54:48 PM GMT+02:00, Bernd Edlinger
> > wrote:
> >>
> >> But I think that alloca just should not be recognized by name any
> >> more.
> >
> > It was introduced to mark calls that should no
> On 07/20/16 20:08, Richard Biener wrote:
> > On July 20, 2016 6:54:48 PM GMT+02:00, Bernd Edlinger
> > wrote:
> >>
> >> Yes. That is another interesting observation. I think, originally this
> >> flag was introduced by Jan Hubicka, and should mean, "it may be alloca
> >> or a weak alias to all
On 07/21/16 00:19, Bernd Edlinger wrote:
> On 07/21/16 00:00, Jakub Jelinek wrote:
>> On Wed, Jul 20, 2016 at 09:50:03PM +, Bernd Edlinger wrote:
>>> But the built-in alloca is still recognized because the builtin
>>> does have ECF_MAY_BE_ALLOCA and ECF_MALLOC.
>>
>> But __builtin_alloca_with
On 07/21/16 00:00, Jakub Jelinek wrote:
> On Wed, Jul 20, 2016 at 09:50:03PM +, Bernd Edlinger wrote:
>> But the built-in alloca is still recognized because the builtin
>> does have ECF_MAY_BE_ALLOCA and ECF_MALLOC.
>
> But __builtin_alloca_with_align likely doesn't have ECF_MALLOC set (even
>
On Wed, Jul 20, 2016 at 09:50:03PM +, Bernd Edlinger wrote:
> But the built-in alloca is still recognized because the builtin
> does have ECF_MAY_BE_ALLOCA and ECF_MALLOC.
But __builtin_alloca_with_align likely doesn't have ECF_MALLOC set (even
when it should).
Jakub
On 07/20/16 20:08, Richard Biener wrote:
> On July 20, 2016 6:54:48 PM GMT+02:00, Bernd Edlinger
> wrote:
>>
>> But I think that alloca just should not be recognized by name any
>> more.
>
> It was introduced to mark calls that should not be duplicated by inlining or
> unrolling to avoid increas
> Very few targets continue to use SJLJ eh (perhaps just cygwin/mingw).
> *But* I think the Ada front-end explicitly uses SJLJ EH, so if you want
> to get some smoke testing, the Ada testsuite is probably the place to go.
Right, the Ada front-end uses an EH scheme directly based on __builtin_setjm
On 07/20/16 21:00, Jeff Law wrote:
> On 07/20/2016 10:30 AM, Bernd Edlinger wrote:
>> On 07/20/16 18:15, Jeff Law wrote:
>>> On 07/20/2016 05:53 AM, Richard Biener wrote:
> Is it OK after boot-strap and regression-testing?
I think the __builtin_setjmp change is wrong - __builtin_setjm
On 07/20/2016 10:30 AM, Bernd Edlinger wrote:
On 07/20/16 18:15, Jeff Law wrote:
On 07/20/2016 05:53 AM, Richard Biener wrote:
Is it OK after boot-strap and regression-testing?
I think the __builtin_setjmp change is wrong - __builtin_setjmp is
_not_ 'setjmp' it is part of the GCC internal mac
On 07/20/2016 10:54 AM, Bernd Edlinger wrote:
Yes. That is another interesting observation. I think, originally this
flag was introduced by Jan Hubicka, and should mean, "it may be alloca
or a weak alias to alloca or maybe even something different".
But some of the later optimizations use it i
On 07/20/2016 12:30 PM, Bernd Edlinger wrote:
On 07/20/16 20:08, Richard Biener wrote:
On July 20, 2016 6:54:48 PM GMT+02:00, Bernd Edlinger
wrote:
Yes. That is another interesting observation. I think, originally this
flag was introduced by Jan Hubicka, and should mean, "it may be alloca
o
On 07/20/16 20:08, Richard Biener wrote:
> On July 20, 2016 6:54:48 PM GMT+02:00, Bernd Edlinger
> wrote:
>>
>> Yes. That is another interesting observation. I think, originally this
>> flag was introduced by Jan Hubicka, and should mean, "it may be alloca
>> or a weak alias to alloca or maybe e
On July 20, 2016 6:54:48 PM GMT+02:00, Bernd Edlinger
wrote:
>On 07/20/16 18:20, Jeff Law wrote:
>> On 07/20/2016 09:41 AM, Bernd Edlinger wrote:
>>> On 07/20/16 12:44, Richard Biener wrote:
On Tue, 19 Jul 2016, Bernd Edlinger wrote:
> Hi!
>
> As discussed at
>https://gcc.gn
On 07/20/16 18:20, Jeff Law wrote:
> On 07/20/2016 09:41 AM, Bernd Edlinger wrote:
>> On 07/20/16 12:44, Richard Biener wrote:
>>> On Tue, 19 Jul 2016, Bernd Edlinger wrote:
>>>
Hi!
As discussed at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71876,
we have a _very_ old hack in
On 07/20/16 18:15, Jeff Law wrote:
> On 07/20/2016 05:53 AM, Richard Biener wrote:
>>> Is it OK after boot-strap and regression-testing?
>>
>> I think the __builtin_setjmp change is wrong - __builtin_setjmp is
>> _not_ 'setjmp' it is part of the GCC internal machinery (using setjmp
>> and longjmp i
On 07/20/2016 05:53 AM, Richard Biener wrote:
Is it OK after boot-strap and regression-testing?
I think the __builtin_setjmp change is wrong - __builtin_setjmp is
_not_ 'setjmp' it is part of the GCC internal machinery (using setjmp
and longjmp in the end) for SJLJ exception handing.
Am I corr
On 07/20/16 13:53, Richard Biener wrote:
> On Wed, 20 Jul 2016, Bernd Edlinger wrote:
>
>> On 07/20/16 12:46, Richard Biener wrote:
>>> On Wed, 20 Jul 2016, Richard Biener wrote:
>>>
On Tue, 19 Jul 2016, Bernd Edlinger wrote:
> Hi!
>
> As discussed at https://gcc.gnu.org/bugzi
On Wed, 20 Jul 2016, Bernd Edlinger wrote:
> On 07/20/16 12:46, Richard Biener wrote:
> > On Wed, 20 Jul 2016, Richard Biener wrote:
> >
> >> On Tue, 19 Jul 2016, Bernd Edlinger wrote:
> >>
> >>> Hi!
> >>>
> >>> As discussed at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71876,
> >>> we have a _v
On 07/20/16 12:46, Richard Biener wrote:
> On Wed, 20 Jul 2016, Richard Biener wrote:
>
>> On Tue, 19 Jul 2016, Bernd Edlinger wrote:
>>
>>> Hi!
>>>
>>> As discussed at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71876,
>>> we have a _very_ old hack in gcc, that recognizes certain functions by
>>>
On 07/19/16 19:30, Bernd Edlinger wrote:
> On 07/19/16 18:37, Jakub Jelinek wrote:
>> On Tue, Jul 19, 2016 at 04:20:55PM +, Bernd Edlinger wrote:
>>> As discussed at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71876,
>>> we have a _very_ old hack in gcc, that recognizes certain functions by
>>
On 07/19/16 18:37, Jakub Jelinek wrote:
> On Tue, Jul 19, 2016 at 04:20:55PM +, Bernd Edlinger wrote:
>> As discussed at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71876,
>> we have a _very_ old hack in gcc, that recognizes certain functions by
>> name, and inserts in some cases unsafe attrib
On Tue, Jul 19, 2016 at 04:20:55PM +, Bernd Edlinger wrote:
> As discussed at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71876,
> we have a _very_ old hack in gcc, that recognizes certain functions by
> name, and inserts in some cases unsafe attributes, that don't work for
> a freestanding en
Hi!
As discussed at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71876,
we have a _very_ old hack in gcc, that recognizes certain functions by
name, and inserts in some cases unsafe attributes, that don't work for
a freestanding environment.
It is unsafe to return ECF_MAY_BE_ALLOCA, ECF_LEAF and
46 matches
Mail list logo
