Re: Should GCC provide __builtin_memcpy_inline like clang does?

[Gabriel Ravier via Gcc]

On 1/19/21 12:33 PM, unlvsur unlvsur via Gcc wrote:
I think __builtin_memmove_inline, __builtin_memset_inline can also get 
provided.


That allows better performance for small size copies


Manual tweaking like that seems a bit ridiculous except in very narrow 
situations, and just letting GCC assume there is an implementation of 
memset/memmove lets it do optimization based on copy size by default. I 
guess there could be some value to such an extension for portably doing 
such specific micro-optimizations manually, though.



and allowing memcpy to be usable without libc.
You can just define it yourself, don't worry, GCC won't mind (as long as 
it has the correct semantics). Even for the narrow case of memmove, 
which could be mildly inconvenient to implement in less than 10 lines on 
a few systems that have non-trivial pointers (i.e. `source < 
destination` doesn't work as expected), you're on freestanding, so you 
should be able to make some kind of working implementation by using 
non-standard stuff for that specific purpose.

Re: problems with memory allocation and the alignment check

[Gabriel Ravier via Gcc]

On 2/22/21 10:37 AM, Michael J. Baars wrote:

On Mon, 2021-02-22 at 01:29 -0800, Andrew Pinski wrote:

On Mon, Feb 22, 2021 at 1:17 AM Michael J. Baars
 wrote:

Hi,

I just wrote this little program to demonstrate a possible flaw in both malloc 
and calloc.

If I allocate a the simplest memory region from main(), one out of three 
optimization flags fail.
If I allocate the same region from a function, three out of three optimization 
flags fail.

Does someone know if this really is a flaw, and if so, is it a gcc or a kernel 
flaw?

There is no flaw.  GCC (kernel, glibc) all assume unaligned accesses
on x86 will not cause an exception.

Is this just an assumption or more like a fact? I agree with you that byte 
aligned is more or less the same as unaligned.
IIRC it's a fact, unless you change EFLAGS to enable the unaligned 
access exception flag, which is forbidden by the ABI.

Thanks,
Andrew


Regards,
Mischa.

Re: IEEE Interchange floating point and extended floating point for C++

[Gabriel Ravier via Gcc]

On 3/11/21 1:56 PM, Jonathan Wakely via Gcc wrote:

On Thu, 11 Mar 2021 at 09:43, Kito Cheng via Gcc  wrote:

Hi:

Would it be possible to support interchange floating point and/or
extended floating point for C++, which is introduced by ISO/IEC TS
18661-3?

I've read the note about C++ support from the initial commit log[1],
so I know there is some concern about C++ support for that, is it
possible to enable that for C++ like a language extension for C++?

The main demand comes from the data type for half-precision, ISO/IEC
TS 18661-3 is the only common spec which supports half-precision and
both GCC and clang are supported.

However it can't be used on C++ for GCC, so it's hard to use that as a
workable solution for half-precision data types.

Or maybe ISO/IEC JTC1 SC22 WG14 N2016[2] is a better way for
half-precision data types?

See https://wg21.link/p1467 and https://wg21.link/p1467 for the
relevant C++ proposals.

Isn't that the same link two times ?

Re: [RFC] Appropriate portable data type for IEEE half-precision on C/C++

[Gabriel Ravier via Gcc]

On 3/12/21 7:07 PM, Joseph Myers wrote:

On Fri, 12 Mar 2021, Jonathan Wakely via Gcc wrote:


Why not just make _Float16 available in C++ as a GCC extension?

There may be questions about promotions from _Float16 to wider formats for
arithmetic.

For C, there are no such promotions at the level of types (adding two
_Float16 values produces a result of type _Float16), but the excess
precision mechanism is used in some cases to cause a result of _Float16
arithmetic, although of semantic type _Float16, to be represented with the
range and precision of _Float32, to reduce the number of conversions of
intermediate results back to the range and precision of _Float16 that are
needed on hardware that doesn't have arithmetic operating directly on
_Float16.  Specifically, on AArch64, the excess precision mechanism is
used before ARMv8.2-A; v8.2-A adds direct arithmetic on _Float16 so no
excess precision is used from then on (see aarch64_excess_precision).

As we don't have excess precision support in the C++ front end,


Couldn't that just be made into shared code between the C and C++ 
frontends ?



supporting
_Float16 for C++ will require a decision about how to handle _Float16
arithmetic on hardware where there aren't actual _Float16 arithmetic
operations.

(The RISC-V document linked to suggests that won't be an issue for RISC-V
with hardware _Float16 support, though obviously it's still necessary to
decide what to do when using _Float16 on RISC-V systems without the
hardware support, if that is allowed at all.)

Re: Remove RMS from the GCC Steering Committee

[Gabriel Ravier via Gcc]

On 3/30/21 7:10 PM, Christopher Dimech via Gcc wrote:

Sent: Wednesday, March 31, 2021 at 4:50 AM
From: "Martin Jambor" 
To: "Giacomo Tesio" 
Cc: "GCC Development" 
Subject: Re: Remove RMS from the GCC Steering Committee

Dear Giacomo,

On Tue, Mar 30 2021, Giacomo Tesio wrote:

Hi Nathan and hello everybody,

On Fri, 26 Mar 2021 16:02:30 -0400 Nathan Sidwell wrote:


The USA is not the world and the SC is not the US government.  For
those in the USA, the (inapplicable) first amendment provides 5
rights, including showing an unwelcome guest the door. [...]

If we fail to do so, it will continue to be harder and harder to
attract new talent to GCC development.

I do not know if I qualify to speak here because I'm Italian and
I ported GCC 9.2.0 to Jehanne (a Plan 9 fork, see
http://jehanne.io/2021/01/06/gcc_on_jehanne.html), but due to the
pandemic I wasn't able to align it with the new developments and
contribute the port upstream. Also, I have no idea if you would be
interested in running GCC on a Plan 9 fork and thus accept my
contribution.


Yet, after a careful read of this thread I realized that I might
be considered the kind of "new talent" Nathan is talking about.

So here is my perspective on this topic, "in the hope it helps but
without any warranty". :-D


I do not share many of Stallman's opinions (we are VERY different), but
when I write free software and contribute to a free software community,
what I want is long term assurances about one and only one topic: that
the software will stay free as in freedom, as a common good for the
whole humanity.

As of today, GPLv3 is the legal tool that best suit this goal.
I don't think it's perfect in this regards, but that's another story.

Nobody suggested that GCC would be relicensed and certainly not to a
non-free license.  If you decide to contribute your port upstream, it
will be safe with us, regardless of who will or will not be on the
steering committee or running the FSF.  Just read the copyright
assignment text that you have singed or would need to sign to contribute
and look for FSF obligations as the license holder there.


As an Italian I'm having a hard time trying to follow your reasoning
about Stallman being a problem to attract new talents.

I do not believe that being European or Italian has anything to do with
it. I am European, I understand and agree with everything Nathan wrote
and apparently I am not the only one.

The ability to see and stand up to consistent wrongdoing is universal
and every human of every nationality posses it.  Unfortunately, all
people are also able to close their eyes and ears and ignore mistreatment
when they are not the victims and when their friend or their favorite
public figure is the perpetrator.  There is absolutely nothing American
or European about either.

Young socialists have been getting organized on colleges campuses
with these extreme ideas not only in the United States.  France, for
instance has been harbouring a socialist model we should all dread.

France was once a role model for what big government can do for its
people. But it has become an embarrassing example since “The Gilets
Jaunes” took to the streets to demonstrate against the insane amount
of taxes they pay. These guys aren’t upper class. They are the people
who had supported the policies that are inevitable when you have the
government providing so many services and involved so deeply in so much
of the economy.

All those people in America who currently fall for the socialism soup
that that Ocasio-Cortez and Sanders are selling need to realize that if
their dream came to pass, they, not the rich – not the bankers and politicians
– will be ones suffering the most from the high taxes, high unemployment, and
slow growth that go hand in hand with the level of public spending they want.
I fail to see how this has anything to do with the message you're 
answering. Is this what the right-wingers in America are resorting to ? 
Randomly making speeches about the "socialist soup" whenever they 
encounter something they can't find a good answer to ?

Sincerely,

Martin

Re: GCC association with the FSF

[Gabriel Ravier via Gcc]

On 4/8/21 6:43 PM, Christopher Dimech via Gcc wrote:

Sent: Friday, April 09, 2021 at 3:00 AM
From: "David Brown" 
To: "Jonathan Wakely" , "David Malcolm" 

Cc: "GCC Development" , "Mark Wielaard" 
Subject: Re: GCC association with the FSF

On 07/04/2021 19:17, Jonathan Wakely via Gcc wrote:

On Wed, 7 Apr 2021 at 15:04, David Malcolm wrote:

For myself, I'm interested in copyleft low-level tools being used to
build a Free Software operating system, but the "GNU" name may be
permanently tarnished for me; I have no wish to be associated with a
self-appointed "chief GNUisance".  I hope the FSF can be saved, since
it would be extremely inconvenient to have to move.

This matches my feelings. If the FSF can be saved, fine, but I don't
think GCC needs to remain associated with it.

If the GNU name is a problem, rename the projects to be simply "GCC",
"Glibc", "GDB" etc without being an initialism.


It should remain an acronym, but it should now stand for "GCC Compiler
Collection".  That allows the project to be disassociated from the GNU
name while still subtly acknowledging its heritage.

I am a gcc user, but not a developer or contributor.  I think it is
important to appreciate the good RMS has done for the software world,
and to accept history as it has happened rather than how we wish it had
been.  But going forward I don't think any project or organisation has
anything to gain by association with RMS, but will have much to lose.
To a large extent, he has done his job - the free and open source worlds
are now far too big and well-established to fail easily.  The time for
fanaticism, ideology and childish (ref. "Chief GNUisance") and
anti-social leadership is over - pragmatism, practicality and
cooperation are the way of the future.  It is time for the FSF to say to
RMS, "Thank you for all you have done.  Now move over for the next
generation, have a happy retirement, and please don't spoil the future
for the rest of us".  (We still need a few ideologists involved, to
remind us of important principles if anyone strays too far.  It's like a
healthy democratic parliament requiring a few representatives from the
greens, communists and other niche parties - you just don't want them
running the show.)

For me as a person, I cannot condone certain aspects of RMS' behaviour.
  I strongly disapprove of "proof by accusation and rumour" or "trial by
public opinion", but there is enough documented evidence in his own
publications and clearly established personal accounts that no one can
be in doubt that his attitudes and behaviour are not acceptable by
modern standards and are discouraging to developers and users in the
FOSS community.  (And yes, I mean FOSS here, not just free software.)

 From a practical viewpoint, I am concerned that opinions about him will
spread.  If the gcc project is not disassociated from anything involving
RMS, I fear the project will suffer from that assosiation, no matter how
unfair it may be.  At some point, someone in the public relations
department at IBM, Google, Facebook, ARM, or other big supporters of the
project will get the impression that the FSF and GNU are lead by a
misogynist who thinks child abuse is fine if the child consents, and
will cut off all support from the top down.  The other companies will
immediately follow.  The gcc lead developers like Ian, Jonathan, Joseph
and Nathan will be given the choice of leaving gcc or leaving the job
that puts food on their tables.  gcc is not a hobby project run by
amateurs in their free time - it is a serious project that needs
commercial backing as well as the massive personal dedication it receives.

If RMS in not indispensable, Ian, Jonathan, Joseph and Nathan are likewise
not indispensable.  Someone could that over and make their own project and
lead it how they wish.  There are many projects where the original author
knows best where to lead.  Classic examples include medical project Gnu
Health and my project.  Although can also mess a project up, mistakes are
allowed.  Einstein did not get his ideas from committees, neither did Stallman.
At work, I have never encountered any committee that done me any good.


RMS is not indispensible because he does not contribute to GCC and 
doesn't bring much to it, and otherwise takes more away from it. If you 
were to remove all of Ian, Jonathan, Joseph and Nathan you would be 
removing ~13% of active contribution to GCC (counting in commits). If 
you also remove all the major contributors that are from corporations 
(counting a major contributor as someone with 10 or more commits), 
you're removing ~63% of active contribution. If you also remove the 
major organizations contributing to GCC, like Adacore and the GDC 
project, you're removing ~18% more of active contribution, meaning 
you're left with 19% of active contribution. While I do not doubt that 
all of the contributors that would remain are talented individuals, GCC 
would undoubtedly, in the best case, heavily suffer from the loss

Re: GCC association with the FSF

[Gabriel Ravier via Gcc]

On 4/9/21 1:48 PM, Pankaj Jangid wrote:

Gabriel Ravier via Gcc  writes:


RMS is not indispensible because he does not contribute to GCC and
doesn't bring much to it, and otherwise takes more away from it. If
you were to remove all of Ian, Jonathan, Joseph and Nathan you would
be removing ~13% of active contribution to GCC (counting in
commits). If you also remove all the major contributors that are from
corporations (counting a major contributor as someone with 10 or more
commits), you're removing ~63% of active contribution. If you also
remove the major organizations contributing to GCC, like Adacore and
the GDC project, you're removing ~18% more of active contribution,
meaning you're left with 19% of active contribution. While I do not
doubt that all of the contributors that would remain are talented
individuals, GCC would undoubtedly, in the best case, heavily suffer
from the loss of 3 to 4 fifths of active contribution and become much
less appealing as a compiler, and in the worst case simply die
out. While each of the individuals forming any of those groups aren't
indispensable, as a group, they certainly are indispensible to GCC
unless you think GCC can really survive with 3/5 times less
contributions to it.

What is this man? Are you trying to compute the probability of survival
a project? You forgot to count me. I am one of the users of GCC. If
there are no users then the project is dead; however heavyweight the
maintainers are.

And let me also tell you the truth. I have looked at the list of
maintainers and the steering committee for the first time, when this
thread was started. My reason for sticking to GCC is FSF and associated
cause. Not the above list of people. Those who are not connected with
the cause have already started migrating to the competing tools.



If you have an enormous exodus of maintainers that takes away 4 fifths 
of maintainers, then there is a very high probability that the project 
will simply die by essentially all measures except for such asinine ones 
as "there is still at least 1 user of it" (under which, say, Version 6 
UNIX is not dead as there are still computers running it and people 
using it), as a GCC with much less people maintaining it would, over 
time, become very unattractive as a tool for actually making programs, 
as progress on developing it would become very slow. It would, for 
example, lose any C++ users that want to use anything beyond C++17 or 
the partial support for C++20 that GCC has right now.


While I am not saying that the amount of maintainers is directly tied to 
the survival of a project, I would certainly say that a project with 
near to no maintainers without which it cannot compete with competing 
projects (for example, Clang) /will/ die off.


The only ones that would remain would be those that would use GCC 
despite its enormous shortcomings for the single and only reason that it 
is licensed under the GPL, and those would be rather rare compared to 
the amount of people that use GCC right now. I am not saying that they 
are just a few dozen people or something like that, but GCC would become 
a shadow of its former self without any other support.


I would say that under those circumstances GCC would become about as 
popular as Turbo C or other antiquated tools like it, and I would 
certainly hope one would consider Turbo C to be a dead compiler, despite 
the fact that it still has at least 1 active user. While I don't think 
this outcome is likely, it would become likely if every single 
corporation and organization involved in the development of GCC suddenly 
retracted support for it. Do you really think GCC could remain 
competitive compared to compilers like Clang or MSVC if development on 
it was 5 times as slow, and if distributions like Fedora and Ubuntu 
started to migrate to LLVM, or even maybe straight up removed GCC from 
their repositories ?


PS: Of course, this is completely implausible, and it is almost certain 
that this will never happen, but you're implying that GCC can perfectly 
survive without any support from corporations: I am simply telling you 
what would happen if all those corporations actually stopped to support it

Re: removing toxic emailers

[Gabriel Ravier via Gcc]

On 4/15/21 8:00 AM, Thomas Koenig via Gcc wrote:

My 0.02 Euro-Cent:

There is a minor problem with contributors being overly harsh/
borderline abusive on the mailing list.  In my > 15 years with
the project, I have only had that problem with one single
person, and I have resolved that by never again touching the
system that particular person is responsible for, also not
for testing.

The _real_ problem is in bugzilla, mostly with abusive users
complaining about the time it sometimes takes to fix bugs
("Why didn't you fix this?  Are you stupid or what? That bug
has been open for _weeks_!") or who will not understand that
their program has an error, and insist on the compiler sanctioning
their particular non-standard usage.


As much as I hate to say it, this is a problem in the wider communities 
around C and C++, too. My teacher will often insist that "GCC and Clang 
make convenient assumptions at O2 and higher" without comprehending that 
the assumptions are "your code conforms to what the C/C++ standard says" 
and that this is the entire reason we have a standard, despite all my 
efforts at explaining things to him.




On bugzilla, there is also a rather minor problem with contributors
being overly harsh/borderline abusive, but that is also quite
restrictive.

If we talk about gcc becoming a more welcoming place, bugzilla
is the place to start. 

Re: A suggestion for going forward from the RMS/FSF debate

[Gabriel Ravier via Gcc]

On 4/18/21 8:44 AM, Christopher Dimech via Gcc wrote:

Sent: Sunday, April 18, 2021 at 6:09 PM
From: "Siddhesh Poyarekar" 
To: "NightStrike" , "Ville Voutilainen" 

Cc: "GCC Development" 
Subject: Re: A suggestion for going forward from the RMS/FSF debate

On 4/17/21 12:11 AM, NightStrike via Gcc wrote:

I was under the (likely incorrect, please enlighten me) impression
that the meteoric rise of LLVM had more to do with the license
allowing corporate contributors to ship derived works in binary form
without sharing proprietary code.  Intel, IBM, nVidia, etc. are

I think this is a blinkered view.  Sure, there are companies that build
proprietary toolchains using llvm as the base but I would argue that it
is the *result* of the rise of llvm and not the cause.

The cause IMO is accessibility to other projects, most notably compiler
researchers and students who find it a lot easier to target llvm than
gcc because compiler-as-a-library.  License may have been a factor for
some of those uses (e.g. I know some who think copyleft is not free
enough and BSD style licensing is the *real* freedom), but concluding
that it is the major reason is to delude ourselves.

It is also the reason why gcc does not even figure in situations where a
larger project would need AOT or JIT compilation; we had to concede that
ground all because of the FSF/GNU fears that companies would make
proprietary compilers out of a gcc compiler-as-a-library.

Of computer science graduates I have encountered over the last decade, I
know few who started their journey with gcc and they were all in the
initial part of the decade.  In recent years I don't think I encountered
any student who works on gcc; many even start with the assumption that
gcc is in maintenance mode.

For military focused PhDs, gcc is used.


So to summarize, the reasons why llvm is gaining traction *today* (I'm
sure there are more):

- Compiler-as-a-library - llvm is the first choice in FOSS projects and
use cases are exploding with gcc nowhere in sight

- Mindshare - most students and researchers are focused on it

- Funding - llvm has a much stronger funding ecosystem than gcc.  This
includes direct funding from the foundation and development workforce
from various organizations and universities.

You will not get funding grants in the US if you mention free software,
because the US Department of Commerce does not allow it.


I'd like to see a source for that. It certainly seems like complete 
bullshit to me, unless you're trying to tell me that they simultaneously 
do not fund anything related to free software while also having policy 
that mandates at least 20 percent of custom-developed code (i.e. code 
they fund the production of) has to be released as OSS (see 
https://www.commerce.gov/about/policies/source-code)




- License - Companies are building proprietary solutions on top of llvm.

Siddhesh

Re: GCC Mission Statement

[Gabriel Ravier via Gcc]

On 6/9/21 7:09 AM, Valentino Giudice via Gcc wrote:

If the Steering Committee updates the mission statement, it may appear
that the mission statement follows the decisions of the steering
committee (in place of the contrary). In that case, what would be the
purpose of a mission statement?


In essence, a mission statement is just that, a statement of the mission 
that the SC aims to follow. If the SC wishes to change that mission, it 
follows that the statement should be adjusted to adapt. The statement 
serves as any other statement serves: it gives information to others.


Of course, the mission statement is also binding on the SC itself, in a 
more social way: If it does not wish to lose faith of the GCC community, 
it should not go against the mission statement nor should it change it 
recklessly.


Speaking on the "change it recklessly" issue, I would personally say 
that SC has indeed arguably done this: I believe there should have been 
discussion of this change in the mailing list before it occurred, as 
essentially the only discussion on the mailing list that could have 
implied something like this would happen was the discussion from a while 
back about RMS and the FSF where some people threatened to pull away 
from GCC entirely if it remained tied to the FSF. I personally happen to 
agree with the change (which seems to have especially avoided what would 
have been a painful split that could have had disastrous consequences 
for GCC as a whole), but find it rather disconcerting that such changes 
with potentially major consequences were done without any direct 
discussion of them with the community whatsoever.

Re: GCC Mission Statement

[Gabriel Ravier via Gcc]

On 6/9/21 12:11 PM, Giacomo Tesio wrote:

Hi Gabriel,

On Wed, 9 Jun 2021 11:44:10 +0200 Gabriel Ravier via Gcc wrote:

Speaking on the "change it recklessly" issue, I would personally say
that SC has indeed arguably done this [...]
some people threatened to pull away from GCC entirely if it remained
tied to the FSF. I personally happen to agree with the change (which
seems to have especially avoided what would have been a painful split
that could have had disastrous consequences for GCC as a whole), but
find it rather disconcerting that such changes with potentially major
consequences were done without any direct discussion of them with the
community whatsoever.

Did you consider that, in fact, the lack of transparency of the
Steering Committee has shown since then (or even just the lack of
professionalism, when it comes to explicit intruduce major changes in
major versions) is a "disastrous consequence for GCC as a whole"?


I do consider that a lack of transparency is pretty bad, and that 
discussions on subjects like this should be done in public, but I 
wouldn't say it's just as bad as the potential risk that a fork would incur.


As for a lack of professionalism, I think it's pretty clear that GCC 11 
is the cutoff point here, and although there might be some problems with 
licensing bug fixes to old versions (which could not be reasonably 
avoided unless GCC made no major releases until GCC 11.5 is out), there 
isn't much reason to make a major version just for this when there was a 
major version a month ago. Note that releases are done ~1 time per year, 
so there isn't much FSF-copyrighted work "lost" with this.




Unilateral undiscussed changes by the Steering Committe is the new norm.


And such Steering Committee is in no way representing the interests of
the worldwide users of GCC, first because its members do not know them
(the vast majority is from the US, work for US corporations or both)
and second because they do not listen to any objection / request that
does not comes from their own circle / social group.


From what I know on this subject, the SC is meant to represent the GCC 
community (those that actively participate in GCC development, at 
least), and they are composed of well-recognized members of that 
community. Adding in random unknown people to represent the "worldwide 
users" of GCC would certainly not be taken well by the community and 
would heavily hurt the credibility of the SC in the eyes of everyone 
involved in working on GCC, which would consequently hurt the project.


You might have your own views on the subject, but I would prefer having 
a credible SC that might not represent everyone in the world well than 
have an SC representing everyone in the world that isn't trusted by the 
people involved with the project (which could then result in the SC 
becoming trusted... by the few people who remain after all those that 
don't trust it leave).




Are you sure that an explicit fork with two projects with different
names and governance would had been worse than what GCC has become?


To be clear: From what I can see, the GCC project has effectively 
declared their independence (which they already pretty much had, they've 
just made it publicly clear) from the FSF in terms of who is at the helm 
of the project. It is their right to do so, and they certainly had the 
power to do so when the only power the FSF could exert over them was 
very minor, with as the only leverage some minor reputation loss from 
the loss of association with GNU and the DNS records for gcc.gnu.org. If 
RMS wants to try to do anything, the most he can do is expel the SC as 
the maintainers of the "GNU Compiler Collection", take the DNS records 
for gcc.gnu.org and make a fork that would most certainly be considered 
by everybody to be "FSF GCC" or something like that to distinguish it 
from what would most certainly be the GCC basically everyone uses. The 
only result of this would be that basically everyone would move over to 
gcc-compiler.org or something like that, and the situation would be 
functionally unchanged from what it is now.


Note: GCC as it has been for the past 2 decades was already a fork of 
the original GCC: RMS just decided to accept EGCS (former name of the 
current GCC) as the official version of GCC endorsed by GNU (this is why 
it was already effectively independent).




Giacomo

Re: GCC/clang warning incompatibility with unused private member variables

[Gabriel Ravier via Gcc]

On 6/11/21 9:37 PM, Markus Faehling wrote:

Hello,

I'm currently facing a problem where I cannot get both gcc and clang 
warning-free simultaneously in my project. My code looks somewhat like 
this:


class Test {
    int a_;
    void b() {};
};

This code gives me the(usually very useful) "-Wunused-private-field" 
warning on clang. But because I have the unused member on purpose, I 
would like to add the [[maybe_unused]] attribute to it:


class Test {
    [[maybe_unused]] int a_;
    void b() {};
};

While this version is warning-free in clang, gcc has a "-Wattributes" 
warning because it ignores the [[maybe_unused]] warning. But I do not 
want to disable either of these warnings because they are still very 
useful in other situations.


Would it be possible to ignore the "-Wattributes" warning for 
[[maybe_unused]] in places where other compilers might use the attribute?


Demonstration on godbolt.org: https://godbolt.org/z/8oT4Kr5eM

Regards,

Markus Faehling

It should be easy to solve this with some application of `#pragma GCC 
diagnostic` pragmas to temporarily disable `-Wattributes` on that 
specific line. I suppose it may look ugly, but it works.

Re: Function attribute to indicate a likely (or unlikely) return value

[Gabriel Ravier via Gcc]

On 7/25/21 7:33 PM, Dominique Pellé via Gcc wrote:

Hi

I read https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
but was left wondering: is there a way to annotate a function
to indicate that a return value is likely (or unlikely)?

For example, let's say we have this function:

   // Return OK (=0) in case of success (frequent case)
   // or an error code != 0 in case of failure (rare case).
   int do_something();

If it's unlikely to fail, I wish I could declare the function like
this (pseudo-code!):

   int do_something() __likely_return(OK);

So wherever it's used, the optimizer can optimize branch
prediction and the instruction cache.  In other words, lines
like this:

   if (do_something() == OK)

...  would implicitly be similar to:

   // LIKELY defined as __builtin_expect((x), 1).
   if (LIKELY(do_something() == OK))

The advantage of being able to annotate the declaration,
is that we only need to annotate once in the header, and
all uses of the function can benefit from the optimization
without polluting/modifying all code where the function
is called.

Another example: a function that would be unlikely to
return NULL could be declared as:

   void *foo() __unlikely_returns(NULL);

This last example would be a bit similar to the
__attribute__((malloc)) since I read about it in the doc:


In addition, the GCC predicts that a function with
the attribute returns non-null in most cases.

Of course __attribute__((malloc)) gives other guarantees
(return value cannot alias any other pointer) so it's not
equivalent.

Would attribute __likely_return() and  __unlikely_return()
make sense?

Is there already a way to achieve this which I missed in
the doc?


I'd assume this can be accomplished with a simple inline wrapper.



Regards
Dominique

Re: Suboptimal code generated for __buitlin_trunc on AMD64 without SS4_4.1

[Gabriel Ravier via Gcc]

On 8/5/21 11:42 AM, Gabriel Paubert wrote:

On Thu, Aug 05, 2021 at 09:25:02AM +0200, Stefan Kanthak wrote:

Hi,

targeting AMD64 alias x86_64 with -O3, GCC 10.2.0 generates the
following code (13 instructions using 57 bytes, plus 4 quadwords
using 32 bytes) for __builtin_trunc() when -msse4.1 is NOT given:

 .text
0:   f2 0f 10 15 10 00 00 00 movsd  .LC1(%rip), %xmm2
 4: R_X86_64_PC32.rdata
8:   f2 0f 10 25 00 00 00 00 movsd  .LC0(%rip), %xmm4
 c: R_X86_64_PC32.rdata
   10:   66 0f 28 d8 movapd %xmm0, %xmm3
   14:   66 0f 28 c8 movapd %xmm0, %xmm1
   18:   66 0f 54 da andpd  %xmm2, %xmm3
   1c:   66 0f 2e e3 ucomisd %xmm3, %xmm4
   20:   76 16   jbe38 <_trunc+0x38>
   22:   f2 48 0f 2c c0  cvttsd2si %xmm0, %rax
   27:   66 0f ef c0 pxor   %xmm0, %xmm0
   2b:   66 0f 55 d1 andnpd %xmm1, %xmm2
   2f:   f2 48 0f 2a c0  cvtsi2sd %rax, %xmm0
   34:   66 0f 56 c2 orpd   %xmm2, %xmm0
   38:   c3  retq

 .rdata
 .align 8
0:   00 00 00 00 .LC0:   .quad  0x1.0p52
 00 00 30 43
 00 00 00 00
 00 00 00 00
 .align 16
   10:   ff ff ff ff .LC1:   .quad  ~(-0.0)
 ff ff ff 7f
   18:   00 00 00 00 .quad  0.0
 00 00 00 00
 .end

JFTR: in the best case, the memory accesses cost several cycles,
   while in the worst case they yield a page fault!


Properly optimized, shorter and faster code, using but only 9 instructions
in just 33 bytes, WITHOUT any constants, thus avoiding costly memory accesses
and saving at least 16 + 32 bytes, follows:

   .intel_syntax
   .text
0:   f2 48 0f 2c c0cvttsd2si rax, xmm0  # rax = trunc(argument)
5:   48 f7 d8  neg rax
 # jz  .L0  # argument zero?
8:   70 16 jo  .L0  # argument indefinite?
# argument overflows 64-bit 
integer?
a:   48 f7 d8  neg rax
d:   f2 48 0f 2a c8cvtsi2sd xmm1, rax   # xmm1 = trunc(argument)
   12:   66 0f 73 d0 3fpsrlq   xmm0, 63
   17:   66 0f 73 f0 3fpsllq   xmm0, 63 # xmm0 = (argument & -0.0) 
? -0.0 : 0.0
   1c:   66 0f 56 c1   orpdxmm0, xmm1   # xmm0 = trunc(argument)
   20:   c3  .L0:  ret
   .end

There is one important difference, namely setting the invalid exception
flag when the parameter can't be represented in a signed integer.  So
using your code may require some option (-fast-math comes to mind), or
you need at least a check on the exponent before cvttsd2si.

The last part of your code then goes to take into account the special
case of -0.0, which I most often don't care about (I'd like to have a
-fdont-split-hairs-about-the-sign-of-zero option).

`-fno-signed-zeros` does that, if you need it


Potentially generating spurious invalid operation and then carefully
taking into account the sign of zero does not seem very consistent.

Apart from this, in your code, after cvttsd2si I'd rather use:
mov rcx,rax # make a second copy to a scratch register
neg rcx
jo .L0
cvtsi2sd xmm1,rax

The reason is latency, in an OoO engine, splitting the two paths is
almost always a win.

With your patch:

cvttsd2si-->neg-?->neg-->cvtsi2sd
   
where the ? means that the following instructions are speculated.


With an auxiliary register there are two dependency chains:

cvttsd2si-?->cvtsi2sd
  |->mov->neg->jump

Actually some OoO cores just eliminate register copies using register
renaming mechanism. But even this is probably completely irrelevant in
this case where the latency is dominated by the two conversion
instructions.

Regards,
Gabriel




regards
Stefan
  


--
_
Gabriel RAVIER
First year student at Epitech
+33 6 36 46 16 43
gabriel.rav...@epitech.eu
11 Quai Finkwiller
67000 STRASBOURG

Re: Superfluous branches due to insufficient flow analysis

[Gabriel Ravier via Gcc]

On 8/13/21 8:58 PM, Stefan Kanthak wrote:

Hi,

compile the following naive implementation of nextafter() for AMD64:

JFTR: ignore the aliasing casts, they don't matter here!

$ cat repro.c
double nextafter(double from, double to)
{
 if (to != to)
 return to;// to is NAN

 if (from != from)
 return from;  // from is NAN

 if (from == to)   // neither from nor to can be NAN here!
 return to;

 if (from == 0.0)  // dito!
 return to < 0.0 ? -0x1.0p-1074 : 0x1.0p-1074;

 unsigned long long ull = *(unsigned long long *) &from;

 if ((from < to) == (from < 0.0))
 ull--;
 else
 ull++;

 return *(double *) &ull;
}
$ gcc -m64 -o- -O3 -S repro.c
...
nextafter:
 ucomisd %xmm1, %xmm1// sets PF for unordered result, i.e. when at
 jp  .L10//  least one operand is NAN
 ucomisd %xmm0, %xmm0// same here
 jp  .L1
 ucomisd %xmm0, %xmm1
 jnp .L14// OUCH: PF can't be set here!
 // OUCH: and if it were, it's MORE LIKELY to be
 //clear, so this branch would be taken
 // ... against the branch prediction
.L11:
 pxor%xmm2, %xmm2// OUCH: switching from FP SSE to integer SSE 
and
 //vice versa incurs a penalty of 1 
cycle
 // on quite a lot Intel Core 
processors!
 // Better use XORPD instead (which is even 1 
byte
 //  shorter)!
 ucomisd %xmm2, %xmm0
 jnp .L15// OUCH: there's still no need to check PF 
here!
.L4:
 comisd  %xmm0, %xmm1
 movq%xmm0, %rdx
 leaq-1(%rdx), %rax
 seta%r8b
 comisd  %xmm0, %xmm2
 seta%cl
 addq$1, %rdx
 cmpb%cl, %r8b
 cmovne  %rdx, %rax
 movq%rax, %xmm0
.L1:
 ret
.L14:
 jne .L11
.L10:
 movapd  %xmm1, %xmm0
 ret
.L15:
 jne .L4
 movabsq $-9223372036854775808, %rdx
 movq%xmm1, %rax
 andq%rdx, %rax
 orq $1, %rax
 movq%rax, %xmm0
 ret


Stefan

Shouldn't this kind of stuff go to the Bugzilla ?

Re: On(c)e more: optimizer failure

[Gabriel Ravier via Gcc]

On 8/21/21 10:19 PM, Stefan Kanthak wrote:

Jakub Jelinek  wrote:


On Sat, Aug 21, 2021 at 09:40:16PM +0200, Stefan Kanthak wrote:

I believe your example doesn't take into account that the values can be NaN
which compares false in all situations.

That's a misbelief!
Please notice the first if-clause, which rules out NaNs for both arguments.
Also notice that GCC did NOT generate JP after the 4 COMISD instructions
in question, i.e. it knew that NaNs had been ruled out.

GCC doesn't do value range propagation of floating point values, not even
the special ones like NaNs, infinities, +/- zeros etc., and without that the
earlier ifs aren't taken into account for the earlier code.

Ouch, to bad! That was but the very least expectation I had.
And indeed, removing the 3 other if-clauses doesn't change how the
final if-clause gets translated.

Sorry Matt, we were both wrong with our assumptions.


Also, as you have been told already, sending these mails to gcc mailing list
is a very bad idea, unless somebody jumps on it immediately and implements
it, they will be effectively forgotten.  You should file missed
optimizations into gcc bugzilla where they can be seen any time.

I don't have a bugzilla account, and I don't use GCC for anything serious.

Stefan


It's *that* demanding for you to create a Bugzilla account ? From my 
experience, creating a Bugzilla account takes around 30 seconds (though 
I suppose you'd have to wait for a bit if automatic account creation is 
temporarily disabled), it quite honestly feels as though you've spent 
far more time writing out these e-mails and talking here on the mailing 
list than that.


On Bugzilla I've had some optimization bug reports of mine take months 
to get a response and more to get fixed, but at least something happened 
after a while: if I just went on the mailing list it's incredibly likely 
they'd have been completely and utterly lost to time (it's not that GCC 
devs don't like the mailing list, but there's a reason a *bug tracking 
system* is used...)

Re: On(c)e more: optimizer failure

[Gabriel Ravier via Gcc]

On 8/22/21 11:22 PM, Stefan Kanthak wrote:

Gabriel Ravier  wrote:


On 8/21/21 10:19 PM, Stefan Kanthak wrote:

Jakub Jelinek  wrote:

[...]


You should file missed optimizations into gcc bugzilla where they can be
seen any time.

You should better implement such missing optimisations your users might
expect from a mature compiler.


I don't have a bugzilla account, and I don't use GCC for anything serious.

Stefan

It's *that* demanding for you to create a Bugzilla account ?

You (and everybody else) if free to use GCC bugzilla.
Everybody and me is but also free NOT to use GCC bugzilla.

Stefan


Yes, you are free not to use the GCC Bugzilla. And GCC developers are 
free to prefer to see bug reports be made to the GCC Bugzilla, as it is 
the place dedicated to GCC bug reports, made specifically for that 
purpose and with the infrastructure to handle it.


What would you think if you had a Github or a Gitlab repository and some 
people felt the need to randomly e-mail you about bugs they found 
instead of filing them using the dedicated Issues system there ? And 
what would you say if, upon being recommended to use that system, they 
said that they are "free not to use" the system dedicated to helping 
them reporting bugs when reporting bugs ? To me, that would just sound 
rude and like they don't actually want to help find and fix bugs.

Re: On(c)e more: optimizer failure

[Gabriel Ravier via Gcc]

On 8/23/21 3:46 PM, Stefan Kanthak wrote:
> Gabriel Ravier  wrote:
>
>> On 8/22/21 11:22 PM, Stefan Kanthak wrote:
>
> [ 2bugzilla | !2bugzilla ]
>
>>> You (and everybody else) if free to use GCC bugzilla.
>>> Everybody and me is but also free NOT to use GCC bugzilla.
>>>
>>> Stefan
>>
>> Yes, you are free not to use the GCC Bugzilla. And GCC developers are
>> free to prefer to see bug reports be made to the GCC Bugzilla, as it is
>> the place dedicated to GCC bug reports, made specifically for that
>> purpose and with the infrastructure to handle it.
>>
>> What would you think if you had a Github or a Gitlab repository and 
some

>> people felt the need to randomly e-mail you about bugs they found
>> instead of filing them using the dedicated Issues system there ? And
>> what would you say if, upon being recommended to use that system, they
>> said that they are "free not to use" the system dedicated to helping
>> them reporting bugs when reporting bugs ? To me, that would just sound
>> rude and like they don't actually want to help find and fix bugs.
>
> That's a VERY WILD and of course RUDE SPECULATION:
> 0. I'm old school, I don't use git-something.
> 1. I explicitly invite everybody who reads my web pages or uses code I
>    publish there to send bug reports, comments, feedback, flames, ...
>    per mail!
> Before you ask: I receive quite some mail from complete strangers, even
> bug reports.

If you want an example that does not involve git: Let us assume some of 
your users started to randomly use rather impractical means of reporting 
bugs to you, like sending you letters or randomly accosting you in the 
street about them. It would be possible to try and handle those bugs, 
but would you not try to redirect those users to more practical means of 
making bug reports ?


Note that *you* may find e-mail to be a practical way of handling bug 
reports, but from what I know, the GCC development team have found that 
impractical and much less efficient than using a bug tracker, especially 
on such a huge project as GCC: if all the bugs that are reported on the 
Bugzilla were instead reported here and all the discussion about them 
was done here, then today there would have been no less than:

- 12 e-mails about new bugs, and
- 159 e-mails relating to existing bugs

>
> I consider the statement on 
>
> | gcc is a high volume list for general development discussions about 
GCC.

> | Anything relevant to the development or testing of GCC and not covered
>       ~~
> | by other mailing lists is suitable for discussion here.
>
> as such an invitation too.

While this might imply in some way that this mailing list might be 
appropriate for this purpose, would it have taken that much time to also 
take a look at the GCC homepage ? The sidebar has an entire "Bugs" 
section, including a link literally called "How to report", which states 
directly to "Please submit your bug report directly to the GCC bug 
tracker." and links to https://gcc.gnu.org/bugzilla/


>
> Stefan
>
> JFTR: do you consider your wild speculations to be on-topic here?

I suppose I should apologize: I did not intend to make any accusations 
here. I simply could not think at the time of any other reasons why you 
would be so hostile to the idea of using Bugzilla (when you've been 
explicitly told that sending issues to the mailing list is close to 
equivalent to sending them to /dev/null) and, not being a native English 
speaker, I must have formulated the message more aggressively than I 
intended. I also had been rather angered by you saying "You should 
better implement such missing optimisations your users might expect from 
a mature compiler" which I misinterpreted (at least, I hope so) as being 
some kind of threat.

Re: atomic_load

[Gabriel Ravier via Gcc]

On 11/26/21 16:48, Jonathan Wakely via Gcc wrote:

On Fri, 26 Nov 2021 at 15:41, Martin Uecker  wrote:

Am Freitag, den 26.11.2021, 09:24 + schrieb Jonathan Wakely:

On Fri, 26 Nov 2021 at 09:00, Martin Uecker via Gcc  wrote:

Am Freitag, den 26.11.2021, 09:29 +0100 schrieb Eric Botcazou:

This is a silent and dangerous incorrect code generation issue.

Let's avoid this kind of FUD, please, builtins are low-level devices and
people must know what they are doing and be prepared for caveats.

Sorry, I do not think this FUD. One needs to look at the assembly
and know *very specific* details about the platform and atomics
to understand that it does not work and silently (!) breaks on
GCC (and not clang) in very rare cases. This with no indication
about this in the documentation which clearly implies that
this works for "all types".

It does. Two objects of type T are still the same type whether or not
they are both aligned to sizeof(T).

Yes, but only under special circumstances which are
not automatically fulfilled for all types.

Erm, two objects of type T are always the same type.

My point is that the docs say "works for all types", not "works for
all objects of all types".

You are claiming the docs are misleading, I'm saying you're misreading
them. They do not say "all objects of all types".
The problem is that it's extremely easy to misinterpret, and as such it 
is very likely someone who is not paying attention to the very precise 
details of the docs and at the exact things they aren't saying, and then 
guessing correctly what exactly they meant to say that they aren't 
saying, will make a misinterpretation and assume the atomic operations 
work on all valid objects, and not only "properly aligned ones" in an 
architecture-dependent way that seemingly cannot be determined portably 
(libstdc++ just makes sure it's at least as large as sizeof(T), but 
that's not necessarily stable, now is it ?). Here, even after making a 
through reading and remembering that you can have `alignof(T) < 
sizeof(T)`, you have to take a wild guess at whether the fact any 
information about this has been omitted means it isn't supported or 
means it is supported.

If these functions are not meant to be used to exising
data,  then at least the documentation needs to be changed
and include a big warning that this only happens to work
corectly if the data has  sufficient alignment for the
specific architecture (which of course makes it impossible
to use this in a portable way).

The last part of the sentence is again a blatant overstatement

Then please explain how one is supposed to use in a portable way if
it sometimes work or not based on platform-specific alignment
properties.

Either align your variable to its size, or don't use non-portable
compiler built-ins, use _Atomic.

If you want to be able to perform atomic operations on non-_Atomic
objects portably, that seems like a useful addition to the C standard
library (like std::atomic_ref in C++20).

The problem is that atomic_ref also only works if the
alignment fulfills special requirements.  So it can not
always be used on existing data structures.

I think it would be helpful if a compiler supports this by
providing suitable builtins, which it could easily do.

Since the existing builtins are already documented in a
way that implies that they allow exactly this, it would
be better and safer to just make this work.

That's not what the docs say though.
It is what they *imply*, though, and if you're wondering whether most 
people would think so, I can tell you right now I have gone and asked 
~10 people about whether they thought, based on the `__atomic` 
documentation (i.e. the 
https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html web 
page), that these builtins would require some kind of alignment or 
something like that, and they all thought that it would not (well, some 
brought up unaligned objects below `alignof(T)`, but that's just not a 
valid object of that type, so it doesn't matter much), whereas the bug 
report certainly seems to indicate it can require it in some situations 
where `alignof(T) < sizeof(T)`.

Re: odd internal failure

[Gabriel Ravier via Gcc]

On 12/4/21 00:54, Gary Oblock via Gcc wrote:

David,

Thanks, I've bookmarked your advice. I do use gdb but I've always
found the macros in common use are the biggest hurdle. In addition
C++ has its own associated difficulties.

Note, in the past working on other compilers I've always tried to have
a function version of the macros available.

#if USE_FUNCTIONS
foo_t
MUMBLE( grumble_t *g)
{
   return FU( BAR(g));
}
#else
MUMBLE(g) FU(BAR(g))
#endif

There are many advantages to this. Some are, better type checking,
being able to step into them and invoke them in gdb "p MUMBLE(x)".

Thanks again,

Gary
Shouldn't it be possible to use `-ggdb3` when compiling GCC to get debug 
information that includes macros ? It seems like that'd avoid having to 
manually define a bunch of equivalent functions for the sole purpose of 
being able to step through them.



From: David Malcolm 
Sent: Thursday, December 2, 2021 6:04 AM
To: Richard Biener ; Gary Oblock 

Cc: gcc@gcc.gnu.org 
Subject: Re: odd internal failure

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On Thu, 2021-12-02 at 12:40 +0100, Richard Biener via Gcc wrote:

On Wed, Dec 1, 2021 at 9:56 PM Gary Oblock 
wrote:

Richard,

I rebuilt at "-O0" and that particular call now works but on a call
to
the same function with a different offset it fails. 😱

use a debugger to see why

In case you haven't seen them, I put together some tips on debugging
GCC here:
https://dmalcolm.fedorapeople.org/gcc/newbies-guide/debugging.html
https://github.com/davidmalcolm/gcc-newbies-guide/blob/master/debugging.rst

Inserting print statements only gets you so far; at some point you
really need a debugger.

Dave


Thanks,

Gary



From: Richard Biener 
Sent: Wednesday, December 1, 2021 1:09 AM
To: Gary Oblock 
Cc: gcc@gcc.gnu.org 
Subject: Re: odd internal failure

[EXTERNAL EMAIL NOTICE: This email originated from an external
sender. Please be mindful of safe email handling and proprietary
information protection practices.]


On Wed, Dec 1, 2021 at 8:46 AM Gary Oblock via Gcc 
wrote:

What is happening should be trivial to determine but for some
reason it's
not. I'd normally bounce this off a coworker but given the pandemic
and modern dispersed hiring practices it's not even remotely
possible.

I'm making this call and tree_to_uhwi is failing on an internal
error.
That's normally easy to fix, but here is where the weirdness kicks
in.

   unsigned HOST_WIDE_INT wi_offset = tree_to_uhwi (offset);

tree_to_uhwi from tree.h is:

extern inline __attribute__ ((__gnu_inline__)) unsigned
HOST_WIDE_INT
tree_to_uhwi (const_tree t)
{
   gcc_assert (tree_fits_uhwi_p (t));
   return TREE_INT_CST_LOW (t);
}

and

tree_fits_uhwi_p from tree.c is

bool
tree_fits_uhwi_p (const_tree t)
{
   return (t != NULL_TREE
  && TREE_CODE (t) == INTEGER_CST
  && wi::fits_uhwi_p (wi::to_widest (t)));
}

Here's what this instrumentation shows (DEBUG_A is an indenting
fprintf to
stderr.)

   DEBUG_A ("TREE_CODE(offset) = %s  && ", code_str (TREE_CODE
(offset)));
   DEBUG_A ("fits %s\n", wi::fits_uhwi_p (wi::to_widest (offset)) ?
"true" : "false");
   DEBUG_A ("tree_fits_uhwi_p(offset) %s\n",tree_fits_uhwi_p
(offset) ? "true" : "false");

TREE_CODE(offset) = INTEGER_CST  && fits true
tree_fits_uhwi_p(offset) true

By the way, offset is:

_Literal (struct BASKET * *) 8

And it's an operand of:

MEM[(struct BASKET * *)&perm + 8B]

Any clues on what's going on here?

it should just work.


Thanks,

Gary


Btw, try to setup things so you don't spam below stuff to public
mailing lists.


CONFIDENTIALITY NOTICE: This e-mail message, including any
attachments, is for the sole use of the intended recipient(s) and
contains information that is confidential and proprietary to Ampere
Computing or its subsidiaries. It is to be used solely for the
purpose of furthering the parties' business relationship. Any
unauthorized review, copying, or distribution of this email (or any
attachments thereto) is strictly prohibited. If you are not the
intended recipient, please contact the sender immediately and
permanently delete the original and any copies of this email and
any attachments thereto.

Re: Issue with a flag that I defined getting set to zero

[Gabriel Ravier via Gcc]

On 1/7/22 09:38, Martin Liška wrote:

On 1/7/22 09:30, Gary Oblock wrote:

Regarding the corporate legal gibberish. It's automatic
and not under my control also we're not supposed to
use private emails for work...


I respect that. But please respect me that I won't reply to your
emails any longer. I don't want to follow the conditions in the NOTICE!

Cheers,
Martin

As far as I know the notice has no legal significance at all (which Gary 
should probably point out to his management. Really, pretty much the 
only thing the disclaimer will do is that _some_ people _might_ read it 
and _some_ of those people _might_ adhere to the terms given there, 
which is basically meaningless compared to the general annoyance 
resulting from disclaimers being at the end of e-mails everywhere). You 
can't just magically establish an agreement that results in a duty of 
nondisclosure like this without agreement, and just receiving an email 
obviously isn't that.


(although ironically, I guess I should add a disclaimer of my own: I 
ain't a lawyer and this isn't legal advice)

Re: [C2x] Disallow function attributes after function identifier

[Gabriel Ravier via Gcc]

On 6/11/22 11:03, Alejandro Colomar via Gcc wrote:
> Hi Jonathan,
>
> On 6/11/22 00:47, Jonathan Wakely wrote:
>> Well, I'd argue the same reasons to remove it from C++.  Don't 
know how
>> useful that feature is for C++, though.  I bet not much, but am 
not an

>> expert in the language.
>>
>>
>> It's used in libstdc++ because I couldn't get an attribute to work 
in any other location, because it isn't valid at other positions in a 
constrained function template. So no, we can't remove it from C++.

>>
>
> Hmm, okay, not removable in C++.  I'm curious about the specific line 
of code, if you have it around and could link to it. But C++ is huge, so 
anything is to be expected :)

>
>>
>>
>>
>> But, are we sure we want to add this to C?  You know how difficult
>> is to
>> revert mistakes in C, as opposed to C++, where additions and
>> deprecations are more common.
>>
>>
>> To the core language grammar? Are you sure about that?
>
> Well, everything is relative.
>
> libstdc++ additions, deprecations (and undeprecations) are much more 
common than in the core C++ language (e.g., the deprecation and later 
undeprecation of  headers).

>
> But breaking changes in the core C++ language are still more common 
than in C, where (sadly) we still have the useless 'auto' for backwards 
compatibility with dead languages, which would be nice in macros with 
the meaning of __auto_type.  Maybe in the 2050s?  :P

>
>
> So, C++ needs this feature.
>
> Then in C, we don't need it (I've never seen code reusing the return 
type to declare more than one function, and I hope to never see that 
apart from theoretical investigation).  `int foo(void), bar(void);` 
seems a useless feature in the language to me, but maybe disallowing it 
through an exception to the rules would complicate the wording more than 
help, so if that's kept in the language, I'm fine with it.

>
> So we could, and also could not, bring the C++ attribute for that 
useless feature.

>
> In C, I don't think that attribute position can have a useful use 
case that can't be achieved by an attribute at the start of the 
prototype, since the language is much simpler.

>
> Do we want to add a completely unnecessary feature, just for symmetry 
with C++, even if it poses a danger of breaking (both human and script) 
readability of function declarations/definitions, especially when hidden 
in macros?


I actually don't get the trouble with this. Your tool already can't 
parse declarations if they don't follow a certain coding style, so you 
can just add this restriction to the coding style that's required.


> I still have the hope that if the feature is finally kept in C23, 
absolutely no-one will ever use it, but then I question the introduction 
in the first place.


Well in the same way, `int long signed const typedef long x;` is valid 
C, and I do hope that nobody will ever use it, but I don't think we 
should change C's grammar to disallow it.


>
> Cheers,
>
> Alex
>

Cheers,

Gabriel

Re: [RFC] Using std::unique_ptr and std::make_unique in our code

[Gabriel Ravier via Gcc]

On 7/8/22 22:46, David Malcolm via Gcc wrote:

std::unique_ptr is C++11, and I'd like to use it in the gcc/analyzer
subdirectory, at least.  The following patch eliminates a bunch of
"takes ownership" comments and manual "delete" invocations in favor
of simply using std::unique_ptr.

The problem is that the patch makes use of std::make_unique, but that
was added in C++14.

I've heard that it's reasonably easy to reimplement std::make_unique,
but I'm not sure that my C++11 skills are up to it.

Is there:
(a) an easy way to implement a std::make_unique replacement
 (e.g. in system.h? what to call it?), or
(b) some C++11-compatible way to do the same thing?
without accidentally bringing in C++14 features.

Thoughts?
Dave

---
  gcc/analyzer/call-info.cc |  1 +
  gcc/analyzer/checker-path.cc  |  1 +
  gcc/analyzer/constraint-manager.cc|  1 +
  gcc/analyzer/diagnostic-manager.cc| 40 --
  gcc/analyzer/diagnostic-manager.h | 12 +++---
  gcc/analyzer/engine.cc| 37 
  gcc/analyzer/exploded-graph.h |  4 +-
  gcc/analyzer/feasible-graph.cc|  1 +
  gcc/analyzer/pending-diagnostic.cc|  1 +
  gcc/analyzer/pending-diagnostic.h |  1 +
  gcc/analyzer/program-point.cc |  1 +
  gcc/analyzer/program-state.cc |  1 +
  gcc/analyzer/region-model-asm.cc  |  1 +
  gcc/analyzer/region-model-impl-calls.cc   |  1 +
  gcc/analyzer/region-model-manager.cc  |  1 +
  gcc/analyzer/region-model-reachability.cc |  1 +
  gcc/analyzer/region-model.cc  | 44 +++
  gcc/analyzer/region-model.h   | 31 +++---
  gcc/analyzer/region.cc|  1 +
  gcc/analyzer/sm-file.cc   | 11 +++--
  gcc/analyzer/sm-malloc.cc | 51 +--
  gcc/analyzer/sm-pattern-test.cc   |  5 ++-
  gcc/analyzer/sm-sensitive.cc  |  5 ++-
  gcc/analyzer/sm-signal.cc |  5 ++-
  gcc/analyzer/sm-taint.cc  | 24 +++
  gcc/analyzer/sm.cc|  9 
  gcc/analyzer/sm.h | 12 +++---
  gcc/analyzer/state-purge.cc   |  1 +
  gcc/analyzer/store.cc |  1 +
  gcc/analyzer/svalue.cc|  1 +
  gcc/analyzer/trimmed-graph.cc |  1 +
  gcc/analyzer/varargs.cc   | 25 ++-
  32 files changed, 194 insertions(+), 138 deletions(-)

diff --git a/gcc/analyzer/call-info.cc b/gcc/analyzer/call-info.cc
index e1142d743a3..87ab35b9e87 100644
--- a/gcc/analyzer/call-info.cc
+++ b/gcc/analyzer/call-info.cc
@@ -19,6 +19,7 @@ along with GCC; see the file COPYING3.  If not see
  .  */
  
  #include "config.h"

+#define INCLUDE_MEMORY
  #include "system.h"
  #include "coretypes.h"
  #include "tree.h"
diff --git a/gcc/analyzer/checker-path.cc b/gcc/analyzer/checker-path.cc
index 211cf3e0333..3e475865e04 100644
--- a/gcc/analyzer/checker-path.cc
+++ b/gcc/analyzer/checker-path.cc
@@ -19,6 +19,7 @@ along with GCC; see the file COPYING3.  If not see
  .  */
  
  #include "config.h"

+#define INCLUDE_MEMORY
  #include "system.h"
  #include "coretypes.h"
  #include "tree.h"
diff --git a/gcc/analyzer/constraint-manager.cc 
b/gcc/analyzer/constraint-manager.cc
index 4133a134778..b2344e79487 100644
--- a/gcc/analyzer/constraint-manager.cc
+++ b/gcc/analyzer/constraint-manager.cc
@@ -19,6 +19,7 @@ along with GCC; see the file COPYING3.  If not see
  .  */
  
  #include "config.h"

+#define INCLUDE_MEMORY
  #include "system.h"
  #include "coretypes.h"
  #include "tree.h"
diff --git a/gcc/analyzer/diagnostic-manager.cc 
b/gcc/analyzer/diagnostic-manager.cc
index 083f66bd739..41d82f6e5dc 100644
--- a/gcc/analyzer/diagnostic-manager.cc
+++ b/gcc/analyzer/diagnostic-manager.cc
@@ -19,6 +19,7 @@ along with GCC; see the file COPYING3.  If not see
  .  */
  
  #include "config.h"

+#define INCLUDE_MEMORY
  #include "system.h"
  #include "coretypes.h"
  #include "tree.h"
@@ -645,14 +646,14 @@ saved_diagnostic::saved_diagnostic (const state_machine 
*sm,
tree var,
const svalue *sval,
state_machine::state_t state,
-   pending_diagnostic *d,
+   std::unique_ptr d,
unsigned idx)
  : m_sm (sm), m_enode (enode), m_snode (snode), m_stmt (stmt),
   /* stmt_finder could be on-stack; we want our own copy that can
  outlive that.  */
m_stmt_finder (stmt_finder ? stmt_finder->clone () : NULL),
m_var (var), m_sval (sval), m_state (state),
-  m_d (d), m_trailing_eedge (NULL),
+  m_d (std::move (d)), m_trailing_eedge (NULL),
m_idx (idx)

Re: rust non-free-compatible trademark

[Gabriel Ravier via Gcc]

On 7/19/22 01:09, lkcl via Gcc wrote:

On Mon, Jul 18, 2022 at 10:01 PM David Malcolm  wrote:


Luke: you appear to me to be the one who is telling people what patches
they can and cannot apply, and it's pissing me off.

1) please don't you dare put words into my mouth that i did not state.
 first and only warning.
2) i'm sorry you're annoyed. Asperger's interactions with neuro-typical
 individuals who are not used to the same typically do not go well:
 this conversation has all the hallmarks i'm used to being subjected
 to (and, frankly, shouldn't have to put up with).
 as you can probably imagine in 25 years it's pretty tiresome
 for me to be constantly subjected to abuse based solely on
 misunderstandings that, with the tiniest bit of tolerance, could
 easily have been avoided.
   3) as you work for redhat, you should be able to speak to HR and
   request Diversity training for how to interact with people with
   Asperger's.  [or, at least, how to recognise them and not get
   pissed off by how they speak].  given that it was "neurodiversity month"
   only a few weeks ago you should be able to find references on linkedin.


Hello there. For a while I've been watching this conversation and seeing 
how
inflammatory it has become, and this seems like the right place to 
intervene,
as I myself have Asperger. I would like to say that from my perspective 
it is

you, not everyone else, who is subjecting people to abuse based on a
misunderstanding with what seems to me like a constant stream of "OMGWTF
THE RUST TRADEMARK WILL DESTROY ALL GCC DEVELOPERS, REMOVE RUST
NOW" (note: this is hyperbole, and I am not claiming it is literally 
what you
have said, it is simply the general feeling that I have been left off 
with after

reading your messages throughout this thread).

David is simply telling you one of the most basic implications of what you
have been claiming, i.e. that if the GCC Rust frontend was to be added to
GCC then it would apparently expose everyone involved in distribution of
GCC (which as we know is a very wide definition) to trademark infringement
lawsuits and even potential criminal liability as you have claimed in a 
previous
message. The hopefully obvious implication is that the patches to add 
the Rust
frontend should thus not be applied. You have answered to this by 
telling him

that this simple statement is somehow abuse, which seems ridiculously
confrontational to me and almost like you are accusing him of deliberately
acting in bad faith, even though I have been doing my best to assume the
assumption of good faith so far. Just as you have cited the Conflict 
Resolution
Kit in one of your previous messages, I too know of similar sources. 
Here is one
that might help you with this: 
https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith



Are you a lawyer?  If so please consider volunteering your time to the
GCC Steering Committee *privately*.  If not, it seems to me to be a
terrible idea to try to get the developers to pontificate in public
about alleged legal issues with the project, their implications, and
supposed workarounds.

i'm a Libre Ethical Technology Specialist.  i expect a project such as
gcc to be held accountable publicly for its decisions and actions,
and to act responsibly.  this conversation will be watched by a hell
of a lot of people and if there are private conversations on this topic
being held behind closed doors then how the hell can anyone have
any confidence and trust in gcc?

i'm publicly and fully accountable in the FOSS projects that *i* manage,
including the full financial records, and given how massively high-profile
gcc is, i expect it to be held publicly accountable to a far greater degree.


While public accountability is a very good thing, I would hope you 
understand

that some topics are best kept private to some degree, at least for a short
duration so as to discourage impulsive or defensive reactions. Security
vulnerabilities should be a rather obvious example of this, but sensible 
issues
such as legal ones (as the one you are raising here) are also the kind 
of things

that seem to me like they should be kept private in the very short term.

Coming on the GCC mailing list, which hundreds of people regularly read,
and making such a statement as "has it been taken into consideration 
that the

draconian (non-free-compatible) requirements of the rust Trademark make the
distribution of the gcc compiler Unlawful?" will instinctively put 
essentially

everyone directly involved with the project on the defensive for hopefully
obvious reasons. By being publicly confrontational on this issue, you 
make it
much, much more likely, regardless of the accuracy of your statements, 
that the
people involved will not want to admit any potential mistake they might 
have
made, and will encourage them to be equally confrontational in 
responding to

you.

Making private contact instead is very useful for establishin

Re: B^HDEAD code generation (AMD64)

[Gabriel Ravier via Gcc]

On 1/10/23 01:34, Stefan Kanthak wrote:

"Thomas Koenig"  wrote:


On 09.01.23 12:35, Stefan Kanthak wrote:

20 superfluous instructions of the total 102 instructions!

The proper place for bug reports is https://gcc.gnu.org/bugzilla/ .

OUCH: there's NO proper place for bugs at all!


Feel free to submit these cases there.

I feel free to do whatever I like to do where I do it, for example:

--- bug.cpp ---
int main() {
 __uint128_t long long bug = 0;
}
--- EOF ---

See 

regards
Stefan


If you're trying to speedrun actually getting banned from this mailing 
list, then sure, I guess you can "do whatever I like to do where I do 
it", but you might find that more difficult after somebody decides to do 
something about it.

Re: [PATCH 3/4] libbacktrace: work with aslr on windows

[Gabriel Ravier via Gcc]

On 1/20/23 14:39, Eli Zaretskii via Gcc wrote:

From: Björn Schäpers 
Date: Fri, 20 Jan 2023 11:54:08 +0100

@@ -856,7 +870,12 @@ coff_add (struct backtrace_state *state, int descriptor,
  + (sections[i].offset - min_offset));
  }
  
-  if (!backtrace_dwarf_add (state, /* base_address */ 0, &dwarf_sections,

+#ifdef HAVE_WINDOWS_H
+module_handle = (uintptr_t) GetModuleHandleW (NULL);
+base_address = module_handle - image_base;
+#endif
+
+  if (!backtrace_dwarf_add (state, base_address, &dwarf_sections,
0, /* FIXME: is_bigendian */
NULL, /* altlink */
error_callback, data, fileline_fn,

Why do you force using the "wide" APIs here?  Won't GetModuleHandle do
the job, whether it resolves to GetModuleHandleA or GetModuleHandleW?


I would expect the reason to be either that:

- using wide APIs with Windows is generally considered to be a best 
practice, even when not strictly needed (and in this case I can't see 
any problem with doing so, unless maybe we want to code to work with 
Windows 95 or something like that...)


- using the narrow API somehow has an actual drawback, for example maybe 
it might not work if the name of the exe file the NULL will tell it to 
get a handle to contains wide characters

Re: [PATCH 3/4] libbacktrace: work with aslr on windows

[Gabriel Ravier via Gcc]

On 1/20/23 20:19, Eli Zaretskii wrote:

Date: Fri, 20 Jan 2023 17:46:59 +0100
Cc: gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
From: Gabriel Ravier 

On 1/20/23 14:39, Eli Zaretskii via Gcc wrote:

From: Björn Schäpers 
Date: Fri, 20 Jan 2023 11:54:08 +0100

@@ -856,7 +870,12 @@ coff_add (struct backtrace_state *state, int descriptor,
  + (sections[i].offset - min_offset));
   }
   
-  if (!backtrace_dwarf_add (state, /* base_address */ 0, &dwarf_sections,

+#ifdef HAVE_WINDOWS_H
+module_handle = (uintptr_t) GetModuleHandleW (NULL);
+base_address = module_handle - image_base;
+#endif
+
+  if (!backtrace_dwarf_add (state, base_address, &dwarf_sections,
0, /* FIXME: is_bigendian */
NULL, /* altlink */
error_callback, data, fileline_fn,

Why do you force using the "wide" APIs here?  Won't GetModuleHandle do
the job, whether it resolves to GetModuleHandleA or GetModuleHandleW?

I would expect the reason to be either that:

- using wide APIs with Windows is generally considered to be a best
practice, even when not strictly needed (and in this case I can't see
any problem with doing so, unless maybe we want to code to work with
Windows 95 or something like that...)

There's no reason to forcibly break GDB on platforms where wide APIs
are not available.
Are there even any platforms that have GetModuleHandleA but not 
GetModuleHandleW ? MSDN states that Windows XP and Windows Server 2003 
are the first versions to support both of the APIs, so if this is 
supposed to work on Windows 98, for instance, whether we're using 
GetModuleHandleA or GetModuleHandleW won't matter.



- using the narrow API somehow has an actual drawback, for example maybe
it might not work if the name of the exe file the NULL will tell it to
get a handle to contains wide characters

Native Windows port of GDB doesn't support Unicode file names anyway,
which is why you used the *A APIs elsewhere in the patch, and
rightfully so.  So there's no reason to use "wide" APIs in this one
place, and every reason not to.


(just as a clarification, I did not write this patch)

Re: [PATCH 3/4] libbacktrace: work with aslr on windows

[Gabriel Ravier via Gcc]

On 1/21/23 05:05, Eli Zaretskii wrote:

Date: Fri, 20 Jan 2023 21:39:56 +0100
Cc: g...@hazardy.de, gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
From: Gabriel Ravier 


- using wide APIs with Windows is generally considered to be a best
practice, even when not strictly needed (and in this case I can't see
any problem with doing so, unless maybe we want to code to work with
Windows 95 or something like that...)

There's no reason to forcibly break GDB on platforms where wide APIs
are not available.

Are there even any platforms that have GetModuleHandleA but not
GetModuleHandleW ? MSDN states that Windows XP and Windows Server 2003
are the first versions to support both of the APIs, so if this is
supposed to work on Windows 98, for instance, whether we're using
GetModuleHandleA or GetModuleHandleW won't matter.

I'm not sure I follow the logic.  A program that calls
GetModuleHandleW will refuse to start on Windows that doesn't have
that API.  So any version before XP is automatically excluded the
moment you use code which calls that API directly (i.e. not through a
function pointer or somesuch).
A program that calls GetModuleHandleA will also refuse to start on 
Windows if it doesn't have that API. The set of Windows versions that do 
not have GetModuleHandleA is, according to MSDN, the same as the set of 
Windows versions that do not have GetModuleHandleW.

Re: More C type errors by default for GCC 14

[Gabriel Ravier via Gcc]

On 5/10/23 14:36, Eli Zaretskii via Gcc wrote:

Date: Wed, 10 May 2023 14:03:01 +0200
From: Jakub Jelinek 
Cc: Jonathan Wakely , fwei...@redhat.com,
 gcc@gcc.gnu.org, ar...@aarsen.me


Why should this compile?

Because GCC is capable of compiling it.

That is not a good argument.  GCC is capable of compiling any code in all
the reported accepts-invalid bugs on which it doesn't ICE.  That doesn't
mean those bugs shouldn't be fixed.

Fixing those bugs, if they are bugs, is not the job of the compiler.
It's the job of the programmer, who is the one that knows what the
code was supposed to do.  If there's a significant risk that the code
is a mistake or might behave in problematic ways, a warning to that
effect is more than enough.


Are you seriously saying that no accepts-invalid bug should ever be 
fixed under any circumstances on the basis that some programmers might 
rely on code exploiting that bug ??




C99 for the above says:

I know what the standard says, but since when do we in the GNU project
accept standards as a dictate?  We do what we consider to be best for
our users, and follow the standards when that doesn't contradict what
we think is best for the users.  GCC has, for example, -std=gnu99
etc. precisely for that purpose.


The proposal is essentially to stop accepting this as a GNU extension
which was added for K&R compatibility I assume and do that only for C99 and
later.

I understand.  I'm saying that there's no reason to make this an
error, because it will break builds that have good reasons for keeping
such code.


Note, this isn't valid even in C89 and is already rejected with
-pedantic-errors for years.

Terrific!  Rejecting such code given a non-default option is _exactly_
what should be done.  But we here are discussing the default behavior.


It compiles today with a warning, so that whoever is interested to fix
the code, can do that already.  The issue at hand is not whether to
flag the code as highly suspicious, the issue at hand is whether
upgrade the warning to errors.  So let's talk about the issue at hand,
not about something else, okay?

We do such changes several times a year, where we reject something that has
been previously accepted in older standards, admittedly mostly in C++.

And that is a Good Thing?  I don't think so.  Maybe for C++ it's
inevitable, I'm not an expert on that.  But making breaking changes is
inherently BAD and should be avoided.


Yes, it is done far less in C, but still, as the above is invalid already in
C89, users had over 3 decades to fix their code, and in many cases they
didn't and without this move they will never bother.

Please consider those cases where the code cannot be "fixed", in
practice.  I described one such situation in a previous message.


A lot of such broken code has been even written in those 3 decades, doesn't
predate it, but because the compiler just warned on it, it still appeared in
the code bases.  If we wait with this change another 2 decades, nothing will
change and we'll have the same problem then.

GCC is not responsible for the existence of that code.  So GCC
shouldn't change its decades-long behavior just because that code is
there.  there must be a much more serious reason for such changes,
something that affects GCC itself.

Re: Wish: scoped enum

[Gabriel Ravier via Gcc]

On 5/12/23 01:58, Yair Lenga via Gcc wrote:

Hi,

I wonder if it will be possible to add support for "scoped" enum to GCC.
The current C standard has one name space for all enums, and different name
space for the members of each "struct". As a result, possible to say

struct foo { int a } ;
struct bar { double a }; // This is different 'a', different type

But illegal to to (ignoring the conversion to use all upper for enum).

enum a { u, v } ;
enum b { v, w } ; // can not do this, as 'v' must be distinct

One annoying side effect is that any package/module creating an enum has to
worry about namespace collision with everyone else in the world. Common
practices include distinct prefixes, similar to the way different libraries
use distinct prefixes to avoid function name collision. This solution is
far from perfect and leads to excessive long enum name.

A reasonable wish list - add a magic keyword that will place the enums into
a scope, so that the following work:

SCOPED enum shirt_sz { small, medium, large } ;
SCOPED enum shoe_sz { small, medium, medium_wide, large, xlarge } ;

enum shirt_sz tshift_size = shift_sz.medium ;
enum shoe_siz boot_size = shoe_sz.xlarge ;

Not perfect, but not complex, will make enum reusable across many scenario,
where they are currently hard to implement - because of namespace conflict
- between system header and user headers, between different packages.

A smart compiler can also alert when "types" are mixed (assign value from
shift_sz to a variable of type shoe_sz). Not critical - as my understanding
is that this is not enforced today. For the case that an enum symbol is
distinct (in the current compilation unit), the compiler can allow using it
without the namespace - practically falling back into current behavior.

Feedback ? Anyone know how to get a prototype into gcc ? How one get
approval for such "extensions".

Yair


You may wish to learn about 
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf - 
although of course this isn't available in C right now, but the addition 
of a differing, syntactically incompatible while substantially 
overlapping feature to C to reproduce the same functionality as `enum 
class` seems far more unlikely to occur than the addition of `enum 
class` to C.

Re: More C type errors by default for GCC 14

[Gabriel Ravier via Gcc]

On 5/12/23 07:57, Po Lu via Gcc wrote:

Eli Schwartz  writes:


There are ***not*** thousands of Makefiles that have this issue. But if
there were, then Makefiles are very easy to update, and only have to be
updated once per project, not thousands of times. So this is fine. You
may have to update your Makefile, but that is no big deal.

It's still no big deal, no matter how much you dramatize the intensity
of adding a flag to your Makefiles.

It's extra work.  Why don't I just write:

   extern int foo ();

above each of the new errors?
That is just about what anyone will do when confronted by these new
errors.  As a result, you have not ensured that any declarations are
correct, but instead you have annoyed a lot of people and lulled
yourself into a false sense of safety.


It's "extra work" to add 10 characters to a Makefile, but normal to add 
random faulty declarations everywhere ? I could only imagine someone 
doing this if they're being either extremely uninformed, extremely 
restricted (e.g. no change to any configuration files, no pragmas to 
disable the errors and not even having 10 seconds to look up the correct 
function prototype) or deliberately obtuse.





So you concede that GCC is not telling you, only trying and failing to
tell you?

I concede that you're playing with words.


Great, so what's the problem? If GCC can't actually enforce it, and even
goes out of its way to offer you options to ignore what it's telling you
to do, then maybe...

... it's not telling you what to do with your code, only suggesting what
to do?

So ignore the suggestion.

Which is made annoying, especially when there is absolutely NO guarantee
being made that the new option will stay.


I'm not sure what this semantics game here is trying to say. Is it
ethically and morally wrong for GCC to try to tell you what to do with
your code? Is it undignifying to have a mere machine go and lecture you,
a real human being with a consciousness and free will, what to do?

Because if that's what this is about then I think you are taking this
inanimate object way too personally.

If not, then I am simply entirely unsure what your objection is to being
"told".



Because that's exactly what is going on here. Features that were valid
C89 code are being used in a GNU99 or GNU11 code file, despite that
***not*** being valid GNU99 or GNU11 code.

How GCC currently behaves defines what is valid GNU C.


No. Absolutely positively 100% no under any circumstances whatsoever no.

This has been explained multiple times by the GCC developers. e.g.
search for references to accepts-invalid.

"""
They are bugs where compiler accepts something that isn't valid in
the selected language nor considered valid extension.
So, after the fix we reject something that has been accepted before.

In the last few years (checked what was fixed in 10/11/12/13 releases so
far), we've fixed 12 such bugs explicitly marked that way:
"""

The Standard states that each conforming implementation must be
accompanied by a document which documents each and every extension.

This document is the GCC manual, which makes reference (not too clearly,
however, which should be fixed) to both implicit int and implicit
function declarations, which are allowed in C99 and later dialects of C.

These constructs are not bugs.  These constructs explicitly defined by
GNU C; since a diagnostic is issued, GNU C's implementation also
conforms to the Standard.


You cannot, and are not permitted, to define "how GCC currently behaves"
as "defines what is valid GNU C". No one agrees with your analysis. Most

 ^^

I'm not a person?
Now you're the one playing with words. That, or you have a complete lack 
of understanding of extremely common English expressions, which you may 
want to work on as you will otherwise inevitably have large problems 
effectively communicating anything with people on this list.



importantly, GCC does not agree with your analysis.

For some definition of GCC, which is apparently you.
The "definition of GCC" used here is in a more general sense, i.e. the 
GCC project and the people involved in it that would be considered 
generally representative of it. In fact, so far on this thread I've seen 
almost nobody on your side of the argument, save for a very few 
extremely loud people repeating the same arguments over and over. So far 
I've seen only a single minor GCC contributor arguing the behavior 
should be kept as-is - pretty much everyone else agrees the behavior 
should be changed. In fact, I've talked to many people who are not 
currently posting in this thread, who consider that the default should 
be changed, and are watching in consternation as a few people appear to 
be trying to hold back the entire community with extremely bad defaults.



It's a wild, wild, wild claim to begin with. You are arguing that any
bug, ANY bug whatsoever, which qualifies for the title "how GCC
currently behaves" because if a bug is cu

Re: More C type errors by default for GCC 14

[Gabriel Ravier via Gcc]

On 5/12/23 08:25, Eli Zaretskii via Gcc wrote:

Date: Thu, 11 May 2023 18:43:32 -0400
Cc: luang...@yahoo.com, gcc@gcc.gnu.org
From: Eli Schwartz 

On 5/11/23 2:24 AM, Eli Zaretskii wrote:


Back to the subject: the guarantees I would personally like to have is
that the current GCC development team sees backward compatibility as
an important goal, and will try not to break old programs without very
good technical reasons.  At least in Emacs development, that is the
consideration that is very high on our priority list when making
development decisions.  It would be nice if GCC (and any other GNU
project, for that matter) would do the same, because being able to
upgrade important tools and packages without fear is something users
value very much.  Take it from someone who uses GCC on various
platforms since version 1.40.

This discussion thread is about having very good technical reasons -- as
explained multiple times, including instances where you agreed that the
technical reasons were good.

They are not technical, no.  Leaving the current behavior does not
technically hamper GCC and its users in any way -- GCC can still
compile the same programs, including those with modern std= values, as
it did before, and no false warnings or errors are caused when
compiling programs written in valid standard C.


The current behavior hampers GCC's users in very significant ways: it 
encourages people who are new to the language to write completely broken 
code in ways that should have been at least slightly harder to 
accomplish since a quarter of a century ago.


Arguing that GCC should compile any "valid standard C" seems like an 
obviously flawed premise to me given that unless you're going the 
strictly conforming route, a "program" such as:


]iN$<\J3"`q
Tf;9ge0k\hm[
!Zsr>MtiV B@
~x?M\A):.s0^W
2$((g]'Vx:jZ
D'?n/X_li|;E
aLA%WQmzNq-(QG'
r"rSV3|]k_BU?R
p:hPWg_(]Y(
And,3xD{iR5B

may be considered by any implementation as a valid standard C program, 
since it does not contain an #error directive.


Such examples may seem like hyperbole to you, but to a beginner, the 
constructs that you wish to leave usable in GCC unaltered may well be 
just about as confusing as you might find any interpretation of the 
valid standard C program presented above to be.


You may not be aware of this, but the current behavior leads to endless 
instances of beginners accidentally using utterly broken constructs and 
then coming to C forums/channels/etc. asking for help, only for people 
like me to discover that such code is still compiled by GCC now without 
anymore than a warning being given to the user (which they extremely 
commonly ignore). Having been on such forums for years, I'd estimate 
that this actually represents a genuinely significant proportion of the 
problems I help diagnose - about 10% or so (though I have of course not 
made a detailed study of every problem I've ever helped solve, but I'm 
relatively confident 10% is not too far from the real proportion). To be 
honest, it's such a common problem that I'm genuinely surprised it 
hasn't spawned off jokes in the same way things like 
T_PAAMAYIM_NEKUDOTAYIM in PHP have (I guess "implicit function 
declaration" has less of a ring to it than T_PAAMAYIM_NEKUDOTAYIM)




The reasons are basically PR: better reputation for GCC etc.  Maybe
even fashion: Clang does that, so how come we don't?


Furthermore, even despite those technical reasons, GCC is *still*
committed to not breaking those old programs anyway. GCC merely wants to
make those old programs have to be compiled in an "old-programs" mode.

Can you explain to me how you think this goal conflicts with your goal?

I already did, in previous messages, where I described what we all are
familiar with: the plight of a maintainer of a large software system
whose build suddenly breaks, and the difficulty in understanding which
part of the system's upgrade caused that.  I'd rather not repeat that:
there are already too many repetitions here that make the discussion
harder to follow.

Re: More C type errors by default for GCC 14

[Gabriel Ravier via Gcc]

On 5/12/23 04:36, Po Lu via Gcc wrote:

Arsen Arsenović  writes:


Indeed they should be - but warning vs. error holds significance.  A
beginner is much less likely to be writing clever code that allegedly
uses these features properly than to be building new code, and simply
having made an error that they do not want and will suffer through
confused.

Most programs already paste a chunk of Autoconf into their configure.ins
which turns on more diagnostics if it looks like the program is being
built by a developer.  i.e. from Emacs:

AC_ARG_ENABLE([gcc-warnings],
   [AS_HELP_STRING([--enable-gcc-warnings@<:@=TYPE@:>@],
   [control generation of GCC warnings.  The TYPE 'yes'
   means to fail if any warnings are issued; 'warn-only'
   means issue warnings without failing (default for
   developer builds); 'no' means disable warnings
   (default for non-developer builds).])],
   [case $enableval in
  yes|no|warn-only) ;;
  *)  AC_MSG_ERROR([bad value $enableval for gcc-warnings option]) ;;
esac
gl_gcc_warnings=$enableval],
   [# By default, use 'warn-only' if it looks like the invoker of 'configure'
# is a developer as opposed to a builder.  This is most likely true
# if GCC is recent enough and there is a .git directory or file;
# however, if there is also a .tarball-version file it is probably
# just a release imported into Git for patch management.
gl_gcc_warnings=no
if test -d "$srcdir"/.git && test ! -f "$srcdir"/.tarball-version; then
   # Clang typically identifies itself as GCC 4.2 or something similar
   # even if it is recent enough to accept the warnings we enable.
   AS_IF([test "$emacs_cv_clang" = yes],
  [gl_gcc_warnings=warn-only],
  [gl_GCC_VERSION_IFELSE([5], [3], [gl_gcc_warnings=warn-only])])
fi])

So this is really not a problem.


Indeed.  I said facilitates, not treats equally.  I think the veterans
here won't lose much by having to pass -fpermissive, and I think that's
a worthwhile sacrifice to make, to nurture the new without pressuring
the old very much.

Until `-fpermissive' goes the way of `-traditional',
`-fwritable-strings'.


On that note - lets presume a beginners role.  I've just started using
GCC.  I run 'gcc -O2 -Wall main.c fun.c' and I get an a.out.  It
mentions some 'implicit function generation', dunno what that means - if
it mattered much, it'd have been an error.  I wrote a function called
test that prints the int it got in hex, but I called it with 12.3, but
it printed 1.. what the heck?

Have you actually seen anyone make this mistake?
As somebody that spends a lot of time helping beginners, yes, 
constantly. I'd go as far as to say it's an error that seemingly 
everyone has made at least once.



Why that happened is obvious to you and I (if you're on the same CPU as
me), but to a beginner is utter nonsense.

At this point, I can only assume one goes to revisit that warning..  I'd
hope so at least.

I doubt the beginner would know to pass
-Werror=implicit-function-declaration in this case (or even about
Werror...  I just told them what -Wall and to read the warnings, which
was gleefully ignored)

I'd expect a question from the newbie, directed at a web search engine.


Hell, I've seen professors do it, and for a simple reason: they knew how
to write code, not how to use a compiler.  That's a big gap.

The beginner here can't adapt - they don't know what -Wall means, they
just pass it because they were told to do it (if they're lucky!).

If this is really such a bad problem, then how about clarifying the
error message?


At the same time, they lose out on what is, IMO, one of the most useful
pieces of the toolchain: _FORTIFY_SOURCE (assuming your vendor enables
it by default.. we do).  It provides effective bug detection, when the
code compiles right.  It regularly spots bugs that haven't happened yet
for me.

(and same goes for all the other useful analysis the toolchain can do
when it has sufficient information to generate correct code, or more;
some of which can't reasonably be a default)

(on a related note, IMO it's a shame that the toolchain hides so many
possibilities behind 'cult knowledge', depths of many manuals and bad
defaults)

_FORTIFY_SOURCE is not really important enough to be considered here.
It's not even available everywhere.


This sample is subject to selection bias.  My testing targets mostly
more modern codebases that have long fixed these errors (if they have
active maintainers), and exclusively Free Software, so I expect that the
likelyhood that you'll need to run `export CC='gcc -fpermissive'
CXX='g++ -fpermissive'` goes up the more you move towards old or more
corporate codebases, but, for a veteran, this is no cost at all.

Is it that much of a stretch to imagine that a maintainer of a codebase
that has not seen revisions to get it past K&R-esque practices would
know that they need to pas

Re: More C type errors by default for GCC 14

[Gabriel Ravier via Gcc]

On 5/12/23 15:19, Po Lu via Gcc wrote:

Jonathan Wakely  writes:


It's not about popularity. If that's your takeaway then you're not
paying attention, whatever you claim about reading everything in the
thread.  It's about helping people write correct code, first time,
without some of the avoidable traps that C presents.

The C ecosystem has a shockingly bad reputation when it comes to
security and "just don't write bugs" is naive and ineffective. Maybe
you're good enough for that to work, but then you should also be able
to cope with a change in defaults.

Right, and how many percent of those came from implicit function
declarations?  Implicit int?  Extern declarations in function scope
being applied at file scope?  Arithmetic between floats being done as
doubles?  Narrow-type promotion to unsigned int?


It's time for some defaults to change so that modern C is preferred,
and "implicit everything, hope the programmer got it right" requires
explicit action, *but it's still possible to do* for the 1970s
nostalgia fans.

It is impossible for implicit int to lead to bugs.
...You're joking, right ? You can't possibly be seriously arguing this, 
you have to be kidding... right ?



If you want to believe that's the start of a slippery slope, that's
your choice. The nostalgia club can always fork gcc if necessary,
that's one of the great things about free software.

I am not part of a nostalgia club, so you might as well stop using this
label.  In courtrooms, the plantiffs may be precluded from using
terminology that can mislead the jury.  This is more or less equivalent.


GCC has always taken backwards compatibility seriously. That doesn't
mean it is the prime directive and can never be violated, but it's
absolutely always considered. In this case, changing the default seems
appropriate to many people, including those who actually maintain gcc
and deal with the consequences of the current defaults.

What consequences?  Really?


Do you have anything new to add other than repeating the same
arguments? We've heard them now, thanks.

Yes, just these quotes from a former GCC maintainer:

   In C, we cannot divide all user code into "right" and "wrong" in this
   kind of simple way, and certainly not based on the ISO standard.  That
   standard is just the decisions of a certain committee (which I was a
   member of) about what cases conforming compilers should commit to
   support.  We must not let ourselves start thinking that C code is
   "wrong", just because it is not conforming ISO C code.

   C programs use many cases that are not conforming, but do work.  This
   will be true for as long as C is used, because changing it would
   require major changes in the C language.

   From time to time, there is a real *need* to make some of these cases
   stop working, for the sake of some benefit that users want.  When this
   happens, we should do it; the user community will accept it, because
   they will see that it is being done for their sake.  Some will
   grumble, but the users who appreciate the benefits will convince them.

   But when there is no *need* to break these cases, when we can keep
   them working fairly easily, we should keep them working.  If we break
   them unnecessarily, we invite the legitimate anger of the users.

and:

   You are arguing for a position that rejects the very idea of making an
   effort to keep old code working.  Your arguments support a general
   conclusion that "If code is not unambiguously valid, it is better to
   break the code than to keep it working."

   This is not just a harsh policy, it is an explicit policy of being
   harsh.  That is, it says, "Be harsh!  Choose the alternative that is
   harsh!"  This is the opposite of the way we should treat our users.

   I understand that your views are not based on sadism or cruelty; you
   think that treating users harshly is better for them.  But your
   motivation, like my motivation, is not the issue anyway.  To adopt a
   policy of harshness towards people--no matter what justification is
   offered for it--is treating them badly.  That is the wrong way to
   treat the users.  We must not make GCC decisions based on a policy of
   harshness.

   I would like future GCC decisions to be based on the policy that
   keeping old code working is a good thing to do, when it is practical
   of course.

   So if any argument leads to the conclusion that one should be harsh to
   the users, please recognize where the argument is taking you, and
   reject it on the grounds that it is a disguised policy of harshness.

   In particular, if it is argued that a policy of kindness has a
   disadvantage, and it turns out that the disadvantage is a consequence
   of the fact that the users have been treated kindly, it is really a
   disguised policy of harshness.

It is sad that this mature attitude no longer seems to be prevalent
among the current maintainership.

Re: More C type errors by default for GCC 14

[Gabriel Ravier via Gcc]

On 5/12/23 19:52, Florian Weimer wrote:

* Florian Weimer:


In summary, all these seems to be good candidates for errors by default:

* int-conversion as errors (already raised separately
* -Wint-conversion for ?:
* parameter names in non-prototype function declarations
* the union wait function pointer compatibility kludge
* return-with-out-value for non-void functions
* -Wincomatible-pointer-types warning for ?: (but no error yet, see below)

I think we have another problem.

We do not warn by default for:

   int x;
   unsigned *p;

   p = &x;

Isn't that a conformance issue because the pointers are incompatible,
requiring a diagnostic?

Furthermore, Unlike the char case, this tends to introduce
strict-aliasing violations, so there is a good reason to treat this
variant as an error (even if we would only warn for char * and
unsigned char *).


Isn't this allowed by the standard ? 6.5.7. Expressions states:
> An object shall have its stored value accessed only by an lvalue 
expression that has one of thefollowing types:[...] - a type that is the 
signed or unsigned type corresponding to the effective type of the object

Re: Will GCC eventually learn to use BSR or even TZCNT on AMD/Intel processors?

[Gabriel Ravier via Gcc]

On 6/5/23 12:17, Stefan Kanthak wrote:

--- failure.c ---
int _clz(unsigned long long argument) {
 return __builtin_clzll(argument);
}

int _ctz(unsigned long long argument) {
 return __builtin_ctzll(argument);
}
--- EOF ---

GCC 13.1-m32 -mabm -mbmi -mlzcnt -O3 failure.c


_clz(unsigned long long):
 mov edx, DWORD PTR [esp+8]
 xor ecx, ecx
 xor eax, eax
 lzcnt   eax, DWORD PTR [esp+4]
 add eax, 32
 lzcnt   ecx, edx
 testedx, edx
 cmovne  eax, ecx
 ret
_ctz(unsigned long long):
 sub esp, 20
 pushDWORD PTR [esp+28]
 pushDWORD PTR [esp+28]
 call__ctzdi2
 add esp, 28
 ret

OUCH: although EXPLICITLY enabled via -mabm (for AMD processors) and -mbmi
   (for Intel processors), GCC generates slowmotion code calling __ctzdi2()
   instead of TZCNT instructions available since 10 (in words: TEN) years.


GCC 13.1-m32 -march=i386 -O3 failure.c


_clz(unsigned long long):
 mov edx, DWORD PTR [esp+4]
 mov eax, DWORD PTR [esp+8]
 testeax, eax
 je  .L2
 bsr eax, eax
 xor eax, 31
 ret
.L2:
 bsr eax, edx
 xor eax, 31
 lea eax, [eax+32]
 ret
_ctz(unsigned long long):
 sub esp, 20
 pushDWORD PTR [esp+28]
 pushDWORD PTR [esp+28]
 call__ctzdi2
 add esp, 28
 ret

OUCH²: the BSF/BSR instructions were introduced 38 (in words: THIRTY-EIGHT)
years ago with the i386 processor, but GCC fails to know/use BSF --
a real shame!

OUCH³: an optimising compiler would of course generate "JMP __ctzdi2" instead
of code fiddling with the stack!

Stefan Kanthak



Hi,

While the optimization concerns your email raises appear to be genuine 
to some degree, I must admit to being quite clueless as to why, exactly, 
after at least 2 years of intermittently sending various seemingly quite 
incensed emails to this list, you appears not to have, at any point, 
questioned whether this method of action is in any way effective.


I myself have, too, made a hobby of investigating the capabilities of 
GCC's optimizer on various pieces of code, and trying to get it 
improved, by filing various appropriately formulated bugs in GCC's 
bugzilla whenever it seemed appropriate to do so (see e.g. 
https://gcc.gnu.org/PR94795, https://gcc.gnu.org/PR98957, 
https://gcc.gnu.org/PR102224 or https://gcc.gnu.org/PR104371 for what I 
believe to be pretty good examples of how to file such a bug).


I have not spent all this time sending various inflammatory emails to 
mailing lists not made for that purpose, and I am quite puzzled by the 
fact you appear to have concluded that doing so is appropriate. Should 
the page on GCC's website about the mailing lists perhaps contain a 
mention that the main mailing list is not made for spamming complaints 
about minor bugs ? I'd have figured it'd be self-evident, but evidently 
it seems this might perhaps be necessary...


Anyway, this leaves me with two more things I'd like to ask you about:

1. Why exactly are you so mad at GCC's optimizer and constantly belittle 
its capacities ? Did a GCC developer working on the optimizer destroy 
your hometown and salt the earth or something ? I also don't get why you 
put "optimizer" between quotes like that - is this supposed to imply 
calling GCC's optimizer as such is some insult to some hypothetical 
better optimizer ? (note: I say hypothetical because I haven't seen any 
optimizer that would be so much better than GCC's as to make it seem 
insultingly bad compared to it - Clang is comparable to GCC in its 
capacities but you also appear to hate it, given what I've seen 
elsewhere, and I'd expect other compilers like ICC and MSVC to be the 
ones that would be the butt of the joke here, given how poor they are 
compared to GCC and Clang...)


2. Are you aware that these emails are not only pretty useless, but 
potentially actively counterproductive ? I'd personally expect GCC 
developers, who are rightfully not particularly happy at the thought of 
having to constantly suffer your belittling emails, to at best actively 
ignore them - but even worse from what I presume would be your POV (that 
of someone who wants GCC's optimizer to improve), this constant spam 
might give rise to what would be a pretty reasonable response: to be 
biased against any proposed improvement that comes from or derives from 
your emails. Arguably, to not be biased against them would encourage you 
to keep sending more emails, which people do not want as of now.



PS: I hope you understand that I'm being somewhat generous when assuming 
you genuinely want to get GCC's optimizer to improve, and are simply 
failing to work effectively towards this goal. So

Re: Will GCC eventually learn to use BSR or even TZCNT on AMD/Intel processors?

[Gabriel Ravier via Gcc]

On 6/6/23 00:23, Dave Blanchard wrote:

On Mon, 5 Jun 2023 13:35:22 +0200
Gabriel Ravier via Gcc  wrote:


[pages of bullshit deleted]

2. Are you aware that these emails are not only pretty useless, but
potentially actively counterproductive ? I'd personally expect GCC
developers, who are rightfully not particularly happy at the thought of
having to constantly suffer your belittling emails, to at best actively
ignore them - but even worse from what I presume would be your POV (that
of someone who wants GCC's optimizer to improve), this constant spam
might give rise to what would be a pretty reasonable response: to be
biased against any proposed improvement that comes from or derives from
your emails.

Sounds like the response of an idiot, or a malignant individual who isn't 
interested in improving their junk code. A not-uncommon response in today's 
world, full of arrogant, self-righteous, brittle individuals who just can't 
stand criticism.


Well, while I don't agree with your opinion on the reasonableness of 
that response (while I'd say it would perhaps be ever so slightly over 
the top as of right now, I don't think it'd be that unreasonable, and 
Stefan's current behavior could easily escalate to a point where one 
could very reasonably want to avoid even a smidge of indirect 
interaction with him), my point is that such a response is a plausible 
one, and given you appear to assume bad faith on the part of the GCC 
developers, I can only assume you agree with me that such a reaction is 
indeed plausible, if for a different reason.





PS: I hope you understand that I'm being somewhat generous when assuming
you genuinely want to get GCC's optimizer to improve,

What? Are you claiming he *doesn't* want to see it improved?
I don't think he doesn't care about optimizers. Certainly, looking at 
his website for just a few minutes makes it clear that he very much 
cares a lot about them. But his behavior is so puzzling as to make me 
question how it's possible to argue his case so badly, as to stretch my 
capacity to apply Hanlon's razor: indeed, a technically possible, if 
hopefully wrong conjecture, would be that he does care a lot about the 
optimizer, but simply hates GCC's optimizer so badly (for failing to 
optimize his code exactly how he wants it to be) that he doesn't even 
care about improving it and just wants to shout at the developers 
endlessly over it. This *should* be obviously stupid, but his current 
behavior on this list makes this possibility practically 
indistinguishable to me from one that assumes good faith (and seemingly 
cripplingly bad communication skills) and, as a result, I need to make a 
conscious effort to assume such good faith on his part.



Someone else might  instead think you're just a troll

Not you, of course. No sir. You're smarter than that, right?
Well, either I'm spending my time trying to get someone to stop 
completely destroying any potential for them to actually be able to 
contribute to GCC's development, or am I indeed quite the fool and 
completely wasting my time for the enjoyment of someone who doesn't care 
at all. That's all I'm trying to say, I don't think assuming good faith 
magically makes your IQ go up.



that uses this as a pretext to send
inflammatory emails everywhere and waste the time of people like me.

I thought the entire purpose of these threads was to call attention to the fact 
that our time IS being wasted already, by the shitty GCC optimizer?

Dave

Wow, I'm actually impressed by how inflammatory you've managed to make 
this single sentence: it feels like you've managed to bottle up the very 
essence of flaming. Anyway, see above for what I meant by "waste the 
time of people like me", if you didn't understand what I meant by that.

Re: Will GCC eventually learn to use BSR or even TZCNT on AMD/Intel processors?

[Gabriel Ravier via Gcc]

On 6/6/23 02:09, Dave Blanchard wrote:

On Tue, 6 Jun 2023 01:59:42 +0200
Gabriel Ravier  wrote:


[nothing of value]

If this guy's threads are such a terrible waste of your time, how about 
employing your email client's filters to ignore his posts (and mine too) and 
fuck off?

Now YOU'RE wasting everyone's time, as your type is so skilled at doing, refocusing an 
important discussion to generic whining about "muh feelings", instead of the 
real issue at hand here: GCC's optimizer is TERRIBLE!
Well, evidently you have a completely different understanding of what 
the "important discussion" here is. I've simply been trying to respond 
to your emails in a manner I thought appropriate: I didn't think you 
were sending mails with the expectation that it is apparently 
unacceptable for me to respond to them, especially when they contain 
multiple explicit direct questions.


I for one appreciate this guy's posts, as this issue might have never been 
called to my attention otherwise; certainly not if this were relegated to the 
dusty corner of some bug list somewhere. I've now reverted to a much older 
version of GCC which will hopefully waste much fewer of my old computer's CPU 
cycles, while also (provably) not constantly breaking my system with all the 
added warnings and errors every release.


I did not think Poe's law would become applicable to so many discussions 
on this mailing list, but here I am... I guess that leaves me with only 
one question: are you actually serious in your claim that this "much 
older version of GCC" will produce faster code than a recent one ?




Dave

Re: inverse of compiling

[Gabriel Ravier via Gcc]

On 6/11/23 02:30, André Coelho via Gcc wrote:

hello


can we compile asm source code to c source code?

It is the inverse, so possiliby is that it is already coded?


thanks in advance


andre


https://en.wikipedia.org/wiki/Decompiler

Re: New version of gnu assembler

[Gabriel Ravier via Gcc]

On 7/2/23 18:52, Dave Blanchard wrote:

On Sat, 01 Jul 2023 13:33:07 +0100
Sam James via Gcc  wrote:


If you've taken files from Binutils BFD, please make sure you preserve
the copyright headers too.

Why? How is that important? That's all you have to say about this?

Copyright is an abomination, and especially so the GPL; particularly the GPLv3. 
I hope he put himself in legal jeopardy for no reason.

FTFY.


OP: Good work and nice project. The GNU ecosystem is full of bloated shitware 
and cruft, and it's nice to see people working to get rid of all the junk so we 
can have software that is actually usable and maintainable.

Dave

Re: GCC 10.5 Released

[Gabriel Ravier via Gcc]

On 7/8/23 14:37, Sidney Marshall wrote:
When I compile GCC 10.5.0 from /pub/gcc/releases/gcc-10.5.0 and run 
the resulting executable I get:


$ g++ --version
g++ (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.


Did I do something wrong?

--Sidney Marshall


If you're running g++ from the shell, then unless you have `.` in your 
PATH and its located before the usual `/bin` directories (very unlikely 
and an absolutely horrible idea), you're running the g++ binary that's 
provided by the system.


If you want to run a g++ binary located in your current directory, do 
`./g++`

Re: Supporting “crippled” MIPS implementations as cpu option

[Gabriel Ravier via Gcc]

On 3/6/25 3:07 PM, mzpqnxow via Gcc wrote:

Hello,

Direct questions listed at the end for the impatient :)

Hopefully my mail client wraps the text properly, if not, I apologize in
advance. I haven’t used this client for mailing list posts before…

I’m looking for information on GCC patch submission, hoping someone can
provide some guidance. Specifically, the formal or informal guidelines used
when determining if a specific submission is, in principle, something that
is welcomed, assuming it meets technical guidelines. I do not want to send
a patch if it won’t be considered as I don’t want to waste developers’ time

What I’m talking about: I would like to understand how open the project is
to accepting small patches that add support for a CPU (-mcpu targets) when
they’re very slight variations within a supported architecture

Why: I have the occasional need to have gcc emit MIPS1 instructions that do
not contain a subset of loads and stores (lwl/swl/lwr/swl instructions)

Context/History: There are several patches floating around that do this,
primarily from developers working on embedded networking development on a
few Realtek SoCs in the rtl819x family. These CPUs do not support these
instructions due to patent issues, and will SIGILL when encountering them.
I’m not aware of any work to contribute these upstream after a few quick
searches. There is extensive information available on OpenWRT [1]

Some specific questions:

1. Are any gcc mips experts aware of a way to accomplish what I described
above (no lwl/swl/lwr/swr instructions) *without* patching GCC? I have not
yet tested -mno-struct-align/-mstrict-align though they sound promising. I
plan to give them a try, it may render this all moot. I may be
misunderstanding precisely what they do
2. Are these sorts of patches (mcpu target, unpopular architecture)
generally considered currently?
3. If “it depends” - what are the primary considerations? Does the
popularity of the target factor into it? I admit that this CPU is not
popular and though it can still be found in embedded network devices, it is
only getting less common
4. If such a patch produces code that is inherently incompatible with glibc
(or some other core dependency of a common toolchain) is that considered a
blocker? What I’m referring to here is a (theoretical) example where glibc
uses the “bad” instructions in an asm block as part of some low-level
component (iirc, sigsetjmp, some of the loader functionality, etc. uses
hand-written asm)

I understand this is a pretty niche thing, only benefitting a subset of GCC
users, so I’m not expecting a lot of willingness to accept such a patch,
despite its relatively simplicity. I’m appreciative of any advice, guidance
or commentary the community has to offer, even if the answer is effectively
“don’t bother” :)

Thanks!

1. https://openwrt.org/docs/techref/hardware/soc/soc.realtek



I would generally expect/hope that such a patch would be relatively 
simple to accept, given that, unless I am gravely wrong about the 
meaning and functionality of the macro "ISA_HAS_LWL_LWR" in 
gcc/config/mips/mips.h, it seems like a patch should not actually 
involve much more than adjusting this macro (and adding some option for 
the corresponding CPUs, as you mentioned).