public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug sanitizer/115172] New: Invalid -fsanitize=bool sanitization of variable from named address space
@ 2024-05-21 9:33 ubizjak at gmail dot com
2024-05-21 10:05 ` [Bug sanitizer/115172] " jakub at gcc dot gnu.org
` (13 more replies)
0 siblings, 14 replies; 15+ messages in thread
From: ubizjak at gmail dot com @ 2024-05-21 9:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115172
Bug ID: 115172
Summary: Invalid -fsanitize=bool sanitization of variable from
named address space
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone: ---
Created attachment 58260
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58260&action=edit
Preprocessed file
Originally reported in PR 111736, comment 42.
Compiling the attached preprocessed file with:
gcc -O2 -fsanitize=kernel-address -fasan-shadow-offset=0xdffffc0000000000
--param asan-instrumentation-with-call-threshold=10000 -fsanitize=bool -S
alternative.i
results in:
movabsq $-2305847407260205056, %rdx
movl $cpu_tlbstate_shared, %eax
shrq $3, %rax
movzbl (%rax,%rdx), %eax
testb %al, %al
je .L399
jle .L473
.L399:
movzbl %gs:cpu_tlbstate_shared(%rip), %r14d
cmpb $1, %r14b
which is wrong. %gs: prefixed addresses should not be sanitized.
Omitting -fsanitize=bool from the above compiles the preprocessed file to:
movzbl %gs:cpu_tlbstate_shared(%rip), %eax
testb %al, %al
where no sanitization is present with the above variable.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug sanitizer/115172] Invalid -fsanitize=bool sanitization of variable from named address space
2024-05-21 9:33 [Bug sanitizer/115172] New: Invalid -fsanitize=bool sanitization of variable from named address space ubizjak at gmail dot com
@ 2024-05-21 10:05 ` jakub at gcc dot gnu.org
2024-05-21 10:16 ` jakub at gcc dot gnu.org
` (12 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-05-21 10:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115172
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed| |2024-05-21
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Reduced testcase for -O2 -fsanitize=address,bool --param
asan-instrumentation-with-call-threshold=100:
extern struct S { _Bool b; } s;
void bar (void);
void
foo (void)
{
if (*(volatile _Bool __seg_gs *) (__UINTPTR_TYPE__) &s.b)
bar ();
}
What the kernel does is terrible, why they just don't declare the extern with
__seg_gs attribute?
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug sanitizer/115172] Invalid -fsanitize=bool sanitization of variable from named address space
2024-05-21 9:33 [Bug sanitizer/115172] New: Invalid -fsanitize=bool sanitization of variable from named address space ubizjak at gmail dot com
2024-05-21 10:05 ` [Bug sanitizer/115172] " jakub at gcc dot gnu.org
@ 2024-05-21 10:16 ` jakub at gcc dot gnu.org
2024-05-21 10:20 ` ubizjak at gmail dot com
` (11 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-05-21 10:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115172
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That said,
--- gcc/ubsan.cc.jj 2024-03-22 09:23:37.695296775 +0100
+++ gcc/ubsan.cc 2024-05-21 12:10:24.261454107 +0200
@@ -1776,13 +1776,17 @@ instrument_bool_enum_load (gimple_stmt_i
|| TREE_CODE (gimple_assign_lhs (stmt)) != SSA_NAME)
return;
+ addr_space_t as = TYPE_ADDR_SPACE (TREE_TYPE (rhs));
+ if (as != TYPE_ADDR_SPACE (utype))
+ utype = build_qualified_type (utype, TYPE_QUALS (utype)
+ | ENCODE_QUAL_ADDR_SPACE (as));
bool ends_bb = stmt_ends_bb_p (stmt);
location_t loc = gimple_location (stmt);
tree lhs = gimple_assign_lhs (stmt);
tree ptype = build_pointer_type (TREE_TYPE (rhs));
tree atype = reference_alias_ptr_type (rhs);
gimple *g = gimple_build_assign (make_ssa_name (ptype),
- build_fold_addr_expr (rhs));
+ build_fold_addr_expr (rhs));
gimple_set_location (g, loc);
gsi_insert_before (gsi, g, GSI_SAME_STMT);
tree mem = build2 (MEM_REF, utype, gimple_assign_lhs (g),
seems to fix that. But wonder how many of the other ~180 spots that create
MEM_REFs don't need similar fixes.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug sanitizer/115172] Invalid -fsanitize=bool sanitization of variable from named address space
2024-05-21 9:33 [Bug sanitizer/115172] New: Invalid -fsanitize=bool sanitization of variable from named address space ubizjak at gmail dot com
2024-05-21 10:05 ` [Bug sanitizer/115172] " jakub at gcc dot gnu.org
2024-05-21 10:16 ` jakub at gcc dot gnu.org
@ 2024-05-21 10:20 ` ubizjak at gmail dot com
2024-05-21 10:35 ` jakub at gcc dot gnu.org
` (10 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: ubizjak at gmail dot com @ 2024-05-21 10:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115172
--- Comment #3 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Jakub Jelinek from comment #1)
> What the kernel does is terrible, why they just don't declare the extern
> with __seg_gs attribute?
This is how kernel currently handles percpu variables. They are redefined to a
named address space just before use, because the percpu infrastructure can't
handle AS qualified variables, mainly due to the extensive use of __typeof__,
please see [1].
The solution is to use __typeof_unqual__ with gcc-14. The prototype patch at
[2] declares percpu variables as __seg_gs during decl time, as you proposed
above.
[1] https://lore.kernel.org/lkml/87bk7ux4e9.ffs@tglx/
[2]
https://lore.kernel.org/lkml/CAFULd4Z-stHtu2UWv02S+Nbx51QqytGUO8ZeW50Fc_PbsfF8BA@mail.gmail.com/
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug sanitizer/115172] Invalid -fsanitize=bool sanitization of variable from named address space
2024-05-21 9:33 [Bug sanitizer/115172] New: Invalid -fsanitize=bool sanitization of variable from named address space ubizjak at gmail dot com
` (2 preceding siblings ...)
2024-05-21 10:20 ` ubizjak at gmail dot com
@ 2024-05-21 10:35 ` jakub at gcc dot gnu.org
2024-05-21 14:21 ` ubizjak at gmail dot com
` (9 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-05-21 10:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115172
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 58261
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58261&action=edit
gcc15-pr115172.patch
Full untested patch.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug sanitizer/115172] Invalid -fsanitize=bool sanitization of variable from named address space
2024-05-21 9:33 [Bug sanitizer/115172] New: Invalid -fsanitize=bool sanitization of variable from named address space ubizjak at gmail dot com
` (3 preceding siblings ...)
2024-05-21 10:35 ` jakub at gcc dot gnu.org
@ 2024-05-21 14:21 ` ubizjak at gmail dot com
2024-05-21 17:19 ` pchelkin at ispras dot ru
` (8 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: ubizjak at gmail dot com @ 2024-05-21 14:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115172
--- Comment #5 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Jakub Jelinek from comment #4)
> Created attachment 58261 [details]
> gcc15-pr115172.patch
>
> Full untested patch.
I can confirm that this patch fixes boot for the kernel config from
PR115172#43.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug sanitizer/115172] Invalid -fsanitize=bool sanitization of variable from named address space
2024-05-21 9:33 [Bug sanitizer/115172] New: Invalid -fsanitize=bool sanitization of variable from named address space ubizjak at gmail dot com
` (4 preceding siblings ...)
2024-05-21 14:21 ` ubizjak at gmail dot com
@ 2024-05-21 17:19 ` pchelkin at ispras dot ru
2024-05-21 21:08 ` jakub at gcc dot gnu.org
` (7 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: pchelkin at ispras dot ru @ 2024-05-21 17:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115172
--- Comment #6 from Fedor Pchelkin <pchelkin at ispras dot ru> ---
(In reply to Uroš Bizjak from comment #5)
> (In reply to Jakub Jelinek from comment #4)
> > Created attachment 58261 [details]
> > gcc15-pr115172.patch
> >
> > Full untested patch.
>
> I can confirm that this patch fixes boot for the kernel config from
> PR115172#43.
Yep. I may confirm, too. Thanks for the prompt fix!
If all goes well, is it expected to land in 14.2 and 13.4?
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug sanitizer/115172] Invalid -fsanitize=bool sanitization of variable from named address space
2024-05-21 9:33 [Bug sanitizer/115172] New: Invalid -fsanitize=bool sanitization of variable from named address space ubizjak at gmail dot com
` (5 preceding siblings ...)
2024-05-21 17:19 ` pchelkin at ispras dot ru
@ 2024-05-21 21:08 ` jakub at gcc dot gnu.org
2024-05-22 7:13 ` cvs-commit at gcc dot gnu.org
` (6 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-05-21 21:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115172
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Fedor Pchelkin from comment #6)
> (In reply to Uroš Bizjak from comment #5)
> > (In reply to Jakub Jelinek from comment #4)
> > > Created attachment 58261 [details]
> > > gcc15-pr115172.patch
> > >
> > > Full untested patch.
> >
> > I can confirm that this patch fixes boot for the kernel config from
> > PR115172#43.
>
> Yep. I may confirm, too. Thanks for the prompt fix!
>
> If all goes well, is it expected to land in 14.2 and 13.4?
If it is approved yes. 14.2 is expected likely in July this year, but 13.4
roughly in a year from now, as it just missed 13.3 (released today).
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug sanitizer/115172] Invalid -fsanitize=bool sanitization of variable from named address space
2024-05-21 9:33 [Bug sanitizer/115172] New: Invalid -fsanitize=bool sanitization of variable from named address space ubizjak at gmail dot com
` (6 preceding siblings ...)
2024-05-21 21:08 ` jakub at gcc dot gnu.org
@ 2024-05-22 7:13 ` cvs-commit at gcc dot gnu.org
2024-05-22 7:19 ` cvs-commit at gcc dot gnu.org
` (5 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-05-22 7:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115172
--- Comment #8 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:d3c506eff54fcbac389a529c2e98da108a410b7f
commit r15-765-gd3c506eff54fcbac389a529c2e98da108a410b7f
Author: Jakub Jelinek <jakub@redhat.com>
Date: Wed May 22 09:12:28 2024 +0200
ubsan: Use right address space for MEM_REF created for bool/enum
sanitization [PR115172]
The following testcase is miscompiled, because -fsanitize=bool,enum
creates a MEM_REF without propagating there address space qualifiers,
so what should be normally loaded using say %gs:/%fs: segment prefix
isn't. Together with asan it then causes that load to be sanitized.
2024-05-22 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/115172
* ubsan.cc (instrument_bool_enum_load): If rhs is not in generic
address space, use qualified version of utype with the right
address space. Formatting fix.
* gcc.dg/asan/pr115172.c: New test.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug sanitizer/115172] Invalid -fsanitize=bool sanitization of variable from named address space
2024-05-21 9:33 [Bug sanitizer/115172] New: Invalid -fsanitize=bool sanitization of variable from named address space ubizjak at gmail dot com
` (7 preceding siblings ...)
2024-05-22 7:13 ` cvs-commit at gcc dot gnu.org
@ 2024-05-22 7:19 ` cvs-commit at gcc dot gnu.org
2024-05-22 7:35 ` cvs-commit at gcc dot gnu.org
` (4 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-05-22 7:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115172
--- Comment #9 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:d224c7d8d8b49daab54a977a4f2217423d3d12a0
commit r14-10230-gd224c7d8d8b49daab54a977a4f2217423d3d12a0
Author: Jakub Jelinek <jakub@redhat.com>
Date: Wed May 22 09:12:28 2024 +0200
ubsan: Use right address space for MEM_REF created for bool/enum
sanitization [PR115172]
The following testcase is miscompiled, because -fsanitize=bool,enum
creates a MEM_REF without propagating there address space qualifiers,
so what should be normally loaded using say %gs:/%fs: segment prefix
isn't. Together with asan it then causes that load to be sanitized.
2024-05-22 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/115172
* ubsan.cc (instrument_bool_enum_load): If rhs is not in generic
address space, use qualified version of utype with the right
address space. Formatting fix.
* gcc.dg/asan/pr115172.c: New test.
(cherry picked from commit d3c506eff54fcbac389a529c2e98da108a410b7f)
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug sanitizer/115172] Invalid -fsanitize=bool sanitization of variable from named address space
2024-05-21 9:33 [Bug sanitizer/115172] New: Invalid -fsanitize=bool sanitization of variable from named address space ubizjak at gmail dot com
` (8 preceding siblings ...)
2024-05-22 7:19 ` cvs-commit at gcc dot gnu.org
@ 2024-05-22 7:35 ` cvs-commit at gcc dot gnu.org
2024-05-22 11:11 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-05-22 7:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115172
--- Comment #10 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:35ac28b9c26debcc8ec8b247d75d4d271de72189
commit r13-8791-g35ac28b9c26debcc8ec8b247d75d4d271de72189
Author: Jakub Jelinek <jakub@redhat.com>
Date: Wed May 22 09:12:28 2024 +0200
ubsan: Use right address space for MEM_REF created for bool/enum
sanitization [PR115172]
The following testcase is miscompiled, because -fsanitize=bool,enum
creates a MEM_REF without propagating there address space qualifiers,
so what should be normally loaded using say %gs:/%fs: segment prefix
isn't. Together with asan it then causes that load to be sanitized.
2024-05-22 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/115172
* ubsan.cc (instrument_bool_enum_load): If rhs is not in generic
address space, use qualified version of utype with the right
address space. Formatting fix.
* gcc.dg/asan/pr115172.c: New test.
(cherry picked from commit d3c506eff54fcbac389a529c2e98da108a410b7f)
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug sanitizer/115172] Invalid -fsanitize=bool sanitization of variable from named address space
2024-05-21 9:33 [Bug sanitizer/115172] New: Invalid -fsanitize=bool sanitization of variable from named address space ubizjak at gmail dot com
` (9 preceding siblings ...)
2024-05-22 7:35 ` cvs-commit at gcc dot gnu.org
@ 2024-05-22 11:11 ` jakub at gcc dot gnu.org
2024-05-28 17:09 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-05-22 11:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115172
--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 13.4+/14.2+/15.1+ so far.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug sanitizer/115172] Invalid -fsanitize=bool sanitization of variable from named address space
2024-05-21 9:33 [Bug sanitizer/115172] New: Invalid -fsanitize=bool sanitization of variable from named address space ubizjak at gmail dot com
` (10 preceding siblings ...)
2024-05-22 11:11 ` jakub at gcc dot gnu.org
@ 2024-05-28 17:09 ` cvs-commit at gcc dot gnu.org
2024-05-28 17:09 ` cvs-commit at gcc dot gnu.org
2024-05-28 17:11 ` ubizjak at gmail dot com
13 siblings, 0 replies; 15+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-05-28 17:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115172
--- Comment #12 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Uros Bizjak <uros@gcc.gnu.org>:
https://gcc.gnu.org/g:da9b7a507ef38287cc16bc88e808293019f9f531
commit r12-10477-gda9b7a507ef38287cc16bc88e808293019f9f531
Author: Jakub Jelinek <jakub@redhat.com>
Date: Wed May 22 09:12:28 2024 +0200
ubsan: Use right address space for MEM_REF created for bool/enum
sanitization [PR115172]
The following testcase is miscompiled, because -fsanitize=bool,enum
creates a MEM_REF without propagating there address space qualifiers,
so what should be normally loaded using say %gs:/%fs: segment prefix
isn't. Together with asan it then causes that load to be sanitized.
2024-05-22 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/115172
* ubsan.cc (instrument_bool_enum_load): If rhs is not in generic
address space, use qualified version of utype with the right
address space. Formatting fix.
* gcc.dg/asan/pr115172.c: New test.
(cherry picked from commit d3c506eff54fcbac389a529c2e98da108a410b7f)
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug sanitizer/115172] Invalid -fsanitize=bool sanitization of variable from named address space
2024-05-21 9:33 [Bug sanitizer/115172] New: Invalid -fsanitize=bool sanitization of variable from named address space ubizjak at gmail dot com
` (11 preceding siblings ...)
2024-05-28 17:09 ` cvs-commit at gcc dot gnu.org
@ 2024-05-28 17:09 ` cvs-commit at gcc dot gnu.org
2024-05-28 17:11 ` ubizjak at gmail dot com
13 siblings, 0 replies; 15+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-05-28 17:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115172
--- Comment #13 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Uros Bizjak <uros@gcc.gnu.org>:
https://gcc.gnu.org/g:d8985ea10c911c994e00dbd6a08dcae907ebc1f7
commit r11-11454-gd8985ea10c911c994e00dbd6a08dcae907ebc1f7
Author: Jakub Jelinek <jakub@redhat.com>
Date: Wed May 22 09:12:28 2024 +0200
ubsan: Use right address space for MEM_REF created for bool/enum
sanitization [PR115172]
The following testcase is miscompiled, because -fsanitize=bool,enum
creates a MEM_REF without propagating there address space qualifiers,
so what should be normally loaded using say %gs:/%fs: segment prefix
isn't. Together with asan it then causes that load to be sanitized.
2024-05-22 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/115172
* ubsan.c (instrument_bool_enum_load): If rhs is not in generic
address space, use qualified version of utype with the right
address space. Formatting fix.
* gcc.dg/asan/pr115172.c: New test.
(cherry picked from commit d3c506eff54fcbac389a529c2e98da108a410b7f)
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug sanitizer/115172] Invalid -fsanitize=bool sanitization of variable from named address space
2024-05-21 9:33 [Bug sanitizer/115172] New: Invalid -fsanitize=bool sanitization of variable from named address space ubizjak at gmail dot com
` (12 preceding siblings ...)
2024-05-28 17:09 ` cvs-commit at gcc dot gnu.org
@ 2024-05-28 17:11 ` ubizjak at gmail dot com
13 siblings, 0 replies; 15+ messages in thread
From: ubizjak at gmail dot com @ 2024-05-28 17:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115172
Uroš Bizjak <ubizjak at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|ASSIGNED |RESOLVED
Target Milestone|--- |11.5
--- Comment #14 from Uroš Bizjak <ubizjak at gmail dot com> ---
Also fixed for 11.5+ and 12.4+.
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2024-05-28 17:11 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-05-21 9:33 [Bug sanitizer/115172] New: Invalid -fsanitize=bool sanitization of variable from named address space ubizjak at gmail dot com
2024-05-21 10:05 ` [Bug sanitizer/115172] " jakub at gcc dot gnu.org
2024-05-21 10:16 ` jakub at gcc dot gnu.org
2024-05-21 10:20 ` ubizjak at gmail dot com
2024-05-21 10:35 ` jakub at gcc dot gnu.org
2024-05-21 14:21 ` ubizjak at gmail dot com
2024-05-21 17:19 ` pchelkin at ispras dot ru
2024-05-21 21:08 ` jakub at gcc dot gnu.org
2024-05-22 7:13 ` cvs-commit at gcc dot gnu.org
2024-05-22 7:19 ` cvs-commit at gcc dot gnu.org
2024-05-22 7:35 ` cvs-commit at gcc dot gnu.org
2024-05-22 11:11 ` jakub at gcc dot gnu.org
2024-05-28 17:09 ` cvs-commit at gcc dot gnu.org
2024-05-28 17:09 ` cvs-commit at gcc dot gnu.org
2024-05-28 17:11 ` ubizjak at gmail dot com
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).