From: "Martin Liška" <mliska@suse.cz>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] rs6000: Fix restored rs6000_long_double_type_size.
Date: Thu, 5 Aug 2021 18:49:21 +0200 [thread overview]
Message-ID: <71e22e72-890f-8a3e-7ab7-0699663006d5@suse.cz> (raw)
In-Reply-To: <20210805153948.GP1583@gate.crashing.org>
On 8/5/21 5:39 PM, Segher Boessenkool wrote:
> On Thu, Aug 05, 2021 at 02:05:24PM +0200, Martin Liška wrote:
>> On 7/23/21 7:57 PM, Segher Boessenkool wrote:
>>> Hi!
>>>
>>> On Fri, Jul 23, 2021 at 07:47:54AM +0200, Martin Liška wrote:
>>>> On 7/12/21 7:20 PM, Segher Boessenkool wrote:
>>>>>>>> +static __attribute__ ((optimize ("-fno-stack-protector"))) __typeof
>>>>>>>> (f) *
>>>>>>>
>>>>>>> -fno-stack-protector is default.
>>>>>>
>>>>>> Yes, but one needs an optimize attribute in order to trigger
>>>>>> cl_target_option_save/restore
>>>>>> mechanism.
>>>>>
>>>>> So it behaves differently if you select the default than if you do not
>>>>> select anything? That is wrong, no?
>>>>
>>>> Sorry, I don't get your example, please explain it.
>>>
>>> If -mbork is the default, the coompiler whould behave the same if you
>>> invoke it with -mbork as when you do not. And the optimize attribute
>>> should work exactly the same as command line options.
>>
>> Ah, got your point. All right, let's use then 'optimize(1)'.
>>
>> Is it fine with the adjustment?
>
> You are saying the compiler's behaviour is broken, but are changing the
> testcase to avoid exhibiting that behaviour?
No, both selections of the 'optimize' attribute trigger the ICE. The reason
is that any optimize attribute triggers eventually cl_target_option_save/restore
mechanism which is what the patch addresses.
> No, this is not fine.
>
> If a flag is the default the compiler should do the same thing with and
> without any attribute setting that flag, directly or indirectly.
Yes, but should not crash. And that's what is my patch dealing with.
Cheers,
Martin
>
>
> Segher
>
next prev parent reply other threads:[~2021-08-05 16:49 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-23 13:22 Martin Liška
2021-06-23 22:46 ` Segher Boessenkool
2021-06-28 12:19 ` Martin Liška
2021-07-12 4:19 ` Martin Liška
2021-07-12 17:00 ` Segher Boessenkool
2021-07-12 17:20 ` Segher Boessenkool
2021-07-23 5:45 ` Martin Liska
2021-07-23 5:45 ` Martin Liska
2021-07-23 5:45 ` Martin Liska
2021-07-23 5:47 ` Martin Liška
2021-07-23 17:57 ` Segher Boessenkool
2021-08-05 12:05 ` Martin Liška
2021-08-05 15:39 ` Segher Boessenkool
2021-08-05 16:49 ` Martin Liška [this message]
2021-08-05 20:06 ` Segher Boessenkool
[not found] ` <202107230545.16N5jkeY006982@gate.crashing.org>
2021-07-23 18:00 ` Segher Boessenkool
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=71e22e72-890f-8a3e-7ab7-0699663006d5@suse.cz \
--to=mliska@suse.cz \
--cc=gcc-patches@gcc.gnu.org \
--cc=segher@kernel.crashing.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).