Re: size of exception handling (Was: performance of exception handling)

On 13/05/2020 00:48, Jonathan Wakely via Gcc wrote: On Tue, 12 May 2020 at 23:39, Jonathan Wakely wrote: On Tue, 12 May 2020, 21:57 Freddie Chopin, wrote: Anyway... If you have to recompile the toolchain, the problem is still there. Most of the people (like 99,666%) will not do that for variou

Re: Two new proposals to the upcoming C2X standard

On 28/05/2020 23:01, Xavier Del Campo Romero via Gcc wrote: Hello gcc team, I have sent the following proposals to the committee, but they require them to be implemented at least into two major compilers, so I am proposing them to be implemented into gcc. This is going to be a rather lengthy e

Re: Two new proposals to the upcoming C2X standard

Hi, On 31/05/2020 22:24, Xavier Del Campo Romero wrote: Hi David, -Wsizeof-pointer-div isn't required by the standard, so any compiler other than gcc or clang is not required to emit anything to the user. In such compilers, the security risk would still be there and would be up to the maint

Re: LTO Dead Field Elimination

On 24/07/2020 17:43, Erick Ochoa wrote: > This patchset brings back struct reorg to GCC. > > We’ve been working on improving cache utilization recently and would > like to share our current implementation to receive some feedback on it. > > Essentially, we’ve implemented the following components:

Re: No warning for module global variable which is set but never used

On 09/12/2020 10:25, webmaster wrote: > Hello,I'm wondering why GCC does not throw any warning when a module global > variable is set (write) but never used (read).Is this behavior wanted? Does > it makes sense to add such warning?Greets > How do you expect the compiler to know if the variable

Re: No warning for module global variable which is set but never used

On 09/12/2020 11:00, Jakub Jelinek wrote: > On Wed, Dec 09, 2020 at 10:50:22AM +0100, David Brown wrote: >> I'd say that it makes sense to have such a warning as a natural >> enhancement to the existing "-Wunused-but-set-variable" warning. But I > > That is

Re: No warning for module global variable which is set but never used

On 10/12/2020 16:10, webmaster wrote: (As a general rule, you'll get more useful responses if you use your name in your posts. It's common courtesy.) > Is it possible to request such feature? > Of course you can file a request for it. Go to the gcc bugzilla site:

Re: Static analysis updates in GCC 11

On 28/01/2021 21:23, David Malcolm via Gcc wrote: > I wrote a blog post covering what I've been working on in the analyzer > in this release: > > https://developers.redhat.com/blog/2021/01/28/static-analysis-updates-in-gcc-11/ > As a gcc user, I am always glad to hear of more static analysis an

Re: Static analysis updates in GCC 11

On 28/01/2021 22:27, David Malcolm wrote: On Thu, 2021-01-28 at 22:06 +0100, David Brown wrote: On 28/01/2021 21:23, David Malcolm via Gcc wrote: I wrote a blog post covering what I've been working on in the analyzer in this release:   https://developers.redhat.com/blog/2021/01/28/s

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

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: 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: 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: 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 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 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: 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: 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

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

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 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

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 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 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 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 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 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: 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: 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

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: C++ order of evaluation of operands, arguments

On 25/11/15 15:47, Michael Matz wrote: > Hi, > > On Tue, 24 Nov 2015, Richard Biener wrote: > >> On Tue, Nov 24, 2015 at 12:01 AM, Jason Merrill wrote: >>> There's a proposal working through the C++ committee to define the order of >>> evaluation of subexpressions that previously had unspecified

Re: AW: basic asm and memory clobbers - Proposed solution

On 02/12/15 08:51, Bernd Edlinger wrote: > On 1.12.2015, David Wohlferd wrote: > On 12/1/2015 10:10 AM, Bernd Edlinger wrote: >>> But IMHO asm("bla":) isn't any better than asm("bla"). >>> I think _any_ asm with non-empty assembler string, that >>> claims to clobber _nothing_ is highly suspicious,

Re: AW: basic asm and memory clobbers - Proposed solution

On 02/12/15 12:34, Bernd Edlinger wrote: > Hi, > >> Surely in code like that, you would make "x" volatile? Memory clobbers >> are not a substitute for correct use of volatile accesses. > > No, > > It is as I wrote, a memory clobber is the only way to guarantee that > the asm statement is not mo

Re: basic asm and memory clobbers - Proposed solution

On 17/12/15 11:39, Andrew Haley wrote: > On 17/12/15 01:41, David Wohlferd wrote: >> On the contrary, I would be surprised to learn that there are ANY >> compilers (other than clang) that support gcc's extended asm format. > > Prepare to be surprised: Sun Studio compilers seem to support it > j

Re: Some real-life feedback on -Wmisleading-indentation

On 11/01/16 08:20, Gerald Pfeifer wrote: Compiling Wine with GCC trunk (to become GCC 6) I noticed four dozen of warnings triggered by -Wmisleading-indentation. Some are simply weird formatting, some may be indicative of real issues -- and I have started to look into them one by one and submitti

Re: [WWWDocs] Deprecate support for non-thumb ARM devices

On 25/02/16 14:32, Stefan Ring wrote: > On Thu, Feb 25, 2016 at 10:20 AM, Richard Earnshaw (lists) > wrote: >> The point is to permit the compiler to use interworking compatible >> sequences of code when generating ARM code, not to force users to use >> Thumb code. The necessary instruction (BX)

SPR access

Hi, (You have something wrong with your emails - the subject for your post had a copy of most of the body of the email. I have changed it to something smaller.) You can't use a function argument for the number of the SPR, because the assembler requires the SPR at assembly time to generate the fu

Re: SPR access

development of the compiler itself. mvh., David On 13/07/16 16:39, tutruong0...@gmail.com wrote: > Hi, > > Thank you for your answer. > It is very useful for me. > > Best regards; > > Truong TT > >> On Jul 8, 2016, at 11:07 PM, David Brown wrote: >> >>

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

On 26/07/16 16:55, Warren D Smith wrote: > On 7/26/16, Joseph Myers wrote: >> On Tue, 26 Jul 2016, Warren D Smith wrote: >> >>> (And in the case of uint4_t, it actually would not even BE an >>> "extension" since as I said, >>> the standard already allows providing other sizes.) >> >> Only sizes wh

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

On 26/07/16 16:37, Warren D Smith wrote: You would get on far better here if you tried a little politeness and respect, rather than anger, accusations and confrontation. The C standards were written by a group of very smart and experienced people, refined over a long time based on real-world issu

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

I am assuming you intended to post this on the mailing list, so I have restored the addresses. On 26/07/16 19:55, Warren D Smith wrote: > To the guy who falsely claimed MIPS fails to provide an add with carry > instruction, > a google search in 1 minute finds this: > > stackoverflow.com/questions

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

On 26/07/16 21:06, Warren D Smith wrote: > OK, you just said you've used packed nybble arrays a couple of times. Yes, a couple of times in 20+ years. And I work with the kind of programming where something like nibble arrays could conceivably be useful. For most C programmers, "int" is the only

Re: Question about Cortex bit-banding feature

On 29/07/16 10:25, Fredrik Hederstierna wrote: > Some processor architectures do support bitwise access to memory, eg. ARM > Cortex-M and 8051 (by ARM called bit-banding). > In these architectures a single bit can somewhat be addressable, but only as > an 'aliased' memory region for another memo

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

On 29/07/16 18:26, Warren D Smith wrote: Booleans are very useful - they turn up all over the place in programming. Nibbles, on the other hand, are almost totally useless. There are very, very few situations where you need to store a number that is within the range 0 .. 15, and are so tightly c

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

On 29/07/16 20:54, Warren D Smith wrote: > On 7/29/16, Jonathan Wakely wrote: >> Let's imagine we have a 4-bit type, called nibble. >> >> sizeof(nibble) == 1, because you can't have an object with a smaller size. >> >> nibble a[2]; >> sizeof(a) == 1; >> >> Because otherwise there isn't much benefi

Re: Possible missed optimization opportunity with const?

On 17/08/16 02:21, Toshi Morita wrote: I was involved in a discussion over the semantics of "const" in C, and the following code was posted: #include int foo = 0; const int *pfoo = &foo; void bar (void) { foo +=3D; I assume that's a typo? } int main(void) { int a, b; a = *pfoo

Re: Possible missed optimization opportunity with const?

On 18/08/16 00:44, Toshi Morita wrote: > David Brown wrote: > >> No, it would not be valid. Declaring pfoo as a "const int*" tells the >> compiler "I will not change anything via this pointer - and you can >> optimise based on that promise". It doe

Re: const volatile behaviour change in GCC 7

On 22/09/16 09:23, Sebastian Huber wrote: > Hello, > > for RTEMS we use linker sets to initialize the system. The following > code worked up to GCC 6, but no longer in GCC 7: > > typedef void ( *rtems_sysinit_handler )( void ); > > typedef struct { > rtems_sysinit_handler handler; > } rtems_sy

Re: const volatile behaviour change in GCC 7

On 22/09/16 16:57, paul.kon...@dell.com wrote: > >> On Sep 22, 2016, at 6:17 AM, David Brown wrote: >> >> ... >> Your trouble is that your two pointers, cur and end, are pointing at >> different variables. Comparing two pointers that are independent (i.e., >

Re: const volatile behaviour change in GCC 7

On 22/09/16 17:30, Richard Biener wrote: On September 22, 2016 5:20:56 PM GMT+02:00, paul.kon...@dell.com wrote: On Sep 22, 2016, at 11:16 AM, David Brown wrote: On 22/09/16 16:57, paul.kon...@dell.com wrote: On Sep 22, 2016, at 6:17 AM, David Brown wrote: ... Your trouble is that

Re: style convention: /*foo_p=*/ to annotate bool arguments

On 04/10/16 01:48, Martin Sebor wrote: > In a recent review Jason and I discussed the style convention > commonly followed in the C++ front end to annotate arguments > in calls to functions taking bool parameters with a comment > along the lines of > > foo (1, 2, /*bar_p=*/true); > > I pointed

Re: style convention: /*foo_p=*/ to annotate bool arguments

On 04/10/16 12:41, Jonathan Wakely wrote: > On 4 October 2016 at 10:21, David Brown wrote: >> On 04/10/16 01:48, Martin Sebor wrote: >>> In a recent review Jason and I discussed the style convention >>> commonly followed in the C++ front end to annotate arguments >&

Re: style convention: /*foo_p=*/ to annotate bool arguments

On 04/10/16 13:40, Nathan Sidwell wrote: > On 10/03/16 19:48, Martin Sebor wrote: >> In a recent review Jason and I discussed the style convention >> commonly followed in the C++ front end to annotate arguments >> in calls to functions taking bool parameters with a comment >> along the lines of >>

Re: style convention: /*foo_p=*/ to annotate bool arguments

On 04/10/16 22:00, Martin Sebor wrote: >> This would have been easier if C++ had allowed the same default value to >> be given in both the declaration and the definition: >> >> void foo(int x, int y, bool bar_p = false); >> >> void foo(int x, int y, bool bar_p = false) >> { >> } >> >> It seems stra

Re: style convention: /*foo_p=*/ to annotate bool arguments

On 05/10/16 22:24, Florian Weimer wrote: > * David Brown: > >> Far and away the best solution would be for C++ to support named >> parameters or named arguments: >> >> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4172.htm> >> >> Then y

Re: Do we really need a CPP manual?

On 16/12/16 11:55, Jonathan Wakely wrote: > On 16 December 2016 at 06:46, Sandra Loosemore wrote: >> Looking at the structure of the whole manual, though, I see that most of it >> is in fact a tutorial on how to use the preprocessor language, like you >> would find in a C programming book. Is this

Re: Performance gain through dereferencing?

On 16/04/14 17:57, Peter Schneider wrote: Hi David, Sorry, I had included more information in an earlier draft which I edited out for brevity. (Sorry for the late reply - Easter is a /serious/ holiday in Norway.) > You cannot learn useful timing > information from a single run of a short

Re: GCC 4.9.0 Released

On 22/04/14 15:10, Jakub Jelinek wrote: > One year and one month passed from the time when the last major version > of the GNU Compiler Collection has been announced, so it is the time again > to announce a new major GCC release, 4.9.0. > > GCC 4.9.0 is a major release containing substantial new >

Re: C PreProcessor GCC-specific features ideas.

On 22/04/14 18:38, Solal wrote: > I've got ideas for improve the preprocessor with specific features. > > The basic idea is to make the preprocessing language a complete > programming language. > That can be useful for includes things like Autotools and advanced > Makefiles directly in the source

Re: Is there any reason to use vfork() ?

On 13/05/14 17:47, Michael N. Moran wrote: On 05/13/2014 10:59 AM, niXman wrote: pinskia 2014-05-13 18:47: Can you share more information about this env. This is specially built distributive used for micro-pc. It might be a bug not in gcc. I'm sure that the bug not in the GCC. After I wrote

Re: Is there any reason to use vfork() ?

On 13/05/14 17:47, Michael N. Moran wrote: On 05/13/2014 10:59 AM, niXman wrote: pinskia 2014-05-13 18:47: Can you share more information about this env. This is specially built distributive used for micro-pc. It might be a bug not in gcc. I'm sure that the bug not in the GCC. After I wrote

Designated Initializers in C++

After a recent discussion about designated initializers in C++, I noticed that they are accepted by modern gcc (when gcc extensions are enabled). On , the documentation specifically says "This extension is not implemented in GNU C++". That

Re: Designated Initializers in C++

On 16/09/14 13:20, Jakub Jelinek wrote: > On Tue, Sep 16, 2014 at 01:14:35PM +0200, David Brown wrote: >> After a recent discussion about designated initializers in C++, I >> noticed that they are accepted by modern gcc (when gcc extensions are >> enabled). >> >> O

Named parameters

Hi, In a discussion on comp.lang.c, the subject of "named parameters" (or "designated parameters") has come up again. This is a feature that some of us feel would be very useful in C (and in C++). I think it would be possible to include it in the language without leading to any conflicts with ex

Re: Named parameters

On 16/03/15 17:34, Marc Glisse wrote: > On Mon, 16 Mar 2015, David Brown wrote: > >> In a discussion on comp.lang.c, the subject of "named parameters" (or >> "designated parameters") has come up again. This is a feature that some >> of us feel would b

Re: [RFC] Kernel livepatching support in GCC

On 28/05/15 10:39, Maxim Kuvyrkov wrote: > Hi, > > Akashi-san and I have been discussing required GCC changes to make > kernel's livepatching work for AArch64 and other architectures. At > the moment livepatching is supported for x86[_64] using the following > options: "-pg -mfentry -mrecord-mcou

A possible gcc bug?

I am always wary of saying there might be a compiler bug - usually it is a bug in the user code. But this time I am very suspicious. The example here comes from a discussion in the comp.lang.c Usenet group. Here is the code I have been testing: unsigned char foo_u(unsigned int v) { retu

Passing empty "tag" structs

In C++ programming, it is sometimes helpful to have empty structs acting as tags. An example is "struct nothrow_t {}". When parameters of these types - such as "nothrow", are passed to functions the compiler passes them as a value 0. Since the type cannot hold any kind of value, surely it co

Re: A possible gcc bug?

On 07/09/2018 09:47, Jakub Jelinek wrote: On Fri, Sep 07, 2018 at 08:57:25AM +0200, David Brown wrote: I am always wary of saying there might be a compiler bug - usually it is a bug in the user code. But this time I am very suspicious. The example here comes from a discussion in the

Re: Passing empty "tag" structs

On 07/09/2018 10:10, Jonathan Wakely wrote: On Fri, 7 Sep 2018 at 08:06, David Brown wrote: In C++ programming, it is sometimes helpful to have empty structs acting as tags. An example is "struct nothrow_t {}". When parameters of these types - such as "nothrow", are

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

On 17/09/18 14:00, Umesh Kalappa wrote: > Hi All, > > When we try to compile the below case from trunk gcc we get the below > warning (-Wconversion) i.e > > void start(void) { > char n = 1; > char n1 = 0x01; > n &= ~n1; > } > > $xgcc -S warn.c -nostdinc -Wconversion > warning: conversion f

Re: Optimization Option Question

On 19/12/18 09:10, Tangnianyao (ICT) wrote: > Greetings All, > I am dealing with compile optimization comparison between arm64 and intel > platform, with g++ (version 4.9.4). > > Compile the following c++ code, > > uint32 Witness::getEntityVolatileDataUpdateFlags(Entity* otherEntity) > { >

Re: -fno-common

On 28/01/2019 16:58, Bernhard Schommer wrote: > Hi, > > I would like to know if the handling of the option -fno-common has > changed between version 7.3 and 8.2 for x86. I tried it with the > default system version of OpenSUSE and for example: > > const int i; > > is placed in the .bss section.

Re: -fno-common

ry if I posted this on the wrong list. Actually I was looking at this not due to changes in my code but rather to implement the option for another compiler and I wanted to mimic the behavior of gcc and was kind of confused in the change of behavior. Bernhard. Am Di., 29. Jan. 2019 um 10:54 Uhr sch

Contributing p0355 to libstdc++-v3

Hello GCC, My name is David Brown and I am interested in contributing to libstdc++-v3. Specifically, I would like to begin implementing https://wg21.link/p0355r7 having used its reference implementation in several projects already. I am aware that I will need to fill out some FSF forms for legal

Re: AVR __progmem__ variable reading

On 22/02/2019 23:34, Łukasz Kostka wrote: Hi I am using for a while now gcc and especially __progmem__ attribute. I’d like to report a feature request for gcc to handle reading from flash memory variables. Compiler has all the knowledge (target device, availability of LPM, ELPM instructions e

Re: AVR __progmem__ variable reading

On 23/02/2019 19:38, Łukasz Kostka wrote: Wiadomość napisana przez David Brown w dniu 23.02.2019, o godz. 16:34: On 22/02/2019 23:34, Łukasz Kostka wrote: Hi I am using for a while now gcc and especially __progmem__ attribute. I’d like to report a feature request for gcc to handle

Re: AVR __progmem__ variable reading

On 24/02/2019 14:47, Łukasz Kostka wrote: Wiadomość napisana przez David Brown <mailto:david.br...@hesbynett.no>> w dniu 24.02.2019, o godz. 12:13: This sort of thing has been an issue for all sorts of small microcontrollers, and all their compilers, since their inception.  I

Re: AVR __progmem__ variable reading

On 24/02/2019 18:29, Łukasz Kostka wrote: Wiadomość napisana przez David Brown w dniu 24.02.2019, o godz. 14:58: On 24/02/2019 14:47, Łukasz Kostka wrote: Wiadomość napisana przez David Brown mailto:david.br...@hesbynett.no>> w dniu 24.02.2019, o godz. 12:13: This sort of thi

Re: AVR __progmem__ variable reading

On 25/02/2019 18:09, Łukasz Kostka wrote: > > >> Wiadomość napisana przez David Brown w dniu >> 25.02.2019, o godz. 08:43: >> >> >> On 24/02/2019 18:29, Łukasz Kostka wrote: >>>> Wiadomość napisana przez David Brown w dniu >>>> 24.

Re: About BZ#87210 [RFE] To initialize automatic stack variables

On 19/02/2019 11:23, P J P wrote: Hello,   -> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87210 This RFE is about providing gcc option(s) to eliminate information leakage issues from programs. Information leakage via uninitialised memory has beena chronic/recurring issue across all software.

Re: About BZ#87210 [RFE] To initialize automatic stack variables

On 05/03/2019 19:37, Segher Boessenkool wrote: Hi! On Mon, Mar 04, 2019 at 09:45:37PM +0100, David Brown wrote: Forcing "stolen_key" to be zero initialised does not help anyone - options for that just make code slower and hide errors that would occur with other compiler opt

Re: About BZ#87210 [RFE] To initialize automatic stack variables

On 06/03/2019 02:50, Segher Boessenkool wrote: > On Tue, Mar 05, 2019 at 09:36:56PM +0100, David Brown wrote: >> On 05/03/2019 19:37, Segher Boessenkool wrote: >>> On Mon, Mar 04, 2019 at 09:45:37PM +0100, David Brown wrote: >>>> void foo(void) { >>>>

Re: Warning for C Parameter Name Mismatch

On 09/03/2019 00:06, Joseph Myers wrote: On Fri, 8 Mar 2019, Joel Sherrill wrote: Can gcc report when the parameter name in a C prototype does not match that used in the implementation? int f(int x); int f(int y) {...} I think this would be normal and expected - an installed header would us

Re: Warning for C Parameter Name Mismatch

On 09/03/2019 03:23, Eric Gallager wrote: On 3/8/19, David Brown wrote: On 09/03/2019 00:06, Joseph Myers wrote: On Fri, 8 Mar 2019, Joel Sherrill wrote: Can gcc report when the parameter name in a C prototype does not match that used in the implementation? int f(int x); int f(int y

Re: Warning for C Parameter Name Mismatch

On 10/03/2019 07:11, Basile Starynkevitch wrote: (I am reading the GCC mailing list in digest mode) On 3/9/19 10:58 PM, gcc-digest-h...@gcc.gnu.org wrote: On Fri, 8 Mar 2019, Joel Sherrill wrote: Can gcc report when the parameter name in a C prototype does not match that used in the implem

Re: GCC turns &~ into | due to undefined bit-shift without warning

On 11/03/2019 12:24, Vincent Lefevre wrote: > On 2019-03-11 11:06:37 +, Moritz Strübe wrote: >> On 11.03.2019 at 10:14 Jakub Jelinek wrote: >>> The fact that negative or >= bit precision shifts are UB is widely known, > [...] > > And even in the case where the compiler maps the shift directly

Re: GCC turns &~ into | due to undefined bit-shift without warning

On 12/03/2019 16:40, Vincent Lefevre wrote: On 2019-03-11 13:51:21 +0100, David Brown wrote: On 11/03/2019 12:24, Vincent Lefevre wrote: It already does by default: -Wshift-count-negative Warn if shift count is negative. This warning is enabled by default

Re: GCC turns &~ into | due to undefined bit-shift without warning

On 13/03/2019 03:25, Vincent Lefevre wrote: > On 2019-03-12 21:56:59 +0100, David Brown wrote: >> I disagree. To generate an unconditional error (rejecting the program), the >> compiler would need such proof - such as by tracing execution from main(). >> But to generat

Re: GCC turns &~ into | due to undefined bit-shift without warning

On 22/03/2019 11:20, Allan Sandfeld Jensen wrote: > On Freitag, 22. März 2019 11:02:39 CET Andrew Haley wrote: >> On 3/21/19 10:19 PM, Allan Sandfeld Jensen wrote: >>> From having fixed UBSAN warnings, I have seen many cases where undefined >>> behavior was performed, but where the code was aware o

Re: programming language that does not inhibit further optimization by gcc

On 30/03/2019 08:13, Albert Abramson wrote: Now I'm on a totally unrelated project, writing code in C, but still using the GCC compiler under the hood. The previous developers used raw pointers quite a bit. However, as I expand the code, I'd like to use some of the features in C++, but Atmel St

Re: Usage of C11 Annex K Bounds-checking interfaces on GCC

On 15/12/2019 02:57, Jeffrey Walton wrote: On Sat, Dec 14, 2019 at 12:36 PM Martin Sebor wrote: On 12/9/19 8:15 PM, li zi wrote: Hi All, We are using gcc in our projects and we found some of the C standard functions (like memcpy, strcpy) used in gcc may induce security vulnerablities like b

Re: Adoption of C subset standards

On 09/01/17 12:34, Jim MacArthur wrote: > Hi all, I've become involved in a group which seeks to refine previous > efforts in both safety-critical and secure coding standards (for example > MISRA and CERT-C). We note that in the past MISRA has been declined for > explicit inclusion in GCC but that

Re: Adoption of C subset standards

On 09/01/17 15:15, Nathan Sidwell wrote: > On 01/09/2017 08:58 AM, David Brown wrote: > >> I don't know about CERT-C, but one of the challenges of implementing >> MISRA coding standards checking in gcc is that the MISRA documents are >> not free. They are cheap (a

Re: Adoption of C subset standards

On 09/01/17 19:43, paul.kon...@dell.com wrote: On Jan 9, 2017, at 1:28 PM, Richard Kenner wrote: Regardless of that sort of issue, I think on previous occasions when the topic of MISRA (or other coding standard) checking came up, there has been a general opinion from the gcc developers tha

Re: Adoption of C subset standards

On 09/01/17 20:11, Richard Kenner wrote: I suppose that would be true if you refer to MISRA in the messages. If you don't then you're not using the trademark. The issue isn't the messages. but how you describe what you've done in, say, documentation or ChangeLog entries. If you claim, in any

Re: Adoption of C subset standards

On 09/01/17 22:17, paul.kon...@dell.com wrote: > >> On Jan 9, 2017, at 4:08 PM, David Brown >> wrote: ... I found a reference to this in MISRA's forums: >> >> <https://www.misra.org.uk/forum/viewtopic.php?f=56&t=1189> >> >> The post and

Re: Obsolete powerpc*-*-*spe*

On 14/02/17 12:55, Sebastian Huber wrote: > Hello Segher, > > On 14/02/17 04:07, Segher Boessenkool wrote: >> Hi all, >> >> I propose to mark powerpc*-*-*spe* as obsolete in GCC 7. This includes >> the spe.h installed header file, all the __builtin_spe* intrinsics, the >> -mfloat-gprs= command-li

Re: "Uninitialized array" warnings by c++ with -O2

On 07/06/17 11:33, Andrew Haley wrote: > On 07/06/17 10:15, Kirill Yu Berezin wrote: >> My question is. Is this an expected behaviour or I must report a bug ? > > It's not a bug: your code displays undefined behaviour: you're casting > a pointer to struct udp_pseudo fields to an array of uint16_t.

Re: Overwhelmed by GCC frustration

On 01/08/17 13:08, Eric Gallager wrote: > On 8/1/17, Richard Biener wrote: >> >> Heh. I suspect -Os would benefit from a separate compilation pipeline >> such as -Og. Nowadays the early optimization pipeline is what you >> want (mostly simple CSE & jump optimizations, focused on code >> size im

  1   2   3   4   >