[PATCH][committed][Fortran] Add a few new tests for -fdec-static and -fdec-structure

These are minor testsuite additions to the gfortran testsuite from engineers at Codethink (Mark Doffman and Jim MacArthur). I'm working with Codethink to help identify what, if any, of their work is still potentially relevant for our Fortran implementation. These tests seem like a no-brainer,

Re: [C++ PATCH] Fix ICE in reshape_init_class (PR c++/84874)

OK. On Thu, Mar 15, 2018 at 7:29 PM, Jakub Jelinek wrote: > Hi! > > As the testcase shows, even when we've already reshaped the initializer, if > it uses designated initializers and skips using those over others, we can > have field != d->cur->index. The following patch

Re: [C++ PATCH] Fix PLACEHOLDER_EXPR handling (PR c++/79937, PR c++/82410)

On Thu, Mar 15, 2018 at 7:33 PM, Jakub Jelinek wrote: > On Thu, Mar 15, 2018 at 04:50:57PM -0400, Jason Merrill wrote: >> > +/* Don't elide the initialization of TARGET_EXPR_SLOT for this >> > TARGET_EXPR. */ >> > +#define TARGET_EXPR_NO_ELIDE(NODE) (TARGET_EXPR_CHECK >> >

Re: [PATCH] PR fortran/69395 -- don't exceed max allowed array dimensions

On 03/14/2018 06:23 PM, Steve Kargl wrote: The attachedi patch detects situations where the sum of an array's rank and corank exceeds the maximum allowed by the Standard. Regression tested on x86_64-*-freebsd. 2018-03-14 Steven G. Kargl PR fortran/69395 *

Re: [C++ PATCH] Fix PLACEHOLDER_EXPR handling (PR c++/79937, PR c++/82410)

On Thu, Mar 15, 2018 at 03:33:12PM -0400, Jason Merrill wrote: > Folding away the INDIRECT_REF is fine. It's the TARGET_EXPR handling > that is wrong. Ah, ok. > > types of TARGET_EXPR, or ask some langhook whether it is ok to do so > > (say not ok if find_placeholders (t))? Or

Re: [C++ PATCH] Fix PLACEHOLDER_EXPR handling (PR c++/79937, PR c++/82410)

On Thu, Mar 15, 2018 at 04:50:57PM -0400, Jason Merrill wrote: > > +/* Don't elide the initialization of TARGET_EXPR_SLOT for this > > TARGET_EXPR. */ > > +#define TARGET_EXPR_NO_ELIDE(NODE) (TARGET_EXPR_CHECK > > (NODE)->base.private_flag) > > This should be specifically on the rhs of a

Re: [RFC Patch], PowerPC memory support pre-gcc9, patch #3

This patch moves the instructions for movdi (both 32-bit and 64-bit) into a separate rs6000_output_move_64bit function. As I'm starting to move more stuff to checking the addr_masks instead of doing a lot of if mode == MODE1 || mode == MODE2, etc. I realized that the mult-register types (complex

[patch, committed] fix nios2 thinko

Our friends at Altera spotted a bug in the Nios II backend that was causing different code to be generated randomly for functions involving taking the address of a symbol. The root of the problem was that in r255492 I goofed and introduced some uses of INTVAL that were not guarded by

Re: PING^3: [PATCH] x86: Force __x86_indirect_thunk_reg for function call via GOT

On Thu, Mar 15, 2018 at 2:03 PM, Jan Hubicka wrote: >> >> >>> in ix86_output_indirect_branch. Since this is performed during RTL >> >> >>> expansion, other instructions may be inserted between movl and >> >> >>> call/jmp. >> >> >>> Linker optimization isn't always possible. >> >

Re: PING^3: [PATCH] x86: Force __x86_indirect_thunk_reg for function call via GOT

> >> >>> in ix86_output_indirect_branch. Since this is performed during RTL > >> >>> expansion, other instructions may be inserted between movl and > >> >>> call/jmp. > >> >>> Linker optimization isn't always possible. > > > > I suppose we can just combine those into patterns if we want to

Re: PING^3: [PATCH] x86: Force __x86_indirect_thunk_reg for function call via GOT

On Thu, Mar 15, 2018 at 1:41 PM, Jan Hubicka wrote: >> On Sun, Mar 11, 2018 at 7:40 AM, H.J. Lu wrote: >> > On Mon, Mar 5, 2018 at 4:20 AM, H.J. Lu wrote: >> >> On Tue, Feb 27, 2018 at 11:39 AM, H.J. Lu wrote: >>

Re: [C++ PATCH] Fix PLACEHOLDER_EXPR handling (PR c++/79937, PR c++/82410)

On Thu, Mar 15, 2018 at 4:28 PM, Jakub Jelinek wrote: > On Thu, Mar 15, 2018 at 03:33:12PM -0400, Jason Merrill wrote: >> Folding away the INDIRECT_REF is fine. It's the TARGET_EXPR handling >> that is wrong. > > Ah, ok. > >> > types of TARGET_EXPR, or ask some langhook whether

Re: PING^3: [PATCH] x86: Force __x86_indirect_thunk_reg for function call via GOT

> On Sun, Mar 11, 2018 at 7:40 AM, H.J. Lu wrote: > > On Mon, Mar 5, 2018 at 4:20 AM, H.J. Lu wrote: > >> On Tue, Feb 27, 2018 at 11:39 AM, H.J. Lu wrote: > >>> For x86 targets, when -fno-plt is used, external functions are called

Re: [PATCH] PR fortran/78741 -- Detect clash of entry and subroutine name

On Thu, Mar 15, 2018 at 01:18:02PM -0700, Steve Kargl wrote: > The patch is fairly slef-explanatory. Well, it would be self-explanatory if I sent the right patch. (Two pathces touch same file). -- Steve Index: gcc/fortran/decl.c

Re: [PATCH] PR fortran/69395 -- don't exceed max allowed array dimensions

Hi Steve, The attachedi patch detects situations where the sum of an array's rank and corank exceeds the maximum allowed by the Standard. Regression tested on x86_64-*-freebsd. OK for trunk. Thanks for the patch! Regards, Thomas

[PATCH] PR fortran/78741 -- Detect clash of entry and subroutine name

The patch is fairly slef-explanatory. Regression tested on x86_64-*-freebsd. OK to commit? 2018-03-15 Steven G. Kargl PR fortran/78741 * decl.c (get_proc_name): Check for clash of entry name with subroutine name. 2018-03-15 Steven G. Kargl

Re: PING^3: [PATCH] i386: Don't generate alias for function return thunk

On Thu, Mar 15, 2018 at 12:54 PM, Jan Hubicka wrote: >> On Thu, Mar 15, 2018 at 10:47 AM, Jan Hubicka wrote: >> >> On Thu, Mar 15, 2018 at 9:03 AM, Jan Hubicka wrote: >> >> >> > What is the reason for using different names for return and indirect

Re: [PATCH] Fix call expansion ICE (PR c++/79085)

LGTM. On Thu, Mar 15, 2018 at 3:25 PM, Jakub Jelinek wrote: > Hi! > > The following testcase ICEs on arm (or other strict alignment targets). > The problem is we have a call that returns a TREE_ADDRESSABLE type, > and the lhs of the call is some memory that isn't known to be

Re: PING^3: [PATCH] i386: Don't generate alias for function return thunk

> On Thu, Mar 15, 2018 at 10:47 AM, Jan Hubicka wrote: > >> On Thu, Mar 15, 2018 at 9:03 AM, Jan Hubicka wrote: > >> >> > What is the reason for using different names for return and indirect > >> >> > thunks at first place? > >> >> > > >> >> > >> >> These 2

Re: [C++ PATCH] Fix PLACEHOLDER_EXPR handling (PR c++/79937, PR c++/82410)

On Thu, Mar 15, 2018 at 01:15:53PM -0400, Jason Merrill wrote: > > g++.dg/cpp0x/nsdmi13.C ICEs without that, we have there: > > a = A({}); > > and build_over_call does: > > 8163 else if (tree_int_cst_equal (TYPE_SIZE (type), TYPE_SIZE > > (as_base))) > > 8164{ > > 8165

[PATCH] Fix reassoc with -frounding-math or IBM long double (PR tree-optimization/84841)

Hi! If any argument of * is negated, reassoc adds an artificial -1.0 multiplier. The code then relies on folding at least all those artificial multipliers through const_binop. That function can fail if the result is inexact for -frounding-math or for composite modes, and we only try to

[PATCH] Don't RTL DCE REG_CFA_RESTORE noop moves (PR debug/84875)

Hi! The following testcase ICEs on s390x-linux, because we have 2 registers saved in prologue, but only one of them modified in one path and then both restored there; cprop_hardreg propagates the saving register into the REG_CFA_RESTORE insn, making it a noop move (we don't really need to restore

Re: [C++ PATCH] Fix PLACEHOLDER_EXPR handling (PR c++/79937, PR c++/82410)

On Thu, Mar 15, 2018 at 1:59 PM, Jakub Jelinek wrote: > On Thu, Mar 15, 2018 at 01:15:53PM -0400, Jason Merrill wrote: >> > g++.dg/cpp0x/nsdmi13.C ICEs without that, we have there: >> > a = A({}); >> > and build_over_call does: >> > 8163 else if (tree_int_cst_equal

[PATCH] Fix call expansion ICE (PR c++/79085)

Hi! The following testcase ICEs on arm (or other strict alignment targets). The problem is we have a call that returns a TREE_ADDRESSABLE type, and the lhs of the call is some memory that isn't known to be sufficiently aligned. expand_call in that case allocates a temporary, lets the call return

Re: libgo patch committed: Force LANG=C when looking for compiler version

On Thu, Mar 15, 2018 at 11:24 AM, Andreas Schwab wrote: > On Mär 15 2018, Ian Lance Taylor wrote: > >> On Thu, Mar 15, 2018 at 10:10 AM, Andreas Schwab >> wrote: >>> On Mär 15 2018, Ian Lance Taylor wrote: >>>

[PING][PATCH v3 1/14] D: The front-end (DMD) language implementation and license.

On 17 February 2018 at 16:08, Iain Buclaw wrote: > On 25 October 2017 at 03:06, Jeff Law wrote: >> On 10/18/2017 01:33 AM, Iain Buclaw wrote: >>> On 6 October 2017 at 14:51, Ian Lance Taylor wrote: On Fri, Oct 6, 2017 at 1:34 AM,

Re: libgo patch committed: Force LANG=C when looking for compiler version

On Mär 15 2018, Ian Lance Taylor wrote: > On Thu, Mar 15, 2018 at 10:10 AM, Andreas Schwab > wrote: >> On Mär 15 2018, Ian Lance Taylor wrote: >> >>> + env = append(env, "LANG=C") >> >> You should use LC_ALL=C instead. > > Does it

Re: PING^3: [PATCH] i386: Don't generate alias for function return thunk

> On Thu, Mar 15, 2018 at 10:47 AM, Jan Hubicka wrote: > >> On Thu, Mar 15, 2018 at 9:03 AM, Jan Hubicka wrote: > >> >> > What is the reason for using different names for return and indirect > >> >> > thunks at first place? > >> >> > > >> >> > >> >> These 2

Re: PING^3: [PATCH] i386: Don't generate alias for function return thunk

On Thu, Mar 15, 2018 at 10:47 AM, Jan Hubicka wrote: >> On Thu, Mar 15, 2018 at 9:03 AM, Jan Hubicka wrote: >> >> > What is the reason for using different names for return and indirect >> >> > thunks at first place? >> >> > >> >> >> >> These 2 thunks are

Re: PING^3: [PATCH] i386: Don't generate alias for function return thunk

> On Thu, Mar 15, 2018 at 9:03 AM, Jan Hubicka wrote: > >> > What is the reason for using different names for return and indirect > >> > thunks at first place? > >> > > >> > >> These 2 thunks are identical. But one may want to provide an > >> alternate thunk only for > >>

Re: libgo patch committed: Force LANG=C when looking for compiler version

On Thu, Mar 15, 2018 at 10:10 AM, Andreas Schwab wrote: > On Mär 15 2018, Ian Lance Taylor wrote: > >> + env = append(env, "LANG=C") > > You should use LC_ALL=C instead. Does it really matter? Do you think that this approach won't work? Ian

Re: [C++ PATCH] Fix up -Wdeprecated (PR c++/84222)

On Thu, Mar 15, 2018 at 4:07 AM, Jakub Jelinek wrote: > On Wed, Mar 14, 2018 at 08:44:48PM -0400, Jason Merrill wrote: >> > --- gcc/cp/decl.c.jj2018-03-14 09:44:55.744974946 +0100 >> > +++ gcc/cp/decl.c 2018-03-14 12:18:08.094012453 +0100 >> > @@ -10448,7 +10448,7 @@

Re: [C++ PATCH] Fix PLACEHOLDER_EXPR handling (PR c++/79937, PR c++/82410)

On Thu, Mar 15, 2018 at 4:32 AM, Jakub Jelinek wrote: > On Wed, Mar 14, 2018 at 08:55:47PM -0400, Jason Merrill wrote: >> > @@ -3192,16 +3198,70 @@ replace_placeholders (tree exp, tree obj >> > return exp; >> > >> >tree *tp = >> > - hash_set pset; >> > -

[arm-embedded][PATCH] Add multilib mapping for -mcpu=cortex-r52

Hi, Currently -mcpu=cortex-r52 gets assigned the default multilib due to lack of mapping from -mcpu=cortex-r52 to an -march option. This is inconsistent with -march=armv8-r which gets the thumb/v7-ar multilib. This patch adds the appropriate mapping. ChangeLog entry is as follows: ***

Re: libgo patch committed: Force LANG=C when looking for compiler version

On Mär 15 2018, Ian Lance Taylor wrote: > + env = append(env, "LANG=C") You should use LC_ALL=C instead. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely

Re: [RFC Patch], PowerPC memory support pre-gcc9, patch #2

This is patch #2 of my series for improving the PowerPC internal memory support. It assumes patch #1 has been applied. This patch moves the rs6000_move_128bit function from rs6000.c to a new file, rs6000-output.c. The third patch will create a rs6000_move_64bit function and change both 32-bit

libgo patch committed: Force LANG=C when looking for compiler version

This libgo patch forces LANG=C when looking for the version of the C compiler. Tested by installing the gcc-locales package and running LANG=de_DE.utf8 go build hello.go Without this change, that fails, as described at GCC PR 84765. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.

Re: [Aarch64] Fix conditional branches with target far away.

On 15/03/18 15:27, Sameera Deshpande wrote: Ping! On 28 February 2018 at 16:18, Sameera Deshpande wrote: On 27 February 2018 at 18:25, Ramana Radhakrishnan wrote: On Wed, Feb 14, 2018 at 8:30 AM, Sameera Deshpande

Re: [PATCH] Fix PR84873

On Thu, Mar 15, 2018 at 1:07 PM, Jakub Jelinek wrote: > On Thu, Mar 15, 2018 at 01:56:16PM +0100, Richard Biener wrote: >> The following fixes the C familiy gimplification langhook to not >> introduce tree sharing which isn't valid during gimplification. >> For the specific case

Re: [PATCH] Fortran -- clean up KILL

On Thu, Mar 15, 2018 at 04:08:10PM +0100, Jakub Jelinek wrote: > On Thu, Mar 15, 2018 at 07:10:26AM -0700, Steve Kargl wrote: > > On Thu, Mar 15, 2018 at 01:35:23PM +0100, Richard Biener wrote: > > > > > > > > extern GFC_INTEGER_4 kill (GFC_INTEGER_4, GFC_INTEGER_4); > > > > extern __typeof(kill)

Re: PING^3: [PATCH] i386: Don't generate alias for function return thunk

On Thu, Mar 15, 2018 at 9:03 AM, Jan Hubicka wrote: >> > What is the reason for using different names for return and indirect >> > thunks at first place? >> > >> >> These 2 thunks are identical. But one may want to provide an >> alternate thunk only for >> indirect branch and

Re: PING^3: [PATCH] i386: Don't generate alias for function return thunk

> > What is the reason for using different names for return and indirect thunks > > at first place? > > > > These 2 thunks are identical. But one may want to provide an > alternate thunk only for > indirect branch and leaves return thunk alone. You can't do that if > both have the same > name.

[committed] Fix testcase for PR c/84852

On Thu, 2018-03-15 at 09:32 +0800, Paul Hua wrote: > Hi: > > The fixits-pr84852-1.c fails on mips64el target. > > FAIL: gcc.dg/fixits-pr84852-1.c (test for excess errors) > FAIL: gcc.dg/fixits-pr84852-1.c dg-regexp 25 not found: > ".*fixits-pr84852.c:-812156810:25:" > > see this patch: > >

Re: PING^3: [PATCH] i386: Don't generate alias for function return thunk

On Thu, Mar 15, 2018 at 8:51 AM, Jan Hubicka wrote: >> On Sun, Mar 11, 2018 at 7:39 AM, H.J. Lu wrote: >> > On Mon, Mar 5, 2018 at 4:17 AM, H.J. Lu wrote: >> >> On Mon, Feb 26, 2018 at 12:48 PM, H.J. Lu wrote: >>

Re: [PATCH] Fortran -- clean up KILL

On Thu, Mar 15, 2018 at 3:54 PM, Jakub Jelinek wrote: > On Thu, Mar 15, 2018 at 03:45:47PM +, Bin.Cheng wrote: >> FYI, both your patches fix the compilation issue. > > It isn't just a compilation problem, it really can't work at all. > Without the patch, if the function

Re: [PATCH] Fortran -- clean up KILL

On Thu, Mar 15, 2018 at 03:45:47PM +, Bin.Cheng wrote: > FYI, both your patches fix the compilation issue. It isn't just a compilation problem, it really can't work at all. Without the patch, if the function builds, it looks like: 002308b0 <_gfortran_kill>: 2308b0: f3 0f 1e

Re: PING^3: [PATCH] i386: Don't generate alias for function return thunk

> On Sun, Mar 11, 2018 at 7:39 AM, H.J. Lu wrote: > > On Mon, Mar 5, 2018 at 4:17 AM, H.J. Lu wrote: > >> On Mon, Feb 26, 2018 at 12:48 PM, H.J. Lu wrote: > >>> Function return thunks shouldn't be aliased to indirect branch thunks

PING^3: [PATCH] x86: Force __x86_indirect_thunk_reg for function call via GOT

On Sun, Mar 11, 2018 at 7:40 AM, H.J. Lu wrote: > On Mon, Mar 5, 2018 at 4:20 AM, H.J. Lu wrote: >> On Tue, Feb 27, 2018 at 11:39 AM, H.J. Lu wrote: >>> For x86 targets, when -fno-plt is used, external functions are called >>> via

PING^3: [PATCH] i386: Don't generate alias for function return thunk

On Sun, Mar 11, 2018 at 7:39 AM, H.J. Lu wrote: > On Mon, Mar 5, 2018 at 4:17 AM, H.J. Lu wrote: >> On Mon, Feb 26, 2018 at 12:48 PM, H.J. Lu wrote: >>> Function return thunks shouldn't be aliased to indirect branch thunks >>>

Re: [PATCH] Fortran -- clean up KILL

On Thu, Mar 15, 2018 at 3:08 PM, Jakub Jelinek wrote: > On Thu, Mar 15, 2018 at 07:10:26AM -0700, Steve Kargl wrote: >> On Thu, Mar 15, 2018 at 01:35:23PM +0100, Richard Biener wrote: >> > > >> > > extern GFC_INTEGER_4 kill (GFC_INTEGER_4, GFC_INTEGER_4); >> > > extern

GW Pharmaceuticals & UC Irvine to Keynote Cannabinoid Therapeutics Symposium

CANNABINOID THERAPEUTICS SYMPOSIUM June 6 - 7, 2018 | Crowne Plaza Redondo Beach & Marina Hotel | Redondo Beach, CA --- SIGN UP TODAY: http://links.infocastevents.mkt8115.com/ctt?kn=5=MzM0ODQwOTES1=NjkyMTk1NzM3MTk0S0=2=MTI0MTgzMjkwMwS2=1=0 --- Get a status report from world-class biomedical

Re: [PATCH] Fix PR84873

On Thu, Mar 15, 2018 at 01:56:16PM +0100, Richard Biener wrote: > The following fixes the C familiy gimplification langhook to not > introduce tree sharing which isn't valid during gimplification. > For the specific case the tree sharing is introduced by > fold_binary_op_with_cond and is reached

Re: [Aarch64] Fix conditional branches with target far away.

Ping! On 28 February 2018 at 16:18, Sameera Deshpande wrote: > On 27 February 2018 at 18:25, Ramana Radhakrishnan > wrote: >> On Wed, Feb 14, 2018 at 8:30 AM, Sameera Deshpande >> wrote: >>> Hi! >>> >>>

[PATCH] rs6000: Fix for the previous abi_v4_pass_in_fpr change

I was a bit over-enthusiastic, we still support xilinxfp. Tested on powerpc64-linux {-m664,-m32}, committing. Segher 2018-03-15 Segher Boessenkool * config/rs6000/rs6000.c (abi_v4_pass_in_fpr): Add back the TARGET_DOUBLE_FLOAT and

Re: PING

> > https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00577.html OK. > https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00587.html I think here problem happens earlier becuase we should not have profile in the function at first place. The change itself make sense, but lets debug who and how computes

Re: [PATCH] Fortran -- clean up KILL

On Thu, Mar 15, 2018 at 07:10:26AM -0700, Steve Kargl wrote: > On Thu, Mar 15, 2018 at 01:35:23PM +0100, Richard Biener wrote: > > > > > > extern GFC_INTEGER_4 kill (GFC_INTEGER_4, GFC_INTEGER_4); > > > extern __typeof(kill) kill __asm__("" "_gfortran_kill"); > > > > Why do you need to jump

Re: [PATCH] Fortran -- clean up KILL

On Thu, Mar 15, 2018 at 12:20:08PM +, Bin.Cheng wrote: > >> -fdata-sections -O2 -mabi=ilp32 -MT kill.lo -MD -MP -MF .deps/kill.Tpo > >> -c /.../gcc/libgfortran/intrinsics/kill.c -o kill.o > >> /.../gcc/libgfortran/intrinsics/kill.c:54:22: error: conflicting types > >> for 'kill' > >> extern

[PATCH,rs6000] PR 844422 Fix FCTID, FCTIW with -mcpu=power7

GCC Maintainers: The following patch fixes an ICE when compiling the test case   gcc -mcpu=power7 builtin-fctid-fctiw-runnable.c The GCC compiler now gives a message  "error: builtin function ‘__builtin_fctiw’ requires the ‘-mpower8- vector’ option"  and exits without generating an

Re: [PATCH] PR gcc/68256 Defining TARGET_USE_CONSTANT_BLOCKS_P causes go bootstrap failure on aarch64.

On 15 March 2018 at 15:07, Bin.Cheng wrote: > On Fri, Feb 16, 2018 at 5:18 PM, wrote: >> From: Vladimir Mezentsev >> >> Ramana Radhakrishnan made a workaround in gcc/config/aarch64/aarch64.c to >> resolve >>

Re: [PATCH] Fortran -- clean up KILL

On Thu, Mar 15, 2018 at 01:35:23PM +0100, Richard Biener wrote: > > > > extern GFC_INTEGER_4 kill (GFC_INTEGER_4, GFC_INTEGER_4); > > extern __typeof(kill) kill __asm__("" "_gfortran_kill"); > > Why do you need to jump through these hoops anyway? Just do ... > Not sure who the "you" refers to.

Re: [PATCH] PR gcc/68256 Defining TARGET_USE_CONSTANT_BLOCKS_P causes go bootstrap failure on aarch64.

On Fri, Feb 16, 2018 at 5:18 PM, wrote: > From: Vladimir Mezentsev > > Ramana Radhakrishnan made a workaround in gcc/config/aarch64/aarch64.c to > resolve > bootstrap comparison failure (2015-11-10, commit >

Re: C++ PATCH to fix an ICE on invalid with OVERLOADs (PR c++/84854)

On Thu, Mar 15, 2018 at 7:49 AM, Marek Polacek wrote: > On Wed, Mar 14, 2018 at 02:06:36PM -0400, Jason Merrill wrote: >> On Wed, Mar 14, 2018 at 11:59 AM, Marek Polacek wrote: >> > cxx_constant_value doesn't understand template codes, and neither it >> >

[PATCH] Fix PR84873

The following fixes the C familiy gimplification langhook to not introduce tree sharing which isn't valid during gimplification. For the specific case the tree sharing is introduced by fold_binary_op_with_cond and is reached via convert () eventually folding something. I've kept folding

Re: [PATCH] Fortran -- clean up KILL

On Thu, Mar 15, 2018 at 1:11 PM, Bin.Cheng wrote: > On Thu, Mar 15, 2018 at 10:18 AM, Bin.Cheng wrote: >> On Wed, Mar 14, 2018 at 12:57 AM, Steve Kargl >> wrote: >>> On Tue, Mar 13, 2018 at 09:49:10PM +0200, Janne

Re: [PATCH] Fortran -- clean up KILL

On Thu, Mar 15, 2018 at 12:11 PM, Bin.Cheng wrote: > On Thu, Mar 15, 2018 at 10:18 AM, Bin.Cheng wrote: >> On Wed, Mar 14, 2018 at 12:57 AM, Steve Kargl >> wrote: >>> On Tue, Mar 13, 2018 at 09:49:10PM +0200, Janne

Re: [PATCH] Add test-case (PR ipa/84805).

> Sorry for the breakage. Actually I did testing on x86_64 and ppcl64 > machines. There is no breakage, just an issue with the ordering of warnings which may vary across platforms. -- Eric Botcazou

Re: [PATCH] Fortran -- clean up KILL

On Thu, Mar 15, 2018 at 10:18 AM, Bin.Cheng wrote: > On Wed, Mar 14, 2018 at 12:57 AM, Steve Kargl > wrote: >> On Tue, Mar 13, 2018 at 09:49:10PM +0200, Janne Blomqvist wrote: >>> >>> int val = kill (pid, signal); >>> return (val == 0): 0

Re: C++ PATCH to fix an ICE on invalid with OVERLOADs (PR c++/84854)

On Wed, Mar 14, 2018 at 02:06:36PM -0400, Jason Merrill wrote: > On Wed, Mar 14, 2018 at 11:59 AM, Marek Polacek wrote: > > cxx_constant_value doesn't understand template codes, and neither it > > understands OVERLOADs, so if we pass an OVERLOAD to it, we crash. Here > >

[arm-embedded][PATCH] Add multilib mapping for -mcpu=cortex-m33+nodsp

Hi, Currently -mcpu=cortex-m33+nodsp gets assigned the thumb multilib due to lack of mapping from -mcpu=cortex-m33+nodsp to an -march option. This leads to link failures for linking Armv4T Thumb code from the multilib with Armv8-M Mainline code from the code being compiled. This patch adds the

Re: [PATCH][GCC][ARM] Fix can_change_mode_class for big-endian

Hi Tamar, On 05/03/18 16:51, Tamar Christina wrote: Hi All, Taking the subreg of a vector mode on big-endian may result in an infinite recursion and eventually a segfault once we run out of stack space. As an example, taking a subreg of V4HF to SImode we end up in the following loop on

Re: [PATCH] Fortran -- clean up KILL

On Wed, Mar 14, 2018 at 12:57 AM, Steve Kargl wrote: > On Tue, Mar 13, 2018 at 09:49:10PM +0200, Janne Blomqvist wrote: >> >> int val = kill (pid, signal); >> return (val == 0): 0 ? errno; >> >> like it already does for the optional status argument for kill_sub.

Re: [PATCH] Add test-case (PR ipa/84805).

On 03/14/2018 09:12 PM, Eric Botcazou wrote: >> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. > > Please make sure to test it on more platforms (see PR ipa/83983 for details). > Sorry for the breakage. Actually I did testing on x86_64 and ppcl64 machines. Martin

Re: [PATCH] PR gcc/68256 Defining TARGET_USE_CONSTANT_BLOCKS_P causes go bootstrap failure on aarch64.

On Mon, Feb 26, 2018 at 12:07 PM, Richard Biener wrote: > On Fri, Feb 16, 2018 at 6:18 PM, wrote: >> From: Vladimir Mezentsev >> >> Ramana Radhakrishnan made a workaround in gcc/config/aarch64/aarch64.c

Re: RFA (make_dispatcher_decl): PATCH for c++/83911, ICE with multiversioned constructor

On Wed, Mar 14, 2018 at 8:57 PM, Jason Merrill wrote: > Ping > > On Fri, Mar 2, 2018 at 1:23 PM, Jason Merrill wrote: >> As I mentioned in the PR, the problem here is that we're replacing a >> constructor with a dispatcher function which doesn't look much like

Re: [C++ PATCH] Fix PLACEHOLDER_EXPR handling (PR c++/79937, PR c++/82410)

On Wed, Mar 14, 2018 at 08:55:47PM -0400, Jason Merrill wrote: > > @@ -3192,16 +3198,70 @@ replace_placeholders (tree exp, tree obj > > return exp; > > > >tree *tp = > > - hash_set pset; > > - replace_placeholders_t data = { obj, false, }; > > + /* Use exp instead of *(type *) */ >

Re: [C++ PATCH] Fix up -Wdeprecated (PR c++/84222)

On Wed, Mar 14, 2018 at 08:44:48PM -0400, Jason Merrill wrote: > > --- gcc/cp/decl.c.jj2018-03-14 09:44:55.744974946 +0100 > > +++ gcc/cp/decl.c 2018-03-14 12:18:08.094012453 +0100 > > @@ -10448,7 +10448,7 @@ grokdeclarator (const cp_declarator *dec > > suppress reports of

Re: [PATCH] Add test-case (PR ipa/84805).

On 14 March 2018 at 21:12, Eric Botcazou wrote: >> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. > > Please make sure to test it on more platforms (see PR ipa/83983 for details). > Hi, These new tests do not work well on arm-none-eabi and

Re: [PATCH] Fix emit_conditional_move (PR target/84860)

On Wed, 14 Mar 2018, Jakub Jelinek wrote: > Hi! > > prepare_cmp_insn in some cases changes both the passed in comparison and the > comparison mode, e.g. by promoting the arguments from SFmode to DFmode etc. > > In emit_conditional_move we call this in a loop, for (pass = 0; pass < 2; > pass++)

Re: [patch][i386] Adding pconfig, wbnoinvd and wbinvd intrinsics

On Wed, Mar 14, 2018 at 1:39 PM, Makhotina, Olga wrote: > Hi, > > I have made changes to this patch. > I attached a new version. > > 14.03. 2018 Olga Makhotina > > gcc/ > * config/i386/sgxintrin.h (_enclv_u32): New intrinsic. >

Re: [PATCH v2] Fix bogus strncpy source length warning on source bound by constant

On Wednesday 14 March 2018 08:40 PM, Richard Biener wrote: > Instead of building a tree from max you should use > > if (wi::to_widest (max) < wi::to_widest (wi::to_wide (dstsize))) > return; > > given compute_objsize is somewhat confused about the type it returns > a widest_int compare