Hi,
On Friday, 7 October 2022 15:51:31 CEST Jason Merrill wrote:
> > * gcc.dg/noreturn-4.c: Likewise.
>
> I'd be inclined to drop this test.
That seems like an odd choice, why do that over using another function
for the test case? (there's nothing specific to main in this test, and
it doesn
On Thursday, 13 October 2022 19:10:10 CEST Jakub Jelinek wrote:
> Don't we have such a test already elsewhere? If not, then certain
> "warn for main" part should be removed or replaced...
Whoops, missed that comment. There is actually an equivalent test that
I overlooked (noreturn-1.c), so mayb
On Thursday, 13 October 2022 19:24:41 CEST Jason Merrill wrote:
> I was arguing that we don't need the new flag; there shouldn't be any
> need to turn it off.
At the time, I opted to go with a more conservative route; I haven't
been around enough to have very strong opinions ;) I certainly can't
On Thursday, 13 October 2022 23:16:02 CEST Jason Merrill wrote:
> I liked in the previous version that you checked the return type of
> main when !flag_hosted, here and in c_missing_noreturn_ok_p. Let's
> bring that back.
Ah, right; I forgot about that. What do you think of this?
Thanks,
--
A
Ping on this patch.
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603574.html
For context, see the rest of this thread. TL;DR is that `int main'
should implicitly return 0 on freestanding, without the other burdens of
main (hosted should remain unchanged, as well as non-int `main's).
On Friday, 21 October 2022 21:14:54 CEST Marek Polacek via Gcc wrote:
> commit 0a91bdaf177409a2a5e7895bce4f0e7091b4b3ca
> Author: Joseph Myers
> Date: Wed Sep 7 13:56:25 2022 +
>
> c: New C2x keywords
>
> which says:
>
> As with the removal of unprototyped functions, this change h
On Friday, 21 October 2022 21:55:53 CEST Florian Weimer wrote:
> That's the implicit function declaration/implicit int change. This
> won't happen in GCC 13, it's too late for that. I tried to make this
> change a couple of years in Fedora, and just flipping the compiler
> flag Does Not Work. I
On Friday, 21 October 2022 23:02:02 CEST Joseph Myers wrote:
> I have no objections to the C changes.
Great! Thanks for the review. I don't have push rights currently, so I
must ask that someone else pushes this patch for me.
Have a great day!
--
Arsen Arsenović
signature.asc
Description: T
Hi,
Florian Weimer via Gcc writes:
> Unfortunately, some build systems immediately delete the input source
> files. Is there some easy way I can dump the pre-processed and
> non-preprocessed sources to my log file? I tried to understand how
> -save-temps for crash recovery works, but it seems
Hi,
I was debugging PR96059 and ran into a question which does not seem
obvious from the code.
For the test case in the PR, in ipa.cc:remove_unreachable_nodes, GCC
seems to try to remove an unreachable function that was already inlined
into a different unreachable function. When the original inl
Philip Herron via Gcc writes:
> Hi Raiki
Welcome, Raiki!
> Excellent work on getting up to speed on the rust front-end. From my
> perspective I am interested to see what the wider GCC community thinks
> about using https://www.gnu.org/software/libunistring/ library within GCC
> instead of roll
s without looking into the problem
> myself.
>
> On Mon, Mar 13 2023, Arsen Arsenović via Gcc wrote:
>> Hi,
>>
>> I was debugging PR96059 and ran into a question which does not seem
>> obvious from the code.
>
> Thanks for looking into old bugs, it really is
"3119369616.qq via Gcc" writes:
> To divide functions into sections and then remove unused sections, I must
> provide flags "-fdata-sections" and "-ffunction-sections" in GCC and a flag
> "--gc-sections" in LD. Most of the build systems don't support these flags so
> GCC will generate bigger bin
Hi,
Martin Jambor writes:
> Hi,
>
> On Sat, Mar 18 2023, Arsen Arsenović wrote:
>> Martin Jambor writes:
>
> [...]
>
For the test case in the PR, in ipa.cc:remove_unreachable_nodes, GCC
seems to try to remove an unreachable function that was already inlined
into a different
Ruchit Raushan via Gcc writes:
> I don't want to receive further emails.
Please see https://gcc.gnu.org/mailman/listinfo/gcc
--
Arsen Arsenović
signature.asc
Description: PGP signature
Dave Blanchard writes:
> On Tue, 09 May 2023 16:07:50 +0100
> Sam James via Gcc wrote:
>
>> Florian did note this already - ABI. Implicit function declarations are
>> pretty horrible in a number of cases:
>> - they prevent fortification (_FORTIFY_SOURCE)
>
> So what? Print a warning, for those
Dave Blanchard writes:
> On Tue, 9 May 2023 16:14:28 +0100
> Jonathan Wakely via Gcc wrote:
>
>> This isn't "be like Clang", this is "diagnose things that have been
>> invalid C since 1999".
>
> And in the process, break half of my system, and make it even more of a pain
> in
> the ass to comp
Eli Zaretskii writes:
>> Cc: Jonathan Wakely , gcc@gcc.gnu.org
>> Date: Tue, 09 May 2023 18:38:05 +0200
>> From: Arsen Arsenović via Gcc
>>
>> You're actively dismissing the benefit.
>
> Which benefit?
>
> No one has yet explained why a warning
David Edelsohn writes:
> This seems to be the core tension. If developers cared about these issues,
> they would enable appropriate warnings and -Werror.
These issues are easy to miss and overlook. Making them louder helps
prevent that.
Additionally, requiring the users to remember a dozen f
Thomas Koenig via Gcc writes:
> Not replying to anybody in particular, just a bit of history, with
> some potential parallels.
>
> In gfortran, we have had two major issues with interfaces. One was that
> code which had happily violated the compiler ABI started failing, due
> to a fix in the gf
Eli Zaretskii writes:
> It is not GCC's business to force developers of packages to get their
> act together.
Why not? Compilers are diagnostic tools besides just machines that
guess what machine code you mean.
> It is the business of those package developers themselves. GCC should
> give th
Po Lu via Gcc writes:
> jwakely@gmail.com (Jonathan Wakely) writes:
>
>> This isn't "be like Clang", this is "diagnose things that have been
>> invalid C since 1999".
>
> Only if your definition of valid C is ``strictly conforming to the ISO
> Standard''. I doubt there are many programs whi
Po Lu via Gcc writes:
> Jonathan Wakely via Gcc writes:
>
>> On Wed, 10 May 2023, 03:32 Eli Zaretskii, wrote:
>>
>>>
>>> And then people will start complaining about GCC unnecessarily
>>> erroring out, which is a compiler bug, since there's no problem
>>> producing correct code in these cases.
Po Lu writes:
> Arsen Arsenović writes:
>
>> Good. The above code is nonsense, the chances that foo will be
>> incorrectly called are high.
>
> Yet lint (or scrutiny, as should be performed with any declaration,
> implicit or not) makes sure that does not happen.
Relying on human scrutiny whe
Eli Zaretskii writes:
>> Cc: Jonathan Wakely , gcc@gcc.gnu.org
>> Date: Thu, 11 May 2023 10:44:47 +0200
>> From: Arsen Arsenović via Gcc
>>
>> the current default of accepting this code in C is harmful to those
>> who are writing new code, or are learning
Hi,
Yair Lenga via Gcc writes:
> 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 {
Po Lu via Gcc writes:
...
> Where is it written that GNU CC follows your so-called
> ``specification-driven development''?
Any development style making documentation a source of truth matches
this principle. This does not refer to ISO specifications specifically,
though, normally, unless the
David Malcolm writes:
> [...snip...]
> I wrote that prototype, but I haven't touched it since 2017, and I
> already have more than enough other work, alas. I'm happy to help if
> someone wants to pick up the work and finish it.
>
> That patch kit did several things:
> (a) adds a new "on the sid
David Edelsohn writes:
> The GNU Toolchain leadership has blacklisted people in the past, but we
> have used the power sparingly.
>
> The behavior of the individual attracts attention, albeit negative, while
> not effectively accomplishing what he purports to desire. The recommended
> solution
zxuiji via Gcc writes:
> Your site is far too bright and is absolutely painful to the eyes, I
> have a simple invert style that I expected to work on all sites and I
> found your site is undertaking the vile act of blocking user styles. I
> expect that sort of rotten design from microsoft & appl
孟祥龙 writes:
> Dear Teacher,
>
>
> I hope this email finds you well. I am writing to kindly request a software
> usage license for the GCC for our research and development activities. We
> believe that this software would greatly contribute to our work and enable us
> to achieve our research go
Sam James via Gcc writes:
> Florian Weimer via Gcc writes:
>
>> My understanding of the consensus goes as follows:
>>
>> * We want to make some changes in this area for GCC 14.
>> * We should do the same thing that Clang does: default to the relevant
>> -Werror= options.
>> * Unlike regular w
Hi,
Sergei Trofimovich via Gcc writes:
> Sounds good. Do you have any preference over specific syntax? My
> suggestions would be:
>
> 1. `-fmacro-prefix-map=file-name`: if `file-name` there is not in `key=val`
>format then treat it as file
> 2. `-fmacro-prefix-map=@file-name`: use @ as a sig
Evening!
While working on
https://inbox.sourceware.org/20240414001113.1698685-1-ar...@aarsen.me/
I had noticed that libstdc++ currently does not get linked against an
in-tree libiconv, as the in-tree libiconv is only a host library.
Should it also be a target one?
With a quick hack of copying
Hi,
Sam James via Gcc writes:
> Hi!
>
> This comes up in #gcc on IRC every so often, so finally
> writing an RFC.
>
> What?
> ---
>
> I propose that MAINTAINERS be modified to be of the form,
> adding an extra field for their GCC/sourceware account:
>account>
> Joe
Hi,
Andrew Stubbs writes:
> On 24/06/2024 23:34, Arsen Arsenović via Gcc wrote:
>> I was also proposing (and would like to re-air that here) enforcing that
>> the committer field of each commit is a (valid) @gcc.gnu.org email.
>> This can be configured repo-locally vi
Hi,
Richard Biener writes:
> [snip]
>> I was also proposing (and would like to re-air that here) enforcing
>> that the committer field of each commit is a (valid) @gcc.gnu.org
>> email. This can be configured repo-locally via:
>>
>> $ git config committer.email @gcc.gnu.org
>>
>> Git has supp
Hi,
Thomas Koenig via Gcc writes:
> Am 25.06.24 um 21:08 schrieb Arsen Arsenović via Gcc:
>
>> Richard Biener writes:
>
>>> I'd welcome this - care to create a patch for
>>> contrib/gcc-git-customization.sh?
>> Sure - I've attached a partial pat
Hi,
"Richard Earnshaw (lists)" writes:
> On 24/06/2024 23:34, Arsen Arsenović via Gcc wrote:
>> Hi,
>>
>> Sam James via Gcc writes:
>>
>>> Hi!
>>>
>>> This comes up in #gcc on IRC every so often, so finally
>>> wr
"Richard Earnshaw (lists)" writes:
> On 25/06/2024 20:08, Arsen Arsenović via Gcc wrote:
>> Hi,
>>
>> Richard Biener writes:
>>
>>> [snip]
>>>> I was also proposing (and would like to re-air that here) enforcing
>>>> that t
Jonathan Wakely via Overseers writes:
> I don't care which account does the changes but I'd prefer to keep the
> emails. There's always at least one that reminds me a bug is actually fixed
> and should be closed, or the target milestone should be removed because it
> isn't going to be fixed on th
Hi!
Currently, I'm looking at PR115731. To summarize the issue, it is
possible for the user to, through coroutines, observe the closure type
of a lambda before it is completed. This closure type, in GCC, is
started before and finished after parsing the lambda body, meaning that
it is incomplete
Paul Eggert writes:
> One possible improvement would be to append "t32" if you want 32-bit time_t,
> instead of appending "t64" for 64-bit time_t. That way, people wouldn't be
> stuck with appending that confusing "t64" for the foreseeable future, and only
> specialists concerned with 32-bit time
Bruno Haible writes:
> Arsen Arsenović wrote:
>> An alternative that I pondered was to teach the linker about some notion
>> of "compatibility strings" that it would compare and reject if
>> different, plus teaching the compiler how to emit those, plus teaching
>> glibc to tell the compiler to em
Bruno Haible writes:
> Paul Eggert wrote:
>> I'd rather just switch, as Debian has.
>
> I'd go one step further, and not only
> make the ABI transition without changing the canonical triplet,
> but also
> make gcc and clang define -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64
> among their predefi
Jacob Bachmeyer writes:
>> At that point, we should bump SONAME of libc and simply remove 32-bit
>> time support. This would probably be okay generally.
>
> This is probably the best solution to this problem at hand, especially since
> the old ABI has a definite expiration date about 14 years fr
Eli Zaretskii via Gcc writes:
> Please don't remove the support for -Wtraditional if it's easy to fix.
> Removing it runs risk of breaking someone's program, so unless keeping
> it is a real dumper on GCC development, I hope you will keep it.
ISTM that it is proposed to ignore rather than reject
Thomas Koenig writes:
> [For the fortran people: Discussion on gcc@]
>
> Just a general remark.
>
> There are people, such as myself, who regularly mess up
> their git repositories because they have no mental model
> of what git is doing (case in point: The Fortran unsigned
> branch, which I mana
Hi,
Georg-Johann Lay writes:
> For a trivial change that I'd like to bootstrap + regtest, I am
> am getting FAILs like:
>
> $ diff xxx/gcc/testsuite/gcc/gcc.sum yyy/gcc/testsuite/gcc/gcc.sum
> 164656c164656
> < PASS: c-c++-common/tsan/atomic_stack.c -O0 output pattern test
> ---
>> FAIL: c-c
Thomas Koenig via Gcc writes:
> (Incidentally, the mailing system messes up the UTF-8 represntation
> of my last name, König, maybe that is somehing to do with it).
IIRC my commits were failing to go through due to the presence of a "ć"
in my /etc/passwd entry on Sourceware. This might be the s
50 matches
Mail list logo
