Re: Remove RMS from the GCC Steering Committee

On 3/30/21 11:34 AM, Jonathan Wakely wrote: > On Tue, 30 Mar 2021 at 11:14, Andrew Haley wrote: >> We could just rename it to "GCC", in much the same way that Acorn Risc >> Machine became Advanced Risc Machines, then just "Arm". But I'd much >> p

Re: Remove RMS from the GCC Steering Committee

ht suggest a new name for the project (~: We could just rename it to "GCC", in much the same way that Acorn Risc Machine became Advanced Risc Machines, then just "Arm". But I'd much prefer that the FSF got its house in order. -- Andrew Haley (he/him) Java Platform Lead Enginee

Re: Integer division on x86 -m32

faster. > > IIRC, idiv requires that the quotient fit in 32 bits, while your C code > doesn't. (1LL << 60) / 3 would cause an error with idiv. Isn't that an integer overflow, which is undefined behaviour? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. <

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

hat we should not change codegen for an existing GCC release series unless there is a bug. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

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

omic CAS. It may well be that on N1 an LDX followed quickly by an STX fails frequently under high contention, which it really should not do. It looks like the sample code provided is fantastically highly- contended, which is IMVHO a perverse thing to optimize for. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: Status of C++11 support

On 12/9/19 5:03 PM, Nicholas Krause wrote: >> https://gcc.gnu.org/projects/cxx-status.html#cxx11 > I'm asking of what support exists in the gcc codebase itself not for other > projects using gcc. That is what you got. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK

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

tin. It's fast, simple, and widely used. These days you might use variable-length arrays instead, which are at least portable. Is there some problem that you want to solve? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: aarch64 TLS optimizations?

Is there some kind of magic TLS optimization that > can happen for certain variables on aarch64? I'm trying > to understand how it could know the offset like > it appears to do in the code. https://www.fsfla.org/~lxoliva/writeups/TLS/paper-lk2006.pdf -- Andrew Haley Java Platform Le

Re: Putting an all-zero variable into BSS

until next > weekend. > > In the meantime, comments are still welcome :-) Did you look at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83100 This was the change that caused this behaviour. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

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

On 3/22/19 10:20 AM, 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, b

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

undefined behaviour commonplace among C programmers? There's nothing in the standard to justify it: any expression which contains UB is undefined. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

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

On 3/21/19 8:53 AM, Moritz Strübe wrote: > Hey. > > Am 20.03.2019 um 18:36 schrieb Andrew Haley: >> On 3/20/19 2:08 PM, Moritz Strübe wrote: >>> Ok, I played around a bit. Interestingly, if I set >>> -fsanitize=udefined and -fsanitize-undefined-trap-

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

_tmp = i * 5; for (int i = start * 5; i < limit_tmp; i += 5) { foo(i); } If you answered "Yes, GCC should be allowed to do this", would you want a warning? And how many such warnings might there be in a typical program? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. &l

Re: autovectorization in gcc

ely requires user documentation. I don't agree. Sometimes vectorization is critical. It would be nice to have a warning which would fire if vectorization failed. That would surely help the OP. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: movmem pattern and missed alignment

On 10/08/2018 07:38 PM, Paul Koning wrote: > > >> On Oct 8, 2018, at 1:29 PM, Andrew Haley wrote: >> >> On 10/08/2018 06:20 PM, Michael Matz wrote: >>> Only if you somewhere visibly add accesses to *i and *j. Without them you >>> only have the "

Re: movmem pattern and missed alignment

; pointers in disguise and hence be in fact only 1-aligned. I.e. there's > nothing in your small example program from which GCC can infer that those > two global pointers are in fact 2-aligned. So all you'd actually have to say is void f1(void) { *i; *j; __builtin_memcpy (i, j, 3

Re: [llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h

pointer to some union type, magic will happen. It won't work, unless the object stored in the memory at that address was stored as the union type. Do not lie to the compiler or it will get its revenge. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> EAC

Re: Finding virtual address of functions in code

On 07/01/2018 03:19 PM, Mahmood Naderan via gcc wrote: > Is there any builtin function in C which prints the virtual address > of functions including the main? I see __builtin_return_address() > but that returns the “return address”. #include int main() { printf("%p\n", m

Re: __builtin_isnormal question

number. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: Please support the _Atomic keyword in C++

tion after initialization but with > volatile it does not. That's what should happen on x86. > So I think it might not provide the same guarantees. I think it does. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: fminnm/fmaxnm generation in aarch64

ould be incorrect for GCC to translate that expression into fminnm. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: [RFC] Deprecate "implicit int" for main() in C++

On 04/25/2018 03:04 PM, Jonathan Wakely wrote: > On 25/04/18 14:59 +0100, Andrew Haley wrote: >> On 04/25/2018 02:56 PM, Jason Merrill wrote: >>> The warning by default seems sufficient to me. >> >> Yes. We've been bitten by this a few times, with mysterious crashes.

Re: [RFC] Deprecate "implicit int" for main() in C++

On 04/25/2018 02:56 PM, Jason Merrill wrote: > The warning by default seems sufficient to me. Yes. We've been bitten by this a few times, with mysterious crashes. I'm not sure it even makes sense only to be a warning, but I guess that's up to the C++ TC. -- Andrew Haley Java Platform L

Re: [RFC] Deprecate "implicit int" for main() in C++

in, the effect is equivalent to a return with operand 0 (see also 18.3). -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: Bugzilla admin?

On 10/01/18 14:33, Jakub Jelinek wrote: > On Wed, Jan 10, 2018 at 02:30:39PM +0000, Andrew Haley wrote: >> I don't seem to have write access to bugs in GCC Bugzilla. I'm pretty >> sure I used to have it. Who do I contact? Thanks. > > You need to use the @gcc.gnu.org

Bugzilla admin?

I don't seem to have write access to bugs in GCC Bugzilla. I'm pretty sure I used to have it. Who do I contact? Thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: TLS details on Linux for x86 and x64

On 03/12/17 10:50, Jakub Jelinek wrote: > On Sat, Dec 02, 2017 at 05:00:23PM +0000, Andrew Haley wrote: >> On 02/12/17 14:04, Liu Hao wrote: >>> >>> 0) What is the magical `@tpoff` suffix supposed to do? The `@ntpoff` and >>> `@dtpoff` things are documented in

Re: TLS details on Linux for x86 and x64

thereafter. How is LD supposed to > associate the section containing the initializer with the symbol of > object being initialized, without disordering? > > Any help will be appreciated. Have you read https://www.fsfla.org/~lxoliva/writeups/TLS/RFC-TLSDESC-x86.txt ? -- Andrew Haley

Re: atomic_thread_fence() semantics

On 19/10/17 14:04, Sebastian Huber wrote: > On 19/10/17 14:18, Andrew Haley wrote: >> On 19/10/17 13:10, Jonathan Wakely wrote: >>> There are no atomic operations on atomic objects here, so the fence >>> doesn't synchronize with anything. >> Really? This seems r

Re: atomic_thread_fence() semantics

th all non-atomic and relaxed atomic loads from the same locations made in thread B after F. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: atomic_thread_fence() semantics

_1 = m_2(D) * 4711; message = _1; __atomic_thread_fence (3); ready = 1; return; } It looks like a bug in the lowering pass. ;; __atomic_thread_fence (3); is lowered to (nil) -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: GCC aliasing extension for C

On 18/09/17 10:48, Florian Weimer wrote: > Is this a property of the char type, or would other types work as well, > for example, double or long double? It has to be a character type, I believe. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> EA

Re: gcc behavior on memory exhaustion

o done it. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: Overwhelmed by GCC frustration

ore optimizations, back off, and concentrate on simplicity and robustness at the expens of ultimate code quality. Should we? It would take courage, and there will be an eternal pressume to improve code. And, of course, we'd risk someone forking GCC and creating the "superoptimized GCC"

Re: What kind of data would be put into code section?

ble sections? Is there any way to avoid this? > Any ideas? On ARM, PC-relative loads have a fairly short range. So: float d() { return 3.141592653589; } d: ldr s0, .LC0 ret .align 2 .LC0: .word 1078530011 -- Andrew Haley Java Platform Lead Engineer Red Hat

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

m_part(uint8_t* buf, int len, uint32_t ret) { struct ui16{ uint16_t d; }; ui16 *ptr = (ui16*)buf; There's no need for any of this messing about with pointer casts, as has been explained. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd.

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

you really want to do this kind of thing, use -fno-strict-aliasing. See also http://www.microhowto.info/howto/calculate_an_internet_protocol_checksum_in_c.html -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

[PATCH] Loop splitting breaks with loops of pointer type

? Andrew. 2017-03-08 Andrew Haley <a...@redhat.com> PR tree-optimization/79894 * tree-ssa-loop-split.c (compute_new_first_bound): When calculating the new upper bound, (END-BEG) should be added, not subtracted. Index: gcc/tree-ssa-loop-s

Re: signed int performance question

On 28/02/17 06:38, Eyal Itkin wrote: > However, in signed integers, the logical meaning of any relation check > is only the theoretical meaning of the order relation between the > numbers in the group Z. Meaning that in a purely theoretical manner "a > + b < c" is a relation order that is

Re: Argument Against Removal of GCJ

On 22/02/17 05:52, R0b0t1 wrote: > I have found GCJ to be one of the best methods for bootstrapping > OpenJDK. No other method of adding support for new architectures that > does not involve working closely with OpenJDK upstream is known to me. That doesn't matter any more because OpenJDK has

Re: Odd gcc-6.3.0 code generation on mips64 platform causing kernel Oops

On 23/01/17 16:11, Joshua Kinard wrote: > So now the question is why stack-probing kills this machine on generic MIPS > code that its smaller cousin is seemingly unaffected by. I do know that IP27 > has a different set of memory initialization routines in the MIPS code, so is > it possible that,

Re: Odd gcc-6.3.0 code generation on mips64 platform causing kernel Oops

On 23/01/17 15:26, Joshua Kinard wrote: > I am not sure what this lone store-doubleword instruction is exactly doing, > nor > can I locate where in the gcc MIPS code it is being generated from. It's a stack probe, making sure that there is enough stack space. Its only purpose is to provide a

Re: [PATCH] Delete GCJ

On 23/01/17 13:41, Jakub Jelinek wrote: > On Mon, Jan 23, 2017 at 04:51:44AM -0800, Per Bothner wrote: >> The last part is moot, as we should strive to not move pages and thus break >> links. > > I meant updating URLs in the pages when they refer to external web pages > which move over time (or

Re: [PATCH] Delete GCJ

On 22/01/17 18:41, Per Bothner wrote: > In my opinion, all/most of these should be restored. Because of the historical interest? That's a good point, and perhaps I was too hasty. Sorry. Andrew.

Re: Why are GCC Internals not Specification Driven ?

On 18/12/16 02:33, Seima Rao wrote: > Precisely, stuffs like GENERIC, GIMPLE, RTL, gas(inline assembly), > GCC extensions internals, ... and gnu's own debugging tied to gcc > (if such exist nowadays), ... are not documented in a specification > driven way. That's interesting. Can

Re: libffi maintenance within GCC?

On 28/10/16 04:03, Ian Lance Taylor wrote: > On Thu, Oct 27, 2016 at 6:08 AM, Anthony Green wrote: >> Is it still important that libffi be included in the GCC tree? > > [ Replying again as last message was bounced as HTML--sorry for the > duplication.] > > libffi is used

Re: libffi maintenance within GCC?

On 27/10/16 13:55, Matthias Klose wrote: > With the removal of libgcj, the only user of libffi in GCC is libgo, however > there is now no maintainer listed anymore for libffi in the MAINTAINERS file, > and the libffi subdir is a bit outdated compared to the libffi upstream > repository (got aware

Re: [PATCH] Delete GCJ

On 04/10/16 09:39, Rainer Orth wrote: > Hi Matthias, > >> On 05.09.2016 17:13, Andrew Haley wrote: >>> As discussed. I think I should ask a Global reviewer to approve this >>> one. For obvious reasons I haven't included the diffs to the deleted >>> gcc/j

Re: [PATCH] Delete GCJ

On 02/10/16 14:27, Andreas Schwab wrote: > Things we may want to remove: > > - references to java in contrib (download_ecj, gcc_update, > patch_tester.sh, update-copyright.py) > - GCJ, GCJ_FOR_BUILD, GCJ_FOR_TARGET in Makefiles.tpl and configure.ac > - LIBGCJ_SONAME in

Re: [PATCH] Fix bootstrap with --enable-languages=all,go

On 30/09/16 23:16, Rainer Orth wrote: > me too, though mostly to have maximum test coverage (primarily on > Solaris). As expected, a x86_64-apple-darwin16 bootstrap with > --enable-objc-gc just failed for me. I'm testing the following patch > (on top of Jakub's). > > Rainer > > >

Re: Move Per Bothner, Andrew Haley, and Tom Tromey to write-after approval after GCJ deletion

On 30/09/16 17:38, Rainer Orth wrote: > but both Per and Tom are still libcpp maintainers, so no need to add > them to the write-after-approval list. Ooh, I had no idea. Will fix, thanks. Andrew.

Move Per Bothner, Andrew Haley, and Tom Tromey to write-after approval after GCJ deletion

Pushed. 2016-09-30 Andrew Haley <a...@redhat.com> * MAINTAINERS: Move Per Bothner, Andrew Haley, and Tom Tromey to write-after approval after GCJ deletion. Index: MAINTAINERS === --- MAINTAINERS (revision

Re: [PATCH] Delete GCJ

On 05/09/16 17:25, Gerald Pfeifer wrote: > And here is the patch for the web pages. > > Note I did not include all the removed java/* contents. Is there > anything particular you'd like to retain there? No, please delete it all. Thanks, Andrew.

Re: [PATCH] Delete GCJ

On 30/09/16 11:27, Marek Polacek wrote: > Can we move forward with this patch, then? I've been travelling for several weeks. However, I'm back at my desk now, so I can move this forward. I have all the approvals and everybody has had time to respond. However, I'll need to pull some more recent

Re: Is this FE bug or am I missing something?

On 12/09/16 20:41, Igor Shevlyakov wrote: > It would be beneficial to make the behaviour consistent between > those 2 cases. You've got two cases of undefined behaviour. What benefit is there from making two cases of UB consistent with each other? It's not worth the effort of changing the

Re: [PATCH] Delete GCJ

On 10/09/16 12:59, NightStrike wrote: > Could we at least reach out and see if there's someone else who could > be the maintainer? I noticed gcj patches recently, so there's still > interest. 1. It's too late. We have been discussing this for a long time, and we're now doing what we decided.

Re: [PATCH] Delete GCJ

On 05/09/16 17:15, Richard Biener wrote: > On September 5, 2016 5:13:06 PM GMT+02:00, Andrew Haley <a...@redhat.com> > wrote: >> As discussed. I think I should ask a Global reviewer to approve this >> one. For obvious reasons I haven't included the diffs to the deleted

Re: [PATCH] Delete GCJ

On 05/09/16 16:29, Matthias Klose wrote: > Please consider removing boehm-gc as well. The only other user is > --enable-objc-gc, which better should use an external boehm-gc. I can do that, but I do not want to do so with this patch. Andrew.

[PATCH] Delete GCJ

like to try it. Andrew. 2016-09-05 Andrew Haley <a...@redhat.com> * Makefile.def: Remove libjava. * Makefile.tpl: Likewise. * Makefile.in: Regenerate. * configure.ac: Likewise. * configure: Likewise. * gcc/java: Remove. * libjava: Li

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

On 26/07/16 15:37, Warren D Smith wrote: > --the reason I am suggesting this to this forum, is I probably am not capable > of > recoding GCC myself. > Why not learn from your own history, and do that again, with these two > extensions? > (And in the case of uint4_t, it actually would not even BE

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

On 26/07/16 14:31, Warren D Smith wrote: > However, why not provide access to double-precision multiply and > add-with-carry (subtract with borrow? shift-left?) in the same fashion? >twofer x = mul(a,b); would cause x.hi and x.lo to be computed. >twofer x = addwithcarry(a,b) ditto.

Re: Symbian support

On 25/07/16 14:17, fedor...@mail.ru wrote: > I build for arm cpu. How write this function? Where I can see example > implementation? GCC builded with multilib support. If your ARM cpu has only one core, the function can be empty. If it has more than one core, then you must tell GCC which model

Re: Symbian support

On 25/07/16 12:37, fedor...@mail.ru wrote: > GCC 6.1.0 inserts call to __sync_synchronize and linker fails with > error: undefined reference to `__sync_synchronize'. If this is bug I > can send preprocessed file. This is something that you can provide yourself. If it's a single-core cpu the

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

On 04/07/16 14:43, Jonathan Wakely wrote: > It doesn't matter how much warning people have to fix such things, > most of them won't do it. Then at the last minute some poor person has > to spend days or weeks going through other people's code fixing all > the problems... ...and breaking

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

On 22/06/16 09:59, Florian Weimer wrote: > 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 ve

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

On 21/06/16 17:43, Jeff Law wrote: > I think there's enough resistance to deprecating basic asms within a > function that we should probably punt that idea. > > I do think we should look to stomp out our own uses of basic asms > within functions just from a long term maintenance standpoint. > >

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

Hi, On 21/06/16 13:08, Michael Matz wrote: > On Tue, 21 Jun 2016, Andrew Haley wrote: > >>> As said in the various threads about basic asms, all correctness >>> problems can be solved by making GCC more conservative in handling >>> them (or better said

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

Hi, On 20/06/16 19:01, Michael Matz wrote: > On Mon, 20 Jun 2016, 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. >

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

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 because they don't declare their dependencies and

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

On 20/06/16 15:52, Segher Boessenkool wrote: > On Mon, Jun 20, 2016 at 03:49:19PM +0100, Andrew Haley wrote: >> On 20/06/16 15:42, Segher Boessenkool wrote: >>> On Mon, Jun 20, 2016 at 02:55:58PM +0100, Andrew Haley wrote: >>>> On 20/06/16 14:50, Segher Boessen

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

On 20/06/16 15:42, Segher Boessenkool wrote: > On Mon, Jun 20, 2016 at 02:55:58PM +0100, Andrew Haley wrote: >> On 20/06/16 14:50, Segher Boessenkool wrote: >>> If basic asm is deprecated, that means some time later it will be >>> removed, at which time an asm without :

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

On 20/06/16 14:50, Segher Boessenkool wrote: > If basic asm is deprecated, that means some time later it will be > removed, at which time an asm without : can be used as extended asm Not exactly: it'd be an asm with no inputs, no outputs, and no clobbers i.e. no effects. Andrew.

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

On 20/06/16 08:00, Andrew Pinski wrote: > + /* Acceptable. */ > + asm (" "); /* { dg-warning "Deprecated: asm in function without > extended syntax" } */ This is incorrect English. It should be "Deprecated: asm without extended syntax in function" because it's the asm that is missing the

Re: [DOC PATCH] Rewrite docs for inline asm

On 04/04/14 20:48, dw wrote: > I do not have write permissions to check this patch in. We must fix that. Andrew.

Re: [PATCH] Make basic asm implicitly clobber memory

On 05/20/2016 07:50 AM, David Wohlferd wrote: > At a minimum, suddenly forcing an unexpected/unneeded memory clobber > can adversely impact the optimization of surrounding code. This can > be particularly annoying if the reason for the asm was to improve > performance. And adding a memory

Re: GNU C: Implicit int and implicit function definitions

On 05/20/2016 10:02 AM, Florian Weimer wrote: > 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

Re: [PATCH] Make basic asm implicitly clobber memory

On 06/05/16 07:35, David Wohlferd wrote: > 1) I'm not clear precisely what problem this patch fixes. It's true > that some people have incorrectly assumed that basic asm clobbers > memory and this change would fix their code. But some people also > incorrectly assume it clobbers registers. I

Re: Please, take '-Wmisleading-indentation' out of -Wall

On 05/05/2016 07:56 PM, Antonio Diaz Diaz wrote: > Take this example http://gcc.gnu.org/ml/gcc-patches/2016-03/msg00261.html > > The user sees this: > >if (flagA) // GUARD > foo (0); // BODY > #if SOME_CONDITION_THAT_DOES_NOT_HOLD >if (flagB) > #endif > foo (1); // NEXT

Re: [patch] Don't encode the minor version in the gcj abi version

On 04/28/2016 12:45 PM, Matthias Klose wrote: > yes, that looks good. Can't approve it myself. OK. Andrew.

Re: [patch] Don't encode the minor version in the gcj abi version

On 28/04/16 08:55, Matthias Klose wrote: > Ok for the 6 branch and the trunk? OK, Andrew.

Re: [PATCH] [AArch64] support -mfentry feature for arm64

On 04/19/2016 03:37 PM, Pedro Alves wrote: > On 04/19/2016 02:25 PM, Andrew Haley wrote: >> On 04/19/2016 02:19 PM, Michael Matz wrote: >> >>> Well, yeah, that's traditional insn caches on multiple cores. From >>> user space you need kernel help for this,

Re: [PATCH] [AArch64] support -mfentry feature for arm64

On 04/19/2016 02:19 PM, Michael Matz wrote: > Well, yeah, that's traditional insn caches on multiple cores. From > user space you need kernel help for this, doing interprocess > interrupts to flush all such buffers on all cores (or at least those > potentially fetching stuff in the patched

Re: [PATCH] [AArch64] support -mfentry feature for arm64

On 18/04/16 18:34, Michael Matz wrote: > Hi, > > On Mon, 18 Apr 2016, Andrew Haley wrote: > >>>> That may not be safe. Consider an implementation which looks >>>> ahead in the instruction stream and decodes the instructions >>>> speculatively. &

Re: [PATCH] [AArch64] support -mfentry feature for arm64

On 04/18/2016 06:13 PM, Michael Matz wrote: > On Mon, 18 Apr 2016, Andrew Haley wrote: > >> On 04/15/2016 06:29 PM, Alexander Monakov wrote: >> >>> Alternatively: replace first nop with a short forward branch that >>> jumps over the rest of the pad, patch re

Re: [PATCH] [AArch64] support -mfentry feature for arm64

On 04/15/2016 06:29 PM, Alexander Monakov wrote: > Alternatively: replace first nop with a short forward branch that > jumps over the rest of the pad, patch rest of the pad, patch the > initial forward branch. That may not be safe. Consider an implementation which looks ahead in the instruction

Re: [wwwdocs,Java] Remove java/status.html

On 17/04/16 17:09, Gerald Pfeifer wrote: > My recommendation is to handle that via java/index, which is the > main page, and redirect other GCJ pages to that one as we remove > them. > > Like in the following, for java/status.html. > > Are you fine with that? OK, thanks. Andrew.

Re: guide me

On 17/04/16 17:58, J a h a n z e b F a h i m wrote: > i am a java developer, i want to install gnu java compiler on LINUX > 7.2 for testing purpose. i already have gcc version 4.8.5 20150623 > (Red Hat 4.8.5-4) (GCC) in my machine. now i want to add gcj in it. > how can i install it? It's going

Re: [wwwdocs,Java] java/index.html -- fix formatting on gcc.gnu.org

On 16/04/16 21:31, Gerald Pfeifer wrote: > On Sun, 10 Apr 2016, Andrew Hughes wrote: >>> That said, looking at the page, and how since 2005 nearly all changes >>> have been maintainance ones from me, is it really worthwhile keeping >>> this (short of historic reasons)? >> I guess the next news

Re: Spurious register spill with volatile function argument

On 27/03/16 06:57, Michael Clark wrote: > GCC, Clang folk, any ideas on why there is a stack spill for a > volatile register argument passed in esi? Does volatile force the > argument to have storage allocated on the stack? Is this a corner > case in the C standard? This argument in the x86_64

Re: Warning for converting (possibly) negative float/double to unsigned int

On 27/02/16 11:53, Jakub Jelinek wrote: > On Sat, Feb 27, 2016 at 10:39:59AM +0000, Andrew Haley wrote: >> On 26/02/16 21:28, Bradley Lucier wrote: >>> Any advice on how to proceed? I'd be willing to write and test the few >>> lines of code myself if I knew where

Re: Warning for converting (possibly) negative float/double to unsigned int

On 26/02/16 21:28, Bradley Lucier wrote: > Any advice on how to proceed? I'd be willing to write and test the few > lines of code myself if I knew where to put them. The best thing, rather than warning, would be to define this conversion as a GCC extension and implement it consistently

Re: Placement new versus flifetime-dse

On 02/16/2016 01:16 PM, Jakub Jelinek wrote: >> > Can someone please tell me Chapter and Verse in the standard, please? >> > Then I can close this one. > I'd think [basic.life] describes this. For the record, I found it in C++98 [class.cdtor]: For an object of non-POD class type ... before the

Placement new versus flifetime-dse

I'm fixing a bug which involves initialization of a field of an object in its placement new function before the constructor is called. This is falling foul of DSE, which deletes the field initialization. I see this: @item -fno-lifetime-dse @opindex fno-lifetime-dse In C++ the value of an

Re: GCC-Bridge: A Gimple Compiler targeting the JVM

On 02/02/2016 05:41 PM, Manuel López-Ibáñez wrote: > Everything is possible! Not sure how hard it would be, though. As > said, GJC, the Java FE, was doing something similar sometime ago, but > it has perhaps bit-rotted now. It is doing something the other way around: bytecode to Gimple. Andrew.

Re: [patch] [java] bump libgcj soname

On 03/01/16 15:52, Matthias Klose wrote: > No, libgcj versions up to 4.9.3 didn't change the value for releases taken > from > the same branch. All of 4.9.0, 4.9.1, 4.9.2, 4.9.3 have the same > GCJ_CXX_ABI_VERSION. But 5.1, 5.2 and 5.3 have *different* > GCJ_CXX_ABI_VERSIONs. > >> > Why

Re: [patch] [java] bump libgcj soname

On 03/01/16 11:38, Matthias Klose wrote: > On 02.01.2016 17:11, Andrew Haley wrote: >> On 02/01/16 15:53, Matthias Klose wrote: >>>>> In any case, GCJ_CXX_ABI_VERSION should be changed to not include >>>>> __GNUC_MINOR__ >>>>>>> anymore.

Re: [patch] [java] bump libgcj soname

On 02/01/16 14:40, Matthias Klose wrote: > > preparing for a test rebuild of the archive, and trying to run gcj-dbtool > (from > GCC 5) with libgcj16 (from GCC 6): > > $ gcj-dbtool -n /tmp/foo.db > libgcj failure: gcj linkage error. > Incorrect library ABI version detected. Aborting. > >

Re: [patch] [java] bump libgcj soname

On 02/01/16 15:53, Matthias Klose wrote: >>> In any case, GCJ_CXX_ABI_VERSION should be changed to not include >>> __GNUC_MINOR__ >>> >> anymore. Maybe for the gcc-5-branch, set it unconditionally to 3 so >>> >> that it >>> >> won't change anymore with future releases from the gcc-5 branch? >>

Re: gcc-4.9.1 generating different code between two successive builds

On 30/12/15 15:33, Georg-Johann Lay wrote: > Some parts of the compiler use the address of objects to compute > hashes, but I don't remember which part(s) actually do this. That > technique can lead to different code for different runs of the > compiler even on the same system. This is hard to

Re: basic asm and memory clobbers - Proposed solution

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 just fine. Andrew.

  1   2   3   4   5   6   7   8   9   10   >