On Mon, 29 Jan 2018, Jeff Law wrote:
> On 01/29/2018 04:37 PM, Jakub Jelinek wrote:
> > Hi!
> >
> > As mentioned in the PR, cunroll sometimes registers some SSA_NAMEs for
> > renaming and then invokes some SCEV using functions before finally updating
> > the SSA form. On the testcase we end up w
On Mon, Jan 29, 2018 at 11:58:45PM -0700, Jeff Law wrote:
> On 01/29/2018 04:37 PM, Jakub Jelinek wrote:
> > Hi!
> >
> > As mentioned in the PR, cunroll sometimes registers some SSA_NAMEs for
> > renaming and then invokes some SCEV using functions before finally updating
> > the SSA form. On the
cpplib-8.1-b20180128.vi.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Vietnamese team of translators. The file is available at:
http://translationproject.org/latest/cpplib/vi.po
(This file, 'cpplib-8.1-b20180
Hello,
If masked variant of vpopcnt[w,q] is being issued: there's no way for reload
to put 32/64 bit mask into mask register, since kmov[d,q] are only available
under -mavx512bw switch.
We can insist user to issue -mavx512bw along w/ -mavx512bitalg if she is
going to use masked variants of corresp
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Russian team of translators. The file is available at:
http://translationproject.org/latest/gcc/ru.po
(This file, 'gcc-8.1-b20180128.ru.po',
On Tue, Jan 30, 2018 at 08:59:43AM +0100, Richard Biener wrote:
> The issue is that
>
> static bool
> tree_unroll_loops_completely_1 (bool may_increase_size, bool unroll_outer,
> bitmap father_bbs, struct loop *loop)
> {
> struct loop *loop_father;
> bool change
Renamed it. Ok for trunk?
gcc/c-family/
* c-common.h (omp_clause_mask): Move to wide_int_bitmask.h
gcc/
* config/i386/i386.c (ix86_option_override_internal): Change flags type
to
wide_int_bitmask.
* wide-int-bitmask.h: New.
Thanks,
Julia
> -Original Message
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Swedish team of translators. The file is available at:
http://translationproject.org/latest/cpplib/sv.po
(This file, 'cpplib-8.1-b20180128
cpplib-8.1-b20180128.sv.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
On Tue, Jan 30, 2018 at 08:35:38AM +, Koval, Julia wrote:
> * c-common.h (omp_clause_mask): Move to wide_int_bitmask.h
Missing dot ad the end.
+ wide_int_bitmask PTA_3DNOW (HOST_WIDE_INT_1U << 0);
Can't all these be const wide_int_bitmask instead of just
wide_int_bitmask?
...
+
+ wi
On Tue, 30 Jan 2018, Jakub Jelinek wrote:
> On Tue, Jan 30, 2018 at 08:59:43AM +0100, Richard Biener wrote:
> > The issue is that
> >
> > static bool
> > tree_unroll_loops_completely_1 (bool may_increase_size, bool unroll_outer,
> > bitmap father_bbs, struct loop *
Segher Boessenkool writes:
> On Mon, Jan 29, 2018 at 11:41:32PM +0100, Jakub Jelinek wrote:
>> On Mon, Jan 29, 2018 at 04:26:50PM -0600, Segher Boessenkool wrote:
>> > > The code actually meant pointer comparison, the question is what is
>> > > different on powerpc* that you end up with a differen
On Jan 29 2018, Jeff Law wrote:
> On 01/07/2018 10:09 AM, Segher Boessenkool wrote:
>> Hi!
>>
>> On Sun, Jan 07, 2018 at 12:58:25AM -0700, Jeff Law wrote:
>>> diff --git a/gcc/testsuite/gcc.target/powerpc/pr56605.c
>>> b/gcc/testsuite/gcc.target/powerpc/pr56605.c
>>> index 3bc335f..be6456c 1006
On Tue, Jan 30, 2018 at 09:41:47AM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Mon, Jan 29, 2018 at 11:41:32PM +0100, Jakub Jelinek wrote:
> >> On Mon, Jan 29, 2018 at 04:26:50PM -0600, Segher Boessenkool wrote:
> >> > > The code actually meant pointer comparison, the quest
This patch tries to deal with the "easy" part of a function ABI,
the return value location, in vectorization costing. The testcase
shows that if we vectorize the returned value but the function
doesn't return in memory or in a vector register but as in this
case in an integer register pair (reg:T
Segher Boessenkool writes:
> On Tue, Jan 30, 2018 at 09:41:47AM +, Richard Sandiford wrote:
>> Segher Boessenkool writes:
>> > On Mon, Jan 29, 2018 at 11:41:32PM +0100, Jakub Jelinek wrote:
>> >> On Mon, Jan 29, 2018 at 04:26:50PM -0600, Segher Boessenkool wrote:
>> >> > > The code actually m
I have been asked to push this change, fixing (somewhat) the impreciseness
of costing constant/invariant vector uses in SLP stmts. The previous
code always just considered a single constant to be generated in the
prologue irrespective of how many we'd need. With this patch we
properly handle thi
On Tue, Jan 30, 2018 at 03:55:58AM -0600, Segher Boessenkool wrote:
> > But in that case, what does the copying?
>
> I don't know. Aaron will look at it, but timezones etc. :-)
>
> > That's what seems strange. I can see why we'd have two nested
> > pluses with the inner plus being pointer-equal
On Tue, Jan 30, 2018 at 11:07:50AM +0100, Richard Biener wrote:
>
> I have been asked to push this change, fixing (somewhat) the impreciseness
> of costing constant/invariant vector uses in SLP stmts. The previous
> code always just considered a single constant to be generated in the
> prologue i
Thank you for your comments, fixed them and rebased Ice Lake patch on top of
it. Ok for trunk?
Bitmask patch changelog:
gcc/c-family/
* c-common.h (omp_clause_mask): Move to wide_int_bitmask.h.
gcc/
* config/i386/i386.c (ix86_option_override_internal): Change flags type
to
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Brazilian Portuguese team of translators. The file is available at:
http://translationproject.org/latest/cpplib/pt_BR.po
(This file, 'cppl
cpplib-8.1-b20180128.pt_BR.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
On Tue, 2018-01-30 at 11:13 +0100, Jakub Jelinek wrote:
> On Tue, Jan 30, 2018 at 03:55:58AM -0600, Segher Boessenkool wrote:
> > > But in that case, what does the copying?
> >
> > I don't know. Aaron will look at it, but timezones etc. :-)
Indeed I did see unshare_all_rtl() copying internal_arg
On 30/01/18 10:19 +0300, Petr Ovtchenkov wrote:
On Tue, 19 Dec 2017 11:37:43 +0300
Petr Ovtchenkov wrote:
ping^3
I don't fully understand the consequences (or need) for this patch.
I asked some other people to look at it, and didn't get confirmation
it's OK. So I'm reluctant to make the cha
On Tue, Jan 30, 2018 at 06:50:50AM -0600, Aaron Sawdey wrote:
> > Anyway, my preference would be to change that gen_rtx_PLUS into
> > stack_parm = crtl->args.internal_arg_pointer;
> > if (!CONST_INT_P (offset_rtx))
> > stack_parm = gen_rtx_PLUS (Pmode, stack_parm, offset_rtx);
> > else if
Hi,
this patch fixed ICE that was introduced by Richard Standiford's change to
reorder
can and want_inline predicates to reduce amount of work done to verify inlining
limits.
This bypasses check that the function is optimized that makes inliner to ICE
because
function summary is missing.
This p
Hi,
this PR is about rounding issue of sreal->integer conversion. I converted the
whole
code to sreals but the change seems bit too big and with no practical
improvement
to be justifiable, so this patch goes by simply fixing the template for current
roundoff
error. Hopefully counter code is now
Hi Joseph,
> On Fri, 12 Jan 2018, Rainer Orth wrote:
>
>> At the same time, I had a new look at when values-Xc.o is used by the
>> Studio compilers. It selects strict ISO C mode in a couple of cases,
>> and the latest Studio 12.6 cc, which is about to do away with the
>> previous -Xc option which
x32 is a 64-bit process with 32-bit software pointer and kernel may
place x32 shadow stack above 4GB. We need to save and restore 64-bit
shadow stack register for x32. builtin jmp buf size is 5 pointers. We
have space to save 64-bit shadow stack pointer: 32-bit SP, 32-bit FP,
32-bit IP, 64-bit SS
On Tue, 30 Jan 2018, Richard Biener wrote:
>
> This patch tries to deal with the "easy" part of a function ABI,
> the return value location, in vectorization costing. The testcase
> shows that if we vectorize the returned value but the function
> doesn't return in memory or in a vector register
On Tue, Jan 30, 2018 at 3:19 PM, Tsimbalist, Igor V
wrote:
> x32 is a 64-bit process with 32-bit software pointer and kernel may
> place x32 shadow stack above 4GB. We need to save and restore 64-bit
> shadow stack register for x32. builtin jmp buf size is 5 pointers. We
> have space to save 64-
On Tue, 30 Jan 2018, Rainer Orth wrote:
> So it seems the following snippet
>
> #define STARTFILE_ARCH_SPEC \
> [...]
> %{std=c9*|std=iso9899\\:199409|std=c1*:values-Xc.o%s; :values-Xa.o%s} \
>
> seems like the right thing to do, as you said.
That version would need updating when we add -s
On Tue, Jan 30, 2018 at 6:38 AM, Uros Bizjak wrote:
> On Tue, Jan 30, 2018 at 3:19 PM, Tsimbalist, Igor V
> wrote:
>> x32 is a 64-bit process with 32-bit software pointer and kernel may
>> place x32 shadow stack above 4GB. We need to save and restore 64-bit
>> shadow stack register for x32. buil
Hi Joseph,
> On Tue, 30 Jan 2018, Rainer Orth wrote:
>
>> So it seems the following snippet
>>
>> #define STARTFILE_ARCH_SPEC \
>> [...]
>> %{std=c9*|std=iso9899\\:199409|std=c1*:values-Xc.o%s; :values-Xa.o%s} \
>>
>> seems like the right thing to do, as you said.
>
> That version would nee
On 30/01/18 15:51 +0100, Rainer Orth wrote:
Hi Joseph,
On Tue, 30 Jan 2018, Rainer Orth wrote:
So it seems the following snippet
#define STARTFILE_ARCH_SPEC \
[...]
%{std=c9*|std=iso9899\\:199409|std=c1*:values-Xc.o%s; :values-Xa.o%s} \
seems like the right thing to do, as you said.
Hi Richard,
Thanks for the review!
On 29/01/18 20:23, Richard Sandiford wrote:
The patch looks good to me FWIW. How about adding something like
the following testcase?
/* { dg-do run } */
/* { dg-options "-O2" } */
typedef void (*fun) (void);
void __att
Hi!
We don't want to move /f instructions across jumps in either direction,
sched_analyze_insn has code for that by adding the insn into
sched_before_next_jump list and by adding anti dependence against
pending_jump_insns. That works fine, as long as we don't flush the
dependency lists, flush_pen
On Tue, 2018-01-30 at 14:04 +0100, Jakub Jelinek wrote:
> On IRC when discussing it with Segher this morning we've come to the
> conclusion that it would be best if rs6000 just followed what all
> other
> ports to, i.e. return a pseudo from the target hook, like:
>
> --- gcc/config/rs6000/rs6000.c
On Tue, Jan 30, 2018 at 10:21:33AM -0600, Aaron Sawdey wrote:
> 2018-01-30 Aaron Sawdey
>
> * config/rs6000/rs6000.c (rs6000_internal_arg_pointer ): Only return
No space before ): . Will defer ack to Segher or David.
> a reg rtx.
> Index: gcc/config/rs6000/rs6000.c
> ===
PING
On Tue, Jan 23, 2018 at 3:31 PM, Janne Blomqvist
wrote:
> As part of the change to larger character lengths, the string copy
> algorithm was temporarily pessimized to get around some spurious
> -Wstringop-overflow warnings. Having tried a number of variations of
> this algorithm I have mana
PING**2
On Wed, Jan 17, 2018 at 8:02 PM, Janne Blomqvist
wrote:
> PING
>
> On Fri, Dec 29, 2017 at 8:28 PM, Janne Blomqvist
> wrote:
>> On Fri, Dec 29, 2017 at 7:17 PM, Thomas Koenig wrote:
>>> Hi Janne,
>>>
Using pointer sized variables (e.g. size_t / ptrdiff_t) when the
variables ar
On Mon, Jan 29, 2018 at 11:51 PM, Thomas Koenig wrote:
> Hello world,
>
> this patch fixes the library issues left over from Paul's rank-15 patch
> by removing the GFC_DTYPE_DERIVED_* macros and (mostly) handling these
> cases separately.
>
> The problem was with folding the type and size into a s
Hi!
On Tue, Jan 30, 2018 at 10:21:33AM -0600, Aaron Sawdey wrote:
> This fix looks good, passes bootstrap, go tests run.
>
> Segher is currently regtesting on ppc64le power9. OK for trunk if tests
> pass?
>
> 2018-01-30 Aaron Sawdey
>
> * config/rs6000/rs6000.c (rs6000_internal_arg_po
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01488.html
This is a minor improvement but there have been a couple of
comments lately pointing out that the numbers in the -Wrestrict
messages can make them confusing.
Jakub, since you made one of those comments (the other came up
in the conte
On Jan 25, 2018, Alexandre Oliva wrote:
> Thanks, I'll retest with the simplified test (just in case; for I can't
> recall why I ended up with all those redundant conditions),
As suspected, removing the redundant tests didn't regress anything. I
suppose they mattered in some earlier experimenta
On Jan 26, 2018, Jakub Jelinek wrote:
> Having to tweak debug info consumers so that they treat DW_LLE_* of 9
> one way for .debug_loclist of version 5 and another way for .debug_loclist
> of version 6 isn't a good idea.
Maybe we don't have to do that. The reason I implemented the proposed
form
On 01/30/2018 11:11 AM, Jakub Jelinek wrote:
Hi!
We don't want to move /f instructions across jumps in either direction,
sched_analyze_insn has code for that by adding the insn into
sched_before_next_jump list and by adding anti dependence against
pending_jump_insns. That works fine, as long as
Hi!
As discussed in the PR, the ICE here happens in dump_generic_node:
case FUNCTION_TYPE:
case METHOD_TYPE:
...
if (TYPE_NAME (node) && DECL_NAME (TYPE_NAME (node)))
dump_decl_name (pp, TYPE_NAME (node), flags);
(gdb) print node
$21 =
(gdb) print node.type_common.name
$2
On Tue, 30 Jan 2018 12:54:21 +
Jonathan Wakely wrote:
> On 30/01/18 10:19 +0300, Petr Ovtchenkov wrote:
> >On Tue, 19 Dec 2017 11:37:43 +0300
> >Petr Ovtchenkov wrote:
> >
> >ping^3
>
>
> I don't fully understand the consequences (or need) for this patch.
>
> I asked some other people to
Hi Janne,
PING**2
OK.
Regards, Thomas
When instantiating the members of a class template, we don't need to
consider lambdas, as instantiating them will be handled when we get to
tsubst_lambda_expr. And now the new assert catches places we were
failing to ignore them, as here.
Tested x86_64-pc-linux-gnu, applied to trunk.
commit d9724
Another refinement to local class handling in determine_visibility.
If we're looking at a local class inside a lambda, it thinks it is in
a template but the lambda isn't a template instantiation. So look for
the enclosing template context to use.
Tested x86_64-pc-linux-gnu, applying to trunk.
com
Hi Jan,
> this patch fixed ICE that was introduced by Richard Standiford's change to
> reorder
> can and want_inline predicates to reduce amount of work done to verify
> inlining limits.
> This bypasses check that the function is optimized that makes inliner to ICE
> because
> function summary
On January 30, 2018 9:05:31 PM GMT+01:00, Rainer Orth
wrote:
>Hi Jan,
>
>> this patch fixed ICE that was introduced by Richard Standiford's
>change to reorder
>> can and want_inline predicates to reduce amount of work done to
>verify inlining limits.
>> This bypasses check that the function is op
This testcase breaks since r256550 because we end up trying to build_address of
a CONSTRUCTOR, but that doesn't work because we hit
gcc_checking_assert (TREE_CODE (t) != CONSTRUCTOR);
finish_static_assert gets {} as 'condition'. In the testcase we have a
user-defined conversion, so {} should b
This patch
2018-01-30 Jan Hubicka
gcc:
PR lto/83954
* lto-symtab.c (warn_type_compatibility_p): Silence false positive
for type match warning on arrays of pointers.
gcc/testsuite:
PR lto/83954
* gcc.dg/lto/pr83954.h: New testcase.
* gcc.
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84112
The patch was successfully bootstrapped and tested on x86-64 and ppc64.
Committed as rev. 257204.
Index: ChangeLog
===
--- ChangeLog (revision 257
Hi Vladimir,
> The following patch fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84112
>
> The patch was successfully bootstrapped and tested on x86-64 and ppc64.
>
> Committed as rev. 257204.
[...]
> Index: testsuite/ChangeLog
> =
On 01/30/2018 03:37 PM, Rainer Orth wrote:
Hi Vladimir,
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84112
The patch was successfully bootstrapped and tested on x86-64 and ppc64.
Committed as rev. 257204.
[...]
Index: testsuite/ChangeLog
=
Hello world,
I have just committed the attached patch as obvious, after regtesting.
Regards
Thomas
2018-01-30 Thomas Koenig
PR fortran/84133
* frontend-passes (matmul_to_var_expr): Return early if
in association list.
(inline_matmul_assign): Likewise
Alexandre Oliva writes:
> On Jan 26, 2018, Jakub Jelinek wrote:
>
>> Having to tweak debug info consumers so that they treat DW_LLE_* of 9
>> one way for .debug_loclist of version 5 and another way for .debug_loclist
>> of version 6 isn't a good idea.
>
> Maybe we don't have to do that. The reas
Hi Jonathan,
> On 30/01/18 15:51 +0100, Rainer Orth wrote:
>>Hi Joseph,
>>
>>> On Tue, 30 Jan 2018, Rainer Orth wrote:
>>>
So it seems the following snippet
#define STARTFILE_ARCH_SPEC \
[...]
%{std=c9*|std=iso9899\\:199409|std=c1*:values-Xc.o%s; :values-Xa.o%s}
Hi all,
I have just committed an obvious patch that adds a closing bracket in
a dg-options directive in the testsuite as r257208:
Index: gcc/testsuite/gfortran.dg/pr68318_1.f90
===
--- gcc/testsuite/gfortran.dg/pr68318_1.f90(revi
Your change looks good, don't hesitate to re-submit a proper patch with
the point 1 below fix. You should add gcc-patches@gcc.gnu.org when you
do so.
Remaining questions will be:
Copyright assignment, your change seems limited enough to avoid it but
you will need an official maintainer confirm
Hi!
[Note: Jakub has mentioned that missing -Warray-bounds regressions
should be punted to GCC 9. I think this particular one is easy
pickings, but if this and/or the rest of the -Warray-bounds regressions
should be marked as GCC 9 material, please let me know so we can adjust
all relevant P
OK. Thought I already sent OK, but must of got side track with work.
--
steve
On Tue, Jan 30, 2018 at 06:25:31PM +0200, Janne Blomqvist wrote:
> PING
>
> On Tue, Jan 23, 2018 at 3:31 PM, Janne Blomqvist
> wrote:
> > As part of the change to larger character lengths, the string copy
> > algori
Hello world,
another obvious fix, this time for an ice-on-invalid regression,
committed after regression-testing.
Regards
Thomas
2017-01-30 Thomas Koenig
PR fortran/84134
* array.c (gfc_ref_dimen_size): Whitespace fixes. If stride is
zero, return false.
20
On Tue, Jan 30, 2018 at 09:05:31PM +0100, Rainer Orth wrote:
> > this patch fixed ICE that was introduced by Richard Standiford's change to
> > reorder
> > can and want_inline predicates to reduce amount of work done to verify
> > inlining limits.
> > This bypasses check that the function is opti
Hi,
Some VSX function has previosly crept into the altivec-13 testcase. In
particular,
anything 'vector long long' and 'vector double', causing issues on platforms
without
VSX support. So, break that content out into it's own testcase, allowing
better
testcase coverage.
Sniff-tested on Pow
Hi!
While -falign-{functions,jumps,labels,loops} are marked Optimization,
-falign-{functions,jumps,labels,loops}= are not. They use the same Var(),
for that it makes no difference, but it means we reject them in optimize
attribute starting with r237174.
Fixed thusly, bootstrapped/regtested on x8
Hi!
This restores GCC 3.3 behavior on this testcase, before 3.4 started ICEing
on it when it started to use the common block comment skipping code for
-traditional-cpp and just a simple function for macro block comments has
been added. Even the macro block comments can be not properly terminated
Hi!
DW_AT_data_location needs to be the data pointer, which is at offset 0,
but we were emitting a bogus +8 in that case (+4 for 32-bit targets).
With this patch, the change on -g -dA is:
- .uleb128 0x4# DW_AT_data_location
+ .uleb128 0x2# DW_AT_data_location
.byte 0
On Tue, Jan 30, 2018 at 11:53:40PM +0100, Jakub Jelinek wrote:
>
> DW_AT_data_location needs to be the data pointer, which is at offset 0,
> but we were emitting a bogus +8 in that case (+4 for 32-bit targets).
>
> With this patch, the change on -g -dA is:
> - .uleb128 0x4# DW_AT_data_l
Testing GCC 8 with recent Linux kernel sources has uncovered
a bug in the handling of arrays of arrays by the -Wrestrict
checker where it fails to take references to different array
elements into consideration, issuing false positives.
The attached patch corrects this mistake.
In addition, to ma
On 01/30/2018 03:11 PM, Aldy Hernandez wrote:
Hi!
[Note: Jakub has mentioned that missing -Warray-bounds regressions
should be punted to GCC 9. I think this particular one is easy
pickings, but if this and/or the rest of the -Warray-bounds regressions
should be marked as GCC 9 material, please
> I would like to commit the following comment about LEON3-FT errata now
> available in GCC-7.3.
Fine with me, thanks.
--
Eric Botcazou
> OK. Makes me wonder how many big endian LRA targets are getting significant
> use.
Debian still has an active SPARC64 port now based on GCC 7 with LRA.
--
Eric Botcazou
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Finnish team of translators. The file is available at:
http://translationproject.org/latest/cpplib/fi.po
(This file, 'cpplib-8.1-b20180128
cpplib-8.1-b20180128.fi.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
On Tue, 30 Jan 2018, Jakub Jelinek wrote:
> Hi!
>
> While -falign-{functions,jumps,labels,loops} are marked Optimization,
> -falign-{functions,jumps,labels,loops}= are not. They use the same Var(),
> for that it makes no difference, but it means we reject them in optimize
> attribute starting wi
On Tue, 30 Jan 2018, Jakub Jelinek wrote:
> Hi!
>
> This restores GCC 3.3 behavior on this testcase, before 3.4 started ICEing
> on it when it started to use the common block comment skipping code for
> -traditional-cpp and just a simple function for macro block comments has
> been added. Even t
This patch by Cherry Zhang fixes the Go frontend so that Function_type
and Backend_function_type are not identical, since they have different
backend representations. Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
=
libgcc/
2018-01-31 Max Filippov
* config/xtensa/ieee754-df.S (__adddf3_aux): Add
.literal_position directive.
* config/xtensa/ieee754-sf.S (__addsf3_aux): Likewise.
---
libgcc/config/xtensa/ieee754-df.S | 1 +
libgcc/config/xtensa/ieee754-sf.S | 1 +
2 files changed, 2
On 01/30/2018 12:23 AM, Uros Bizjak wrote:
> On Tue, Jan 30, 2018 at 5:48 AM, Jeff Law wrote:
>>
>>
>>
>> stack-clash-protection will sometimes force a prologue to use pushes to
>> save registers. We try to limit how often that happens as it constrains
>> options for generating efficient prologue
Whee, fun, this appears to have been broken for a very long time,
possibly since the introduction of -fstack-check in 2010. Thankfully it
only affects 32 bit and only in relatively constrained circumstances.
-fstack-check and -fstack-clash both potentially create a loop for stack
probing. In tha
This patch to the Go frontend's GCC interface uses VIEW_CONVERT_EXPR
where needed. The code was using fold_convert_loc in
constructor_expression and temporary_variable, which almost always
worked. However, it failed in https://golang.org/issue/23606. This
patch fixes the problem. Bootstrapped a
87 matches
Mail list logo
