On Sun, 2018-01-14 at 21:52 +0100, Uros Bizjak wrote:
>
> Well, you did say that these are strange times ;)
>
> From the user perspective, it would be more convenient to use the
> thunk names that are the same for 32bit and 64bit targets. If we
> ignore this fact, the difference is only a couple
On 01/11/2018 04:49 PM, Martin Sebor wrote:
> On 01/11/2018 04:24 PM, Jeff Law wrote:
>> On 01/10/2018 01:26 PM, Martin Sebor wrote:
>>> To avoid issuing duplicate warnings for the same function call
>>> in the source code the -Wrestrict warning code makes sure
>>> the no-warning bit is propagated
On 01/12/2018 01:58 PM, li...@coryfields.com wrote:
> From: Cory Fields
>
> 2018-01-12 Cory Fields
>* tree-ira.c (allocno_hard_regs_compare): stabilize sort
Thanks. I fixed the ChangeLog entry and installed hte patch on the trunk.
jeff
On 01/12/2018 01:58 PM, li...@coryfields.com wrote:
> From: Cory Fields
>
> 2018-01-12 Cory Fields
>* tree-ssa-loop-im.c (sort_bbs_in_loop_postorder_cmp): stabilize sort
Thanks. Installed onto the trunk.
jeff
On 01/11/2018 06:54 AM, Nathan Rossi wrote:
> 2018-01-11 Nathan Rossi
>
> PR target/83013
> * config/microblaze/microblaze.c (microblaze_asm_output_ident):
> Use .pushsection/.popsection
THanks. Installed on the trunk.
jeff
Hi
> -Original Message-
> From: H.J. Lu [mailto:hjl.to...@gmail.com]
> Sent: Sunday, January 14, 2018 7:52 PM
> To: Jan Hubicka
> Cc: Kumar, Venkataramanan ; gcc-
> patc...@gcc.gnu.org; Dharmakan, Rohit arul raj
> ; Nagarajan, Muthu kumar raj
> ; Uros Bizjak (ubiz...@gmail.com)
>
> Subj
On Sun, Jan 14, 2018 at 1:23 PM, H.J. Lu wrote:
> On Sun, Jan 14, 2018 at 10:52 AM, Uros Bizjak wrote:
>> On Sun, Jan 14, 2018 at 7:08 PM, H.J. Lu wrote:
>>> On Sun, Jan 14, 2018 at 9:51 AM, Uros Bizjak wrote:
- (ior (and (not (match_test "TARGET_X32"))
+ (ior (and (not (match_test
The attached patch fixes PR c++/83588 - struct with two flexible
arrays causes an internal compiler error. The ICE is caused by
the same assertion in varasm.c that has led to other similar
reports in the past:
/* Given a non-empty initialization, this field had better
be last. Given a fl
On Sun, Jan 14, 2018 at 3:23 PM, David Woodhouse wrote:
> I think we *shouldn't* do this. Uros said we could look at it and make
> a decision, and GCC would implement what we decide. Up to Linus.
Regardless of whether we end up having to do this, I'm not doing rc8
with it, and let's hope we can j
At the last minute, they were switched from __x86_indirect_thunk_rax to
__x86_indirect_thunk_ax without the 'r' or 'e' on the register name.
Except for the _r[89..] versions, obviously.
This is not entirely an improvement, IMO.
Reluctantly-signed-off-by: David Woodhouse
---
I think we *shouldn't
On 10 January 2018 15:59:28 CET, "Martin Liška" wrote:
>On 01/10/2018 02:13 PM, Richard Biener wrote:
>> On Tue, Jan 9, 2018 at 7:29 PM, Jeff Law wrote:
>>> On 01/09/2018 07:43 AM, Martin Liška wrote:
On 09/20/2017 05:00 PM, Jeff Law wrote:
> On 09/20/2017 01:24 AM, Martin Liška wrote:
>
On Sun, Jan 14, 2018 at 3:09 PM, David Woodhouse wrote:
>
> I think we should stick with what we have now, with the names of the
> thunks actually being the *full* name of the register (rax, eax, etc.)
> that they use.
It that works for the gcc people, then yes, I agree. The mixed
"sometimes full
On Sun, 2018-01-14 at 15:02 -0800, Linus Torvalds wrote:
> On Sun, Jan 14, 2018 at 2:39 PM, David Woodhouse > wrote:
> >
> > I'm not convinced we want to do this, but I'll defer to Linus.
>
> Well, I guess we have no choice, if gcc ends up using the stupid
> names.
At this point, they'll do what
On Sun, Jan 14, 2018 at 2:39 PM, David Woodhouse wrote:
>
> I'm not convinced we want to do this, but I'll defer to Linus.
Well, I guess we have no choice, if gcc ends up using the stupid names.
And yes, apparently this just made our macros worse instead of
cleaning anything up. Oh well.
I do h
On Sun, 2018-01-14 at 14:12 -0800, H.J. Lu wrote:
> Please use this GCC patch instead.
Building now; thanks.
This is the kernel patch I'll test as soon as the compiler is done.
It's slightly less horrid than the "clever" one I sent out earlier, but
does still end up needing those _ASM_AX etc. mac
On Sun, Jan 14, 2018 at 2:09 PM, David Woodhouse wrote:
> On Sun, 2018-01-14 at 14:03 -0800, H.J. Lu wrote:
>>
>> > And *that* was the point at which I asked HJ to just use the proper
>> > bloody register names :)
>>
>> Please let me know if I should make the change to ax,..., r8,..r15.
>
> This i
On Sun, 2018-01-14 at 14:03 -0800, H.J. Lu wrote:
>
> > And *that* was the point at which I asked HJ to just use the proper
> > bloody register names :)
>
> Please let me know if I should make the change to ax,..., r8,..r15.
This is what I'm building my compiler with now, to make that change:
ht
On Sun, Jan 14, 2018 at 1:58 PM, David Woodhouse wrote:
> On Sun, 2018-01-14 at 13:07 -0800, Linus Torvalds wrote:
>> On Sun, Jan 14, 2018 at 1:02 PM, David Woodhouse wrote:
>> >
>> > Review on the GCC patches has led to a request that the thunk symbols
>> > be changed from e.g. __x86_indirect_th
On Sun, 2018-01-14 at 13:07 -0800, Linus Torvalds wrote:
> On Sun, Jan 14, 2018 at 1:02 PM, David Woodhouse wrote:
> >
> > Review on the GCC patches has led to a request that the thunk symbols
> > be changed from e.g. __x86_indirect_thunk_rax to
> > __x86_indirect_thunk_ax without the 'r'.
> Ok.
On 01/14/2018 03:31 AM, Jakub Jelinek wrote:
On Sat, Jan 13, 2018 at 04:14:38PM -0700, Martin Sebor wrote:
-The @option{-Wclass-memaccess} option is enabled by @option{-Wall}.
+The @option{-Wclass-memaccess} option is enabled by @option{-Wall}. Casting
Perhaps "Explicitly casting" instead? T
On 01/14/2018 09:42 AM, Jerry DeLisle wrote:
> Hello all,
>
> I committed the following as trivial.
>
> Regression tested on x86_64-pc-linux-gnu.
>
> This is a regression on 7 so I will backport.
>
> Regards,
>
> Jerry
>
> 2018-01-18 Jerry DeLisle
>
> PR libgfortran/83811
> *
On Sun, Jan 14, 2018 at 1:07 PM, Linus Torvalds
wrote:
> On Sun, Jan 14, 2018 at 1:02 PM, David Woodhouse wrote:
>> Review on the GCC patches has led to a request that the thunk symbols
>> be changed from e.g. __x86_indirect_thunk_rax to
>> __x86_indirect_thunk_ax without the 'r'.
>
> Ok. I think
On Sun, Jan 14, 2018 at 10:52 AM, Uros Bizjak wrote:
> On Sun, Jan 14, 2018 at 7:08 PM, H.J. Lu wrote:
>> On Sun, Jan 14, 2018 at 9:51 AM, Uros Bizjak wrote:
>>> - (ior (and (not (match_test "TARGET_X32"))
>>> + (ior (and (not (match_test "TARGET_X32
>>> + || ix86_indirect_branch_thunk_re
On Sun, 14 Jan 2018, David Woodhouse wrote:
> On Sun, 2018-01-14 at 13:07 -0800, Linus Torvalds wrote:
> > On Sun, Jan 14, 2018 at 1:02 PM, David Woodhouse
> > wrote:
> > > Review on the GCC patches has led to a request that the thunk symbols
> > > be changed from e.g. __x86_indirect_thunk_rax t
On Sun, 2018-01-14 at 13:07 -0800, Linus Torvalds wrote:
> On Sun, Jan 14, 2018 at 1:02 PM, David Woodhouse wrote:
> > Review on the GCC patches has led to a request that the thunk symbols
> > be changed from e.g. __x86_indirect_thunk_rax to
> > __x86_indirect_thunk_ax without the 'r'.
>
> Ok. I
On Sun, Jan 14, 2018 at 1:02 PM, David Woodhouse wrote:
> Review on the GCC patches has led to a request that the thunk symbols
> be changed from e.g. __x86_indirect_thunk_rax to
> __x86_indirect_thunk_ax without the 'r'.
Ok. I think that just makes it easier for us, since then the names are
inde
On Sun, 2018-01-14 at 21:52 +0100, Uros Bizjak wrote:
> On Sun, Jan 14, 2018 at 9:34 PM, David Woodhouse wrote:
> > But sure, right now it isn't that might of a difference for me; my
> > implementation has changed since I made that reqeust. I have no
> > fundamental technical objection to the bare
On Sun, Jan 14, 2018 at 9:34 PM, David Woodhouse wrote:
> Likewise, the CONFIG_TRIM_UNUSED_SYMBOLS mechanism in the kernel passes
> .S files through the preprocessor and looks for EXPORT_SYMBOL, so it
> wasn't working well with my .irp-based implementation like the one in
> Xen. So I've swapped i
On Sun, Jan 14, 2018 at 10:52 AM, Uros Bizjak wrote:
> On Sun, Jan 14, 2018 at 7:08 PM, H.J. Lu wrote:
>> On Sun, Jan 14, 2018 at 9:51 AM, Uros Bizjak wrote:
>>> - (ior (and (not (match_test "TARGET_X32"))
>>> + (ior (and (not (match_test "TARGET_X32
>>> + || ix86_indirect_branch_thunk_re
On Sunday 14 January 2018 at 16:08:09 +, Mike Crowe wrote:
> Hi Torvald,
>
> Thanks for reviewing this change.
>
> On Saturday 13 January 2018 at 16:29:57 +0100, Torvald Riegel wrote:
> > On Sun, 2018-01-07 at 20:55 +, Mike Crowe wrote:
> > > This is a first attempt to make std::future::w
On Sun, 2018-01-14 at 21:21 +0100, Uros Bizjak wrote:
> A quick look through latest x86/pti update [1] shows:
>
> +#ifdef CONFIG_X86_32
> +#define INDIRECT_THUNK(reg) extern asmlinkage void
> __x86_indirect_thunk_e ## reg(void);
> +#else
> +#define INDIRECT_THUNK(reg) extern asmlinkage void
> __x8
On Sun, Jan 14, 2018 at 7:22 PM, Uros Bizjak wrote:
> On Sun, Jan 14, 2018 at 6:44 PM, Woodhouse, David wrote:
>> This won't make the list; I'll send a more coherent and less HTML-afflicted
>> version later.
>>
>> The bare 'ax' naming made it painful to instantiate the external thunks for
>> 32-b
On Sun, 2018-01-14 at 12:06 +0100, Jan Hubicka wrote:
>
> Yes, according to my understanding we want both pause and lefence by default
> (it is expensive anyway) + command line option to control which one to use?
>
> Probably thus the first patch should default to both.
In the kernel we're going
On Sun, Jan 14, 2018 at 7:08 PM, H.J. Lu wrote:
> On Sun, Jan 14, 2018 at 9:51 AM, Uros Bizjak wrote:
>> - (ior (and (not (match_test "TARGET_X32"))
>> + (ior (and (not (match_test "TARGET_X32
>> + || ix86_indirect_branch_thunk_register"))
>> (match_operand 0 "sibcall_memory_operand")
On Sun, Jan 14, 2018 at 6:44 PM, Woodhouse, David wrote:
> This won't make the list; I'll send a more coherent and less HTML-afflicted
> version later.
>
> The bare 'ax' naming made it painful to instantiate the external thunks for
> 32-bit and 64-bot code because we had to put the e/r back again
On Sun, Jan 14, 2018 at 9:51 AM, Uros Bizjak wrote:
> - (ior (and (not (match_test "TARGET_X32"))
> + (ior (and (not (match_test "TARGET_X32
> + || ix86_indirect_branch_thunk_register"))
> (match_operand 0 "sibcall_memory_operand"))
> - (and (match_test "TARGET_X32 && Pmode == DI
- (ior (and (not (match_test "TARGET_X32"))
+ (ior (and (not (match_test "TARGET_X32
+ || ix86_indirect_branch_thunk_register"))
(match_operand 0 "sibcall_memory_operand"))
- (and (match_test "TARGET_X32 && Pmode == DImode")
+ (and (match_test "TARGET_X32 && Pmode == DImode
This won't make the list; I'll send a more coherent and less HTML-afflicted
version later.
The bare 'ax' naming made it painful to instantiate the external thunks for
32-bit and 64-bot code because we had to put the e/r back again inside the .irp
reg ax bx... code.
We could probably have lived
Hello all,
I committed the following as trivial.
Regression tested on x86_64-pc-linux-gnu.
This is a regression on 7 so I will backport.
Regards,
Jerry
2018-01-18 Jerry DeLisle
PR libgfortran/83811
* write.c (select_buffer): Adjust buffer size up by 1.
diff --git a/libgfo
Hi,
It was pointed out off-list that I should add some executable tests for
the new -msafe-indirect-jumps implementation. This patch adds three
such tests to demonstrate correct behavior.
Tested on powerpc64-linux-gnu and powerpc64le-linux-gnu. Are these tests
okay for trunk after the other pat
Installed as obvious.
Andreas.
PR libstdc++/81092
* config/abi/post/ia64-linux-gnu/baseline_symbols.txt: Update.
diff --git a/libstdc++-v3/config/abi/post/ia64-linux-gnu/baseline_symbols.txt
b/libstdc++-v3/config/abi/post/ia64-linux-gnu/baseline_symbols.txt
index 0b166d5e2a..041
On 01/12/2018 06:16 PM, David Malcolm wrote:
> On Fri, 2017-12-01 at 17:57 -0500, Mike Gulick wrote:
>> I've come up with some patches that fix PR preprocessor/83173, which
>> I reported
>> a couple of weeks ago.
>>
>> The first patch is a test case. The second and third patches are two
>> versi
On Sun, Jan 14, 2018 at 8:45 AM, Jakub Jelinek wrote:
> On Sun, Jan 14, 2018 at 08:41:54AM -0800, H.J. Lu wrote:
>> They are used in asm statements in kernel:
>>
>> extern void (*func_p) (void);
>>
>> void
>> foo (void)
>> {
>> asm ("call __x86_indirect_thunk_%V0" : : "a" (func_p));
>
> Well, us
On Sun, Jan 14, 2018 at 8:48 AM, Uros Bizjak wrote:
> On Sun, Jan 14, 2018 at 5:41 PM, H.J. Lu wrote:
>> On Sun, Jan 14, 2018 at 8:39 AM, Uros Bizjak wrote:
>>> On Sun, Jan 14, 2018 at 5:35 PM, H.J. Lu wrote:
On Sun, Jan 14, 2018 at 8:19 AM, Uros Bizjak wrote:
> On Fri, Jan 12, 2018 a
On Sun, Jan 14, 2018 at 5:41 PM, H.J. Lu wrote:
> On Sun, Jan 14, 2018 at 8:39 AM, Uros Bizjak wrote:
>> On Sun, Jan 14, 2018 at 5:35 PM, H.J. Lu wrote:
>>> On Sun, Jan 14, 2018 at 8:19 AM, Uros Bizjak wrote:
On Fri, Jan 12, 2018 at 9:01 AM, Uros Bizjak wrote:
> On Thu, Jan 11, 2018 a
On Sun, Jan 14, 2018 at 08:41:54AM -0800, H.J. Lu wrote:
> They are used in asm statements in kernel:
>
> extern void (*func_p) (void);
>
> void
> foo (void)
> {
> asm ("call __x86_indirect_thunk_%V0" : : "a" (func_p));
Well, using it just with a single register classes wouldn't make much sens
On Sun, Jan 14, 2018 at 5:35 PM, H.J. Lu wrote:
> On Sun, Jan 14, 2018 at 8:19 AM, Uros Bizjak wrote:
>> On Fri, Jan 12, 2018 at 9:01 AM, Uros Bizjak wrote:
>>> On Thu, Jan 11, 2018 at 2:28 PM, H.J. Lu wrote:
>>>
Hi Uros,
Can you take a look at my x86 backend changes so that they
On Sun, Jan 14, 2018 at 8:39 AM, Uros Bizjak wrote:
> On Sun, Jan 14, 2018 at 5:35 PM, H.J. Lu wrote:
>> On Sun, Jan 14, 2018 at 8:19 AM, Uros Bizjak wrote:
>>> On Fri, Jan 12, 2018 at 9:01 AM, Uros Bizjak wrote:
On Thu, Jan 11, 2018 at 2:28 PM, H.J. Lu wrote:
> Hi Uros,
>
>>
On Sun, Jan 14, 2018 at 5:35 PM, H.J. Lu wrote:
> On Sun, Jan 14, 2018 at 8:19 AM, Uros Bizjak wrote:
>> On Fri, Jan 12, 2018 at 9:01 AM, Uros Bizjak wrote:
>>> On Thu, Jan 11, 2018 at 2:28 PM, H.J. Lu wrote:
>>>
Hi Uros,
Can you take a look at my x86 backend changes so that they
On Sun, Jan 14, 2018 at 8:19 AM, Uros Bizjak wrote:
> On Fri, Jan 12, 2018 at 9:01 AM, Uros Bizjak wrote:
>> On Thu, Jan 11, 2018 at 2:28 PM, H.J. Lu wrote:
>>
>>> Hi Uros,
>>>
>>> Can you take a look at my x86 backend changes so that they are ready
>>> to check in once we have consensus.
>>
>>
Hi!
I've noticed that i?86-*-* has 2 gfniintrin.h entries in extra_headers
and x86_64-*-* even 3, one should be enough. Fixed thusly, committed
to trunk as obvious.
2018-01-14 Jakub Jelinek
* config.gcc (i[34567]86-*-*): Remove one duplicate gfniintrin.h
entry from extra_head
On Fri, Jan 12, 2018 at 9:01 AM, Uros Bizjak wrote:
> On Thu, Jan 11, 2018 at 2:28 PM, H.J. Lu wrote:
>
>> Hi Uros,
>>
>> Can you take a look at my x86 backend changes so that they are ready
>> to check in once we have consensus.
>
> Please finish the talks about the correct approach first. Once
Hi Torvald,
Thanks for reviewing this change.
On Saturday 13 January 2018 at 16:29:57 +0100, Torvald Riegel wrote:
> On Sun, 2018-01-07 at 20:55 +, Mike Crowe wrote:
> > This is a first attempt to make std::future::wait_until and
> > std::future::wait_for make correct use of
> > std::chrono::
On Sun, Jan 14, 2018 at 4:57 AM, H.J. Lu wrote:
> On Sun, Jan 14, 2018 at 2:47 AM, Jan Hubicka wrote:
>>> Since the thunk function may not be reachable in large code model,
>>> -mcmodel=large is incompatible with -mindirect-branch=thunk,
>>> -mindirect-branch=thunk-extern, -mfunction-return=thunk
On Sun, Jan 14, 2018 at 2:46 AM, Jan Hubicka wrote:
>> Add -mindirect-branch-register to force indirect branch via register.
>> This is implemented by disabling patterns of indirect branch via memory,
>> similar to TARGET_X32.
>>
>> -mindirect-branch= and -mfunction-return= tests are updated with
On Sun, Jan 14, 2018 at 2:47 AM, Jan Hubicka wrote:
>> Add 'V', a special modifier which prints the name of the full integer
>> register without '%'. For
>>
>> extern void (*func_p) (void);
>>
>> void
>> foo (void)
>> {
>> asm ("call __x86_indirect_thunk_%V0" : : "a" (func_p));
>> }
>>
>> it ge
On Sun, Jan 14, 2018 at 4:54 AM, H.J. Lu wrote:
> On Sun, Jan 14, 2018 at 3:31 AM, H.J. Lu wrote:
>> On Sun, Jan 14, 2018 at 2:48 AM, Jan Hubicka wrote:
Add -mfunction-return= option to convert function return to call and
return thunks. The default is 'keep', which keeps function retu
On Sun, Jan 14, 2018 at 4:52 AM, H.J. Lu wrote:
> On Sun, Jan 14, 2018 at 3:06 AM, Jan Hubicka wrote:
>>> On 2018.01.14 at 11:46 +0100, Jan Hubicka wrote:
>>> > > gcc/
>>> > >
>>> > > * config/i386/i386-opts.h (indirect_branch): New.
>>> > > * config/i386/i386-protos.h (ix86_output_indirect_j
Now my patch set has been checked into trunk. Here is a patch set
to move struct ix86_frame to machine_function on GCC 7, which is
needed to backport the patch set to GCC 7:
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01239.html
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01240.html
https://g
From: hjl
When there is no need to make a copy of ix86_frame, we can use reference
of struct ix86_frame to avoid copy.
Tested on x86-64.
Backport from mainline
* config/i386/i386.c (ix86_can_use_return_insn_p): Use reference
of struct ix86_frame.
(ix86_initial_el
Make ix86_frame available to i386 code generation. This is needed to
backport the patch set of -mindirect-branch= to mitigate variant #2 of
the speculative execution vulnerabilities on x86 processors identified
by CVE-2017-5715, aka Spectre.
Backport from mainline
* config/i386/i3
When there is no need to make a copy of ix86_frame, we can use reference
of struct ix86_frame to avoid copy.
Backport from mainline
* config/i386/i386.c (ix86_expand_prologue): Use reference of
struct ix86_frame.
(ix86_expand_epilogue): Likewise.
---
gcc/config/i38
This patch set makes ix86_frame available to i386 code generation. They
are needed to backport the patch set of -mindirect-branch= to mitigate
variant #2 of the speculative execution vulnerabilities on x86 processors
identified by CVE-2017-5715, aka Spectre.
H.J. Lu (2):
i386: Move struct ix86_
When address of packed member of struct or union is taken, it may result
in an unaligned pointer value. This patch adds -Waddress-of-packed-member
to warn it:
$ cat x.i
struct pair_t
{
char c;
int i;
} __attribute__ ((packed));
extern struct pair_t p;
int *addr = &p.i;
$ gcc -O2 -S x.i
x.i:8
On Sun, Jan 14, 2018 at 6:20 AM, Jan Hubicka wrote:
>> > Hi HJ,
>> >
>> > > -Original Message-
>> > > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
>> > > ow...@gcc.gnu.org] On Behalf Of H.J. Lu
>> > > Sent: Sunday, January 14, 2018 9:07 AM
>> > > To: gcc-patches@gcc.gnu.org
>>
> > Hi HJ,
> >
> > > -Original Message-
> > > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> > > ow...@gcc.gnu.org] On Behalf Of H.J. Lu
> > > Sent: Sunday, January 14, 2018 9:07 AM
> > > To: gcc-patches@gcc.gnu.org
> > > Subject: [PATCH 0/5] x86: CVE-2017-5715, aka Spectre
>
On Sun, Jan 14, 2018 at 2:47 AM, Jan Hubicka wrote:
>> Since the thunk function may not be reachable in large code model,
>> -mcmodel=large is incompatible with -mindirect-branch=thunk,
>> -mindirect-branch=thunk-extern, -mfunction-return=thunk and
>> -mfunction-return=thunk-extern. Issue an erro
On Sun, Jan 14, 2018 at 3:31 AM, H.J. Lu wrote:
> On Sun, Jan 14, 2018 at 2:48 AM, Jan Hubicka wrote:
>>> Add -mfunction-return= option to convert function return to call and
>>> return thunks. The default is 'keep', which keeps function return
>>> unmodified. 'thunk' converts function return t
On Sun, Jan 14, 2018 at 4:42 AM, Jan Hubicka wrote:
>> On Sun, Jan 14, 2018 at 11:40 AM, Jan Hubicka wrote:
>> >> Hi HJ,
>> >>
>> >> > -Original Message-
>> >> > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
>> >> > ow...@gcc.gnu.org] On Behalf Of H.J. Lu
>> >> > Sent: Sunday,
On Sat, Jan 13, 2018 at 8:09 AM, Jeff Law wrote:
> On 01/12/2018 09:16 AM, H.J. Lu wrote:
>> On Thu, Jan 11, 2018 at 3:00 PM, H.J. Lu wrote:
>>> On Thu, Jan 11, 2018 at 2:46 PM, Jeff Law wrote:
>>
Do you want to mention that CET and retpolines are inherently
>>>
>>> I will document it.
>>>
On Sun, Jan 14, 2018 at 3:06 AM, Jan Hubicka wrote:
>> On 2018.01.14 at 11:46 +0100, Jan Hubicka wrote:
>> > > gcc/
>> > >
>> > > * config/i386/i386-opts.h (indirect_branch): New.
>> > > * config/i386/i386-protos.h (ix86_output_indirect_jmp): Likewise.
>> > > * config/i386/i386.c (ix86_using
> On Sun, Jan 14, 2018 at 11:40 AM, Jan Hubicka wrote:
> >> Hi HJ,
> >>
> >> > -Original Message-
> >> > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> >> > ow...@gcc.gnu.org] On Behalf Of H.J. Lu
> >> > Sent: Sunday, January 14, 2018 9:07 AM
> >> > To: gcc-patches@gcc.gnu.org
On Sun, Jan 14, 2018 at 12:45 PM, Janne Blomqvist
wrote:
> On Sat, Jan 13, 2018 at 7:35 PM, Dominique d'Humières
> wrote:
>> I have finally bootstrapped gfortran with the two patches applied and the
>> spurious warnings with -Wall are now gone (limited testing), but I see a
>> regression for gf
On Sun, Jan 14, 2018 at 11:40 AM, Jan Hubicka wrote:
>> Hi HJ,
>>
>> > -Original Message-
>> > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
>> > ow...@gcc.gnu.org] On Behalf Of H.J. Lu
>> > Sent: Sunday, January 14, 2018 9:07 AM
>> > To: gcc-patches@gcc.gnu.org
>> > Subject: [P
On Sun, Jan 14, 2018 at 2:48 AM, Jan Hubicka wrote:
>> Add -mfunction-return= option to convert function return to call and
>> return thunks. The default is 'keep', which keeps function return
>> unmodified. 'thunk' converts function return to call and return thunk.
>> 'thunk-inline' converts fu
Hi,
this patch fixes ICE on the testcase where we estimate function body
to be rather slow and get roundoff error out of sreal.
Honza
PR ipa/83051
* gcc.c-torture/compile/pr83051.c: New testcase.
* ipa-inline.c (edge_badness): Tolerate roundoff errors.
Index: testsuite/gc
> On 2018.01.14 at 11:46 +0100, Jan Hubicka wrote:
> > > gcc/
> > >
> > > * config/i386/i386-opts.h (indirect_branch): New.
> > > * config/i386/i386-protos.h (ix86_output_indirect_jmp): Likewise.
> > > * config/i386/i386.c (ix86_using_red_zone): Disallow red-zone
> > > with local indirect j
On 2018.01.14 at 11:46 +0100, Jan Hubicka wrote:
> > gcc/
> >
> > * config/i386/i386-opts.h (indirect_branch): New.
> > * config/i386/i386-protos.h (ix86_output_indirect_jmp): Likewise.
> > * config/i386/i386.c (ix86_using_red_zone): Disallow red-zone
> > with local indirect jump wh
Hello world,
here is the latest take on the min/maxloc ABI change for BACK.
This version now passes BACK as a GFC_LOGCIAL_4 by value in all cases.
I did this by using the existing %VAL mechanism. I also added
another test case which crashed during one stage of development.
So, OK for trunk?
Reg
Am 14.01.2018 um 11:45 schrieb Janne Blomqvist:
I have tried to use %wp, but it didn’t work:
../../work/gcc/fortran/decl.c: In function 'void
gfc_set_constant_character_len(gfc_charlen_t, gfc_expr*, gfc_charlen_t)':
../../work/gcc/fortran/decl.c:1567:5: error: unknown conversion type character
> After inlining A into B, inline_small_functions updates the information
> for (most) callees and callers of the new B:
>
> update_callee_keys (&edge_heap, where, updated_nodes);
> [...]
> /* Our profitability metric can depend on local properties
>such as number of in
> Add -mfunction-return= option to convert function return to call and
> return thunks. The default is 'keep', which keeps function return
> unmodified. 'thunk' converts function return to call and return thunk.
> 'thunk-inline' converts function return to inlined call and return thunk.
> 'thunk-
> Since the thunk function may not be reachable in large code model,
> -mcmodel=large is incompatible with -mindirect-branch=thunk,
> -mindirect-branch=thunk-extern, -mfunction-return=thunk and
> -mfunction-return=thunk-extern. Issue an error when they are used with
> -mcmodel=large.
>
> gcc/
>
> gcc/
>
> * config/i386/i386-opts.h (indirect_branch): New.
> * config/i386/i386-protos.h (ix86_output_indirect_jmp): Likewise.
> * config/i386/i386.c (ix86_using_red_zone): Disallow red-zone
> with local indirect jump when converting indirect call and jump.
> (ix86_
> Add 'V', a special modifier which prints the name of the full integer
> register without '%'. For
>
> extern void (*func_p) (void);
>
> void
> foo (void)
> {
> asm ("call __x86_indirect_thunk_%V0" : : "a" (func_p));
> }
>
> it generates:
>
> foo:
> movqfunc_p(%rip), %rax
>
> Add -mindirect-branch-register to force indirect branch via register.
> This is implemented by disabling patterns of indirect branch via memory,
> similar to TARGET_X32.
>
> -mindirect-branch= and -mfunction-return= tests are updated with
> -mno-indirect-branch-register to avoid false test failu
On Sat, Jan 13, 2018 at 7:35 PM, Dominique d'Humières
wrote:
> I have finally bootstrapped gfortran with the two patches applied and the
> spurious warnings with -Wall are now gone (limited testing), but I see a
> regression for gfortran.dg/string_1.f90 due to an additional error
>
> /opt/gcc/_c
> Hi HJ,
>
> > -Original Message-
> > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> > ow...@gcc.gnu.org] On Behalf Of H.J. Lu
> > Sent: Sunday, January 14, 2018 9:07 AM
> > To: gcc-patches@gcc.gnu.org
> > Subject: [PATCH 0/5] x86: CVE-2017-5715, aka Spectre
> >
> > This set
On Sat, Jan 13, 2018 at 04:14:38PM -0700, Martin Sebor wrote:
> -The @option{-Wclass-memaccess} option is enabled by @option{-Wall}.
> +The @option{-Wclass-memaccess} option is enabled by @option{-Wall}. Casting
Perhaps "Explicitly casting" instead? The implicit cast doesn't suppress it
and occu
On 01/12/2018 09:44 AM, Jan Hubicka wrote:
Hi.
Following patch adds new sanitization checks for profile_quality.
Problem is that zero initialization of a struct with profile_count will
lead to an invalid counter. This can help to catch them.
Patch can bootstrap on ppc64le-redhat-linux and survi
On 12 January 2018 at 23:25, Jakub Jelinek wrote:
> On Fri, Jan 12, 2018 at 10:38:39AM -0700, Jeff Law wrote:
>> >>> Thanks for pointing it out. I see it there as well with
>> >>> Prathamesh's test case, though not with the test case in
>> >>> bug 83543. It is the same root cause in both. I agr
Hi Arjan,
> -Original Message-
> From: Van De Ven, Arjan [mailto:arjan.van.de@intel.com]
> Sent: Saturday, January 13, 2018 10:16 PM
> To: David Woodhouse ; Kumar, Venkataramanan
> ; H.J. Lu ; Jeff
> Law ; Paul Turner ; Mallick, Asit K
>
> Cc: Nagarajan, Muthu kumar raj ;
> GCC Patch
After inlining A into B, inline_small_functions updates the information
for (most) callees and callers of the new B:
update_callee_keys (&edge_heap, where, updated_nodes);
[...]
/* Our profitability metric can depend on local properties
such as number of inlinable ca
93 matches
Mail list logo
