Re: get_range_query vs NULL argument

[Aldy Hernandez via Gcc]

On 2/16/23 08:57, Richard Biener wrote:

On Wed, Feb 15, 2023 at 11:31 PM Andrew MacLeod via Gcc  wrote:



On 2/15/23 14:50, Andrew Pinski wrote:

Hi,
While fixing PR 108354, I came across that
ssa_name_has_boolean_range calls get_range_query with cfun as the
argument but sometimes while in IPA passes cfun is currently nullptr.
The question should we check the argument before calling
get_range_query or is it a valid thing to call it with a nullptr (and
have it return global_ranges in that case)?


That might be ok...  personally I see nothing wrong with:

diff --git a/gcc/value-query.h b/gcc/value-query.h
index 63878968118..2d7bf8fcf33 100644
--- a/gcc/value-query.h
+++ b/gcc/value-query.h
@@ -140,7 +140,7 @@ get_global_range_query ()
   ATTRIBUTE_RETURNS_NONNULL inline range_query *
   get_range_query (const struct function *fun)
   {
-  return fun->x_range_query ? fun->x_range_query : &global_ranges;
+  return (fun && fun->x_range_query) ? fun->x_range_query : &global_ranges;
   }

   // Query the global range of NAME in function F.  Default to cfun.


The client is probably going to do that anyway.


But if there's no 'fun', what is 'global_ranges' initialized for?  Or
is 'global_ranges'
usable in IPA context?


If there is no fun, global_ranges will just return what get_range_info() 
used to return (i.e. SSA_NAME_RANGE_INFO).


Aldy

Git 'hooks/post_receive.py': UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in position 2766: invalid start byte

[Thomas Schwinge]

Hi!

The following is not an actual problem for me or GCC/Rust; just for your
information:

I've just pushed to GCC devel/rust/master branch
Git commits cc23831ec66..74913f718b0, which 'hooks/post_receive.py' threw
up upon:

$ git push upstream github/Rust-GCC/gccrs/master:devel/rust/master
Enumerating objects: 326, done.
Counting objects: 100% (326/326), done.
Delta compression using up to 12 threads
Compressing objects: 100% (143/143), done.
Writing objects: 100% (224/224), 32.72 KiB | 6.54 MiB/s, done.
Total 224 (delta 191), reused 106 (delta 79)
remote: Resolving deltas: 100% (191/191), completed with 86 local objects.
remote: Traceback (most recent call last):
remote:   File "hooks/post_receive.py", line 118, in 
remote: post_receive(refs_data, args.submitter_email)
remote:   File "hooks/post_receive.py", line 65, in post_receive
remote: submitter_email)
remote:   File "hooks/post_receive.py", line 47, in post_receive_one
remote: update.send_email_notifications()
remote:   File 
"/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py", line 189, 
in send_email_notifications
remote: self.__email_new_commits()
remote:   File 
"/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py", line 
1031, in __email_new_commits
remote: commit, self.get_standard_commit_email(commit))
remote:   File 
"/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py", line 
1011, in __send_commit_email
remote: default_diff=email.diff)
remote:   File 
"/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py", line 946, 
in __maybe_get_email_custom_contents
remote: hook_input=json.dumps(hooks_data),
remote:   File "/usr/lib64/python2.7/json/__init__.py", line 244, in dumps
remote: return _default_encoder.encode(obj)
remote:   File "/usr/lib64/python2.7/json/encoder.py", line 207, in encode
remote: chunks = self.iterencode(o, _one_shot=True)
remote:   File "/usr/lib64/python2.7/json/encoder.py", line 270, in 
iterencode
remote: return _iterencode(o, 0)
remote: UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in position 
2766: invalid start byte
To git+ssh://gcc.gnu.org/git/gcc.git
   cc23831ec66..74913f718b0  github/Rust-GCC/gccrs/master -> 
devel/rust/master

I very much suppose this "byte 0xff" is
commit 92d6dc8443acbd27cab411bfd68eaca56a89
"Implemented UTF-8 checking for include_str!()" adding
'gcc/testsuite/rust/compile/invalid_utf8':

$ od -x gcc/testsuite/rust/compile/invalid_utf8
000 0aff
002

Due to that (I suppose), Git commit emails to  have
not been sent.


Grüße
 Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

Re: Git 'hooks/post_receive.py': UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in position 2766: invalid start byte

[Martin Liška]

On 2/16/23 13:26, Thomas Schwinge wrote:
> Hi!
> 
> The following is not an actual problem for me or GCC/Rust; just for your
> information:

Hello.

Thanks for letting me know.

> 
> I've just pushed to GCC devel/rust/master branch
> Git commits cc23831ec66..74913f718b0, which 'hooks/post_receive.py' threw
> up upon:
> 
> $ git push upstream github/Rust-GCC/gccrs/master:devel/rust/master
> Enumerating objects: 326, done.
> Counting objects: 100% (326/326), done.
> Delta compression using up to 12 threads
> Compressing objects: 100% (143/143), done.
> Writing objects: 100% (224/224), 32.72 KiB | 6.54 MiB/s, done.
> Total 224 (delta 191), reused 106 (delta 79)
> remote: Resolving deltas: 100% (191/191), completed with 86 local objects.
> remote: Traceback (most recent call last):
> remote:   File "hooks/post_receive.py", line 118, in 
> remote: post_receive(refs_data, args.submitter_email)
> remote:   File "hooks/post_receive.py", line 65, in post_receive
> remote: submitter_email)
> remote:   File "hooks/post_receive.py", line 47, in post_receive_one
> remote: update.send_email_notifications()
> remote:   File 
> "/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py", line 
> 189, in send_email_notifications
> remote: self.__email_new_commits()
> remote:   File 
> "/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py", line 
> 1031, in __email_new_commits
> remote: commit, self.get_standard_commit_email(commit))
> remote:   File 
> "/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py", line 
> 1011, in __send_commit_email
> remote: default_diff=email.diff)
> remote:   File 
> "/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py", line 
> 946, in __maybe_get_email_custom_contents
> remote: hook_input=json.dumps(hooks_data),
> remote:   File "/usr/lib64/python2.7/json/__init__.py", line 244, in dumps
> remote: return _default_encoder.encode(obj)
> remote:   File "/usr/lib64/python2.7/json/encoder.py", line 207, in encode
> remote: chunks = self.iterencode(o, _one_shot=True)
> remote:   File "/usr/lib64/python2.7/json/encoder.py", line 270, in 
> iterencode
> remote: return _iterencode(o, 0)
> remote: UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in 
> position 2766: invalid start byte
> To git+ssh://gcc.gnu.org/git/gcc.git
>cc23831ec66..74913f718b0  github/Rust-GCC/gccrs/master -> 
> devel/rust/master

Well, the https://github.com/AdaCore/git-hooks were ported to Python 3 some 
time ago and I thought we've been
using the updated version. But it seems we're still on python2.7 :((

Joseph, can we update it, please?

> 
> I very much suppose this "byte 0xff" is
> commit 92d6dc8443acbd27cab411bfd68eaca56a89
> "Implemented UTF-8 checking for include_str!()" adding
> 'gcc/testsuite/rust/compile/invalid_utf8':
> 
> $ od -x gcc/testsuite/rust/compile/invalid_utf8
> 000 0aff
> 002
> 
> Due to that (I suppose), Git commit emails to  have
> not been sent.

Dunno if that will be fixed or not, but Python 3 should make our life easier.

Martin

> 
> 
> Grüße
>  Thomas
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
> München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
> Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
> München, HRB 106955

Missed warning (-Wuse-after-free)

[Alejandro Colomar via Gcc]

Hi!

I was preparing an example program of a use-after-realloc bug,
when I found that GCC doesn't warn in a case where it should.


alx@debian:~/tmp$ cat realloc.c
#include 
#include 
#include 
#include 
#include 

static inline char *
xstrdup(const char *s)
{
char  *p;

p = strdup(s);
if (p == NULL)
exit(EXIT_FAILURE);
return p;
}

static inline char *
strnul(const char *s)
{
return (char *) s + strlen(s);
}

int
main(void)
{
char  *p, *q;

p = xstrdup("");
q = strnul(p);

if (p == q)
puts("equal before");
else
exit(EXIT_FAILURE); // It's an empty string; this won't happen

printf("p = %p; q = %p\n", p, q);

p = realloc(p, UINT16_MAX);
if (p == NULL)
exit(EXIT_FAILURE);
puts("realloc()");

if (p == q) {  // Use after realloc.  I'd expect a warning here.
puts("equal after");
} else {
/* Can we get here?
   Let's see the options:

- realloc(3) fails:
We exit immediately.  We don't arrive here.

- realloc(3) doesn't move the memory:
p == q, as before

- realloc(3) moved the memory:
p is guaranteed to be a unique pointer,
and q is now an invalid pointer.  It is
Undefined Behavior to read `q`, so `p == q`
is UB.

   As we see, there's no _defined_ path where this can happen
 */
printf("PID = %i\n", (int) getpid());
}

printf("p = %p; q = %p\n", p, q);
}
alx@debian:~/tmp$ cc -Wall -Wextra realloc.c -O3 -fanalyzer
realloc.c: In function ‘main’:
realloc.c:67:9: warning: pointer ‘p’ may be used after ‘realloc’ 
[-Wuse-after-free]
   67 | printf("p = %p; q = %p\n", p, q);
  | ^~~~
realloc.c:39:13: note: call to ‘realloc’ here
   39 | p = realloc(p, UINT16_MAX);
  | ^~
alx@debian:~/tmp$ ./a.out 
equal before
p = 0x55bff80802a0; q = 0x55bff80802a0
realloc()
PID = 25222
p = 0x55bff80806d0; q = 0x55bff80802a0


Did I miss anything?

Cheers,

Alex

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Re: Missed warning (-Wuse-after-free)

[David Malcolm via Gcc]

On Thu, 2023-02-16 at 15:35 +0100, Alejandro Colomar via Gcc wrote:
> Hi!
> 
> I was preparing an example program of a use-after-realloc bug,
> when I found that GCC doesn't warn in a case where it should.
> 
> 
> alx@debian:~/tmp$ cat realloc.c
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> static inline char *
> xstrdup(const char *s)
> {
> char  *p;
> 
> p = strdup(s);
> if (p == NULL)
> exit(EXIT_FAILURE);
> return p;
> }
> 
> static inline char *
> strnul(const char *s)
> {
> return (char *) s + strlen(s);
> }
> 
> int
> main(void)
> {
> char  *p, *q;
> 
> p = xstrdup("");
> q = strnul(p);
> 
> if (p == q)
> puts("equal before");
> else
> exit(EXIT_FAILURE); // It's an empty string; this
> won't happen
> 
> printf("p = %p; q = %p\n", p, q);
> 
> p = realloc(p, UINT16_MAX);
> if (p == NULL)
> exit(EXIT_FAILURE);
> puts("realloc()");
> 
> if (p == q) {  // Use after realloc.  I'd expect a warning
> here.
> puts("equal after");
> } else {
> /* Can we get here?
>    Let's see the options:
> 
> - realloc(3) fails:
> We exit immediately.  We don't arrive
> here.
> 
> - realloc(3) doesn't move the memory:
> p == q, as before
> 
> - realloc(3) moved the memory:
> p is guaranteed to be a unique
> pointer,
> and q is now an invalid pointer.  It
> is
> Undefined Behavior to read `q`, so `p
> == q`
> is UB.
> 
>    As we see, there's no _defined_ path where this
> can happen
>  */
> printf("PID = %i\n", (int) getpid());
> }
> 
> printf("p = %p; q = %p\n", p, q);
> }
> alx@debian:~/tmp$ cc -Wall -Wextra realloc.c -O3 -fanalyzer
> realloc.c: In function ‘main’:
> realloc.c:67:9: warning: pointer ‘p’ may be used after ‘realloc’ [-
> Wuse-after-free]
>    67 | printf("p = %p; q = %p\n", p, q);
>   | ^~~~
> realloc.c:39:13: note: call to ‘realloc’ here
>    39 | p = realloc(p, UINT16_MAX);
>   | ^~
> alx@debian:~/tmp$ ./a.out 
> equal before
> p = 0x55bff80802a0; q = 0x55bff80802a0
> realloc()
> PID = 25222
> p = 0x55bff80806d0; q = 0x55bff80802a0
> 
> 
> Did I miss anything?

GCC's -fanalyzer will warn if you dereference q, so e.g. adding:
 printf("*q = %i\n", *q);
gives a warning:
  https://godbolt.org/z/6qx4afb3E

: In function 'main':
:65:29: warning: use after 'free' of 'q' [CWE-416] 
[-Wanalyzer-use-after-free]
   65 | printf("*q = %i\n", *q);
  | ^~
  'main': events 1-2
|
|   25 | main(void)
|  | ^~~~
|  | |
|  | (1) entry to 'main'
|..
|   29 | p = xstrdup("");
|  | ~~~
|  | |
|  | (2) calling 'xstrdup' from 'main'
|
+--> 'xstrdup': events 3-5
   |
   |8 | xstrdup(const char *s)
   |  | ^~~
   |  | |
   |  | (3) entry to 'xstrdup'
   |..
   |   13 | if (p == NULL)
   |  |~
   |  ||
   |  |(4) following 'false' branch (when 'p' is 
non-NULL)...
   |   14 | exit(EXIT_FAILURE);
   |   15 | return p;
   |  |~
   |  ||
   |  |(5) ...to here
   |
<--+
|
  'main': events 6-15
|
|   29 | p = xstrdup("");
|  | ^~~
|  | |
|  | (6) returning to 'main' from 'xstrdup'
|..
|   32 | if (p == q)
|  |~ 
|  ||
|  |(7) following 'true' branch (when 'p == q')...
|   33 | puts("equal before");
|  | 
|  | |
|  | (8) ...to here
|..
|   39 | p = realloc(p, UINT16_MAX);
|  | ~~
|  | |
|  | (9) freed here
|  | (10) when 'realloc' succeeds, moving buffer
|   40 | if (p == NULL)
|  |~ 
|  ||
|  |(11) following 'false' branch (when 'p' is non-NULL)...
|   41 | exit(EXIT_FAILURE);
|   42 | puts("realloc()");
|  | 

Stepping down as gcov maintainer and callgraph reviewer

[Martin Liška]

Hello GCC community.

After spending last decade (including my diploma thesis even more)
of my life working on GCC, I decided to leave the project and try
a different job. I would like to thank all the community members I had
change to interact with, I learned so much and enjoyed the journey!
I'll be leaving somewhen at the beginning of May.

That said, I'm stepping down from my 2 positions as I won't have a time
for proper patch review and bugs in the area I'm responsible for.

I wish the project all the best!

Cheers,
MartinFrom bb3aee20cdeeb6399ca77ac05cd8093d66256df3 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Thu, 16 Feb 2023 16:50:38 +0100
Subject: [PATCH] MAINTAINERS: stepping down from my positions

ChangeLog:

	* MAINTAINERS: I'm stepping down from my positions.
---
 MAINTAINERS | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 18edc86df67..a61d3ae06df 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -230,7 +230,6 @@ docstring relicensing	Gerald Pfeifer		
 docstring relicensing	Joseph Myers		
 predict.def		Jan Hubicka		
 gcov			Jan Hubicka		
-gcov			Martin Liska		
 gcov			Nathan Sidwell		
 option handling		Joseph Myers		
 middle-end		Jeff Law		
@@ -268,7 +267,6 @@ check in changes outside of the parts of the compiler they maintain.
 			Reviewers
 
 arc port		Claudiu Zissulescu	
-callgraph		Martin Liska		
 callgraph		Martin Jambor		
 C front end		Marek Polacek		
 CTF, BTF		David Faust		
@@ -519,6 +517,7 @@ Kriang Lerdsuwanakij
 Renlin Li	
 Xinliang David Li
 Chen Liqin	
+Martin Liska	
 Jiangning Liu	
 Sa Liu		
 Ralph Loader	
-- 
2.39.1

Re: Stepping down as gcov maintainer and callgraph reviewer

[Mark Wielaard]

Hi Martin,

On Thu, 2023-02-16 at 16:54 +0100, Martin Liška wrote:
> After spending last decade (including my diploma thesis even more)
> of my life working on GCC, I decided to leave the project and try
> a different job. I would like to thank all the community members I had
> change to interact with, I learned so much and enjoyed the journey!
> I'll be leaving somewhen at the beginning of May.
> 
> That said, I'm stepping down from my 2 positions as I won't have a time
> for proper patch review and bugs in the area I'm responsible for.

Thanks so much for all your work. I hope you aren't going too far away.
It is always a pleasure to work with you.

Cheers,

Mark

Re: Stepping down as gcov maintainer and callgraph reviewer

[David Edelsohn via Gcc]

On Thu, Feb 16, 2023 at 10:54 AM Martin Liška  wrote:

> Hello GCC community.
>
> After spending last decade (including my diploma thesis even more)
> of my life working on GCC, I decided to leave the project and try
> a different job. I would like to thank all the community members I had
> change to interact with, I learned so much and enjoyed the journey!
> I'll be leaving somewhen at the beginning of May.
>
> That said, I'm stepping down from my 2 positions as I won't have a time
> for proper patch review and bugs in the area I'm responsible for.
>
> I wish the project all the best!
>

Hi, Martin

Thank you very much for your great work on GCC over the past years.  Your
excellent technical contributions to GCC and to the development environment
behind the scenes have helped create and maintain a world-class toolchain
that powers the world.

Wishing you much success in the next steps of your career and I eagerly
await to see the tremendous impact where you choose to apply your skills
next.

Thanks, David

Re: Git 'hooks/post_receive.py': UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in position 2766: invalid start byte

[Joseph Myers]

On Thu, 16 Feb 2023, Martin Liška wrote:

> Well, the https://github.com/AdaCore/git-hooks were ported to Python 3 
> some time ago and I thought we've been using the updated version. But it 
> seems we're still on python2.7 :((
> 
> Joseph, can we update it, please?

If someone wishes to update them I'd encourage doing so (this particular 
error might be https://github.com/AdaCore/git-hooks/issues/19).  The 
update would need testing first (using the gcc-reposurgeon-8 repository 
which we've used for such test purposes) and there would need to be a 
check for any changes to configuration semantics or defaults since the 
version we're using that indicate a need to update 
refs/meta/config:project.config.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Stepping down as gcov maintainer and callgraph reviewer

[Jan Hubicka via Gcc]

Martin,
> Hello GCC community.
> 
> After spending last decade (including my diploma thesis even more)
> of my life working on GCC, I decided to leave the project and try
> a different job. I would like to thank all the community members I had
> change to interact with, I learned so much and enjoyed the journey!
> I'll be leaving somewhen at the beginning of May.
> 
> That said, I'm stepping down from my 2 positions as I won't have a time
> for proper patch review and bugs in the area I'm responsible for.

I am sad to hear this news and will definitely miss you as coleague
and co-maintaner.  Thank you for all the work on GCC!

Honza
> 
> I wish the project all the best!
> 
> Cheers,
> Martin

> From bb3aee20cdeeb6399ca77ac05cd8093d66256df3 Mon Sep 17 00:00:00 2001
> From: Martin Liska 
> Date: Thu, 16 Feb 2023 16:50:38 +0100
> Subject: [PATCH] MAINTAINERS: stepping down from my positions
> 
> ChangeLog:
> 
>   * MAINTAINERS: I'm stepping down from my positions.
> ---
>  MAINTAINERS | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 18edc86df67..a61d3ae06df 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -230,7 +230,6 @@ docstring relicensing Gerald Pfeifer  
> 
>  docstring relicensingJoseph Myers
> 
>  predict.def  Jan Hubicka 
>  gcov Jan Hubicka 
> -gcov Martin Liska
>  gcov Nathan Sidwell  
>  option handling  Joseph Myers
> 
>  middle-end   Jeff Law
> @@ -268,7 +267,6 @@ check in changes outside of the parts of the compiler 
> they maintain.
>   Reviewers
>  
>  arc port Claudiu Zissulescu  
> -callgraphMartin Liska
>  callgraphMartin Jambor   
>  C front end  Marek Polacek   
>  CTF, BTF David Faust 
> @@ -519,6 +517,7 @@ Kriang Lerdsuwanakij  
> 
>  Renlin Li
>  Xinliang David Li
>  Chen Liqin   
> +Martin Liska 
>  Jiangning Liu
>  Sa Liu   
>  Ralph Loader 
> -- 
> 2.39.1
> 

gcc-10-20230216 is now available

[GCC Administrator via Gcc]

Snapshot gcc-10-20230216 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/10-20230216/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-10 revision 4303f7d9bc5b37cabb77413c7a4f6946772b9da9

You'll find:

 gcc-10-20230216.tar.xz   Complete GCC

  SHA256=36ed578a5c80bed60695969fa98462cc016049da7a512ed1886aaf308c729261
  SHA1=6b5e65ac4f3d61d91e88485312c14d8bd12e7c09

Diffs from 10-20230209 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-10
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: Missed warning (-Wuse-after-free)

[Alejandro Colomar via Gcc]

[CC: Added those who contributed to the discussion in linux-man@,
 and also the authors of N2861 for C2x]

Hi David,

On 2/16/23 16:15, David Malcolm wrote:
> On Thu, 2023-02-16 at 15:35 +0100, Alejandro Colomar via Gcc wrote:
>> Hi!
>>
>> I was preparing an example program of a use-after-realloc bug,
>> when I found that GCC doesn't warn in a case where it should.
>>
>>
>> alx@debian:~/tmp$ cat realloc.c
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>>
>> static inline char *
>> xstrdup(const char *s)
>> {
>> char  *p;
>>
>> p = strdup(s);
>> if (p == NULL)
>> exit(EXIT_FAILURE);
>> return p;
>> }
>>
>> static inline char *
>> strnul(const char *s)
>> {
>> return (char *) s + strlen(s);
>> }
>>
>> int
>> main(void)
>> {
>> char  *p, *q;
>>
>> p = xstrdup("");
>> q = strnul(p);
>>
>> if (p == q)
>> puts("equal before");
>> else
>> exit(EXIT_FAILURE); // It's an empty string; this
>> won't happen
>>
>> printf("p = %p; q = %p\n", p, q);
>>
>> p = realloc(p, UINT16_MAX);
>> if (p == NULL)
>> exit(EXIT_FAILURE);
>> puts("realloc()");
>>
>> if (p == q) {  // Use after realloc.  I'd expect a warning
>> here.
>> puts("equal after");
>> } else {
>> /* Can we get here?
>>    Let's see the options:
>>
>> - realloc(3) fails:
>> We exit immediately.  We don't arrive
>> here.
>>
>> - realloc(3) doesn't move the memory:
>> p == q, as before
>>
>> - realloc(3) moved the memory:
>> p is guaranteed to be a unique
>> pointer,
>> and q is now an invalid pointer.  It
>> is
>> Undefined Behavior to read `q`, so `p
>> == q`
>> is UB.
>>
>>    As we see, there's no _defined_ path where this
>> can happen
>>  */
>> printf("PID = %i\n", (int) getpid());
>> }
>>
>> printf("p = %p; q = %p\n", p, q);
>> }
>> alx@debian:~/tmp$ cc -Wall -Wextra realloc.c -O3 -fanalyzer
>> realloc.c: In function ‘main’:
>> realloc.c:67:9: warning: pointer ‘p’ may be used after ‘realloc’ [-
>> Wuse-after-free]
>>    67 | printf("p = %p; q = %p\n", p, q);
>>   | ^~~~
>> realloc.c:39:13: note: call to ‘realloc’ here
>>    39 | p = realloc(p, UINT16_MAX);
>>   | ^~
>> alx@debian:~/tmp$ ./a.out 
>> equal before
>> p = 0x55bff80802a0; q = 0x55bff80802a0
>> realloc()
>> PID = 25222
>> p = 0x55bff80806d0; q = 0x55bff80802a0
>>
>>
>> Did I miss anything?
> 
> GCC's -fanalyzer will warn if you dereference q, so e.g. adding:
>  printf("*q = %i\n", *q);
> gives a warning:
>   https://godbolt.org/z/6qx4afb3E
> 
> : In function 'main':
> :65:29: warning: use after 'free' of 'q' [CWE-416] 
> [-Wanalyzer-use-after-free]
>65 | printf("*q = %i\n", *q);
>   | ^~

[...]

> 
> I'm not convinced that it's useful to the end-user to warn about the
> "use of q itself" case.

I didn't quote the standard because I couldn't find it.  I was searching in C11,
and it seems that it was only implicitly Undefined Behavior, without explicit
spelling (the value of the pointer was indeterminate, according to C11).
Now C23 will better clarify that reading such a pointer value (not even
dereferencing) is Undefined Behavior.

There was a discussion in linux-man@ some years ago, which now I realize it
didn't end up being applied (I thought we had applied a patch, but it seems we
didn't).  I'll check if we still need such a patch (and I guess we do, since
we're having this conversation).

Using the pointer is _wrong_.  And by wrong, I mean that it's Undefined 
Behavior.
I think that alone is enough to issue a warning.  Especially, since the compiler
already has that information; otherwise, it couldn't have warned about line 67
of my example program.  I could understand if due to optimizations the compiler
lost that information, so it couldn't warn, but in this case, there's no excuse.

The benefit for users?  They'll realize that the code they wrote is bad.  Not 
even
suspicious, as some warnings warn about suspicious code.  This case is
uncontroversially wrong.  That code has no valid reason to be written that way,
under ISO C.

Cheers,

Alex

> 
> Dave

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Re: Missed warning (-Wuse-after-free)

[Alejandro Colomar via Gcc]

On 2/17/23 02:04, Alejandro Colomar wrote:
> [CC: Added those who contributed to the discussion in linux-man@,
>  and also the authors of N2861 for C2x]

[...]

> 
> There was a discussion in linux-man@ some years ago, which now I realize it
> didn't end up being applied (I thought we had applied a patch, but it seems we
> didn't).  I'll check if we still need such a patch (and I guess we do, since
> we're having this conversation).

I forgot to link:


-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

[wwwdocs] testing: Tweak the link to upstream FTensor (was: Anyone using FTensor to test GCC (or otherwise)?)

[Gerald Pfeifer]

On Tue, 14 Feb 2023, NightStrike wrote:
>> Alas http://www.wlandry.net/Projects/FTensor has been down for a while,
>> and there does not appear to be a new location?
> https://wlandry.net/Projects/FTensor/ works

Ah, indeed. Thank you! Somehow that must have been the one combination I 
did not try.

I pushed the little patch below.

Gerald

commit b74309c36e59105ef0d8e0d91a85a5bfa884e175
Author: Gerald Pfeifer 
Date:   Fri Feb 17 02:19:19 2023 +0100

Tweak the link to upstream FTensor.

diff --git a/htdocs/testing/testing-ftensor.html 
b/htdocs/testing/testing-ftensor.html
index 2e67b4d8..7b1f4675 100644
--- a/htdocs/testing/testing-ftensor.html
+++ b/htdocs/testing/testing-ftensor.html
@@ -11,7 +11,7 @@
 FTensor build and test guide
 
 This page is a guide to running the testing and timing programs for the
-http://www.wlandry.net/Projects/FTensor";>FTensor
+https://wlandry.net/Projects/FTensor";>FTensor
 tensor class library as part of GCC integration testing.
 
 Resource usage

Re: Missed warning (-Wuse-after-free)

[Sam James via Gcc]

> On 17 Feb 2023, at 01:05, Alejandro Colomar via Gcc  wrote:
> 
> On 2/17/23 02:04, Alejandro Colomar wrote:
>> [CC: Added those who contributed to the discussion in linux-man@,
>> and also the authors of N2861 for C2x]
> 
> [...]
> 
>> 
>> There was a discussion in linux-man@ some years ago, which now I realize it
>> didn't end up being applied (I thought we had applied a patch, but it seems 
>> we
>> didn't).  I'll check if we still need such a patch (and I guess we do, since
>> we're having this conversation).
> 
> I forgot to link:
> 
> 

See also 
https://siddhesh.in/posts/that-is-not-a-number-that-is-a-freed-object.html.


signature.asc
Description: Message signed with OpenPGP

Re: Missed warning (-Wuse-after-free)

[Siddhesh Poyarekar]

On 2023-02-16 10:15, David Malcolm via Gcc wrote:

I'm not convinced that it's useful to the end-user to warn about the
"use of q itself" case.


FWIW, -Wuse-after-free=3 already should do this:

At level 3, the warning also diagnoses uses of indeterminate pointers in 
equality expressions.  All uses of indeterminate pointers are undefined 
but equality tests sometimes appear after
calls to "realloc" as an attempt to determine whether the call resulted 
in relocating the object to a different address.  They are diagnosed at 
a separate level to aid legacy code gradually
transition to safe alternatives.  For example, the equality test in the 
function below is diagnosed at this level:


Jakub and I had discussed this in the context of _FORTIFY_SOURCE=3 
(which is anal about this and can break things) and we got pr#105217, 
but that is also a best-effort thing, not really a guarantee.


IMO the analyzer should go that extra mile and warn for the use of q 
itself and maybe deprecate -Wuse-after-free=3 in its favour.


Sid