Bruno Haible writes:
> I did:
>> Fix compilation errors with clang that masquerades as gcc 13.
>
> And here is a patch that fixes the clang warnings that appear to be caused
> by this version of __GNUC__.
>
> Previously I did not like the __GNUC_PREREQ (glibc) or _GL_GNUC_PREREQ
> (gnulib)
Bruno Haible writes:
> Sam James wrote:
>> It would happen on mandriva ...
>
> Mandriva is dead [1][2][3].
>
> Did you mean OpenMandriva Lx? Or Mageia? Or ROSA?
Sorry, bad old habits. OpenMandriva Lx is what you want:
*
https://github.com/OpenMandrivaAssociation/llvm/blob
Paul Eggert writes:
> On 2024-08-24 09:05, Bruno Haible wrote:
>> So, when we have a conditional that tests for GCC >= 4.7 or 10 or 14,
>> we don't need to exclude clang, because it's already excluded.
>
> Weird. I can no longer reproduce the problem with clang. So I undid
> that change. If the p
Collin Funk writes:
> Hi Bruno,
>
> Bruno Haible writes:
>
>> But this causes a compilation error on FreeBSD 14.0, which uses clang 16.
>> The problem is that my test case was incomplete and clang 16 fixes the
>> problem only in some circumstances, not in others.
>
> I wish they just standardize
Bruno Haible writes:
> Sam James wrote:
>> It's metadata in addition to the
>> commit summary (matching based on a title isn't easy, it's way easier if
>> someone says "here's the commits it's based on"; one can give multiple
>> such
Bruno Haible writes:
>> > easy to compare with the original commit and distinguish
>> > branch-only commits from backports.
>
> You can get limited insights by comparing the ChangeLogs of the
> master branch with a stable branch.
>
> But if what you want is a mechanically verifiable assertion of
Bruno Haible writes:
> Sam James wrote:
>> Could I propose that cherry-picks to the stable-XXX branches are done
>> with 'git cherry-pick -x'? This is often done in projects following a
>> gnulib-like model.
>>
>> git will append '(cherry picked
Hi,
Could I propose that cherry-picks to the stable-XXX branches are done
with 'git cherry-pick -x'? This is often done in projects following a
gnulib-like model.
git will append '(cherry picked from commit ...)' to the commit message
which makes it easy to compare with the original commit and di
Paul Eggert writes:
> On 2024-04-27 15:17, Sam James wrote:
>> Someone might read this and wrongly think that "GCC 14"
>> is broken.
>> I'd just omit 14 here.
>
> Good point as I think some of these bugs are also in GCC 13.x for some
> value of x.
Paul Eggert writes:
> * m4/nullptr.m4 (gl_NULLPTR): Work around GCC bug 114780.
> ---
> ChangeLog | 3 +++
> doc/gnulib.texi | 4
> m4/nullptr.m4 | 18 --
> 3 files changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/ChangeLog b/ChangeLog
> index b30238f934.
Paul Eggert writes:
> This patch is mostly taken from Autoconf master.
> * m4/largefile.m4 (AC_SYS_YEAR2038_RECOMMENDED):
> Undefine if unpatched Autoconf 2.72 or earlier, so that
> later code will redefine it.
> The remaining part of this patch is from Autoconf master.
> (_AC_SYS_YEAR2038_PROBE,
Bruno Haible writes:
> Our new committer, Collin Funk, asks:
>> Since I am not a GNU maintainer and have not
>> used Savannah, please send any other rules, documentation, etc. that
>> you think would be beneficial to read.
> [...]
Forgive the noise, but congratulations Collin!
> [...]
>
> Bruno
Bruno Haible writes:
> Hi Sam,
>
Hi Bruno,
>> * m4/wchar_h.m4: Remove duplicate serial number specification and increment
>> serial.
>
> Thanks, applied.
>
>> (It's easier for some work I'm doing if each serial maps to one checksum
>> of the macro, and serial #s are free.)
>
> We cannot guaran
Remove duplicate serial number specification (the latter of which is invalid)
and increment the serial to reflect this change.
(It's easier for some work I'm doing if each serial maps to one checksum
of the macro, and serial #s are free.)
* m4/wchar_h.m4: Remove duplicate serial number specificat
Bruno Haible writes:
> Nick Bowler wrote:
>> If I distribute a release package, what I have tested is exactly what is
>> in that package. If you start replacing different versions of m4 macros,
>> or use some distribution-patched autoconf/automake/libtool or whatever,
>> then this you have inval
Paul Eggert writes:
> I've not been a fan of those .m4 serial numbers, which may help to
> explain why so many .m4 files lack them. Although I still have doubts
> whether they're worth the trouble, perhaps it'd help if we added a
> file m4/.dir-locals.el (or something similar) that would cause Em
Bruno Haible writes:
> Sam James wrote:
>> For reasons once might be able to guess, I'm currently playing with
>> "known" M4 macros vs unseen serials and such.
>>
>> At the moment, my tool uses the format described at
>> https://www.gnu.org
Hi all,
For reasons once might be able to guess, I'm currently playing with
"known" M4 macros vs unseen serials and such.
At the moment, my tool uses the format described at
https://www.gnu.org/software/automake/manual/html_node/Serials.html.
My reading of it implies that the use in e.g. m4/buil
Bruno Haible writes:
> Sam James wrote:
>> > I see... you are building a cache that will become invalid when either
>> > - the bootstrap.conf changes, or
>> > - there is a change in gnulib in one of the request modules (in the
>> > module descri
Bruno Haible writes:
> Simon Josefsson wrote:
>> I now
>> remember that something like this was discussed before:
>>
>> https://git.savannah.gnu.org/cgit/libidn.git/commit/?id=9ae53e866a6fafa56db26d184ccae9c39dae7446
>> https://lists.gnu.org/archive/html/bug-gnulib/2021-05/msg00077.html
>
> I
Bruno Haible writes:
> Sam James wrote:
>> > It's good if you have the time to test not-yet-released compiler versions.
>> > I don't have that time, and therefore will prefer to wait until the
>> > clang release is out.
>>
>> OK. You've
Bruno Haible writes:
> Sam James wrote:
>> it's still going to be an issue if (as
>> planned) Clang flips '-Wincompatible-pointer-types' to error out by
>> default unless they carve out an exception for qualifiers here.
>>
>> I'll advocate
Sam James writes:
> Bruno Haible writes:
>
>> Hi Sam,
>
> Hi Bruno,
>
>>
>>> The configure test in gl_FUNC_FREXP_WORKS within m4/frexp.m4 triggers
>>> a Clang warning/error when Clang is passed
>>> -Werror=incompatible-pointer-types.
Bruno Haible writes:
> Hi Sam,
Hi Bruno,
>
>> The configure test in gl_FUNC_FREXP_WORKS within m4/frexp.m4 triggers
>> a Clang warning/error when Clang is passed
>> -Werror=incompatible-pointer-types.
>
> Gnulib does not support CC or CPPFLAGS or CFLAGS values with -Werror at
> configure time
Hi,
The configure test in gl_FUNC_FREXP_WORKS within m4/frexp.m4 triggers
a Clang warning/error when Clang is passed
-Werror=incompatible-pointer-types.
This _isn't_ an issue with GCC 14, as it doesn't consider the lost
const to be a problem, like so:
/tmp/foo.c: In function ‘main’:
/tmp/foo.c:5
Gavin Smith writes:
> On Sun, Nov 12, 2023 at 12:41:58PM +0100, John Paul Adrian Glaubitz wrote:
>
>> > diff tree.c.old tree.c -u
>> > --- tree.c.old 2023-11-04 16:15:13.632755680 +
>> > +++ tree.c 2023-11-04 16:16:36.211072521 +
>> > @@ -43,7 +43,10 @@
>> >if (obs_element_fir
Bruno Haible writes:
> Sam James wrote:
>> I don't think this applies to gnulib, but it feels relevant enough for
>> me to mention it: for packages with their own allocator where they
>> retain a pool, it may be worth adding ASAN attributes/hooks.
>>
>>
Bruno Haible writes:
> I was impressed by the fact that CHERI detected the multithread-safety
> bug of gnulib's use of rand() in the test suite.
>
> Now I'd like to try CHERI on packages like gettext, and see whether
> it finds bugs that neither valgrind nor the gcc bounds-checking options
> ca
Hello,
Forwarding a downstream report at https://bugs.gentoo.org/913368
of coreutils-9.4 failing to build with openssl-1.1.x:
"""
x86_64-pc-linux-gnu-gcc -I. -I./lib -DHASH_ALGO_BLAKE2=1 -DHAVE_CONFIG_H
-Ilib -I./lib -Isrc -I./src-O2 -march=x86-64 -pipe -pipe
-frecord-gcc-switches -fno-dia
Paul Eggert writes:
> * m4/manywarnings.m4 (gl_MANYWARN_ALL_GCC): Omit -fno-common
> in GCC 10 and later, as it is the default there.
I think this is fine, but I'd note that (to my surprise),
nixpkgs inverted this default for a while.
But I don't think that changes what you should do here.
s
Bruno Haible writes:
> Paul Eggert wrote:
>> > How about a middle ground between the two macros? A macro, say
>> > AC_SYS_YEAR2038_UNLESS_OPT_OUT (*), that
>> >- like AC_SYS_YEAR2038, has the option --disable-year2038,
>> >- like AC_SYS_YEAR2038_REQUIRED, fails if a large 'time_t' is
>>
Bruno Haible writes:
> Hi Sam,
Hi Bruno,
>
>> The test-pthread-cond test fails for me.
>>
>> gnulib-tests/test-pthread-cond.log doesn't have much detail:
>> ```
>> Starting test_pthread_cond_wait ... OK
>> Starting test_pthread_cond_timedwait ...FAIL test-pthread-cond (exit
>> status: 134)
>>
The test-pthread-cond test fails for me.
gnulib-tests/test-pthread-cond.log doesn't have much detail:
```
Starting test_pthread_cond_wait ... OK
Starting test_pthread_cond_timedwait ...FAIL test-pthread-cond (exit
status: 134)
```
Access to the machine is available if needed.
best,
sam
signat
> On 7 Feb 2023, at 12:06, Bruno Haible wrote:
>
> Thanks Paul, for reviewing what I wrote.
>
> Paul Eggert wrote:
>>> * We should stop compiling with -Wstrict-prototypes and instead (not
>>> always,
>>> but frequently enough) compile with the '-std=gnu23' option. Clang
>>> currentl
> On 4 Feb 2023, at 22:03, Paul Eggert wrote:
>
> On 2023-02-04 12:23, Sam James wrote:
>> I guess it's hard for me to say given I don't know what options allowed it
>> to be reproduced and I couldn't hit it.
>> I assumed it must have been -Wstri
> On 4 Feb 2023, at 20:20, Paul Eggert wrote:
>
> On 2023-02-04 11:53, Sam James wrote:
>> I'd consider using #pragma GCC ... to suppress -Wuse-after-free
>> for the "problematic" lines instead. It'd avoid the risk of either
>> optimisations o
> On 4 Feb 2023, at 18:46, Paul Eggert wrote:
>
> I manually inspected fts.c to look for violations of the C standard that
> might draw GCC's attention, and installed the attached patches into Gnulib.
> As you can see, they don't fix the technical violations of the C standard.
> However, I h
> On 3 Feb 2023, at 22:11, Paul Eggert wrote:
>
> On 2023-02-03 12:24, Peter Frazier wrote:
>> dangling pointers & gcc 13.1
>> problem with:
>> coreutils/gnulib, fts.c
>> compilation failure:
>> -Werror=use-after-free error
>> approach to resolution (thus far):
>> post free of vars, I set the v
> On 20 Jan 2023, at 03:40, Paul Eggert wrote:
>
> On 1/19/23 13:30, Sam James wrote:
>> Right, I just meant that we don't tend to care about quieting warnings with
>> older compilers,
>> and it's not useful from a static analysis perspective here either
> On 19 Jan 2023, at 21:20, Paul Eggert wrote:
>
> On 1/19/23 12:44, Sam James wrote:
>> _Noreturn is pretty much just an optimisation (and I'm not convinced that
>> it's _needed_ in a lot of cases, rather just a useful hint).
>
> _Noreturn is not just
> On 19 Jan 2023, at 04:17, Paul Eggert wrote:
>
> The problem we found in Gawk was that this sort of function call:
>
>(b ? f : g) (x)
>
> is mishandled by Clang < 16 when one function is _Noreturn and the other
> isn't, in that Clang mistakenly treats the call as if both functions are
Hi all,
Over on bug-gawk, we ended up finding that Clang was miscompiling certain
expressions involving _Noreturn. This is fixed in Clang's git repo but not
in any released version. It should be in 16.0.
Paul suggested [0] that gnulib ought to #define _Noreturn to blank
for known-broken Clang ver
> On 5 Jan 2023, at 23:06, Arsen Arsenović wrote:
>
> Hi,
>
> Paul Eggert writes:
>
>> This is a serious bug in Clang: it generates incorrect machine code.
>>
>> The code that Clang generates for the following (gawk/support/dfa.c lines
>> 1141-1143):
>>
>>((dfa->syntax.dfaopts & DFA_CO
> On 3 Jan 2023, at 02:14, Sam James wrote:
>
>
>
>> On 2 Jan 2023, at 06:10, Paul Eggert wrote:
>>
>> This is a serious bug in Clang: it generates incorrect machine code.
>>
>> [snip]
>>
>> My guess is that Clang got confuse
> On 2 Jan 2023, at 06:10, Paul Eggert wrote:
>
> This is a serious bug in Clang: it generates incorrect machine code.
>
> [snip]
>
> My guess is that Clang got confused because dfaerror is declared _Noreturn,
> so Clang mistakenly assumed that dfawarn is also _Noreturn, which it is not.
>
Hi,
Compiling texinfo 7.0.1 with CFLAGS="-O2 -flto -Werror=lto-type-mismatch"
results
in the following:
```
make[3]: Entering directory
'/var/tmp/portage/sys-apps/texinfo-7.0.1/work/texinfo-7.0.1/install-info'
x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../gnulib/lib
-I../gnulib/li
> On 25 Nov 2022, at 22:25, Bruno Haible wrote:
>
> Minsoo Choo wrote:
>> sprintf is deprecated on macOS. Silence this warning by silencing
>> -Wdeprecated-declartions.
>
> I don't get a warning by compiling the 'vasnprintf-posix' module
> on macOS 12.6, even with -Wall -Wdeprecated-declaratio
> On 16 Nov 2022, at 15:27, Richard Biener wrote:
>
> On Wed, Nov 16, 2022 at 4:02 PM Michael Matz via Gcc wrote:
>>
>> Hey,
>>
>> On Wed, 16 Nov 2022, Alexander Monakov wrote:
>>
The idea is so obvious that I'm probably missing something, why autoconf
can't use that idiom instead
> On 15 Nov 2022, at 13:30, Zack Weinberg wrote:
>
> On Tue, Nov 15, 2022, at 12:03 AM, Sam James wrote:
>>> On 13 Nov 2022, at 00:43, Paul Eggert wrote:
>>>
>>> Although there will be problems with people who run "./configure
>>> CFL
> On 12 Nov 2022, at 21:31, Paul Eggert wrote:
>
> On 2022-11-12 12:23, Wookey wrote:
>> we can't just have everyone who enabled LFS sometime in the
>> last 20 years suddenly being forced into the time_t change (can we?)
>
> We've done it in the past.
>
> AC_SYS_LARGEFILE originally was in Gn
> 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 m
> On 12 Nov 2022, at 02:20, Zack Weinberg via Libc-alpha
> wrote:
>
> Sam James writes:
>>> On 11 Nov 2022, at 09:19, Florian Weimer wrote:
>>> We need to support legacy binaries on i386. Few libraries are
>>> explicitly dual-ABI. Whether it's
> On 11 Nov 2022, at 09:19, Florian Weimer wrote:
>
> * Sam James:
>
>> In Gentoo, we've been planning out what we should do for time64 on
>> glibc [0] and concluded that we need some support in glibc for a newer
>> option. I'll outline why below.
&g
> On 10 Nov 2022, at 17:16, Zack Weinberg wrote:
>
> I’m the closest thing Autoconf has to a lead maintainer at present.
>
> It’s come to my attention (via https://lwn.net/Articles/913505/ and
> https://fedoraproject.org/wiki/Changes/PortingToModernC) that GCC and
> Clang both plan to disable
> On 25 Aug 2022, at 15:53, dmitrii.pasech...@cs.ox.ac.uk wrote:
>
> On Thu, Feb 08, 2018 at 11:43:08AM +0100, Bruno Haible wrote:
>> Wesley Viana wrote:
>>> So I was wondering how to contribute by "packing" gnulib into a brew
>>> formula.
>>
>> Packaging gnulib through a packaging system (such
> On 3 Feb 2021, at 03:45, Sam James wrote:
> [snip]
>> What's the result of
>> grep LIBCSTACK config.status
>> ? I.e. is GNU libsigsegv in use? And if yes, which version?
>
> # grep LIBCSTACK config.status
> S["LTLIBCSTACK"]=""
>
Hi,
> On 3 Feb 2021, at 03:23, Bruno Haible wrote:
>
> Hi,
>
Hey, thanks for the quick reply.
> What's the result of
> grep LIBCSTACK config.status
> ? I.e. is GNU libsigsegv in use? And if yes, which version?
# grep LIBCSTACK config.status
S["LTLIBCSTACK"]=""
S["LIBCSTACK"]=""
So no, I th
Hi,
This issue was noticed through grep 3.5 and 3.6’s stack-overflow test failing
[0] on SPARC on Gentoo GNU/Linux.
Following Paul Eggert’s instructions in that bug to test gnulib’s c-stack
component, I had the following
in /gltests/test-suite.log:
"FAIL: test-c-stack.sh
=
58 matches
Mail list logo
