[PATCH] generate EH info for volatile asm statements (PR inline-asm/93981)

2020-03-05 Thread J.W. Jagersma
The following patch extends the generation of exception handling information to cover volatile asms too. This was already mostly implemented, and only very minor changes are required in order to make it work. The change in rewrite_stmt is necessary because it inserts debug statements after the as

Re: [PATCH] generate EH info for volatile asm statements (PR inline-asm/93981)

2020-03-06 Thread J.W. Jagersma
On 2020-03-06 09:55, Richard Biener wrote: On Thu, Mar 5, 2020 at 5:49 PM J.W. Jagersma wrote: diff --git a/gcc/tree-eh.c b/gcc/tree-eh.c index 2a409dcaffe..8314db00922 100644 --- a/gcc/tree-eh.c +++ b/gcc/tree-eh.c @@ -2077,6 +2077,9 @@ lower_eh_constructs_2 (struct leh_state *state

[PATCH v2] generate EH info for volatile asm statements (PR93981)

2020-03-07 Thread J.W. Jagersma
The following patch extends the generation of exception handling information to cover volatile asms too. This was already mostly implemented, and only minor changes are required in order to make it work. The new test case works for me on x86_64-linux-gnu, but will likely fail on most other platfo

Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)

2020-03-07 Thread J.W. Jagersma
On 2020-03-07 20:20, Segher Boessenkool wrote: Hi! On Sat, Mar 07, 2020 at 06:12:45PM +0100, J.W. Jagersma wrote: The following patch extends the generation of exception handling information to cover volatile asms too. This was already mostly implemented, and only minor changes are required

Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)

2020-03-07 Thread J.W. Jagersma
On 2020-03-07 21:48, Marek Polacek wrote: On Sat, Mar 07, 2020 at 09:43:59PM +0100, J.W. Jagersma wrote: What does stage 1 refer to? I'm sorry, this is my first gcc patch and I'm still learning how this all works. No worries, you'll get there. You can read more about t

Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)

2020-03-08 Thread J.W. Jagersma
On 2020-03-08 00:03, Segher Boessenkool wrote: > On Sat, Mar 07, 2020 at 10:06:46PM +0100, J.W. Jagersma wrote: >> Thanks Marek and Gerald, I hadn't read that page yet. So do I resubmit >> the final patch during stage 1, or will it end up in a queue to be >> included w

Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)

2020-03-09 Thread J.W. Jagersma
On 2020-03-09 13:13, Richard Sandiford wrote: > Thanks for doing this. Hi Richard, thanks for your response. > "J.W. Jagersma" writes: >> On 2020-03-07 20:20, Segher Boessenkool wrote: >>> Some comments: >>> >>>> +When non-call except

Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)

2020-03-09 Thread J.W. Jagersma
On 2020-03-09 19:01, Segher Boessenkool wrote: > Hi! > > On Mon, Mar 09, 2020 at 01:54:53PM +0100, Richard Biener wrote: >> I think memory operands are fine - my original concern was about >> register outputs and SSA form that should reflect the correct def >> on the EH vs non-EH edge. From a "mi

Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)

2020-03-09 Thread J.W. Jagersma
On 2020-03-09 23:10, Segher Boessenkool wrote: > Hi! > > On Sun, Mar 08, 2020 at 05:18:21PM +0100, J.W. Jagersma wrote: >> There is also still the question of whether non-volatile asms should be >> allowed to throw or not. I don't know if that should be discussed he

Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)

2020-03-09 Thread J.W. Jagersma
On 2020-03-10 01:25, Segher Boessenkool wrote: > On Mon, Mar 09, 2020 at 07:42:20PM +0100, J.W. Jagersma wrote: >> On 2020-03-09 19:01, Segher Boessenkool wrote: >>> On Mon, Mar 09, 2020 at 01:54:53PM +0100, Richard Biener wrote: >>>>

[PING][PATCH] i386: Allow setting target attribute from conditional expression

2022-11-08 Thread J.W. Jagersma via Gcc-patches
I realize this is a feature with a somewhat niche use-case, but I'd really like to have it in gcc 13, if possible. Any feedback is appreciated. On 2022-10-17 16:44, J.W. Jagersma wrote: > Recently I tried to set a function's target attribute conditionally > based on templat

[PATCH] i386: Allow setting target attribute from conditional expression

2022-10-17 Thread J.W. Jagersma via Gcc-patches
Recently I tried to set a function's target attribute conditionally based on template parameters, eg.: template [[gnu::target (enable_sse ? "sse" : "")]] void func () { /* ... */ } I then discovered that this is currently not possible. This small patch resolves that. A possible alte

[PATCH v3 0/2] generate EH info for asm statements (PR93981)

2020-03-11 Thread J.W. Jagersma via Gcc-patches
As there were no more comments in the previous thread, I am submitting a new revision of this patch. The patch is split up in two parts now. The first covers only volatile asms and is mostly identical to the last revision. There are no code changes, only the test cases and documentation are expa

[PATCH v3 1/2] generate EH info for volatile asm statements (PR93981)

2020-03-11 Thread J.W. Jagersma via Gcc-patches
The following patch extends the generation of exception handling information, so that it is possible to catch exceptions thrown from volatile asm statements, when -fnon-call-exceptions is enabled. Parts of the gcc code already suggested this should be possible, but it was never fully implemented.

[PATCH v3 2/2] generate EH info for all asm statements (PR93981)

2020-03-11 Thread J.W. Jagersma via Gcc-patches
This patch extends the generation of exception handling information to cover all asm statements, when -fnon-call-exceptions is given. The previous patch only enabled this for volatile asms. The previously added test cases are adjusted to cover this change. gcc/ 2020-03-11 Jan W. Jagersma

Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)

2020-03-12 Thread J.W. Jagersma via Gcc-patches
On 2020-03-12 16:32, Segher Boessenkool wrote: > On Thu, Mar 12, 2020 at 02:08:18PM +0100, Richard Biener wrote: >>> It wasn't clear from my message above, but: I was mostly worried about >>> requiring the asm to treat memory operands in a certain way when the >>> exception is thrown. IMO it would

Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)

2020-03-12 Thread J.W. Jagersma via Gcc-patches
On 2020-03-12 10:59, Richard Sandiford wrote: > The other case I mentioned was equivalent to: > > int > test_mem2 () > { >int i = 2; >try > { >asm volatile ("ud2; mov%z0 $1, %0" : "=m" (i)); > } >catch (const illegal_opcode&) >

Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)

2020-03-12 Thread J.W. Jagersma via Gcc-patches
On 2020-03-12 20:26, Segher Boessenkool wrote: > On Thu, Mar 12, 2020 at 07:42:30PM +0100, J.W. Jagersma wrote: >> On 2020-03-12 16:32, Segher Boessenkool wrote: >>> On Thu, Mar 12, 2020 at 02:08:18PM +0100, Richard Biener wrote: >>>>> It wasn't clear fr

Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)

2020-03-13 Thread J.W. Jagersma via Gcc-patches
On 2020-03-13 14:31, Richard Sandiford wrote: > "J.W. Jagersma" writes: >> On 2020-03-12 10:59, Richard Sandiford wrote: >>> The other case I mentioned was equivalent to: >>> >>> int >>> test_mem2 () >>> { >&g

Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)

2020-03-18 Thread J.W. Jagersma via Gcc-patches
Hi Michael, thanks for your response. On 2020-03-17 16:32, Michael Matz wrote: > Hello, > > On Mon, 16 Mar 2020, Richard Sandiford wrote: > >> Segher Boessenkool writes: >>> On Mon, Mar 16, 2020 at 05:47:03PM +, Richard Sandiford wrote: Segher Boessenkool writes: >> we do delete "

Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)

2020-03-19 Thread J.W. Jagersma via Gcc-patches
On 2020-03-19 00:56, Segher Boessenkool wrote: > On Tue, Mar 17, 2020 at 03:32:34PM +, Michael Matz wrote: >> On Mon, 16 Mar 2020, Richard Sandiford wrote: >>> Similarly for non-call exceptions on other statements. It sounds like >>> what you're describing requires the corresponding definitio

Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)

2020-03-20 Thread J.W. Jagersma via Gcc-patches
On 2020-03-19 18:06, Michael Matz wrote: > Hello, > > On Wed, 18 Mar 2020, J.W. Jagersma via Gcc-patches wrote: > >>> Well, it's both: on the exception path the compiler has to assume that the >>> the value wasn't changed (so that former defines are regar

Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)

2020-03-24 Thread J.W. Jagersma via Gcc-patches
fication which alternative will eventually be chosen. The second problem is that it sets off -Wuninitialized warnings everywhere. Is there some way to determine in gimplify_asm_expr which outputs have already been assigned to? On 2020-03-19 18:06, Michael Matz wrote: > Hello, > > On Wed

[PATCH] djgpp: emit "b" flag for named bss sections

2020-03-25 Thread J.W. Jagersma via Gcc-patches
Unlike ELF, named sections such as .bss.* and .gnu.linkonce.b.* have no special meaning in COFF, therefore they will have the CONTENTS and LOAD attributes set. The result is that these sections take up space in object files and executables. These attributes can be cleared by emitting the "b" flag

Re: [PATCH v3 1/2] generate EH info for volatile asm statements (PR93981)

2020-11-15 Thread J.W. Jagersma via Gcc-patches
On 2020-11-12 16:51, Jeff Law wrote: > > On 3/11/20 6:38 PM, J.W. Jagersma via Gcc-patches wrote: >> The following patch extends the generation of exception handling >> information, so that it is possible to catch exceptions thrown from >> volatile asm statements, when

Re: [PATCH v3 1/2] generate EH info for volatile asm statements (PR93981)

2020-11-15 Thread J.W. Jagersma via Gcc-patches
On 2020-11-13 09:41, Richard Biener wrote: > On Thu, Mar 12, 2020 at 1:41 AM J.W. Jagersma via Gcc-patches > wrote: >> diff --git a/gcc/tree-eh.c b/gcc/tree-eh.c >> index 2a409dcaffe..58b16aa763a 100644 >> --- a/gcc/tree-eh.c >> +++ b/gcc/tree-eh.c >> @@ -207

Re: [PATCH v3 1/2] generate EH info for volatile asm statements (PR93981)

2020-11-21 Thread J.W. Jagersma via Gcc-patches
On 2020-11-19 06:55, Jeff Law wrote: > > > On 11/15/20 6:04 AM, J.W. Jagersma via Gcc-patches wrote: >> On 2020-11-13 09:41, Richard Biener wrote: >>> On Thu, Mar 12, 2020 at 1:41 AM J.W. Jagersma via Gcc-patches >>> wrote: >>>> diff --git a/gcc/tre

Re: [PATCH v3 1/2] generate EH info for volatile asm statements (PR93981)

2020-11-22 Thread J.W. Jagersma via Gcc-patches
On 2020-11-21 12:27, J.W. Jagersma wrote: > ... > Another idea I had is to introduce a new operand modifier, eg. '-', which > would signify that the output *must* be considered clobbered on exception, > and it would be an error if a copy is not possible. Then the meaning of

Re: [PATCH v3 1/2] generate EH info for volatile asm statements (PR93981)

2020-11-23 Thread J.W. Jagersma via Gcc-patches
On 2020-11-23 09:20, Richard Biener wrote: > On Sun, Nov 22, 2020 at 5:38 PM J.W. Jagersma wrote: >> >> On 2020-11-21 12:27, J.W. Jagersma wrote: >>> ... >>> Another idea I had is to introduce a new operand modifier, eg. '-', which >>> would si

Re: [PATCH v3 1/2] generate EH info for volatile asm statements (PR93981)

2020-11-30 Thread J.W. Jagersma via Gcc-patches
On 2020-11-23 09:20, Richard Biener wrote: > On Sun, Nov 22, 2020 at 5:38 PM J.W. Jagersma wrote: >> >> On 2020-11-21 12:27, J.W. Jagersma wrote: >>> ... >>> Another idea I had is to introduce a new operand modifier, eg. '-', which >>> would si

Re: [PATCH v3 1/2] generate EH info for volatile asm statements (PR93981)

2020-12-01 Thread J.W. Jagersma via Gcc-patches
On 2020-11-30 17:47, J.W. Jagersma wrote: > On 2020-11-23 09:20, Richard Biener wrote: >> On Sun, Nov 22, 2020 at 5:38 PM J.W. Jagersma wrote: >>> >>> On 2020-11-21 12:27, J.W. Jagersma wrote: >>>> ... >>>> Another idea I had is to introduc

[PATCH v4] generate EH info for asm statements (PR93981)

2020-12-01 Thread J.W. Jagersma via Gcc-patches
The following patch extends the generation of exception handling information, so that it is possible to catch exceptions thrown from asm statements, when -fnon-call-exceptions is enabled. Parts of the gcc code already suggested this should be possible, but it was never fully implemented. Both vol