On 9/30/21 1:35 PM, Joseph Myers wrote:
On Thu, 30 Sep 2021, Martin Sebor via Gcc-patches wrote:
Jason, since you approved the C++ changes, would you mind looking
over the C bits and if they look good to you giving me the green
light to commit the patch?
https://gcc.gnu.org/pipermail/gcc-patch
On Thu, 30 Sep 2021, Martin Sebor via Gcc-patches wrote:
> Jason, since you approved the C++ changes, would you mind looking
> over the C bits and if they look good to you giving me the green
> light to commit the patch?
>
> https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579693.html
Th
Jason, since you approved the C++ changes, would you mind looking
over the C bits and if they look good to you giving me the green
light to commit the patch?
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579693.html
Thanks in advance for your help!
On 9/24/21 8:31 AM, Martin Sebor wr
Ping: Jeff, with the C++ part approved, can you please confirm your
approval with the C parts of the patch?
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579693.html
On 9/21/21 6:34 PM, Martin Sebor wrote:
On 9/21/21 3:40 PM, Jason Merrill wrote:
The C++ changes are OK.
Jef
On 9/21/21 20:34, Martin Sebor wrote:
On 9/21/21 3:40 PM, Jason Merrill wrote:
On 9/17/21 12:02, Martin Sebor wrote:
On 9/8/21 2:06 PM, Jason Merrill wrote:
On 9/2/21 7:53 PM, Martin Sebor wrote:
@@ -4622,28 +4622,94 @@ warn_for_null_address (location_t location,
tree op, tsubst_flags_t compl
On 9/21/21 3:40 PM, Jason Merrill wrote:
On 9/17/21 12:02, Martin Sebor wrote:
On 9/8/21 2:06 PM, Jason Merrill wrote:
On 9/2/21 7:53 PM, Martin Sebor wrote:
@@ -4622,28 +4622,94 @@ warn_for_null_address (location_t location,
tree op, tsubst_flags_t complain)
if (!warn_address
||
On 9/17/21 12:02, Martin Sebor wrote:
On 9/8/21 2:06 PM, Jason Merrill wrote:
On 9/2/21 7:53 PM, Martin Sebor wrote:
@@ -4622,28 +4622,94 @@ warn_for_null_address (location_t location,
tree op, tsubst_flags_t complain)
if (!warn_address
|| (complain & tf_warning) == 0
|| c_
On 9/8/21 2:06 PM, Jason Merrill wrote:
On 9/2/21 7:53 PM, Martin Sebor wrote:
@@ -4622,28 +4622,94 @@ warn_for_null_address (location_t location,
tree op, tsubst_flags_t complain)
if (!warn_address
|| (complain & tf_warning) == 0
|| c_inhibit_evaluation_warnings != 0
-
On 9/2/21 7:53 PM, Martin Sebor wrote:
@@ -4622,28 +4622,94 @@ warn_for_null_address (location_t location, tree op,
tsubst_flags_t complain)
if (!warn_address
|| (complain & tf_warning) == 0
|| c_inhibit_evaluation_warnings != 0
- || warning_suppressed_p (op, OPT_Waddres
Attached is an updated patch with Jason's suggested change to use
handled_component_p(), retested on x86_64-linux and with Glibc.
Adding more tests led to more changes but hopefully also a better
end result.
I've changed the warning suppression from a cast to void* to one
to intptr_t, in part bec
On 9/2/21 7:43 AM, Jason Merrill wrote:
On 9/1/21 6:27 PM, Martin Sebor wrote:
On 9/1/21 3:39 PM, Jason Merrill wrote:
On 9/1/21 4:33 PM, Martin Sebor wrote:
On 9/1/21 1:21 PM, Jason Merrill wrote:
On 8/31/21 10:08 PM, Martin Sebor wrote:
A Coverity run recently uncovered a latent bug in GCC
On 9/1/21 6:27 PM, Martin Sebor wrote:
On 9/1/21 3:39 PM, Jason Merrill wrote:
On 9/1/21 4:33 PM, Martin Sebor wrote:
On 9/1/21 1:21 PM, Jason Merrill wrote:
On 8/31/21 10:08 PM, Martin Sebor wrote:
A Coverity run recently uncovered a latent bug in GCC that GCC should
be able to detect itself
On 9/1/21 3:39 PM, Jason Merrill wrote:
On 9/1/21 4:33 PM, Martin Sebor wrote:
On 9/1/21 1:21 PM, Jason Merrill wrote:
On 8/31/21 10:08 PM, Martin Sebor wrote:
A Coverity run recently uncovered a latent bug in GCC that GCC should
be able to detect itself: comparing the address of a declared ob
On 9/1/21 4:33 PM, Martin Sebor wrote:
On 9/1/21 1:21 PM, Jason Merrill wrote:
On 8/31/21 10:08 PM, Martin Sebor wrote:
A Coverity run recently uncovered a latent bug in GCC that GCC should
be able to detect itself: comparing the address of a declared object
for equality to null, similar to:
> On Sep 1, 2021, at 3:35 PM, Iain Sandoe wrote:
>
>
> [EXTERNAL EMAIL]
>
> Hi Paul,
>
>> ...
>> If so, then I would think that ignoring it for this patch as well is
>> reasonable. If in a given target a pointer that C thinks of as NULL is in
>> fact a valid object pointer, then all sor
On 9/1/21 1:21 PM, Jason Merrill wrote:
On 8/31/21 10:08 PM, Martin Sebor wrote:
A Coverity run recently uncovered a latent bug in GCC that GCC should
be able to detect itself: comparing the address of a declared object
for equality to null, similar to:
int f (void)
{
int a[2][2];
On Sep 01 2021, Iain Sandoe via Gcc-patches wrote:
> I wonder what things like m68k do that have vector tables at 0 …
Vector 0 is the reset stack pointer, if that isn't ROM you have a
problem. On the Atari, the MCU redirects physical addresses 0-7 to the
system ROM. Then there is the VBR on m68
Hi Paul,
> On 1 Sep 2021, at 20:28, Koning, Paul via Gcc-patches
> wrote:
>
>> On Sep 1, 2021, at 3:08 PM, Jeff Law via Gcc-patches
>> wrote:
>> On 9/1/2021 12:57 PM, Koning, Paul wrote:
>>>
On Sep 1, 2021, at 1:35 PM, Jeff Law via Gcc-patches
wrote:
Generally OK. The
> On Sep 1, 2021, at 3:08 PM, Jeff Law via Gcc-patches
> wrote:
>
>
>
> On 9/1/2021 12:57 PM, Koning, Paul wrote:
>>
>>> On Sep 1, 2021, at 1:35 PM, Jeff Law via Gcc-patches
>>> wrote:
>>>
>>> Generally OK. There's some C++ front-end bits that Jason ought to take a
>>> quick looksie a
On 8/31/21 10:08 PM, Martin Sebor wrote:
A Coverity run recently uncovered a latent bug in GCC that GCC should
be able to detect itself: comparing the address of a declared object
for equality to null, similar to:
int f (void)
{
int a[2][2];
return &a == 0;
}
GCC issues -Wadd
On 9/1/2021 12:57 PM, Koning, Paul wrote:
On Sep 1, 2021, at 1:35 PM, Jeff Law via Gcc-patches
wrote:
Generally OK. There's some C++ front-end bits that Jason ought to take a quick
looksie at. Second, how does this interact with targets that allow objects at
address 0? We have a fe
> On Sep 1, 2021, at 1:35 PM, Jeff Law via Gcc-patches
> wrote:
>
> Generally OK. There's some C++ front-end bits that Jason ought to take a
> quick looksie at. Second, how does this interact with targets that allow
> objects at address 0? We have a few targets like that and that makes
On 8/31/2021 8:08 PM, Martin Sebor via Gcc-patches wrote:
A Coverity run recently uncovered a latent bug in GCC that GCC should
be able to detect itself: comparing the address of a declared object
for equality to null, similar to:
int f (void)
{
int a[2][2];
return &a == 0;
}
G
A Coverity run recently uncovered a latent bug in GCC that GCC should
be able to detect itself: comparing the address of a declared object
for equality to null, similar to:
int f (void)
{
int a[2][2];
return &a == 0;
}
GCC issues -Waddress for this code, but the bug Coverity found
24 matches
Mail list logo
