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 template parameters, eg.:
>
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
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
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 introduce a new operand modifier, eg. '-', which
would
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 signify that the output *must* be considered clobbered
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 signify that the output *must* be considered clobbered
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 '+'
> can be extended
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
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
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, wh
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"
ion 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, 18
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 regarded as dea
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
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
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 ()
>>> {
>>>int i = 2;
>>>try
>>> {
>>>asm
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 from my message above, but: I was mostly
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&)
>
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
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
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.
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
22 matches
Mail list logo
