Re: C89isms in the test suite

[Florian Weimer via Gcc]

* Sam James:

> Would you be able to backport 6be2672e4ee41c566a9e072088a263bab5f7
> and 885b6660c17fb91980b5682514ef54668e544b02 to the active <13
> branches?

Jakub, okay to backport these two (to 12, 11, 10 I presume)?

commit 6be2672e4ee41c566a9e072088a263bab5f7
Author: Florian Weimer 
Date:   Tue Oct 18 16:58:48 2022 +0200

libsanitizer: Avoid implicit function declaration in configure test

libsanitizer/

* configure.ac (sanitizer_supported): Include  for
syscall prototype.
* configure: Regenerate.

commit 885b6660c17fb91980b5682514ef54668e544b02
Author: Florian Weimer 
Date:   Tue Oct 18 16:58:48 2022 +0200

libiberty: Fix C89-isms in configure tests

libiberty/

* acinclude.m4 (ac_cv_func_strncmp_works): Add missing
int return type and parameter list to the definition of main.
Include  and  for prototypes.
(ac_cv_c_stack_direction): Add missing
int return type and parameter list to the definitions of
main, find_stack_direction.  Include  for exit
prototype.
* configure: Regenerate.

Thanks,
Florian

Re: Revert Sphinx documentation [Was: Issues with Sphinx]

[Martin Liška]

On 11/14/22 03:49, Martin Liška wrote:
> I'm going to revert the patchset during today (Monday) and I'll send a patch 
> with a couple
> of new changes that landed in the period of time we used Sphinx.

The revert is done and I included ce51e8439a491910348a1c5aea43b55f000ba8ac 
commit
that ports all the new documentation bits to Texinfo.

Web pages content will be updated with Jakub in the afternoon.

Martin

Re: Revert Sphinx documentation [Was: Issues with Sphinx]

[Jonathan Wakely via Gcc]

On Mon, 14 Nov 2022 at 08:40, Martin Liška wrote:
>
> On 11/14/22 03:49, Martin Liška wrote:
> > I'm going to revert the patchset during today (Monday) and I'll send a 
> > patch with a couple
> > of new changes that landed in the period of time we used Sphinx.
>
> The revert is done and I included ce51e8439a491910348a1c5aea43b55f000ba8ac 
> commit
> that ports all the new documentation bits to Texinfo.

Sorry it didn't work out, and thanks for reapplying my two doc changes
that landed during the era of the sphinx.

I formatted my new region/endregion pragmas on one line because that
seemed to be how it should be done for rSt, e.g. we had:

``#pragma GCC push_options`` ``#pragma GCC pop_options``

But I think the attached patch is more correct for how we document
pragmas in texinfo.

OK for trunk?
commit 3aa461d4ba46449544730a342cb2dcb0ce6851e9
Author: Jonathan Wakely 
Date:   Mon Nov 14 09:19:13 2022

doc: Format region pragmas as separate items

This seems consistent with how other paired pragmas are documented in
texinfo, e.g. push_options and pop_options.

gcc/ChangeLog:

* doc/cpp.texi (Pragmas): Use @item and @itemx for region
pragmas.

diff --git a/gcc/doc/cpp.texi b/gcc/doc/cpp.texi
index 1be29eb605e..5e86a957a88 100644
--- a/gcc/doc/cpp.texi
+++ b/gcc/doc/cpp.texi
@@ -3843,7 +3843,8 @@ file will never be read again, no matter what.  It is a 
less-portable
 alternative to using @samp{#ifndef} to guard the contents of header files
 against multiple inclusions.
 
-@code{#pragma region @{tokens@}...}, @code{#pragma endregion @{tokens@}...}
+@item #pragma region @{tokens@}...
+@itemx #pragma endregion @{tokens@}...
 These pragmas are accepted, but have no effect.
 
 @end ftable

Re: [BUG] -Wuninitialized: initialize variable with itself

[David Brown via Gcc]

On 13/11/2022 19:43, Alejandro Colomar via Gcc wrote:

Hi Andrew!

On 11/13/22 19:41, Andrew Pinski wrote:

On Sun, Nov 13, 2022 at 10:40 AM Andrew Pinski  wrote:


On Sun, Nov 13, 2022 at 10:36 AM Alejandro Colomar via Gcc
 wrote:


Hi,

While discussing some idea for a new feature, I tested the following 
example

program:


  int main(void)
  {
  int i = i;
  return i;
  }


This is NOT a bug but a documented way of having the warning not 
being there.
See 
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Warning-Options.html#index-Winit-self 

https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Warning-Options.html#index-Wuninitialized 


"If you want to warn about code that uses the uninitialized value of
the variable in its own initializer, use the -Winit-self option."


I should note the main reason why I Know about this is because I fixed
this feature years ago (at least for C front-end)
and added the option to disable the feature.


I'm curious: what are the reasons why one would want to disable such a 
warning?

Why is it not in -Wall or -Wextra?

Thanks,

Alex



Warnings are not perfect - there is always the risk of false positives 
and false negatives.  And different people will have different ideas 
about what code is perfectly reasonable, and what code is risky and 
should trigger a warning.  Thus gcc has warning flag groups (-Wall, 
-Wextra) that try to match common consensus, and individual flags for 
personal fine-tuning.


Sometimes it is useful to have a simple way to override a warning in 
code, without going through "#pragma GCC diagnostic" lines (which are 
powerful, but not pretty).


So if you have :

int i;
if (a == 1) i = 1;
if (b == 1) i = 2;
if (c == 1) i = 3;
return i;

the compiler will warn that "i" may not be initialised.  But if you 
/know/ that one of the three conditions will match (or you don't care 
what "i" is if it does not match), then you know your code is fine and 
don't want the warning.  Writing "int i = i;" is a way of telling the 
compiler "I know what I am doing, even though this code looks dodgy, 
because I know more than you do".


It's just like writing "while ((*p++ = *q++));", or using a cast to void 
to turn off an "unused parameter" warning.

Re: [BUG] -Wuninitialized: initialize variable with itself

[Alejandro Colomar via Gcc]

Hi David,

On 11/14/22 10:41, David Brown wrote:

On 13/11/2022 19:43, Alejandro Colomar via Gcc wrote:

Hi Andrew!

On 11/13/22 19:41, Andrew Pinski wrote:

On Sun, Nov 13, 2022 at 10:40 AM Andrew Pinski  wrote:


On Sun, Nov 13, 2022 at 10:36 AM Alejandro Colomar via Gcc
 wrote:


Hi,

While discussing some idea for a new feature, I tested the following example
program:


  int main(void)
  {
  int i = i;
  return i;
  }


This is NOT a bug but a documented way of having the warning not being there.
See 
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Warning-Options.html#index-Winit-self

https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Warning-Options.html#index-Wuninitialized
"If you want to warn about code that uses the uninitialized value of
the variable in its own initializer, use the -Winit-self option."


I should note the main reason why I Know about this is because I fixed
this feature years ago (at least for C front-end)
and added the option to disable the feature.


I'm curious: what are the reasons why one would want to disable such a warning?
Why is it not in -Wall or -Wextra?

Thanks,

Alex



Warnings are not perfect - there is always the risk of false positives and false 
negatives.  And different people will have different ideas about what code is 
perfectly reasonable, and what code is risky and should trigger a warning.  Thus 
gcc has warning flag groups (-Wall, -Wextra) that try to match common consensus, 
and individual flags for personal fine-tuning.


Sometimes it is useful to have a simple way to override a warning in code, 
without going through "#pragma GCC diagnostic" lines (which are powerful, but 
not pretty).


So if you have :

 int i;
 if (a == 1) i = 1;
 if (b == 1) i = 2;
 if (c == 1) i = 3;
 return i;

the compiler will warn that "i" may not be initialised.  But if you /know/ that 
one of the three conditions will match (or you don't care what "i" is if it does 
not match), then you know your code is fine and don't want the warning.  Writing 
"int i = i;" is a way of telling the compiler "I know what I am doing, even 
though this code looks dodgy, because I know more than you do".


Ahh, that makes sense.  Since the default warnings warn about 'int i=i+1;' it 
makes sense to me.  Writing 'int i=i;' is just too stupid that can be considered 
a reasonable way to tell the compiler we know better.


Thanks!

Cheers,

Alex



It's just like writing "while ((*p++ = *q++));", or using a cast to void to turn 
off an "unused parameter" warning.


--



OpenPGP_signature
Description: OpenPGP digital signature

Re: [whish] -Wunterminated-string-initialization: new warning

[Alejandro Colomar via Gcc]

Hi Andrew!

On 11/13/22 23:12, Andrew Pinski wrote:

On Sun, Nov 13, 2022 at 1:57 PM Alejandro Colomar via Gcc
 wrote:


Hi!

I'd like to get warnings if I write the following code:

char foo[3] = "foo";


This should be easy to add as it is already part of the -Wc++-compat
option as for C++ it is invalid code.

:2:19: warning: initializer-string for array of 'char' is too long
 2 | char two[2] = "foo";   // 'f' 'o'
   |   ^
:3:19: warning: initializer-string for array of 'char' is too
long for C++ [-Wc++-compat]
 3 | char   three[3] = "foo";   // 'f' 'o' 'o'
   |   ^


... (for your more complex case [though I needed to modify one of the
strings to exactly 8]

:5:7: warning: initializer-string for array of 'char' is too
long for C++ [-Wc++-compat]
 5 |   "01234567",
   |   ^~

   else if (warn_cxx_compat
&& compare_tree_int (TYPE_SIZE_UNIT (type), len) < 0)
 warning_at (init_loc, OPT_Wc___compat,
 ("initializer-string for array of %qT "
  "is too long for C++"), typ1);

That is the current code which does this warning even so it is just a
matter of adding an option to c-family/c.opt and then having
c++-compat enable it and using that new option here.

Thanks,
Andrew Pinski


Great!  I'd like to implement it myself, as I've never written any GCC code yet, 
so it's interesting to me.  If you recall any (hopefully recent) case where a 
similar thing happened (the warning was already implemented and only needed a 
name), it might help me check how it was done.


BTW, I had another idea to add a suffix to string literals to make them 
unterminated:


char foo[3] = "foo"u;  // OK
char bar[4] = "bar";   // OK

char baz[4] = "baz"u;  // Warning: initializer is too short.
char etc[3] = "etc";   // Warning: unterminated string.

Is that doable?  Do you think it makes sense?

I have a code base that uses a mix of terminated and unterminated strings, and 
it would be nice to be able to tell the one I want in each case.


Cheers,

Alex





It's hard to keep track of sizes to make sure that the string literals always
initialize to terminated strings.  It seems something that should be easy to
implement in the compiler.

A morecomplex case where it's harder to keep track of sizes is:

static const char  log_levels[][8] = {
  "alert",
  "error",
  "warn",
  "notice",
  "info",
  "debug",
};

Here, 8 works now (and 7 too, but for aligmnent reasons I chose 8).  If tomorrow
we add or change an entry, It'll be hard to keep it safe.  Such a warning would
help a lot.


An example program is:

$ cat str.c
char two[2] = "foo";   // 'f' 'o'
char   three[3] = "foo";   // 'f' 'o' 'o'
charfour[4] = "foo";   // 'f' 'o' 'o' '\0'
charfive[5] = "foo";   // 'f' 'o' 'o' '\0' '\0'
char implicit[] = "foo";   // 'f' 'o' 'o' '\0'

$ cc -Wall -Wextra str.c
str.c:1:19: warning: initializer-string for array of ‘char’ is too long
  1 | char two[2] = "foo";   // 'f' 'o'
|   ^
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/Scrt1.o:
in function `_start':
(.text+0x17): undefined reference to `main'
collect2: error: ld returned 1 exit status


Here, I'd like that with the new warning, 'three' would also get warned.

Cheers,

Alex
--



--



OpenPGP_signature
Description: OpenPGP digital signature

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Aaron Ballman via Gcc]

On Sat, Nov 12, 2022 at 7:43 PM Paul Eggert  wrote:
>
> On 2022-11-11 07:11, Aaron Ballman wrote:
> > We believe the runtime behavior is sufficiently dangerous to
> > warrant a conservative view that any call to a function will be a call
> > that gets executed at runtime, hence a definitive signature mismatch
> > is something we feel comfortable diagnosing (in some form) by default.
>
> As long as these diagnostics by default do not cause the compiler to
> exit with nonzero status, we should be OK with Autoconf-generated
> 'configure' scripts. Although there will be problems with people who run
> "./configure CFLAGS='-Werror'", that sort of usage has always been
> problematic and unsupported by Autoconf, so we can simply continue to
> tell people "don't do that".

That's good to know, but is a problem more generally -- we are
strengthening more diagnostics to be warnings that are treated as an
error by default. This gives our users the best experience in terms of
diagnostic behavior -- they're clearly alerted to serious issues in
their code (either issues of conformance, like with use of implicit
int or implicit function decls in C99 or later, or issues of security
like statically known instances of UB), but they still have the chance
to downgrade the diagnostic back into a warning (good as a temporary
solution to start migrating code) or disable the diagnostic entirely
(good if you plan to never update your compiler version but otherwise
not recommended). Some of these diagnostics are expected to change to
be error-only diagnostics in the future, so this strengthening helps
to set user expectations as well.

That's why it's generally a problem when autoconf relies on invalid
language constructs -- it creates a tension between the autoconf uses
and improving the C ecosystem.  The autoconf uses aren't always
unreasonable, but are very much a special case scenario compared to
general C development. I suspect that as the security posture of the C
language and its implementations improves in response to recent
concerns around suitability of the language
(https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF),
this tension will come up more frequently.

~Aaron

Re: Revert Sphinx documentation [Was: Issues with Sphinx]

[Gerald Pfeifer]

On Mon, 14 Nov 2022, Martin Liška wrote:
> The situation with the Sphinx migration went out of control. The TODO 
> list overwhelmed me and there are road-blocks that can't be easily fixed 
> with what Sphinx currently supports.

This migration was/is a huge and complex undertaking, and you have been 
patiently chipping away at obstacle after obstacle.

So while it probably is disappointing it did not go through this time,
you made a lot of progress and important contributions - and we all 
learned quite a bit more, also in terms of (not so obvious) requirements,
dependencies, and road blocks left which you summarized.


Timing was tricky for me being on the road last week and I am definitely
committed to keep helping with this transition. Maybe soon after we are in 
stage 1 again?

And would it make sense to convert at least our installation docs and
https://gcc.gnu.org/install/ for the GCC 13 release?

Gerald

Re: [whish] -Wunterminated-string-initialization: new warning

[Jonathan Wakely via Gcc]

On Mon, 14 Nov 2022 at 11:38, Alejandro Colomar via Gcc  wrote:
>
> Hi Andrew!
>
> On 11/13/22 23:12, Andrew Pinski wrote:
> > On Sun, Nov 13, 2022 at 1:57 PM Alejandro Colomar via Gcc
> >  wrote:
> >>
> >> Hi!
> >>
> >> I'd like to get warnings if I write the following code:
> >>
> >> char foo[3] = "foo";
> >
> > This should be easy to add as it is already part of the -Wc++-compat
> > option as for C++ it is invalid code.
> >
> > :2:19: warning: initializer-string for array of 'char' is too long
> >  2 | char two[2] = "foo";   // 'f' 'o'
> >|   ^
> > :3:19: warning: initializer-string for array of 'char' is too
> > long for C++ [-Wc++-compat]
> >  3 | char   three[3] = "foo";   // 'f' 'o' 'o'
> >|   ^
> >
> >
> > ... (for your more complex case [though I needed to modify one of the
> > strings to exactly 8]
> >
> > :5:7: warning: initializer-string for array of 'char' is too
> > long for C++ [-Wc++-compat]
> >  5 |   "01234567",
> >|   ^~
> >
> >else if (warn_cxx_compat
> > && compare_tree_int (TYPE_SIZE_UNIT (type), len) < 
> > 0)
> >  warning_at (init_loc, OPT_Wc___compat,
> >  ("initializer-string for array of %qT "
> >   "is too long for C++"), typ1);
> >
> > That is the current code which does this warning even so it is just a
> > matter of adding an option to c-family/c.opt and then having
> > c++-compat enable it and using that new option here.
> >
> > Thanks,
> > Andrew Pinski
>
> Great!  I'd like to implement it myself, as I've never written any GCC code 
> yet,
> so it's interesting to me.  If you recall any (hopefully recent) case where a
> similar thing happened (the warning was already implemented and only needed a
> name), it might help me check how it was done.

`git log gcc/c-family/c.opt` will show loads of changes adding warnings.

>
> BTW, I had another idea to add a suffix to string literals to make them
> unterminated:
>
> char foo[3] = "foo"u;  // OK
> char bar[4] = "bar";   // OK
>
> char baz[4] = "baz"u;  // Warning: initializer is too short.
> char etc[3] = "etc";   // Warning: unterminated string.
>
> Is that doable?  Do you think it makes sense?

IMHO no. This is not useful enough to add a language extension, it's
an incredibly niche use case. Your suggested syntax also looks very
confusing with UTF-16 string literals, and is not sufficiently
distinct from a normal string literal to be obvious when quickly
reading the code. People expect string literals in C to be
null-terminated, having a subtle suffix that changes that would be a
bug farm.

You can do {'b', 'a', 'z'} if you want an explicitly unterminated array of char.

GCC 13.0.0 Status Report (2022-11-14), Stage 3 in effect now

[Richard Biener via Gcc]

Status
==

The GCC development branch which will become GCC 13 is now in
bugfixing mode (Stage 3) until the end of Jan 15th.

As usual the first weeks of Stage 3 are used to feature patches
posted late during Stage 1.  At some point unreviewed features
need to be postponed for the next Stage 1.


Quality Data


Priority  #   Change from last report
---   ---
P1  33
P2  473 
P3  113   +  29
P4  253   +   6
P5  25   
---   ---
Total P1-P3 619   +  29
Total   897   +  35


Previous Report
===

https://gcc.gnu.org/pipermail/gcc/2022-October/239690.html

unterminated string literals (was: [whish] -Wunterminated-string-initialization: new warning)

[Alejandro Colomar via Gcc]

Hi Jonathan,

On 11/14/22 14:14, Jonathan Wakely wrote:

On Mon, 14 Nov 2022 at 11:38, Alejandro Colomar via Gcc  wrote:

BTW, I had another idea to add a suffix to string literals to make them
unterminated:

char foo[3] = "foo"u;  // OK
char bar[4] = "bar";   // OK

char baz[4] = "baz"u;  // Warning: initializer is too short.
char etc[3] = "etc";   // Warning: unterminated string.

Is that doable?  Do you think it makes sense?


IMHO no. This is not useful enough to add a language extension, it's
an incredibly niche use case.


I agree it's way too niche.


Your suggested syntax also looks very
confusing with UTF-16 string literals,


Maybe.


and is not sufficiently
distinct from a normal string literal to be obvious when quickly
reading the code. People expect string literals in C to be
null-terminated, having a subtle suffix that changes that would be a
bug farm.


But, you have to combine both the suffix with the corresponding size (one less 
than for normal strings).  A programmer needs to be consciously doing this.  For 
readers of the code, maybe there's a bit more of a readability issue, especially 
if you don't know the extension.  But when you stop a little bit to check what 
that suffix is doing and then realize the size is weird, a reasonable programmer 
should at least ask or check the documentation for that thing.


Regarding safety, I also have that thing very present in my mind, and in an 
attempt to get the compiler on my side, I decided to use 'char *' for 
NUL-terminated strings, and 'u_char *' for u_nterminated strings.  That helps 
the compiler know when we're using one in place of another, which as you say 
would be a source of bugs.


Maybe having the type of these new strings be u_char[] instead of char[] would 
help have more type safety.  I didn't suggest this because that would not be how 
strings in C have always been.  However, considering that they are not really 
strings, it could make sense.




You can do {'b', 'a', 'z'} if you want an explicitly unterminated array of char.


A bit unreadable :)
I think I'll keep using normal literals, and maybe some workaround to disable 
the warnings for specific cases.  Not my preference, but it can work.


Cheers,

Alex

--



OpenPGP_signature
Description: OpenPGP digital signature

Re: [whish] -Wunterminated-string-initialization: new warning

[Alejandro Colomar via Gcc]

Hi Jonathan,

On 11/14/22 14:14, Jonathan Wakely wrote:

On Mon, 14 Nov 2022 at 11:38, Alejandro Colomar via Gcc  wrote:


Hi Andrew!

On 11/13/22 23:12, Andrew Pinski wrote:

On Sun, Nov 13, 2022 at 1:57 PM Alejandro Colomar via Gcc
 wrote:


Hi!

I'd like to get warnings if I write the following code:

char foo[3] = "foo";


This should be easy to add as it is already part of the -Wc++-compat
option as for C++ it is invalid code.

:2:19: warning: initializer-string for array of 'char' is too long
  2 | char two[2] = "foo";   // 'f' 'o'
|   ^
:3:19: warning: initializer-string for array of 'char' is too
long for C++ [-Wc++-compat]
  3 | char   three[3] = "foo";   // 'f' 'o' 'o'
|   ^


... (for your more complex case [though I needed to modify one of the
strings to exactly 8]

:5:7: warning: initializer-string for array of 'char' is too
long for C++ [-Wc++-compat]
  5 |   "01234567",
|   ^~

else if (warn_cxx_compat
 && compare_tree_int (TYPE_SIZE_UNIT (type), len) < 0)
  warning_at (init_loc, OPT_Wc___compat,
  ("initializer-string for array of %qT "
   "is too long for C++"), typ1);

That is the current code which does this warning even so it is just a
matter of adding an option to c-family/c.opt and then having
c++-compat enable it and using that new option here.

Thanks,
Andrew Pinski


Great!  I'd like to implement it myself, as I've never written any GCC code yet,
so it's interesting to me.  If you recall any (hopefully recent) case where a
similar thing happened (the warning was already implemented and only needed a
name), it might help me check how it was done.


`git log gcc/c-family/c.opt` will show loads of changes adding warnings.


Thanks, I will check and try it, and come back if I have any doubts.

Cheers,

Alex

--



OpenPGP_signature
Description: OpenPGP digital signature

[BUG] README: Reference to non-existent path?

[Alejandro Colomar via Gcc]

Hi,

I'm trying to understand a few implementation details of gcc for implementing a 
new warning.  For that, I first read the GCC manual [1].


[1]: 

However, that manual has nothing about internals, such as 'LangEnabledBy()'.
Then I checked what's in the root of the repo to see what I can read:

$ ls
ABOUT-NLS   config-ml.in  libcody  libvtv
COPYING config.guess  libcpp   ltgcc.m4
COPYING.LIB config.rpath  libdecnumber ltmain.sh
COPYING.RUNTIME config.sublibffi   lto-plugin
COPYING3configure libgcc   ltoptions.m4
COPYING3.LIBconfigure.ac  libgfortran  ltsugar.m4
ChangeLog   contrib   libgoltversion.m4
ChangeLog.jit   depcomp   libgomp  lt~obsolete.m4
ChangeLog.tree-ssa  fixincludes   libibertymaintainer-scripts
INSTALL gcc   libitm   missing
MAINTAINERS gnattools libobjc  mkdep
Makefile.defgotools   liboffloadmicmkinstalldirs
Makefile.in include   libphobosmove-if-change
Makefile.tplinstall-shlibquadmath  multilib.am
README  intl  libsanitizer symlink-tree
ar-lib  libadalibssp   test-driver
c++toolslibatomic libstdc++-v3 ylwrap
compile libbacktrace  libtool-ldflags  zlib
config  libcc1libtool.m4

The only interesting file seems to be the README.  Let's see what it says:


The directory INSTALL contains copies of the installation information
as HTML and plain text.  The source of this information is
gcc/doc/install.texi.  The installation information includes details
of what is included in the GCC sources and what files GCC installs.

See the file gcc/doc/gcc.texi (together with other files that it
includes) for usage and porting information.  An online readable
version of the manual is in the files gcc/doc/gcc.info*.


Okay, let's see the online readable version of the manual:

$ ls gcc/doc/gcc.info*
ls: cannot access 'gcc/doc/gcc.info*': No such file or directory

No files with that glob(7).  BTW, it might be interesting to provide that manual 
in a package, so that I could install it as something like:


apt-get install gcc-doc-internal

Cheers,

Alex

--



OpenPGP_signature
Description: OpenPGP digital signature

Re: [BUG] -Wuninitialized: initialize variable with itself

[NightStrike via Gcc]

On Mon, Nov 14, 2022, 04:42 David Brown via Gcc  wrote:

> On 13/11/2022 19:43, Alejandro Colomar via Gcc wrote:
> > Hi Andrew!
> >
> > On 11/13/22 19:41, Andrew Pinski wrote:
> >> On Sun, Nov 13, 2022 at 10:40 AM Andrew Pinski 
> wrote:
> >>>
> >>> On Sun, Nov 13, 2022 at 10:36 AM Alejandro Colomar via Gcc
> >>>  wrote:
> 
>  Hi,
> 
>  While discussing some idea for a new feature, I tested the following
>  example
>  program:
> 
> 
>    int main(void)
>    {
>    int i = i;
>    return i;
>    }
> >>>
> >>> This is NOT a bug but a documented way of having the warning not
> >>> being there.
> >>> See
> >>>
> https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Warning-Options.html#index-Winit-self
> >>>
> >>>
> https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Warning-Options.html#index-Wuninitialized
> >>>
> >>> "If you want to warn about code that uses the uninitialized value of
> >>> the variable in its own initializer, use the -Winit-self option."
> >>
> >> I should note the main reason why I Know about this is because I fixed
> >> this feature years ago (at least for C front-end)
> >> and added the option to disable the feature.
> >
> > I'm curious: what are the reasons why one would want to disable such a
> > warning?
> > Why is it not in -Wall or -Wextra?
> >
> > Thanks,
> >
> > Alex
> >
>
> Warnings are not perfect - there is always the risk of false positives
> and false negatives.  And different people will have different ideas
> about what code is perfectly reasonable, and what code is risky and
> should trigger a warning.  Thus gcc has warning flag groups (-Wall,
> -Wextra) that try to match common consensus, and individual flags for
> personal fine-tuning.
>
> Sometimes it is useful to have a simple way to override a warning in
> code, without going through "#pragma GCC diagnostic" lines (which are
> powerful, but not pretty).
>
> So if you have :
>
> int i;
> if (a == 1) i = 1;
> if (b == 1) i = 2;
> if (c == 1) i = 3;
> return i;
>
> the compiler will warn that "i" may not be initialised.  But if you
> /know/ that one of the three conditions will match (or you don't care
> what "i" is if it does not match), then you know your code is fine and
> don't want the warning.  Writing "int i = i;" is a way of telling the
> compiler "I know what I am doing, even though this code looks dodgy,
> because I know more than you do".
>
> It's just like writing "while ((*p++ = *q++));", or using a cast to void
> to turn off an "unused parameter" warning.
>

Wouldn't it be easier, faster, and more obvious to the reader to just use
"int i = 0"? I'm curious what a real world use case is where you can't do
the more common thing if =0.

>

Re: [BUG] README: Reference to non-existent path?

[Jonathan Wakely via Gcc]

On Mon, 14 Nov 2022 at 15:03, Alejandro Colomar via Gcc  wrote:
>
> Hi,
>
> I'm trying to understand a few implementation details of gcc for implementing 
> a
> new warning.  For that, I first read the GCC manual [1].
>
> [1]: 

That's the user manual, for GCC internals see the gccint docs:
https://gcc.gnu.org/onlinedocs/gccint/Options.html#Options

Re: [BUG] README: Reference to non-existent path?

[Jonathan Wakely via Gcc]

On Mon, 14 Nov 2022 at 15:03, Alejandro Colomar wrote:
> BTW, it might be interesting to provide that manual
> in a package, so that I could install it as something like:
>
>  apt-get install gcc-doc-internal

"info gccint" already works fine on my distro. If it's not packaged
for yours, that's a distro issue.

Re: [BUG] -Wuninitialized: initialize variable with itself

[David Brown via Gcc]

On 14/11/2022 16:10, NightStrike wrote:



On Mon, Nov 14, 2022, 04:42 David Brown via Gcc 



Warnings are not perfect - there is always the risk of false positives
and false negatives.  And different people will have different ideas
about what code is perfectly reasonable, and what code is risky and
should trigger a warning.  Thus gcc has warning flag groups (-Wall,
-Wextra) that try to match common consensus, and individual flags for
personal fine-tuning.

Sometimes it is useful to have a simple way to override a warning in
code, without going through "#pragma GCC diagnostic" lines (which are
powerful, but not pretty).

So if you have :

         int i;
         if (a == 1) i = 1;
         if (b == 1) i = 2;
         if (c == 1) i = 3;
         return i;

the compiler will warn that "i" may not be initialised.  But if you
/know/ that one of the three conditions will match (or you don't care
what "i" is if it does not match), then you know your code is fine and
don't want the warning.  Writing "int i = i;" is a way of telling the
compiler "I know what I am doing, even though this code looks dodgy,
because I know more than you do".

It's just like writing "while ((*p++ = *q++));", or using a cast to
void
to turn off an "unused parameter" warning.


Wouldn't it be easier, faster, and more obvious to the reader to just 
use "int i = 0"? I'm curious what a real world use case is where you 
can't do the more common thing if =0.




You can write "int i = 0;" if you prefer.  I would not, because IMHO 
doing so would be wrong, unclear to the reader, less efficient, and 
harder to debug.


In the code above, the value returned should never be 0.  So why should 
"i" be set to 0 at any point?  That's just an extra instruction the 
compiler must generate (in my line of work, my code often needs to be 
efficient).  More importantly, perhaps, it means that if you use 
diagnostic tools such as sanitizers you are hiding bugs from them 
instead of catching them - a sanitizer could catch the case of "return 
i;" when "i" is not set.


(I don't know if current sanitizers will do that or not, and haven't 
tested it, but they /could/.)


But I'm quite happy with :

int i = i;  // Self-initialise to silence warning

I don't think there is a "perfect" solution to cases like this, and 
opinions will always differ, but self-initialisation seems a good choice 
to me.  Regardless of the pros and cons in this particular example, the 
handling of self-initialisation warnings in gcc is, AFAIUI, to allow 
such code for those that want to use it.

Re: [BUG] README: Reference to non-existent path?

[Alejandro Colomar via Gcc]

Hi Jonathan,

On 11/14/22 16:36, Jonathan Wakely wrote:

On Mon, 14 Nov 2022 at 15:03, Alejandro Colomar wrote:

BTW, it might be interesting to provide that manual
in a package, so that I could install it as something like:

  apt-get install gcc-doc-internal


"info gccint" already works fine on my distro. If it's not packaged
for yours, that's a distro issue.


It works.  I didn't know it existed :)

Maybe add a reference to it in the README?

Thanks!

Alex

--



OpenPGP_signature
Description: OpenPGP digital signature

Re: GCC 13.0.0 Status Report (2022-11-14), Stage 3 in effect now

[Xi Ruoyao via Gcc]

Hi Martin,

Is it allowed to merge libsanitizer from LLVM in stage 3?  If not I'd
like to cherry pick some commits from LLVM [to fix some stupid errors
I've made in LoongArch libasan :(].

On Mon, 2022-11-14 at 13:21 +, Richard Biener via Gcc-patches wrote:
> Status
> ==
> 
> The GCC development branch which will become GCC 13 is now in
> bugfixing mode (Stage 3) until the end of Jan 15th.
> 
> As usual the first weeks of Stage 3 are used to feature patches
> posted late during Stage 1.  At some point unreviewed features
> need to be postponed for the next Stage 1.
> 
> 
> Quality Data
> 
> 
> Priority  #   Change from last report
>     ---   ---
> P1  33    
> P2  473 
> P3  113   +  29
> P4  253   +   6
> P5  25   
>     ---   ---
> Total P1-P3 619   +  29
> Total   897   +  35
> 
> 
> Previous Report
> ===
> 
> https://gcc.gnu.org/pipermail/gcc/2022-October/239690.html

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

Re: [BUG] -Wuninitialized: initialize variable with itself

[NightStrike via Gcc]

On Mon, Nov 14, 2022, 10:49 David Brown  wrote:

>
>
> On 14/11/2022 16:10, NightStrike wrote:
> >
> >
> > On Mon, Nov 14, 2022, 04:42 David Brown via Gcc 
> >
> > Warnings are not perfect - there is always the risk of false
> positives
> > and false negatives.  And different people will have different ideas
> > about what code is perfectly reasonable, and what code is risky and
> > should trigger a warning.  Thus gcc has warning flag groups (-Wall,
> > -Wextra) that try to match common consensus, and individual flags for
> > personal fine-tuning.
> >
> > Sometimes it is useful to have a simple way to override a warning in
> > code, without going through "#pragma GCC diagnostic" lines (which are
> > powerful, but not pretty).
> >
> > So if you have :
> >
> >  int i;
> >  if (a == 1) i = 1;
> >  if (b == 1) i = 2;
> >  if (c == 1) i = 3;
> >  return i;
> >
> > the compiler will warn that "i" may not be initialised.  But if you
> > /know/ that one of the three conditions will match (or you don't care
> > what "i" is if it does not match), then you know your code is fine
> and
> > don't want the warning.  Writing "int i = i;" is a way of telling the
> > compiler "I know what I am doing, even though this code looks dodgy,
> > because I know more than you do".
> >
> > It's just like writing "while ((*p++ = *q++));", or using a cast to
> > void
> > to turn off an "unused parameter" warning.
> >
> >
> > Wouldn't it be easier, faster, and more obvious to the reader to just
> > use "int i = 0"? I'm curious what a real world use case is where you
> > can't do the more common thing if =0.
> >
>
> You can write "int i = 0;" if you prefer.  I would not, because IMHO
> doing so would be wrong, unclear to the reader, less efficient, and
> harder to debug.
>
> In the code above, the value returned should never be 0.  So why should
> "i" be set to 0 at any point?  That's just an extra instruction the
> compiler must generate (in my line of work, my code often needs to be
> efficient).  More importantly, perhaps, it means that if you use
> diagnostic tools such as sanitizers you are hiding bugs from them
> instead of catching them - a sanitizer could catch the case of "return
> i;" when "i" is not set.
>
> (I don't know if current sanitizers will do that or not, and haven't
> tested it, but they /could/.)
>
> But I'm quite happy with :
>
> int i = i;  // Self-initialise to silence warning
>
> I don't think there is a "perfect" solution to cases like this, and
> opinions will always differ, but self-initialisation seems a good choice
> to me.  Regardless of the pros and cons in this particular example, the
> handling of self-initialisation warnings in gcc is, AFAIUI, to allow
> such code for those that want to use it.


Thanks for the extended explanation, insight,  and detail!

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Joseph Myers]

On Sun, 13 Nov 2022, Alejandro Colomar via Gcc wrote:

> Maybe allowing integral types and pointers would be enough.  However,
> foreseeing that the _Lengthof() proposal (BTW, which paper was it?) will
> succeed, and combining it with this one, _Lengthof(pointer) would ideally give
> the length of the array, so allowing pointers would conflict.

Do you mean N2529 Romero, New pointer-proof keyword to determine array 
length?  To quote the convenor in WG14 reflector message 18575 (17 Nov 
2020) when I asked about its status, "The author asked me not to put those 
on the agenda.  He will supply updated versions later.".

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

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Alejandro Colomar via Gcc]

Hi Joseph!

On 11/14/22 18:52, Joseph Myers wrote:

On Sun, 13 Nov 2022, Alejandro Colomar via Gcc wrote:


Maybe allowing integral types and pointers would be enough.  However,
foreseeing that the _Lengthof() proposal (BTW, which paper was it?) will
succeed, and combining it with this one, _Lengthof(pointer) would ideally give
the length of the array, so allowing pointers would conflict.


Do you mean N2529 Romero, New pointer-proof keyword to determine array
length?


Yes, that's it!  Thanks.


To quote the convenor in WG14 reflector message 18575 (17 Nov
2020) when I asked about its status, "The author asked me not to put those
on the agenda.  He will supply updated versions later.".


Since his email is not in the paper, would you mind forwarding him this 
suggestion of mine of renaming it to avoid confusion with string lengths?  Or 
maybe point him to the mailing list discussion[1]?


[1]: 



Cheers,

Alex

--



OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Joseph Myers]

On Sun, 13 Nov 2022, Alejandro Colomar via Gcc wrote:

> SYNOPSIS:
> 
> unary-operator:  . identifier

That's not what you mean.  See the standard syntax.

unary-expression:
  [other alternatives]
  unary-operator cast-expression

unary-operator: one of
  & * + - ~ !

> -  It is not an lvalue.
> 
>-  This means sizeof() and _Lengthof() cannot be applied to them.

sizeof can be applied to non-lvalues.

>-  This prevents ambiguity with a designator in an initializer-list within
> a nested braced-initializer.

No, it doesn't.  See my previous points about syntactic disambiguation 
being a separate matter from "one parse would result in a constraint 
violation, so choose another parse that doesn't" (necessarily, because the 
constraint violation that results could in general be at an arbitrary 
distance from the point where a choice of parse has to be made).  Or see 
e.g. the disambiguation rule about enum type specifiers: there is an 
explicit rule "If an enum type specifier is present, then the longest 
possible sequence of tokens that can be interpreted as a specifier 
qualifier list is interpreted as part of the enum type specifier." that 
ensures that "enum e : long int;" interprets "long int" as the enum type 
specifier, rather than "long" as the enum type specifier and "int" as 
another type specifier in the sequence of declaration specifiers, even 
though the latter parse would result in a constraint violation later.

Also, requiring unbounded lookahead to determine what kind of construct is 
being parsed may be considered questionable for C.  (If you have an 
initializer starting .a.b.c.d.e, possibly with array element access as 
well, those could all be designators or .a might be a reference to a 
parameter of struct or union type and .b.c.d.e a sequence of references to 
members within it and disambiguation under your rule would depend on 
whether an '=' follows such an unbounded sequence.)

> -  The type of a .identifier is always an incomplete type.
> 
>-  This prevents circular dependencies involving sizeof() or _Lengthof().

We have typeof as well, which can be applied to expressions with 
incomplete type.

> -  Shadowing rules apply.
> 
>-  This prevents ambiguity.

"Shadowing rules apply" isn't much of a specification.  You need detailed 
wording that would be added to 6.2.1 Scopes of identifiers (or equivalent 
elsewhere) to make it clear exactly what scopes apply for identifiers 
looked up using this construct.

>-
>void foo(struct bar { int x; char c[.x] } a, int x);
> 
>Explanation:
>-  Because of shadowing rules, [.x] refers to the struct member.

I really don't think standardizing VLAs-in-structures would be a good 
idea.  Certainly it would be a massive pain to specify meaningful 
semantics for them and this outline doesn't even attempt to work through 
the consequences of removing the rule that "If an identifier is declared 
as having a variably modified type, it shall be an ordinary identifier (as 
defined in 6.2.3), have no linkage, and have either block scope or 
function prototype scope.".

The idea that .x as an expression might refer to either a member or a 
parameter is also a massive change to the namespace rules, where at 
present those are in completely different namespaces and so in any given 
context a name only needs looking up as one or the other.

Again, proposals should be *minimal*.  And even when they are, many issues 
may well arise in practice (see the long list of constexpr issues in my 
commit message for that C2x feature, for example, which I expect to turn 
into multiple NB comments and at least two accompanying documents).

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

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Paul Eggert]

On 2022-11-14 04:41, Aaron Ballman wrote:

it's generally a problem when autoconf relies on invalid
language constructs


Autoconf *must* rely on invalid language constructs, if only to test 
whether the language constructs work. And Clang therefore must be 
careful about how it diagnoses invalid constructs. Clang shouldn't 
willy-nilly change the way it reports invalid constructs, as that can 
break Autoconf.



issues of security
like statically known instances of UB


It's fine to report those; I'm not saying don't report them. All I'm 
saying is that Clang should be careful about *how* it reports them.


At the very least if there are going to be changes in this area, the 
Clang developers should notify Autoconf (and presumably other) 
downstream users of the changes, and provide a supported way to get the 
old behavior for reporting, and give downstream time to adapt.

Re: [BUG] README: Reference to non-existent path?

[Joseph Myers]

On Mon, 14 Nov 2022, Alejandro Colomar via Gcc wrote:

> Okay, let's see the online readable version of the manual:
> 
> $ ls gcc/doc/gcc.info*
> ls: cannot access 'gcc/doc/gcc.info*': No such file or directory

That reference is for releases - those files are in release tarballs, but 
not in git or snapshots.

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

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Joseph Myers]

On Mon, 14 Nov 2022, Alejandro Colomar via Gcc wrote:

> > To quote the convenor in WG14 reflector message 18575 (17 Nov
> > 2020) when I asked about its status, "The author asked me not to put those
> > on the agenda.  He will supply updated versions later.".
> 
> Since his email is not in the paper, would you mind forwarding him this
> suggestion of mine of renaming it to avoid confusion with string lengths?  Or
> maybe point him to the mailing list discussion[1]?
> 
> [1]:
> 

I don't have his email address (I don't see any emails from him on the 
reflector since I joined it in 2001).

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

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Florian Weimer via Gcc]

* Paul Eggert:

> On 2022-11-14 04:41, Aaron Ballman wrote:
>> it's generally a problem when autoconf relies on invalid
>> language constructs
>
> Autoconf *must* rely on invalid language constructs, if only to test
> whether the language constructs work. And Clang therefore must be 
> careful about how it diagnoses invalid constructs. Clang shouldn't
> willy-nilly change the way it reports invalid constructs, as that can 
> break Autoconf.

This is only true for the status quo.  We could finally band together
and define an interface between autoconf and the toolchain that avoids
feature probing through source code fragments for common cases.  It
might make configure scripts to run quite a bit faster, too.

That being said, system compilers need to be careful when turning
warnings into errors by default, but that doesn't mean we should never
do such changes, particularly when we know based on interactions with
programmers that the warnings are not sufficient for avoiding wasted
time.

Thanks,
Florian

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Aaron Ballman via Gcc]

On Mon, Nov 14, 2022 at 1:14 PM Paul Eggert  wrote:
>
> On 2022-11-14 04:41, Aaron Ballman wrote:
> > it's generally a problem when autoconf relies on invalid
> > language constructs
>
> Autoconf *must* rely on invalid language constructs, if only to test
> whether the language constructs work. And Clang therefore must be
> careful about how it diagnoses invalid constructs. Clang shouldn't
> willy-nilly change the way it reports invalid constructs, as that can
> break Autoconf.
>
> > issues of security
> > like statically known instances of UB
>
> It's fine to report those; I'm not saying don't report them. All I'm
> saying is that Clang should be careful about *how* it reports them.
>
> At the very least if there are going to be changes in this area, the
> Clang developers should notify Autoconf (and presumably other)
> downstream users of the changes, and provide a supported way to get the
> old behavior for reporting, and give downstream time to adapt.

Definitely agreed about the communication aspects! I mentioned this upthread:

FWIW, we're working on improving communication
about potentially disruptive changes to Clang, so you might want to
consider either subscribing to the clang-vendors code review group at
https://reviews.llvm.org/project/members/113/ (if you want to be
involved in code review before things land) or the Announcements
discourse channel at https://discourse.llvm.org/c/announce/ (if you
want to be notified after something lands but before Clang ships).

One other thing we've done recently is starting to call out
potentially disruptive changes in the release notes as well:
https://clang.llvm.org/docs/ReleaseNotes.html#potentially-breaking-changes
-- but this is more for notifying folks after a release goes out, so
one of the other approaches is more proactive if the goal is to alert
Clang developers to serious deployment problems before we ship.

~Aaron

Re: Revert Sphinx documentation [Was: Issues with Sphinx]

[Gerald Pfeifer]

On Mon, 14 Nov 2022, Jonathan Wakely wrote:
> I formatted my new region/endregion pragmas on one line because that
> seemed to be how it should be done for rSt, e.g. we had:
> 
> ``#pragma GCC push_options`` ``#pragma GCC pop_options``
> 
> But I think the attached patch is more correct for how we document
> pragmas in texinfo.
> 
> OK for trunk?

Looks good to my eyes. Thank you for caring for such details, Jonathan!

Gerald

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Sam James via Gcc]

> On 13 Nov 2022, at 00:43, Paul Eggert  wrote:
> 
> On 2022-11-11 07:11, Aaron Ballman wrote:
>> We believe the runtime behavior is sufficiently dangerous to
>> warrant a conservative view that any call to a function will be a call
>> that gets executed at runtime, hence a definitive signature mismatch
>> is something we feel comfortable diagnosing (in some form) by default.
> 
> As long as these diagnostics by default do not cause the compiler to exit 
> with nonzero status, we should be OK with Autoconf-generated 'configure' 
> scripts. Although there will be problems with people who run "./configure 
> CFLAGS='-Werror'", that sort of usage has always been problematic and 
> unsupported by Autoconf, so we can simply continue to tell people "don't do 
> that".
> 

Is there somewhere in the autoconf docs we actually say this?

I've seen a few instances of folks adding it themselves very
early in their configure scripts (which is a pain for distros
anyway) which then ends up affecting the rest.


signature.asc
Description: Message signed with OpenPGP

Re: C89isms in the test suite

[Sam James via Gcc]

> On 14 Nov 2022, at 08:19, Florian Weimer  wrote:
> 
> * Sam James:
> 
>> Would you be able to backport 6be2672e4ee41c566a9e072088a263bab5f7
>> and 885b6660c17fb91980b5682514ef54668e544b02 to the active <13
>> branches?
> 
> Jakub, okay to backport these two (to 12, 11, 10 I presume)?

(Yes please. It's also given me something to poke at as I didn't log
the failure and only noticed when libasan wasn't installed...)

Thanks.


signature.asc
Description: Message signed with OpenPGP