Re: [wwwdocs] a bug report about some deprecated parts of gcc

On 31/01/2025 14:22, noname noname via Gcc wrote: hello, I'm a regular user of Fedora 41 Workstation. I usually install all my apps through one command which has tons of packages to it. So I'm not sure which one of them pulled gcc as a dependency. But either way. While installing all of them, dnf

Re: [wwwdocs] a bug report about some deprecated parts of gcc

On 31/01/2025 14:22, noname noname via Gcc wrote: hello, I'm a regular user of Fedora 41 Workstation. I usually install all my apps through one command which has tons of packages to it. So I'm not sure which one of them pulled gcc as a dependency. But either way. While installing all of them, dnf

Re: New function attribute __call_push_jmp__

On 01/12/2024 23:55, Frederick Virchanza Gotham via Gcc wrote: Some modern CPU's now have control flow enforcement. Here's how it works on Intel CPU's: "The shadow stack stores a copy of the return address of each CALL. On a RET, the processor checks if the return address stored in the normal st

Re: Two suggestions for GCC beginners projects

On 28/11/2024 12:18, Aaron Peter Bachmann via Gcc wrote: Two suggestions for GCC beginners projects I watched some of the 2024 Gnu Cauldron videos. The question of what could be a suitable project for a beginner came up. I have two suggestions: 1.    Add a warning when users use reserved or p

Re: -Wfloat-equal and comparison to zero

On 13/11/2024 22:34, James K. Lowden wrote: On Thu, 14 Nov 2024 10:04:59 +0100 David Brown via Gcc wrote: No. This is - or at least appears to be - missing critical thinking. You are explaining this to someone who designed research databases and who implemented quantitative models that ran

Re: -Wfloat-equal and comparison to zero

On 12/11/2024 22:44, James K. Lowden wrote: On Tue, 12 Nov 2024 18:12:50 +0100 David Brown via Gcc wrote: Under what circumstances would you have code that : ... d) Would be perfectly happy with "x" having the value 2.225e-307 (or perhaps a little larger) and doing the division

Re: -Wfloat-equal and comparison to zero

On 12/11/2024 15:29, Sad Clouds via Gcc wrote: On Mon, 11 Nov 2024 21:14:43 + (UTC) Joseph Myers wrote: I don't think this has anything to do with whether one operand of the comparison is a constant. It's still the case when comparing with 0.0 that it's OK if your algorithm is designed su

Re: feature request: a linker option to avoid merging variables from separate object files into shared cache lines

On 24/10/2024 16:35, Jonathan Wakely via Gcc wrote: On Thu, 24 Oct 2024 at 15:00, Mateusz Guzik via Gcc wrote: I understand the stock behavior of pilling variables on may happen to improve cache usage. However, in a multicore setting it is a never-ending source of unintentionally showing up a

Re: Is there a need to sometimes change gcc/config/t-* files when building a cross compiler?

On 27/09/2024 10:13, Dennis Luehring via Gcc wrote: Am 27.09.2024 um 09:56 schrieb Jonathan Wakely: On Fri, 27 Sept 2024, 08:39 Dennis Luehring, wrote: > Am 27.09.2024 um 09:34 schrieb Jonathan Wakely: > > > > They might not have > > been using the original gcc-3.4.0 sources. > > > seems to be

Re: spelling of `side effects` vs `side-effects`

On 23/09/2024 22:09, Andrew Pinski via Gcc wrote: While working on the review from https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663418.html . I noticed that there are places which use `side effects` and some use `side-effects`. I assume we should follow a similar pattern as `back-end`

Re: Apply function attributes (e.g., [[gnu::access()]]) to pointees too

On 11/07/2024 11:58, Martin Uecker via Gcc wrote: Am Donnerstag, dem 11.07.2024 um 11:35 +0200 schrieb Alejandro Colomar via Gcc: Hi, I was wondering how we could extend attributes such as gnu::access() to apply it to pointees too. Currently, there's no way to specify the access mode of a poi

Re: How to avoid some built-in expansions in gcc?

On 04/06/2024 19:43, Michael Matz via Gcc wrote: Hello, On Tue, 4 Jun 2024, Richard Biener wrote: A pragmatic solution might be a new target hook, indicating a specified builtin is not to be folded into an open-coded form. Well, that's what the mechanism behind -fno-builtin-foobar is suppose

Re: Is fcommon related with performance optimization logic?

On 30/05/2024 04:26, Andrew Pinski via Gcc wrote: On Wed, May 29, 2024 at 7:13 PM 赵海峰 via Gcc wrote: Dear Sir/Madam, We found that running on intel SPR UnixBench compiled with gcc 10.3 performs worse than with gcc 8.5 for dhry2reg benchmark. I found it related with -fcommon option which i

Re: aliasing

On 18/03/2024 16:00, Martin Uecker via Gcc wrote: Am Montag, dem 18.03.2024 um 14:29 +0100 schrieb David Brown: On 18/03/2024 12:41, Martin Uecker wrote: Hi David, Am Montag, dem 18.03.2024 um 10:00 +0100 schrieb David Brown: Hi, I would very glad to see this change in the standards

Re: aliasing

On 18/03/2024 17:46, David Brown via Gcc wrote: On 18/03/2024 14:54, Andreas Schwab via Gcc wrote: On Mär 18 2024, David Brown wrote: I think it would be possible to have an implementation where "signed char" was 8-bit two's complement except that 0x80 would be a trap repres

Re: aliasing

On 18/03/2024 14:54, Andreas Schwab via Gcc wrote: On Mär 18 2024, David Brown wrote: I think it would be possible to have an implementation where "signed char" was 8-bit two's complement except that 0x80 would be a trap representation rather than -128. signed char cannot ha

Re: aliasing

On 18/03/2024 12:41, Martin Uecker wrote: Hi David, Am Montag, dem 18.03.2024 um 10:00 +0100 schrieb David Brown: Hi, I would very glad to see this change in the standards. Should "byte type" include all character types (signed, unsigned and plain), or should it be res

Re: aliasing

Hi, I would very glad to see this change in the standards. Should "byte type" include all character types (signed, unsigned and plain), or should it be restricted to "unsigned char" since that is the "byte" type ? (I think allowing all character types makes sense, but only unsigned char is

Re: Optimization of bit field assignemnts

On 12/02/2024 17:47, Hugh Gleaves via Gcc wrote: I’m interested in whether it would be feasible to add an optimization that compacted assignments to multiple bit fields. Today, if I have a 32 bit long struct composed of say, four 8 bit fields and assign constants to them like this:

Re: issue: unexpected results in optimizations

Hi, First, please ignore everything Dave Blanchard writes. I don't know why, but he likes to post angry, rude and unhelpful messages to this list. Secondly, this is the wrong list. gcc-help would be the correct list, as you are asking for help with gcc. This list is for discussions on the

Re: Suboptimal warning formatting with `bool` type in C

On 02/11/2023 00:28, peter0x44 via Gcc wrote: On 2023-11-01 23:13, Joseph Myers wrote: On Wed, 1 Nov 2023, peter0x44 via Gcc wrote: Why is #define used instead of typedef? I can't imagine how this could possibly break any existing code. That's how stdbool.h is specified up to C17.  In C23,

Re: C89 question: Do we need to accept -Wint-conversion warnings

On 11/10/2023 12:17, Florian Weimer wrote: * David Brown: On 11/10/2023 10:10, Florian Weimer wrote: * David Brown: So IMHO (and as I am not a code contributor to GCC, my opinion really is humble) it is better to be stricter than permissive, even in old standards. It is particularly

Re: C89 question: Do we need to accept -Wint-conversion warnings

On 11/10/2023 10:10, Florian Weimer wrote: * David Brown: So IMHO (and as I am not a code contributor to GCC, my opinion really is humble) it is better to be stricter than permissive, even in old standards. It is particularly important for "-std=c89", while "-std=gnu89&quo

Re: C89 question: Do we need to accept -Wint-conversion warnings

On 10/10/2023 18:30, Jason Merrill via Gcc wrote: On Tue, Oct 10, 2023 at 7:30 AM Florian Weimer via Gcc wrote: Are these code fragments valid C89 code? int i1 = 1; char *p1 = i; char c; char *p2 = &c; int i2 = p2; Or can we generate errors for them even with -std=gnu89? (It

Re: seek advice about GCC learning

On 26/09/2023 08:48, weizhe wang via Gcc wrote: Thanks for your reply. Is there some guide for building rv32 cross compiler gcc ? I encounter some error in the building progress. You might find useful information here:

Re: GCC support addition for Safety compliances

On 12/07/2023 14:43, Jonathan Wakely via Gcc wrote: On Wed, 12 Jul 2023 at 10:25, Vishal B Patil via Gcc wrote: Hi Team, Any updates ? You're not going to get any useful answers. You asked "Please share the costs and time as well." Costs for what? From whom? GCC is an open-source project

Re: user sets ABI

On 07/07/2023 00:27, André Albergaria Coelho via Gcc wrote: What if the user chooses in own ABI, say specifying a config file like My abi " Parameters = pushed in stack" say gcc -abi "My abi" some.c -o some what would be the problems of specifying an ABI?? would that improve the usage of u

Re: wishlist: support for shorter pointers

On 06/07/2023 09:00, Rafał Pietrak via Gcc wrote: Hi, W dniu 5.07.2023 o 19:39, David Brown pisze: [--] I'm not sure what this means? At compile time, you only have literals, so what's missing? The compiler knows a lot more than just literal values at compile time

Re: wishlist: support for shorter pointers

On 05/07/2023 18:13, Rafał Pietrak via Gcc wrote: Hi, W dniu 5.07.2023 o 16:45, David Brown pisze: On 05/07/2023 15:29, Rafał Pietrak wrote: [---] OK. I don't see a problem here, but I admit that mixing semantics often lead to problems. I think it also allows b

Re: wishlist: support for shorter pointers

On 05/07/2023 15:29, Rafał Pietrak wrote: Hi, W dniu 5.07.2023 o 14:57, David Brown pisze: [] My objection to named address spaces stem from two points: 1. They are compiler implementations, not user code (or library code), which means development is inevitably much slower and

Re: wishlist: support for shorter pointers

On 05/07/2023 14:25, Rafał Pietrak wrote: Hi, W dniu 5.07.2023 o 13:55, David Brown pisze: On 05/07/2023 11:42, Rafał Pietrak via Gcc wrote: [--] So your current objections to named spaces ... are in fact in favor of them. Isn't it so? Not really, no - I would rathe

Re: wishlist: support for shorter pointers

On 05/07/2023 11:42, Rafał Pietrak via Gcc wrote: Hi, W dniu 5.07.2023 o 11:11, David Brown pisze: On 05/07/2023 10:05, Rafał Pietrak via Gcc wrote: [---] I am not sure if you are clear about this, but the address space definition macros here are for use in the source code for the

Re: wishlist: support for shorter pointers

On 05/07/2023 11:25, Martin Uecker wrote: Am Mittwoch, dem 05.07.2023 um 11:11 +0200 schrieb David Brown: On 05/07/2023 10:05, Rafał Pietrak via Gcc wrote: ... In my personal opinion (which you are all free to disregard), named address spaces were an interesting idea that failed.  I was

Re: wishlist: support for shorter pointers

On 05/07/2023 10:05, Rafał Pietrak via Gcc wrote: Hi, W dniu 5.07.2023 o 09:29, Martin Uecker pisze: Am Mittwoch, dem 05.07.2023 um 07:26 +0200 schrieb Rafał Pietrak: [---] And if it's so ... there is no mention of how does it show up for "simple user" of the GCC (instead of the use of th

Re: wishlist: support for shorter pointers

On 04/07/2023 16:46, Rafał Pietrak wrote: Hi, W dniu 4.07.2023 o 14:38, David Brown pisze: [-] A key difference is that using 32-bit pointers on an x86 is enough address space for a large majority of use-cases, while even on the smallest small ARM microcontroller, 16-bit is not enough

Re: wishlist: support for shorter pointers

On 04/07/2023 16:20, Rafał Pietrak wrote: W dniu 3.07.2023 o 18:29, Rafał Pietrak pisze: Hi David, [--] 4. It is worth taking a step back, and thinking about how you would like to use these pointers.  It is likely that you would be better thinking in terms of an array, rather t

Re: wishlist: support for shorter pointers

On 03/07/2023 18:42, Rafał Pietrak via Gcc wrote: Hi Ian, W dniu 3.07.2023 o 17:07, Ian Lance Taylor pisze: On Wed, Jun 28, 2023 at 11:21 PM Rafał Pietrak via Gcc wrote: [] I was thinking about that, and it doesn't look as requiring that deep rewrites. ABI spec, that  could accomodat

Re: wishlist: support for shorter pointers

On 28/06/2023 10:35, Rafał Pietrak via Gcc wrote: Hi Jonathan, W dniu 28.06.2023 o 09:31, Jonathan Wakely pisze: If you use a C++ library type for your pointers the syntax above doesn't need to change, and the fancy pointer type can be implemented portable, with customisation for targets w

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

On 06/06/2023 14:53, Paul Smith wrote: On Tue, 2023-06-06 at 16:36 +0800, Julian Waters via Gcc wrote: Sorry for my outburst, to the rest of this list. I can no longer stay silent and watch these little shits bully people who are too kind to fire back with the same kind of venom in their words.

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

On 06/06/2023 02:09, Dave Blanchard wrote: 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? You apparently appreciate Stefan's posts, but burst a blood vessel when reading anyone els

Re: Who cares about performance (or Intel's CPU errata)?

On 28/05/2023 01:30, Andrew Pinski via Gcc wrote: On Sat, May 27, 2023 at 3:54 PM Stefan Kanthak wrote: seteal movzx eax, al # superfluous No it is not superfluous, well ok it is because of the context of eax (besides the lower 8 bits) are already

Re: Will GCC eventually support correct code compilation?

On 27/05/2023 20:16, Dave Blanchard wrote: On Fri, 26 May 2023 18:44:41 +0200 David Brown via Gcc wrote: On 26/05/2023 17:49, Stefan Kanthak wrote: I don't like to argue with idiots: they beat me with experience! Stefan Stefan, you are clearly not happy about the /free/ compiler yo

Re: Will GCC eventually support SSE2 or SSE4.1?

On 26/05/2023 17:49, Stefan Kanthak wrote: I don't like to argue with idiots: they beat me with experience! Stefan Stefan, you are clearly not happy about the /free/ compiler you are using, and its /free/ documentation (which, despite its flaws, is better than I have seen for most other co

Re: More C type errors by default for GCC 14

On 14/05/2023 07:28, Po Lu via Gcc wrote: Eli Schwartz writes: Quoting my previous reply on the topic. Until everyone is on the same page as you about whether these are GNUC extensions, this conversation will go nowhere. You are of the opinion that "GCC currently behaves a certain way when c

Re: More C type errors by default for GCC 14

On 14/05/2023 07:38, Po Lu via Gcc wrote: No, all you have to do is to tell GNU CC to compile Standard C. But what's being debated here is the behavior of GNU CC when translating both Standard C and GNU C, so your demonstration is almost completely pointless. You keep using the term "Standard

Re: [wish] Flexible array members in unions

On 12/05/2023 08:16, Richard Biener via Gcc wrote: On Thu, May 11, 2023 at 11:14 PM Kees Cook via Gcc wrote: On Thu, May 11, 2023 at 08:53:52PM +, Joseph Myers wrote: On Thu, 11 May 2023, Kees Cook via Gcc wrote: On Thu, May 11, 2023 at 06:29:10PM +0200, Alejandro Colomar wrote: On 5/1

Re: More C type errors by default for GCC 14

On 12/05/2023 04:08, Po Lu via Gcc wrote: Eli Schwartz writes: 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 va

Re: More C type errors by default for GCC 14

On 11/05/2023 04:09, Po Lu via Gcc wrote: jwakely@gmail.com (Jonathan Wakely) writes: So let's do it. Let's write a statement saying that the GCC developers consider software security to be of increasing importance, and that we consider it irresponsible to default to accepting invalid const

Re: More C type errors by default for GCC 14

On 10/05/2023 18:28, Eli Zaretskii via Gcc wrote: Date: Wed, 10 May 2023 17:58:16 +0200 From: David Brown via Gcc In any case, I was not not talking about bug-compatibility, I was talking about being able to compile code which GCC was able to compile in past versions. Being able to compile

Re: More C type errors by default for GCC 14

On 10/05/2023 16:39, Eli Zaretskii via Gcc wrote: Date: Wed, 10 May 2023 15:30:02 +0200 From: David Brown via Gcc If some developers want to ignore warnings, it is not the business of GCC to improve them, even if you are right in assuming that they will not work around errors like they work

Re: More C type errors by default for GCC 14

On 10/05/2023 16:14, Eli Zaretskii via Gcc wrote: Date: Wed, 10 May 2023 14:41:27 +0200 Cc: jwakely@gmail.com, fwei...@redhat.com, gcc@gcc.gnu.org, ar...@aarsen.me From: Gabriel Ravier Because GCC is capable of compiling it. That is not a good argument. GCC is capable of compiling any

Re: More C type errors by default for GCC 14

On 10/05/2023 15:10, Basile Starynkevitch wrote: Hello all, After a suggestion by Eric Gallager Idea for a compromise: What if, instead of flipping the switch on all 3 of these at once, we staggered them so that each one becomes a default in a separate release? i.e., something like: - GCC 14:

Re: More C type errors by default for GCC 14

On 10/05/2023 14:22, Eli Zaretskii via Gcc wrote: From: Jonathan Wakely Date: Wed, 10 May 2023 12:49:52 +0100 Cc: David Brown , gcc@gcc.gnu.org If some developers want to ignore warnings, it is not the business of GCC to improve them, even if you are right in assuming that they will not work

Re: More C type errors by default for GCC 14

On 09/05/2023 22:13, David Edelsohn via Gcc wrote: On Tue, May 9, 2023 at 3:22 PM Eli Zaretskii via Gcc wrote: Date: Tue, 9 May 2023 21:07:07 +0200 From: Jakub Jelinek Cc: Jonathan Wakely , ar...@aarsen.me, gcc@gcc.gnu.org On Tue, May 09, 2023 at 10:04:06PM +0300, Eli Zaretskii via Gcc wro

Re: More C type errors by default for GCC 14

On 09/05/2023 21:04, Eli Zaretskii via Gcc wrote: From: Jonathan Wakely Date: Tue, 9 May 2023 18:15:59 +0100 Cc: Arsen Arsenović , gcc@gcc.gnu.org On Tue, 9 May 2023 at 17:56, Eli Zaretskii wrote: No one has yet explained why a warning about this is not enough, and why it must be made an erro

Re: Is it possible to enable data sections and function sections without explicitly giving flags "-fdata-sections" and "-ffunction-sections"?

On 19/03/2023 13:38, 3119369616.qq via Gcc wrote: 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 b

Re: Please, really, make `-masm=intel` the default for x86

On 25/11/2022 07:39, LIU Hao via Gcc wrote: I am a Windows developer and I have been writing x86 and amd64 assembly for more than ten years. One annoying thing about GCC is that, for x86 if I need to write I piece of inline assembly then I have to do it twice: one in AT&T syntax and one in Inte

Re: [BUG] -Wuninitialized: initialize variable with itself

On 14/11/2022 16:10, NightStrike wrote: On Mon, Nov 14, 2022, 04:42 David Brown via Gcc Warnings are not perfect - there is always the risk of false positives and false negatives.  And different people will have different ideas about what code is perfectly reasonable, and

Re: [BUG] -Wuninitialized: initialize variable with itself

On 13/11/2022 19:43, Alejandro Colomar via Gcc wrote: Hi Andrew! On 11/13/22 19:41, Andrew Pinski wrote: On Sun, Nov 13, 2022 at 10:40 AM Andrew Pinski wrote: On Sun, Nov 13, 2022 at 10:36 AM Alejandro Colomar via Gcc wrote: Hi, While discussing some idea for a new feature, I tested the

Re: -Wint-conversion, -Wincompatible-pointer-types, -Wpointer-sign: Are they hiding constraint C violations?

On 10/11/2022 20:16, Florian Weimer via Gcc wrote: * Marek Polacek: On Thu, Nov 10, 2022 at 07:25:21PM +0100, Florian Weimer via Gcc wrote: GCC accepts various conversions between pointers and ints and different types of pointers by default, issuing a warning. I've been reading the (hopefully

Re: Local type inference with auto is in C2X

On 03/11/2022 16:19, Michael Matz via Gcc wrote: Hello, On Thu, 3 Nov 2022, Florian Weimer via Gcc wrote: will not have propagated widely once GCC 13 releases, so rejecting implicit ints in GCC 13 might be too early. GCC 14 might want to switch to C23/C24 mode by default, activating auto supp

Re: rust non-free-compatible trademark

On 17/07/2022 18:31, Mark Wielaard wrote: Hi Luke, On Sun, Jul 17, 2022 at 04:28:10PM +0100, lkcl via Gcc wrote: with the recent announcement that rust is supported by gcc There is just a discussion about whether and how to integrate (portions) of the gccrs frontend into the main gcc reposito

Re: Gcc Digest, Vol 29, Issue 7

On 05/07/2022 09:19, Yair Lenga via Gcc wrote: Hi, Wanted to get some feedback on an idea that I have - trying to address the age long issue with type check on VA list function - like 'scanf' and friends. In my specific case, I'm trying to build code that will parse a list of values from SELECT

Re: reordering of trapping operations and volatile

On 11/01/2022 08:11, Richard Biener via Gcc wrote: > On Mon, Jan 10, 2022 at 6:36 PM Martin Uecker wrote: >> > > I realize that UB in a + b isn't (usually) observable but > UB resulting in traps are. > > So I'm still wondering why you think that 'volatile' makes > a critical difference we oug

Re: reordering of trapping operations and volatile

On 08/01/2022 09:32, Martin Uecker via Gcc wrote: > > Hi Richard, > > I have a question regarding reodering of volatile > accesses and trapping operations. My initial > assumption (and hope) was that compilers take > care to avoid creating traps that are incorrectly > ordered relative to observa

Re: Can gcc.dg/torture/pr67828.c be an infinite loop?

On 24/09/2021 10:03, Aldy Hernandez via Gcc wrote: > Hi folks. > > My upcoming threading improvements turn the test below into an infinite > runtime loop: > > int a, b; > short c; > > int > main () > { >   int j, d = 1; >   for (; c >= 0; c++) >     { > BODY: >   a = d; >   d = 0; >

Re: Can gcc.dg/torture/pr67828.c be an infinite loop?

On 24/09/2021 11:38, Andrew Pinski via Gcc wrote: > On Fri, Sep 24, 2021 at 2:35 AM Aldy Hernandez wrote: >> >> >> >> On 9/24/21 11:29 AM, Andrew Pinski wrote: >>> On Fri, Sep 24, 2021 at 1:05 AM Aldy Hernandez via Gcc >>> wrote: >>> Huh about c>=0 being always true? the expression, "c++"

Re: Can gcc.dg/torture/pr67828.c be an infinite loop?

On 24/09/2021 10:59, Aldy Hernandez via Gcc wrote: > > > On 9/24/21 10:08 AM, Richard Biener wrote: >> On Fri, Sep 24, 2021 at 10:04 AM Aldy Hernandez via Gcc >> wrote: >>> >>> Is this correct, or did I miss something? >> >> Yes, 'c' will wrap to negative SHORT_MIN and terminate the loop via >>

Re: unexpected result with -O2 solved via "volatile"

On 19/09/2021 20:17, Allin Cottrell via Gcc wrote: > Should this perhaps be considered a bug? Below is a minimal test case > for a type of calculation that occurs in my real code. It works as > expected when compiled without optimization, but produces what seems > like a wrong result when compiled

Re: a feature to the wishlist

On 14/09/2021 20:48, Rafał Pietrak wrote: W dniu 13.09.2021 o 13:41, David Brown pisze: On 13/09/2021 11:51, Rafał Pietrak via Gcc wrote: Hi, Thenk you for very prompt reply. (I'm not sure how much this is a "gcc development list" matter, rather than perhaps a &qu

Re: a feature to the wishlist

On 13/09/2021 11:51, Rafał Pietrak via Gcc wrote: > Hi, > > Thenk you for very prompt reply. (I'm not sure how much this is a "gcc development list" matter, rather than perhaps a "gcc help list" or perhaps comp.arch.embedded Usenet group discussion, but I'll continue here until Jonathan or other

Re: [Questions] Is there any bit in gimple/rtl to indicate this IR support fast-math or not?

On 14/07/2021 09:49, Matthias Kretz wrote: > On Wednesday, 14 July 2021 09:39:42 CEST Richard Biener wrote: >> -ffast-math decomposes to quite some flag_* and those generally are not >> reflected into the IL but can be different per function (and then >> prevent inlining). > > Is there any chance

Re: Using source-level annotations to help GCC detect buffer overflows

Thanks for the reply here. I've snipped a bit to save space. On 30/06/2021 19:12, Martin Sebor wrote: On 6/29/21 12:31 PM, David Brown wrote: On 29/06/2021 17:50, Martin Sebor wrote: On 6/29/21 6:27 AM, David Brown wrote: On 28/06/2021 21:06, Martin Sebor via Gcc wrote: I wro

Re: Using source-level annotations to help GCC detect buffer overflows

On 29/06/2021 17:50, Martin Sebor wrote: > On 6/29/21 6:27 AM, David Brown wrote: >> On 28/06/2021 21:06, Martin Sebor via Gcc wrote: >>> I wrote an article for the Red Hat Developer blog about how >>> to annotate code to get the most out of GCC's access checking

Re: Using source-level annotations to help GCC detect buffer overflows

On 28/06/2021 21:06, Martin Sebor via Gcc wrote: > I wrote an article for the Red Hat Developer blog about how > to annotate code to get the most out of GCC's access checking > warnings like -Warray-bounds, -Wformat-overflow, and > -Wstringop-overflow.  The article published last week: > > https:/

Re: [RFC] Implementing detection of saturation and rounding arithmetic

On 12/05/2021 10:00, Tamar Christina wrote: > Hi David, > >> -Original Message----- >> From: David Brown >> Sent: Tuesday, May 11, 2021 11:04 AM >> To: Tamar Christina ; gcc@gcc.gnu.org >> Cc: Richard Sandiford ; Richard Biener >> >> Subject

Re: [RFC] Implementing detection of saturation and rounding arithmetic

On 11/05/2021 19:00, Joseph Myers wrote: > On Tue, 11 May 2021, David Brown wrote: > >> It is also worth noting that gcc already has support for saturating >> types on some targets: >> >> <https://gcc.gnu.org/onlinedocs/gcc/Fixed-Point.html> >> >>

Re: [RFC] Implementing detection of saturation and rounding arithmetic

On 11/05/2021 07:37, Tamar Christina via Gcc wrote: > Hi All, > > We are looking to implement saturation support in the compiler. The aim is to > recognize both Scalar and Vector variant of typical saturating expressions. > > As an example: > > 1. Saturating addition: >char sat (char a, cha

Re: -flto and -Werror

On 04/05/2021 14:39, Matthias Klose wrote: > Using -flto exposes some new warnings in code, as seen in the both build logs > below, for upstream elfutils and systemd. I have seen others. These > upstreams > enable -Werror by default, but probably don't see these warnings turning to > errors them

Re: removing toxic emailers

On 20/04/2021 16:15, Richard Kenner via Gcc wrote: >> Just for the record, Google has no problem with the GPLv3. Google stopped >> working on GCC because they made a company decision to use clang instead. >> That decision was made for technical reasons, not licensing reasons. > > But note that so

Re: On US corporate influence over Free Software and the GCC Steering Committee

On 20/04/2021 08:54, Giacomo Tesio wrote: > Hi GCC developers, > > just to further clarify why I think the current Steering Committee is highly > problematic, > I'd like you to give a look at this commit > message over Linux MAINTAINERS > > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/

Re: removing toxic emailers

ies are doing wrong for gcc? How do you think they are influencing it? Who are all these "concerned people" ? If you have justification, evidence, or even a rational argument for your concerns, please share them. If not, please stop repeating baseless paranoia. You have made your point, such as it is - please move along now. (That is not censorship - it's just a polite request to stop wasting people's time.) David Brown

Re: GCC association with the FSF

On 11/04/2021 17:06, Jonathan Wakely via Gcc wrote: > On Sun, 11 Apr 2021, 15:26 Richard Sandiford via Gcc, >> >> FWIW, again speaking personally, I would be in favour of joining a fork.[*] >> > > Glad to hear it :-) > > I will be forking, alone if necessary, but I've already been told by a few

Re: GCC association with the FSF

On 11/04/2021 16:37, Richard Kenner via Gcc wrote: >> I guess my point is that the direction in which a project *does* go is not >> always the direction in which it *should* go. > > I agree. And depending on people's "political" views, that can either be > an advantage or disadvantage of the fr

Re: GCC association with the FSF

On 11/04/2021 15:39, Alfred M. Szmidt wrote: >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. > > Then it would not longer be GCC. It

Re: GCC association with the FSF

On 10/04/2021 14:58, Pankaj Jangid wrote: > > I have never said that the project will survive without maintainers. I > just asked you to count me as well. Success of the project also depends > on how widely it is used. And you need to look at the reasons why people > are using it. > I think it i

Re: GCC association with the FSF

On 09/04/2021 20:36, John Darrington wrote: > On Fri, Apr 09, 2021 at 07:01:07PM +0200, David Brown wrote: > > Different opinions are fine. Bringing national or international > politics into the discussion (presumably meant to be as an insult) is > not fine.

Re: GCC association with the FSF

On 09/04/2021 20:02, Christopher Dimech wrote: > >> Sent: Saturday, April 10, 2021 at 5:01 AM >> From: "David Brown" >> >> Different opinions are fine. Bringing national or international >> politics into the discussion (presumably meant to be a

Re: GCC association with the FSF

On 09/04/2021 16:40, Christopher Dimech wrote: >> Sent: Friday, April 09, 2021 at 10:37 PM >> From: "David Brown" >> To: "John Darrington" , "David Malcolm" >> >> Cc: g...@gnu.org >> Subject: Re: GCC association with the FSF >

Re: GCC association with the FSF

destruction would be correct or appropriate - I am saying it will happen in the end if the free software community is not careful.) (I agree that there are few, if any, people who had the qualities of RMS to do the job he did. But IMHO that role is over - we don't need someone to fill his shoes.) David Brown

Re: GCC association with the FSF

On 08/04/2021 19:22, Giacomo Tesio wrote: > No, David, > > On April 8, 2021 3:00:57 PM UTC, David Brown wrote: > >> (And yes, I mean FOSS here, not just free software.) > > you are not talking about Free Software, but Open Source. > > FOSS, as a term, has

Re: GCC association with the FSF

On 08/04/2021 18:43, Christopher Dimech wrote: > >> Sent: Friday, April 09, 2021 at 3:00 AM >> From: "David Brown" >> To: "Jonathan Wakely" , "David Malcolm" >> >> Cc: "GCC Development" , "Mark Wielaard" &

Re: GCC association with the FSF

om major users (Linux kernel people, Debian folk, etc.), from target manufacturers (Intel, ARM, etc.), from ordinary users - in short, it should represent the people who have most interest in the future success of the project. It might also make sense to gang together with other important toolchain projects, such as the binutils folk. David Brown (A mostly happy embedded gcc user.)

Re: using undeclared function returning bool results in wrong return value

On 20/02/2021 16:46, David Malcolm wrote: > On Sat, 2021-02-20 at 15:25 +0100, David Brown wrote: > > I think we need to think about both of these use-cases e.g. as we > implement our diagnostics, and that we should mention this distinction > in our UX guidelines... > &g

Re: using undeclared function returning bool results in wrong return value

On 19/02/2021 12:18, Jonathan Wakely via Gcc wrote: > On Fri, 19 Feb 2021 at 09:42, David Brown wrote: >> Just to be clear - I am not in any way suggesting that this situation is >> the fault of any gcc developers. If configure scripts are failing >> because they r

Re: using undeclared function returning bool results in wrong return value

On 19/02/2021 09:45, Florian Weimer wrote: * David Brown: On 18/02/2021 13:31, Florian Weimer via Gcc wrote: * Jonathan Wakely via Gcc: Declare your functions. Don't ignore warnings. It's actually a GCC bug that this isn't an error. However, too many configure scri

Re: using undeclared function returning bool results in wrong return value

On 18/02/2021 13:31, Florian Weimer via Gcc wrote: > * Jonathan Wakely via Gcc: > >> Declare your functions. Don't ignore warnings. > > It's actually a GCC bug that this isn't an error. However, too many > configure scripts would still break if we changed the default. > People have had 22 year

Re: Comma Operator - Left to Right Associativity

On 04/02/2021 22:21, Andreas Schwab wrote: > On Feb 04 2021, David Brown wrote: > >> For the built-in comma operator, you get guaranteed order of evaluation >> (or more precisely, guaranteed order of visible side-effects). But for >> a user-defined comma operator,

Re: Comma Operator - Left to Right Associativity

On 04/02/2021 21:08, AJ D via Gcc wrote: > Isn't comma operator suppose to honor left-to-right associativity? > > When I try it on this test case, it exhibits right-to-left associativity. You are not talking about associativity - you are talking about evaluation order. (The two things are often

Re: Static analysis updates in GCC 11

On 29/01/2021 01:03, Martin Sebor wrote: On 1/28/21 2:27 PM, David Malcolm via Gcc wrote: On Thu, 2021-01-28 at 22:06 +0100, David Brown wrote: I wrote a feature request for gcc a while back, involving adding tag attributes to functions in order to ensure that certain classes of functions

  1   2   3   4   >