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.
> (__enclv_bc, __enclv_cd, __enclv_generic): New defi
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++)
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 aarch64-none-elf.
(as oppose
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 deprecate
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 = &exp;
> > - hash_set pset;
> > - replace_placeholders_t data = { obj, false, &pset };
> > + /* Use exp instead of *(type
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 a
>> constructor. This patch adjust
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 to
>> resolve
>> bootstrap comparison failure (2015-11-10, commit
>> bc443a71dafa2e707bae4
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
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.
>>
>
> Committed as r258511 with yo
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 big-end
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 a
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
> > instantiate_non_dependent
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 ? errno;
>>>
>>> like it already does for the optional sta
> 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
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 Blomqvist wrote:
int val = kill (pid, signal);
return (val == 0):
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 Blomqvist wrote:
int val = kill (pid, signal);
return (val == 0): 0
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
>> > understands OVERLOADs, so if we pass an O
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 constants
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
> bc443a71dafa2e707bae4b2fa74f83b05dea37ab).
> The real bug is in gcc/varasm.c.
> hash_s
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.
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
>> bootstrap comparison failure (2015-11-10, commit
>> bc443a71dafa2e707bae4b2fa74f83b05
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 interna
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 GF
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 throug
>
> 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
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 TARGET_SINGLE_FLOAT conditions on the DFmod
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!
>>>
>>> Please find attached the patch to fix bug in branches with offsets over
>>> 1MiB.
>>> There
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 vi
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&ms=MzM0ODQwOTES1&r=NjkyMTk1NzM3MTk0S0&b=2&j=MTI0MTgzMjkwMwS2&mt=1&rt=0
---
Get a status report from world-clas
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 __typeof(kill) kill __asm__(
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
>>> since indirect branch thunks are placed in COMDAT section and a COMDA
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 GOT slot, in 64-bit mode:
>>>
>>> [bnd] call/jmp *foo@GOT
> 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
> >>> since indirect branch thunks are placed in COMDAT section a
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 fa
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 builds, it looks like:
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:
>> >>> Function return thunks shouldn't be aliased to indirect branch thunks
>> >>> s
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:
>
> diff
> > 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.
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 leaves return thunk
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) k
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 the tree sharing i
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
wrote:
Hi!
Please find attached the patch to fix bug in branches with offse
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. C
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
an
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 different."
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:
*** gcc/Chan
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 = &exp;
>> > - hash_set pset;
>> > - replace_placeholders_t dat
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 @@ grokdeclarator (cons
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
> 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 lea
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 identical. But one may want to provide a
> 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 identical. But one may wan
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 really matter? Do you think that this approach won't work?
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, Iain Buclaw wrote:
>
> Out of curiosity, I did have
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:
>>>
+ env = append(env, "LANG=C")
>>>
>>> You should use LC_ALL=C instead.
>>
>
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
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 (TYPE_SIZE (type), TYPE
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
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
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 recursivel
> 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 identical. But one may wan
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 sufficiently
> aligne
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
>> >> >> > thunks at first place?
>> >> >> >
>>
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
PR fortran/78741
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
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
==
> 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 GOT slot, in 64-bit mode:
> >>>
> >>> [bnd] cal
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 it is ok to do so
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:
>> >>> For x86 targets, when -fno-plt is used, external functions are called
>> >>> v
> >> >>> 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 preven
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.
>> >
>> > I suppose w
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 CONST_INT
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 v
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 MODIFY
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 contains_placehol
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
* decl.c (merge_array
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
>> > (NODE)->base.private_
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 handles that case.
>
> Bo
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, pa
On 03/15/2018 07:07 AM, 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
>> bootstrap comparison failure (2015-11-10, commit
>> bc443a71dafa2e707bae4b2fa74f83b05dea
80 matches
Mail list logo
