Re: Call for compiler help/advice: atomic builtins for v3

* Paolo Carlini: > Actually, the situation is not as bad, as far as I can see: the worst > case is i386 vs i486+, and Old-Sparc vs New-Sparc. More generally, a > targer either cannot implement the builtin at all (a trivial fall back > using locks or no MT support at all) or can in no more than 1 >

Re: Call for compiler help/advice: atomic builtins for v3

* Richard Henderson: > To keep all this in perspective, folks should remember that atomic > operations are *slow*. Very very slow. Orders of magnitude slower > than function calls. Seriously. Taking p4 as the extreme example, > one can expect a null function call in around 10 cycles, but a loc

Re: Call for compiler help/advice: atomic builtins for v3

* Peter Dimov: > Even on a P4, inlining may enable compiler optimizations. One case is when > the compiler can see that the return value of __sync_fetch_and_or (for > instance) isn't used. It's possible to use a wait-free "lock or" instead of > a "lock cmpxchg" loop (MSVC 8 does this for _Inter

Re: Is "-fdump-tree-original-raw" a stable feature?

* Hendrik Post: > I want to start a code analysis project using the "-fdump" debugging > outputs. Therefore I would like to ask if these features / switches are > considered stable in future versions of gcc ( I could not find any > information in the provided docs). Alternatively I have to writ

Re: Adding the D programming language

* Romain Failliot: > Is it plan to add the D language in the ones that are supported by GCC > by default? There is a GCC front end, but it has zero chance of being integrated into FSF GCC at this stage. The run-time library license contains this little gem: * (ii) Any derived vers

Re: How Can I Get See A Memory Map For An Executable

* Steven Woody: > i want to check in my C++ program, what variable is allocated in where. is > there such a tool? > how can i get see the runtime memory useage graph for my c++ > program? this will include stack memory and dynamic memory > (heap). thanks. To some extent, valgrind can generate su

should_duplicate_loop_header_p and volatile asm statements

In the following test case (based on gcc.dg/tree-ssa/copy-headers.c), the volatile asm statement is duplicated: extern int foo (int); void bla (void) { int i, n = foo (0); for (i = 0; (({{ __asm__ volatile ("foo_label:"); }}), i < n); i++) foo (i); } In this case, this is problematic b

Re: should_duplicate_loop_header_p and volatile asm statements

* Steven Bosscher: > On Nov 14, 2005 10:31 AM, Florian Weimer <[EMAIL PROTECTED]> wrote: >> >> What do you think? > > I thought labels can't appear in an asm statement...? Of course, you can put pretty much what you want into asm statements, the compiler does not

Re: Mention gcc 4.1 in News/Announcements

* Richard Guenther: > What makes you think it is? I think there was some release announcement on Slashdot when the branch was created. 8-)

Re: GNAT package GNAT.Traceback.Symbolic

* David Gressett: > It does work with the GNAT GPL 2005 that I have on my XP box at home. A > search of the gcc mailing list archive didn't turn up much, but there > was one message which indicated that there was a license problem with > the addr2line source code that the Ada Core people were

Re: GNAT package GNAT.Traceback.Symbolic

* Andrew Haley: > > Java implementations needs to solve pretty much the same problem. How > > is it done in GCJ? > > Every Java class has full reflection data for all of its methods. > Given the address of a method, therefore, it's a straightforward > reverse lookup to get the name. It seems t

Re: GNU Tools Cauldron 2020

* Alfred M. Szmidt: >Please feel free to share with other groups as appropriate. > > The form requires non-free software and Google malware. Please do not > recommend that people share such things on GNU project lists. The message you quoted also said: | If unable to use this form, please v

Re: Git ChangeLog policy for GCC Testsuite inquiry

* Eric Botcazou: >> I strongly prefer to move towards relying on the git log. > > In my experience the output of git log is a total mess so cannot replace > ChangeLogs. That's fixable if the commit message is part of the patch review (just like the source code comments).

libc coordination list

You can also manage your subscription at <https://www.openwall.com/lists/>. This list is lightly moderated (to deal with automated email submissions), with Rich Felker and Florian Weimer as the initial moderators, and the expectation that regular posters will be white-listed.

Re: List-Id header being stripped

* Richard Bradfield: > It appears that since the migration (or whatever happened on the list > over the weekend), the List-Id header is also being stripped from > outbound mail. The last GCC mail I have where the header is intact was > from Friday 6th. There weren't any List-Id headers before the

Re: List-Id header being stripped

* Richard Earnshaw: > On 09/03/2020 10:30, Florian Weimer wrote: >> * Richard Bradfield: >> >>> It appears that since the migration (or whatever happened on the list >>> over the weekend), the List-Id header is also being stripped from >>> outbound mail.

Mailman defaults to duplicate suppression

It seems that the Mailman migration has turned on duplicate suppression: if a recipient address is mentioned in the message headers, Mailman will not distribute the message to that recipient address, under the assumption that the message will make it to the recipient directly from the original post

Re: Not usable email content encoding

* Martin Liška: > It's probably related to the following email tag: > Content-Transfer-Encoding: quoted-printable > > The format is problematic when copying a patch. > Email example: > https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542053.html This is a known issue in the redhat.com email i

Re: Feature request for "friendship" of pointers in "C"

* aotto: > Hi, the following scenario has a "definition hole" in the "C" language > > code example: > > - > struct base { >   ... > }; > > struct A { >   struct base obj; >   ... > } aObj; > > struct B { >   struct base obj; >   ... > } bObj; > > void method_base (stru

Re: Not usable email content encoding

* Frank Ch. Eigler via Gcc: >> > Are you trying to copy from the raw message representation? >> >> Everyone trying to work with a patch (instead of just the email) always >> is working with the raw message. Just patch < mbox or git-am mbox >> for example. >> >> https://gcc.gnu.org/contribute

Re: Not usable email content encoding

* Frank Ch. Eigler: > Hi - > >> > The key here is to realize that the raw message is not what you get >> > back from the mailing list reflector, and also not the raw message >> > that was sent by the sender. In this day of mta intermediaries, >> > proxies, reflectors, it may be time to revisit th

Re: Not usable email content encoding

* Tom Tromey: > Also, gerrit was pretty bad about threading messages, so it became quite > hard to follow progress in email (but following all patches in the web > interface is very difficult, a problem shared by all these web UIs). What I found most disappointing was that the web interface doesn

Re: Not usable email content encoding

* Richard Biener: > On Thu, Mar 19, 2020 at 2:28 PM Florian Weimer wrote: >> >> * Tom Tromey: >> >> > Also, gerrit was pretty bad about threading messages, so it became quite >> > hard to follow progress in email (but following all patches in the web >

Re: Spam, bounces and gcc list removal

* Maciej W. Rozycki: > On Sat, 21 Mar 2020, Frank Ch. Eigler via Gcc wrote: > >> > > So, a request: Could the overseers either install more effective >> > > spam protection for the list as a whole (preferred) >> >> Heh, if only it were that easy! Spam filtering was and is distinct >> from mailin

Re: Spam, bounces and gcc list removal

* Maciej W. Rozycki: > On Sun, 22 Mar 2020, Florian Weimer wrote: > >> > Spam bouncing is evil and often hits an innocent person whose address has >> > been faked by the sender of spam, making the source of bounces not better >> > than the originator. >>

Re: Not usable email content encoding

* Jonathan Wakely: > On Mon, 6 Apr 2020 at 23:00, Maciej W. Rozycki via Gcc > wrote: >> And can certainly score a positive though not a definite rating in spam >> qualification. I don't think we ought to encourage bad IT management >> practices by trying to adapt to them too hard and hurting o

Re: Not usable email content encoding

* Maciej W. Rozycki: > On Tue, 7 Apr 2020, Christopher Faylor wrote: > >> >In a way that's amusing and just reinforces my p.o.v. that DMARC is >> >bollocks. >> >> Not that it means anything but I agree 100%. >> >> It's like whoever made the "standard" just said "to hell with mailing >> lists".

Re: Not usable email content encoding

* Tamar Christina: > A bit late to the party, but this really doesn't work that well > because until recent version of gitlab there was no fairness > guarantee. another patch could be approved after mine (with hours > in between because of CI) and yet still get merged first causing my > own patch

Re: Broken check rejecting -fcf-protection and -mindirect-branch=thunk-extern

* H. J. Lu via Gcc: > On Tue, Apr 28, 2020 at 10:24 AM David Woodhouse wrote: >> Sure, there is work to do to enable CET. But Andy's point is that >> we deliberately fixed up retpoline to be register-based >> *specifically* for the purpose of being CET-compatible, so it's >> somewhat daft for GCC

Re: gcc math functions for OpenMP vectoization

* Toon Moene: > On 6/5/20 6:10 PM, Tobias Burnus wrote: > >> On 6/5/20 4:11 PM, Jakub Jelinek via Gcc wrote: > >>> It is glibc that provides them, not GCC. >>> See >>> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86/fpu/bits/math-vector.h;h=0801905da7b85e2f43fb6b682a7b84c5eec469d4;hb

Re: TLS Implementation Across Architectures

* Nathan Sidwell: > On 6/25/20 2:34 PM, Joel Sherrill wrote: >> Hi >> >> RTEMS supports over 15 processor architectures and we would like to ensure >> that TLS is supported on all rather than just a handful of popular ones >> (arm, x86, powerpc, sparc, etc). I know of Ulrich Drepper's document (

Re: Separate commit mailing lists for trunk/branches possible?

* Carlos O'Donell via Gcc: > FYI, for glibc we use the AdaCore git commit hooks (like gdb). > > There we use this configuration: > > # Only send emails for master and release branches. > no-emails = refs/heads/(?!master|release.*) > > This way you don't get vendor branch commit ema

Re: Why was it important to change "FALLTHROUGH" to "fall through"?

* Bruce Korb via Gcc: > I don't write a lot of code anymore, but this sure seems like a > gratuitous irritation to me. I've been using > > // FALLTHRU and > // FALLTHROUGH > > for *DECADES*, so it's pretty incomprehensible why the compiler should > have to invalidate my code because it thi

Re: Lowest i386 CPU Model with proper C++ atomics

* Joel Sherrill: > With that in mind, what's the lowest/oldest i386 CPU model we > should consider as the new base model? The 80486 has a CMPXCHG instruction (4-byte CAS). Starting from CAS, you can build the rest. There might be some caveats about the memory model implementation (it may not be

Re: Lowest i386 CPU Model with proper C++ atomics

* Joel Sherrill: > I don't know that we have a huge issue in making the i486 a minimum. > I was proposing a Pentium II or P6 as a baseline since that moves you > up to having a TBR and initial SMP support. Sorry, what's a TBR? > But I think there are still embedded x86 clones that I am not sure

Re: Git commit "Author: [...] via Gcc-patches "

* Thomas Schwinge: > Should we have a Git commit hook to catch that (and similar variants)? It's also possible to move to a mailing list host which does not rewrite the From: header. The commit hook is better than nothing, although it's probably a bit tricky—some of use sourceware.org addresses,

Re: [RFC] Increase libstdc++ line length to 100(?) columns

* Allan Sandfeld Jensen: > If you _do_ change it. I would suggest changing it to 120, which is next > common step for a lot of C++ projects. 120 can be problematic for a full HD screen in portrait mode. Nine pixels per character is not a lot (it's what VGA used), and you can't have any window d

Re: Add -fdirect-access-external-data

* Fangrui Song: > Hi, I filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112 which > proposes -fdirect-access-external-data to address some x86-64 > GCC/binutils pain[1] and also benefit non-x86 architectures (also see [1] > it can prevent copy relocations). > > [1] Mentioned in https://gcc.gn

Re: Remove RMS from the GCC Steering Committee

* David Edelsohn via Gcc: > Has the GCC SC blocked any new port or major feature? Not that I'm aware of. What about the plugin framework? The libgcc licensing change would not have happened naturally. Someone had to step in and delay the plugin framework feature until the licensing changes wer

Re: Moving to git

* Jeff Law: > I suspect Jakub will strongly want to see some kind commit hook to > associate something similar to an SVN id to each git commit to support > his workflow where the SVN ids are associated with the compiler > binaries he keeps around for very fast bisection. As long as we do not reb

Re: [PATCH][www] svnwrite.html: recommend giving checkin messages a title (was Re: Moving to git)

* David Malcolm: > +The log message for a checkin should be a single line giving a > +descriptive title for the checkin, followed by a blank line, followed by > +the complete ChangeLog entry for the change. This is the git convention; > +giving titles to checkins makes life easier for developers

Re: Offer of help with move to git

* Eric S. Raymond: > In the mean time, I'm enclosing a contributor map that will need to be > filled in whoever does the conversion. The right sides should become > full names and preferred email addresses. Thanks for your offer for working on this. (I actually brought up your name at the Cauld

Re: Offer of help with move to git

* Eric S. Raymond: > Florian Weimer : >> Thanks for your offer for working on this. (I actually brought up >> your name at the Cauldron. :) >> >> Can your tools handle changes in preferred email addresses over time? > > It would in theory be possible to do thi

Re: Replacing malloc with alloca.

* Ajit Kumar Agarwal: > The replacement of malloc with alloca can be done on the following > analysis. > > If the lifetime of an object does not stretch beyond the immediate > scope. In such cases the malloc can be replaced with alloca. This > increases the performance to a great extent. You als

Re: Replacing malloc with alloca.

* Jeff Law: > On 09/13/2015 12:28 PM, Florian Weimer wrote: >> * Ajit Kumar Agarwal: >> >>> The replacement of malloc with alloca can be done on the following >>> analysis. >>> >>> If the lifetime of an object does not stretch beyond the i

Re: Git conversion: disposition of old branches and tags

* Jason Merrill: > There are lots of ancient branches and tags in the SVN repository that > are no longer interesting, and it would be nice not to have them > cluttering up the lists and default fetch set. Just one minor comment: Due to the way Git branches work, this decision can be deferred to

Re: Multiprecision Arithmetic Builtins

http://clang.llvm.org/docs/LanguageExtensions.html) > to GCC? Do you mean these? <https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html> Is there something else that is missing? -- Florian Weimer / Red Hat Product Security

Re: C++ Exception Handling

* Rodrigo Bonifacio: > We are expanding this research to a broader community, so I kindly > invite you to answer our new version of the survey at: > > https://www.surveymonkey.com/r/SXCB7WJ Question 9 is too ambiguous. Do you expect answers that reflect our own judgement, or do you want us to gu

Re: Strange C++ function pointer test

On 12/31/2015 01:31 PM, Jonathan Wakely wrote: > On 31 December 2015 at 11:37, Marc Glisse wrote: >> That's what I called "bug" in my message (there are a few bugzilla PRs for >> this). It would probably work on Solaris. > > Yes, the case is still a mess in the standard and in glibc. > The "only

Re: RFC: Support non-standard extension (call via casted function pointer)

On 01/27/2016 04:17 PM, Richard Biener wrote: > We are trying to support > > t.c > --- > void *foo(); > > int bar() > { > return ((int (*)())foo) (); > } > > t2.c > - > int foo () { return 0; } > > thus doing a direct call to a function with a (wrong) prototype via a function > pointer c

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

* H. J. Lu: > I am proposing to update Intel386, x86-64 and IA MCU psABIs to specify > how to pass/return empty struct: > > 1. "collection". A collection is a structure, union or C++ class. > 2. "empty collection". An empty collection is: >a. A collection without member. Or >b. A collec

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

* H. J. Lu: >> Any syntactical array argument (at the C level) is should be passed as >> a pointer. The language appears to change that. > > I didn't use aggregate so that array is excluded here. > >> For 2., static members and non-data members do not count. > > They do count here. That is why I

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

* H. J. Lu: >> I tested GCC 5.3.1 and Clang 3.5.0. >> >> GCC Clang >> s0 non-emptynon-empty >> s1 non-emptyempty >> s2 non-emptyempty >> s3 emptyempty >> s4 emptyempty >> s5 non-emptyempty >> >> I believe s3, s4, s5 are non-empty according

Re: Linux-abi group

* H. J. Lu: > I created a mailing list to discuss Linux specific,.processor independent > modification and extension of generic System V Application Binary Interface: > > https://groups.google.com/d/forum/linux-abi > > I will start to document existing Linux extensions, like STT_GNU_IFUNC. > I wil

Re: Linux-abi group

* H. J. Lu: > On Mon, Feb 8, 2016 at 11:32 AM, Florian Weimer wrote: >> * H. J. Lu: >> >>> I created a mailing list to discuss Linux specific,.processor independent >>> modification and extension of generic System V Application Binary Interface: >>> &

Re: gnu-gabi group

* Szabolcs Nagy: > you as a group admin can do that, others cannot join > without creating a account at google (which requires > the acceptance of the google tos etc). It should be possible to subscribe to the list by sending an empty email message to . At least it works for me, and I currently

Re: gnu-gabi group

* Frank Ch. Eigler: > mark wrote: > >> [...] >>> [...] >>> >> Having a local gnu-gabi group on sourceware.org would be better IMHO. >>> > +1 >>> +1 >> >> Great. I'll ask overseers to create a mailinglist. [...] > > Done [1] [2]. If y'all need a wiki too, just ask. > > [1] gnu-g...@sourceware.org

Re: Spurious register spill with volatile function argument

* Andrew Haley: > "volatile" doesn't really mean very much, formally speaking. Sure, the > standard says "accesses to volatile objects are evaluated > strictly according to the rules of the abstract machine," but nowhere > is it specified exactly what constitutes an access. Reading or modifying

Re: Spurious register spill with volatile function argument

* Paul Koning: >> On Mar 28, 2016, at 8:11 AM, Florian Weimer wrote: >> >> ... >> The problem is that “reading” is either not defined, or the existing >> flatly contradicts existing practice. >> >> For example, if p is a pointer to a struct, will the e

Re: Should a disabled warning be allowed to be promoted to an error(Bugzilla PR 70275)?

> In Bugzilla PR # 70275, Manuel López-Ibáñez reports that even though > he provides the "-Werror=return-type" option, the compiler doesn't > flag the warning/error about a control reaching the end of a non-void > function, due to the presence of the "-w" option. He points out that > clang++ wtill

Re: Should a disabled warning be allowed to be promoted to an error(Bugzilla PR 70275)?

* Segher Boessenkool: > On Mon, Mar 28, 2016 at 04:32:50PM -0600, Martin Sebor wrote: >> On 03/28/2016 01:56 PM, Florian Weimer wrote: >> >>In Bugzilla PR # 70275, Manuel López-Ibáñez reports that even though >> >>he provides the "-Werror=return-type"

Re: std::list iteration performance for under 1000 elements

On 04/25/2016 12:51 AM, Soul Studios wrote: Hi guys, I was wondering if any of you could explain this performance for me: www.plflib.org/colony.htm#benchmarks (full disclosure, this is my website and benchmarks - I just don't under the std::list results I'm getting at the moment) If you look at

Re: SafeStack proposal in GCC

* Rich Felker: > On Wed, Apr 20, 2016 at 06:09:54PM +0200, Volodymyr Kuznetsov wrote: >> We have prototype that supports swapcontext that we're happy to >> release, but it clearly requires more work before being ready to merge >> upstream. > > The *context APIs are deprecated and I'm not sure they

GNU C: Implicit int and implicit function definitions

I just spend an hour hunting down someone else's GCC code generation bug, when it turned out it was caused by an implicit function definition, where the real return type was incompatible with int. C99 got rid of implicit function definitions and implicit ints. Would it be possible to remove t

Re: GNU C: Implicit int and implicit function definitions

On 05/20/2016 10:30 AM, lh mouse wrote: Implicit function declarations result in warnings since C99 or GNU99 and '-pedantic-errors' turns them into errors. The same goes for implicit return types. The warnings typically do not stop the build, and thus are not really helpful when you are looki

Re: GNU C: Implicit int and implicit function definitions

On 05/20/2016 11:22 AM, Andreas Schwab wrote: Florian Weimer writes: C99 got rid of implicit function definitions and implicit ints. Would it be possible to remove them retroactively from the -std=gnu99 and -std=gnu11 language variants (as well as -std=c99 and -std=c11), so that they are

Re: when gcc support -z ?

On 05/23/2016 07:59 AM, zet wrote: hello, all just like the title, when gcc support -z keyword? This seems to be a question for the gcc-help mailing list or a binutils list. Anyway, GCC already implements -z by forwarding to the linker (hence the binutils aspect). Florian

Re: Implementing atomic load as compare-and-swap for read-only memory

On 06/03/2016 02:26 PM, Torvald Riegel wrote: On Fri, 2016-06-03 at 12:03 +0200, Jakub Jelinek wrote: I guess it is a tough decision. If you don't have HW instruction to read say double word aligned integer atomically, if you don't implement atomic load on it through compare and swap (which ind

Disabling warn_unused_result warnings on a case-by-case basis

A long time ago, GCC decided that warn_unused_result warnings should *not* be silenced by casting to void, as in: (void) write (STDOUT_FILENO, message, strlen (message)); Apparently, programmers have figured out to use this idiom as a replacement: if (write (STDOUT_FILENO, message, strlen

Re: Deprecating basic asm in a function - What now?

On 06/20/2016 07:40 PM, Andrew Haley wrote: > On 20/06/16 18:36, Michael Matz wrote: >> I see zero gain by deprecating them and only churn. What would be the >> advantage again? > > Correctness. It is very likely that many of these basic asms are not > robust in the face of compiler changes bec

Re: Deprecating basic asm in a function - What now?

On 06/21/2016 06:53 PM, Andrew Haley wrote: > Me too. I wonder if there's anything else we can do to make basic asm > in a function a bit less of a time bomb. GCC could parse the assembly instructions and figure out the clobbers. Florian

Re: Help with implementing Wine optimization experiment

On 08/14/2016 08:23 AM, Daniel Santos wrote: ms_abi_push_regs: pop%rax push %rdi push %rsi sub$0xa8,%rsp movaps %xmm6,(%rsp) movaps %xmm7,0x10(%rsp) movaps %xmm8,0x20(%rsp) movaps %xmm9,0x30(%rsp) movaps %xmm10,0x40(%rsp) movaps %xmm11,0x50(%rs

Re: GNU indirect functions vs. symbol visibility

* Alan Modra: > glibc people: As the main user of ifuncs, how do you feel about not > declaring functions hidden that are implemented in glibc by ifuncs? We have run into this before, I think: > It's fine to make them hidden via a v

Re: Proposal: readable and writable attributes on variables

On 08/30/2016 02:22 PM, Jens Bauer wrote: Hi all. I know it's possible to declare a variable 'read-only' by using 'const'. When working with microcontrollers (small ICs, which often requires you to write your code at driver-level), you need to be able to declare a structure member 'read-only'

Lessons learned from compiler error/warnings tests

For compile-time fortify checks (such as the wrappers for type-safe open/openat), we need to add tests in glibc which examine the compiler output for warnings and errors. I do not want to add Dejagnu as a dependency to the glibc test suite, but I wonder if you could share any lessons learned f

Re: Lessons learned from compiler error/warnings tests

On 09/09/2016 04:13 PM, David Malcolm wrote: On Fri, 2016-09-09 at 14:28 +0200, Florian Weimer wrote: For compile-time fortify checks (such as the wrappers for type-safe open/openat), we need to add tests in glibc which examine the compiler output for warnings and errors. I do not want to add

Re: sprintf warning on overlapping output

* Jeff Law: > On 09/25/2016 03:46 AM, Bernd Edlinger wrote: >> Hi Martin, >> >> in the past I have seen (and fixed) code like >> >> sprintf(buf, "%s %d", buf, x); >> >> that may possibly work by chance, but usually >> produces undefined results. >> >> Do you see a way to enhance the warning for ca

Re: sprintf warning on overlapping output

* Jeff Law: sprintf(buf, "%s %d", buf, x); >> Or we could make this well-defined because it is such a useful >> extension. > That just encourages developers to write non-portable code. I'd > rather see this kind of thing halt the program in its tracks before > wandering into the realm of u

Re: Optimization question

* Nikolaus Dunn: > I've run into an issue where turning on compiler optimization using > -O1 or higher causes an issue in my program. Specifically, I am > replacing the new and delete operators globally to perform some real > time allocation tracking. When I compile with -O1 or -O2, my > implement

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

* Jeff Law: > On 10/04/2016 03:08 PM, Jason Merrill wrote: >> In GCC sources, I think users look at the function definition more >> often than the declaration in the header, the latter of which >> typically has neither comments nor parameter names. > So true. One could claim that our coding stand

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

* David Brown: > Far and away the best solution would be for C++ to support named > parameters or named arguments: > > > > Then you could write: > > foo(1, 2, bar_p: true); > > You could also write > > foo(y: 2, bar_p:

LSDA unwind information is off by one (in __gcc_personality_v0)

We have a fun little glibc bug which causes pthread_cond_wait to write out of bounds on i386: https://sourceware.org/bugzilla/show_bug.cgi?id=20719 Root cause is this in libgcc/unwind-c.c: 130 int ip_before_insn = 0; … 158 /* Parse the LSDA header. */ 159 p = parse_lsd

Re: LSDA unwind information is off by one (in __gcc_personality_v0)

On 10/20/2016 07:17 PM, Andreas Schwab wrote: On Okt 20 2016, Florian Weimer wrote: We have a fun little glibc bug which causes pthread_cond_wait to write out of bounds on i386: https://sourceware.org/bugzilla/show_bug.cgi?id=20719 Root cause is this in libgcc/unwind-c.c: 130 int

Re: LSDA unwind information is off by one (in __gcc_personality_v0)

On 10/20/2016 08:37 PM, Jeff Law wrote: Obviously if the PC value is actually pointing at the proper instruction, then the decrement is highly undesirable as it could put the adjusted PC into a different exception region. Yes, that's what's happening with the glibc bug. The question is how to

Re: LSDA unwind information is off by one (in __gcc_personality_v0)

On 10/21/2016 12:08 AM, Eric Botcazou wrote: We don't call _Unwind_GetIPInfo from __gcc_personality_v0 because HAVE_GETIPINFO is not defined. This happens only when using the system unwinder on ia64, if I'm not mistaken. Disassembly shows that the code is not compiled in and not part of libgcc_s

Re: LSDA unwind information is off by one (in __gcc_personality_v0)

On 10/20/2016 10:06 PM, Jim Wilson wrote: But I also see that while HAVE_GETIPINFO appears to be set by configure, it is apparently not being used when building unwind-c.o. I see that HAVE_GETIPINFO is set in the libgcc/auto-target.h file, but this file is not included by unwind-c.c. I only se

Re: where is the source code generate crtbegin.o (i386)?

* zet: > Hello, all > > where is the source code which generate crtbegin.o (i386)? > > gcc-6.2.0-source/libgcc/config/i386 only have ctr1.S/crtn.S, where is > the others(crtbegin/crtend/crt1, etc)? See libgcc/Makefile.in: ifeq ($(CUSTOM_CRTSTUFF),) # Compile two additional files that are linked

Re: How to avoid constant propagation into functions?

* Alexander Monakov: > On Wed, 7 Dec 2016, Segher Boessenkool wrote: >> > For example, this might have impact on writing test for GCC: >> > >> > When I am writing a test with noinline + noclone then my >> > expectation is that no such propagation happens, because >> > otherwise a test might turn

Re: How to avoid constant propagation into functions?

* Segher Boessenkool: > On Wed, Dec 07, 2016 at 06:27:56PM +0100, Florian Weimer wrote: >> >> > When I am writing a test with noinline + noclone then my >> >> > expectation is that no such propagation happens, because >> >> > otherwise a test migh

Re: How to avoid constant propagation into functions?

* Alexander Monakov: > On Fri, 9 Dec 2016, Richard Biener wrote: >> Right, 'used' thwarts IPA on the callee side only. noclone and noinline are >> attributes affecting the caller side but we indeed miss attributes for the >> properties you mention above. I suppose adding a catch-all attribute fo

Re: [RFC] noipa attribute (was Re: How to avoid constant propagation into functions?)

* Jakub Jelinek: > + if (lookup_attribute ("used", attributes) == NULL) > + attributes = tree_cons (get_identifier ("used"), NULL, attributes); Attribute “used” seems different to me from the rest. Based on the documentation, I wouldn't expect it to have any action-at-a-distance effect

Re: [RFC] noipa attribute (was Re: How to avoid constant propagation into functions?)

* Jakub Jelinek: > On Thu, Dec 15, 2016 at 07:11:09PM +0100, Florian Weimer wrote: >> * Jakub Jelinek: >> >> > + if (lookup_attribute ("used", attributes) == NULL) >> > + attributes = tree_cons (get_identifier ("used"), NULL, attributes

Re: [RFC] noipa attribute (was Re: How to avoid constant propagation into functions?)

* Alexander Monakov: > 2. Can we gently suggest to readers of documentation that this was > invented for use in the GCC testsuite, and encourage them to seek > proper alternatives, e.g.: > > This attribute is exposed for the purpose of testing the compiler. > In general it should be preferable

Re: Do we really need a CPP manual?

On 12/16/2016 07:06 PM, Jeff Law wrote: That's likely the manual RMS kept asking folks (semi-privately) to review. My response was consistently that such review should happen publicly, which RMS opposed for reasons I don't recall. I don't see that manual as part of the GCC project and I certai

Re: Do we really need a CPP manual?

On 12/19/2016 07:17 PM, Joseph Myers wrote: When BSI consulted on the ISO strategic plan consultation for 2016-2020 my response said that all standards should be freely licensed (I said 'I would like to see these points reflected in BSI's response to ISO. ... Thus: the goal for ISO should be to

Resurrecting -Wunreachable

that is used for this.) So I hope that the known target dependency issues would not impact the generated warnings. Comments? -- Florian Weimer / Red Hat Product Security Team

Re: Resurrecting -Wunreachable

think this works for -Wunreachable because trivially unreachable code is already gone when we enter SSA. Or am I missing something? -- Florian Weimer / Red Hat Product Security Team

Re: Resurrecting -Wunreachable

cess to these trivial if statements. -- Florian Weimer / Red Hat Product Security Team

Re: Resurrecting -Wunreachable

code unreachable after (some) optimization, just like we report type errors there. The more challenging issue with early GIMPLE is that loops have already been lowered to gotos, so adopting the syntax-based Java reachability rules is impossible. Oh dear. -- Florian Weimer / Red Hat Product Security Team

Re: Resurrecting -Wunreachable

y from information collected during optimization, but unreachable code doesn't. -- Florian Weimer / Red Hat Product Security Team

<    1   2   3   4   5   6   7   8   >