don't complain about undefined env vars in self specs on gcc -v

K to commit ? Thanks in advance, With Kind Regards, Olivier 2017-06-09 Olivier Hainque <hain...@adacore.com> * gcc.c (process_command): When deciding if undefined variables should be ignored when processing specs, accept "gcc -v" as well. undef-var-gcc-v.diff Description: Binary data

fix libgcc build on VxWorks, missing -I for wrn/coreip

oned error. This might be turn out only a temporary measure pending results of further discussions on other aspects regarding the workarounds for the header file name conflicts, but this is all very intricate and I find it easier to proceed incrementally. With Kind Regards, Olivier 2017-06-08 Olivier Hain

Re: add VxWorks specific crtstuff implementation files for Ada runtimes

> On 06 Jun 2017, at 23:02, Olivier Hainque <hain...@adacore.com> wrote: >> + * Copyright (C) 2016, Free Software Foundation, Inc. >> >> Date update? About to commit the attached patch, to convey the year during which the sources entered the tree.

Re: add VxWorks specific crtstuff implementation files for Ada runtimes

Hi Nathan, > On Jun 5, 2017, at 12:58 , Nathan Sidwell <nat...@acm.org> wrote: > > On 06/02/2017 11:58 AM, Olivier Hainque wrote: >> Hello, > >> 2017-06-02 Olivier Hainque <hain...@adacore.com> >> ada/ >> * vx_crtbegin_aut

add missing value to gthread_once return statement for VxWorks

Committing as obvious. With Kind Regards, Olivier 2017-06-02 Olivier Hainque <hain...@adacore.com> libgcc/ * config/vxlib.c (__gthread_once): Add missing value to a nested return statement. vxlib-return.diff Description: Binary data

add VxWorks specific crtstuff implementation files for Ada runtimes

proceeds through after the change. Olivier 2017-06-02 Olivier Hainque <hain...@adacore.com> ada/ * vx_crtbegin_auto.c: New file. * vx_crtbegin.c: New file. * vx_crtbegin.inc: New file. * vx_crtend.c: New file. ada-vxcrt.diff Description: Binary data

Re: DWARF unwind info is supported on VxWorks

> On Jun 2, 2017, at 16:43 , Olivier Hainque <hain...@adacore.com> wrote: > > VxWorks has had support for dwarf unwinding for many years now. This patch > adjusts our configuration accordingly. A few extra details: I noticed this while trying to build an Ada runtim

DWARF unwind info is supported on VxWorks

VxWorks has had support for dwarf unwinding for many years now. This patch adjusts our configuration accordingly. 2017-06-02 Olivier Hainque <hain...@adacore.com> * config/vx-common.h (DWARF_UNWIND_INFO): Switch #define to 1. vx-unwind.diff Description: Binary data

fix libgcc build for VxWorks

r changes (preparing the submission of VxWorks 7 ports for a few targets). With Kind Regards, Olivier 2017-05-30 Olivier Hainque <hain...@adacore.com> libgcc/ * config/t-vxworks (LIBGCC2_INCLUDES): Remove extraneous dollar sign before $(MULTIDIR). vx-multidi

Re: Obsolete powerpc*-*-*spe*

> On Mar 15, 2017, at 15:26 , Segher Boessenkool > wrote: > I do not think VLE can get in, not in its current shape at least. VLE > is very unlike PowerPC in many ways so it comes at a very big cost to > the port (maintenance and otherwise -- maintenance is what I

Re: Obsolete powerpc*-*-*spe*

Hello Andrew, > On Mar 13, 2017, at 19:01 , Andrew Jenner wrote: > > I volunteer to be the point of contact for the SPE port. > > Over here at CodeSourcery/Mentor Embedded, we have a strong interest in SPE > *not* being deprecated (we actively ship toolchain products

Re: fix spurious error from switch-conversion on overaligned types

> On Mar 10, 2017, at 10:20 , Richard Biener wrote: > >> Is this one OK ? > > Ok. Committing, thanks!

Re: fix spurious error from switch-conversion on overaligned types

> Yes, unconditionally. Here's an adjusted patch, pleasantly simpler indeed (thanks again for the suggestion). Test passes fine as well. Is this one OK ? Olivier * tree-switch-conversion (array_value_type): Start by resetting candidate type to it's main variant.

Re: fix spurious error from switch-conversion on overaligned types

> On 09 Mar 2017, at 16:16, Richard Biener wrote: > > I think a simpler fix, doing > > type = TYPE_MAIN_VARIANT (type); > > should work equally well. Hmm, indeed. Thanks for the super fast review and suggestion. You meant that we can do that unconditionally

fix spurious error from switch-conversion on overaligned types

introduced on Mar 2015 for PR 65310, to fix a regression a previous change on the PR exposed against PR 50819. We see the the spurious error on our gcc-6 based compilers, not on those based on gcc-4.9 so this qualifies as a regression I think. OK to commit ? Thanks in advance! With Kind Regards,

Re: Obsolete powerpc*-*-*spe*

> On 21 Feb 2017, at 17:14, David Edelsohn wrote: > > Hi, Olivier > > There are three main areas that require attention: > > 1) Regular builds of the SPE configuration and regular GCC testsuite > runs that are reported to the gcc-testsuite mailing list. > > 2) Timely

Re: Obsolete powerpc*-*-*spe*

Hi David, > On Feb 17, 2017, at 01:10 , David Edelsohn wrote: > > This is not a new issue. The maintainer did not suddenly resign last > week. There have been numerous efforts to reach out to the SPE > community for over a *decade*, cajoling them to step up with >

Re: Obsolete powerpc*-*-*spe*

Hi Segher, > On Feb 14, 2017, at 04:07 , Segher Boessenkool > wrote: > > Hi all, > > I propose to mark powerpc*-*-*spe* as obsolete in GCC 7. This includes > the spe.h installed header file, all the __builtin_spe* intrinsics, the > -mfloat-gprs= command-line

Re: Oliver Hainque as co-maintainer of the VxWorks port.

> On Sep 26, 2016, at 14:15 , Ramana Radhakrishnan > wrote: > > I am pleased to announce that the GCC Steering Committee has > appointed Oliver Hainque as co-maintainer for the VxWorks port. > > Please join me in congratulating Oliver on his new role. > > Oliver,

Re: fix libsanitizer build on ppc-linux

> On 29 Apr 2016, at 12:42, Olivier Hainque <hain...@adacore.com> wrote: > > I'll discuss with the compiler-rt folks. The change just went in upstream. http://reviews.llvm.org/D19799. Olivier

Re: fix libsanitizer build on ppc-linux

> On Apr 29, 2016, at 10:34 , Jakub Jelinek wrote: > > > No, for these files we aren't upstream and just periodically merge stuff > from there. So, you should try to discuss this in asan upstream and get > a fix committed there and we can then merge it and/or cherry-pick it.

fix libsanitizer build on ppc-linux

; ... The attach patch fixes this, and bootstrap+regtests fine on x86_64-linux. OK to commit ? Thanks in advance, With Kind Regards, Olivier 2016-04-29 Olivier Hainque <hain...@adacore.com> libsanitizer/ * sanitizer_common/sanitizer_platform_limits_linux.cc: #i

Re: rs6000 stack_tie mishap again

> On Apr 15, 2016, at 18:42 , Jeff Law wrote: >> /* (mem:BLK (scratch)) is a special mechanism to conflict with everything. >> This is used in epilogue deallocation functions. */ > *That's* the one I was looking for :-) :-) >> Yes, I pondered this one and thought

Re: rs6000 stack_tie mishap again

> On Apr 15, 2016, at 00:42 , Segher Boessenkool > wrote: > >> >> Something like the attached patch, at least for next stage1 until the >> more general issue is sorted out ? > > It's a bit heavy; as a workaround, we may want this clobber in the stack >

Re: rs6000 stack_tie mishap again

> On Apr 15, 2016, at 06:37 , Andreas Krebbel > wrote: >> /* (mem:BLK (scratch)) is a special mechanism to conflict with everything. >> This is used in epilogue deallocation functions. */ >> ... > > Ok thanks. I've verified that the dependencies are also

Re: rs6000 stack_tie mishap again

> On 14 Apr 2016, at 18:50, Jeff Law wrote: > > I thought we had code to handle this case specially, but I can't immediately > find it in sched-deps.c. Unless I misunderstood what you were exactly looking for, the special code is in alias.c. E.g. write_dependence_p: /*

Re: rs6000 stack_tie mishap again

> On Mar 28, 2016, at 19:41 , Richard Henderson wrote: > > But I expect for stage4, the best solution is to strengthen the stack_tie > pattern to block all memory. Early scheduling of the stack frame > deallocation (a simple logic insn) can't really be that important to >

Re: rs6000 stack_tie mishap again

> On Apr 8, 2016, at 17:37 , Segher Boessenkool <seg...@kernel.crashing.org> > wrote: > > On Fri, Apr 08, 2016 at 10:24:50AM +0200, Olivier Hainque wrote: >>> But I expect for stage4, the best solution is to strengthen the stack_tie >>> pattern to

Re: rs6000 stack_tie mishap again

Hello Richard & Alan, Thanks for your feedback. Back on it after a few extra experiments. > On Mar 28, 2016, at 19:41 , Richard Henderson wrote: > >> Let's see what rth thinks. He did say the patch might need to be >> redone. :) >>

Re: rs6000 stack_tie mishap again

Hello Segher, > On Mar 28, 2016, at 13:18 , Segher Boessenkool > wrote: > >> You need to have had r11 last used to designate a global >> symbol as part of the function body (in order to have base_term >> designate a symbol_ref etc), and then have the scheduler >>

Re: rs6000 stack_tie mishap again

> On Mar 28, 2016, at 05:01 , Segher Boessenkool > wrote: > > The normal -m32 compiler here generates code like > > lwz 11,0(1) > > and try as I might I cannot get it to fail. Maybe because the GPR11 > setup here involves a load? You need to have had r11

Re: rs6000 stack_tie mishap again

Hello Alan, > On 24 Mar 2016, at 05:10, Alan Modra wrote: > >>if (could_be_prologue_epilogue >>&& prologue_epilogue_contains (insn)) >> continue; > https://gcc.gnu.org/ml/gcc-patches/1999-08n/msg00048.html Ah, interesting,

Re: rs6000 stack_tie mishap again

> On 24 Mar 2016, at 05:58, Alan Modra wrote: > > On Wed, Mar 23, 2016 at 01:38:26PM -0400, David Edelsohn wrote: >> The description and >> references to prior SPE prologue and epilogue changes do not confirm a >> wider problem. > > There's a good chance this affects ABI_V4

rs6000 stack_tie mishap again

so obvious. So, aside from the dependency issue which needs to be fixed somehow, I think it would make sense to consider using a strong blockage mecanism in expand_epilogue. Thoughts ? Thanks in advance for your feedback, With Kind Regards, Olivier - 2016-03-23 Olivier Hainque <ha

Re: prevent "undef var" errors on gcc --help or --version

Hello Bernd, Thanks for your feedback on this :-) > On 11 Jan 2016, at 17:09, Bernd Schmidt <bschm...@redhat.com> wrote: > > On 01/08/2016 02:23 PM, Olivier Hainque wrote: >> + /* Undefined variable references in specs are harmless if >> + we're running fo

Re: prevent "undef var" errors on gcc --help or --version

> On 12 Jan 2016, at 17:14, Bernd Schmidt wrote: > > I think you can do without the outer braces. Ok with those removed. Great! Thanks for the review and comments. With Kind Regards, Olivier

[ping] fix VXWORKS_LIBGCC_SPEC not to include -lc_internal for shared rtps

Hello, Ping for https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02028.html > * config/vxworks.h (VXWORKS_LIBGCC_SPEC): Don't link shared RTPs with > libc_internal. Thanks in advance, With Kind Regards, Olivier

prevent "undef var" errors on gcc --help or --version

Olivier Hainque <hain...@adacore.com> * gcc.c (spec_undefvar_allowed): New global. (process_command): Set to true when running for --version or --help alone, or together. (getenv_spec_function): When the variable is not defined, use the variabl

Re: [ping] fix VXWORKS_LIBGCC_SPEC not to include -lc_internal for shared rtps

> On Jan 8, 2016, at 15:17 , Nathan Sidwell wrote: >>> * config/vxworks.h (VXWORKS_LIBGCC_SPEC): Don't link shared RTPs with >>> libc_internal. > ok Great! Thanks for your prompt feedback Nathan :-)

Re: adjust fallback_frame_state for 32bits AIX 7.1

with what is already there, and we >> thought >> it might be useful to others as well. >> >> OK to commit ? >> >> 2015-01-05 Olivier Hainque <hain...@adacore.com> >> >> libgcc/ >>* config/rs6000/aix-unwind.h (ucontext_for): Handle AIX 7.1 >>specificities. > > Okay. Thanks!

adjust fallback_frame_state for 32bits AIX 7.1

kernels at this stage, unfortunately), this is nevertheless an improvement on 32bits. The patch is very short and in line with what is already there, and we thought it might be useful to others as well. OK to commit ? 2015-01-05 Olivier Hainque <hain...@adacore.com> libgcc/ * config/

fix VXWORKS_LIBGCC_SPEC not to include -lc_internal for shared rtps

now, and I checked that a mainline compiler configured for powerpc-wrs-vxworks builds after the change. OK to commit ? 2015-12-22 Olivier Hainque <hain...@adacore.com> * config/vxworks.h (VXWORKS_LIBGCC_SPEC): Don't link shared RTPs with libc_internal. link-shared-rtp.

[visium] skip block move insn test on gr5

Block move insns are specific to gr6. They aren't available at all on gr5. Committing to mainline with offline agreement from Eric. Olivier 2015-12-14 Olivier Hainque <hain...@adacore.com> testsuite/ * gcc.target/visium/block_move.c: Skip for gr5. skip-bmd-gr5.diff Descr

[Ada] Introduce a Frontend_Exceptions flag in system.ads

Hello, The Ada compiler supports different sorts of exception schemes today. The two most commonly used are what we commonly refer to as "frontend-sjlj", and "gcc-zcx". The former is entirely managed by the front-end (gigi included), relying on builtin_setjmp / builtin_longjmp pairs. The latter

Re: [Ada] Introduce a Frontend_Exceptions flag in system.ads

> On Nov 23, 2015, at 12:02 , Olivier Hainque <hain...@adacore.com> wrote: > Then all the system.ads files will be updated with a correct value of the > Frontend_Exceptions flags. Here's the patch. eh-flags-rts.diff Description: Binary data

[Ada] handle 'Code_Address on targets with function descriptors

this, relying on a tm definition that we'll be submitting later on. With everything in place, the testcase below is expected to display OK. Bootstrapped and regtested on x86_64-pc-linux-gnu Olivier 2015-03-12 Olivier Hainque hain...@adacore.com * gcc-interface/trans.c (Attribute_to_gnu

Re: [patch] powerpc-vxworksmils port, variant of powerpc-vxworksae

On Jan 19, 2015, at 16:06 , Gerald Pfeifer ger...@pfeifer.com wrote: This looks sweet, thank you! My pleasure, just checked-in. Thanks for your note and feedback :-)

Re: [patch] powerpc-vxworksmils port, variant of powerpc-vxworksae

Hi Gerald, this feels a little too small for an announcement on our home page, but would you mind adding something to gcc-5/changes.html? Sure. (Or suggest some wording for that page and I'll take care.) Something like the attached patch ? wwwdocs/htdocs/gcc-5/ *

Re: [ping] account for register spans in expand_builtin_init_dwarf_reg_sizes

On Dec 4, 2014, at 23:14 , Jason Merrill ja...@redhat.com wrote: On 11/24/2014 03:08 AM, Olivier Hainque wrote: + if (init_state-processed_regno[regno]) +return; I would expect this to go in the loop in expand_builtin_init_dwarf_reg_sizes, before we look up a span for the regno

[ping] account for register spans in expand_builtin_init_dwarf_reg_sizes

Hi Jason, ping for https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02975.html, a proposal to address comments you made on a patch I had sent earlier on. The attached patches combined bootstrap and regtest fine on x86_64-linux. We also have nominal test results with our 4.9 based series of

Re: [ping] account for register spans in expand_builtin_init_dwarf_reg_sizes

On Nov 18, 2014, at 16:21 , Olivier Hainque hain...@adacore.com wrote: On Nov 18, 2014, at 03:29 , Jason Merrill ja...@redhat.com wrote: What happens when the outer loop hits a register that we've already seen as part of a span? I have a candidate improvement to prevent processing the same

Re: [patch] fix expand_builtin_init_dwarf_reg_sizes wrt register spans

On Nov 18, 2014, at 04:01 , Jeff Law l...@redhat.com wrote: Best for Jason, Richard or Jakub. My knowledge of dwarf2 and our implementation in dwarf*out.c is minimal at best. Thanks for your answer Jeff. Richard Jason have provided feedback (thanks for this as well :) on which I'll

Re: [ping] account for register spans in expand_builtin_init_dwarf_reg_sizes

On Nov 18, 2014, at 03:29 , Jason Merrill ja...@redhat.com wrote: What happens when the outer loop hits a register that we've already seen as part of a span? Hmm, I was under the impression that this was supposed never to happen. I can see that this is not so clear though. What would

[ping*3] fix unwinding on e500 processors

Hello, ping for https://gcc.gnu.org/ml/gcc-patches/2014-10/msg03264.html TIA for your feedback, Olivier On Oct 31, 2014, at 11:31 , Olivier Hainque hain...@adacore.com wrote: Hello, ping for https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01369.html a proposal to repair unwinding

Re: [patch] fix expand_builtin_init_dwarf_reg_sizes wrt register spans

Hi David, Thanks for your support :) Note that the DWARF_REG_TO_UNWIND_COLUMN part is essentially a noop today and is not necessary to fix the breakage. It's just something that ISTM should be there in principle. Olivier On Nov 17, 2014, at 16:56 , David Edelsohn dje@gmail.com wrote:

Re: GCC 5.0 Status Report (2014-11-03), Stage 1 ends Nov 15th

Hello Jakub, On Nov 3, 2014, at 10:18 , Jakub Jelinek ja...@redhat.com wrote: The trunk is scheduled to transition from Stage 1 to Stage 3 at the end of Saturday, November 15th (use your timezone to your advantage) ... What larger merges are still planned for GCC 5? What else have been

[ping*2] fix unwinding on e500 processors

Hello, ping for https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01369.html a proposal to repair unwinding breakage on e500 targets. The url above is that of the first ping, where the originally submitted patch was splitted in two to facilitate review. The original submission, with a more

[ping] account for register spans in expand_builtin_init_dwarf_reg_sizes

(dwregspan.diff) 2014-10-15 Olivier Hainque hain...@adacore.com * dwarf2cfi.c (init_one_dwarf_reg_size): New helper, processing one particular reg for expand_builtin_init_dwarf_reg_sizes. (expand_builtin_init_dwarf_reg_sizes): Rework to use helper and account for dwarf register

Re: [i386] Replace builtins with vector extensions

Hello Marc, On Oct 9, 2014, at 12:33 PM, Marc Glisse wrote: If this is accepted, I will gladly prepare patches removing the unused builtins and extending this to a few more operations (integer vectors in particular). If this is not the direction we want to go, I'd like to hear it clearly

Re: [BUILDROBOT] Ada broken

On Oct 3, 2014, at 06:15 , Jan Hubicka hubi...@ucw.cz wrote: I'm bisecting it (on powerpc64-linux, where it also shows up); it needs full bootstrapping every time, so will be another one to two hours. I just hope it isn't mine, that's going to be fun to debug :-) Nono, it is mine - the

Re: [ping*2] define CROSS = @CROSS@ in gcc/Makefile.in

On Sep 30, 2014, at 6:48 PM, Jeff Law wrote: * Makefile.in (CROSS): Define, to @CROSS@. OK. Jeff Thanks Jeff :-)

[patch] fix expand_builtin_init_dwarf_reg_sizes wrt register spans

for GPRs on powerpc-eabispe, then with bootstrap and regtest for languages=all,ada on x86_64-linux. OK to commit ? Thanks in advance for your feedback, With Kind Regards, Olivier 2014-09-30 Olivier Hainque hain...@adacore.com libgcc/ * unwind-dw2.c (DWARF_REG_TO_UNWIND_COLUMN): Move

[ping*2] define CROSS = @CROSS@ in gcc/Makefile.in

Hello, ping on https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00056.html Thanks in advance, With Kind Regards, Olivier On Sep 1, 2014, at 17:26 , Olivier Hainque hain...@adacore.com wrote: Hello, This patch is necessary for proper operation of a piece of the Ada Makefile fragment which

Re: [patch] flag .persistent.bss sections as bss

On Sep 19, 2014, at 01:22 , Jeff Law l...@redhat.com wrote: * varasm.c (default_section_type_flags): Flag .persistent.bss sections as SECTION_BSS. Ok. Jeff Thanks for this review and the other ones Jeff :-)

[patch] powerpc-vxworksmils port, variant of powerpc-vxworksae

Olivier Hainque hain...@adacore.com gcc/ * config.gcc (powerpc-wrs-vxworksmils): New configuration. * config/rs6000/t-vxworksmils: New file. * config/rs6000/vxworksmils.h: New file. libgcc/ * config.host (powerpc-wrs-vxworksmils): New configuration, same

[patch] normalize the x86-vxworks port organization

and VxWorksAE targets. The patch attached here applies on mainline and passes make all-gcc for --target=i686-wrs-vxworksae --enable-languages=c OK to commit ? Thanks in advance for your feedback, With Kind Regards, Olivier 2014-09-18 Olivier Hainque hain...@adacore.com * config/i386

Re: [patch] allowing configure --target=e500v[12]-etc

Hello Joseph, On Sep 16, 2014, at 23:01 , Joseph S. Myers jos...@codesourcery.com wrote: config.sub patches have to go to config-patches first, we only ever import the latest unmodified config.sub and config.guess from config.git, without making local changes. Ok, will start there then.

Re: [ping*3] fix build failure of x86_64-mingw32, missing crtbegin/crtend.o

Hello Kai, On Sep 17, 2014, at 10:52 , Kai Tietz ktiet...@googlemail.com wrote: Sorry for the delay in review. No problem at all. Thanks for your feedback :) Patch looks ok. Have you just tested -pc- variant, or also -w64- one? Just the -pc- variant, by our nightly builders. We

Re: [ping*3] fix build failure of x86_64-mingw32, missing crtbegin/crtend.o

On Sep 17, 2014, at 12:55 , Kai Tietz ktiet...@googlemail.com wrote: We probably could twist our configuration scripts to experiment the -w64- variant as well. Might take a bit of time though. Well, would be interesting. Yes, I agree. I'll open an internal discussion to pursue this

[ping] define CROSS = @CROSS@ in gcc/Makefile.in

Hello, ping on https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00056.html Thanks in advance, With Kind Regards, Olivier On Sep 1, 2014, at 17:26 , Olivier Hainque hain...@adacore.com wrote: Hello, This patch is necessary for proper operation of a piece of the Ada Makefile fragment which

[ping*3] fix build failure of x86_64-mingw32, missing crtbegin/crtend.o

Hello, Ping #3 for https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00237.html Thanks in advance for your feedback, With Kind Regards, Olivier On Jul 3, 2014, at 16:57 , Olivier Hainque hain...@adacore.com wrote: From gcc/i386/config/mingw32.h, STARTFILE_SPEC and ENDFILE_SPEC include

[patch] allowing configure --target=e500v[12]-etc

appropriate for proper ABI selection. We find this useful to have triplets like e500v2-wrs-vxworks or e500v2-wrs-linux work out of the box, and thought others might find it useful as well. OK to commit ? Thanks in advance for your feedback, Olivier 2014-09-16 Olivier Hainque hain

[patch] flag .persistent.bss sections as bss

on x86_64-linux. OK to commit ? Thanks in advance for your feedback, With Kind Regards, Olivier 2014-09-16 Olivier Hainque hain...@adacore.com * varasm.c (default_section_type_flags): Flag .persistent.bss sections as SECTION_BSS. persistent-bss.diff Description: Binary data

Re: [patch] prevent tree sinking of trapping stmts

On Sep 4, 2014, at 12:22 , Richard Biener richard.guent...@gmail.com wrote: So I tend to think that removing / delaying traps is ok unless you can catch them within the active EH scheme. Certainly that Oliver excludes loads/stores (but not integer division!) points at the fact that

[patch] prevent tree sinking of trapping stmts

quite a bit for no valid reason. Bootstrapped and regression tested on x86_64-linux-gnu. OK to commit ? Thanks in advance for your feedback, With Kind Regards, Olivier 2014-09-03 Olivier Hainque hain...@adacore.com * tree-ssa-sink.c (statement_sink_location): Don't sink !load-or-store

Re: [patch] prevent tree sinking of trapping stmts

Hi Richard, (Thanks for your feedback) On Sep 3, 2014, at 12:52 , Richard Biener richard.guent...@gmail.com wrote: I don't quite follow this reasoning. Why would a trapping FP operation not be undefined behavior without -fnon-call-exceptions? That is, don't you want to check

Re: [patch] prevent tree sinking of trapping stmts

On Sep 3, 2014, at 15:05 , Richard Biener richard.guent...@gmail.com wrote: Well, but that's a bug in the Ada frontend if it does exceptions behind GCCs back. I agree that this is a problem and that could_throw_p is a better predicate. I wasn't convinced by my own answer but hadn't really

Re: [patch] prevent tree sinking of trapping stmts

On Sep 3, 2014, at 15:27 , Richard Biener richard.guent...@gmail.com wrote: Eventually the FE can still simply set flag_exeptions / flag_non_call_exceptions? It will still not be correct for all cases but at least external throw predicates would work ... Yes, these would work. I have

Re: [patch] propagate INSTALL Makefile variables down from gcc/

On Aug 30, 2014, at 8:36 AM, Jeff Law wrote: * Makefile.in (FLAGS_TO_PASS): Propagate INSTALL, INSTALL_DATA, INSTALL_SCRIPT and INSTALL_PROGRAM as well. OK. Checked-in, Thanks :)

[patch] fix VXWORKSAE_TARGET_DIR not to designate a hardcoded /home subdir

gcc 4.7 based compiler series, checked that the patch works fine with gcc-4.9 and that it applies as-is on the current mainline. OK to commit ? Thanks in advance, With Kind Regards, Olivier 2014-09-01 Olivier Hainque hain...@adacore.com * config/vxworksae.h (VXWORKSAE_TARGET_DIR): Rely

Re: [patch] fix VXWORKSAE_TARGET_DIR not to designate a hardcoded /home subdir

On Sep 1, 2014, at 2:45 PM, Nathan Sidwell wrote: OK to commit ? Yes, thanks Done. Thanks for your super prompt feedback. Olivier

[patch] define CROSS = @CROSS in gcc/Makefile.in

and multiple targets in our local trees. Boostrapped reg-tested on x86_64-linux. OK to commit ? Thanks in advance for your feedback, Olivier 2014-09-01 Olivier Hainque hain...@adacore.com * Makefile.in (CROSS): Define, to @CROSS. mk-cross.diff Description: Binary data

[patch] propagate INSTALL Makefile variables down from gcc/

Hello, Experiments with custom install programs exposed that the INSTALL series of Makefile variables aren't propagated down from the gcc subdir. This patch fixes this. Checked that it addressed the unexpected behavior we were observing + bootstrapped regtested on x86_64-linux-gnu. OK to

Re: [ping*2] fix build failure of x86_64-mingw32, missing crtbegin/crtend.o

Hello, Ping #2 for https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00237.html Thanks in advance for your feedback, With Kind Regards, Olivier On Jul 3, 2014, at 16:57 , Olivier Hainque hain...@adacore.com wrote: From gcc/i386/config/mingw32.h, STARTFILE_SPEC and ENDFILE_SPEC include

[patch, ping] fix build failure of x86_64-mingw32, missing crtbegin/crtend.o

Hello, Ping for https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00237.html Thanks in advance for your feedback, With Kind Regards, Olivier On Jul 3, 2014, at 16:57 , Olivier Hainque hain...@adacore.com wrote: From gcc/i386/config/mingw32.h, STARTFILE_SPEC and ENDFILE_SPEC include crtbegin.o

[ping] Honor the vxworks options overrides on VxWorksae

Ping for https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02400.html Thanks in advance, With Kind Regards, Olivier On Jun 30, 2014, at 15:29 , Olivier Hainque hain...@adacore.com wrote: Hello, The vxworks_override_option code is general enough to apply to both regular VxWorks

Re: [ping] Honor the vxworks options overrides on VxWorksae

On Jul 29, 2014, at 18:18 , Nathan Sidwell nat...@acm.org wrote: 2014-05-30 Olivier Hainque hain...@adacore.com * config/vxworksae.h (VXWORKS_OVERRIDE_OPTIONS): Define. Ok, Great, thanks! thanks for the ping. Sure, no problem of course. Thanks for your prompt feedback

[patch] fix build failure of x86_64-mingw32, missing crtbegin/crtend.o

to completion after the change. OK to commit ? Thanks in advance for your feedback, With Kind Regards, Olivier 2014-07-02 Olivier Hainque hain...@adacore.com libgcc/ * config.host (x86_64-*-mingw*): Add i386/t-cygming to tmake_file and crtbegin.o + crtend.o to extra_parts

[patch] Honor the vxworks options overrides on VxWorksae

. Tested by verifying that the port still builds after the change, and that -fPIC without -mrtp is rejected as it should. OK to commit ? Thanks in advance, With Kind Regards 2014-05-30 Olivier Hainque hain...@adacore.com * config/vxworksae.h (VXWORKS_OVERRIDE_OPTIONS): Define.

Re: [patch] Honor the vxworks options overrides on VxWorksae

With the patch attached ... On Jun 30, 2014, at 15:29 , Olivier Hainque hain...@adacore.com wrote: Hello, The vxworks_override_option code is general enough to apply to both regular VxWorks and VxWorksAE configurations. The VxWorksAE configuration files miss the triggering bits, however

Re: [patch] improve sloc assignment on bind_expr entry/exit code

Hi Jeff, On Jun 17, 2014, at 22:42 , Jeff Law l...@redhat.com wrote: * tree-core.h (tree_block): Add an end_locus field, allowing memorization of the end of block source location. * tree.h (BLOCK_SOURCE_END_LOCATION): New accessor. * gimplify.c (gimplify_bind_expr):

Re: [patch] improve sloc assignment on bind_expr entry/exit code

On Jun 18, 2014, at 09:42 , Olivier Hainque hain...@adacore.com wrote: I assume y'all will add a suitable test to the Ada testsuite and propagate it into the GCC testsuite in due course? ISTM that dg-scan-asm for the expected extra .loc's would work, maybe restricted to some target we know

Re: [patch] improve sloc assignment on bind_expr entry/exit code

On Jun 18, 2014, at 15:48 , Jeff Law l...@redhat.com wrote: ISTM that dg-scan-asm for the expected extra .loc's would work, maybe restricted to some target we know produces .loc directives. Sounds appropriate ? Yea, that should be fine. Most folks test x86-64 linux, so that's going to

[patch] improve sloc assignment on bind_expr entry/exit code

.loc directives before the entry/exit code on the example. The patch also bootstraps and regtests fine for languages=all,ada on x86_64-pc-linux-gnu. OK to commit ? Thanks in advance for your feedback, With Kind Regards, Olivier -- 2014-06-11 Olivier Hainque hain...@adacore.com * tree

[patch] don't link shared RTPs with libc_internal.a on VxWorks

, Olivier 2014-06-11 Olivier Hainque hain...@adacore.com * config/vxworks.h (VXWORKS_LIBGCC_SPEC): Don't link shared RTPs with libc_internal. vxworks_libc_internal.diff Description: Binary data

Re: [patch] don't link shared RTPs with libc_internal.a on VxWorks

On Jun 11, 2014, at 17:49 , Olivier Hainque hain...@adacore.com wrote: * config/vxworks.h (VXWORKS_LIBGCC_SPEC): Don't link shared RTPs with libc_internal. Oops. I think I sent a bogus version of the patch, as the system libc.so embeds libgcc as well. Let me revisit. Olivier

Re: strengthen protection against REG_EQUIV/EQUAL on !REG set

* rtl.h (set_for_reg_notes): Declare. * emit-rtl.c (set_for_reg_notes): New function. (set_unique_reg_note): Use it. * optabs.c (add_equal_note): Likewise. This is fine. checked-in as revision 210998. Thanks Jeff :-) Olivier

Re: [patch] VxWorks configuration adjustments for powerpc 8548 (e500v2)

On May 27, 2014, at 5:27 PM, Nathan Sidwell wrote: ok Great! Committed as rev 211011. Thanks Nathan :-) Olivier

[patch] VxWorks configuration adjustments for powerpc 8548 (e500v2)

? Thanks much in advance for your feedback, With Kind Regards, Olivier 2014-05-27 Olivier Hainque hain...@adacore.com * config/rs6000/vxworks.h (VXCPU_FOR_8548): New. Default to PPC85XX. (CPP_SPEC): Add entry for -mcpu=8548. * config/rs6000/vxworksae.h: Reinstate. Override

strengthen protection against REG_EQUIV/EQUAL on !REG set

Hello, This is a follow up on a thread started long ago there: http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00967.html With a first followup and a patch proposal there: http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00731.html Then a refinement suggested by Richard Sandiford here:

<    1   2   3   4   5   6   7   >