On January 9, 2018 12:52:47 AM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>Matthias reported that -freport-bug may insert preprocessor diagnostics
>into middle of the preprocessed dump generated by -freport-bug.
>The diagnostic text in there is intentional, but should be at the
>beginning
>of the fil
On January 9, 2018 12:59:04 AM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>SMS is done before reload and assumes it can extend the lifetime by
>making
>copies of the destination registers without trying to re-recognize the
>instructions etc. That can work only with pseudos, for some hard
>registers
On Mon, Jan 08, 2018 at 06:51:06PM -0800, Jerry DeLisle wrote:
> On 01/08/2018 04:58 PM, Steve Kargl wrote:
> > On Sun, Jan 07, 2018 at 06:52:22PM -0800, Steve Kargl wrote:
> >>
> >> I have zero knowledge about co-arrays and especially zero
> >> knowledge about gfortran internals for co-arrays. I'
On 01/08/2018 04:28 AM, Richard Biener wrote:
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
a
On 01/08/2018 04:58 PM, Steve Kargl wrote:
> On Sun, Jan 07, 2018 at 06:52:22PM -0800, Steve Kargl wrote:
>>
>> I have zero knowledge about co-arrays and especially zero
>> knowledge about gfortran internals for co-arrays. I'm
>> disinclined to waste another 12 hours trying to get gfortran
>> to e
On Mon, Jan 08, 2018 at 05:33:01PM -0800, Damian Rouson wrote:
> I’ll be glad to test with -fcoarray=lib -lcaf_mpi with two caveats:
>
> 1. My turnaround time will probably usually be 48-72 hours for
> such tests.
Turn around time is unimportant to me. I'm simply interested if
what I have done w
I’ll be glad to test with -fcoarray=lib -lcaf_mpi with two caveats:
1. My turnaround time will probably usually be 48-72 hours for such tests.
2. I don’t monitor this mailing list very closely so I might miss similar
requests unless they are also submitted as issues on the OpenCoarrays GitHub
This patch updates libgo to the Go1.10beta1 release. The final Go
1.10 release is expected around February 1, so it's not clear how the
release timing is going to work with GCC 8. In any case this updates
GCC to something pretty close to the final Go 1.10 release.
A few changes to the frontend w
Committed as obvious. Forgot the testcase. I'll commit that shortly.
2018-01-08 Steven G. Kargl
* match.c (gfc_match_allocate): Check for NULL pointer.
Index: match.c
===
--- match.c (revision 256363)
+++ match.c
On 01/08/2018 04:40 AM, Richard Biener wrote:
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 suc
The gcc-7-branch version of the patch.
2018-01-08 Monk Chiang
Kito Cheng
gcc/
* config/riscv/riscv.c (machine_function::is_leaf): Remove field.
(riscv_leaf_function_p): Delete.
(riscv_function_ok_for_sibcall): Return false when TARGET
On Sun, Jan 07, 2018 at 06:52:22PM -0800, Steve Kargl wrote:
>
> I have zero knowledge about co-arrays and especially zero
> knowledge about gfortran internals for co-arrays. I'm
> disinclined to waste another 12 hours trying to get gfortran
> to emit essentially a call to this_image(). See ires
This fixes a bug originally reported at
https://github.com/riscv/riscv-gcc/issues/115
where mixing -msave-restore and sibcall optimizations results in corrupted
call-save registers, because we are restoring them from a different offset
in the epilogue than they were saved in the prologue. The
On Tue, 2018-01-09 at 00:02 +0100, Michael Matz wrote:
> Hi,
>
> On Mon, 8 Jan 2018, Woodhouse, David wrote:
>
> >
> > >
> > > >
> > > > That can be done via asm aliases or direct assembler use; the kernel
> > > > doesn't absolutely have to access them via C compatible symbol names.
> > > >
>
Hi!
SMS is done before reload and assumes it can extend the lifetime by making
copies of the destination registers without trying to re-recognize the
instructions etc. That can work only with pseudos, for some hard registers
there isn't even a valid move instruction to pseudo (e.g. the powerpc CA
Hi!
The assert there assumes we never evaluate a statement list to
DEBUG_BEGIN_STMT, but it breaks appart when a BIND_EXPR with a typedef in it
has some DEBUG_BEGIN_STMTs in it and nothing else (without -g it is just
empty STATEMENT_LIST inside of the BIND_EXPR). We want to return void_node
in th
Hi!
Matthias reported that -freport-bug may insert preprocessor diagnostics
into middle of the preprocessed dump generated by -freport-bug.
The diagnostic text in there is intentional, but should be at the beginning
of the file and each line prefixed with //, which is done, but then
because of the
Thanks for the review! Committed with suggested changes as r256358.
Hi,
On Mon, 8 Jan 2018, Woodhouse, David wrote:
> > > That can be done via asm aliases or direct assembler use; the kernel
> > > doesn't absolutely have to access them via C compatible symbol names.
> > >
> > Hi David,
> >
> > Can you comment on this?
>
> It ends up being a real pain for the C
On Mon, 2018-01-08 at 14:27 -0800, Andi Kleen wrote:
> On Mon, Jan 08, 2018 at 09:35:26PM +, David Woodhouse wrote:
> > 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:
> > > > >
> > > > > >
> > > >
On Mon, Jan 08, 2018 at 09:35:26PM +, David Woodhouse wrote:
> 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 . chara
On 01/08/2018 04:49 PM, Jason Merrill wrote:
On 01/08/2018 04:01 PM, David Malcolm wrote:
On Fri, 2018-01-05 at 15:29 -0500, Jason Merrill wrote:
I'd rather handle location wrappers separately, and abort if
VIEW_CONVERT_EXPR or NON_LVALUE_EXPR appear other than as wrappers.
Once I fixed the
On 01/08/2018 04:01 PM, David Malcolm wrote:
On Fri, 2018-01-05 at 15:29 -0500, Jason Merrill wrote:
I'd rather handle location wrappers separately, and abort if
VIEW_CONVERT_EXPR or NON_LVALUE_EXPR appear other than as wrappers.
Once I fixed the issue with location_wrapper_p with decls chang
Hi Janne,
If I understand it correctly, in the library the back argument is
always a LOGICAL(kind=4). But in the frontend, the back argument is
coerced to gfc_default_logical_kind. So this doesn't work if one uses
the -fdefault-integer-8 option, because then gfc_default_logical_kind
will be 8.
On 01/05/2018 05:20 PM, 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:
@@ -24998,6 +25018,8 @@ build_non_dependent_expr (tree expr)
&& !expanding_concept ())
fold_non_dependent_expr (expr);
+ STRIP_ANY_
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
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
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
"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
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:
>
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 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 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 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 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
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 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
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
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
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
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 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 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
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 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
* 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 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,
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, 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
[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
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
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
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
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
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
* 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
* 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
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
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 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
>
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 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, 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 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
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 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 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 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
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 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
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
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
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
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!
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
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
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
> [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
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
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
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
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.
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
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
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 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
> 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 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 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
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 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+
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
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, [
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
==
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.
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
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
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
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_
1 - 100 of 125 matches
Mail list logo
