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

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

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

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

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

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

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

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

answer, sorry 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

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

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

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

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

Re: Question about GCC benchmarks and uninitialized variables

On 24/07/18 09:40, Fredrik Hederstierna wrote: > Hi > > This is a general question to all you working with GCC benchmarking. > > I have been working with code benchmarks like CSiBE for ARM. From > time to time unpredicted results appears where numbers gets worse by > no reason. > > When looking

Re: O2 Agressive Optimisation by GCC

Hi, This is nothing to do with undefined behaviour, but a matter of scheduling of effects that are visible in different circumstances. In particular, i and j are declared in a way that tells the compiler that the compiler, in its current thread of execution has full control of them. The

Re: LTO vs GCC 8

On 15/05/18 22:03, Freddie Chopin wrote: > > I cannot reproduce this here ); Don't get me wrong - if there's a > "free" way to improve code size/speed with some compiler flags which I > did not use previously, then I'm very much interested, however in my > particular case the best result

Re: LTO vs GCC 8

On 11/05/18 17:49, Freddie Chopin wrote: > On Fri, 2018-05-11 at 13:06 +0200, David Brown wrote: >> For the Cortex-M devices (and probably many other RISC targets), >> -fdata-sections comes at a big cost - it effectively blocks >> -fsection-anchors and makes access to file-sta

Re: LTO vs GCC 8

On 11/05/18 11:19, Richard Biener wrote: > On Thu, May 10, 2018 at 11:32 PM, Freddie Chopin wrote: >> Hi! >> >> In one of my embedded projects I have an option to enable LTO. This was >> working more or less fine for GCC 6 and GCC 7, however for GCC 8.1.0 >> (and binutils

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

On 19/04/18 11:27, Manish Jain wrote: > > On 04/19/18 14:46, David Brown wrote: >> Certainly it is heavily used in existing code - making an option >> to disable it would be impractical. > > Thanks for replying, Mr. Brown. > > What I meant was if an option could be

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

On 19/04/18 10:09, Manish Jain wrote: > Hi all, > > One of the historical artefacts of the C language has been the burden of > lugging around multiple declarations in a single statement, with some > well-known pitfalls: > > int* ptr1, ptr2; > > Since ptr2 looks like a pointer but actually is

Re: where should C++ options be documented?

On 03/04/18 03:33, Martin Sebor wrote: > Jason, > > The manual mentions some C++-only options in the language > independent section 3.8 Options to Request or Suppress > Warnings and others in 3.5 Options Controlling C++ Dialect. > > For example, -Wcatch-value, -Wconditionally-supported, > and

Re: Debugging optimizer problems

On 02/02/18 23:03, jacob navia wrote: > Le 02/02/2018 à 22:11, Florian Weimer a écrit : >> * jacob navia: >> >>> I have in my small C compiler introduced the following construct: >>> >>> #pragma optimize(on/off,push/pop) >> Not sure what you are after. GCC has something quite similar: >> >>

Re: Unused GCC builtins

On 22/01/18 16:46, Manuel Rigger wrote: > Hi everyone, > > As part of my research, we have been analyzing the usage of GCC builtins > in 5,000 C GitHub projects. One of our findings is that many of these > builtins are unused, even though they are described in the documentation > (see

Re: extern const initialized warns in C

t is so rare, that it is probably sufficient.  There is no going out of the way to accurately simulate the static linker  at dynamic link time. Functions are only exported if they are annotated  in source or listed in a separate file. Not just by being non-static.   - Jay -----

Re: extern const initialized warns in C

m being an ancient programmer who /has/ noticed how things have changed over the last 20+ years. But I work in a relatively narrow field - small systems embedded programming - and your experience may differ in other fields.) mvh., David  - Jay ---

Re: extern const initialized warns in C

to do it. I am not sure what you mean by that. mvh., David     - Jay From: Jay K Sent: Monday, January 22, 2018 9:31 AM To: David Brown; gcc Subject: Re: extern const initialized warns in C By this argument there is a missing warning for the equivalent:   const int foo = 1

Re: extern const initialized warns in C

the declaration right before the definition, in the same source file. I realize there are many arguments for and against file level static. There are no /good/ arguments against file-level static in C, except perhaps temporarily while debugging (it can be easier to view non-static data in a d

Re: extern const initialized warns in C

On 21/01/18 08:12, Jay K wrote: > extern const int foo = 123; > > > > Why does this warn? > This is a valid portable form, with the same meaning > across all compilers, and, importantly, portably > to C and C++. > > I explicitly do not want to say: > > const int foo = 123 > > because I

Re: Implementing p0515 - spaceship operator

On 11/01/18 12:32, Jonathan Wakely wrote: > On 11 January 2018 at 11:28, David Brown wrote: >> On 11/01/18 11:13, Jonathan Wakely wrote: >>> t all cleaOn 11 January 2018 at 10:05, David Brown wrote: >>>> Maybe it is easier to say "gcc supports <=> in C++2

Re: Implementing p0515 - spaceship operator

On 11/01/18 11:13, Jonathan Wakely wrote: > t all cleaOn 11 January 2018 at 10:05, David Brown wrote: >> Maybe it is easier to say "gcc supports <=> in C++2a, and as an >> extension also supports it in C and C++ of any standard" ? I don't >> believ

Re: Implementing p0515 - spaceship operator

On 10/01/18 14:00, Jonathan Wakely wrote: > On 9 Jan 2018 10:56 p.m., "Tim van Deurzen" wrote: > > > Just to confirm with you, it does make sense to conditionally parse the > token for operator<=> in libcpp (i.e. only when the cxx standard being used > is >=2a)? I'm just

Re: Potential bug on Cortex-M due to used registers/interrupts.

On 16/11/17 17:54, Vitalijus Jefišovas wrote: > On Cortex-M mcu’s, when interrupt happens, NVIC copies r0-r3 and couple > other registers onto the psp stack, and then jumps to interrupt routine, > when it finishes, NVIC restores these registers, and jumps back to user’s > function. > What is

Re: Please support Coroutines TS in C++

On 17/10/17 00:19, Nathan Sidwell wrote: > On 10/16/2017 07:06 AM, Jonathan Wakely wrote: >> On 16 October 2017 at 08:25, Ramón García wrote: >>> ping >> >> As previously stated, nobody is working on it. > > Not because nobody cares, but because of lack of time against higher > priority things. >

Re: -ffunction-sections and -fdata-sections documentation

On 13/10/17 09:06, Sebastian Huber wrote: > Hello, > > I would like to update the documentation of these compiler flags and > have some questions. The -ffunction-sections and -fdata-sections > documentation is currently: > > Do these options affect the code generation? > -fdata-sections

Re: Exhaustive Instructions for Toolchain Generation

On 05/10/17 22:16, R0b0t1 wrote: On Wed, Oct 4, 2017 at 3:33 AM, David Brown <da...@westcontrol.com> wrote: R0b0t1, you might not realise this but CodeSoucery is a major contributor to gcc and other gnu tools. Individuals and companies pay them for their services - to put together

Re: Exhaustive Instructions for Toolchain Generation

On 03/10/17 23:27, R0b0t1 wrote: > On Sun, Oct 1, 2017 at 4:35 PM, Sandra Loosemore > wrote: >> On 09/26/2017 03:05 PM, R0b0t1 wrote: >>> Is there anything else I should be aware of? >> >> >> Yes, there are companies (like, ahem, the one I work for -- >>

Re: Byte swapping support

On 14/09/17 11:30, Eric Botcazou wrote: >> I seem to remember it being able to attach a big-endian or little-endian >> label to any individual variable (rather than a type), which could be a >> scaler rather than a struct. So it was a bit more flexible than gcc. > > Well, the only thing I see in

Re: Byte swapping support

On 14/09/17 08:22, Eric Botcazou wrote: >> And there are lots of other problems, I don't have time to document them >> all, or even remember them all. Personally, I think you are better off >> trying to fix the application to make it more portable. Fixing the >> compiler is not a magic solution

Re: Byte swapping support

On 12/09/17 20:56, Michael Meissner wrote: > On Tue, Sep 12, 2017 at 05:26:29PM +0200, David Brown wrote: >> On 12/09/17 16:15, paul.kon...@dell.com wrote: >>> >>>> On Sep 12, 2017, at 5:32 AM, Jürg Billeter >>>> <juerg.bille...@codethink.co.

Re: Byte swapping support

On 12/09/17 16:15, paul.kon...@dell.com wrote: > >> On Sep 12, 2017, at 5:32 AM, Jürg Billeter >> wrote: >> >> Hi, >> >> To support applications that assume big-endian memory layout on little- >> endian systems, I'm considering adding support for reversing the >>

Re: Overwhelmed by GCC frustration

On 31/07/17 15:25, Georg-Johann Lay wrote: > This weekend I un-mothed an old project, just an innocent game on a > cathode-ray-tube, driven by some AVR µC. After preparing the software > so that it compiled with good old v3.4, the results overwhelmed me > with complete frustration: Any version

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

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

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=

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 <da...@westcontrol.com> >> wrote: ... I found a reference to this in MISRA's forums: >> >> <https://www.misra.org.uk/forum/viewtopic.php?f=56=1189> >> >

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

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

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

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

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

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 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 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: 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 <da...@westcontrol.com> wrote: On 22/09/16 16:57, paul.kon...@dell.com wrote: On Sep 22, 2016, at 6:17 AM, David Bro

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

Re: Possible missed optimization opportunity with const?

On 18/08/16 00:44, Toshi Morita wrote: > David Brown <david.br...@hesbynett.no> 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 >> optimis

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 = void bar (void) { foo +=3D; I assume that's a typo? } int main(void) { int a, b; a = *pfoo;

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

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

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

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

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

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

Re: SPR access

is for 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 <da...@westcontrol.c

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

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

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

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

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 >

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

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

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

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 be very useful in C (and in C++). I think it would

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

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 https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html, 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). On https://gcc.gnu.org/onlinedocs/gcc

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

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

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

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: Performance gain through dereferencing?

Hi, You cannot learn useful timing information from a single run of a short test like this - there are far too many other factors that come into play. You cannot learn useful timing information from unoptimised code. There is too much luck involved in a test like this to be useful. You need

Re: returning short-enum and truncate doesn't trigger conversion warning

On 19/03/14 15:33, Paulo Matos wrote: Hi all, This is either a C standard subtlety or a bug in GCC. This is perfectly normal behaviour for C, and not a bug. It is also a topic for the gcc help list, rather than the development list. For example: unsigned short foo (unsigned int a) {

Re: GNU C extension: Function Error vs. Success

On 10/03/14 18:26, Shahbaz Youssefi wrote: I'm mostly interested in C. Nevertheless, you can of course also do the same in C: struct option_float { float value; int error_code; bool succeeded; }; struct option_float inverse(int x) { if (x == 0) return (struct

Re: [AVR] remove two maintainers

On 10/03/14 11:29, Jeremy Bennett wrote: On 03/03/14 11:35, David Brown wrote: On 02/03/14 19:24, Denis Chertykov wrote: I would remove two maintainers for AVR port: 1. Anatoly Sokolov ae...@post.ru 2. Eric Weddington eric.wedding...@atmel.com I have discussed the removal with Anatoly

<    1   2   3   4   >