On Mon, Jan 8, 2018 at 1:23 AM, Thomas Koenig wrote:
> Hello world,
>
> the attached patch is a step towards the implementaion of the BACK
> argument for the MINLOC and MAXLOC intrinsics, a part of F2008.
> This readies the ABI for a later date.
Makes sense.
> In order to avoid combinatrorial ex
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2018-01-08 Richard Biener
PR middle-end/83517
* match.pd ((t * 2) / 2) -> t): Add missing :c.
* gcc.dg/pr83517.c: New testcase.
Index: gcc/match.pd
==
* H. J. Lu:
> Add -mindirect-branch-loop= option to control loop filler in call and
> return thunks generated by -mindirect-branch=. 'lfence' uses "lfence"
> as loop filler. 'pause' uses "pause" as loop filler. 'nop' uses "nop"
> as loop filler. The default is 'lfence'.
Why is the loop needed
The following fixes PR83580, split_constant_offset is a somewhat odd
beast, replicating SCEV code and tree-affine a bit. It also got
similar tricks as those with regarding to looking through conversions
but while being pedantic about overflow it simply strips sign-conversions.
That's of course wr
On 01/08/2018 01:39 AM, Gerald Pfeifer wrote:
...so adjust to where it redirects.
Applied.
Ah, good catch. Thank you Gerald!
--
Pierre-Marie de Rodat
On 12/17/2017 01:01 AM, Martin Sebor wrote:
* c-c++-common/Wrestrict.c: New test.
681/* The following doesn't overlap but it should trigger
-Wstrinop-ovewrflow
682 for writing past the end. */
683T ("012", a + sizeof a, a);
For nvptx, the warning actually shows
On 01/07/2018 11:59 PM, H.J. Lu wrote:
> Function return thunk is the same as memory thunk for -mindirect-branch=
> where the return address is at the top of the stack:
>
> __x86_return_thunk:
> call L2
> L1:
> lfence
> jmp L1
> L2:
> lea 8(%rsp), %rsp|lea 4(%esp), %esp
>
Hi,
This patch requires alloca for some test-cases.
Tested on x86_64 and committed.
Thanks,
- Tom
Require alloca for some test-cases
2018-01-08 Tom de Vries
* c-c++-common/builtins.c: Require effective target alloca.
* gcc.dg/Wrestrict.c: Same.
* gcc.dg/tree-ssa/loop-interchange-15.c: S
On 01/08/2018 01:29 AM, H.J. Lu wrote:
> 1. They need to be backportable to GCC 7/6/5/4.x.
I must admit this is very important constrain. To be honest, we're planning
to backport the patchset to GCC 4.3.
Martin
On 01/07/2018 11:59 PM, H.J. Lu wrote:
> +static void
> +output_indirect_thunk_function (bool need_bnd_p, int regno)
> +{
> + char name[32];
> + tree decl;
> +
> + /* Create __x86_indirect_thunk/__x86_indirect_thunk_bnd. */
> + indirect_thunk_name (name, regno, need_bnd_p);
> + decl = build_d
Hi,
The -mjsr option in RX should ensure the that BSR instruction is not
generated, only JSR instruction should be generated.
However this does not work as expected: BSR instruction still gets generated
even if -mjsr is passed in the command line.
This is reproducible even if test cases from the g
On Thu, Dec 14, 2017 at 11:10:13PM -0500, Michael Meissner wrote:
> I am working on some patches to optionally enable multilibs for the PowerPC
> long double support to be switchable between IBM extended double and IEEE
> 128-bit floating point. While the patches to actually enable the multlibs
>
On Mon, Jan 8, 2018 at 12:20 AM, Florian Weimer wrote:
> * H. J. Lu:
>
>> Add -mindirect-branch-loop= option to control loop filler in call and
>> return thunks generated by -mindirect-branch=. 'lfence' uses "lfence"
>> as loop filler. 'pause' uses "pause" as loop filler. 'nop' uses "nop"
>> as
This patch adds:
(i) Default initializers for parameterized arrays;
(ii) Fixes ordinary assignment of PDTs by implementing the same deep
copy mechanism as for derived types with allocatable components; and
(iii) Fixes the len parameter checking, which failed where the dummy
type had an assumed para
On Sat, Jan 6, 2018 at 11:04 PM, Martin Sebor wrote:
> Bug 83671 - Fix for false positive reported by -Wstringop-overflow
> does not work at -O1, points out that the string length range
> optimization implemented as a solution for bug 83373 doesn't help
> at -O1. The root cause is that the fix wa
On Sun, Jan 7, 2018 at 8:07 PM, Sandra Loosemore
wrote:
> On 01/07/2018 03:58 PM, H.J. Lu wrote:
>>
>> This set of patches for GCC 8 mitigates variant #2 of the speculative
>> execution
>> vulnerabilities on x86 processors identified by CVE-2017-5715, aka
>> Spectre. They
>> convert indirect bran
On Mon, Jan 8, 2018 at 3:11 AM, Martin Sebor wrote:
> GCC is able to fold references to members of global aggregate
> constants in many expressions but it doesn't known how do it
> for strlen() arguments. As a result, strlen calls with such
> arguments such the one below are not optimized:
>
>
On Sun, Jan 7, 2018 at 10:55 PM, Markus Trippelsdorf
wrote:
> On 2018.01.07 at 21:07 -0700, Sandra Loosemore wrote:
>> On 01/07/2018 03:58 PM, H.J. Lu wrote:
>> > This set of patches for GCC 8 mitigates variant #2 of the speculative
>> > execution
>> > vulnerabilities on x86 processors identified
On Mon, Jan 8, 2018 at 5:22 AM, Jeff Law wrote:
>
> This patch fixes the original problem reported in 81308. Namely that
> g++.dg/pr62079.C will trigger a checking failure on 32bit x86.
>
> As Jakub noted in the BZ the problem is we had an insn with an EH region
> note. That insn gets split and
On Mon, Jan 8, 2018 at 5:45 AM, Jeff Law wrote:
> This patch fixes the second testcase in 81308 and the duplicate in 83724.
>
> For those cases we have a switch statement where one or more case labels
> are marked as __builtin_unreachable.
>
> Switch conversion calls group_case_labels which can dr
On Mon, Jan 8, 2018 at 5:47 AM, Jeff Law wrote:
> On 01/07/2018 07:20 PM, Bill Schmidt wrote:
>> Hi Richard,
>>
>> Unfortunately, I don't see any way that this will be useful for the ppc
>> targets. We don't
>> have a way to force resolution of a condition prior to continuing
>> speculation, so
Hi,
this patch requires stack size for some test-cases that are currently
failing for nvptx with error message:
...
nvptx-run: error launching kernel: invalid argument
(CUDA_ERROR_INVALID_VALUE, 1)
...
Tested on nvptx.
Committed.
Thanks,
- Tom
Require stack size for some test-cases
2018-0
On Mon, Jan 8, 2018 at 2:10 AM, Martin Liška wrote:
> On 01/07/2018 11:59 PM, H.J. Lu wrote:
>> +static void
>> +output_indirect_thunk_function (bool need_bnd_p, int regno)
>> +{
>> + char name[32];
>> + tree decl;
>> +
>> + /* Create __x86_indirect_thunk/__x86_indirect_thunk_bnd. */
>> + ind
On Mon, Jan 8, 2018 at 1:56 AM, Martin Liška wrote:
> On 01/07/2018 11:59 PM, H.J. Lu wrote:
>> Function return thunk is the same as memory thunk for -mindirect-branch=
>> where the return address is at the top of the stack:
>>
>> __x86_return_thunk:
>> call L2
>> L1:
>> lfence
>>
On Mon, Jan 08, 2018 at 03:55:52AM -0800, H.J. Lu wrote:
> > I'm wondering whether thunk creation can be a good target-independent
> > generalization? I guess
> > we can emit the function declaration without direct writes to asm_out_file?
> > And the emission
> > of function body can be potential
On Mon, Jan 8, 2018 at 4:00 AM, Jakub Jelinek wrote:
> On Mon, Jan 08, 2018 at 03:55:52AM -0800, H.J. Lu wrote:
>> > I'm wondering whether thunk creation can be a good target-independent
>> > generalization? I guess
>> > we can emit the function declaration without direct writes to
>> > asm_out_
By switching from int to size_t in order to handle larger values,
r256322 introduced a bug that manifested itself on 32-bit
targets. Fixed by using the correct type to store the result of a
next_array_record call.
Regtested on x86_64-pc-linux-gnu and i686-pc-linux-gnu, committed to
trunk as obviou
Hi Carl,
On Mon, Dec 18, 2017 at 04:10:06PM -0800, Carl Love wrote:
> --- a/gcc/config/rs6000/altivec.md
> +++ b/gcc/config/rs6000/altivec.md
> @@ -1,3 +1,4 @@
> +
> ;; AltiVec patterns.
> ;; Copyright (C) 2002-2017 Free Software Foundation, Inc.
> ;; Contributed by Aldy Hernandez (a...@quesejo
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2018-01-08 Richard Biener
PR lto/83719
* dwarf2out.c (output_indirect_strings): Handle empty
skeleton_debug_str_hash.
(dwarf2out_early_finish): Index strings for -gsplit-dwarf.
* g
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2018-01-08 Richard Biener
PR tree-optimization/83685
* tree-ssa-pre.c (create_expression_by_pieces): Do not insert
references to abnormals.
* gcc.dg/torture/pr83685.c: New testcase.
Index
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk
sofar.
Richard.
2018-01-08 Richard Biener
PR middle-end/83713
* convert.c (do_narrow): Properly guard TYPE_OVERFLOW_WRAPS checks.
* g++.dg/torture/pr83713.C: New testcase.
Index: gcc/convert.c
==
Segher Boessenkool wrote:
> On Fri, Jan 05, 2018 at 12:22:44PM +, Wilco Dijkstra wrote:
>> An example epilog in a shrinkwrapped function before:
>>
>> ldp x21, x22, [sp,#16]
>> ldr x23, [sp,#32]
>> ldr x24, [sp,#40]
>> ldp x25, x26, [sp,#48]
>> ldr x27, [sp,#64]
>> ldr x28, [
Hi,
For nvptx we have:
...
FAIL: gcc.dg/tree-ssa/ssa-dom-cse-2.c scan-tree-dump optimized "return 28;"
...
The test-case is compiled with -O3, which implies -ftree-loop-vectorize
and -ftree-slp-vectorize.
I've investigated the test-case on x86_64, and there the test-case fails
when specifyin
On 25/12/17 23:59 +0200, Ville Voutilainen wrote:
In the midst of the holiday season, the king and ruler of all elves, otherwise
known as The Elf, was told by little elves that users are complaining how
stlstl and libc++ make optional's copy and move operations conditionally
trivial, but libstdc+
Index: htdocs/gcc-7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.96
diff -u -r1.96 changes.html
--- htdocs/gcc-7/changes.html 4 Aug 2017 12:44:54 - 1.96
+++ htdocs/gcc-7/changes.h
On 23/11/17 22:22 +0100, François Dumont wrote:
Gentle reminder for this patch.
I looked when the constructor got unused and I think it is back in
June 2015 in git commit:
commit debb6aabb771ed02cb7256a7719555e5fbd7d3f7
Author: redi
Date: Wed Jun 17 17:45:45 2015 +
* include/b
On 08/01/18 02:20, Bill Schmidt wrote:
> Hi Richard,
>
> Unfortunately, I don't see any way that this will be useful for the ppc
> targets. We don't
> have a way to force resolution of a condition prior to continuing
> speculation, so this
> will just introduce another comparison that we would
> On Jan 7, 2018, at 10:47 PM, Jeff Law wrote:
>
> On 01/07/2018 07:20 PM, Bill Schmidt wrote:
>> Hi Richard,
>>
>> Unfortunately, I don't see any way that this will be useful for the ppc
>> targets. We don't
>> have a way to force resolution of a condition prior to continuing
>> speculation
On Sun, Jan 07, 2018 at 04:36:20PM -0700, Jeff Law wrote:
> On 01/07/2018 03:58 PM, H.J. Lu wrote:
> > This set of patches for GCC 8 mitigates variant #2 of the speculative
> > execution
> > vulnerabilities on x86 processors identified by CVE-2017-5715, aka Spectre.
[snip]
> My fundamental problem
I post this patch early last year and did not submit because I was up
to my eyeballs with PR34640. I just forgot about it until it came up
on clf a few days ago.
Bootstraps and regtests on FC23/x86_64 - OK for trunk?
Paul
2018-01-08 Paul Thomas
PR fortran/52162
* trans-expr.c (gfc_tr
On Mon, Jan 8, 2018 at 6:23 AM, Alan Modra wrote:
> On Sun, Jan 07, 2018 at 04:36:20PM -0700, Jeff Law wrote:
>> On 01/07/2018 03:58 PM, H.J. Lu wrote:
>> > This set of patches for GCC 8 mitigates variant #2 of the speculative
>> > execution
>> > vulnerabilities on x86 processors identified by CV
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2018-01-08 Richard Biener
PR tree-optimization/83563
* graphite.c (canonicalize_loop_closed_ssa_form): Reset the SCEV
cache.
* gcc.dg/graphite/pr83563.c: New testcase.
Index: gcc/graphite
Hello,
This patch reverts the changes introduced by r255946 and further changes
to that done by r256195, as the former causes large number of regressions
on aarch64_be* targets. This should be respun with the mismatch in lane
numbering in AArch64 and GCC's numbering fixed as explained in PR83663.
On Mon, Jan 08, 2018 at 07:00:11AM -0800, H.J. Lu wrote:
> See:
>
> https://sourceware.org/ml/binutils/2017-11/msg00369.html
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x00 0x 0x 0x00200 0x00200 R 0x20
LO
On Fri, 2017-12-01 at 16:45 -0600, Segher Boessenkool wrote:
> Looks good otherwise. I'll ok it when there is a user (or a
> testcase).
> It shouldn't go in before the canonicalize_condition patch, of
> course.
The canonicalize_condition patch is in, so I have checked in this
cleanup and addition
Hi all,
We don't have the t-aprofile, t-multilib and t-arm-elf mapping
rules for multilibs when using the variants of -march=armv8.3-a
and the dotproduct extension.
This patch adds them. -march=armv8.3-a behaves in the same
way as -march=armv8.2-a in this regard.
Bootstrapped and tested with the
> [ARC][LRA] Use TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV.
> [ARC] Don't allow the last ZOL insn to be in a delay slot.
> [ARC] Add trap instruction.
> [ARC] Update legitimate constant hook.
> [ARC] Enable unaligned access.
> [ARC] Revamp trampoline implementation.
> [ARC][ZOL] Update uses
On 08/01/18 14:19, Bill Schmidt wrote:
>
>> On Jan 7, 2018, at 10:47 PM, Jeff Law wrote:
>>
>> On 01/07/2018 07:20 PM, Bill Schmidt wrote:
>>> Hi Richard,
>>>
>>> Unfortunately, I don't see any way that this will be useful for the ppc
>>> targets. We don't
>>> have a way to force resolution of
Hi Guys,
It seems to me that it might be worth taking a step back here,
and consider adding a security framework to gcc. Mitigations
for CVEs in the past have resulted in individual patches being
added to gcc, oftern in a target specific manner, and with no
real framework to support the
Hi!
On Thu, Jan 04, 2018 at 08:16:06AM -0600, Bill Schmidt wrote:
> https://gcc.gnu.org/PR83677 reports that generation of xxpermr is always
> wrong. It effectively inverts the order of the two input registers from
> what they should be. This patch addresses that and provides a test case
> modif
On Jan 8, 2018, at 8:06 AM, Richard Earnshaw (lists)
wrote:
>
> On 08/01/18 02:20, Bill Schmidt wrote:
>> Hi Richard,
>>
>> Unfortunately, I don't see any way that this will be useful for the ppc
>> targets. We don't
>> have a way to force resolution of a condition prior to continuing
>> spe
Hi Nathan,
> On 01/02/2018 09:36 AM, Marek Polacek wrote:
>> This test exercising inheriting a template constructor in this PR got
>> fixed with
>> r251426. As I don't see any lambdas here, I thought it worth to add it.
>>
>> Tested on x86_64-linux, ok for trunk?
>>
>> 2018-01-02 Marek Polacek
I thought about your new builtin again, and I wonder if
something like that might work as well?
cat despec.s
.arch armv7-a
.eabi_attribute 28, 1
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_at
On Mon, Jan 8, 2018 at 7:06 AM, Jakub Jelinek wrote:
> On Mon, Jan 08, 2018 at 07:00:11AM -0800, H.J. Lu wrote:
>> See:
>>
>> https://sourceware.org/ml/binutils/2017-11/msg00369.html
>
> Program Headers:
> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> LOAD
On Thu, Jan 04, 2018 at 06:05:55PM -0500, Michael Meissner wrote:
> This patch is the beginning step to switching the PowerPC long double support
> from IBM extended double to IEEE 128-bit floating point on PowerPC servers.
> It
> will be necessary to have this patch or a similar patch to allow t
This PR skips saving of any registers in main.
Attribute OS_main can do this as well, however we can just drop
any saves / restores in all optimized compilation -- not even
the test suite needs these saves.
The feature can still be switched off by new -mno-OS_main
Ok for trunk?
gcc/
D
On Mon, Jan 08, 2018 at 08:17:27AM -0800, H.J. Lu wrote:
> On Mon, Jan 8, 2018 at 7:06 AM, Jakub Jelinek wrote:
> > On Mon, Jan 08, 2018 at 07:00:11AM -0800, H.J. Lu wrote:
> >> See:
> >>
> >> https://sourceware.org/ml/binutils/2017-11/msg00369.html
> >
> > Program Headers:
> > Type Of
On 12/18/2017 05:57 PM, Vladimir Makarov wrote:
On 12/15/2017 06:25 AM, Tom de Vries wrote:
Proposed Solution:
The patch addresses the problem, by:
- marking the hard regs that have been used in lra_spill in
hard_regs_spilled_into
- using hard_regs_spilled_into in lra_create_live_ranges to
On Jan 8, 2018, at 9:23 AM, Richard Earnshaw (lists)
wrote:
>
> On 08/01/18 14:19, Bill Schmidt wrote:
>>
>>> On Jan 7, 2018, at 10:47 PM, Jeff Law wrote:
>>>
>>> On 01/07/2018 07:20 PM, Bill Schmidt wrote:
Hi Richard,
Unfortunately, I don't see any way that this will be usefu
On Fri, 2018-01-05 at 17:20 -0500, David Malcolm wrote:
> On Fri, 2018-01-05 at 15:29 -0500, Jason Merrill wrote:
> > On 12/29/2017 12:06 PM, David Malcolm wrote:
> > > One issue I ran into was that fold_for_warn doesn't eliminate
> > > location wrappers when processing_template_decl, leading to
>
On 01/08/2018 12:02 PM, David Malcolm wrote:
On Fri, 2018-01-05 at 17:20 -0500, David Malcolm wrote:
Doing so uncovered an issue which I'm not sure how to resolve: it's
possible for a decl to change type during parsing, after location
wrappers may have been created, which changes location_wrap
Hi,
On Mon, 8 Jan 2018, Jakub Jelinek wrote:
> On Mon, Jan 08, 2018 at 07:00:11AM -0800, H.J. Lu wrote:
> > See:
> >
> > https://sourceware.org/ml/binutils/2017-11/msg00369.html
>
> Program Headers:
> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> LOAD 0
On Mon, Jan 08, 2018 at 12:10:50PM -0500, Nathan Sidwell wrote:
> > Both "_S_terminal" VAR_DECLs have a "_CharT" TEMPLATE_TYPE_PARM, but
> > these types are different tree nodes.
>
> correct. they are not EQ but are EQUAL (same_type_p will be true).
So perhaps location_wrapper_p could use that in
Hi,
On Mon, 8 Jan 2018, H.J. Lu wrote:
> On Mon, Jan 8, 2018 at 4:00 AM, Jakub Jelinek wrote:
> > On Mon, Jan 08, 2018 at 03:55:52AM -0800, H.J. Lu wrote:
> >> > I'm wondering whether thunk creation can be a good target-independent
> >> > generalization? I guess
> >> > we can emit the function
On Mon, Jan 8, 2018 at 9:18 AM, Michael Matz wrote:
> Hi,
>
> On Mon, 8 Jan 2018, H.J. Lu wrote:
>
>> On Mon, Jan 8, 2018 at 4:00 AM, Jakub Jelinek wrote:
>> > On Mon, Jan 08, 2018 at 03:55:52AM -0800, H.J. Lu wrote:
>> >> > I'm wondering whether thunk creation can be a good target-independent
>
On 01/08/2018 12:14 PM, Jakub Jelinek wrote:
On Mon, Jan 08, 2018 at 12:10:50PM -0500, Nathan Sidwell wrote:
Both "_S_terminal" VAR_DECLs have a "_CharT" TEMPLATE_TYPE_PARM, but
these types are different tree nodes.
correct. they are not EQ but are EQUAL (same_type_p will be true).
So perhap
On Mon, Jan 08, 2018 at 10:17:06AM -0600, Segher Boessenkool wrote:
> On Thu, Jan 04, 2018 at 06:05:55PM -0500, Michael Meissner wrote:
> > This patch is the beginning step to switching the PowerPC long double
> > support
> > from IBM extended double to IEEE 128-bit floating point on PowerPC serve
* H. J. Lu:
> This set of patches for GCC 8 mitigates variant #2 of the
> speculative execution vulnerabilities on x86 processors identified
> by CVE-2017-5715, aka Spectre. They convert indirect branches to
> call and return thunks to avoid speculative execution via indirect
> call and jmp.
Wou
* Sandra Loosemore:
> I have a general documentation issue with all the new command-line
> options and attributes added by this patch set: the documentation is
> very implementor-speaky and doesn't explain what user-level problem
> they're trying to solve.
Agreed. Ideally, the documentation
2018-01-08 20:19 GMT+04:00 Georg-Johann Lay :
> This PR skips saving of any registers in main.
>
> Attribute OS_main can do this as well, however we can just drop
> any saves / restores in all optimized compilation -- not even
> the test suite needs these saves.
>
> The feature can still be switche
On Mon, 2018-01-08 at 09:25 -0800, H.J. Lu wrote:
> On Mon, Jan 8, 2018 at 9:18 AM, Michael Matz wrote:
> >
> > Hi,
> >
> > On Mon, 8 Jan 2018, H.J. Lu wrote:
> >
> > >
> > > On Mon, Jan 8, 2018 at 4:00 AM, Jakub Jelinek wrote:
> > > >
> > > > On Mon, Jan 08, 2018 at 03:55:52AM -0800, H.J. L
On 08/01/18 16:10, Bernd Edlinger wrote:
> I thought about your new builtin again, and I wonder if
> something like that might work as well?
>
>
> cat despec.s
> .arch armv7-a
> .eabi_attribute 28, 1
> .eabi_attribute 20, 1
> .eabi_attribute 21, 1
> .eabi_attribute 2
Hi all,
This patch adds the +fp16fml extension that enables some
half-precision floating-point Advanced SIMD instructions,
available through arm_neon.h intrinsics.
This extension is on by default for armv8.4-a
if fp16 is available, so it can be enabled by -march=armv8.4-a+fp16.
fp16fml is also
Hi all,
This patch implements the lane-wise fp16fml intrinsics.
There's quite a few of them so I've split them up from
the other simpler fp16fml intrinsics.
These ones expose instructions such as
vfmal.f16 Dd, Sn, Sm[] 0 <= index <= 1
vfmal.f16 Qd, Dn, Dm[] 0 <= index <= 3
vfmsl.f16 Dd, Sn, S
[resending due to mailer problems...]
Hi all,
This patch adds support for the Armv8.4-A architecture [1]
in the arm backend. This is done through the new
-march=armv8.4-a option.
With this patch armv8.4-a is recognised as an argument
and supports the extensions: simd, fp16, crypto, nocrypto,
no
On Mon, 2018-01-08 at 12:25 -0500, Nathan Sidwell wrote:
> On 01/08/2018 12:14 PM, Jakub Jelinek wrote:
> > On Mon, Jan 08, 2018 at 12:10:50PM -0500, Nathan Sidwell wrote:
> > > > Both "_S_terminal" VAR_DECLs have a "_CharT"
> > > > TEMPLATE_TYPE_PARM, but
> > > > these types are different tree nod
On Mon, Jan 08, 2018 at 01:02:37PM -0500, David Malcolm wrote:
> Thanks Nathan and Jakub: a quick smoketest using TREE_LANG_FLAG_0
> worked, and fixes this issue.
>
> However, should I be using a TREE_LANG_FLAG for something that's in
> tree.h/c, rather than just in the "cp" subdir? (the wrapper
On Mon, Jan 08, 2018 at 01:27:24PM +, Wilco Dijkstra wrote:
> Segher Boessenkool wrote:
> > On Fri, Jan 05, 2018 at 12:22:44PM +, Wilco Dijkstra wrote:
> >> An example epilog in a shrinkwrapped function before:
> >>
> >> ldp x21, x22, [sp,#16]
> >> ldr x23, [sp,#32]
> >> ldr x24,
* H. J. Lu:
> On Mon, Jan 8, 2018 at 12:20 AM, Florian Weimer wrote:
>> * H. J. Lu:
>>
>>> Add -mindirect-branch-loop= option to control loop filler in call and
>>> return thunks generated by -mindirect-branch=. 'lfence' uses "lfence"
>>> as loop filler. 'pause' uses "pause" as loop filler. 'n
On 1/3/18 11:43 AM, Janne Blomqvist wrote:
On Wed, Jan 3, 2018 at 8:34 PM, Bob Deen wrote:
On 12/29/17 5:31 AM, Janne Blomqvist wrote:
In order to handle large character lengths on (L)LP64 targets, switch
the GFortran character length from an int to a size_t.
This is an ABI change, as proced
Formatting fixed.
diff --git a/libstdc++-v3/include/tr1/bessel_function.tcc
b/libstdc++-v3/include/tr1/bessel_function.tcc
index 7ac733d..5f8fc9f 100644
--- a/libstdc++-v3/include/tr1/bessel_function.tcc
+++ b/libstdc++-v3/include/tr1/bessel_function.tcc
@@ -27,6 +27,10 @@
* Do not attempt t
On Mon, Jan 8, 2018 at 10:32 AM, Florian Weimer wrote:
> * H. J. Lu:
>
>> On Mon, Jan 8, 2018 at 12:20 AM, Florian Weimer wrote:
>>> * H. J. Lu:
>>>
Add -mindirect-branch-loop= option to control loop filler in call and
return thunks generated by -mindirect-branch=. 'lfence' uses "lfenc
On Sat, 2018-01-06 at 08:44 +0100, Richard Biener wrote:
> On January 5, 2018 11:55:11 PM GMT+01:00, David Malcolm hat.com> wrote:
> > On Fri, 2018-01-05 at 10:36 +0100, Richard Biener wrote:
> > > On Thu, Jan 4, 2018 at 10:52 PM, David Malcolm > > om>
> > > wrote:
> > > > PR lto/83121 reports an
On Tue, 2017-12-12 at 10:13 -0600, Segher Boessenkool wrote:
> Please fix those trivialities, and it's okay for trunk (after the
> rtlanal patch is approved too). Thanks!
Here's the final version of this, which is committed as 256351.
2018-01-08 Aaron Sawdey
* config/rs6000/rs6000-s
On 01/08/2018 07:19 AM, Bill Schmidt wrote:
>
>> On Jan 7, 2018, at 10:47 PM, Jeff Law wrote:
>>
>> On 01/07/2018 07:20 PM, Bill Schmidt wrote:
>>> Hi Richard,
>>>
>>> Unfortunately, I don't see any way that this will be useful for the ppc
>>> targets. We don't
>>> have a way to force resolutio
Hello!
Attached patch corrects wrong mode argument in the call to
force_to_mode call for ASHIFT operator. The patch uses "mode" mode,
the same as for all binop and unop operators in the force_int_to_mode
function.
Also, the unpatched function would force operand to op_mode and later
truncate to o
Segher Boessenkool wrote:
> On Mon, Jan 08, 2018 at 01:27:24PM +, Wilco Dijkstra wrote:
>
>> Peepholing is very conservative about instructions using SP and won't touch
>> anything frame related. If this was working better then the backend could
>> just
>> emit single loads/stores and let peep
On Mon, 2018-01-08 at 09:27 +0100, Florian Weimer wrote:
> * H. J. Lu:
>
> >
> > This set of patches for GCC 8 mitigates variant #2 of the
> > speculative execution vulnerabilities on x86 processors identified
> > by CVE-2017-5715, aka Spectre. They convert indirect branches to
> > call and retu
Committed as obvious.
Index: ChangeLog
===
--- ChangeLog (revision 256351)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2018-01-08 Steven G. Kargl
+
+ * expr.c (gfc_check_pointer_assign): Fix typo in comment.
+
2018-01-
On Sun, 2018-01-07 at 16:36 -0700, Jeff Law wrote:
>
> My fundamental problem with this patchkit is that it is 100% x86/x86_64
> specific.
>
> ISTM we want a target independent mechanism (ie, new standard patterns,
> options, etc) then an x86/x86_64 implementation using that target
> independent
On Mon, 2018-01-08 at 09:20 +0100, Florian Weimer wrote:
> * H. J. Lu:
>
> > Add -mindirect-branch-loop= option to control loop filler in call and
> > return thunks generated by -mindirect-branch=. 'lfence' uses "lfence"
> > as loop filler. 'pause' uses "pause" as loop filler. 'nop' uses "nop"
On Fri, 2018-01-05 at 15:29 -0500, Jason Merrill wrote:
> On 12/29/2017 12:06 PM, David Malcolm wrote:
> > One issue I ran into was that fold_for_warn doesn't eliminate
> > location wrappers when processing_template_decl, leading to
> > failures of the template-based cases in
> > g++.dg/warn/Wmemse
On Jan 8, 2018, at 1:40 PM, Jeff Law wrote:
>
> On 01/08/2018 07:19 AM, Bill Schmidt wrote:
>>
>>> On Jan 7, 2018, at 10:47 PM, Jeff Law wrote:
>>>
>>> On 01/07/2018 07:20 PM, Bill Schmidt wrote:
Hi Richard,
Unfortunately, I don't see any way that this will be useful for the pp
On Mon, Jan 8, 2018 at 1:00 PM, David Woodhouse wrote:
> On Mon, 2018-01-08 at 09:20 +0100, Florian Weimer wrote:
>> * H. J. Lu:
>>
>> > Add -mindirect-branch-loop= option to control loop filler in call and
>> > return thunks generated by -mindirect-branch=. 'lfence' uses "lfence"
>> > as loop fi
On Mon, 2018-01-08 at 03:59 -0800, H.J. Lu wrote:
> On Mon, Jan 8, 2018 at 1:56 AM, Martin Liška wrote:
> >
> > On 01/07/2018 11:59 PM, H.J. Lu wrote:
> > >
> > > Function return thunk is the same as memory thunk for -mindirect-branch=
> > > where the return address is at the top of the stack:
>
"H.J. Lu" writes:
>>
>> Talking about PIC thunks, those have I believe . character in their symbols,
>> so that they can't be confused with user functions. Any reason these
>> retpoline thunks aren't?
>>
>
> They used to have '.'. It was changed at the last minute since kernel needs
> to
> expo
On Mon, Jan 08, 2018 at 08:25:47PM +, Wilco Dijkstra wrote:
> > Always pairing two registers together *also* degrades code quality.
>
> No, while it's not optimal, it means smaller code and fewer memory accesses.
It means you execute *more* memory accesses. Always. This may be
sometimes hid
Hi
Bug confirmed, limited to range insertion on unordered_set and
unordered_map.
I had to specialize _M_insert_range for those containers. Now this
method maintains the theoretical number of elements to insert which is
used only if an insertion takes place.
I also took this opo
On Mon, Jan 8, 2018 at 8:46 AM, Andi Kleen wrote:
> "H.J. Lu" writes:
>>>
>>> Talking about PIC thunks, those have I believe . character in their symbols,
>>> so that they can't be confused with user functions. Any reason these
>>> retpoline thunks aren't?
>>>
>>
>> They used to have '.'. It wa
On Mon, 2018-01-08 at 13:32 -0800, H.J. Lu wrote:
> On Mon, Jan 8, 2018 at 8:46 AM, Andi Kleen wrote:
> >
> > "H.J. Lu" writes:
> > >
> > > >
> > > >
> > > > Talking about PIC thunks, those have I believe . character in their
> > > > symbols,
> > > > so that they can't be confused with user
1 - 100 of 125 matches
Mail list logo
