Hello,
This patch is an attempt to fix the crash reported in PR82155.
When generating a C++ class method for a class that is itself nested in
a class method, dwarf2out_early_global_decl currently leaves the
existing context DIE as it is if it already exists. However, it is
possible that this cal
-- Shane
On Tue, Sep 12, 2017, at 09:56 AM, gcc-patches-h...@gcc.gnu.org wrote:
> Hi! This is the ezmlm program. I'm managing the
> gcc-patches@gcc.gnu.org mailing list.
>
> To confirm that you would like
>
>general+...@matley.com.au
>
> added to the gcc-patches mailing list, please send
On 09/02/2017 11:43 AM, Aldy Hernandez wrote:
> On Fri, Sep 1, 2017 at 6:11 PM, Jeff Law wrote:
>> On 09/01/2017 02:18 PM, Aldy Hernandez wrote:
>>> Hi.
>>>
>>> Attached are misc cleanups to tree-ssa-threadbackwards.c and friends.
>>> The main gist of the patch is making the path vectors live in t
On 09/11/2017 03:59 PM, Max Filippov wrote:
> Hi Richard,
>
> On Mon, Sep 11, 2017 at 2:36 PM, Richard Sandiford
> wrote:
>> Max Filippov writes:
>>> 2017-09-11 Max Filippov
>>> gcc/
>>> * expmed.c (emit_store_flag_int): Initialize rtx tem.
>>
>> LGTM, thanks, but I can't approve it.
>>
On 09/11/2017 11:18 AM, Richard Sandiford wrote:
> Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
> Also tested by comparing the testsuite assembly output on at least one
> target per CPU directory. OK to install?
>
> Richard
>
>
> gcc/
> * target.def (hard_regno
Well, here's a version which actually throws a hard error in
obvious cases; the other cases are reserved for -Wextra.
Turns up a few bugs in the testsuite, too.
An interesting one is unconstrained_commons.f, where
the code quite happily saves and stores outside a common
block array with a single
On 09/11/2017 11:13 AM, Richard Sandiford wrote:
> Pretty mechanical conversion.
>
> Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
> Also tested by comparing the testsuite assembly output on at least one
> target per CPU directory. OK to install?
>
> Richard
>
>
> 20
On 09/11/2017 11:18 AM, Richard Sandiford wrote:
> This patch converts some places that use HARD_REGNO_NREGS to use
> hard_regno_nregs, in places where the initialisation has obviously
> already taken place.
>
> Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
> Also tested
On 09/11/2017 11:17 AM, Richard Sandiford wrote:
> This patch converts hard_regno_nregs into an inline function, which
> in turn allows hard_regno_nregs to be used as the name of a targetm
> field. This is just a mechanical change.
>
> Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le
On 09/11/2017 11:16 AM, Richard Sandiford wrote:
> An upcoming patch will convert hard_regno_nregs into an inline
> function, which in turn allows hard_regno_nregs to be used as the
> name of a targetm field. This patch rewrites a use that can use
> in_hard_reg_set_p instead.
>
> Tested on aarch6
On 09/11/2017 11:16 AM, Richard Sandiford wrote:
> An upcoming patch will convert hard_regno_nregs into an inline
> function, which in turn allows hard_regno_nregs to be used as the
> name of a targetm field. This patch rewrites uses that can use
> end_hard_regno instead.
>
> Tested on aarch64-li
On 11/09/17 22:39 +0200, Daniel Krügler wrote:
2017-09-11 22:36 GMT+02:00 François Dumont :
[..]
So my remark was rather for the:
_Fwd_list_iterator() noexcept
: _M_node() { }
that could simply be
_Fwd_list_iterator() = default;
no ?
Yes, that should be fine.
I'm not sure
Hi Richard,
On Mon, Sep 11, 2017 at 2:36 PM, Richard Sandiford
wrote:
> Max Filippov writes:
>> 2017-09-11 Max Filippov
>> gcc/
>> * expmed.c (emit_store_flag_int): Initialize rtx tem.
>
> LGTM, thanks, but I can't approve it.
>
> This makes the later "tem = 0;" redundant, so perhaps it
This adds 'constexpr' everywhere it's missing from
std::basic_string_view.
PR libstdc++/70483
* include/bits/string_view.tcc (basic_string_view::find)
(basic_string_view::rfind, basic_string_view::find_first_of)
(basic_string_view::find_last_of, basic_string_view::
Max Filippov writes:
> 2017-09-11 Max Filippov
> gcc/
> * expmed.c (emit_store_flag_int): Initialize rtx tem.
LGTM, thanks, but I can't approve it.
This makes the later "tem = 0;" redundant, so perhaps it would make
sense to delete that too? There again, it was redundant before the
spl
On 9/11/2017 10:26 AM, Iain Buclaw wrote:
On 11 September 2017 at 17:12, Jeff Law wrote:
On 05/28/2017 03:02 PM, Iain Buclaw wrote:
(Sorry, repost as I rushed the first one a bit).
This patch adds the DMD front-end proper and license (Boost) files,
comprised of a lexer, parser, and semantic
On Mon, Sep 11, 2017 at 2:18 PM, augustine.sterl...@gmail.com
wrote:
> On Mon, Sep 11, 2017 at 2:16 PM, Max Filippov wrote:
>> 2017-09-11 Max Filippov
>> gcc/
>> * config/xtensa/xtensa.c (xtensa_mem_offset): Check that both
>> words of E_DImode object are reachable by xtensa_ui
On Mon, Sep 11, 2017 at 2:16 PM, Max Filippov wrote:
> 2017-09-11 Max Filippov
> gcc/
> * config/xtensa/xtensa.c (xtensa_mem_offset): Check that both
> words of E_DImode object are reachable by xtensa_uimm8x4 access.
Approved. Please apply.
2017-09-11 Max Filippov
gcc/
* config/xtensa/xtensa.c (xtensa_mem_offset): Check that both
words of E_DImode object are reachable by xtensa_uimm8x4 access.
---
gcc/config/xtensa/xtensa.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/config/xtensa/xtensa.c b/gcc/config/
2017-09-11 Max Filippov
gcc/
* expmed.c (emit_store_flag_int): Initialize rtx tem.
---
gcc/expmed.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/expmed.c b/gcc/expmed.c
index 7f0cb0a0ec05..945ab3d656a2 100644
--- a/gcc/expmed.c
+++ b/gcc/expmed.c
@@ -5601,7 +5
2017-09-11 22:36 GMT+02:00 François Dumont :
[..]
> So my remark was rather for the:
>
> _Fwd_list_iterator() noexcept
> : _M_node() { }
>
> that could simply be
>
> _Fwd_list_iterator() = default;
>
> no ?
Yes, that should be fine.
- Daniel
On 11/09/2017 14:11, Jonathan Wakely wrote:
On 11/09/17 07:44 +0200, Daniel Krügler wrote:
2017-09-11 7:12 GMT+02:00 François Dumont :
When user declare a container iterator like that:
std::forward_list::iterator it;
There is no reason to initialize it with a null node pointer. It is
just an
> I think the issue is that we set SUBREG_PROMOTED_* on something that is
> possibly not so (aka uninitialized in this case).
Yes, that's what I called inherent weakness of the promoted subregs mechanism.
> We may only set it if either the ABI or a previous operation forced it to.
> Maybe this is
On 09/11/2017 11:14 AM, Richard Sandiford wrote:
> An upcoming patch will convert hard_regno_nregs into an inline
> function, which in turn allows hard_regno_nregs to be used as the
> name of a targetm field. This patch rewrites uses that are more
> easily (and efficiently) written as REG_NREGS.
>
Hi Paul,
> I have fixed all the PDT bugs that have been reported to me so far in
> the attached patch. The patch is straightforward and is commented for
> clarity where necessary. Please note that whitespace changes have been
> suppressed. For this reason, if you are tempted to try the patch use
>
> That regresses on gnat.dg/specs/atomic1.ads for aarch64/-mabi=ilp32,
> missing the error on line 13. The missing error on line 9 is
> preexisting.
That's sort of expected, since the point of the patch is to make the 2
situations equivalent wrt atomicity. Clearly the test is not portable and
On Sun, Jul 9, 2017 at 11:43 AM, Paul Richard Thomas
wrote:
> Hi Thomas, Hi All,
>
> Please find attached what I believe is the final version of the patch.
>
> The problem concerning temporaries being generated in lieu of the
> descriptor being passed directly - see pointer_array_7.f90 and the
> c
Dear Thomas, dear All,
I have fixed all the PDT bugs that have been reported to me so far in
the attached patch. The patch is straightforward and is commented for
clarity where necessary. Please note that whitespace changes have been
suppressed. For this reason, if you are tempted to try the patch
Jeff Law wrote:
> On 09/09/2017 02:51 AM, Eric Botcazou wrote:
> >> No, the stack never gets misaligned - my patch doesn't change that at all.
> >
> > Yes, it does. Dynamic allocation works like this: the amount to be
> > allocated
> > is added to VIRTUAL_STACK_DYNAMIC_REGNUM and the result is
On 09/11/2017 11:15 AM, Richard Sandiford wrote:
> An upcoming patch will convert hard_regno_nregs into an inline
> function, which in turn allows hard_regno_nregs to be used as the
> name of a targetm field. This patch rewrites uses that are more
> easily (and efficiently) written as END_REGNO.
>
This patch fixes the ttest failures on aarch64 by adding AM_CFLAGS to
the test options, like btest already does and as Wilco says works for
him in Comment #4 of the bug report.
Tested by me on aarch64. Ok to checkin?
Steve Ellcey
sell...@cavium.com
2017-09-11 Steve Ellcey
PR other/
On 09/09/2017 02:51 AM, Eric Botcazou wrote:
>> No, the stack never gets misaligned - my patch doesn't change that at all.
>
> Yes, it does. Dynamic allocation works like this: the amount to be allocated
> is added to VIRTUAL_STACK_DYNAMIC_REGNUM and the result is then dynamically
> aligned. Y
On Sep 09 2017, Eric Botcazou wrote:
> * gcc-interface/decl.c (promote_object_alignment): New function taken
> from...
> (gnat_to_gnu_entity) : ...here. Invoke it.
> (gnat_to_gnu_field): If the field is Atomic or VFA, invoke it and
> create a padding type on success
On Mon, Sep 11, 2017 at 08:04:02PM +0200, Iain Buclaw wrote:
> > You may need to bump the copyright dates.
> >
>
> I thought I bumped all copyright dates in v2 of the patch. I will check
> again.
Regarding copyright dates, after everything is committed, we should also
adjust
contrib/update-copy
On 11 September 2017 at 18:40, Jeff Law wrote:
> On 06/24/2017 11:53 AM, Iain Buclaw wrote:
>> On 28 May 2017 at 23:17, Iain Buclaw wrote:
>>> This patch adds GCC builtins and runtime support for GDC compiled code.
>>>
>>> - module __entrypoint defines the C main function. Its contents are
>>>
On 11 September 2017 at 18:05, Jeff Law wrote:
> On 05/28/2017 03:12 PM, Iain Buclaw wrote:
>> This patch adds the D frontend language configure make files, as
>> described on the anatomy of a language front-end.
>>
>> ---
>>
>>
>> 04-d-frontend-misc.patch
>>
>>
>
>
>> +
>> +You can specify more t
On 11 September 2017 at 17:43, Jeff Law wrote:
> On 05/28/2017 03:11 PM, Iain Buclaw wrote:
>> This patch just includes all changelogs for the D front-end (GDC),
>> going back to the dawn of time itself.
>>
>> Change logs for the DMD front-end and libraries are kept on the dlang site.
> Your call
On 11 September 2017 at 17:42, Jeff Law wrote:
> On 05/28/2017 03:11 PM, Iain Buclaw wrote:
>> This patch adds the D front-end implementation, the only part of the
>> compiler that interacts with GCC directly, and being the parts that I
>> maintain, is something that I can talk about more directly
On 09/11/2017 11:27 AM, Mike Stump wrote:
> On Sep 11, 2017, at 9:34 AM, Jeff Law wrote:
>>
>> On 05/28/2017 03:15 PM, Iain Buclaw wrote:
>>> This patch adds D language support to GCC itself.
>>>
>>> ---
>>>
>>>
>>> 06-d-gcc-proper.patch
>>>
>>>
>>> gcc/ChangeLog
>>>
>>> * config/rs6000/rs6000
On Sep 11, 2017, at 9:34 AM, Jeff Law wrote:
>
> On 05/28/2017 03:15 PM, Iain Buclaw wrote:
>> This patch adds D language support to GCC itself.
>>
>> ---
>>
>>
>> 06-d-gcc-proper.patch
>>
>>
>> gcc/ChangeLog
>>
>> * config/rs6000/rs6000.c (rs6000_output_function_epilogue):
>> Sup
On 11 September 2017 at 17:12, Jeff Law wrote:
> On 05/28/2017 03:02 PM, Iain Buclaw wrote:
>> (Sorry, repost as I rushed the first one a bit).
>>
>> This patch adds the DMD front-end proper and license (Boost) files,
>> comprised of a lexer, parser, and semantic analyzer.
>>
>> Split 1/4
>>
>> Gz
On 09/09/17 10:33 +0200, Jason Merrill wrote:
On Fri, Sep 8, 2017 at 10:03 PM, Jonathan Wakely wrote:
Define the __cpp_lib_threadsafe_static_init feature-test macro as per
recent SD-6 drafts.
Tested powerpc64le-linux and x86_64-linux.
OK for trunk?
The branches too?
Yes.
Jason
I've comm
Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
Also tested by comparing the testsuite assembly output on at least one
target per CPU directory. OK to install?
Richard
gcc/
* target.def (hard_regno_nregs): New hook.
(class_max_nregs): Refer to it instead
This patch converts some places that use HARD_REGNO_NREGS to use
hard_regno_nregs, in places where the initialisation has obviously
already taken place.
Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
Also tested by comparing the testsuite assembly output on at least one
t
This patch converts hard_regno_nregs into an inline function, which
in turn allows hard_regno_nregs to be used as the name of a targetm
field. This is just a mechanical change.
Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
Also tested by comparing the testsuite assembly
An upcoming patch will convert hard_regno_nregs into an inline
function, which in turn allows hard_regno_nregs to be used as the
name of a targetm field. This patch rewrites a use that can use
in_hard_reg_set_p instead.
Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
Also
An upcoming patch will convert hard_regno_nregs into an inline
function, which in turn allows hard_regno_nregs to be used as the
name of a targetm field. This patch rewrites uses that can use
end_hard_regno instead.
Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
Also tes
An upcoming patch will convert hard_regno_nregs into an inline
function, which in turn allows hard_regno_nregs to be used as the
name of a targetm field. This patch rewrites uses that are more
easily (and efficiently) written as END_REGNO.
Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc
Richard Sandiford writes:
> Pretty mechanical conversion.
>
> Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
> Also tested by comparing the testsuite assembly output on at least one
> target per CPU directory. OK to install?
>
> Richard
>
>
> 2017-09-11 Richard Sandifor
An upcoming patch will convert hard_regno_nregs into an inline
function, which in turn allows hard_regno_nregs to be used as the
name of a targetm field. This patch rewrites uses that are more
easily (and efficiently) written as REG_NREGS.
Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc
Pretty mechanical conversion.
Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
Also tested by comparing the testsuite assembly output on at least one
target per CPU directory. OK to install?
Richard
2017-09-11 Richard Sandiford
Alan Hayward
On 05/28/2017 03:47 PM, Iain Buclaw wrote:
> This patch adds the D runtime library and license (Boost) files. D
> runtime is a low level that implements the building blocks of the
> runtime environment, as well as C and C++ platform bindings. Many
> high level operations are lowered to generate c
On 04/09/17 16:48 +0100, Jonathan Wakely wrote:
On 30/07/17 15:01 +0200, Daniel Krügler wrote:
2017-07-28 22:40 GMT+02:00 Daniel Krügler :
2017-07-28 22:29 GMT+02:00 Daniel Krügler :
2017-07-28 22:25 GMT+02:00 Tim Song :
On Fri, Jul 28, 2017 at 4:10 PM, Daniel Krügler
wrote:
+ // Perfo
On 06/24/2017 11:53 AM, Iain Buclaw wrote:
> On 28 May 2017 at 23:17, Iain Buclaw wrote:
>> This patch adds GCC builtins and runtime support for GDC compiled code.
>>
>> - module __entrypoint defines the C main function. Its contents are
>> parsed and compiled in during compilation, but only if
On 05/28/2017 03:15 PM, Iain Buclaw wrote:
> This patch adds D language support to GCC itself.
>
> ---
>
>
> 06-d-gcc-proper.patch
>
>
> gcc/ChangeLog
>
> * config/rs6000/rs6000.c (rs6000_output_function_epilogue):
> Support GNU D by using 0 as the language type.
> * dwarf2o
On 05/28/2017 03:15 PM, Iain Buclaw wrote:
> This patch adds the D language front-end to GCC documentation and
> configuration files, as described on the anatomy of a language
> front-end.
>
> ---
>
>
> 05-d-gcc-config.patch
>
>
> ChangeLog:
>
> * Makefile.def (target_modules): Add libp
GCC Maintainers:
The following patch re-adds the vectorization support for the vec_mule()
and vec_mul0() builtins to the tree. The vectorization support was part
of the original patch, commit 249424, to add the builtin funtionality.
But the vectorization part was pulled as part of commit 250295 d
Hello Michael,
> On Sep 11, 2017, at 17:28 , Michael Haubenwallner
> wrote:
>>> Makefile.in:
>>> ...
>>> export libsubdir
>>>
>>> This is not working well on cygwin environments where environment
>>> variable names are translated to uppercase (so sub-makes evaluating
>>> the variable with t
On 05/28/2017 03:12 PM, Iain Buclaw wrote:
> This patch adds the D frontend language configure make files, as
> described on the anatomy of a language front-end.
>
> ---
>
>
> 04-d-frontend-misc.patch
>
>
> +
> +You can specify more than one input file on the @command{gdc} command line,
> +i
On 05/28/2017 03:11 PM, Iain Buclaw wrote:
> This patch just includes all changelogs for the D front-end (GDC),
> going back to the dawn of time itself.
>
> Change logs for the DMD front-end and libraries are kept on the dlang site.
Your call on how much of the historical record you want to keep.
On 05/28/2017 03:11 PM, Iain Buclaw wrote:
> This patch adds the D front-end implementation, the only part of the
> compiler that interacts with GCC directly, and being the parts that I
> maintain, is something that I can talk about more directly.
>
> For the actual code generation pass, that conv
On Tue, Sep 05, 2017 at 03:12:47PM +0200, Richard Biener wrote:
> On Tue, 5 Sep 2017, Tamar Christina wrote:
>
> >
> >
> > > -Original Message-
> > > From: Richard Biener [mailto:rguent...@suse.de]
> > > Sent: 05 September 2017 13:51
> > > To: Tamar Christina
> > > Cc: Andrew Pinski; And
Any further comments?
Kyrill Tkachov wrote:
> > After Bernd's change almost all DI mode instructions are split before
> > register
> > allocation. So instructions using DI mode no longer exist and thus these
> > extend variants can never be matched and are thus redundant.
>
> Bernd's patch
Hi Oliver,
On 09/11/2017 04:30 PM, Olivier Hainque wrote:
> Hello,
>
> Ping for https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00017.html
>
>> Makefile.in:
>> ...
>> export libsubdir
>>
>> This is not working well on cygwin environments where environment
>> variable names are translated to
Simon Atanasyan writes:
> Here is the updated patch with chnaged e-mail address and fixed
> indentation issues:
> -8<
> Currently GCC supports 'long_call', 'far', and 'near' attributes. The
> 'long_call' and 'far' attributes are synonyms. This patch adds support
> for the 'shor
On 05/28/2017 03:02 PM, Iain Buclaw wrote:
> (Sorry, repost as I rushed the first one a bit).
>
> This patch adds the DMD front-end proper and license (Boost) files,
> comprised of a lexer, parser, and semantic analyzer.
>
> Split 1/4
>
> Gzipped because of size limitations.
So for 1/13, these a
Hello,
Ping for https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01783.html
> config.gcc already has a provision for a good default
> cpu selection for SPE with double precision floats
> when the latter is explicitly requested with an explicit
> --enable command line option.
...
> The attached patch
Hello,
Ping for https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00017.html
> Makefile.in:
> ...
> export libsubdir
>
> This is not working well on cygwin environments where environment
> variable names are translated to uppercase (so sub-makes evaluating
> the variable with the lowercase nam
Now with the patch :-)
VP.
On Mon, Sep 11, 2017 at 03:20:12PM +0100, Vidya Praveen wrote:
> Hello,
>
> The following two related patches need to be reverted as it causes
> cross-native
> builds to fail with the following message:
>
> g++ -c -DIN_GCC -DGENERATOR_FILE -I. [...] \
>
Hello,
The following two related patches need to be reverted as it causes cross-native
builds to fail with the following message:
g++ -c -DIN_GCC -DGENERATOR_FILE -I. [...] \
-o build/genpreds.o /path/to/src/gcc/gcc/genpreds.c
In file included from ./options.h:8:0,
On 09/09/17 12:44, Ramana Radhakrishnan wrote:
I'm pleased to announce that the steering committee has appointed
- James Greenhalgh as a full maintainer for the AArch64 port
and
- Kyrylo Tkachov as a full maintainer for the ARM port.
James & Kyrylo, if you could update your entries in the
Eric Botcazou wrote:
>> No, the stack never gets misaligned - my patch doesn't change that at all.
>
> Yes, it does.
No. Look at the diffs, there is not a single change in alignment anywhere for
all
of the alloca variants. If the alignment is incorrect after my patch, it is also
incorrect
Here is the updated patch with chnaged e-mail address and fixed
indentation issues:
-8<
Currently GCC supports 'long_call', 'far', and 'near' attributes. The
'long_call' and 'far' attributes are synonyms. This patch adds support
for the 'short_call' attribute as a synonym for `n
Ping...
On 09/04/17 10:07, Bernd Edlinger wrote:
> Hi,
>
> as you know we have a -Wcast-align warning which works only for
> STRICT_ALIGNMENT targets. But occasionally it would be nice to be
> able to switch this warning on even for other targets.
>
> Therefore I would like to add a strict ver
Simon Atanasyan writes:
> Currently GCC supports 'long_call', 'far', and 'near' attributes. The
> 'long_call' and 'far' attributes are synonyms. This patch adds support
> for the 'short_call' attribute as a synonym for `near` to make this list
> complete, consistent with other targets, and compati
This patch totally disables the freezing of an expression function at the
point its body is analyzed, as well the freezing of all the types that are
not yet frozen, in order to support more cases where the profile contains
a type which depends on a private type that is declared in an open scope
and
> On 4 Sep 2017, at 21:48, Jakub Jelinek wrote:
>
> On Mon, Sep 04, 2017 at 08:47:07PM +0100, Simon Wright wrote:
>> On 1 Sep 2017, at 23:05, Simon Wright wrote:
>>>
>>> 2017-09-01 Simon Wright
>>>
>>> PR target/80204
>>> * config/darwin-driver.c (darwin_find_version_from_kernel)
On 11/09/17 07:44 +0200, Daniel Krügler wrote:
2017-09-11 7:12 GMT+02:00 François Dumont :
When user declare a container iterator like that:
std::forward_list::iterator it;
There is no reason to initialize it with a null node pointer. It is just an
uninitialized iterator which is invalid to us
hough that isn't a full solution
either).
Richard.
>
>2017-09-11 Eric Botcazou
>
> * expmed.c (store_fixed_bit_field_1): Force the masking if the value
> is an unsigned promoted SUBREG of a sufficiently large object.
>
>
>2017-09-11 Eric Botcazou
>
> * gcc.c-torture/execute/20170911-1.c: New test.
The new gcc.target/i386/pr81736-[34].c tests currently FAIL on 32-bit
Solaris x86. Fixed as suggested by HJ in the PR. Tested with the
appropriate runtest invocation on i386-pc-solaris2.11,
x86_64-pc-linux-gnu, and x86_64-apple-darwin11. Assembler output on
Linux and Darwin is unchanged.
Ok for
> this is a bug originally reported in Ada on 32-bit PowerPC with the SVR4 ABI
> (hence not Linux) and reproducible in C with the attached testcase at -O1.
With the right C testcase this time...
--
Eric Botcazoustruct S { char c1, c2, c3, c4; } __attribute__((aligned(4)));
static char bar (char
OK for the mainline?
2017-09-11 Eric Botcazou
* expmed.c (store_fixed_bit_field_1): Force the masking if the value
is an unsigned promoted SUBREG of a sufficiently large object.
2017-09-11 Eric Botcazou
* gcc.c-torture/execute/20170911-
Same renaming as just done for libgnarl, under libgnat this time.
Tested on x86_64-pc-linux-gnu, committed on trunk
2017-09-11 Jerome Lambourg
* libgnat: Rename ?-[a-z]*-* into ?-[a-z]*__*
* gcc-interface/Makefile.in, gcc-interface/Make-lang.in: Take this
renaming into
On September 11, 2017 11:03:39 AM GMT+02:00, Martin Jambor
wrote:
>Hi,
>
>in r251264 the code of split_edge was changed not to reallocate PHI
>vectors, but it reorders them along with the order of incoming edges
>to the BB. There are two places in the HSA BE where we call
>split_edge while itera
Thanks for answer.
I understood all points which you mentioned, but can't
find last one
> It seems to work
> out the file name a second time, even though the file name must
> already be known.
Can you please show me where I've missed that, if you have a time for that.
Anyway, your patch works fo
This is the next step in the source file and directory reorg in GNAT sources.
This time, we rename all files of the form ?-[a-z]*-* into ?-[a-z]*_*,
for example s-tpopsp-posix.adb becomes s-tpopsp__posix.adb. This is done
so that it's easier to see which files are platform specific variants (such
f
Hi,
in r251264 the code of split_edge was changed not to reallocate PHI
vectors, but it reorders them along with the order of incoming edges
to the BB. There are two places in the HSA BE where we call
split_edge while iterating over PHI node arguments and those broke,
resulting in a number of lib
PING.
An this time with an actual patch ;-).
Aldy
On Sat, Sep 2, 2017 at 1:43 PM, Aldy Hernandez wrote:
> On Fri, Sep 1, 2017 at 6:11 PM, Jeff Law wrote:
>> On 09/01/2017 02:18 PM, Aldy Hernandez wrote:
>>> Hi.
>>>
>>> Attached are misc cleanups to tree-ssa-threadbackwards.c and friends.
>>> Th
On Tue, Jul 18, 2017 at 5:50 AM, Christophe Lyon
wrote:
> Hello,
>
> I've received a complaint that GCC for AArch64 would generate
> vectorized code relying on unaligned memory accesses even when using
> -mstrict-align. This is a problem for code where such accesses lead to
> memory faults.
>
> A
ping^3 ?
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01063.html
On 31 August 2017 at 11:22, Christophe Lyon wrote:
> ping^2 ?
>
>
> On 21 August 2017 at 15:04, Christophe Lyon
> wrote:
>> ping ?
>> https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01063.html
>>
>> Christophe
>>
>>
>> On 18 July
90 matches
Mail list logo