Re: GCC Multi-Threading Ideas

[Eric Gallager]

On 1/24/20, Richard Earnshaw (lists)  wrote:
> On 24/01/2020 10:27, Jonathan Wakely wrote:
>> On Fri, 24 Jan 2020 at 03:39, Nicholas Krause 
>> wrote:
>>> Sorry for the second message Allan but make -j does not scale well
>>> beyond 4 or
>>> 8 threads and that's considering a 4 core or 8 machine. The problem has
>>> to
>>> do with large build machines with CPUs with more cores than this or as
>>> is becoming
>>> more common on mainstream systems.
>>
>> And make scales well beyond 8 processes (not threads) on such machines.
>>
>
> The problem isn't make, per se, or even gcc.  It's the build system as a
> whole.
>
> On a highly multi-core machine, gcc itself hits the bottle-neck called
> configure.  That's serial, run *many* times (especially when there are
> many multilibs) and dominates build time.
>
> On high multi-core machines, gcc's 15-minute system load gets no-where
> near to the number of threads on the machine because of this.
>
> R.
>

It would be great if we could get some new autotools releases some
time to help with this; autoconf in particular hasn't had an update in
several years now AFAIK. While automake has had updates more recently
than autoconf, they've mostly just been to the automake part itself
and not to the aclocal program that comes with it, and aclocal in
particular is another bottleneck for people who regenerate the build
system files (although it could just be that way in my case because I
have so many m4 macro files installed on my system for it to search
thru for macros every time...)

Re: sprintf warning on overlapping output

[Eric Gallager]

On 9/25/16, Bernd Edlinger  wrote:
> Hi Martin,
>
> in the past I have seen (and fixed) code like
>
> sprintf(buf, "%s %d", buf, x);
>
> that may possibly work by chance, but usually
> produces undefined results.
>
> Do you see a way to enhance the warning for cases
> where the output buffer overlaps an input buffer?
>
>
>
> Thanks
> Bernd.
>


I was testing Prathamesh's -Wrestrict patch, and it caught a few cases
like that:
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00027.html

Eric

Lint-style comments, more generally

[Eric Gallager]

Seeing how long the thread on gcc-patches on what comments
-Wimplicit-fallthrough should recognize has gotten, I thought it might
be a good idea to start a discussion on lint-style comments more
generally. Instead of just limiting the use of lint-style comments to
-Wimplicit-fallthrough, why not split the recognition of it off into a
separate switch (-flint-style-comments or -Wlint-style-comments) that
can be taken advantage of by other warnings? Here are some examples
I've seen in actual code:
/*NOTREACHED*/ to tell the compiler that code is unreachable; could be
useful if the -Wunreachable-code warning were to be revived. I
suggested making this equivalent to __builtin_unreachable() on a bug
on bugzilla, but apparently that also affects codegen, so instead of
making the two exactly equivalent, how about if the comment just
silences the warning and leaves the codegen the same?
/*ARGSUSED*/ which is pretty similar to __attribute__((unused)) or
#pragma unused; could also be used to silence -Wunused-parameter
/*VARARGS*/ for functions with a variable number of arguments; I'm not
aware of any GCC warnings that this one would currently silence.

Further links I found by Googling:
http://csweb.cs.wfu.edu/~torgerse/Kokua/More_SGI/007-0701-150/sgi_html/apb.html
(lists some other ones I hadn't seen)
http://www.splint.org/manual/manual.html#annotations (scroll down to
the "Traditional Lint Comments" section)
https://docs.freebsd.org/info/cpp/cpp.info.Invocation.html (The
FreeBSD cpp seems to have a '-lint' flag; apparently their GCC
supports a #pragma lint)
http://www.fnal.gov/docs/products/gcc/v2_95_2/cpp.info,.Invocation.html
(seems to be the same as the previous, but with some further
commentary about option naming)

Anyways, what do people think?

Re: GCC 7.0.0 Status Report (2016-10-21)

[Eric Gallager]

On Fri, Oct 21, 2016 at 9:46 AM, Jakub Jelinek  wrote:
> Status
> ==
>
> Trunk which will eventually become GCC 7 is still in Stage 1 but its
> end is near and we are planning to transition into Stage 3 starting
> Nov 13th end of day time zone of your choice.
>
> This means it is time to get things you want to have in GCC 7 finalized
> and reviewed.  As usual there may be exceptions to late reviewed features
> but don't count on that.  Likewise target specific features can sneak in
> during Stage 3 if maintainers ok them.
>
>
> Quality Data
> 
>
> Priority  #   Change from last report
> ---   ---
> P14+   1
> P2  117+  27
> P3  192+ 174
> P4  109+   9
> P5   29-   1
> ---   ---
> Total P1-P3 313+ 202
> Total   451+ 210
>
>
> Previous Report
> ===
>
> https://gcc.gnu.org/ml/gcc/2016-04/msg00106.html

Are we allowed to ping other people's patches? If so, I'd like to ping
these, which I don't think have gone in yet:

- https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00612.html Adds
-Wshadow-local and -Wshadow-compatible-local
- https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01545.html Adds -Wrestrict
- Um... there were a few others that I'll have to check once I get back home

Thanks,
Eric

Re: History of GCC

[Eric Gallager]

On 10/26/16, Ian Lance Taylor  wrote:
> On Wed, Oct 26, 2016 at 9:31 AM, Will Hawkins  wrote:
>>
>> Thank you for your response! I don't think that there has to be
>> controversy to be interesting. Obviously that split/reunification was
>> important, but I think that there might even be some value in
>> documenting the minutia of the project's growth. In other words, what
>> was the process for incorporating each new version of the C++
>> standard? Who and why did GCC start a frontend for X language? Things
>> like that.
>
> It is easier to answer specific questions.
>
> There have always been GCC developers that have tracked the evolution
> of C++.  The first C++ standard was of course in 1998, at which point
> the language was over 10 years old, so there were a lot of C++
> language changes before then.  GCC has generally acquired new language
> features as they were being adopted into the standard, usually
> controlled by options like the current -std=c++1z.  This of course
> means that the new features have shifted as the standard has shifted,
> but as far as I know that hasn't happened too often.
>
> GCC started as a C compiler.  The C++ frontend was started by Michael
> Tiemann around 1987 or so.  It started as a patch and was later
> incorporated into the mainline.
>
> The Objective C frontend was started at NeXT.  They originally
> intended to keep it proprietary, but when they understood that the GPL
> made that impossible they contributed it back.  I forget when the
> Objective C++ frontend came in.


The Objective C++ frontend was contribute by Apple. The earliest
proposal I can find for adding it was in 2001 for GCC 3.x:
https://gcc.gnu.org/ml/gcc/2001-11/msg00609.html
However, it didn't actually make it in to the FSF version until 4.1:
https://gcc.gnu.org/ml/gcc-patches/2005-05/msg01781.html
https://gcc.gnu.org/ml/gcc-patches/2005-12/msg01812.html
Personally, I think one of the interesting stories of GCC history is
how Apple used to be really involved in GCC development until 2007, at
which point the GPL3 and iPhone came out, and Apple abandoned GCC for
llvm/clang. If you read through the mailing list archives on
gcc.gnu.org, you can find all sorts of emails from people with "at
apple dot com" email addresses in the early 2000s, until they just
sort of stopped later that decade. Even llvm/clang was originally just
another branch of gcc, and Chris Lattner was even going to contribute
it and keep it part of gcc, but then he never got around to getting
his copyright assignment paperwork filed, and then Apple turned it
into a separate project:
https://gcc.gnu.org/ml/gcc/2005-11/msg00888.html
https://gcc.gnu.org/ml/gcc/2006-03/msg00706.html


>
> Cygnus Support developed the Chill and, later, Java frontends.  The
> Chill frontend was removed later, and in fact the Java frontend was
> removed just recently.
>
> As I recall Fortran was a hobbyist project that eventually made it in.
> There were two competing forks, I think.  I don't remember too much
> about that off the top of my head.
>
> The Ada frontend was developed at AdaCore.
>
> The Go frontend was written by me, mostly because I like Go and I've
> been working on GCC for a long time.  I work at Google, and Go was
> developed at Google, but there wouldn't be a GCC Go frontend if I
> hadn't decided to write one.
>
> There is a Modula frontend that is always close to getting in.  I
> think there is a Pascal frontend out there too, somewhere.  And a D
> frontend.
>
> Ian
>

Re: warning: conversion from ‘int’ to ‘char’ may change value

[Eric Gallager]

On 9/20/18, Martin Sebor  wrote:
> On 09/20/2018 08:08 AM, Vincent Lefevre wrote:
>> On 2018-09-17 10:03:48 -0600, Martin Sebor wrote:
>>> On 09/17/2018 06:00 AM, Umesh Kalappa wrote:
 Hi All,

 When we try to compile the below case from trunk gcc we get the below
 warning (-Wconversion) i.e

 void start(void) {
  char n = 1;
  char n1 = 0x01;
  n &=  ~n1;
 }

 $xgcc -S  warn.c -nostdinc -Wconversion
  warning: conversion from ‘int’ to ‘char’ may change value
 [-Wconversion]
   n &=  ~n1;
>> [...]
>>> It looks like a bug to me.
>>>
>>> Declaring n1 const avoids the warning at -O2 but in C but not
>>> at -O0.
>>
>> Perhaps at some optimization level, GCC determines that the
>> expression is safe (thus no longer emits the warning), i.e.
>> that n & ~n1 is necessarily representable in a char.
>>
>>> That doesn't seem quite right -- GCC determines the
>>> type of the bitwise AND expression to be different between
>>> the optimization levels.
>>
>> No, the type of this AND expression is always int. The question
>> is whether this int is necessarily representable in a char.
>>
>>> In C++, declaring n1 const avoids the warning regardless of
>>> optimization levels.
>>
>> If the constant propagation is done at -O0, this could explain
>> the behavior.
>>
>> Or do you mean that GCC remembers the type the data come from,
>> i.e. assuming char is signed, if n1 is of type char, then ~n1
>> is necessarily representable in a char, thus can be regarded
>> as of being of type char in its analysis?
>
> What I'm saying is that the type that determines whether or
> not to issue a warning in this case is computed in
> the shorten_binary_op() function.  The function is passed
> the operands of the &= expression and returns the expression's
> "new" type.  When n1's value is known (i.e., when it's const
> and with -O2) and fits in char, and when n's type is the  char
> (or under a bunch of other conditions), the function returns
> the type char.  Comments in the code indicate it's
> an optimization.  That may be fine as far as code correctness
> goes but it doesn't seem quite right or robust to me because
> it makes the warning appear inconsistent, both between
> languages, and in C, between optimization levels.  Delaying
> the warning until a later stage (e.g., until folding as Jason
> suggested) would make it more consistent.  It wouldn't solve
> all problems (e.g., it would still be prone to false positives
> in unreachable code), but solving those by delaying it even
> further could easily lead to others.
>
> Martin
>

I think this is bug 40752: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40752
(or some of the bugs related to it, or marked as duplicates of it)

Re: GCC 6 branch is now closed

[Eric Gallager]

On 10/26/18, Jakub Jelinek  wrote:
> After the GCC 6.5 release the GCC 6 branch is now closed.  Please
> refrain from committing to it from now on.
>
> Thanks
>   Jakub
>

So, since it's the last branch with java in it, can we go and finally
remove the last vestiges of java from the gcc website? Specifically:

- On https://gcc.gnu.org/lists.html move "java" and "java-patches"
from "Open lists" to "Historical lists" (and likewise with "java-prs"
and "java-cvs" in "Read only lists")
- In Bugzilla, prevent any new bugs with java-related components from
being opened for the GCC product
- Also in Bugzilla, does it really make sense to have classpath
continue to share a bugzilla with gcc now that the last gcc branch
with java has been closed? Seems like, if possible, it'd be better to
separate classpath out into its own bug database. That way the bug
creation process could be made one step shorter, since the "First, you
must pick a product on which to enter a bug" page would then no longer
be necessary, since classpath would no longer be a choice, so there'd
only be one product left (gcc).

Eric

Re: Regarding projects and begineer guide.

[Eric Gallager]

On 12/5/18, David Malcolm  wrote:
> On Wed, 2018-12-05 at 22:48 +0530, Durgesh Kumar wrote:
>> Dear sir/mam
>> I am durgesh kumar from ABES engineering collenge,ghaziabad,uttar
>> pradesh,india.
>>
>> I am currently in 2nd year of my graduation(Btech CSE )
>>
>> I want to contribute in some of your prestigious project. So i
>> request you
>> to please provide me some of your top priority project and a begineer
>> guide.
>>
>> I hope you will concern my request.
>
> I'd recommend starting with something small, in an area that interests
> you.  We're currently in feature freeze for gcc 9, so bugfixing is our
> main focus right now.

And we have many bugs that could use attention, too! For newcomers, I
would recommend checking bugs tagged with the "easyhack" keyword on
bugzilla:

https://gcc.gnu.org/wiki/EasyHacks

https://gcc.gnu.org/bugzilla/buglist.cgi?keywords=easyhack&list_id=223372&resolution=---

>
> FWIW, here's an unofficial beginner's guide I wrote to document my own
> experiences learning GCC:
>   https://dmalcolm.fedorapeople.org/gcc/newbies-guide/
>
> You might want to also look at this:
>   https://gcc.gnu.org/ml/gcc/2018-11/msg00184.html
>
> Hope this is helpful
> Dave
>
>

Re: GSoC Project Ideas

[Eric Gallager]

On 3/3/19, Patrick Palka  wrote:
> Hi everyone,
>
> I am very interested in working on GCC as part of GSoC this year.  A few
> years
> ago I was a somewhat active code contributor[1] and unfortunately my
> contributing waned once I went back to school, but I'm excited to
> potentially
> have the opportunity to work on GCC again this summer.  My contributions
> were
> mainly to the C++ frontend and to the middle end, and I've been thinking
> about
> potential projects in these areas of the compiler.  Here are some project
> ideas
> related to parts of the compiler that I've worked on in the past:
>
>   * Extend VRP to track unions of intervals
> (inspired by comment #2 of PR72443 [2])
>   Value ranges tracked by VRP currently are represented as an interval
> or
>   its complement: [a,b] and ~[a,b].  A natural extension of this is
>   to support unions of intervals, e.g. [a,b]U[c,d].  Such an extension
>   would make VRP more powerful and at the same time would subsume
>   anti-ranges, potentially making the code less complex overall.
>
>   * Make TREE_NO_WARNING more fine-grained
> (inspired by comment #7 of PR74762 [3])
>   TREE_NO_WARNING is currently used as a catch-all marker that inhibits
> all
>   warnings related to the marked expression.  The problem with this is
> that
>   if some warning routine sets the flag for its own purpose,
>   then that later may inhibit another unrelated warning from firing, see
> for
>   example PR74762.  Implementing a more fine-grained mechanism for
>   inhibiting particular warnings would eliminate such issues.
>
>   * Make -Wmaybe-uninitialized more robust
>   (Inspired by the recent thread to move -Wmaybe-uninitialized to
> -Wextra [4])
>   Right now the pass generates too many false-positives, and hopefully
> that
>   can be fixed somewhat.
>   I think a distinction could be made between the following two
> scenarios in
>   which a false-positive warning is emitted:
> 1. the pass incorrectly proves that there exists an execution path
> that
>results in VAR being used uninitialized due to a deficiency in
> the
>implementation, or
> 2. the pass gives up on exhaustively verifying that all execution
> paths
>use VAR initialized (e.g. because there are too many paths to
> check).
>The MAX_NUM_CHAINS, MAX_CHAIN_LEN, etc constants currently
> control
>when this happens.
>   I'd guess that a significant fraction of false-positives occur due to
> the
>   second case, so maybe it would be worthwhile to allow the user to
> suppress
>   warnings of this second type by specifying a warning level argument,
> e.g.
>   -Wmaybe-uninitialized=1|2.

Instead of adding numeric levels to -Wmaybe-uninitialized, I'd prefer
to have different named flags for finer granularity. For example,
clang has -Wsometimes-uninitialized and -Wconditional-uninitialized:
https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00225.html

>   Still, false-positives are generated in the first case too, see e.g.
>   PR61112.  These can be fixed by improving the pass to understand such
>   control flow.
>
>   * Bug fixing in the C++ frontend / general C++ frontend improvements
>   There are 100s of open PRs about the C++ frontend, and the goal here
>   would just be to resolve as many as one can over the summer.

You're missing a zero; that should be thousands, not hundreds... ;-)

>
> Would any of these ideas work as a GSoC project?
>
> Regards,
> Patrick Palka
>
> [1]: https://gcc.gnu.org/git/?p=gcc.git;a=search;s=ppalka;st=author
> [2]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72443#c2
> [3]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74762#c7
> [4]: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00020.html
>

Re: Warning for C Parameter Name Mismatch

[Eric Gallager]

On 3/8/19, David Brown  wrote:
> On 09/03/2019 00:06, Joseph Myers wrote:
>> On Fri, 8 Mar 2019, Joel Sherrill wrote:
>>
>>> Can gcc report when the parameter name in a C prototype
>>> does not match that used in the implementation?
>>>
>>> int f(int x);
>>>
>>> int f(int y) {...}
>>
>> I think this would be normal and expected - an installed header would use
>> a reserved-namespace name for the parameter while the implementation uses
>> a non-reserved name that's more convenient for use within the
>> implementation.  (Thus anything like this would only be useful if it can
>> know that it's e.g. OK to have __y and y as the names, and some code no
>> doubt uses other such conventions relating the two names.)
>>
>
> I can appreciate that a warning like this is not for everyone.  But /I/
> would like and use such a warning for my own code.
>
> The kind of headers which would specifically use reserved or otherwise
> unusual parameter names are things like library headers - and you will
> not be compiling the implementation source code, and thus won't get a
> mismatch.  A warning like this would be used with your own header/source
> combinations - where your implementation is #include'ing the unit's
> header as a way of checking that you've got the function name and
> parameter types correct.  This warning would add parameter names to the
> things that are checked.
>
>

How would it handle the case where the parameter name is missing
entirely from the prototype? I see a lot of header files with their
prototypes written like that.

e.g.

int f(int);

int f(int y) {...}

Re: [RFC] split of i386.c

[Eric Gallager]

On 3/12/19, Martin Liška  wrote:
> Hi.
>
> I've thinking about the file split about quite some time, mainly
> in context of PR84402. I would like to discuss if it's fine for
> maintainers of the target to make such split and into which logical
> components can the file be split?
>
> I'm suggesting something like:
> - option-related and attribute-related stuff (i386-options.c - as seen in
> patch)
> - built-in related functions
> - expansion/gen functions - still quite of lot of functions, would make
>   sense to split into:
>   - scalar
>   - vector
> - prologue/epilogue, GOT, PLT, symbol emission
> - misc extensions like STV, TLS, CET, retpolines, multiversioning, ..
> - helpers - commonly used functions, print_reg, ix86_print_operand, ..
>
> I am volunteering to make the split, hopefully early in the next stage1.
>
> Thoughts?
>
> Thanks,
> Martin
>

I'm not a maintainer, but just as an onlooker I highly support this
move; i386.c is way too long as it is. 7 pieces sounds like a good
number of new files to split it into, too.

Eric

Re: How to add %' into gfc_fatal_error

[Eric Gallager]

On 3/11/19, Martin Sebor  wrote:
> On 3/11/19 8:18 AM, Martin Liška wrote:
>> Hi.
>>
>> I would like to add %' into __gcc_gfc__ in order to handle:
>>
>> ./xgcc -B. /tmp/module.ii -Wformat -c
>> /home/marxin/Programming/gcc/gcc/fortran/module.c: In function ‘void
>> dump_module(const char*, int)’:
>> /home/marxin/Programming/gcc/gcc/fortran/module.c:6205:19: warning:
>> unknown conversion type character ‘'’ in format [-Wformat=]
>>   6205 |  gfc_fatal_error ("Can%'t delete module file %qs: %s", filename,
>>|   ^~~
>>
>> Can you please help me how to do that?
>
> gfc_fatal_error ("Cannot delete module file %qs: %s", filename,
>
> ;-)
>
> Seriously, I would avoid contractions in diagnostics, especially
> "can't."
>
> Martin
>

Not just in diagnostics but in general, I would argue.

Re: Warning for C Parameter Name Mismatch

[Eric Gallager]

On 3/8/19, Joel Sherrill  wrote:
> Hi
>
> This may be just an ignorant user question on my part.
>
> Can gcc report when the parameter name in a C prototype
> does not match that used in the implementation?
>
> int f(int x);
>
> int f(int y) {...}
>
> We try to fix every warning gcc reports but this is one that gcc
> doesn't report for us. It could be we need an extra -Wxxx but
> we end up spotting these with Doxygen.
>
> Anything we are missing?
>
> Thanks.
>
> --joel
>

I found bug 79022 which seems relevant to this conversation:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79022

Re: GSOC Proposal

[Eric Gallager]

On 3/29/19, nick  wrote:
>
>
> On 2019-03-29 10:28 a.m., nick wrote:
>>
>>
>> On 2019-03-29 5:08 a.m., Richard Biener wrote:
>>> On Thu, 28 Mar 2019, nick wrote:
>>>


 On 2019-03-28 4:59 a.m., Richard Biener wrote:
> On Wed, Mar 27, 2019 at 6:31 PM nick  wrote:
>>
>> Greetings All,
>>
>> I've already done most of the work required for signing up for GSoC
>> as of last year i.e. reading getting started, being signed up legally
>> for contributions.
>>
>> My only real concern would be the proposal which I started writing
>> here:
>> https://docs.google.com/document/d/1BKVeh62IpigsQYf_fJqkdu_js0EeGdKtXInkWZ-DtU0/edit?usp=sharing
>>
>> The biography and success section I'm fine with my bigger concern
>> would be the project and roadmap
>> section. The roadmap is there and I will go into more detail about it
>> in the projects section as
>> need be. Just wanted to known if the roadmap is detailed enough or can
>> I just write out a few
>> paragraphs discussing it in the Projects Section.
>
> I'm not sure I understand either the problem analysis nor the project
> goal parts.  What
> shared state with respect to garbage collection are you talking about?
>
> Richard.
>
 I just fixed it. Seems we were discussing RTL itself. I edited it to
 reflect those changes. Let me know if it's unclear or you would actually

 like me to discuss some changes that may occur in the RTL layer itself.


 I'm glad to be more exact if that's better but seems your confusion was

 just what layer we were touching.
>>>
>>> Let me just throw in some knowledge here.  The issue with RTL
>>> is that we currently can only have a single function in this
>>> intermediate language state since a function in RTL has some
>>> state in global variables that would differ if it were another
>>> function.  We can have multiple functions in GIMPLE intermediate
>>> language state since all such state is in a function-specific
>>> data structure (struct function).  The hard thing about moving
>>> all this "global" state of RTL into the same place is that
>>> there's global state in the various backends (and there's
>>> already a struct funtion 'machine' part for such state, so there's
>>> hope the issue isn't as big as it could be) and that some of
>>> the global state is big and only changes very rarely.
>>> That said, I'm not sure if anybody knows the full details here.
>>>
>>> So as far as I understand you'd like to tackle this as project
>>> with the goal to be able to have multiple functions in RTL
>>> state.
>>>
>>> That's laudable but IMHO also quite ambitious for a GSoC
>>> project.  It's also an area I am not very familiar with so
>>> I opt out of being a mentor for this project.
>>>
>> While I'm aware of three areas where the shared state is an issue
>> currently:
>> 1, Compiler's Proper
>> 2. The expand_functions
>> 3. RTL
>> 4.Garbage Collector
>>
>> Or maybe a project to be more
>> explicit about regions of the code that assume that the garbage-
>> collector can't run within them?[3] (since the GC is state that would
>> be shared by the threads).
>>
>> This is what we were discussing previously and I wrote my proposal for
>> that. You however seem confused about what parts of the garbage collector
>> would be touched. That's fine with me, however seems you want be to
>> be more exact about which part  is touched.
>>
>> My questions would be as it's changed back to the garbage collector
>> project:
>> https://docs.google.com/document/d/1BKVeh62IpigsQYf_fJqkdu_js0EeGdKtXInkWZ-DtU0/edit
>>
>> 1. Your confusion about which part of the garbage collector is touched
>> doesn't
>> really make sense s it's for the whole garbage collector as related to
>> shared
>> state?
>> 2. Injection was my code here in phase 3 for the callers of the new
>> functions or
>> macros, perhaps this is not needed as the work with the garbage collector
>> is enough?
>> 3. Am I not understanding this project as I thought I was in the proposal
>> I wrote?
>>
>> Seems your more confusing my wording probably so I'm going to suggest one
>> of
>> two things here:
>> a) I'm going to allow you to make comments with what's confusing you and
>> it needs that's the issue here more than anything else so I sent you
>> a link and please comment where you are having issues with this not
>> be clear for you:
>> Or maybe a project to be more
>> explicit about regions of the code that assume that the garbage-
>> collector can't run within them?[3] (since the GC is state that would
>> be shared by the threads).
>> as that's the actual project
>>
>> b) Just comment here about the wording that's an issue for you or
>> where you want more exact wording
>>
>> Sorry and hopefully this is helps you understand where I'm going,
>> Nick
>>
>>> Richard.
>>>
 Nick
>> Any other comments are welcome as well as I write it there,
>> Nick

Re: [RFC/RFA] Obsolete Cell Broadband Engine SPU targets

[Eric Gallager]

On 4/2/19, Ulrich Weigand  wrote:
> Hello,
>
> the spu-elf target in GCC supports generating code for the SPU processors
> of the Cell Broadband Engine; it has been part of upstream GCC since 2008.
>
> However, at this point I believe this target is no longer in use:
> - There is no supported Cell/B.E. hardware any more.

Wait, SPU includes the Playstation 3, right? I'm pretty sure there are
still plenty of PS3s in use out there... AFAIK my university (GWU) is
still running its PS3 supercomputer cluster... (I'd have to check to
make sure...)

> - There is no supported operating system supporting Cell/B.E. any more.
>
> I've still been running daily regression tests until now, but I'll be
> unable to continue to do so much longer since the systems I've been
> using for this will go away.
>
> Rather than leave SPU support untested/maintained, I'd therefore
> propose to declare all SPU targets obsolete in GCC 9 and remove
> the code with GCC 10.
>
> Any objections to this approach?
>
> Bye,
> Ulrich
>
>
> gcc/ChangeLog:
>
>   * config.gcc: Mark spu* targets as deprecated/obsolete.
>
> Index: gcc/config.gcc
> ===
> --- gcc/config.gcc(revision 270076)
> +++ gcc/config.gcc(working copy)
> @@ -248,6 +248,7 @@ md_file=
>  # Obsolete configurations.
>  case ${target} in
>*-*-solaris2.10*   \
> +  | spu*-*-* \
>| tile*-*-*\
>   )
>  if test "x$enable_obsolete" != xyes; then
> --
>   Dr. Ulrich Weigand
>   GNU/Linux compilers and toolchain
>   ulrich.weig...@de.ibm.com
>
>

Re: Iain Sandoe appointed Darwin co-maintainer

[Eric Gallager]

Congrats Iain on having your "de facto" maintainer status upgraded to
being official!

On 4/19/19, David Edelsohn  wrote:
>   I am pleased to announce that the GCC Steering Committee has
> appointed Iain Sandoe as Darwin co-maintainer.
>
>   Please join me in congratulating Iain on his new role.
> Iain, please update your listing in the MAINTAINERS file.
>
> Happy hacking!
> David
>
>

Re: About GSOC.

[Eric Gallager]

On 5/31/19, Nathan Sidwell  wrote:
> On 5/30/19 5:38 PM, Segher Boessenkool wrote:
>> On Thu, May 30, 2019 at 07:08:45PM +0200, Martin Jambor wrote:
>>> Interesting, I was also puzzled for a moment.  But notice that:
>>>
>>> int main ()
>>> {
>>>  _Float128 x = 18446744073709551617.5f128;
>>>  _Float128 y = __builtin_roundf128 (x);
>>> }
>>>
>>> behaves as expected... the difference is of course the suffix pegged to
>>> the literal constant (see
>>> https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Floating-Types.html).
>>>
>>> I would also expect GCC to use a larger type if a constant does not fit
>>> into a double, but apparently that does not happen.  I would have to
>>> check but it is probably the right behavior according to the standard.
>>
>> 6.4.4.2/4: "An unsuffixed floating constant has type double."  I don't
>> think your suggestion would be okay?
>
> Not only that, but
>
> 1) there isn't a literal suffix to mean 'double', so one couldn't
> override that extended type.

There's not a standard one, but there is 'D' or 'd' as a GNU
extension. The fact that it's nonstandard, though, is what causes some
projects to ignore -Wunsuffixed-float-constants:
https://lists.gnu.org/archive/html/bug-gzip/2011-11/msg00017.html

> 2) how do you define 'doesn't fit'?  decimal 0.1 has a recurring binary
> representation.  Should that become the longest floating point type?
>
> nathan
>
> --
> Nathan Sidwell
>

Re: Enabling Ctags Tree Wide for GCC

[Eric Gallager]

On 9/11/19, Nicholas Krause  wrote:
> Greetings,
>
> I was wondering what is the easiest way to allow source tree wide ctags.
> There doesn't
>
> seem to be a make x command for it nor any real documentation online and
> it would
>
> be nice to have.
>

ISTR this topic coming up 2 years ago:
https://gcc.gnu.org/ml/gcc/2017-09/msg00266.html

>
> Thanks,
>
> Nick
>
>

Re: Moving to C++11

[Eric Gallager]

On 9/26/19, Nicholas Krause  wrote:
> Greetings,
>
> I asked about moving to C/C++ 11 as it would make it easier to
>
> allow multithreading support due to having a memory model
>
> alongside other features. Jason Merill mentioned due to it
>
> being so common it may be a good  time to.
>
> Moving to git seems to be universally agree on so I'm opening the
> discussion
>
> for the same as related to C/C++11 migration and if possible opening
>
> a TODO similar to git if decided on.
>
> Please post your comments or ideas about the migration in response to this
>
> email,
>
> Nick
>
>

A good first step would be to flip the switch from -Wno-narrowing to
-Wnarrowing in the warning flags GCC uses when building, as C++11 has
stricter rules about narrowing conversions. This would be useful even
if we don't end up going to C++11 yet, as such narrowing conversions
are bad even in versions of the standard where they're allowed.

Re: GCC selftest improvements

[Eric Gallager]

On 10/25/19, Gabriel Dos Reis via gcc  wrote:
> [Andrew]
>
> | > GCC has some rather unique requirements, in that we support a great
> many
> | > build configurations, some of which are rather primitive - for example,
> | > requiring just C++98 with exceptions disabled, in that we want to be
> able to
> | be
> | > bootstrappable on relatively "ancient" configurations.
> | > IIRC auto-registration of tests requires that the build configuration
> have a
> | > sufficiently sane implementation of C++ - having globals with
> non-trivial
> | ctors
> | > tends to be problematic when dealing with early implementations of C++.
> |
> | Is C++98 the limit of what we can use in GCC? If so, that immediately
> | eliminates Catchv1 (C++03), Catch2 (C++11+) and GTest (C++11)
>
> C++98 was what Diego, Lawrence, Benjamin, Ian, and myself could agreed to
> back in 2011-2012 when C++11 got just out as a C++ standard, so we couldn't
> pick C++11 as we didn't have enough G++ out there to count on.
>
> I would expect the situation to have drastically changed - with very handy
> and popular features such as 'constexpr' (especially with the C++14
> relaxation), lambdas and range-for.
>
> Jason, Jonathan - is the situation on the terrain really that dire that
> C++11 (or C++14) isn't at all available for platforms that GCC is
> bootstrapped from?
>
> -- Gaby
>

Nicholas Krause was also wanting to move to C++11 recently:
https://gcc.gnu.org/ml/gcc/2019-10/msg00110.html (this month)
https://gcc.gnu.org/ml/gcc/2019-09/msg00228.html (last month)
As I said in that thread, I'd want to try just toggling -Wnarrowing
from off to on first before going full C++11. So, GCC 10 would be
C++98 + -Wnarrowing, and then GCC 11 could be full C++11. Plus then
the GCC version numbers would also line up with the version of C++
being used.

Eric

Re: GCC selftest improvements

[Eric Gallager]

On 10/31/19, Pedro Alves  wrote:
> On 10/26/19 11:46 PM, Eric Gallager wrote:
>
>> Nicholas Krause was also wanting to move to C++11 recently:
>> https://gcc.gnu.org/ml/gcc/2019-10/msg00110.html (this month)
>> https://gcc.gnu.org/ml/gcc/2019-09/msg00228.html (last month)
>> As I said in that thread, I'd want to try just toggling -Wnarrowing
>> from off to on first before going full C++11.
>
> Why?  GDB went the other way when it moved to C++11.  It switched
> to C++11, and for several months, used -Wno-narrowing to quiet
> the thousands of warnings.
>
> https://gcc.gnu.org/wiki/FAQ#Wnarrowing

Sorry, lost track of this conversation in the end-of-month mail
archive rollover... Uh, to be honest, I guess I don't really have a
rational reason for wanting to switch to -Wnarrowing first; it's
really more of an emotional/aesthetic desire I have on my part... Feel
free to do the switch in the other order if that turns out to be
easier. Anyways, from the rest of the discussion, it looks like this
will be waiting for GCC 11 anyways, so I'm already getting my "hold
off 1 release" wish, so I guess I don't really care as much about the
-Wnarrowing part as much any longer...

Eric

>
>> So, GCC 10 would be
>> C++98 + -Wnarrowing, and then GCC 11 could be full C++11. Plus then
>> the GCC version numbers would also line up with the version of C++
>> being used.
>
> Thanks,
> Pedro Alves
>

Re: [RFC] Characters per line: from punch card (80) to line printer (132)

[Eric Gallager]

On 12/5/19, Andrew Stubbs  wrote:
> On 05/12/2019 16:17, Joseph Myers wrote:
>> Longer lines mean less space for multiple terminal / editor windows
>> side-by-side to look at different pieces of code.  I don't think that's
>> an
>> improvement.
>
> Here's a data-point 
>
> My 1920 pixel-wide screen, in the default font, allows 239 columns; not
> enough for two 130-wide editors.  Especially not with line numbers and
> "gutter" columns.
>
> On the other hand, 80 columns does tend to cause some formatting
> contortions, with long function names and deeper indentations.
>
> I think a nice round 100 would be a good compromise.

Here's mine:

My 1280 pixel-wide screen allows 179 columns, which comes to 89.5
columns when divided by 2. I think rounding up to 90 columns would be
a good compromise, although if that's too small, 100 is good as well.

>
> Andrew
>

Re: C2X Proposal, merge '.' and '->' C operators

[Eric Gallager]

On 12/16/19, J Decker  wrote:
> Here's the gist of what I would propose...
> https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da
>
> In C, there are two operators . and -> used to access members of struct and
> union types. These operators are specified such that they are always paired
> in usage; for example, if the left hand expression is a pointer to a struct
> or union, then the operator -> MUST be used. There is no occasion where .
> and -> may be interchanged, given the existing specification.
>
> It should be very evident to the compiler whether the token before '.' or
> '->' is a pointer to a struct/union or a struct/union, and just build the
> appropriate output.

I have mixed feelings on this proposal. On the one hand, when I was
first learning C, the difference between '.' and '->' was a major
source of confusion (as was understanding pointers in general). On the
other hand, now that I understand them a bit better, I find the
distinction to be helpful in reducing ambiguity and making code more
readable.

>
> The source modification for the compiler is very slight, even depending on
> flag_c2x(that's not it's name).  It ends up changing a lot of existing
> lines, just to change their indentation; but that shouldn't really count
> against 'changed lines'.
>
> I'm sure, after 4 score and some years ('78-19) that it must surely have
> come up before?  Anyone able to point me to those existing proposals?

I saw some Twitter threads and StackOverflow Q&As on the topic before;
I'm not really sure how to search to find them again though, given
that the punctuation involved is often treated as special
characters...

>
> D
>

Re: Doxygen for GCC

[Eric Gallager]

On 6/8/17, Martin Liška  wrote:
> On 04/28/2017 02:32 PM, Martin Liška wrote:
>> I'm planning to periodically build it and rsync to a public website.
>> I guess, sometimes it can be handy.
>
> Done that (it's weekly updated):
>
> http://gcc.opensuse.org/gcc-doxygen/
>
> Martin
>

Clicking on the first link on the sidebar, it looks like doxygen needs
to be taught how to handle gcc's kind of md files:
http://gcc.opensuse.org/gcc-doxygen/md_gcc_common.html
Has there been a bug raised with doxygen for this?

Re: Missing warning opportunity - code after break;

[Eric Gallager]

On 6/19/17, Soul Studios  wrote:
> Just noticed this:
> while(something)
> {
>   // stuff
>
>   if (num_elements == 0)
>   {
>   break;
>   --current_group;
>   }
> }
>
> doesn't trigger a warning in GCC 5.1, 6.3 and 7.1. The line after
> "break;" is unused, probably should be before the break, ie. user error.
>
> Matt Bentley
>

This is bug 46476: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46476

Re: Could preprocessor warn for unsafe macros and side-effects?

[Eric Gallager]

On 7/12/17, Martin Sebor  wrote:
> On 07/11/2017 11:50 PM, sa...@hederstierna.com wrote:
>> Hi
>>
>> Reading about macro pitfalls and eg duplication side-effects
>> https://gcc.gnu.org/onlinedocs/cpp/Macro-Pitfalls.html#Macro-Pitfalls
>>
>> would it be possible to let the preprocessor generate warnings for any of
>> these pitfalls?
>
> The preprocessor has no knowledge of the language rules but it is
> possible to detect some of these problems in the parser.  In fact,
> a checker for one of the CERT problems was added not too long ago:
> -Wmulti-statement-macros.  I would suggest to open an enhancement
> request asking for features you would find particularly valuable.
>

I think bug 6906 is related although it's limited to just the specific
case of assert(): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6906

>>
>> Maybe all language specific parts are not know at this early preprocessing
>> stage, but possibly some info could be stored for use in later pass?
>>
>> I'm thinking of eg. for "function-like macros" with arguments, checking
>>
>> -Wmacro-side-effects
>>
>> * IF function-like macro expands/duplicates an argument more than once
>> THEN
>> WARN if function() is part as the argument
>> WARN if unary ++ or -- is used on variable as part of argument
>> WARN if assignment operator = is part of argument
>> WARN if volatile variable part as the argument
>>
>> -Wmacro-operator-precedence
>>
>> * WARN if macro argument contains an expression with operator(s), an a
>> _higher_ precedence operator is used within the macro on this argument,
>> without parenthesis around
>>
>> I'm not sure its even possible at preprocessing stage, but it would be
>> nice to have,
>> I saw some static code analysis tools like Coverity detects these
>> https://www.securecoding.cert.org/confluence/display/c/PRE31-C.+Avoid+side+effects+in+arguments+to+unsafe+macros
>>
>> Of course it might generate some false-positives so warning might not be
>> enabled by default, maybe just -Wall or -Wextra,
>> but perhaps it hard to solve, and I'm not sure where and how to implement
>> the checking algorithm.
>
> Those sound like good ideas.  Some of them and the challenges
> with implementing them were discussed in the context of the
> -Wmulti-statement-macros enhancement:
>
>https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00064.html
>
> Martin
>

Re: Killing old dead bugs

[Eric Gallager]

On 7/18/17, Yuri Gribov  wrote:
> On Tue, Jul 18, 2017 at 3:54 PM, Martin Sebor  wrote:
>> On 07/17/2017 02:25 PM, Yuri Gribov wrote:
>>>
>>> On Mon, Jul 17, 2017 at 4:23 PM, Martin Sebor  wrote:

 On 07/17/2017 02:14 AM, Yuri Gribov wrote:
>
>
> Hi Mikhail,
>
> On Sun, Jul 2, 2017 at 6:39 PM, Mikhail Maltsev 
> wrote:
>>
>>
>> Hi. Yes, bug maintenance is appreciated. See this message and replies
>> to it: https://gcc.gnu.org/ml/gcc/2016-04/msg00258.html .
>
>
>
> Replies in your link suggest to leave a final comment in bugs with
> explanatory suggestion to close them so that maintainers who read
> gcc-bugs list hopefully notice them and act appropriately.
> Unfortunately I found this to _not_ work in practice. Below you can
> see a list of bugs I've investigated (and often bisected) in the past
> weeks - none of them were closed by maintainers (or at least
> commented).
>
> So I'm afraid we have to conclude that there's no working process to
> close stale bugs in place (which may be one of the reasons of bugcount
> growth).



 The informal process that some (most?) of us have been following
 is to close them with a comment explaining our rationale.
 It's good to fill in the Known to fail/Known to work versions if they
 can be determined.  Mentioning the commit that fixed the bug as
 you did for the bugs below is ideal.  Adding a test case if one
 doesn't exist in the test suite is also very useful, though quite
 a bit more work.  In my experience, if a bug is closed that should
 stay open, someone usually notices pretty quickly and reopens it,
 so I wouldn't be too worried about doing something wrong.
>>>
>>>
>>> Martin,
>>>
>>> Firstly, thanks for detailed explanation.
>>>
>>> What to do about bugs originating in upstream packages?  I noticed
>>> they sometimes get closed with "RESOLVED MOVED" resolution
>>> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58841) but often this
>>> does not happen and they just hang in tracker forever for no good
>>> reason.
>>>
>>> Actually what I tried to emphasize is that it's impossible for a
>>> casual commiter (who does not have maintainer access to Bugzilla i.e.
>>> rights to close bugs) to contribute to project by cleaning stale bugs,
>>> because requests to close them are mostly ignored (because
>>> maintainers, obviously, have much more interesting work to do).
>>
>>
>> I take your point.  I didn't realize closing bugs was restricted.
>> Given the work you've done on the bugs below (and elsewhere) you
>> should be able to close them.  If you aren't and would like to be
>> able to, please request it by emailing overse...@gcc.gnu.org ((at
>> least I think that's the right way to go about it), or follow up
>> here and I'm sure someone with the right karma will make it happen.
>
> Jonathan also mentioned something not immediately obvious in IRC:
> logging into BZ with gcc.gnu.org account provides elevated privileges.
> So if you have write access, you should get extra BZ rights for free.
>

Is there a way to do this with a password thru a graphical web
browser? The instructions I found on the SVN write page
 only mentioned ssh-ing into the
server. It says "Your gcc.gnu.org account... is what you use for
Bugzilla" but doesn't actually say how to do that. I tried using the
same password as I do for the Bugzilla account linked to the email
that my gcc.gnu.org account forwards to (this one), but that didn't
work. Sorry if I'm missing something obvious...

 The process for managing bugs is in more detail described here:

   https://gcc.gnu.org/bugs/management.html

 If you think it should be clarified in some way please feel free
 to send in a patch.

 Martin


>
> * Bug 41992 - ICE on invalid dereferencing of void *
> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00860.html)
> * Bug 63245 - renderMemorySnippet shouldn't show more bytes than the
> underlying type
> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00645.html)
> * Bug 61693 - [asan] is not intercepting aligned_alloc
> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00643.html)
> * Bug 61771 - Test failures in ASan testsuite on ARM Linux due to FP
> format mismatch between libasan and GCC
> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00646.html)
> * Bug 78028 - ASAN doesn't find memory leak
> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00653.html)
> * Bug 55316 - gcc/libsanitizer/asan/asan_linux.cc:70:3: error: #error
> "Unsupported arch"
> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00636.html)
> * Bug 78654 - ubsan can lead to excessive stack usage
> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00640.html)
> * Bug 60892 - GCC (libsanitizer) fails to build with Linux 2.6.21
> headers (https://gcc.gnu.org/ml/gcc-bugs/2

Re: Killing old dead bugs

[Eric Gallager]

On 7/19/17, Yuri Gribov  wrote:
> On Wed, Jul 19, 2017 at 7:15 PM, Eric Gallager 
> wrote:
>> On 7/18/17, Yuri Gribov  wrote:
>>> On Tue, Jul 18, 2017 at 3:54 PM, Martin Sebor  wrote:
>>>> On 07/17/2017 02:25 PM, Yuri Gribov wrote:
>>>>>
>>>>> On Mon, Jul 17, 2017 at 4:23 PM, Martin Sebor 
>>>>> wrote:
>>>>>>
>>>>>> On 07/17/2017 02:14 AM, Yuri Gribov wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hi Mikhail,
>>>>>>>
>>>>>>> On Sun, Jul 2, 2017 at 6:39 PM, Mikhail Maltsev 
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi. Yes, bug maintenance is appreciated. See this message and
>>>>>>>> replies
>>>>>>>> to it: https://gcc.gnu.org/ml/gcc/2016-04/msg00258.html .
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Replies in your link suggest to leave a final comment in bugs with
>>>>>>> explanatory suggestion to close them so that maintainers who read
>>>>>>> gcc-bugs list hopefully notice them and act appropriately.
>>>>>>> Unfortunately I found this to _not_ work in practice. Below you can
>>>>>>> see a list of bugs I've investigated (and often bisected) in the
>>>>>>> past
>>>>>>> weeks - none of them were closed by maintainers (or at least
>>>>>>> commented).
>>>>>>>
>>>>>>> So I'm afraid we have to conclude that there's no working process to
>>>>>>> close stale bugs in place (which may be one of the reasons of
>>>>>>> bugcount
>>>>>>> growth).
>>>>>>
>>>>>>
>>>>>>
>>>>>> The informal process that some (most?) of us have been following
>>>>>> is to close them with a comment explaining our rationale.
>>>>>> It's good to fill in the Known to fail/Known to work versions if they
>>>>>> can be determined.  Mentioning the commit that fixed the bug as
>>>>>> you did for the bugs below is ideal.  Adding a test case if one
>>>>>> doesn't exist in the test suite is also very useful, though quite
>>>>>> a bit more work.  In my experience, if a bug is closed that should
>>>>>> stay open, someone usually notices pretty quickly and reopens it,
>>>>>> so I wouldn't be too worried about doing something wrong.
>>>>>
>>>>>
>>>>> Martin,
>>>>>
>>>>> Firstly, thanks for detailed explanation.
>>>>>
>>>>> What to do about bugs originating in upstream packages?  I noticed
>>>>> they sometimes get closed with "RESOLVED MOVED" resolution
>>>>> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58841) but often this
>>>>> does not happen and they just hang in tracker forever for no good
>>>>> reason.
>>>>>
>>>>> Actually what I tried to emphasize is that it's impossible for a
>>>>> casual commiter (who does not have maintainer access to Bugzilla i.e.
>>>>> rights to close bugs) to contribute to project by cleaning stale bugs,
>>>>> because requests to close them are mostly ignored (because
>>>>> maintainers, obviously, have much more interesting work to do).
>>>>
>>>>
>>>> I take your point.  I didn't realize closing bugs was restricted.
>>>> Given the work you've done on the bugs below (and elsewhere) you
>>>> should be able to close them.  If you aren't and would like to be
>>>> able to, please request it by emailing overse...@gcc.gnu.org ((at
>>>> least I think that's the right way to go about it), or follow up
>>>> here and I'm sure someone with the right karma will make it happen.
>>>
>>> Jonathan also mentioned something not immediately obvious in IRC:
>>> logging into BZ with gcc.gnu.org account provides elevated privileges.
>>> So if you have write access, you should get extra BZ rights for free.
>>>
>>
>> Is there a way to do this with a password thru a graphical web
>> browser? The instructions I found on the SVN write page
>> <https://gcc.gnu.org/svnwrite.html> only mentione

Re: Overwhelmed by GCC frustration

[Eric Gallager]

On 8/1/17, Richard Biener  wrote:
> On Mon, Jul 31, 2017 at 7:08 PM, Andrew Haley  wrote:
>> On 31/07/17 17:12, Oleg Endo wrote:
>>> On Mon, 2017-07-31 at 15:25 +0200, Georg-Johann Lay wrote:
 Around 2010, someone who used a code snipped that I published in
 a wiki, reported that the code didn't work and hang in an
 endless loop.  Soon I found out that it was due to some GCC
 problem, and I got interested in fixing the compiler so that
 it worked with my code.

 1 1/2 years later, in 2011, [...]
>>>
>>> I could probably write a similar rant.  This is the life of a
>>> "minority target programmer".  Most development efforts are being
>>> done with primary targets in mind.  And as a result, most changes
>>> are being tested only on such targets.
>>>
>>> To improve the situation, we'd need a lot more target specific tests
>>> which test for those regressions that you have mentioned.  Then of
>>> course somebody has to run all those tests on all those various
>>> targets.  I think that's the biggest problem.  But still, with a
>>> test case at hand, it's much easier to talk to people who have
>>> silently introduced a regression on some "other" targets.  Most of
>>> the time they just don't know.
>>
>> It's a fundamental problem for compilers, in general: every
>> optimization pass wants to be the last one, and (almost?) no-one who
>> writes a pass knows all the details of all the subsequent passes.  The
>> more sophisticated and subtle an optimization, the more possibility
>> there is of messing something up or confusing someone's back end or a
>> later pass.  We've seen this multiple times, with apparently
>> straightforward control flow at the source level turning into a mess
>> of spaghetti in the resulting assembly.  But we know that the
>> optimization makes sense for some kinds of program, or at least that
>> it did at the time the optimization was written.  However, it is
>> inevitable that some programs will be made worse by some
>> optimizations.  We hope that they will be few in number, but it
>> really can't be helped.
>>
>> So what is to be done?  We could abandon the eternal drive for more
>> and more optimizations, back off, and concentrate on simplicity and
>> robustness at the expens of ultimate code quality.  Should we?  It
>> would take courage, and there will be an eternal pressume to improve
>> code.  And, of course, we'd risk someone forking GCC and creating the
>> "superoptimized GCC" project, starving FSF GCC of developers.  That's
>> happened before, so it's not an imaginary risk.
>
> Heh.  I suspect -Os would benefit from a separate compilation pipeline
> such as -Og.  Nowadays the early optimization pipeline is what you
> want (mostly simple CSE & jump optimizations, focused on code
> size improvements).  That doesn't get you any loop optimizations but
> loop optimizations always have the chance to increase code size
> or register pressure.
>

Maybe in addition to the -Os optimization level, GCC mainline could
also add the -Oz optimization level like Apple's GCC had, and clang
still has? Basically -Os is -O2 with additional code size focus,
whereas -Oz is -O0 with the same code size focus. Adding it to the
FSF's GCC, too, could help reduce code size even further than -Os
currently does.

> But yes, targeting an architecture like AVR which is neither primary
> nor secondary (so very low priority) _plus_ being quite special in
> target abilities (it seems to be very easy to mess up things) is hard.
>
> SUSE does have some testers doing (also) code size monitoring
> but as much data we have somebody needs to monitor it, further
> bisect and report regressions deemed worthwhile.  It's hard to
> avoid slow creep -- compile-time and memory use are a similar
> issue here.
>
> Richard.
>
>> --
>> Andrew Haley
>> Java Platform Lead Engineer
>> Red Hat UK Ltd. 
>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>

Re: Overwhelmed by GCC frustration

[Eric Gallager]

On 8/1/17, Jakub Jelinek  wrote:
> On Tue, Aug 01, 2017 at 07:08:41AM -0400, Eric Gallager wrote:
>> > Heh.  I suspect -Os would benefit from a separate compilation pipeline
>> > such as -Og.  Nowadays the early optimization pipeline is what you
>> > want (mostly simple CSE & jump optimizations, focused on code
>> > size improvements).  That doesn't get you any loop optimizations but
>> > loop optimizations always have the chance to increase code size
>> > or register pressure.
>> >
>>
>> Maybe in addition to the -Os optimization level, GCC mainline could
>> also add the -Oz optimization level like Apple's GCC had, and clang
>> still has? Basically -Os is -O2 with additional code size focus,
>> whereas -Oz is -O0 with the same code size focus. Adding it to the
>> FSF's GCC, too, could help reduce code size even further than -Os
>> currently does.
>
> No, lack of optimizations certainly doesn't reduce the code size.
> For small code, you need lots of optimizations, but preferrably code-size
> aware ones.  For RTL that is usually easier, because you can often compare
> the sizes of the old and new sequences and choose smaller, for GIMPLE
> optimizations it is often just a wild guess on what optimizations generally
> result in smaller and what optimizations generally result in larger code.
> There are too many following passes to know for sure, and finding the right
> heuristics is hard.
>
>   Jakub
>

Upon rereading of the relevant docs, I guess it was a mistake to
compare -Oz to -O0. Let me quote from the apple-gcc "Optimize Options"
page:

-Oz
(APPLE ONLY) Optimize for size, regardless of performance. -Oz
enables the same optimization flags that -Os uses, but -Oz also
enables other optimizations intended solely to reduce code size.
In particular, instructions that encode into fewer bytes are
preferred over longer instructions that execute in fewer cycles.
-Oz on Darwin is very similar to -Os in FSF distributions of GCC.
-Oz employs the same inlining limits and avoids string instructions
just like -Os.

Meanwhile, their description of -Os as contrasted to -Oz reads:

-Os
Optimize for size, but not at the expense of speed. -Os enables all
-O2 optimizations that do not typically increase code size.
However, instructions are chosen for best performance, regardless
of size. To optimize solely for size on Darwin, use -Oz (APPLE
ONLY).

And the clang docs for -Oz say:

-Oz Like -Os (and thus -O2), but reduces code size further.

So -Oz does actually still optimize, so it's more like -O2 than -O0
after all, just even more size-focused than -Os.

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

[Eric Gallager]

On 8/15/17, Jonathan Wakely  wrote:
> On 15 August 2017 at 04:10, Martin Sebor wrote:
>> On 08/14/2017 04:22 PM, Eric Gallager wrote:
>>>
>>> I'm emailing this manually to the list because Bugzilla is down and I
>>> can't file a bug on Bugzilla about Bugzilla being down. The error
>>> message looks like this:
>
>
> Even if it were possible, there wouldn't be any point in filing a bug
> that bugzilla's down, and so not much point emailing gcc-bugs either
> (since that's for bugzilla mail).  Using gcc@ seems like the right
> list to me.
>
> N.B. since the server is being restored from a backup all of
> yesterday's changes to bugzilla have been lost, including all Richi's
> 7.2 release changes, and Eric's housekeeping.
>
> I don't suggest redoing all that work until all services are fully
> restored, in case it's lost again.
>

I see Richi redid all his 7.2 release changes; does that imply that
the server restore is now complete?

Re: Optimization breaks inline asm code w/ptrs

[Eric Gallager]

On 8/14/17, Alan Modra  wrote:
> On Sun, Aug 13, 2017 at 10:25:14PM +0930, Alan Modra wrote:
>> On Sun, Aug 13, 2017 at 03:35:15AM -0700, David Wohlferd wrote:
>> > Using "m"(*pStr) as an (unused) input parameter has no effect.
>>
>> Use "m" (*(const void *)pStr) and ignore the warning, or use
>> "m" (*(const struct {char a; char x[];} *) pStr).
>
> or even better "m" (*(const char (*)[]) pStr).
>
>> The issue is one of letting gcc know what memory is accessed by the
>> asm, if you don't want to use a "memory" clobber.  And there are very
>> good reasons to avoid clobbering all memory.
>>
>> "m"(*pStr) ought to work IMO, but apparently just tells gcc you are
>> only interested in the first character.  Of course that is exactly
>> what *pStr is, but in this context it would be nicer if it meant the
>> entire array.
>
> I take that back.  The relatively simple cast to differentiate a
> pointer to a char from a pointer to an indeterminate length char array
> makes it quite unnecessary for "m"(*pStr) to be treated as as array
> reference.
>
> I've opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81845 to
> track the lack of documentation.
>

Alan, you might want to re-file that bug; it got lost in the Bugzilla
crash, and a different unrelated bug ended up taking its bug number...
(check the gcc-bugs archives)

> --
> Alan Modra
> Australia Development Lab, IBM
>

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

[Eric Gallager]

On 8/25/17, Szabolcs Nagy  wrote:
> On 16/08/17 18:38, Joseph Myers wrote:
>> On Wed, 16 Aug 2017, Eric Gallager wrote:
>>> I see Richi redid all his 7.2 release changes; does that imply that
>>> the server restore is now complete?
>>
>> No, there's still a search process ongoing to identify corrupted or
>> missing files by comparison with the last backup.
>>
>> My expectation is that all the other Bugzilla changes from 13 and 14
>> August UTC need redoing manually (recreating bugs with new numbers in the
>>
>> case of new bugs filed during that period, if those bugs are still
>> relevant, repeating comments, etc. - and possibly recreating accounts for
>>
>> people who created accounts and filed bugs during that period).  But I
>> haven't seen any official announcement from overseers to all affected
>> projects (for both GCC and Sourceware Bugzillas) yet.
>>
>
> can i resubmit my lost bug reports now?
>
>

Yes, please do. Joseph said the restore was done in a comment on bug web/81846:

http://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01718.html

Re: Weird warning when building gcc

[Eric Gallager]

On Sat, Sep 23, 2017 at 12:34 PM, nick  wrote:
>
>
> On 2017-09-23 12:05 PM, Jeff Law wrote:
>> On 09/22/2017 08:25 PM, nick wrote:
>>> Greetings All,
>>>
>>> I am wondering if this is a warning worth looking into or is it just 
>>> another false postive:
>>>
>>> /home/nick/gcc/gcc/combine.c:1316:8: warning: ‘prev’ may be used 
>>> uninitialized in this function [-Wmaybe-uninitialized]
>>>  if ((next = try_combine (insn, prev, NULL, NULL,
>>>
>>> Maybe it's just me being new to the project but is the code for that 
>>> literally or also identical between this and the
>>> one where CC0 register is directly used.
>> Looks like a false positive to me.   Without more details (host, target,
>> flags, cpp output) I can't be 100% sure why it triggers though.
>>
>> Flow sensitive warnings such as this are very sensitive to a variety of
>> low level target and IL details.
>>
>>
>>
>> Jeff
>>
>
> Jeff,
>
> Thanks specifically what low level details do you need. It's currently on a 
> x86-64 bit ubuntu host.
> Was build with the stock gcc from the ubuntu 17.04 repos with W=2 for extra 
> warnings. What do these
> lines do, anything outside of the normal setting marcos as they seem to me:
>
> && GET_CODE (PATTERN (insn)) == SET
> && reg_mentioned_p (cc0_rtx, SET_SRC (PATTERN (insn)))
>
> I am wondering what GET_CODE,SET_SRC, PATTERN marcos do plus the function 
> called, reg_mentioned_P?
> If your able to just tell me where the functions are located or how do you 
> enable ctags for all of
> gcc? That would just save me asking stupid questions. Is there a global 
> setting like make ctags for
> doing this or you I have to do it manually.
>
> Thanks for the quick response,
>
> Nick

I think I remember running into this warning before; it's because
stage 1 of bootstrap is built without optimization so the warnings
don't have as good information.

Right, here's the link to the end of the thread about it:
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00143.html

Re: Weird warning when building gcc

[Eric Gallager]

On Sat, Sep 23, 2017 at 12:34 PM, nick  wrote:
> If your able to just tell me where the functions are located or how do you 
> enable ctags for all of
> gcc? That would just save me asking stupid questions. Is there a global 
> setting like make ctags for
> doing this or you I have to do it manually.
>
> Thanks for the quick response,
>
> Nick

Also, for `make ctags` to work from the top level source directory,
this patch needs to be applied:
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00370.html
(The patch is approved but the thread says I was still waiting on
commit access at the time; I have since received commit access, but my
ssh keys that allow me to commit are currently stuck on a failing hard
drive, so if someone else could commit for me, it'd be appreciated.)

Re: Weird warning when building gcc

[Eric Gallager]

On Mon, Sep 25, 2017 at 11:17 AM, nick  wrote:
>
>
> On 2017-09-24 10:10 AM, Eric Gallager wrote:
>> On Sat, Sep 23, 2017 at 12:34 PM, nick  wrote:
>>> If your able to just tell me where the functions are located or how do you 
>>> enable ctags for all of
>>> gcc? That would just save me asking stupid questions. Is there a global 
>>> setting like make ctags for
>>> doing this or you I have to do it manually.
>>>
>>> Thanks for the quick response,
>>>
>>> Nick
>>
>> Also, for `make ctags` to work from the top level source directory,
>> this patch needs to be applied:
>> https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00370.html
>> (The patch is approved but the thread says I was still waiting on
>> commit access at the time; I have since received commit access, but my
>> ssh keys that allow me to commit are currently stuck on a failing hard
>> drive, so if someone else could commit for me, it'd be appreciated.)
>>
>
> Eric,
>
> I rewrote the patch as it was failing for me on the trunk of gcc git. It's 
> still
> reported as failing but it seems to apply fine when I inspect the lines I 
> changed,
> all apply fine now.
>
> Here is the reported git warning:
>
> Applying: Fix Ctags Patch to Work on Master Tree
> .git/rebase-apply/patch:15: trailing whitespace.
> host_modules= { module= libdecnumber; bootstrap=true;
> warning: 1 line adds whitespace errors.
>
> I will fix this after I get some comments on my update of the patch. It's
> attached here. Here is a link to the original patch I rewrote due to
> failing for me:
> https://gcc.gnu.org/ml/gcc-patches/2016-10/txtNehNSQvx5L.txt
>
> Nick

The way to get the patch to work that I was going to suggest would be
to just apply the portion that applies to Makefile.def, and then
regenerate Makefile.in manually by running `autogen Makefile.def`, as
described in the top comments of Makefile.tpl. But if you managed it
another way, that's cool too.

Eric

Re: RFC: Update top level libtool files

[Eric Gallager]

On Tue, Oct 10, 2017 at 11:20 AM, Nick Clifton  wrote:
> Hi Joseph,
>
>> As per previous discussions on the issue: it's necessary to revert libtool
>> commit 3334f7ed5851ef1e96b052f2984c4acdbf39e20c, see
>> .
>
> OK - thanks for that pointer.
>
>> I do not know
>> if there are other local libtool changes that are not in version 2.4.6; it
>> would be necessary to check all differences from 2.2.7a to determine
>> whether any need to be re-applied to 2.4.6.
>
> *sigh*  It seems that 2.2.7a was not an official release.  At least I could
> not find a tarball for that specific version on the ftp.gnu.org/libtool 
> archive.
> (There is a 2.2.6b release and a 2.2.8 release but no 2.2.7).  So it
> looks like we have been using a modified set of sources for a long time now.
>
> Maybe I would be better off not rocking the boat, and just submit the Fedora
> sys_path patch for consideration instead...
>
>
>> For that matter, these trees are also using very old autoconf and automake
>> versions and using the current versions of those (2.69 and 1.15.1) would
>> be a good idea as well.  Hopefully version dependencies are loose enough
>> that it's possible to update one tool at a time (so update libtool without
>> needing to update autoconf or automake at the same time).
>
> Oh gosh - I would love to see that done.  But the last time I tried I ended
> up going down a rabbit hole of autoconf/automake problems that just never
> ended.  So I gave up. :-(  Maybe someone with more autoconf-fu than me will
> have a go one day though.
>
> Cheers
>   Nick
>

 I updated my fork of binutils/gdb (which shares a toplevel with gcc)
to use autoconf 2.69 and automake 1.15 instead of the current
versions, and it usually works for my usecase, but I think there's
still issues with it and I probably broke stuff in the process, so I'd
be afraid of making similar mistakes if I tried to do the same update
for gcc...

Re: Feature request: -Wno-unknown-warnings to silently ignore unknown warning control flags.

[Eric Gallager]

On Thu, Oct 12, 2017 at 4:46 AM, Oren Ben-Kiki  wrote:
> Motivation/Use case:
>
> * Since gcc/g++ intentionally does not have `-Weverything`, there is a
> number of explicit `-W...` flags one might wish to specify explicitly. Fair
> enough.
>
> * Additional `-W...` flags are introduced in new gcc/g++ versions, which
> check for new potential code smells, possibly related to later language
> standards. That's great (thanks!).
>
> * Not all platforms run the latest gcc/g++ compiler version. So build tools
> need to deal with a range of versions.
>
> Taking these three points together, we have a problem. The build tool
> wishes to specify `-Wshiny-new-warning` but may only do so if the gcc/g++
> compiler version is above some version X.
>
> This is difficult for several reasons:
>
> * The documentation does not clearly specify the 1st compiler version that
> supports each error/warning command line flag. One has to manually
> backtrack through the release notes for all the compiler versions.
>
> In fact the documentation also doesn't make it easy to see which flags are
> covered by other flags - one has to read through the documentation, one
> flag at a time, and extract the information from the English text. Some
> form of a more structured table would have been awesome: 1st compiler
> version supporting the flag, the list of other flags such as `-Wall` that
> imply the flag, maybe a list of related flags such as `-f...`. But that
> aside...
>
> * Even if we know which compiler version to check for, this quickly becomes
> a PITA to maintain in the build tool, given the large number of compiler
> versions in use in the wild. Having many versions means the compiler has
> been actively progressing at a fast rate, which is great! But it makes it
> nasty to deal with providing the correct warning flags for the correct
> compiler version.
>
> This is (mostly) solved with the new proposed flag: the build tool would
> simply list all the desired warning flags, which would be silently ignored
> by older compiler versions.
>
> Typos are a potential issue. One would have to run a "recent" version
> without the `-Wno-unknown-warnings` to catch such typos; that would be
> rare, and is simple enough to do (and automate in the build tool if
> desired).
>
> Another obvious issue is that the new `-Wno-unknown-warnings` flag would
> only be available starting in a future compiler version. So build tools
> would have to deal with the problem for a long time before the flag would
> provide its full benefits. Barring having a working time machine ;-)
>
> However, it is much simpler for a build tool to do a single test of whether
> or not the compiler version supports the proposed new flag, than to deal
> with the full problem of multiple versions. If the new flag is not
> supported, the build tool could fall back to using a conservative set of
> warning flags.
>
> Also, as time goes by, older compiler versions would eventually be phased
> out, so even this test would be (eventually) removed. Sure, it would take a
> decade or more, but: as the saying goes, "The best time to plant a tree is
> 20 years ago; the second best time is today".
>
> Thanks,
>
> Oren Ben-Kiki

If you use autoconf to generate a configure script for your project, I
recommend using the macros from gnulib's manywarnings.m4 and related
files:

https://www.gnu.org/software/gnulib/manual/html_node/warnings.html#warnings
https://www.gnu.org/software/gnulib/manual/html_node/manywarnings.html#manywarnings

Re: Fail to compile GDB with recent GCC trunk (-Werror=stringop-overflow=, -Werror=stringop-truncation)

[Eric Gallager]

On 11/20/17, Yao Qi  wrote:
>
> Hi,
> I failed to compile GDB with GCC trunk (8.0.0 20171117) because of some
> -Werror=stringop-overflow= and -Werror=stringop-truncation warnings.
> Some of them are not necessary to me,
>
> 1. ../../binutils-gdb/gdb/python/py-gdb-readline.c:79:15: error: ‘char*
> strncpy(char*, const char*, size_t)’ output truncated before terminating nul
> copying as many bytes from a string as its length
> [-Werror=stringop-truncation]
>strncpy (q, p, n);
>^
> ../../binutils-gdb/gdb/python/py-gdb-readline.c:73:14: note: length computed
> here
>n = strlen (p);
>~~~^~~
>
> the code is simple,
>
>   n = strlen (p);
>
>   /* Copy the line to Python and return.  */
>   q = (char *) PyMem_RawMalloc (n + 2);
>   if (q != NULL)
> {
>   strncpy (q, p, n);
>   q[n] = '\n';
>   q[n + 1] = '\0';
> }
>
> I don't see the point of warning here.
>
> 2. ../../binutils-gdb/gdb/cp-namespace.c:1071:11: error: ‘char*
> strncpy(char*, const char*, size_t)’ output truncated before terminating nul
> copying 2 bytes from a string of the same length
> [-Werror=stringop-truncation]
>strncpy (full_name + scope_length, "::", 2);
>^~~
>
>   full_name = (char *) alloca (scope_length + 2 + strlen (name) + 1);
>   strncpy (full_name, scope, scope_length);
>   strncpy (full_name + scope_length, "::", 2);
>   strcpy (full_name + scope_length + 2, name);
>
> the code looks right to me,
>
> Likewise,
>
> ../../../binutils-gdb/gdb/gdbserver/remote-utils.c:1204:14: error: ‘char*
> strncpy(char*, const char*, size_t)’ output truncated before terminating nul
> copying 6 bytes from a string of the same length
> [-Werror=stringop-truncation]
>   strncpy (buf, "watch:", 6);
>   ^~
>
> strncpy (buf, "watch:", 6);
> buf += 6;
> 
> *buf = '\0';
>
> I can "fix" these warnings by changing GDB code, use strcpy in 1) and
> use memcpy in 2).  Do we expect all the users of GCC 8 changing their
> correct code because GCC is not happy on the code?  The warning is too
> aggressive to me.
>
> --
> Yao (齐尧)
>

I thought there was a gcc bug open about this but now I can't seem to
find it; please let me know if you come across the one I was trying to
remember...

Re: Fail to compile GDB with recent GCC trunk (-Werror=stringop-overflow=, -Werror=stringop-truncation)

[Eric Gallager]

On 11/20/17, Eric Gallager  wrote:
> On 11/20/17, Yao Qi  wrote:
>>
>> Hi,
>> I failed to compile GDB with GCC trunk (8.0.0 20171117) because of some
>> -Werror=stringop-overflow= and -Werror=stringop-truncation warnings.
>> Some of them are not necessary to me,
>>
>> 1. ../../binutils-gdb/gdb/python/py-gdb-readline.c:79:15: error: ‘char*
>> strncpy(char*, const char*, size_t)’ output truncated before terminating
>> nul
>> copying as many bytes from a string as its length
>> [-Werror=stringop-truncation]
>>strncpy (q, p, n);
>>^
>> ../../binutils-gdb/gdb/python/py-gdb-readline.c:73:14: note: length
>> computed
>> here
>>n = strlen (p);
>>~~~^~~
>>
>> the code is simple,
>>
>>   n = strlen (p);
>>
>>   /* Copy the line to Python and return.  */
>>   q = (char *) PyMem_RawMalloc (n + 2);
>>   if (q != NULL)
>> {
>>   strncpy (q, p, n);
>>   q[n] = '\n';
>>   q[n + 1] = '\0';
>> }
>>
>> I don't see the point of warning here.
>>
>> 2. ../../binutils-gdb/gdb/cp-namespace.c:1071:11: error: ‘char*
>> strncpy(char*, const char*, size_t)’ output truncated before terminating
>> nul
>> copying 2 bytes from a string of the same length
>> [-Werror=stringop-truncation]
>>strncpy (full_name + scope_length, "::", 2);
>>^~~
>>
>>   full_name = (char *) alloca (scope_length + 2 + strlen (name) + 1);
>>   strncpy (full_name, scope, scope_length);
>>   strncpy (full_name + scope_length, "::", 2);
>>   strcpy (full_name + scope_length + 2, name);
>>
>> the code looks right to me,
>>
>> Likewise,
>>
>> ../../../binutils-gdb/gdb/gdbserver/remote-utils.c:1204:14: error: ‘char*
>> strncpy(char*, const char*, size_t)’ output truncated before terminating
>> nul
>> copying 6 bytes from a string of the same length
>> [-Werror=stringop-truncation]
>>   strncpy (buf, "watch:", 6);
>>   ^~
>>
>> strncpy (buf, "watch:", 6);
>> buf += 6;
>> 
>> *buf = '\0';
>>
>> I can "fix" these warnings by changing GDB code, use strcpy in 1) and
>> use memcpy in 2).  Do we expect all the users of GCC 8 changing their
>> correct code because GCC is not happy on the code?  The warning is too
>> aggressive to me.
>>
>> --
>> Yao (齐尧)
>>
>
> I thought there was a gcc bug open about this but now I can't seem to
> find it; please let me know if you come across the one I was trying to
> remember...
>

Never mind, I found the bug I was looking for (80354), but it was
about -Wformat-truncation, not -Wstringop-truncation, and it's closed,
not open, and the point I made in it was about sprintf vs. snprintf,
not strcpy vs. strncpy (although it applies equally as well in both
cases): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80354

Re: Possbile patch for compilation errors re possibly uninitialized variables at -Og

[Eric Gallager]

On 12/29/17, Louis Krupp  wrote:
> I tried to build the trunk using:
>
> BOOT_CFLAGS='-g -Og' CFLAGS_FOR_TARGET='-g -Og' CFLAGS_FOR_BUILD='-g -Og'
>
> I got a number of compilation warnings -- promoted to errors -- about
> possibly uninitialized variables.
>
> I have what I believe is a decent patch that initializes those variables and
> which I've tested at revision 256030. The errors go away for -Og, as well as
> for -O0.
>
> When I run make with no arguments and then run "make check", I get the same
> test failures as I do in an unmodified and identically built reference tree
> at the same revision.
>
> I've attached the patch along with a list of tentative ChangeLog entries and
> their respective directories. I can adjust the format of those entries as
> needed.
>
> Being able to build with -Og or -O0 would make my life easier.
>
> Louis Krupp
>

Patches go to the gcc-patches mailing list instead. Also please be
aware of bug 78394: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78394

Re: Possbile patch for compilation errors re possibly uninitialized variables at -Og

[Eric Gallager]

On 12/30/17, Louis Krupp  wrote:
> Thank you for making me stop and think about this. I was basically full of
> crap; like the test case in 78394, the tree compiles just fine at -O0. I
> don't know where I got the idea that it didn't.
>
> Initializing dozens of variables just to make the tree compile at -Og might
> be nice in some abstract way, but it's a moving target, and I would be very
> surprised if it were worth the trouble.
>
> Louis
>

It's okay; I've tried doing the same thing with stage1 -Wuninitialized
warnings at -O0 previously...

>
>   On Fri, 29 Dec 2017 19:40:38 -0800 Eric Gallager
>  wrote 
>  > On 12/29/17, Louis Krupp  wrote:
>  > > I tried to build the trunk using:
>  > >
>  > > BOOT_CFLAGS='-g -Og' CFLAGS_FOR_TARGET='-g -Og' CFLAGS_FOR_BUILD='-g
> -Og'
>  > >
>  > > I got a number of compilation warnings -- promoted to errors -- about
>  > > possibly uninitialized variables.
>  > >
>  > > I have what I believe is a decent patch that initializes those
> variables and
>  > > which I've tested at revision 256030. The errors go away for -Og, as
> well as
>  > > for -O0.
>  > >
>  > > When I run make with no arguments and then run "make check", I get the
> same
>  > > test failures as I do in an unmodified and identically built reference
> tree
>  > > at the same revision.
>  > >
>  > > I've attached the patch along with a list of tentative ChangeLog
> entries and
>  > > their respective directories. I can adjust the format of those entries
> as
>  > > needed.
>  > >
>  > > Being able to build with -Og or -O0 would make my life easier.
>  > >
>  > > Louis Krupp
>  > >
>  >
>  > Patches go to the gcc-patches mailing list instead. Also please be
>  > aware of bug 78394: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78394
>  >
>
>
>

GCC and Meltdown and Spectre vulnerabilities

[Eric Gallager]

Is there anything GCC could be doing at the compiler level to mitigate
the recently-announced Meltdown and Spectre vulnerabilities? From
reading about them, it seems like they involve speculative execution
and indirect branch prediction, and those are the domain of things the
compiler deals with, right? (For reference, Meltdown is CVE-2017-5754,
and Spectre is CVE-2017-5753 and CVE-2017-5715)

Just wondering,
Eric

Re: GCC and Meltdown and Spectre vulnerabilities

[Eric Gallager]

On 1/4/18, Will Hawkins  wrote:
> On Thu, Jan 4, 2018 at 10:10 PM, Eric Gallager 
> wrote:
>> Is there anything GCC could be doing at the compiler level to mitigate
>> the recently-announced Meltdown and Spectre vulnerabilities? From
>> reading about them, it seems like they involve speculative execution
>> and indirect branch prediction, and those are the domain of things the
>> compiler deals with, right? (For reference, Meltdown is CVE-2017-5754,
>> and Spectre is CVE-2017-5753 and CVE-2017-5715)
>>
>> Just wondering,
>> Eric
>
> Check out
>
> https://support.google.com/faqs/answer/7625886
>
> and especially
>
> http://git.infradead.org/users/dwmw2/gcc-retpoline.git/shortlog/refs/heads/gcc-7_2_0-retpoline-20171219
>
> I'd love to hear what other people have heard!
>
> Will
>

Thanks, this is what I was looking for. Seeing commits by H.J. Lu in
that branch gives me confidence that it'll eventually make it back
into trunk.

Eric

Re: GCC and Meltdown and Spectre vulnerabilities

[Eric Gallager]

On 1/5/18, Eric Gallager  wrote:
> On 1/4/18, Will Hawkins  wrote:
>> On Thu, Jan 4, 2018 at 10:10 PM, Eric Gallager 
>> wrote:
>>> Is there anything GCC could be doing at the compiler level to mitigate
>>> the recently-announced Meltdown and Spectre vulnerabilities? From
>>> reading about them, it seems like they involve speculative execution
>>> and indirect branch prediction, and those are the domain of things the
>>> compiler deals with, right? (For reference, Meltdown is CVE-2017-5754,
>>> and Spectre is CVE-2017-5753 and CVE-2017-5715)
>>>
>>> Just wondering,
>>> Eric
>>
>> Check out
>>
>> https://support.google.com/faqs/answer/7625886
>>
>> and especially
>>
>> http://git.infradead.org/users/dwmw2/gcc-retpoline.git/shortlog/refs/heads/gcc-7_2_0-retpoline-20171219
>>
>> I'd love to hear what other people have heard!
>>
>> Will
>>
>
> Thanks, this is what I was looking for. Seeing commits by H.J. Lu in
> that branch gives me confidence that it'll eventually make it back
> into trunk.
>
> Eric
>

Oh, and apparently there was already a thread on gcc-patches relevant
to this as of yesterday that I missed; it's here:
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00205.html ("[PATCH 0/3]
Add __builtin_load_no_speculate")

Re: Google Summer of Code 2018: Call for mentors and ideas

[Eric Gallager]

On 1/17/18, Martin Jambor  wrote:
> Hi,
>
> following a discussion at IRC about an upcoming deadline to register GCC
> as an independent organization for Google Summer of Code 2018 (GSoC), I
> have volunteered to serve as the org-admin for GCC if:
>
>   - there is not another volunteer (so step up if you are!),
>
>   - the community does not object (so let me and/or the steering
> committee know if you think I am not the right person!), and
>
>   - we have at least 4 good project ideas together(!) with willing
> mentors by next Monday January 22 (the deadline is on Tuesday).  I
> will be very happy if we have more.
>
> There are project ideas on our GSoC wiki page
> (https://gcc.gnu.org/wiki/SummerOfCode) but those are not associated
> with a willing mentor and it is basically an idea dump, it is often not
> clear how up to date the proposals are and often they are just a bit too
> terse.
>
> Therefore I would like to ask all seasoned GCC contributors who would
> like to mentor a GSoC student to send a reply to this thread with their
> idea for a project.  If you have an idea but you do not want to be a
> mentor then I will consider it only if it is really interesting, really
> specific (e.g. improving -O2 -g *somehow* is not specific) and I would
> have to be reasonably confident I'd find a good mentor for it.  So far I
> have the following ideas from the IRC discussion:
>
> 1) Jakub is willing to mentor (with someone from GDB but I reckon that
>we will find someone) a project implementing OMPD.
>
> 2) Martin Liška is willing to mentor either:
>2a) -fsanitize=type (He provided URL https://reviews.llvm.org/D32197
>but it gives me a 404 error) or its prototype, or
>2b) bash code completion like:
>
> http://blog.llvm.org/2017/09/clang-bash-better-auto-completion-is.html
>but frankly I am afraid it is too small to be a GSoC project, or
>2c) textual representation of LTO stream a.k.a. lto-dump tool
>
> 3?) Joseph Myers brought up idea to do "built-in functions for TS 18661
> floating-point functions - which has the feature that there are a
> lot of similar built-in functions for C99/C11 functions to serve as
> a guide for how to implement things)" ...Joseph, would you be
> willing to mentor it?
>
> Please send me your idea for a project you'd like to mentor.  Also feel
> free to comment on other proposals including those above.  I intend to
> put successful project ideas from this thread into a prominent position
> on the wiki page.  Remember, I want at least four plausible ones with
> willing mentors until Monday, January 22nd 23:59 CET.
>
> All sorts of information are available from the GSoC web page at
> https://summerofcode.withgoogle.com/, for example guides for mentors are
> at
> https://developers.google.com/open-source/gsoc/resources/guide#mentor_manual
>
> Thanks,
>
> Martin
>

Would it make sense to recycle old GSoC projects that never got
completed? I'm wondering about the "replace libiberty with gnulib" one

Re: Bugzilla timing out

[Eric Gallager]

On 1/18/18, Frank Ch. Eigler  wrote:
>
> msebor wrote:
>
>> I'm having trouble bringing up bugs or updating them.  Has anyone else
>> noticed Bugzilla (and/or other services running on gcc.gnu.org) being
>> very slow or timing out?
>
> One failed disk in the server has been replaced yesterday.  Please let
> us know if problems persist or reoccur.
>
> - FChE
>

Problems are still occurring for me; Bugzilla gives me 504 Gateway
Time-outs when I try to access it tonight...

Re: Blog post about gcc 8 usability improvements

[Eric Gallager]

On 3/15/18, David Malcolm  wrote:
> Sorry for the shameless self-promotion, but I've written up the work
> I've done on gcc 8 usability, in blog form, here:
>
> https://developers.redhat.com/blog/2018/03/15/gcc-8-usability-improvements/
>
> I'm working on a patch for the website's changes.html, covering the
> same material.
>
> Dave
>

Thank you re: the updating the changes.html part; I was thinking it
was looking rather bare compared to previous changes.html pages at
this same point in previous release cycles...

Eric

Re: Gcc bugzilla is down

[Eric Gallager]

Confirming, I got the same error message at around 7:29 AM Eastern
Daylight Time. Please fix!

Eric

On 4/1/18, Thomas König  wrote:
> Hi,
>
> it seems that gcc bugzilla is currently down, error message is:
>
> Software error:
>
> Can't connect to the database.
> Error: Can't connect to local MySQL server through socket
> '/var/lib/mysql/mysql.sock' (2)
>Is your database installed and up and running?
>Do you have the correct username and password selected in localconfig?
>
> If somebody could bring it up again, it would certainly help my plans to
> do some gcc hacking over the Easter weekdend :-)
>
> Regards
>
>   Thomas
>

Re: where should C++ options be documented?

[Eric Gallager]

On 4/2/18, Martin Sebor  wrote:
> Jason,
>
> The manual mentions some C++-only options in the language
> independent section 3.8 Options to Request or Suppress
> Warnings and others in 3.5 Options Controlling C++ Dialect.
>
> For example, -Wcatch-value, -Wconditionally-supported,
> and -Wzero-as-null-pointer-constant are mentioned only
> on the former page, while -Wabi-tag, -Wctor-dtor-privacy,
> -Wliteral-suffix, and -Wclass-memaccess are mentioned only
> on the latter.
>
> That makes C++ options harder to find than they should be.
> It also makes it difficult to tell which C++ options are
> included in -Wall or -Wextra.  I think we should converge
> on the same approach for all C++ options that doesn't have
> these problems.  What should it be?
>
> An approach that I think might work well is to continue
> to mention even C++-only options in 3.8 but move their
> descriptions to 3.5 (i.e., have the entry for each link
> to the full description of the option on the C++ page).
>
> Should I try to make this happen for GCC 8?
>
> Martin
>

This is bug 71283: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71283

Re: Request for compiler option to disable multiple declarations in a single statement

[Eric Gallager]

On 4/19/18, Manish Jain  wrote:
> Hi all,
>
> One of the historical artefacts of the C language has been the burden of
> lugging around multiple declarations in a single statement, with some
> well-known pitfalls:
>
> int* ptr1, ptr2;
>
> Since ptr2 looks like a pointer but actually is not, standard coding
> guidelines recommend declaring like this:
>
> int *p1, *p2;
>
> If anything, this leads to bizarre statements - very misleading for
> those trying to understand pointer usage in C or just read code:
>
> int i;
> int *j = &i; // impression: *j is being assigned &i
>
> char *k = "Text";  // impression: *k is "Text"
>
> void *fx(char *z); // impression: *fx is will accept char & return void
>
>
> Each of these idiosyncrasies is best avoided by retaining the space
> after the asterisk (and removing the one before) in a pointer
> declaration. This really ought to be the standard coding guideline.
>
> As for the problem of multiple declarations fraught in the suggestion
> above, I would like gcc developers to please consider a compiler option
> (--single-declarations perhaps) under which the programmer can only
> introduce one declaration in one statement. If such an option could be
> made available, it takes care of all declaration woes and lets declared
> types bear close resemblance to what they appear to be from signatures.
>
> Would my idea have takers on this list ?
>
> --
> Thank you & Regards,
> Manish Jain
>

Clang has a warning flag called -Wcomma to warn about code like this;
perhaps GCC could add it as well.

Re: Wabi warnings during GCC build

[Eric Gallager]

On 6/27/18, Marek Polacek  wrote:
> On Wed, Jun 27, 2018 at 08:53:48AM -0700, Steve Ellcey wrote:
>> Are other people building GCC seeing these messages during the build:
>>
>> cc1plus: warning: -Wabi won't warn about anything [-Wabi]
>> cc1plus: note: -Wabi warns about differences from the most up-to-date ABI,
>> which is also used by default
>> cc1plus: note: use e.g. -Wabi=11 to warn about changes from GCC 7
>>
>> It doesn't seem to be causing any problems in the build (even bootstrap)
>> but I am wondering why it is there.  It seems to be happening when
>> using the latest (just built) g++ to build libstdc++ so it shouldn't
>> be related to the system GCC that I am using to build with.
>>
>> I didn't find any mention of it in the gcc or libstdc++ mailing lists
>> when I looked or find any bugzilla report.
>
> I see it too, started with r261571.

Yeah I also see it.

> libstdc++/acinclude.m4 needs to be adjusted:
> WARN_FLAGS='-Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi'
> I guess to -Wabi=11?
>
> Marek
>

At first I was going to wonder if it wasn't necessary to remain
compatible with old versions of GCC that don't support -Wabi=11, but
then I reread the part about this happening with the just-built GCC,
so if that warning is only ever used with the just-built GCC, then
yeah, I'd guess it'd probably be okay.

Re: [PATCH] Add new tests for --completion option.

[Eric Gallager]

On 6/29/18, Martin Liška  wrote:
> Hi.
>
> I would like to add some DejaGNU tests for completion option.
>
> Ready for trunk?
> Martin
>

So, correct me if I'm wrong, but these tests would need to be updated
every time a new option starting like one of those is added, right? If
so, can you think of any ways to ease the increased maintenance
efforts?

Re: GCC bugzilla is down

[Eric Gallager]

On 7/1/18, Jeffrey Walton  wrote:
> On Sun, Jul 1, 2018 at 4:31 AM, Martin Liška  wrote:
>>
>> Please fix bugzilla:
>> https://gcc.gnu.org/bugzilla/
>>
>> Can't connect to the database.
>> Error: Can't connect to local MySQL server through socket
>> '/var/lib/mysql/mysql.sock' (2)
>>   Is your database installed and up and running?
>>   Do you have the correct username and password selected in localconfig?
>
> I think it was reported that happens at night because of a backup. I
> think the workaround is to visit the bug reporter during the day. Also
> see https://gcc.gnu.org/ml/gcc-help/2017-08/msg00092.html .
>
> Jeff
>

It was down for me last night and earlier this morning, too, but it
seems to be back up now.

Eric

Re: ChangeLog's: do we have to?

[Eric Gallager]

On 7/5/18, Aldy Hernandez  wrote:
> After 20 years of hacking on GCC I feel like I have literally wasted
> days of my life typing out ChangeLog entries that could have easily been
> generated programmatically.
>
> Can someone refresh my memory here, what are the remaining arguments for
> requiring ChangeLog entries?
>
> I vaguely recall Jakub (or Alex Oliva??) mentioning that they were
> desired for releases.  If this is the case, may I volunteer to write the
> necessary scripts to generate these automatically?
>
> It would be nice if we could have meaningful commit messages explaining
> why we are doing things, and any list of changed files be generated on
> the fly.
>
> Sorry, I'm getting old, and would hate to spend any meaningful remaining
> time typing things that a computer can do for me.
>
> Aldy
>

Many other GNU projects have discussed ditching/autogenerating
ChangeLogs in recent years; see these other mailing list discussion
threads for examples:

http://lists.gnu.org/archive/html/m4-patches/2017-01/msg00010.html
http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00904.html
http://lists.gnu.org/archive/html/emacs-devel/2016-03/msg00180.html
https://lists.gnu.org/archive/html/bug-standards/2017-07/msg0.html
https://sourceware.org/ml/libc-alpha/2017-08/msg00064.html
https://sourceware.org/ml/gdb/2018-02/msg00025.html

(Some of them cross the month boundary in the archives, so you might
have to click around more to get the whole story)

Re: Detecting superfluous "else"

[Eric Gallager]

On 7/19/18, U.Mutlu  wrote:
> Hi,
> it makes me 'crazy' when I see such if-else constructs:
>if (x)
>  return 7;
>else
>  return 4;
>
> (Of course in this case one better would use the shorthand "return x ? 7 :
> 4;", but that's not the issue here)
>
> The 'else' is obviously superfluous/redundant, ie. unneeded at all:
>if (x)
>  return 7;
>return 4;
>
> Is it possible to warn about such unneccessary occurances of "else"?
> If not, then I suggest to add a new warning code -Wsuperfluous-else or
> -Wredundant-else or so.
>
> Thx
>

Semi-related: bug 81851: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81851
(my disagreement with that request is similar to my disagreement with
this request)

Re: [RFC] Adding Python as a possible language and it's usage

[Eric Gallager]

On 7/19/18, Jeff Law  wrote:
> On 07/18/2018 03:28 PM, Segher Boessenkool wrote:
>> On Wed, Jul 18, 2018 at 11:51:36AM +0200, Richard Biener wrote:
>>> We already conditionally require Perl for building for some targets so I
>>> wonder
>>> if using perl would be better ...
>>
>> At least perl is GPL (Python is not).
>>
>>
>> What would the advantage of using Python be?  I haven't heard any yet.
>> Awk may be a bit clunky but at least it is easily readable for anyone.
> I've found python *far* easier to read than awk.  And you can actually
> run a debugger on your python code to see what it's doing.
> Jeff
>

gawk comes with a debugger, too:
https://www.gnu.org/software/gawk/manual/html_node/Debugger.html

Re: ChangeLog's: do we have to?

[Eric Gallager]

On 7/23/18, Segher Boessenkool  wrote:
> On Mon, Jul 23, 2018 at 04:03:31PM +0300, Alexander Monakov wrote:
>> Not necessarily in the source tree: individual users can put that into
>> their
>> $XDG_CONFIG_HOME/git/attributes or $HOME/.config/git/attributes.
>
> And then that user has *all* .md files treated as GCC machine description
> files.  But .md is a quite common extension.
>
>
> Segher
>

Yeah, it's usually used for markdown. This file extension clash came
up previously when trying to generate doxygen documentation for gcc
sources: https://gcc.gnu.org/ml/gcc/2017-06/msg00063.html

Re: "fall-through" errors

[Eric Gallager]

On 7/28/18, Bruce Korb  wrote:
> ../../autoopts/makeshell.c: In function ‘text_to_var’:
> ../../autoopts/makeshell.c:324:14: error: this statement may fall
> through [-Werror=implicit-fallthrough=]
>  (*(opts->pUsageProc))(opts, EXIT_SUCCESS);
>  ~^~~~
>
> This warning goes away if the comment "/* FALLTHROUGH */ is present.
> You are missing a condition:
>
> switch (which) {
> case TT_LONGUSAGE:
> (*(opts->pUsageProc))(opts, EXIT_SUCCESS);
> /* NOTREACHED */
>
> Please add the exception for a "/* NOTREACHED */" comment. Thank you.
>

I suggested gcc start recognizing "/*NOTREACHED*/" in bug 53479
comment 14 but got shot down there, too:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479#c14

Re: gcc 13.2 is missing warnings?

[Eric Gallager]

On Thu, Oct 19, 2023 at 7:52 AM Martin Uecker  wrote:
>
>
>
> Note that the C++ warning is for jumping over a declaration,
> which is generally allowed in C but not in C++.
>
> Martin

(Also note that in C, there's -Wjump-misses-init for this, which is
enabled by -Wc++-compat, which isn't enabled by anything else, and has
to be requested manually)

>
> Am Donnerstag, dem 19.10.2023 um 13:49 +0200 schrieb Martin Uecker:
> >
> >
> > GCC supports this as an extension.
> >
> > Mixing declarations and code is allowed in C99 and C23
> > will also allow placing labels before declarations and at
> > the end of a compound statement. GCC supports all this
> > also in earlier language modes.
> >
> > See:
> > https://gcc.gnu.org/onlinedocs/gcc/Mixed-Labels-and-Declarations.html
> >
> > You will get the warnings with -pedantic.
> >
> > Martin
> >
> > Am Donnerstag, dem 19.10.2023 um 07:39 -0400 schrieb Eric Sokolowsky via 
> > Gcc:
> > > I am using gcc 13.2 on Fedora 38. Consider the following program.
> > >
> > > #include 
> > > int main(int argc, char **argv)
> > > {
> > > printf("Enter a number: ");
> > > int num = 0;
> > > scanf("%d", &num);
> > >
> > > switch (num)
> > > {
> > > case 1:
> > > int a = num + 3;
> > > printf("The new number is %d.\n", a);
> > > break;
> > > case 2:
> > > int b = num - 4;
> > > printf("The new number is %d.\n", b);
> > > break;
> > > default:
> > > int c = num * 3;
> > > printf("The new number is %d.\n", c);
> > > break;
> > > }
> > > }
> > >
> > > I would expect that gcc would complain about the declaration of
> > > variables (a, b, and c) within the case statements. When I run "gcc
> > > -Wall t.c" I get no warnings. When I run "g++ -Wall t.c" I get
> > > warnings and errors as expected. I do get warnings when using MinGW on
> > > Windows (gcc version 6.3 specifically). Did something change in 13.2?
> > >
> > > Eric
> >
>

Re: Enable top-level recursive 'autoreconf'

[Eric Gallager]

On Thu, Oct 19, 2023 at 6:43 AM Thomas Schwinge  wrote:
>
> Hi!
>
> On 2023-10-19T11:57:33+0200, Andreas Schwab  wrote:
> > On Okt 19 2023, Thomas Schwinge wrote:
> >> On 2023-10-18T15:42:18+0100, R jd <3246251196r...@gmail.com> wrote:
> >>> I guess I can ask, why there is not a recursive approach for configuring
> >>> GCC. e.g. AC_SUBDIRS in the top level?
> >>
> >> ('AC_CONFIG_SUBDIRS' you mean.)  You know, often it just takes someone to
> >> ask the right questions...  ;-)
> >>
> >> What do people think about the attached
> >> "Enable top-level recursive 'autoreconf'"?  Only lightly tested, so far.
> >
> > The top-level files are shared with binutils-gdb, which has a different
> > set of subdirs.
>
> Good point, thanks!  Fortunately, the failure mode for non-existing
> directories is non-fatal (skipped with 'subdirectory [...] not present'
> diagnostic); with my original "Enable top-level recursive 'autoreconf'"
> (also re-attached) applied to Binutils/GDB Git master branch, we get:
>
> $ PATH=[...] autoreconf -v
> autoreconf: Entering directory `.'
> autoreconf: configure.ac: not using Gettext
> autoreconf: running: aclocal
> autoreconf: configure.ac: tracing
> autoreconf: configure.ac: subdirectory c++tools not present
> autoreconf: configure.ac: subdirectory fixincludes not present
> autoreconf: configure.ac: subdirectory gcc not present
> autoreconf: configure.ac: subdirectory gcc/m2 not present
> autoreconf: configure.ac: subdirectory gnattools not present
> autoreconf: configure.ac: subdirectory gotools not present
> autoreconf: configure.ac: adding subdirectory intl to autoreconf
> autoreconf: Entering directory `intl'
> [...]
> autoreconf: Leaving directory `intl'
> autoreconf: configure.ac: subdirectory libada not present
> autoreconf: configure.ac: subdirectory libatomic not present
> autoreconf: configure.ac: adding subdirectory libbacktrace to autoreconf
> autoreconf: Entering directory `libbacktrace'
> [...]
>
> So we could (a) simply list *all* directories in the shared top-level
> 'configure.ac', or (b) configure GCC vs. other projrcts via a non-shared
> file ('m4_include([config/AC_CONFIG_SUBDIRS.m4])' or similar -- is there
> an established procedure for non-shared top-level files)?  (I don't have
> a strong preference either way.)
>

I'd just like to note that I have GCC bug 103459 open about silencing
warnings from autoreconf:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103459
Although I guess in this case, they're just notices, and not warnings,
so it's probably okay. (-Werror doesn't turn them into errors, does
it?)

> It's just GCC and Binutils/GDB, or are the top-level files also shared
> with additional projects?
>
>
> 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: Deprecating -fgnu-tm support for GCC 14 and removing it for GCC 15

[Eric Gallager]

On Sat, Dec 16, 2023 at 3:16 PM Andrew Pinski via Gcc  wrote:
>
> -fgnu-tm support has not been improved since GCC 5 or earlier. It is
> not even supported with LTO. Does it make sense to deprecate the
> support for GCC 14 and remove it in GCC 15?
>
> Thanks,
> Andrew Pinski

Personally, since GCC is in stage 3 now, I would push that schedule
back a release and move deprecation to GCC 15, and then only remove it
for GCC 16 if no one objects, but then again I don't actually use
-fgnu-tm myself, so I wouldn't be too upset if the faster schedule is
chosen instead.
Eric Gallager

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

[Eric Gallager via Gcc]

On 5/25/20, Arseny Solokha  wrote:
> Hi,
>
>
>>> >> PRs from the second group were filed by me, so if there's consensus to
>>> >> close all
>>> >> of them, the ones from this second group I can close myself. I don't
>>> >> have the
>>> >> right permissions to modify PRs reported by someone else, so I'd like
>>> >> to ask a
>>> >> volunteer to step up and close the ones from the first group.
>>> >>
>>> >> WDYT?
>>> >
>>> > I can do both, if you want, or just the first group?  Your choice.
>>> >
>>> > But let's hear other opinions first.
>>>
>>> Thanks. I think I'll close the second group myself, as they constitute
>>> almost
>>> half of the total amount.
>>
>> Okido, thanks!
>
> Two full weeks have passed without any new input from either former port
> maintainer or global maintainers, so it's probably about time to go ahead
> and
> wrap it up.
>

Agreed; a reduction in the number of open bugs in my searches will be
most welcome.

WWDC thread: support for darwin/macOS going forward

[Eric Gallager via Gcc]

Hi, at Apple's WWDC this year they have announced that they are doing
yet another architecture transition, so I was wondering what exactly
would be the best way to go about adding support for it? The first
issue would be just what to call the new architecture; it seems to be
ARM-based, but there might be some proprietary extensions, so
arm-apple-darwin or aarch64-apple-darwin might not work? The next
issue would be how exactly to go about adding support for it: Apple
had arm-apple-darwin support for gcc in their version of gcc-4.2 that
I don't think they ever contributed back upstream, but that was for
iOS, so I doubt it could just be forward-ported, and even if it could,
previous attempts to grab stuff from Apple's version of gcc-4.2 have
faltered for legal reasons, so that could also be a factor here. I'm
guessing it might be better instead to just start afresh from scratch?
I'd offer to help with testing but I *just* got a new Intel-based Mac
that I haven't even managed to set up yet, so I highly doubt I'll have
any money for a new ARM-based Mac anytime soon... Anyways, I'm
interested to hear what people are thinking.

Thanks,
Eric Gallager

Re: Copyright assignment for Rust-GCC

[Eric Gallager via Gcc]

On Mon, Jan 4, 2021 at 11:13 AM David Edelsohn via Gcc 
wrote:

> On Mon, Jan 4, 2021 at 5:29 AM Nala Ginrut via Gcc 
> wrote:
> >
> > Hi Folks!
> > This mail is about the development of Rust frontend of GCC.
> >
> > To avoid misunderstanding, please let me introduce Rust-GCC briefly.
> > In 2013, Philip Herron had announced the project in GCC mailing-list:
> > https://gcc.gnu.org/legacy-ml/gcc/2013-12/msg00017.html
> > In 2019, @SimplyTheOther had contributed the almost complete parser and
> > AST.
> > And I helped to do some trivial work to make it work with the latest GCC
> > at that time.
> > Of course there are more contributors that I can't mention one by one.
> > At that time, a small community of Rust-GCC had formed. We're interested
> > in continuing it till it can be merged into GCC.
> > https://github.com/Rust-GCC/gccrs
> > So this is the brief history.
> >
> > Now we have a question, when should we assign copyright paper for GNU?
> > Last time I assigned the copyright paper, I noticed that the paper
> > mentioned the project name. But Rust-GCC hasn't been recognized by GCC
> > community yet, so I'm not sure if it's the correct time to consider this
> > issue.
> >
> > Comments are welcome.
>
> As Jeff wrote, the assignment is for the GNU Compiler Collection (GCC)
> project, not for specific languages.  One does /not/ submit separate
> assignments for GNU Fortran, GNU C++, GNU Go, GNU Ada, GNU Modula2,
> etc.
>
>
Speaking of Modula2, has that frontend made it into mainline GCC yet? I see
there was a bugzilla component for it added, but I don't remember seeing
anything about it in the changes.html file for any existing releases...


> Please have all of the developers start the FSF copyright assignment
> process now.
>
> Thanks, David
>

Re: Static analysis updates in GCC 11

[Eric Gallager via Gcc]

On Sat, Jan 30, 2021 at 2:29 AM Eric Gallager  wrote:
>
> On Thu, Jan 28, 2021 at 3:24 PM David Malcolm via Gcc  wrote:
> >
> > I wrote a blog post covering what I've been working on in the analyzer
> > in this release:
> >  
> > https://developers.redhat.com/blog/2021/01/28/static-analysis-updates-in-gcc-11/
> >
> > Hope this is of interest
> > Dave
> >
> >
>
> Thanks for the post! One nit: the post says: "Each of these
> corresponds to a pre-existing warning implemented in the C and C++
> front ends, but with a “-Wanalyzer” prefix rather than “-W.” As an
> example, -Wanalyzer-write-to-const corresponds to -Wwrite-to-const."
> There isn't actually a warning called "-Wwrite-to-const" though. There
> is "-Wwrite-strings" which is similar, but since it isn't actually a
> warning option itself (as per bug 61579), the warning flag that the
> warnings it provokes are actually issued by is -Wdiscarded-qualifiers.
> So, while I got what you meant, it still might confuse new programmers
> who might try to go using a flag called "-Wwrite-to-const" and then
> wonder why it doesn't exist.
>
> Thanks again!
> Eric

Oops I just realized I accidentally removed the mailing list from the
recipients; I'm adding that back now

Freenode changing ownership

[Eric Gallager via Gcc]

Recently I have noticed a post going around various FOSS circles about
Freenode changing hands:
https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409
I also checked the GCC wiki, and on both its main page and its
GCConIRC page it advertises an IRC channel on Freenode for GCC:
https://gcc.gnu.org/wiki and https://gcc.gnu.org/wiki/GCConIRC
Many other projects have been talking about moving their IRC channels
to other servers in wake of this ownership change; is GCC going to do
likewise? Since GCC already also has an IRC channel on OFTC, maybe the
Freenode one could be moved there as well? Of course, that would
require coming up with a new name for the one being migrated from
Freenode, so that it doesn't clash with the existing GCC channel on
OFTC... Anyways, just something to consider; let me know if the
community decides anything.
Thanks,
Eric Gallager

Re: Update to GCC copyright assignment policy

[Eric Gallager via Gcc]

On Tue, Jun 1, 2021 at 10:02 AM David Edelsohn via Gcc  wrote:
>
> GCC was created as part of the GNU Project but has grown to operate as
> an autonomous project.
>
> The GCC Steering Committee has decided to relax the requirement to
> assign copyright for all changes to the Free Software Foundation.  GCC
> will continue to be developed, distributed, and licensed under the GNU
> General Public License v3.0. GCC will now accept contributions with or
> without an FSF copyright assignment. This change is consistent with
> the practices of many other major Free Software projects, such as the
> Linux kernel.
>
> Contributors who have an FSF Copyright Assignment don't need to
> change anything.  Contributors who wish to utilize the Developer Certificate
> of Origin[1] should add a Signed-off-by message to their commit messages.
> Developers with commit access may add their name to the DCO list in the
> MAINTAINERS file to certify the DCO for all future commits in lieu of 
> individual
> Signed-off-by messages for each commit.
>
> The GCC Steering Committee continues to affirm the principles of Free
> Software, and that will never change.
>
> - The GCC Steering Committee
>
> [1] https://developercertificate.org/

One thing I'm wondering about this change is if it allows certain old
changes that previously couldn't be upstreamed to now be upstreamed?
For example, when I have asked about trying to forward-port certain
changes from Apple's old gcc-4.2 branch, I was told that one reason
this couldn't happen was because Apple hadn't assigned copyright for
those changes. Of course, there are still the technical difficulties
of the fact that 4.2 has bitrotted considerably in the years since its
last release, but regardless of those, are the legal difficulties at
least now out of the way?
Thanks,
Eric Gallager

Re: gcc plugin on MacOS failure

[Eric Gallager via Gcc]

On Thu, Jul 22, 2021 at 4:18 PM Iain Sandoe via Gcc  wrote:
>
>
>
> > On 22 Jul 2021, at 20:41, Andrew Pinski via Gcc  wrote:
> >
> > On Thu, Jul 22, 2021 at 7:37 AM Marc  wrote:
> >>
>
> >> I have a gcc plugin (for afl++,
> >> https://github.com/AFLplusplus/AFLplusplus) that works fine when
> >> compiled on Linux but when compiled on MacOS (brew install gcc) it fails:
> >>
> >> ~/afl++ $ g++-11 -g -fPIC -std=c++11
> >> -I/usr/local/Cellar/gcc/11.1.0_1/lib/gcc/11/gcc/x86_64-apple-darwin20/11.1.0/plugin/include
> >> -I/usr/local/Cellar/gcc/11.1.0_1/lib/gcc/11/gcc/x86_64-apple-darwin20/11.1.0/plugin
> >> -I/usr/local//Cellar/gmp/6.2.1/include -shared
> >> instrumentation/afl-gcc-pass.so.cc -o afl-gcc-pass.so
> >
> > A few things, You are not building the plugin with the correct options
> > for darwin.
> > Basically you need to allow undefined references
>
> -Wl, -undefined, dynamic_lookup
>
> but if you expect those to bind to the main exe (e.g. cc1plus) at runtime, 
> then you will need to build that with dynamic export. (-export_dynamic)
>
> These things will *not* transfer to arm64 macOS and they will probably 
> produce build warnings from newer linkers.
>
> ===
>
> I suspect that we will need to find a different recipe for that case 
> (possibly using the main exe as a "link library" on the plugin link line, I 
> guess).
>
> > and then also use
> > dylib as the extension.
>
> That’s a convention for shared libs but it won’t stop a plugin working (in 
> fact things like python use .so on macOS)
>
>  for pluign modules, (e.g. Frameworks) even omitting the extension completely 
> has been done.
>
> (so this is not the source of the problem)
>
> > A few other things too.  I always forgot the exact options to use on
> > Darwin really.  GNU libtool can help with that.
>
> perhaps, but I am not sure it’s maintained agressively .. so make sure to 
> check what you find is up to date.
>

It's not even maintained at all, much less aggressively; the FSF has
been looking for a maintainer for it for years, to no avail...

> cheers,
> Iain.
>

Listing deprecated targets in changes.html

[Eric Gallager via Gcc]

Hi, I see that a number of targets are going to be deprecated for GCC 12:
- m32r{,le}-linux:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579265.html
- cr16: https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579280.html
- m68k-openbsd:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579298.html
- vax-openbsd: 
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579299.html
However, none of these targets are listed in the changes page for GCC 12 yet:
https://gcc.gnu.org/gcc-12/changes.html
I would encourage people involved with these patches to list these
deprecations on the changes page ASAP, so that people can have time to
prepare for the impending deprecations.
Thanks,
Eric Gallager

Re: [FYI] bugzilla cleanup

[Eric Gallager via Gcc]

On Thu, Sep 16, 2021 at 11:45 AM Martin Sebor via Gcc  wrote:
>
> On 9/14/21 2:10 AM, Andrew Pinski via Gcc wrote:
> > Hi all,
> >I am doing some bugzilla cleanup.  This includes disabling some
> > components and some versions for new bugs.
> > So far I have disabled versions before GCC 4 because we have not had a
> > report from someone for those versions in over 7 years.  I disabled
> > some versions which are about developmental branches which are
> > inactive too.
> > I also disabled the java, libgcj, fastjar, libmudflap, treelang and
> > libf2c components.
> >
> > I am in the process of moving away from having an inline-asm component
> > to an inline-asm keyword instead; this was suggested on IRC and I
> > agree.  After the current open bugs have moved away from the
> > inline-asm component, I will disable it also.
> >
> > If anyone else has any other suggestions that should be done, please
> > let me know and I will look into doing it.
>
> Re: Keywords: I find it useful to differentiate between two kinds of
> diagnostic bugs: false positives and false negatives (the latter for
> existing warnings that don't trigger when intended, as opposed to
> requests to enhance existing warnings or add new ones). I've been
> using Personal Tags for this but it might be useful to others as
> well.  If you agree and add the corresponding new keywords
> (false-positive and false-negative) I'll set them based on my Tags.
>

Oh right, if we're promoting Personal Tags to keywords, I have one
that I think could be useful: "need-better-backtrace", for cases when
the reporter posted a backtrace, but built their GCC without debugging
symbols, meaning that the backtrace is incomplete, i.e., missing stuff
like line info and/or arguments to functions.

> One other suggestion: every once in a while someone asks if
> ice-on-invalid-code bugs apply to syntactically well-formed code that
> has undefined behavior (I don't believe it does).  It would help to
> clarify the Description for this Keyword (and, correspondingly, for
> ice-on-valid).  E.g., something like
>
> ice-on-invalid-code: ICE on code that is not syntactically valid.
> ice-on-valid-code: ICE on code that is syntactically valid.
>
> Martin

Re: Can gcc itself be tested with ubsan? If so, how?

[Eric Gallager via Gcc]

On Tue, Sep 28, 2021 at 2:48 AM Toon Moene  wrote:
>
> On 9/28/21 8:35 AM, Erick Ochoa via Gcc wrote:
>
> >> Can ubsan be used on the compiler itself?
>
> I regularly build the compiler(s) natively with ubsan enabled, see for
> instance:
>
> https://gcc.gnu.org/pipermail/gcc-testresults/2021-September/719448.html
>
> The configure line tells you how to do it (towards the end of the mail):
>
> configure flags: --prefix=/home/toon/compilers/install/gcc --with-gnu-as
> --with-gnu-ld --enable-languages=all,ada --disable-multilib
> --disable-nls --with-build-config=bootstrap-ubsan --enable-checking=all
>

To elaborate on that, to see what the --with-build-config=bootstrap-ubsan
configure flag does, you can check the file config/bootstrap-ubsan.mk

> (the enable-checking part is not relevant, and can be omitted).
>
> Kind regards,
>
> --
> Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
> Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands

Re: Generating GCC Documentation

[Eric Gallager via Gcc]

On Wed, Nov 10, 2021 at 9:26 AM Joel Sherrill  wrote:
>
> Thanks for the quick reply.
>
> On Wed, Nov 10, 2021 at 8:20 AM Jonathan Wakely  wrote:
> >
> > On Wed, 10 Nov 2021 at 14:08, Joel Sherrill wrote:
> > >
> > > Hi
> > >
> > > It's been a while since I tried this and it appears things have
> > > changed. I tried to follow the instructions at:
> > >
> > > https://gcc.gnu.org/onlinedocs/libstdc++/manual/documentation_hacking.html
> >
> > Are you asking about docs for GCC itself, or libstdc++? Those docs are
> > for the latter only.
>
> I was hoping to build everything including libstdc++.

This is something I've been meaning to work on lately; I recently did
a patch to allow the install-dvi target to work from the top-level,
and was meaning to do likewise for install-man, too... but instead I
ran into bug 102824 first, so I kinda want to get that fixed first:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102824

>
> FYI Google found that page for "generating GCC docs" and I obviously missed
> that it was C++ only. The URL has C++ and the first sentence also says that 
> but
> the section title must be more important to the search.
>
> > > with gcc 11.2 and had a few questions:
> > >
> > > + I did a simple configure --prefix=/tmp/gcc-docs the first time and
> > > then "make html". One of those told me prerequisites were missing so I
> > > downloaded them and then it proceeded to build the compiler before
> > > building the html. Is that expected? Can you build the docs without
> > > building the compiler itself?
> >
> > For libstdc++? Yes, see maintainer-scripts/generate_libstdcxx_web_docs
> >
> > For GCC itself, I am not sure, but
> > maintainer-scripts/update_web_docs_git might help.
>
> Thanks. I'll try those.
>
> > > + I was going through the formats in the order on the document. I
> > > sucessfully built html and pdf. But make man from the top of the build
> > > directory doesn't work.
> > >
> > >  make man
> > > make: *** No rule to make target `man'.  Stop.
> >
> > You seem to be trying to follow the libstdc++ docs in the top-level,
> > that's not going to work.
>
> Gotcha.

IMO it *should* work, though; `make man` is a common Makefile target
that is recognized in some of the subdirectories, which ought to be
made consistent throughout all of them.

>
> > > "make -C gcc install-man" does install some man pages so I'm guessing
> > > something is wrong with the top Makefile.
> >
> > I think you're following the wrong docs.
> >
> > At the top-level, 'make -C gcc doc' works, and so does 'make -C gcc html'
>
> Is there a top-level stanza to generate docs for everything or is just
> a sequence of commands and I need to look at the scripts?
>

I agree that having a top-level `make docs` target (and `make
install-docs` target) that does all of the other documentation targets
would be useful; feel free to open a bug on bugzilla about it, and
I'll confirm it.

> > If you really do want to build the libstdc++ docs, you need to be in
> > the $target/libstdc++-v3/ sub-directory to use the libstdc++ makefile
> > targets.
>
> OK. Plenty to digest.
>
> Thanks.
>
> --joel

Re: Help with an ABI peculiarity

[Eric Gallager via Gcc]

On Mon, Jan 10, 2022 at 8:28 AM Iain Sandoe  wrote:
>
> Hi Florian,
>
> > On 10 Jan 2022, at 08:38, Florian Weimer  wrote:
> >
> > * Jeff Law via Gcc:
> >
> >> Most targets these days use registers for parameter passing and
> >> obviously we can run out of registers on all of them.  The key
> >> property is the size/alignment of the argument differs depending on if
> >> it's pass in a register (get promoted) or passed in memory (not
> >> promoted).  I'm not immediately aware of another ABI with that
> >> feature.  Though I haven't really gone looking.
> >
> > I think what AArch64 Darwin does is not compatible with a GCC extension
> > that allows calling functions defined with a prototype without it (for
> > pre-ISO-C compatibility).
>
> AFAIU the implementation:
>
> In the case that a call is built and no prototype is available, the 
> assumption is
> that all parms are named.  The promotion is then done according to the C
> promotion rules.
>
> [for the number of args that can be passed in int regs] the callee will 
> happen to
> observe the same rules in this case.
>
> It will, however, break once we overflow the number of int regs.. :/
>
> 
>
> The case that is fundamentally broken from scratch is of a variadic function
> called without a prototype - since the aarch64-darwin ABI places unnamed
> parms differently.
>
> So that the absence of a prototype causes us to place all args as if they were
> named.
>
> 
>
> Wmissing-prototype
> Wstrict-prototypes
>
> would wisely be promoted to errors for this platform,

Relevant bugs in this area:
82922, add -Wstrict-prototypes to -Wextra:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82922
91092, Error on implicit function declarations by default:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
(and the related bugs in the "See Also", "Depends On", "Duplicates",
etc. fields for each of them)

>
> (the ABI is obviously not up for change, since it’s already on millions of 
> devices).
>
> >  Given that, anyone defining an ABI in
> > parallel with a GCC implementation probably has paused, reconsidered
> > what they were doing,
>
> My guess is that this step was omitted - i.e. the port was designed in the 
> LLVM
> framework.  I can raise a query with the ABI owners, I guess.
>
> >  and adjusted the ABI for K&R compatibility.
>
> FWIW, we bootstrap sucessfully including the K&R code in intl/
> Given we have 8 int regs available, probably many calls will work ..
>
> 
>
> As of now, I must assume that what is broken by the cases above will remain
> broken, and I just need to find a way to implement the cases that will work 
> (i.e.
> when proper prototypes are available)
>
> thanks
> Iain
>

Re: git hooks: too strict check

[Eric Gallager via Gcc]

On Fri, Jan 14, 2022 at 11:14 AM Michael Matz via Gcc  wrote:
>
> Hello,
>
> On Fri, 14 Jan 2022, Martin Liška wrote:
>
> > Hello.
> >
> > I'm working on a testsuite clean-up where some of the files are wrongly 
> > named.
> > More precisely, so files have .cc extension and should use .C. However 
> > there's
> > existing C test-case and it leads to:
> >
> > marxin@marxinbox:~/Programming/gcc/gcc/testsuite> find . -name test-asm.*
> > ./jit.dg/test-asm.C
> > ./jit.dg/test-asm.c
>
> You can't have that, the check is correct.  There are filesystems (NTFS
> for instance) that are case-preserving but case-insensitive, on those you
> really can't have two files that differ only in casing.

HFS for Macs behaves this way by default, too, for reference.

> You need to find a different solution, either consistently use .cc instead
> of .C, live with the inconsistency or rename the base name of these files.
>
>
> Ciao,
> Michael.
>
> >
> > test-kunlun me/rename-testsuite-files
> > Enumerating objects: 804, done.
> > Counting objects: 100% (804/804), done.
> > Delta compression using up to 16 threads
> > Compressing objects: 100% (242/242), done.
> > Writing objects: 100% (564/564), 142.13 KiB | 7.48 MiB/s, done.
> > Total 564 (delta 424), reused 417 (delta 295), pack-reused 0
> > remote: Resolving deltas: 100% (424/424), completed with 222 local objects.
> > remote: *** The following filename collisions have been detected.
> > remote: *** These collisions happen when the name of two or more files
> > remote: *** differ in casing only (Eg: "hello.txt" and "Hello.txt").
> > remote: *** Please re-do your commit, chosing names that do not collide.
> > remote: ***
> > remote: *** Commit: 7297e1de9bed96821d2bcfd034bad604ce035afb
> > remote: *** Subject: Rename tests in jit sub-folder.
> > remote: ***
> > remote: *** The matching files are:
> > remote: ***
> > remote: *** gcc/testsuite/jit.dg/test-quadratic.C
> > remote: *** gcc/testsuite/jit.dg/test-quadratic.c
> > remote: ***
> > remote: *** gcc/testsuite/jit.dg/test-switch.C
> > remote: *** gcc/testsuite/jit.dg/test-switch.c
> > remote: ***
> > remote: *** gcc/testsuite/jit.dg/test-asm.C
> > remote: *** gcc/testsuite/jit.dg/test-asm.c
> > remote: ***
> > remote: *** gcc/testsuite/jit.dg/test-alignment.C
> > remote: *** gcc/testsuite/jit.dg/test-alignment.c
> >
> > Can we please do something about it?
> >
> > Thanks,
> > Martin
> >

Re: No type checking in ctype builtins

[Eric Gallager via Gcc]

On Wed, Apr 27, 2022 at 12:20 PM Jonathan Wakely via Gcc
 wrote:
>
> On Wed, 27 Apr 2022 at 16:29, Andrea Monaco via Gcc  wrote:
> >
> >
> > This program
> >
> >   #include 
> >
> >   int main ()
> >   {
> > char *s;
> > isspace (s);
> >   }
> >
> > compiles with no warning in gcc 8.3.0, even though there's a type
> > mistake; the correct call would be isspace (*s).
>
> N.B. The correct call would be isspace((unsigned char)*s) because
> isspace has undefined behaviour if you pass it a char with a negative
> value.
>
> It would be nice if GCC warned about *that*.

Related bugs:
78155: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78155
99950: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99950

Re: How to regenerate aclocal.m4?

[Eric Gallager via Gcc]

On Sun, May 1, 2022 at 7:09 PM Maciej W. Rozycki  wrote:
>
> On Sat, 30 Apr 2022, Zopolis0 via Gcc wrote:
>
> > I'm trying to regenerate autotools files in liboffloadmic (and other
> > directories) but when running automake it tells me I need to run aclocal,
> > which gives me a warning about not finding AM_ENABLE_MULTILIB in library,
> > which then translates into an autoconf error. How do I fix this? Is there a
> > specific aclocal version?
>
>  You need to use the same options that automatic regeneration via `make'
> would.  They are given in ACLOCAL_AMFLAGS near the top of Makefile.am.
>
>  HTH,
>
>   Maciej

To go a bit further into detail, what's necessary is that the correct
directory is searched for macro includes. AM_ENABLE_MULTILIB is
defined in `config/multi.m4`, so you need `-I config` in the flags you
use with aclocal (or whatever the relative path to config is from your
current working directory).

Eric

Re: [RFC] Support for nonzero attribute

[Eric Gallager via Gcc]

On Sun, Jun 5, 2022 at 4:10 PM Miika via Gcc  wrote:
>
> Based on Jakub's and Yair's comments I created a new attribute "inrange".
> Inrage takes three arguments, pos min and max.
> Pos being the argument position in the function, and min and max defines the
> range of valid integer. Both min and max are inclusive and work with enums.
> Warnings are enabled with the new flag: "-Winrange".
>
> The attribute definition would look something like this:
> inrange(pos, min, max)
>
>
> So for example compiling this with "gcc foo.c -Winrange":
>
> #include 
> void foo(int d) __attribute__ ((inrange (1, 100, 200)));
> void foo(int d) {
> printf("%d\n", d == 0);
> }
>
> int main() {
> foo(0); // warning
> foo(100); // no warning
> }
>
> Would give the following error:
>
> foo.c: In function 'main':
> foo.c:8:9: warning: argument in position 1 not in rage of 100..200 [-Winrange]
> 8 | foo(0); // warning
>   | ^~~
>
>
> I thought about having separate minval and maxval attributes but I personally
> prefer that min and max values have to be defined explicitly.
>
> If this looks good, I could look into applying inrange to types and variables
> and after that I could start looking into optimization.
>

Could you take a look at bug 78155 too? There was a request to add
something like this in that bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78155
(and I think I've seen similar requests elsewhere, too)

> Patch for adding inrange is attached below
>
> Miika
>
> ---
> diff --git a/gcc/builtin-attrs.def b/gcc/builtin-attrs.def
> index 3239311b5a4..2f5732b3ed2 100644
> --- a/gcc/builtin-attrs.def
> +++ b/gcc/builtin-attrs.def
> @@ -98,6 +98,7 @@ DEF_ATTR_IDENT (ATTR_FORMAT, "format")
>  DEF_ATTR_IDENT (ATTR_FORMAT_ARG, "format_arg")
>  DEF_ATTR_IDENT (ATTR_MALLOC, "malloc")
>  DEF_ATTR_IDENT (ATTR_NONNULL, "nonnull")
> +DEF_ATTR_IDENT (ATTR_INRANGE, "inrange")
>  DEF_ATTR_IDENT (ATTR_NORETURN, "noreturn")
>  DEF_ATTR_IDENT (ATTR_NOTHROW, "nothrow")
>  DEF_ATTR_IDENT (ATTR_LEAF, "leaf")
> diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
> index ac936d5..d6dc9c37723 100644
> --- a/gcc/c-family/c-attribs.c
> +++ b/gcc/c-family/c-attribs.c
> @@ -119,6 +119,7 @@ static tree handle_novops_attribute (tree *, tree, tree, 
> int, bool *);
>  static tree handle_vector_size_attribute (tree *, tree, tree, int,
>   bool *);
>  static tree handle_nonnull_attribute (tree *, tree, tree, int, bool *);
> +static tree handle_inrange_attribute (tree *, tree, tree, int, bool *);
>  static tree handle_nonstring_attribute (tree *, tree, tree, int, bool *);
>  static tree handle_nothrow_attribute (tree *, tree, tree, int, bool *);
>  static tree handle_cleanup_attribute (tree *, tree, tree, int, bool *);
> @@ -379,6 +380,8 @@ const struct attribute_spec c_common_attribute_table[] =
>   handle_tls_model_attribute, NULL },
>{ "nonnull",0, -1, false, true, true, false,
>   handle_nonnull_attribute, NULL },
> +  { "inrange",3, 3, false, true, true, false,
> + handle_inrange_attribute, NULL },
>{ "nonstring",  0, 0, true, false, false, false,
>   handle_nonstring_attribute, NULL },
>{ "nothrow",0, 0, true,  false, false, false,
> @@ -3754,6 +3757,59 @@ handle_nonnull_attribute (tree *node, tree name,
>return NULL_TREE;
>  }
>
> +/* Handle the "inrange" attribute.  */
> +
> +static tree
> +handle_inrange_attribute (tree *node, tree name,
> + tree args, int ARG_UNUSED (flags),
> + bool *no_add_attrs)
> +{
> +  tree type = *node;
> +
> +  /* Test the position argument  */
> +  tree pos = TREE_VALUE (args);
> +  if (!positional_argument (type, name, pos, INTEGER_TYPE, 0))
> +*no_add_attrs = true;
> +
> +  /* Make sure that range args are INTEGRALs  */
> +  bool range_err = false;
> +  for (tree range = TREE_CHAIN (args); range; range = TREE_CHAIN (range))
> +{
> +  tree val = TREE_VALUE (range);
> +  if (val && TREE_CODE (val) != IDENTIFIER_NODE
> + && TREE_CODE (val) != FUNCTION_DECL)
> +   val = default_conversion (val);
> +
> +  if (TREE_CODE (val) != INTEGER_CST
> + || !INTEGRAL_TYPE_P (TREE_TYPE (val)))
> +   {
> + warning (OPT_Wattributes,
> +  "range value is not an integral constant");
> + *no_add_attrs = true;
> + range_err = true;
> +   }
> +}
> +
> +  /* Test the range arg max is not smaller than min
> + if range args are integrals  */
> +  if (!range_err)
> +{
> +  tree range = TREE_CHAIN (args);
> +  tree min = TREE_VALUE(range);
> +  range = TREE_CHAIN (range);
> +  tree max = TREE_VALUE(range);
> +  if (!tree_int_cst_le (min, max))
> +   {
> + warning (OPT_Wattributes,
> 

Re: [RFC] Support for nonzero attribute

[Eric Gallager via Gcc]

On Wed, Jun 8, 2022 at 5:00 PM Miika  wrote:
>
> On Wednesday, June 8th, 2022 at 8:42 PM, Eric Gallager  
> wrote:
> > Could you take a look at bug 78155 too? There was a request to add
> > something like this in that bug:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78155
> > (and I think I've seen similar requests elsewhere, too)
>
> I took a look at the bug and looks like the inrange attribute can be applied 
> to
> builtin functions too.
>
> So now the example code
> int main (void)
> {
> __builtin_printf ("%i\n", __builtin_isalpha (99));
> }
>
> Now gives the following error:
>
> foo.c: In function 'main':
> foo.c:3:31: warning: argument in position 1 not in rage of 0..255 [-Winrange]
> 3 | __builtin_printf ("%i\n", __builtin_isalpha (99));
>   |
>
> Miika

Nice, good to hear! I'm looking forward to seeing this get added!
Thanks,
Eric

Re: New "Diving into GCC internals" section in newbies guide

[Eric Gallager via Gcc]

On Sun, Jun 12, 2022 at 12:38 PM David Malcolm via Gcc  wrote:
>
> On Sat, 2022-06-11 at 02:35 +0200, Eric Botcazou wrote:
> > > Hope this is helpful; please let me know if you see any mistakes,
> > > or if
> > > there's room for improvement
> >
> > Nice work!  In the "inside cc1" chapter, I think that IR is usually
> > meant for
> > "Intermediate Representation" rather than "Internal Representation"
> > in this
> > context.
>
> Thanks - you're right.  I've updated the doc accordingly.
>
> Dave

For the unwritten "What’s in the GCC source tree?" page I'd just like
to note that there's a similar page in the existing GCC internals docs
in sourcebuild.texi; I updated it recently in r13-817-gda5f0cc2f51a79:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=da5f0cc2f51a791a397fd1b3cef662763897a826

Re: remove intl/ directory?

[Eric Gallager via Gcc]

On Sat, Jun 18, 2022 at 1:01 PM Bruno Haible  wrote:
>
> Hi,
>
> As the long-term GNU gettext maintainer, I would suggest to remove the intl/
> directory from the GCC distribution.
>
> The effect for the users would be:
>   * On systems without glibc, users who want an internationalized GCC
> installation would have to install GNU gettext first. Then the GCC
> binaries would be linked with the shared library libintl.so
> (unless gettext was built with --disable-shared); they would no longer
> contain the libintl code in 'cc1', 'cc1plus', etc.
>   * On systems with glibc, no change.
>
> The effect for the GCC maintainers would be:
>   * Easier to stay up-to-date with upstream libintl.
>   * Less maintenance work with *.m4 files such as
>   codeset.m4
>   glibc21.m4
>   intdiv0.m4
>   inttypes_h.m4
>   inttypes.m4
>   inttypes-pri.m4
>   lcmessage.m4
>   stdint_h.m4
>   uintmax_t.m4
>   ulonglong.m4
>   * Reduced risk of a CVE that would impact GCC binaries.
>
> Rationale:
>   * This intl/ code is from 2003; of course several bugs have been
> fixed in it over the last 19 years.
>   * At that time GNU packages were still favouring static libraries.
> GNU libtool became widely reliable only about in 2005.
>   * Since then, distros have been favouring shared libraries over
> static libraries, in order to be able to fix CVEs without
> rebuilding many dependent binaries.
>   * For this reason, GNU gettext removed the support for this way
> of packaging libintl in version 0.20 (May 2019). The NEWS entry
> said:
> - The --intl option of the gettextize program (deprecated since 2010) is
>   no longer available. Instead of including the intl sources in your
>   package, we suggest making the libintl library an optional prerequisite
>   of your package. This will simplify the build system of your package.
> - Accordingly, the Autoconf macro AM_GNU_GETTEXT_INTL_SUBDIR is gone
>   as well.
>
> This point came up while discussing with Eric Gallager, who is working on
> the GCC configury.
>

Hi, just for some additional context for anyone reading from the
archives, but this conversation came out of autoconf sr #110324:
https://savannah.gnu.org/support/?110324
My work can be seen in the
refs/users/egallager/heads/autotools-tinkering branch, which I'm also
mirroring on GitHub here:
https://github.com/cooljeanius/gcc/tree/me/autotools-tinkering
The latest pending patch I've submitted from this branch is here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596654.html
As for the underlying topic of this thread, personally I see removing
the intl/ subdirectory as just one possible solution to the issue of
its autoconf macros being outdated, the other would be to fix
autoupdate so that it can handle things properly, but I can see how
that would be harder. Whichever solution turns out to be the simplest
for everyone involved will be the one I'll support.
Thanks,
Eric

> I don't volunteer to implement this suggestion, but I can give advice where
> needed.
>
> Bruno
>

Re: remove intl/ directory?

[Eric Gallager via Gcc]

On Thu, Jun 23, 2022 at 12:25 AM Bruno Haible  wrote:
>
> Iain Sandoe wrote:
> > Yes (
> > # We can use an in-tree build of libintl.
> > if test -f  ifelse([$1],,[../gettext-runtime],[$1])/uninstalled-config.sh; 
> > then
> >   
> > relative_builddir='ifelse([$1],,[${top_builddir}/..],[$1]/..)/gettext-runtime'
> >   .  ifelse([$1],,[../gettext-runtime],[$1])/uninstalled-config.sh
> > elif test -f  ifelse([$1],,[../intl],[$1])/config.intl; then
> >   .  ifelse([$1],,[../intl],[$1])/config.intl
> > fi
> > )
> > and it works ...
>
> Good!
>
> > … although now I see some configure warnings about not being able to access 
> > build-aux (which I do not recall seeing with the previous hack - but that 
> > could be just bad memory ;) )
>
> You can get warnings if you _move_ the gettext-runtime directory so that it
> becomes a sibling directory of 'gcc'. You should *not* get warnings if you
> create a symlink, sibling of the 'gcc' directory, to the
> gettext-20220620/gettext-runtime/ directory.
>
> > FWIW this following snippet would be just as broken on macOS as other noted 
> > platforms - it would need auto-foo-provided shared lib extension - or the 
> > equivalent to be used.
> > …  is there any reason that all platforms with non-’so’ suffixes would not 
> > work with that change?
>
> On macOS (with .dylib instead of .so) it would probably work.
>
> However, AIX and HP-UX will not work, because (as I understand it) if you want
> to have a binary, say cc1, which depends on libintl, then
>   - the cc1 that accesses /usr/local/lib/libintl.$suffix
> and
>   - the cc1 that accesses 
> /home/user/build/gcc-snap/gettext-runtime/intl/.libs/libintl.$suffix
> must necessarily be different. You cannot just install the second one in
> public locations, because it will have the wrong shared library filename
> hardcoded into it. This is why on these systems, libtool has to rebuild
> executables during "make install".
>
> Anyway, you said that for GCC, the important case is to build libintl as a
> static (non-shared) library.
>
> > > There is also a GCC specific quirk, that I upstreamed into GNU gettext:
> > > https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=fdc2bd236a6a62b477c1fca4205df10b0e64266b
> >
> > IMHO we need to fix this ^ in GCC config - since gettext-runtime accepts 
> > “—with-pic” we should amend the GCC configury to pass —with-pic [to GMP et. 
> > al. as well, currently to build in-tree with host-shared, needs a manual 
> > —with-pic on the configure too]
>
> Indeed, the option '--with-pic' (from libtool) has the same effect as
> '--enable-host-shared'. If you can arrange to pass '--with-pic' instead
> of '--enable-host-shared', I can revert the addition of the option
> '--enable-host-shared' in gettext-runtime/intl from two days ago.
>
> > I think that we now need to deal with the GCC-side of the configury …
> >
> > 1) add logic [like GMP et. al.] to specify an external source of the 
> > library (when there is no-in-tree source present)
>
> Are you aware that gettext.m4 already introduces the configure options
>   --with-libintl-prefix[=DIR]  search for libintl in DIR/include and DIR/lib
>   --without-libintl-prefix don't search for libintl in includedir and 
> libdir
> ?
>

N.B. that there's already at least one issue open about those flags
that I can think of OTTOMH; it's part of the reason I wanted to go
about updating GCC configury in the first place:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78251

> Bruno
>
>
>

Re: New/improved warning option for padding bytes

[Eric Gallager via Gcc]

On Fri, Aug 19, 2022 at 6:13 AM Jonas Rahlf via Gcc  wrote:
>
> As a firmware developer I would appreciate a warning option about padding
> bytes, but only for such cases where you can reduce the number of padding
> bytes by rearranging the fields.
>
> The current -Wpadded warns about all padding bytes, which is annoying.
>
> The concept sounds simple: you rearrange all fields from large to small and
> check if the size changed.
>
> The goal is to more easily optimize RAM/flash in space constrained systems.
>
> Jonas

That sounds like bug 52981: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52981

Humor in GCC

[Eric Gallager via Gcc]

Happy April Fools' Day! In the spirit of the day, I've done a brief
survey of humor in other FOSS projects, and how they could be used as
inspiration for fun features in GCC.

* Emacs: The etc/ folder in the emacs sources has plenty of humorous
material in it, most obviously, etc/JOKES (although, some of the jokes
there can be kind of cringe). Emacs also has games included in it,
such as Tetris:
https://www.masteringemacs.org/article/fun-games-in-emacs
If emacs can have games in it, why can't GCC bring back its "play
nethack on undefined behavior" option?
* glibc: glibc has some joke functions in it, such as strfry:
https://sourceware.org/bugzilla/show_bug.cgi?id=4403
...or memfrob: 
https://www.gnu.org/software/libc/manual/html_node/Obfuscating-Data.html#Obfuscating-Data
Perhaps GCC could offer builtins for these functions? i.e.,
__builtin_strfry() and __builtin_memfrob()
* clang: clang has a flag called -fheinous-gnu-extensions:
https://stackoverflow.com/questions/19367572/what-does-fheinous-gnu-extensions-option-do
It allows for compiling code such as this:
https://opensource.apple.com/source/clang/clang-318.0.45/src/tools/clang/test/Sema/heinous-extensions-on.c.auto.html
In GCC, such a flag is unnecessary, as such casts in inline assembly
are already allowed. Thus, attempting to use the flag with actual GCC
results in the following error message:
gcc: error: unrecognized command-line option
'-fheinous-gnu-extensions'; did you mean '-fno-ms-extensions'?
However, I've thought it might be fun to special-case the error
message for this specific flag: maybe GCC could have a unique message
such as "gcc: error: GNU extensions are never heinous!" just as an
easter egg for this flag?
* sudo: sudo is notable for having configure options that will cause
it to insult you when you mistype your password:
https://askubuntu.com/questions/837558/where-are-sudos-insults-stored
Imagine if GCC had similar functionality where it would insult you
when providing compile warnings and/or errors? What might it say?
* gdb: gdb has a song: https://www.gnu.org/music/gdb-song.en.html
Perhaps GCC could have a song as well?

Anyways, just some fun food for thought on this day of foolishness;
please don't take these suggestions too seriously (unless you want
to).

Happy hacking!
Eric Gallager

Re: More C type errors by default for GCC 14

[Eric Gallager via Gcc]

On 5/9/23, Jonathan Wakely via Gcc  wrote:
> On Tue, 9 May 2023 at 23:38, Joel Sherrill wrote:
>> We are currently using gcc 12 and specifying C11.  To experiment with
>> these stricter warnings and slowly address them, would we need to build
>> with a newer C version?
>
> No, the proposed changes are to give errors (instead of warnings) for
> rules introduced in C99. GCC is just two decades late in enforcing the
> C99 rules properly!
>
>
>> What practices might the GCC community recommend to a project
>> wanting to discover the issues uncovered and slowly address them? I
>
> -Werror=implicit-int
> -Werror=implicit-function-declaration
> -Werror=int-conversion
>

Idea for a compromise: What if, instead of flipping the switch on all
3 of these at once, we staggered them so that each one becomes a
default in a separate release? i.e., something like:

- GCC 14: -Werror=implicit-function-declaration gets added to the defaults
- GCC 15: -Werror=implicit-int gets added to the defaults
- GCC 16: -Werror=int-conversion gets added to the defaults

That would give people more time to catch up on a particular warning,
rather than overwhelming them with a whole bunch all at once. Just an
idea.

>> i am a bit gun shy because I remember the move from GCC 3.3 to 3.4
>> where the improved strict alias checking gave us a LOT of warnings to
>> deal with and it felt overwhelming. I don't want to do that again.
>>
>> But I believe in letting the compiler get stricter and find things.
>> Defaulting
>> to stricter checking is a good thing.
>
> The checks are already done, they're just warnings by default, and so
> easily missed/ignored when compiling large code bases.
>

Re: More C type errors by default for GCC 14

[Eric Gallager via Gcc]

On 5/15/23, Richard Earnshaw (lists) via Gcc  wrote:
> On 10/05/2023 03:38, Eli Zaretskii via Gcc wrote:
>>> From: Arsen Arsenović 
>>> Cc: Eli Zaretskii , Jakub Jelinek ,
>>>   jwakely@gmail.com, gcc@gcc.gnu.org
>>> Date: Tue, 09 May 2023 22:21:03 +0200
>>>
 The concern is using the good will of the GNU Toolchain brand as the tip
 of
 the spear or battering ram to motivate software packages to fix their
 problems. It's using GCC as leverage in a manner that is difficult for
 package maintainers to avoid.  Maybe that's a necessary approach, but
 we
 should be clear about the reasoning.  Again, I'm not objecting, but
 let's
 clarify why we are choosing this approach.
>>>
>>> Both the GNU Toolchain and the GNU Toolchain users will benefit from a
>>> stricter toolchain.
>>>
>>> People can and have stopped using the GNU Toolchain due to lackluster
>>> and non-strict defaults.  This is certainly not positive for the brand,
>>> and I doubt it buys it much good will.
>>
>> It is not GCC's business to force developers of packages to get their
>> act together.  It is the business of those package developers
>> themselves.  GCC should give those developers effective and convenient
>> means of detecting any unsafe and dubious code and of correcting it as
>> they see fit.  Which GCC already does by emitting warnings.  GCC
>> should only error out if it is completely unable to produce valid
>> code, which is not the case here, since it has been producing valid
>> code for ages.
>>
>> It is a disservice to GCC users if a program that compiled yesterday
>> and worked perfectly well suddenly cannot be built because GCC was
>> upgraded, perhaps due to completely unrelated reasons.  It would be a
>> grave mistake on the part of GCC to decide that part of its mission is
>> to teach package developers how to write their code and when and how
>> to modify it.
>
> That argument doesn't really wash.  We already upgrade the 'default'
> language version (-std=...) from time to time and that can impact
> existing programs (eg we changed from gnu-inline to std-inline model).
>
> If this really isn't legal C, then my suggestion would be to tie this to
> a setting of -std, so -std=c2 would default to being more
> aggressive in enforcing this (via changing the warning to -werror=) and
> then -std=gnu2 might follow a bit behind that.
> Furthermore, we can trail this aggressively in release notes so that
> nobody can really claim to be surprised.
>

I support this plan for using -Werror= and having it be split based on
whether -std= is set to a strict ANSI option or a GNU option; is there
a way to do that in the optfiles, or would it have to be handled at
the specs level instead?

> At some point that std setting will become the default and the overall
> goal is achieved.
>
> R.
>

Re: Warning specifically for a returning noreturn

[Eric Gallager via Gcc]

On Wed, Jul 5, 2023 at 7:28 AM Jonathan Wakely via Gcc  wrote:
>
> On Wed, 5 Jul 2023 at 12:01, Julian Waters via Gcc  wrote:
> >
> > I see, thanks Andrew.
> >
> > Anyone else have opinions on this besides Liu or Andrew? The responses have
> > been surprisingly quiet thus far
>
> IMHO all warnings should have an option controlling them, so that you
> can disable them via pragmas.
>

This is bug 44209, for reference:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209

> But I agree that you shouldn't need to return from a noreturn
> function, it can either throw or use __builtin_unreachable() on the
> line where you currently return.
>
>
> >
> > best regards,
> > Julian
> >
> > On Wed, 5 Jul 2023, 09:40 Andrew Pinski,  wrote:
> >
> > > On Tue, Jul 4, 2023 at 6:32 PM Julian Waters 
> > > wrote:
> > > >
> > > > Hi Andrew, thanks for the quick response,
> > > >
> > > > What if the method has a return value? I know it sounds
> > > counterintuitive, but in some places HotSpot relies on the noreturn
> > > attribute being applied to methods that do return a value in an 
> > > unreachable
> > > code path. Does the unreachable builtin cover that case too?
> > >
> > > It is wrong to use noreturn on a function other than one which has a
> > > return type of void as documented.
> > >
> > > https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-noreturn-function-attribute
> > > :
> > > ```
> > > It does not make sense for a noreturn function to have a return type
> > > other than void.
> > > ```
> > >
> > > Thanks,
> > > Andrew Pinski
> > >
> > >
> > > >
> > > > best regards.
> > > > Julian
> > > >
> > > > On Wed, Jul 5, 2023 at 9:07 AM Andrew Pinski  wrote:
> > > >>
> > > >> On Tue, Jul 4, 2023 at 5:54 PM Julian Waters via Gcc 
> > > wrote:
> > > >> >
> > > >> > Hi all,
> > > >> >
> > > >> > Currently to disable the warning that a noreturn method does return,
> > > it's
> > > >> > required to disable warnings entirely. This can be very inconvenient
> > > when
> > > >> > -Werror is enabled with a noreturn method that isn't specifically
> > > calling
> > > >> > something like std::abort() at the end, when one wants all other
> > > -Wall and
> > > >> > -Wextra warnings to be reported, for instance in the Java HotSpot VM
> > > (which
> > > >> > I'm currently adapting to compile with gcc on all supported
> > > platforms). Is
> > > >> > there a possibility we can add a disable warning option specifically
> > > for
> > > >> > this case? Something like -Wno-returning-noreturn. I'm interested in
> > > adding
> > > >> > this myself if it's not convenient for gcc's maintainers to do so at
> > > the
> > > >> > moment, but I'd need some guidance on where to look and what the
> > > relevant
> > > >> > code is
> > > >>
> > > >> You could just add
> > > >> __builtin_unreachable(); (or std::unreachable(); if you are C++23 or
> > > >> unreachable() if you are using C23).
> > > >> Or even add while(true) ;
> > > >>
> > > >> I am pretty sure not having an option is on purpose and not really
> > > >> interested in adding an option here because of the above workarounds.
> > > >>
> > > >> Thanks,
> > > >> Andrew Pinski
> > > >>
> > > >> >
> > > >> > best regards,
> > > >> > Julian
> > >

Re: GNU Tools Cauldron 2024

[Eric Gallager via Gcc]

On Tue, Mar 5, 2024 at 11:01 PM Bradley M. Kuhn via Gcc  wrote:
>
> Jeremy, David, Carlos, and the GCC Community,
>
> Jeremy Bennett wrote yesterday:
> > We are starting to put together the plans for this year's Cauldron.  We
> > have a suggested date of 13-15 September, the weekend before LPC.
>
> > We have not finalized a host for the meeting. If you wish to host, please
> > let me, David Edelsohn, Carlos O'Donnell or Jan Hubicka know ASAP.
>
> During the open session at the of Cauldron in 2023, I offered that Software
> Freedom Conservancy could offer hosting for a “Cauldron USA” — in conjunction
> with the annual FOSSY (Free and Open Source Software Yearly) conference that
> we organize and host in each year in Portland, Oregon, USA.
>
> There seemed some interest to that.  We're just a few days away from
> finalizing the date and venue for FOSSY.  It's similar to FOSDEM in
> that we organize and pay for the venue, handle on-site logistics, and
> provide the usual logistics — and then volunteers need to handle review
> of talk proposals for the track and be on site to introduce speakers, etc.
>
> This would be different dates (it's likely to be in mid-to-late northern
> hemisphere summer), and in the USA, so it would complement the usual
> Cauldron.
>
> Let me know if any of you are interested in this, and I can put you in touch
> with the staff at SFC who orgainze FOSSY.
>
> Let me know!

Hi, I would greatly appreciate a US option, and having it in Portland
would be especially convenient for me, as then I could stay with
family, so I would like to express my interest in it and would hope
that such an option can go forwards

> --
> Bradley M. Kuhn - he/them
> Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
> 
> Become a Conservancy Sustainer today: https://sfconservancy.org/sustainer

Re: [RFC] add regenerate Makefile target

[Eric Gallager via Gcc]

On Fri, Mar 15, 2024 at 4:53 AM Christophe Lyon via Gcc  wrote:
>
> On Thu, 14 Mar 2024 at 19:10, Simon Marchi  wrote:
> >
> >
> >
> > On 2024-03-13 04:02, Christophe Lyon via Gdb wrote:
> > > Hi!
> > >
> > > After recent discussions on IRC and on the lists about maintainer-mode
> > > and various problems with auto-generated source files, I've written
> > > this small prototype.
> > >
> > > Based on those discussions, I assumed that people generally want to
> > > update autotools files using a script similar to autoregen.py, which
> > > takes care of running aclocal, autoheader, automake and autoconf as
> > > appropriate.
> > >
> > > What is currently missing is a "simple" way of regenerating other
> > > files, which happens normally with --enable-maintainer-mode (which is
> > > reportedly broken).  This patch as a "regenerate" Makefile target
> > > which can be called to update those files, provided
> > > --enable-maintainer-mode is used.
> > >
> > > I tried this approach with the following workflow for binutils/gdb:
> > > - run autoregen.py in srcdir
> > > - cd builddir
> > > - configure --enable-maintainer-mode
> > > - make all-bfd all-libiberty regenerate -j1
> > > - for gdb: make all -C gdb/data-directory -j1
> > > - make all -jXXX
> > >
> > > Making 'all' in bfd and libiberty is needed by some XXX-gen host
> > > programs in opcodes.
> > >
> > > The advantage (for instance for CI) is that we can regenerate files at
> > > -j1, thus avoiding the existing race conditions, and build the rest
> > > with -j XXX.
> > >
> > > Among drawbacks:
> > > - most sub-components use Makefile.am, but gdb does not: this may make
> > >   maintenance more complex (different rules for different projects)
> > > - maintaining such ad-hoc "regenerate" rules would require special
> > >   attention from maintainers/reviewers
> > > - dependency on -all-bfd and all-libiberty is probably not fully
> > >intuitive, but should not be a problem if the "regenerate" rules
> > >are used after a full build for instance
> > >
> > > Of course Makefile.def/Makefile.tpl would need further cleanup as I
> > > didn't try to take gcc into account is this patch.
> > >
> > > Thoughts?
> >
> > My first thought it: why is it a Makefile target, instead of some script
> > on the side (like autoregen.sh).  It would be nice / useful to be
> > able to it without configuring / building anything.  For instance, the
> > autoregen buildbot job could run it without configuring anything.
> > Ideally, the buildbot wouldn't maintain its own autoregen.py file on the
> > side, it would just use whatever is in the repo.
>
> Firstly because of what you mention later: some regeneration steps
> require building host tools first, like the XXX-gen in opcodes.
>
> Since the existing Makefiles already contain the rules to autoregen
> all these files, it seemed natural to me to reuse them, to avoid
> reinventing the wheel with the risk of introducing new bugs.
>
> This involves changes in places where I've never looked at before, so
> I'd rather reuse as much existing support as possible.
>
> For instance, there are the generators in opcodes/, but also things in
> sim/, bfd/, updates to the docs and potfiles. In gcc, there's also
> something "unusual" in fixincludes/ and libgfortran/
>
> In fact, I considered also including 'configure', 'Makefile.in',
> etc... in the 'regenerate' target, it does not seem natural to me to
> invoke a script on the side, where you have to replicate the behaviour
> of existing Makefiles, possibly getting out-of-sync when someone
> forgets to update either Makefile or autoregen.py. What is currently
> missing is a way to easily regenerate files without having to run a
> full 'make all' (which currently takes care of calling autoconf &
> friends to update configure/Makefile.in).
>
> But yeah, having to configure before being able to regenerate files is
> a bit awkward too :-)
>
>
> >
> > Looking at the rule to re-generate copying.c in gdb for instance:
> >
> > # Make copying.c from COPYING
> > $(srcdir)/copying.c: @MAINTAINER_MODE_TRUE@ $(srcdir)/../COPYING3 
> > $(srcdir)/copying.awk
> >awk -f $(srcdir)/copying.awk \
> >< $(srcdir)/../COPYING3 > $(srcdir)/copying.tmp
> >mv $(srcdir)/copying.tmp $(srcdir)/copying.c
> >
> > There is nothing in this code that requires having configured the source
> > tree.  This code could for instance be moved to some
> > generate-copying-c.sh script.  generate-copying-c.sh could be called by
> > an hypothetical autoregen.sh script, as well as the copying.c Makefile
> > target, if we want to continue supporting the maintainer mode.
> Wouldn't it be more obscure than now? Currently such build rules are
> all in the relevant Makefile. You'd have to open several scripts to
> discover what's involved with updating copying.c
>

Yeah I agree that it's good to keep all build rules in the Makefile;
if there's a possibility of something changing, things that depend
up

Re: [RFC] add regenerate Makefile target

[Eric Gallager via Gcc]

On Tue, Mar 19, 2024 at 2:10 PM Tom Tromey  wrote:
>
> > not sure if the current autoregen.py is in sync with that?
>
> I'm curious why "autoreconf -f" is insufficient.
> It seems to me that this should work.

`autoreconf -f` works fine in individual subdirectories, the problem
is that the top-level configure.ac doesn't use the AC_CONFIG_SUBDIRS
macro to specify its subdirectories, but rather uses its own
hand-rolled method of specifying subdirectories that autoreconf
doesn't know about. This means that autoreconf won't automatically
recurse into all the necessary subdirectories by itself automatically,
and instead has to be run manually in each subdirectory separately.
Also the various subdirectories are inconsistent about whether they
have a rule for running it (autoreconf) from the Makefile or not,
which usually comes down to whether the subdirectory uses automake for
its Makefile or not (the top-level Makefile doesn't; it uses its own
weird autogen-based regeneration method instead, which means that it
misses out on all the built-in rules that automake would implicitly
generate, including ones related to build system regeneration).

>
> > Also... I discovered the existence of an automake rule:
> > am--refresh which IIUC is intended to automake the update of Makefile
> > and its dependencies.
>
> Don't use that rule directly.  It's an implementation detail and
> shouldn't be relied on.
>
> thanks,
> Tom

Re: SARIF support in GCC: wiki page and BZ keyword

[Eric Gallager via Gcc]

On Fri, Jun 21, 2024 at 12:12 PM David Malcolm via Gcc  wrote:
>
> I've create a wiki page to track our support for GCC:
>   https://gcc.gnu.org/wiki/SARIF
>
> and a keyword "SARIF" in our bugzilla instance for bugs relating to it
> (see links on the above page).
>

Hi, thanks for creating these. Since "SARIF" is a keyword, what
component should bugs using it generally go under?
Thanks,
Eric

> Dave
>

Re: Simple GCC projects page

[Eric Gallager via Gcc]

On Sun, Aug 18, 2024 at 8:21 AM Gerald Pfeifer  wrote:
>
> On Tue, 20 Mar 2018, Christopher Higgs via gcc wrote:
> > If this belongs in a different mailbox, please let me know where it
> > should be sent.
>
> This was the right address, though sadly it somehow fell through the
> cracks originally.
>
> > I would like to start contributing to GCC. In viewing the relevant pages
> > it became clear that they have not been updated for some time, which
> > makes starting to contribute a bit more challenging.
> >
> > To name a few on the Simple GCC projects page:1. A few references are
> > made to the java front-end.
>
> Indeed, and this is something we (specifically Eric) addressed, together
> with various other issues on this page.
>
> > Under code cleanliness, the bullet for enormous files lists files in the
> > 150-500K sizes. These sizes are not current and there are at least a
> > couple of files in the MB range (the C++ parser.c file for example).
>
> Eric updated these as well, alas some have further grown; I'll see to do a
> new tally and update that.
>
> > Simplifying parser action code. GCC seems to have migrated away from
> > parser generators in favor of ad hoc approaches. Does this project still
> > apply?
>
> I don't think so, and will push a patch to remove this and associated
> items in a minute.
>
> A belated thank you for your feedback; I'll be looking for further issue
> and will happily look into anything else you may find.
>

Oh yeah, I remember there being a few other projects on there that I
also remember feeling unsure about how relevant they still were;
definitely let us know if you find anything else that seems
outdated...

> Gerald

Re: gcc-wwwdocs branch python-formatting created. e1e17c97a8ae35cfb6b2f7428fb52b05f82450d1

[Eric Gallager via Gcc]

On Thu, Aug 22, 2024 at 1:27 PM Gerald Pfeifer  wrote:
>
> On Mon, 19 Aug 2024, Eric Gallager via Gcc-cvs-wwwdocs wrote:
> > This is an automated email from the git hooks/post-receive script. It was
> > generated because a ref change was pushed to the repository containing
> > the project "gcc-wwwdocs".
> >
> > The branch, python-formatting has been created
> > at  e1e17c97a8ae35cfb6b2f7428fb52b05f82450d1 (commit)
> >
> > - Log -
> > ---
>
> Hmm, are you intentionally creating a branch for the wwwdocs repository
> (i.e., our web pages)? I don't recall us having used one before.
>

Sorry about that, I'd meant to create it just for my copy of the repo
that's mirrored to GitHub, but pushed it to the wrong remote by
accident.

> If you have any Python-related fixes, go ahead I'd say.
>

Right now it's just silencing some flake8 warnings:
https://github.com/cooljeanius/gcc-wwwdocs/pull/2
However, I'm also curious about using some other automated python code
quality tools... for example, there are autopep8 and black for python
auto-formatting, but the two of them conflict on the styles they
enforce, so I'm wondering, would one be preferred over the other?

> Gerald

Re: #pragma once behavior

[Eric Gallager via Gcc]

On Sat, Sep 7, 2024 at 5:34 AM Richard Biener via Gcc  wrote:
>
>
>
> > Am 07.09.2024 um 07:27 schrieb Jeremy Rifkin :
> >
> > 
> >>
> >> This is why I said what is the a same file if you can't rely on inodes 
> >> working?
> >
> > I don't have a good answer for such a case. Of course, no matter how one
> > approaches #pragma once there will be cases that aren't handled.
> >
> > The criteria to optimize for, imo, is which has the most clear failure
> > mode. Contents happening match could occur naturally without realizing,
> > which is hard to triage. Mtimes colliding could easily happen without
> > realizing, which is also hard to triage and reproduce. Path issues pop
> > up as real build systems use links. Mtime can fail on multiple mounts,
> > path certainly will. In my opinion, the failure modes for contents and
> > mtime are very sub-ideal. Path isn't adequate, it seems clear supporting
> > links is an important goal.
> >
> > To level-set: I don't think it's reasonable to expect #pragma once to
> > handle multiple distinct copies of the same file. Especially given that
> > contents isn't an option.
> >
> > The failure mode of inodes, however, is a lot clearer. It breaks with
> > things like multiple mounts and filesystems that don't have inodes. The
> > way I see it, advice to users becomes clear since it's much clearer
> > exactly how and why #pragma once might break.
> >
> >> Early 2000s vs now have a different landscape when it comes to file 
> >> systems.
> >
> > Given the landscape today, could it make sense to re-evaluate mtime + 
> > content?
>
> I’d rather drop the feature - IIRC it’s already deprecated and I’d oppose 
> standardization
> as doing so doesn’t make much sense given all the above issues and there is a 
> working
> solution - include guards.  What can pragma once do that include guards 
> can‘t?  What’s
> the issue to solve?  Include guard collisions?  That’s a much better 
> understood failure
> mode than indodes, hardlinks or mtime.

IMO if GCC is going to focus harder on include guards as the preferred
method of dealing with these sorts of problems, then it would make
sense to prioritize adopting some of clang's diagnostics regarding
include guards, for example, -Wheader-guard, as requested in bug
96842: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96842


>
> Richard
>
> > Cheers
> > Jeremy
> >
> > On Sep 6 2024, at 10:29 pm, Andrew Pinski  wrote:
> >
>  On Fri, Sep 6, 2024, 7:42 PM Jeremy Rifkin  wrote:
> >>>
>  Hi Andrew,
>  Thanks for the thoughts and quick reply.
> 
> > Not always. because inodes are not always stable on some file systems.
> > And also does not work with multi-mounted devices too.
> 
>  Unusual filesystems and multiple mounts are indeed the failing. As I
>  mentioned, there's no silver bullet; they each have pitfalls. I do,
>  however, think this is a less surprising failure mode than GCC's which
>  rears its head in surprising and inconsistent cases.
> 
> > I say if the file has the same content, then it is the same file and
> > GCC uses that definition.
> 
>  GCC doesn't use this definition, really. It's relying primarily on the
>  mtime check and only falling back to contents in case of collision.
> 
>  The point on same contents contents == same file is well received. When
>  I wrote the first draft of my paper I wrote it proposing this, however,
>  I have become convinced this isn't the right approach based on examples
>  where you could intend to include two files with the same contents that
>  actually mean different things (such as Example 1).
> 
>  GCC's approach is hybrid, half relying on something from the filesystem
>  and half relying on the contents. As far as I can tell this can lead to
>  a worst of both worlds.
> 
> > GCC definition is the only one which supports all issues described
> > here dealing with inodes (sometimes being non-stable), canonical paths
> > and both kinds of links and even re-mounted file systems.
> 
>  I'd initially been thinking of a content-based solution in order to
>  avoid any filesystem reliance and support multiple mounts etc. The
>  problem currently is even GCC's approach, which has the best chance of
>  working on multiple mounts, doesn't work consistently due to potential
>  differences in mtime resolution.
> 
> > What does the other implementations say about changing their
> > definition of what "the same file is"? Have you asked clang and MSVC
> > folks?
> 
>  I've not yet asked. If I proceed with a proposal paper what I'll most
>  likely be proposing is what Clang does, worded in terms of same device
>  same location. I started here since GCC's approach is least similar to
>  that than what MSVC does. It's also easier to reach out to
>  developers on
>  open source projects.
> >>
> >> Except the clang solution does

Re: Update bootstrap requirement to C++14?

[Eric Gallager via Gcc]

On Sat, Sep 14, 2024 at 11:53 AM Jason Merrill via Gcc  wrote:
>
> We moved to a bootstrap requirement of C++11 in GCC 11, 8 years after
> support was stable in GCC 4.8.
>
> It is now 8 years since C++14 was the default mode in GCC 6 (and 9 years
> since support was complete in GCC 5); perhaps it's time to update?
>

Can we flip the switch from -Wno-narrowing to -Wnarrowing while at it, too?

> IIRC I've previously suggested this in response to a couple of different
> patches that could have been simplified in C++14, but am failing to find
> those messages now.
>
> Jason

Re: Is -Wtraditional obsolete?

[Eric Gallager via Gcc]

On Wed, Oct 16, 2024 at 2:52 PM Arsen Arsenović via Gcc  wrote:
>
> Eli Zaretskii via Gcc  writes:
>
> > Please don't remove the support for -Wtraditional if it's easy to fix.
> > Removing it runs risk of breaking someone's program, so unless keeping
> > it is a real dumper on GCC development, I hope you will keep it.
>
> ISTM that it is proposed to ignore rather than reject Wtraditional, and
> as a warning option, it should be incosequential to parsing and codegen,
> so risk of breakage is minimal or nonexistent, save for the change in
> workflow caused by it not being effective.
> --
> Arsen Arsenović

One thing about -Wtraditional is that it enables a lot of different
messages, so I always thought it would make more sense as an umbrella
warning that just enables a bunch of sub-warning flags. While many of
the individual sub-warnings may no longer be relevant, some of them
might still be useful for reasons besides compatibility with
traditional C.

Re: Is -Wtraditional obsolete?

[Eric Gallager via Gcc]

On Wed, Oct 16, 2024 at 4:29 PM Joseph Myers  wrote:
>
> On Wed, 16 Oct 2024, Eric Gallager via Gcc wrote:
>
> > One thing about -Wtraditional is that it enables a lot of different
> > messages, so I always thought it would make more sense as an umbrella
> > warning that just enables a bunch of sub-warning flags. While many of
> > the individual sub-warnings may no longer be relevant, some of them
> > might still be useful for reasons besides compatibility with
> > traditional C.
>
> A few are also controlled by other options (I'm not proposing doing
> anything with -Wtraditional-conversion or -Wlong-long, for example).  I
> don't think any of the others are likely to be of use.
>
> "non-static declaration of %q+D follows static declaration"
> "traditional C lacks a separate namespace for labels, identifier %qE 
> conflicts"
> "traditional C rejects ISO C style function definitions"
> "traditional C rejects string constant concatenation"
> "traditional C rejects the unary plus operator"
> "traditional C rejects automatic aggregate initialization"
> "traditional C rejects initialization of unions"
> "% switch expression not converted to % in ISO C"
> "the meaning of %<\\%c%> is different in traditional C"
> "the meaning of %<\\x%> is different in traditional C"
> "the meaning of %<\\a%> is different in traditional C"
> "suggest not using %<#elif%> in traditional C"
> "traditional C ignores %<#%s%> with the %<#%> indented"
> "suggest hiding %<#%s%> from traditional C with an indented %<#%>"

This is one of the things I tested when adding gcc.dg/pragma-diag-7.c
in r8-787-g4287da829c9697:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=4287da829c9697c58131666447bf8f707bd8b635

> "traditional C rejects the %<%.*s%> suffix"

Some coding style guidelines dislike suffixed constants; for example,
see this passage from GCC's own README.Portability:

Suffixes on Integer Constants
-

You should never use a 'l' suffix on integer constants ('L' is fine),
since it can easily be confused with the number '1'.

> "function-like macro %qs must be used with arguments in traditional C"

This one just makes sense as a style guideline to me, and it would be
good if GCC's own fix-it hint system paid attention to it, as per bug
81419: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81419

> "macro argument %qs would be stringified in traditional C"

This one I added a test for in gcc.dg/pragma-diag-7.c due to having
seen it in real code; see r8-4796-g34b81eb96cd1df:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=34b81eb96cd1df28d7f878bc1f3df607746507da

>
> If someone thinks one of these is desirable as a coding style warning
> without regard for traditional C, please explain why.  Or if you do have
> code you'd like to build with both GCC 15 or later, and a pre-C89
> compiler, please give details.  Such details are much more relevant than
> pure speculation that maybe something could be of use to someone.
>
> --
> Joseph S. Myers
> josmy...@redhat.com
>

Re: Sourceware forge experiment

[Eric Gallager via Gcc]

On Sun, Oct 20, 2024 at 9:27 PM Mark Wielaard  wrote:
>
> As an experiment Sourceware is now running an forgejo v9 instance at
> https://forge.sourceware.org
>
> Everybody with an @sourceware.org, @cygwin.com or @gcc.gnu.org address
> can register an account (please use the same user name as your account
> name).
>
> The setup has disabled most "extras" (no badges, stars, issues, wikis,
> packages, timetracking, milestones, etc.). And users can only fork
> existing repos (it has mirrors of various sourceware projects).

Is the intent to get mirrors of all of them on there at some point?
I'm only seeing a few at the moment...

> Some things haven't been setup yet (external trackers/bugzilla, incoming
> email, ci, etc.)

I was able to get the link to an external tracker (the gcc bugzilla)
set up in my "gcc-mirror" fork:
https://forge.sourceware.org/egallager/gcc-mirror

>
> The full setup can be found in this git repository:
> https://sourceware.org/cgit/forge/
>
> For now it is only open for existing maintainers/developers for
> experimentating with a pull-request model.

So, I tested this out: I forked the gcc-mirror and gcc-wwwdocs-mirror
repos, but it looks like the mirror ones aren't accepting PRs at the
moment, so I tried forking their "-TEST" variants, but it looks like
it won't let me make a fork of the "-TEST" copy since I already have a
fork of the "-mirror" one? When I click the "fork" button on one of
the "-TEST" repos, it just redirects me back to my existing "-mirror"
fork of the corresponding "-mirror" one...

> We can add others as long as they understand this is an experiment
> and does not mean projects are accepting patches through it.
> Contributions should still be sent through the mailinglists.
>
> There is also a new mailinglist for discussion about the setup and the
> best way to create a pull-request workflow. Please subscribe if you
> create an account and mention which project/organization you would
> like do some experiments for. We can then add you to that organization.
>

...is subscribing necessary? I'm trying to limit my subscriptions...

> https://sourceware.org/mailman/listinfo/forge

Re: On pull request workflows for the GNU toolchain

[Eric Gallager via Gcc]

On Mon, Sep 23, 2024 at 8:09 AM Thomas Koenig via Gcc  wrote:
>
> [For the fortran people: Discussion on gcc@]
>
> Just a general remark.
>
> There are people, such as myself, who regularly mess up
> their git repositories because they have no mental model
> of what git is doing (case in point: The Fortran unsigned
> branch, which I managed to put into an unrepairable state
> despite considerable help from people who tried to help me
> fix it).

As one such person who has messed up his fork of GCC, I'd just like to
note that in my particular case at least, I messed it up because I was
trying to apply GitHub's model for git usage, while the GCC project
has a very different model for git usage, and the two don't exactly
play very well with one another. I see switching to a pull request
model as reducing the chances of people getting their forks into
unusable states, rather than increasing it.

> This is especially true of volunteer maintainers,
> who are still the mainstay of gfortran.
>
> Whatever you end up doing, consider such maintainers, and
> if they still can contribute or would simply give up.
> If what you end up doing is too complicated, it may end up
> severely impacting the gfortran project (and possibly others).
>
> Best regards
>
> Thomas
>
>
>

Re: Passing a hidden argument in a dedicated register

[Eric Gallager via Gcc]

On Mon, Dec 16, 2024 at 11:43 AM Alexander Monakov  wrote:
>
>
> On Mon, 16 Dec 2024, Florian Weimer via Gcc wrote:
>
> > I would like to provide a facility to create wrapper functions without
> > lots of argument shuffling.  To achieve that, the wrapping function and
> > the wrapped function should have the same prototype.  There will be a
> > trampoline that puts additional data somewhere (possibly including the
> > address of the wrapped function, but that interpretation is up to the
> > wrapping function) and then transfers control to the wrapper function
> > with an indirect jump (tail call).
> >
> > For signal safety, I think the hidden argument needs to be in a register
> > (instead of, say, thread-local storage).  Most System V ABI variants
> > seem to reserve a register for use by the dynamic linker, or for the
> > static chain pointer of nested functions.
> >
> > Is there a way to reuse either register for this purpose and assign it
> > to a local variable reliably at the start of the wrapper function
> > implementation?
>
> Not in a way that will work with LLVM, I'm afraid, and with GCC
> you'll have to shield wrappers from LTO:
>
> register void *r10 asm("r10");
> void f(int, int);
> void f_wrap(int a, int b)
> {
> r10 = f;
> f(a, b);
> }
>
> LLVM refuses to translate this. With GCC you must compile with -ffixed-r10,
> otherwise r10 is not reserved, and GCC will warn:
>
>  warning: call-clobbered register used for global register variable
> 1 | register void *r10 asm("r10");
>   |^~~:
>

It would be nice if this warning message would mention the -ffixed-r10
flag, to help users figure out what precisely they're supposed to do
about it.

>
> This is the only approach I'm aware of, apart of generating wrappers
> in asm (speaking of, is there some reason that wouldn't work for you?).
>
> HTH
> Alexander