Re: Fixing inline expansion of overlapping memmove and non-overlapping memcpy

Hi, On Wed, 15 May 2019, Jakub Jelinek wrote: > Just one thing to note, our "memcpy" expectation is that either there is > no overlap, or there is 100% overlap (src == dest), both all the current > movmem == future cpymem expanders and all the supported library > implementations do support tha

Re: alloca (0) in include/libiberty.h

Hi, On Tue, 11 Jun 2019, Martin Liška wrote: > I see 3 occurrences of the alloca (0) in libiberty/regex.c, but there are > properly > guarded within: > > # ifdef C_ALLOCA > alloca (0); > # endif > > and then I noticed 2 more occurrences in gdb that break build right now: > > gdb/regcach

Re: [PATCH] Do not warn with warn_unused_result for alloca(0).

Hi, On Wed, 12 Jun 2019, Martin Sebor wrote: > > Otherwise LGTM as the patch, but I'd like to hear from others whether > > it is kosher to add such a special case to the warn_unused_result > > attribute warning. And if the agreement is yes, I think it should be > > documented somewhere that a

Re: [PATCH] Do not warn with warn_unused_result for alloca(0).

Hi, On Thu, 13 Jun 2019, Jeff Law wrote: > > (In fact I think our builtin_alloca implementation could benefit when we > > added that behaviour as well; it's a natural wish to be able to free > > memory that you allocated). > > Also note that simply sprinkling alloca(0) calls won't magically re

Re: Can LTO minor version be updated in backward compatible way ?

Hi, On Wed, 17 Jul 2019, Romain Geissler wrote: > However at scale, I think this can become a problem. What will happen > when in gcc 9.3 we change the version to 8.2 ? Will Tumbleweed recompile > 100% of the static libraris it ships ? Every compiler change causes the whole distro to be rebuilt.

Re: Use predicates for RTL objects

Hi, On Wed, 7 Aug 2019, Arvind Sankar wrote: > => x->is_a (REG) Oh god, please no. Currently at least the RTL parts of GCC still have mostly a consistent and obvious style, which is a good thing. I have no idea why anyone would think the above is easier to read than REG_P (x). Ciao,

Re: [RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)

Hello, (oh a flame bait :) ) On Thu, 5 Dec 2019, Thomas Schwinge wrote: > So, I formally propose that we lift this characters per line restriction > from IBM punch card (80) to mainframe line printer (132). > > Tasks: > > - Discussion. I object to cluttering code in excuse for using sensibl

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

Hello, On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: > Where does your '50 chars' limit come from? It's not in the glibc text, > and it's not in the linux kernel text either. AFAICT this is your > invention and you seem to be the only person proposing it. Nope, it's fairly common, so m

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

Hi, On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: > The idea is that the [...] part is NOT part of the commit, only part of > the email. I understand that, but the subject line of this thread says "e-mail subject lines", so I thought we were talking about, well, exactly that; and I see

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

Hello, On Mon, 3 Feb 2020, Jakub Jelinek wrote: > > > The idea is that the [...] part is NOT part of the commit, only part of > > > the email. > > > > I understand that, but the subject line of this thread says "e-mail > > subject lines", so I thought we were talking about, well, exactly that;

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

Hello, On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: > Well, I'd review a patch differently depending on whether or not it was > already committed, a patch requiring review or an RFC looking for more > general comments, so I *do* think such an email prefix is useful. As I said: a very go

Re: Question about undefined functions' parameters during LTO

Hello, On Fri, 13 Mar 2020, Erick Ochoa wrote: > +for (tree parm = DECL_ARGUMENTS (undefined_function->decl); parm; parm = > DECL_CHAIN (parm)) > + { > + tree type = TREE_TYPE(parm); > + if (dump_file) fprintf(dump_file, "I want the type, do I have it? > %s\n", type ? "true" :

Re: Not usable email content encoding

Hi, On Wed, 18 Mar 2020, Frank Ch. Eigler via Gcc wrote: > > > 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, reflect

Re: Not usable email content encoding

Hello, On Wed, 18 Mar 2020, Frank Ch. Eigler via Gcc wrote: > > > The From: header rewriting for DMARC participants is something sourceware > > > is doing now. > > > > Out of curiousity, is this rewriting you are talking about the cause for a > > lot of mails showing up as "From: GCC List" rathe

Re: Question about undefined functions' parameters during LTO

Hello, On Tue, 7 Apr 2020, Erick Ochoa wrote: > Thanks for this lead! It is almost exactly what I need. I do have one more > question about this. It seems that the types obtained via > FOR_EACH_FUNCTION_ARGS and TREE_TYPE are different pointers when compiled with > -flto. > > What do I mean by t

Re: Question about undefined functions' parameters during LTO

Hello, On Tue, 7 Apr 2020, Erick Ochoa wrote: > > So, when you want to compare types use useless_type_conversion_p (for > > equivalence you need useless(a,b) && useless(b,a)). In particular, > > for record types T it's TYPE_CANONICAL(T) that needs to be > > pointer-equal. (I.e. you could hard

Re: Not usable email content encoding

Hello, On Tue, 7 Apr 2020, Jonathan Wakely via Gcc wrote: > 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 try

Re: Not usable email content encoding

Hello, On Tue, 7 Apr 2020, Frank Ch. Eigler wrote: > > I find that unconvincing, because even googlegroup email lists don't > > mangle From: from sender domains that are now mangled by sourceware.org > > :-/ > > It turns out receiving mail FROM google-groups mail is itself > sometimes at risk

Re: Not usable email content encoding

Hello, On Wed, 8 Apr 2020, Mark Wielaard wrote: > On Tue, 2020-04-07 at 11:53 +0200, Florian Weimer via Overseers wrote: > > Gmail can drop mail for any reason. It's totally opaque, so it's a > > poor benchmark for any mailing list configuration changes because it's > > very hard to tell if a pa

Re: Not usable email content encoding

Hello, On Mon, 13 Apr 2020, Christopher Faylor wrote: > On Wed, Apr 08, 2020 at 04:15:27PM -0500, Segher Boessenkool wrote: > >On Wed, Apr 08, 2020 at 01:50:51PM +, Michael Matz wrote: > >>On Wed, 8 Apr 2020, Mark Wielaard wrote: > >>>Earlier versions of Mainma

Re: GCC optimizations with O3

Hello, On Wed, 22 Apr 2020, Erick Ochoa wrote: > in order for me to debug my issue, I'm going to have to refactor passes > which directly reference optimize. For debugging you can also work backwards: use -O3 and add -fno-xy options. At least you then know (after disabling all O3 passes) that

Re: Should ARMv8-A generic tuning default to -moutline-atomics

Hello, On Wed, 29 Apr 2020, Florian Weimer via Gcc wrote: > Distributions are receiving requests to build things with > -moutline-atomics: > > > > Should this be reflected in the GCC upstream defaults for ARMv8-A > generic tuning? It

Re: [LTO] Flattening memory expressions?

Hi, On Thu, 8 Jun 2006, Richard Guenther wrote: > > Please don't get too fixated on the above pseudo-code. I have not > > thought about this through in detail. I just want to bring this up, > > particularly for folks doing data dependency. Perhaps we need > > different > > expressions altoget

Re: [LTO] Flattening memory expressions?

Hi, On Thu, 8 Jun 2006, Daniel Berlin wrote: > >>> with base being either some memory object or an INDIRECT_REF of a > >>> pointer and be done with that tree code. > >> So if you have MEM_REF(INDIRECT_REF(a),i,0), you really haven't done > >> any better in removing recursion :) > > > > What type

Re: [LTO] Flattening memory expressions?

Hi, On Thu, 8 Jun 2006, Daniel Berlin wrote: > >> Thoughts? > > > > We (me and Matz) thought over this as well and concluded it would be > > nice to have > > > > - MEM_REF ( base, offset, alias_tag ) > > > > with base being either some memory object or an INDIRECT_REF of a > > pointer and be

Re: Patch queue and reviewing (Was Re: Generator programs can only be built with optimization enabled?)

Hi, On Wed, 14 Jun 2006, Joe Buck wrote: > On Wed, Jun 14, 2006 at 11:34:33AM -0700, Mike Stump wrote: > > I'd welcome the issue be addressed by the SC. I'd favor more timely > > reviews. Maybe auto approval for a patch that sits for more than a > > week? :-) > > I see your smilie, Mike,

Re: [RFC] Optimization Diary

Hi, On Wed, 7 Jun 2006, Daniel Jacobowitz wrote: > On Wed, Jun 07, 2006 at 11:29:44AM -0700, Devang Patel wrote: > > And string does not answer localization issue, however for numbers at least > > there is one precedent to follow. > > I think this discussion has gotten totally sidetracked. When

Re: x86_64 ABI

Hi, On Thu, 13 Jul 2006, Maurizio Vitale wrote: > my understanding of the x86_64 ABI is that the following structure should be > passed in registers: Right. > struct data { > unsigned int x; > unsigned int y; > unsigned long z; > }; > > but when I compile: > > #include > >

Re: g77 problem for octave

Hi, On Sun, 16 Jul 2006, Steven Bosscher wrote: > On 7/16/06, Tim Prince <[EMAIL PROTECTED]> wrote: > > > On my computer, the installed version of gcc is 4.1.0-25 and i could not > > > find any compatible version of g77 to install. For the installation of > > > octave, i need exactly gcc-g77 not

Re: gcc visibility used by moz

Hi, On Sat, 15 Jul 2006, Gabriel Dos Reis wrote: > | I don't see how they get past this issue. I've had some claim, but > | it's a feature, not a bug. > | > | The basic question is, are two unrelated types in different dlls the > | same, just because they have the same name? How do you preve

Re: RFD: language hooks in GIMPLE / lang_flag?

Hi, On Fri, 14 Jul 2006, Mark Mitchell wrote: > > Everything must be explicitly represented in the IL, totally > > independent from the input language. > > FWIW, I agree. However, I do not agree that two types are compatible > iff they would produce identical RTL. GIMPLE should still know th

New branch: insn-select

e. The branch is maintained by Michael Matz. Architecture-specific

Re: type consistency of gimple

Hi, On Mon, 14 Aug 2006, Mark Mitchell wrote: > pressure build on some set of infrastructure until it has been painfully > obvious for some amount of time that it has to change. (In my > experience, the same thing happens in developing proprietary software; > convincing product management to let

Re: Question about strange register calling truncates to SImode on x86_64

Hi, On Wed, 11 Oct 2006, Kai Tietz wrote: > > -mcmodel=small' > > Generate code for the small code model: the program and its > > symbols must be linked in the lower 2 GB of the address space. > > Pointers are 64 bits. Programs can be statically or dynamically > > linked. This is the de

Re: Question about strange register calling truncates to SImode on x86_64

Hi, On Thu, 12 Oct 2006, Kai Tietz wrote: > thanks for description. I wasn't aware, that the upper 32 bits are > zeroed. Does this means that even the stack has to be in the first 4 Gb, > too. Why should it? I.e. no, it doesn't have to. > Or does this mov instruction does a sign-extention.

Re: Unwinding CFI gcc practice of assumed `same value' regs

Hi, On Tue, 12 Dec 2006, Andrew Haley wrote: > > > In practice, %ebp either points to a call frame -- not necessarily > > > the most recent one -- or is null. I don't think that having an > > > optional frame pointer mees you can use %ebp for anything random at > > > all, but we need to m

Re: Unwinding CFI gcc practice of assumed `same value' regs

Hi, On Mon, 11 Dec 2006, Jan Kratochvil wrote: > currently (on x86_64) the gdb backtrace does not properly stop at the > outermost > frame: > > #3 0x0036ddb0610a in start_thread () from /lib64/tls/libpthread.so.0 > #4 0x0036dd0c68c3 in clone () from /lib64/tls/libc.so.6 > #5 0x00

Re: Unwinding CFI gcc practice of assumed `same value' regs

Hi, On Tue, 12 Dec 2006, Ulrich Drepper wrote: > > Really? Well, that's one interpretation. I don't believe that, > > though. It's certainly an inconsistency in the specification, which > > says that null-termination is supported, and this implies that you > > can't put a zero in there. >

Re: gcc-c-api

Hi, On Mon, 10 Sep 2012, Richard Guenther wrote: > > Thoughts? > > Micha was also working on the proposed introspection API, I blame him > for not posting anything about this despite it's being "ready" since a > few months... He. I didn't yet come to make the changes about operand inspectors

Re: gcc-c-api

Hi David, On Mon, 10 Sep 2012, David Malcolm wrote: > Is it possible for you to post your work-in-progress code somewhere? Attached. > I know that you don't feel it's ready for committing, but I would find > it helpful - I'm interested in understanding the general approach, > rather than seei

Re: C++'ization of cp/parser.c/h, limited C++ parsing support for gengtype, Remove dependency of cp/cp-lang.c on cp/parser.h

Hi, On Mon, 10 Sep 2012, Gabriel Dos Reis wrote: > > You could also do this with an explicit pointer-to-context-struct > > parameter that's passed around (and that version of the patch I > > posted), but the class-based approached seems nicer to me. > > Are we talking about encapsulation or "l

Re: Cgraph Modification Plan

Hi, On Tue, 11 Sep 2012, Lawrence Crowl wrote: > change > node->symbol.whatever > to > node->ref_symbol().whatever Please don't uglify the compiler with this. If GTY deficiencies force you to do that, then hold off on it until GTY doesn't force you anymore. Ciao, Michael.

Re: Normalizing the bitmap APIs.

Hi, On Sat, 13 Oct 2012, Lawrence Crowl wrote: > > > I have no problem in always returning a status change, if you are OK > > > with that. > > > > I am ok with that. > > There is some rationale for being concerned about performance, as the > checking routines need to read memory locations that

Re: Build/Makefile question

Hi, On Sat, 27 Oct 2012, Ian Lance Taylor wrote: > On Sat, Oct 27, 2012 at 1:45 PM, Caroline Tice wrote: > > Ian Tayler (in private communication) asked that I get the part of the > > build log that shows the .so and .a files being built and send it to > > the list. Here it is. > > I see the p

Re: lto is streamable?

Hi, On Wed, 14 Nov 2012, Paulo Matos wrote: > There's a function in lto-streamer-out.c which determines if a tree is > streamable. > This is lto_is_streamable? I have a LANG_TYPE that I want to stream and > adding to that function: > #ifdef TARGET_MYPORT > if (code == LANG_TYPE) >return tr

Re: Simplifying Gimple Generation

Hi Lawrence, On Wed, 14 Nov 2012, Lawrence Crowl wrote: > Diego and I seek your comments on the following (loose) proposal. In principle I agree with the goal, I'm not sure I like the specific way yet, and even if I do I have some suggestions: > We will add a set of helper classes to be used a

Re: Simplifying Gimple Generation

Hi, On Thu, 15 Nov 2012, Gabriel Dos Reis wrote: > On Thu, Nov 15, 2012 at 8:48 AM, Michael Matz wrote: > [...] > > The method name should imply the action, e.g. 'add_stmt' or append_stmt > > or the like. > > strongly agreed. > [...] > > >

Re: Simplifying Gimple Generation

Hi, On Thu, 15 Nov 2012, Lawrence Crowl wrote: > They allow us to use the same name for the same actions in two > different contexts. In particular, distinguishing between statement > construction in SSA and non-SSA. I don't see the difference, and I don't see where you need context data to di

Re: Simplifying Gimple Generation

Hi, On Fri, 16 Nov 2012, Diego Novillo wrote: > > I think consistency should trump brevity here, so also add a tree code for > > the converter, i.e. > > ssa_stmt b = q.stmt (NOP_EXPR, shadow_type, a); > > Ah, yes. This one was amusing. When we were drafting the proposal, > Lawrence kept wond

Re: Unifying the GCC Debugging Interface

Hi, On Mon, 19 Nov 2012, Martin Jambor wrote: > Well, this is what I was actually afraid of. If things like generic > or tree dump of a tree value is selected by new TDF_ flags, then you > are in danger of just replacing current mess in function names by a > mess of constants. I'd much rather h

Re: Unused Field in graphite-poly.h?

Hi, On Fri, 16 Nov 2012, Lawrence Crowl wrote: > I think the field "htab_t original_pddrs" in struct scop in > graphite-poly.h is unused. Seems I overlooked it during my post-isl cleanups. Yes, remove it. Ciao, Michael.

Re: Unused DSE Functions

Hi, On Tue, 20 Nov 2012, Steven Bosscher wrote: > On Mon, 19 Nov 2012 18:31:27 -0800, Lawrence Crowl wrote: > > > Richi, ping? > > Just guessing... isn't he simply out on Honeymoon? Yes, he'll be back next week. Ciao, Michael.

Re: Unifying the GCC Debugging Interface

Hi, On Tue, 20 Nov 2012, Lawrence Crowl wrote: > On 11/19/12, Diego Novillo wrote: > > On Nov 19, 2012 Michael Matz wrote: > > > So, yes, the larger layouting should be determined by name of the > > > dump function. A flag argument might look nice from an interfa

Re: Hash table iterators.

Hi, On Thu, 22 Nov 2012, Lawrence Crowl wrote: > I have found that tree-flow.h implements iteration over htab_t, > while there is no current facility to do that with hash_table. > Unfortunately, the specific form does not match the standard C++ > approach to iterators. We have several choices. >

Re: System V Application Binary Interface 0.99.5

Hi, On Wed, 30 Jan 2013, Andrew Haley wrote: > I'm looking at Section 3.2.3, Parameter Passing. > http://artfiles.org/kernel.org/pub/scm/devel/binutils/hjl/x86-64-psabi.git/ > > I still cannot tell whether parameters should or should not be sign- or > zero-extended when they are moved into regis

Re: System V Application Binary Interface 0.99.5

Hi, On Wed, 30 Jan 2013, Andrew Haley wrote: > >>> It's an optimization to do so to avoid partial register stalls. > >> > >> Well, it's hardly an optimization if it's incorrect, and it seems to > >> be incorrect. Hmm? GCC generates code that doesn't rely on the extension taking place. > >> As

Re: Global Value Numbering and dependence on SSA in GCC

Hi, On Sun, 10 Feb 2013, Richard Biener wrote: > >> Consider the following example: > >> > >> if (...) > >>a_1 = 5; > >> else if (...) > >>a_2 = 2; > >> else > >>a_3 = 13; > >> > >> # a_4 = PHI > >> return a_4; > >> > >> Do you mean that I treat a

RE: genattrtab regression: infinite loop

Hi, On Mon, 11 Feb 2013, Paulo Matos wrote: > The following self-contained md file generates an infinite loop in genattrtab: > (define_attr "fpsize" "short,long" (const_string "short")) > > (define_attr "fplength" "" > (if_then_else > (eq_attr "fpsize" "long") > (const_int

Re: C/C++ Option to Initialize Variables?

Hi, On Mon, 18 Feb 2013, Jeffrey Walton wrote: > On Mon, Feb 18, 2013 at 10:34 AM, Andrew Haley wrote: > > On 02/18/2013 03:07 PM, Jeffrey Walton wrote: > >> On Mon, Feb 18, 2013 at 9:43 AM, Jonathan Wakely > >> wrote: > >>> On 18 February 2013 13:28, Jeffrey Walton wrote: > > > What if t

Re: C/C++ Option to Initialize Variables?

Hi, On Mon, 18 Feb 2013, Alexander Monakov wrote: > On Mon, 18 Feb 2013, Michael Matz wrote: > > Automatic variables, as they are on the stack, are unlikely to usually get > > the value 0 out of pure luck, so an option to initialize them to 0xDEADBEAF > > doesn't mak

Re: How does _ZNSs4_Rep20_S_empty_rep_storageE (not) become a unique global symbol?

Hi, On Tue, 19 Feb 2013, Stephan Bergmann wrote: > I'm puzzled by the following on Linux, where I don't understand what causes it > that a given symbol is exported as "u" (when viewed with nm, which documents > "u" as "a unique global symbol. This is a GNU extension...") or not: > > * On an olde

Re: How does _ZNSs4_Rep20_S_empty_rep_storageE (not) become a unique global symbol?

Hi, On Wed, 20 Feb 2013, Michael Matz wrote: > I.e. it looks like as if a following reference once the link editor saw > the definition of the symbol resets it's unique status. I can make both > symbols wrong/non-unique by placing wlocale-inst.o last in the linker > cmdlin

Re: [RFC] IL verification reorg

Hi, On Thu, 21 Feb 2013, Richard Biener wrote: > Do people think that the fine-grained verification control > is actually useful or do you agree with me that it leads to > sloppiness? I agree with you ... > --- 1955,1982 > return; > > #if defined ENABLE_CHECKING > ! if (flags

Re: Inline virtual call puzzling behaviour

Hi, On Sun, 7 Jul 2013, Thierry Lavoie wrote: > int main(int argc, char** argv) > { > A* ptr = 0; > if(argc == 1) > ptr = new B(); > else > ptr = new A(); > > ptr->blah(); > > B().blah(); > C().blah(); > } > > The

Re: Calculating instruction costs

Hi, On Tue, 9 Jul 2013, David Given wrote: > Trying 8, 9 -> 10: > Successfully matched this instruction: > (set (reg:SI 47 [ *_5 ]) > (mem:SI (plus:SI (mult:SI (reg/v:SI 43 [ b ]) > (const_int 4 [0x4])) > (reg:SI 0 r0 [ a ])) [2 *_5+0 S4 A32])) > rejecting combinat

Re: Calculating instruction costs

Hi, On Wed, 10 Jul 2013, David Given wrote: > Michael Matz wrote: > [...] > > As you didn't adjust any cost I would guess the high value comes from the > > default implementation of address_cost, which simply uses arithmetic cost, > > and the MULT in there

Re: Should -Wmaybe-uninitialized be included in -Wall?

Hi, On Thu, 11 Jul 2013, Gabriel Dos Reis wrote: > > Arg, no. -Werror is very useful for development and I'm sure that > > code quality increases because of it, but it should never be enabled > > by default for releases. I think about 80% of the bugs we've had > > filed so far for packages f

Re: Dependency confusion in sched-deps

Hi, On Thu, 5 Dec 2013, Maxim Kuvyrkov wrote: > Output dependency is the right type (write after write). Anti > dependency is write after read, and true dependency is read after write. > > Dependency type plays a role for estimating costs and latencies between > instructions (which affects pe

Re: GCC libatomic ABI specification draft

Hi, On Wed, 18 Jan 2017, Richard Henderson wrote: > > Section 3 Rationale, alternative 1: I'm wondering if the example is > > correct. For a 4-byte-aligned type of size 3, the implementation > > cannot simply use 4-byte hardware-backed atomics because this will > > inevitably touch the 4th by

Re: GCC libatomic ABI specification draft

Hi, On Fri, 20 Jan 2017, Richard Henderson wrote: > > You can't have a 4-aligned type of size 3. Sizes must be multiples of > > alignment (otherwise arrays don't work). The type of a 3-sized field > > in a packed struct that syntactically might be a 4-aligned type (e.g. > > by using attribut

Re: SPEC 456.hmmer vectorization question

Hi Steve, On Mon, 6 Mar 2017, Steve Ellcey wrote: > I was looking at the spec 456.hmmer benchmark and this email string > from Jeff Law and Micheal Matz: > > https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01970.html > > and was wondering if anyone was looking at what more it would take > for G

Re: Steering committee, please, consider using lzip instead of xz

Hi, On Thu, 8 Jun 2017, Jakub Jelinek wrote: > For integrity checking, gcc provides the md5.sum, sha512.sum files on > gcc.gnu.org and gpg signatures on ftp.gnu.org. The choice of xz is that > it is used very widely these days, which is not the case of lzip. And given http://lists.gnu.org/

Re: Optimization breaks inline asm code w/ptrs

Hi, On Mon, 14 Aug 2017, Alan Modra wrote: > I've opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81845 to track > the lack of documentation. You mean like in this paragraph discussing memory clobbers and uses in extended asms that we have since 2004? : If your assembler

Re: gcc torture test pr52286.c

Hi, On Mon, 28 Aug 2017, Jeff Law wrote: > > long a, b = 0; > > asm ("" : "=r" (a) : "0" (0)); > I wouldn't use a matching constraint here. Something like this is > probably closer to what you want: > > asm ("" : "=r" (a) : "n" (0)); > > The "n" says accept any immediate integer constant w

Re: gcc torture test pr52286.c

Hi, On Mon, 28 Aug 2017, Jeff Law wrote: > I can't remember matching constraints ever working that way. They do work exactly so. These uses are all correct, though they place some random value into x: int x, y, z; y = z = init(); asm ("" : "=r" (x) : "r" (y+z)); asm ("" : "=r" (x) : "

Re: gcc torture test pr52286.c

Hi, On Mon, 28 Aug 2017, Paul S wrote: > I've ported gcc to a 16 bit CPU and have all torture tests passing bar one, > pr52286.c > > The offending lines of code are > > long a, b = 0; > asm ("" : "=r" (a) : "0" (0)); > > > which should cause zero to be assigned to the "a" SI sized variabl

Re: gcc torture test pr52286.c

Hi, On Mon, 28 Aug 2017, Michael Matz wrote: > On Mon, 28 Aug 2017, Jeff Law wrote: > > > I can't remember matching constraints ever working that way. > > They do work exactly so. FWIW, I was momentarily worried that there once was a world where you were right. If so

Re: gcc torture test pr52286.c

Hi, On Mon, 28 Aug 2017, Jeff Law wrote: > > asm ("" : "=r" (x) : "r" (y+z)); > > asm ("" : "=r" (x) : "r" (z)); > > asm ("" : "=r" (x) : "r" (42)); > > > > > (are we still agreeing on this? I'm having a problem understanding why > > you think the above wouldn't work) > > How do we rep

Re: Question about generated type for common block in fortran

Hi, On Thu, 26 Oct 2017, Richard Biener wrote: > >Hi, > >I am looking into DSE transformation of some fortran codes. Given > >below fortran declarations: > > > > real*8 a(len) , b(len) , c(len) , d(len) > > common /area/ a, b, c, d > > real*8 src1(len), temp1(len), t

Re: Question about generated type for common block in fortran

Hi, On Wed, 8 Nov 2017, Richard Biener wrote: > Not sure how - the issue is the FIELD_DECLs overlap which rules out a > RECORD_TYPE and leaves us with a UNION_TYPE. No, as the initial mail already mentioned, for the example in question the overlapping fields can be put into a union which itsel

Re: Question about generated type for common block in fortran

Hi, On Thu, 9 Nov 2017, Bin.Cheng wrote: > So I have two questions here. > A) Is this special kind union type only generated by fortran FE for > equivalence+common? It's not special in that it isn't marked in any way. For all purposes it's a normal union type with surprising field(offset)s. I

Re: Who generate .rela.debug_info?

Hi, On Mon, 18 Dec 2017, Nancy wrote: > tls.c: > __thread int i=10; > > $gcc -g -c -save-temps tls.c > $readelf -r tls.o > Relocation section '.rela.debug_info' at offset 0x2d0 contains 6 entries: > Offset Info Type Sym. ValueSym. Name + > Addend > 000

Re: Unstable build/host qsorts causing differing generated target code

Hi, On Fri, 12 Jan 2018, Joseph Myers wrote: > On Fri, 12 Jan 2018, Alexander Monakov wrote: > > > No. The qsort_chk effort was limited to catching instances where comparators > > are invalid, i.e. lack anti-commutativity (may indicate A < B < A) or > > transitivity property (may indicate A < B

Re: gdb 8.x - g++ 7.x compatibility

Hi, On Wed, 7 Feb 2018, Simon Marchi wrote: > This addresses the issue of how to do good software design in GDB to > support different producers cleanly, but I think we have some issues > even before that, like how to support g++ 7.3 and up. I'll try to > summarize the issue quickly. It's now

Re: gdb 8.x - g++ 7.x compatibility

Hi, On Wed, 7 Feb 2018, Simon Marchi wrote: > On 2018-02-07 12:30, Jonathan Wakely wrote: > >> Ah ok, the class name appears mangled in other entities' mangled name. But > >> from what I understand there's no mangled name for the class such that > >> > >> echo | c++filt > >> > >> outputs the

Re: how to make GCC option hook aware

Hi, On Sat, 17 Feb 2018, Andre Groenewald wrote: > Hi GCC folks, > > I have implemented a function for LANG_HOOKS_HANDLE_OPTION for my toy > language front end to handle options. > > The specific option is populated in lang.opt as fdemo-debug > > My lang-specs file has the following: {"@demo",

Re: Dealing with default recursive procedures in Fortran

Hi, On Thu, 12 Apr 2018, Thomas König wrote: > with Fortran 2018, recursive is becoming the default. This will likely > have a serious impact on many user codes, which often declare large > arrays which could then overflow stacks, leading to segfaults without > further explanation. -fopenmp alre

Re: Auto-generated .rodata contents and __attribute__((section))

Hi, On Wed, 16 May 2018, Richard Biener wrote: > > Are constant pool entries merged at compile time or at link time? I > > would presume it should be done at link time because otherwise you're > > only merging entries within a single compilation unit (which doesn't > > sound that useful in a b

Re: Auto-generated .rodata contents and __attribute__((section))

Hi, On Fri, 18 May 2018, Richard Biener wrote: > Interesting. Do they allow merging across such sections? Consider a 8 > byte entity 0x12345678 and 4 byte entities 0x1234 0x5678, will the 4 > byte entities share the rodata with the 8 byte one? There's no language to forbid this (as long as t

Re: Invalid program counters and unwinding

Hi, On Thu, 28 Jun 2018, Jeff Law wrote: > I believe "dumb" is referring to the fact that we're already in a bit of > a weird state as evidenced by the NULL FDE. Blindly trying to read the > contents of the PC that we couldn't map to an FDE is, IMHO, dumb. > > One might even be able to argue

Re: Invalid program counters and unwinding

Hi, On Mon, 2 Jul 2018, Jakub Jelinek wrote: > > I disagree. ASM code often lacks unwind descriptors (now less than in > > the past, but still). My rule of thumb is always: no descriptor -> > > has to be a framepointer-using routine with standard calling sequence. > > (I.e. declare the comb

Re: [RFC] Adding Python as a possible language and it's usage

Hi, On Tue, 17 Jul 2018, Martin Liška wrote: > 1) gcc/optc-save-gen.awk is full of copy&pasted code, due to lack of flags > type classes multiple > global variables are created (var_opt_char, var_opt_string, ...) > > 2) similar happens in gcc/opth-gen.awk > > 3) we do very many regex matches (

Re: [RFC] Adding Python as a possible language and it's usage

Hi, On Fri, 27 Jul 2018, Michael Matz wrote: > Using any python scripts as part of generally building GCC (i.e. where > the generated files aren't prepackaged) will introduce a python > dependency for distro packages. And for those distros that bootstrap a > core cycle

Re: [RFC] Adding Python as a possible language and it's usage

Hi, On Fri, 27 Jul 2018, Joseph Myers wrote: > I would have expected most concerns to be about builds on non-GNU hosts - > not about builds on GNU/Linux where Python is generally already available > (and differences in Python versions should definitely *not* affect the > generated output, so t

Re: dejagnu version update?

Hi, On Wed, 8 Aug 2018, Bernhard Reutner-Fischer wrote: > How come? > > If one wants to develop on a distro that is notoriously outdated then > you have to obtain the missing pieces yourself. It's not about developing on an "notoriously outdated" distro, but about _testing_ on it. There are

Re: Questions related to creation of libgcov.so

Hi, On Tue, 14 Aug 2018, Martin Liška wrote: > I'm sending second version of the patch candidate. I was able to create > a mapfile and generate versioned symbols for libgcov.so file. > > Unresolved issues: > 1) I still see linking with static library: > > $ find /home/marxin/bin/gcc -name libgc

Re: Questions related to creation of libgcov.so

Hi, On Thu, 16 Aug 2018, Martin Liška wrote: > SHLIB_SOVERSION = 1 > SHLIB_SONAME = @shlib_base_name@.so.$(SHLIB_SOVERSION) > > which would require a substitution for soversion, show I generalize even > so much? I wouldn't bother. libgcov.so.1 sounds just fine, and due to symbol versioning w

Re: Questions related to creation of libgcov.so

Hi, On Thu, 16 Aug 2018, Joseph Myers wrote: > On Thu, 16 Aug 2018, Michael Matz wrote: > > > > About the location of libgcov.{a,so}, I believe right place would be now: > > > > > > /home/marxin/bin/gcc/lib64/libgcov.so.1 > > > /home/marxin/bin/gcc/l

Re: Questions related to creation of libgcov.so

Hi, On Fri, 24 Aug 2018, Martin Liška wrote: > >> Where > >> /home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/libgcov.so > >> points to /home/marxin/bin/gcc/lib64/libgcov.so.1 ? > > > > Any symlinks need to be *relative*, not absolute, so the install tree > > is relocatable. There's

Re: Questions related to creation of libgcov.so

Hi, On Fri, 24 Aug 2018, Martin Liška wrote: > If I see correctly, for libgcc has following files: > > /home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/libgcc_eh.a > /home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/libgcc.a > /home/marxin/bin/gcc/lib64/libgcc_s.so.1 > /home/marxi

<    1   2   3   4   5   >