On 19/05/2023 17:39, Bruno Haible wrote:
Pádraig Brady wrote:
I'm going to keep this one.
...
I've lost many hours to analyzing false positives from this one ...
and I've never found a real issue identified by this warning.
But can you please remove the line
# FP wth -O0 in nstrftime.c w/gc
Pádraig Brady wrote:
> I'm going to keep this one.
> ...
> I've lost many hours to analyzing false positives from this one ...
> and I've never found a real issue identified by this warning.
But can you please remove the line
# FP wth -O0 in nstrftime.c w/gcc 12, and 13 at least
since we now hav
On 18/05/2023 22:27, Paul Eggert wrote:
Let's revert the "avoid incorrect -Wmaybe-uninitialized warnings" patch.
--enable-gcc-warnings is designed for the default gcc -O2, and we
shouldn't dumb down our source code for lesser platforms like "gcc -O0",
or clang, or whatever.
OK I'll revert.
I d
On 18/05/2023 22:43, Paul Eggert wrote:
--- a/configure.ac
+++ b/configure.ac
@@ -261,6 +261,11 @@ if test $gl_gcc_warnings != no; then
# FP in careadlinkat.c w/gcc 10.0.1 20200205
gl_WARN_ADD([-Wno-return-local-addr])
+ # FIXME: remove this line when gcc improves
+ # https://gcc.gn
Hey everyone,
Thanks for coming back to this.
As I said, I'm primarily not a fan of having different code paths depending on
build type; that makes debugging harder than necessary.
Just a remark, in theory, you can have the cake and eat it, but afterwards your
plate will be riddled with the cr
On 5/18/23 14:50, Bruno Haible wrote:
But when "gcc -Wall" reports 10 warnings to me, and I don't notice
that one of them is an actual bug because I mentally discard all of
them
If you're using -O0, then in my experience it's a mistake to also use
--enable-gcc-warnings, as the combination gene
Paul Eggert wrote:
> The goal here is software reliability not pacifying compilers
But when "gcc -Wall" reports 10 warnings to me, and I don't notice
that one of them is an actual bug because I mentally discard all of
them "oh these new warnings must all be false positives by gcc",
there is someth
--- a/configure.ac
+++ b/configure.ac
@@ -261,6 +261,11 @@ if test $gl_gcc_warnings != no; then
# FP in careadlinkat.c w/gcc 10.0.1 20200205
gl_WARN_ADD([-Wno-return-local-addr])
+ # FIXME: remove this line when gcc improves
+ # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
+ # FP
To silence these warnings:
* -O0 only:
../../gllib/nstrftime.c:148:31: warning: 'memset' specified size
18446744073709551615 exceeds maximum object size 9223372036854775807
[-Wstringop-overflow=]
../../gllib/nstrftime.c:147:32: warning: 'memset' specified size
18446744073709551615 exceeds ma
In order to silence these warnings:
> * -O1, -O2, -O3, -Os only:
> ../../gllib/vasnprintf.c:1392:10: warning: 'e' may be used uninitialized
> [-Wmaybe-uninitialized]
> ../../gllib/vasnprintf.c:1410:10: warning: 'e' may be used uninitialized
> [-Wmaybe-uninitialized]
>
> * -Og only:
> ../../glli
Let's revert the "avoid incorrect -Wmaybe-uninitialized warnings" patch.
--enable-gcc-warnings is designed for the default gcc -O2, and we
shouldn't dumb down our source code for lesser platforms like "gcc -O0",
or clang, or whatever.
For example, this patch:
- int dest_desc;
- int dest_e
[Dropping coreutils from CC.]
Pádraig Brady wrote:
> Actually different -Wmaybe-initialized warnings can trigger at various
> optimization levels.
That's an interesting observation. Indeed, compiling a testdir of all of gnulib
at various optimization levels with gcc 13.1.0, through commands like
On 14/03/2023 16:50, Pádraig Brady wrote:
On 14/03/2023 13:55, Marcus Müller wrote:
Dear Gnulib community,
On Linux, x86_64, Fedora 37, ran, on today's coreutils' HEAD (e68b15), which
submodule-includes gnulib f17d3977:
CFLAGS=-Wno-deprecated-declarations ./configure
(as that CFLAGS is neces
> The goal should not be to pacify compilers' false alarms. The goal should be
> to have code that works correctly, is easy to understand, is efficient, etc.
In my personal code, when gcc complains about an uninitialized variable, even
if the code is correct, I usually either add an initializati
Hi Bruno,
On 16.03.23 04:46, Bruno Haible wrote:
Apparently Paul and you have different ways of reading code, which
leads to different measures of "readability". You two could keep
contradicting each other eternally; that's not fruitful.
I don't intend to do that :) Paul seems to be the more exp
Hey Paul,
I think we're in agreement, even though I've been in the situation that the compiler
warning me about unitialized variable usage has saved me a lot of headache – and maybe
that's why I'm more sympathetic to making the compiler happy in such isolated circumstances.
We both would like t
Hi Marcus,
Please try to understand Paul's arguments.
> Sorry to respectfully contradict you here: introducing a macro really
> doesn't do readability and immediate clarity of effect any better than
> a commented zero-initialization.
Apparently Paul and you have different ways of reading code,
On 3/15/23 16:03, Marcus Müller wrote:
introducing a macro really doesn't do readability
I don't want the macro either. Let's just leave the code alone.
I consider code paths that intentionally differ between debug and release builds
There's no need for that. Debug with the same options you
Hi Paul,
Sorry to respectfully contradict you here: introducing a macro really doesn't
do readability and immediate clarity of effect any better than a commented
zero-initialization.
I also disagree with your approach being less of a submission to the false (or
over-arching) compiler warnings
On 3/15/23 02:41, Marcus Müller wrote:
If my compiler doesn't optimize it away, well, then I have caused very
little overhead.
It's not really a question of overhead. Unecessary initializations make
code harder to understand. Polluting code with unnecessary
initializations together with comm
Hi Paul,
Uff, being a newb to this community, I feel really bad about giving my 2ct to roughly the
first thing I read on the mailing list, but:
Let's not do what GNU emacs does.
Having different code when linting and not linting makes bugs that only happen in
non-debug/lint builds impossible
On 3/14/23 09:50, Pádraig Brady wrote:
The attached also addresses -Wmaybe-initialized warnings in coreutils
that show up at lower optimization levels.
Let's not make that sort of change, please. It makes the code harder to
read and analyze, because I look at the code and wonder, "why is this
Hi Pádraig,
ah, this literally came in as I sent my reply to Bruno (and of course mistyped his name;
sorry!); indeed, that makes "sense" (as far as sense and compiler bugs go well together),
less optimization means fewer stages of constant folding etc; however, it's surprising
that GCC is *tha
Hi Bruna,
thanks for answering,
On 14.03.23 17:41, Bruno Haible wrote:
The build only fails because coreutils' configure.ac turns warnings into
errors by default in some situation.
Obviously, I agree with this on the deprecated functionality warning, but the string
method argument overflow w
Pádraig Brady wrote:
>return cnt == digest_bin_bytes;
> }
>
> +# pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
> static bool
> digest_check (char const *checkfile_name)
> {
Note that this pragma produces a warning with GCC versions < 4.7:
GCC 4.6.4:
foo.c:1:10: warning: unknown
On 14/03/2023 13:55, Marcus Müller wrote:
Dear Gnulib community,
On Linux, x86_64, Fedora 37, ran, on today's coreutils' HEAD (e68b15), which
submodule-includes gnulib f17d3977:
CFLAGS=-Wno-deprecated-declarations ./configure
(as that CFLAGS is necessary, otherwise sha will fail to build due
Hi,
Marcus Müller wrote:
> However, building coreutils fails in gnulib
The build only fails because coreutils' configure.ac turns warnings into
errors by default in some situation. Use the configure option
--disable-gcc-warnings
or
--enable-gcc-warnings=no
to allow warnings.
> and that does
27 matches
Mail list logo
