The reason would be to show that they continue to not ICE as they used to.
No go paths are just as useful as go paths.
On Sat, Mar 11, 2023, 10:57 Jeff Law wrote:
>
>
> On 2/16/23 01:16, Eric Botcazou via Gcc-patches wrote:
> >> This fixes dg.exp/stack-check-2.c, -7, 8, and -16.c, which is
On 2/16/23 01:16, Eric Botcazou via Gcc-patches wrote:
This fixes dg.exp/stack-check-2.c, -7, 8, and -16.c, which is great!
Try the attached patch.
I'd suggest going ahead and applying the fix to
check_effective_target_supports_stack_clash_protection.
There's really not a strong reason
On 2/17/23 01:56, NightStrike via Gcc-patches wrote:
On Thu, Feb 16, 2023 at 3:16 AM Eric Botcazou wrote:
This fixes dg.exp/stack-check-2.c, -7, 8, and -16.c, which is great!
Try the attached patch.
Well... that patch just marks all of the tests as unsupported. But
for example, the
> Is there a way to say that the test results should be inverted on a
> particular platform (instead of purely unsupported)?
Yes, you can do pretty much what you want with the testsuite harness.
--
Eric Botcazou
On Thu, Feb 16, 2023 at 3:16 AM Eric Botcazou wrote:
>
> > This fixes dg.exp/stack-check-2.c, -7, 8, and -16.c, which is great!
>
> Try the attached patch.
Well... that patch just marks all of the tests as unsupported. But
for example, the ones quoted above run, work, and pass. And when they
> This fixes dg.exp/stack-check-2.c, -7, 8, and -16.c, which is great!
Try the attached patch.
--
Eric Botcazoudiff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 227e3004077..d4f036a3f1e 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++
On Wed, Feb 15, 2023 at 10:24 AM Eric Botcazou via Gcc-patches
wrote:
>
> Hi,
>
> this is the incompatibility of -fstack-clash-protection with Windows SEH. Now
> the Windows ports always enable TARGET_STACK_PROBE, which means that the stack
> is always probed (out of line) so
On 2/15/23 08:24, Eric Botcazou via Gcc-patches wrote:
Hi,
this is the incompatibility of -fstack-clash-protection with Windows SEH. Now
the Windows ports always enable TARGET_STACK_PROBE, which means that the stack
is always probed (out of line) so -fstack-clash-protection does nothing
Hi,
this is the incompatibility of -fstack-clash-protection with Windows SEH. Now
the Windows ports always enable TARGET_STACK_PROBE, which means that the stack
is always probed (out of line) so -fstack-clash-protection does nothing more.
Tested on x86-64/Windows and Linux, OK for all active
