2020-06-17 Bill Schmidt
* config/rs6000/rs6000-builtin-new.def: Add MASK_FLOAT128_HW,
MASK_DFP, MASK_CRYPTO, and MASK_HTM builtins.
---
gcc/config/rs6000/rs6000-builtin-new.def | 217 +++
1 file changed, 217 insertions(+)
diff --git a/gcc/config/rs6000/rs60
I posted a version of these patches back in stage 4 (February),
but we agreed that holding off until stage 1 was a better idea.
Since then I've made more progress and reorganized the patches
accordingly. This group of patches lays groundwork, but does not
actually change GCC's behavior yet, other
2020-06-17 Bill Schmidt
* config/rs6000/rbtree.c: New file.
* config/rs6000/rbtree.h: New file.
---
gcc/config/rs6000/rbtree.c | 233 +
gcc/config/rs6000/rbtree.h | 51
2 files changed, 284 insertions(+)
create mode 100644 gcc/conf
2020-06-17 Bill Schmidt
* config/rs6000/rs6000-gen-builtins.c (parse_args): New function.
(parse_prototype): Implement.
---
gcc/config/rs6000/rs6000-gen-builtins.c | 144
1 file changed, 144 insertions(+)
diff --git a/gcc/config/rs6000/rs6000-gen-built
2020-06-17 Bill Schmidt
* config/rs6000/rs6000-gen-builtins.c (ovld_stanza): New struct.
(MAXOVLDSTANZAS): New defined constant.
(ovld_stanzas): New filescope variable.
(curr_ovld_stanza): Likewise.
(MAXOVLDS): New defined constant.
(ovlddata): Ne
2020-06-17 Bill Schmidt
* config/rs6000/rs6000-builtin.def: Add comments.
* config/rs6000/rs6000-call.c: Likewise.
---
gcc/config/rs6000/rs6000-builtin.def | 15 +++
gcc/config/rs6000/rs6000-call.c | 166 +++
2 files changed, 181 insertions(+)
dif
The std::uninitialized_fill_n algorithm uses sd::fill_n for trivial
types, but that algorithm has a stronger requirement that the Size
parameter is convertible to an integral type. As the new test shows,
there are types which are valid for std::uninitialized_fill_n but which
produce a different res
Martin Liška writes:
> On 6/16/20 4:14 PM, Richard Sandiford wrote:
>> Martin Liška writes:
>>> Hmm, sounds like a nice abstraction but I see 2 problems with that:
>>>
>>> 1) How can I define a constructor of the iterator_pair when I need
>>> something like:
>>> iterator_pair (region_begin, regi
On 17/06/20 20:55 +0100, Jonathan Wakely wrote:
+struct Value
+{
+ int value = 0x1234;
+};
Oops, I modified this test, and it no longer tests the right code.
This type isn't trivial, so doesn't use the fill_n optimization
anyway. I'll fix the test.
(Sorry, sent my previous message before seeing this one.)
Martin Sebor writes:
> Since the iterator_pair template is being added as a foundational
> type I'd suggest fleshing out the design a bit more. There is
> little difference between iterator_pair and std::pair, but since
> the class is bei
On 17/06/20 21:10 +0100, Jonathan Wakely wrote:
On 17/06/20 20:55 +0100, Jonathan Wakely wrote:
+struct Value
+{
+ int value = 0x1234;
+};
Oops, I modified this test, and it no longer tests the right code.
This type isn't trivial, so doesn't use the fill_n optimization
anyway. I'll fix the te
Hi Jason
Jason Merrill via Gcc-patches wrote:
We were crashing trying to find the CALL_EXPR in the result of a call to a
consteval operator.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* call.c (build_new_op_1): Don't look for a CALL_EXPR when
I suspect that t
On 6/16/20 3:21 AM, Forrest Timour via Gcc-patches wrote:
Hi,
This patch fixes an off-by-one typo in the documentation example of the
access function attribute.
This is my first contribution and I don't have write access, so I will need
somebody to submit for me on approval.
Thank you! I've
Greetings again,
Could you please look at this patch when convenient?
--Doug
On 6/1/20 10:13 AM, Douglas B Rupp wrote:
Greetings,
Curious if you've had a chance to look at this patch yet?
--Doug
On 5/18/20 4:02 PM, Douglas B Rupp wrote:
Greetings,
The attached patch is proposed for rs6000
The std::__uninitialized_default_n algorithm used by std::vector creates
an initial object as a local variable then copies that into the
destination range. If the object is too large for the stack this
crashes. We should create the first object directly into the
destination and then copy it from th
Hi!
It's been a while... ;-)
On 2016-11-13T23:22:26+0100, Martin Jambor wrote:
> --- a/gcc/hsa-gen.c
> +++ b/gcc/hsa-gen.c
> @@ -5068,6 +5102,12 @@ gen_hsa_insns_for_call (gimple *stmt, hsa_bb *hbb)
>if (!gimple_call_builtin_p (stmt, BUILT_IN_NORMAL))
> {
>tree function_decl =
Hi!
On 2020-06-08T13:49:55+0200, Samuel Thibault wrote:
> Samuel Thibault, le lun. 08 juin 2020 13:36:55 +0200, a ecrit:
>> Thomas Schwinge, le lun. 08 juin 2020 12:15:12 +0200, a ecrit:
>> > Which GCC branches would you like this on?
>>
>> Ideally it's be backported to gcc 9 and 10, so that it l
(It would be nice to convince your mailer that a patch is not just
Application/OCTET-STREAM)
Aren't you missing :cs on bit_ior?
On Wed, 17 Jun 2020, Przemyslaw Wirkus wrote:
Hi,
Pattern "(x | y) - y" can be optimized to simple "(x & ~y)" andn pattern.
Bootstrapped and tested on aarch64-none
Hi!
On 2020-04-29T16:01:56+0200, Tobias Burnus wrote:
> See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94848
>
> The problem is a generated static array variable in the
> device function:
>static integer(kind=4) A.12[3] = {1, 2, 3};
> used as
>_26 = A.12[S.13_67];
>
> [...]
..., and t
Hi!
On 2020-04-30T12:14:39+0200, Jakub Jelinek via Gcc-patches
wrote:
> On Thu, Apr 30, 2020 at 12:07:32PM +0200, Thomas Schwinge wrote:
>> Is the attached OK for master branch, in next stage 1? [...]
>
> Ok for stage1, thanks.
Thanks. I've now pushed "[OpenMP, gimplifier] 'inform' after 'err
On Thu, Jun 18, 2020 at 12:26:06AM +0200, Thomas Schwinge wrote:
> Hi!
>
> On 2020-04-30T12:14:39+0200, Jakub Jelinek via Gcc-patches
> wrote:
> > On Thu, Apr 30, 2020 at 12:07:32PM +0200, Thomas Schwinge wrote:
> >> Is the attached OK for master branch, in next stage 1? [...]
> >
> > Ok for st
On Wed, 2020-06-17 at 10:04 +0200, Jakub Jelinek via Gcc-patches wrote:
> On Wed, Jun 17, 2020 at 09:13:25AM +0200, Richard Biener via Gcc-patches
> wrote:
> > > Not doing the transformation I suggest at all, or not doing it in
> > > cases when the member does match the source?
> >
> > We are cur
On Wed, Jun 17, 2020 at 04:37:54PM -0600, Jeff Law wrote:
> On Wed, 2020-06-17 at 10:04 +0200, Jakub Jelinek via Gcc-patches wrote:
> > On Wed, Jun 17, 2020 at 09:13:25AM +0200, Richard Biener via Gcc-patches
> > wrote:
> > > > Not doing the transformation I suggest at all, or not doing it in
> >
On 16/06/20 15:14 +0100, Richard Sandiford wrote:
Martin Li?ka writes:
On 6/16/20 10:50 AM, Richard Sandiford wrote:
Hmm, sounds like a nice abstraction but I see 2 problems with that:
1) How can I define a constructor of the iterator_pair when I need something
like:
iterator_pair (region_beg
On 18/06/20 00:55 +0100, Jonathan Wakely wrote:
On 16/06/20 15:14 +0100, Richard Sandiford wrote:
Martin Li?ka writes:
On 6/16/20 10:50 AM, Richard Sandiford wrote:
Hmm, sounds like a nice abstraction but I see 2 problems with that:
1) How can I define a constructor of the iterator_pair when
On 18/06/20 00:59 +0100, Jonathan Wakely wrote:
On 18/06/20 00:55 +0100, Jonathan Wakely wrote:
On 16/06/20 15:14 +0100, Richard Sandiford wrote:
Martin Li?ka writes:
On 6/16/20 10:50 AM, Richard Sandiford wrote:
Hmm, sounds like a nice abstraction but I see 2 problems with that:
1) How can
Since r11-423 tsubst_copy_and_build/TREE_LIST uses tsubst_tree_list
instead of open coding it. While the latter could return an error
node wrapped in a TREE_LIST, the former can return a naked error node.
That broke in tsubst_copy_and_build/NEW_EXPR:
tree placement = RECUR (TREE_OPERAND (t, 0))
Jiufu Guo writes:
Gentle ping.
https://gcc.gnu.org/legacy-ml/gcc-patches/2020-02/msg00927.html
BR,
Jiufu Guo
> Jiufu Guo via Gcc-patches writes:
>
> Hi,
>
> I would like to reping this, hope to get approval for this patch.
> https://gcc.gnu.org/legacy-ml/gcc-patches/2020-02/msg00927.html
>
> B
On Jun 17, 2020, Tobias Burnus wrote:
> I hope it helps.
Thanks! Not quite as much as I'd hoped, because I forgot much of the
arg passing in lto land is through @files, but I think I've got enough
to take a shot at fixing this.
Two questions that come to mind:
- do we wish to preserve the te
On 6/17/20 8:10 PM, Marek Polacek wrote:
Since r11-423 tsubst_copy_and_build/TREE_LIST uses tsubst_tree_list
instead of open coding it. While the latter could return an error
node wrapped in a TREE_LIST, the former can return a naked error node.
That broke in tsubst_copy_and_build/NEW_EXPR:
On Jun 9, 2020, Thomas Schwinge wrote:
> Are you able to easily create/suggest patches for these? (You're
> probably not set up for offloading compilation...) Can you suggest
> how/where to adjust: producer-side (GCC driver, 'mkoffload's?), or
> consumer-side (testsuite: offload tree scanning
Thanks for the comments, just had a question about one of them…
Jonathan Wakely writes:
> On 16/06/20 15:14 +0100, Richard Sandiford wrote:
>>Martin Li?ka writes:
>>> On 6/16/20 10:50 AM, Richard Sandiford wrote:
>>> Hmm, sounds like a nice abstraction but I see 2 problems with that:
>>>
>>> 1)
On 16/06/2020 12:42, Richard Sandiford wrote:
[...]
2020-06-16 Richard Sandiford
gcc/
* coretypes.h (first_type): New alias template.
* recog.h (insn_gen_fn::operator()): Use it instead of a decltype.
Remove spurious “...” and split the function type out into a typede
101 - 133 of 133 matches
Mail list logo
