Morning Maciej,
Then there is a fix for the PDP11 backend addressing an issue I found in
the handling of floating-point comparisons. Unlike all the other changes
this one has not been regression-tested, not even built as I have no idea
how to prepare a development environment for a PDP11
On Fri, Nov 20, 2020 at 12:58 AM Segher Boessenkool
wrote:
>
> On Thu, Nov 19, 2020 at 03:30:37PM -0700, Jeff Law wrote:
> > > No, the vast majority of people will *not* (consciously) use them,
> > > because the target defaults will set things to useful values.
> > >
> > > The compiler could use
On 11/20/20 8:44 AM, Vyacheslav Barinov wrote:
Hello,
Okay, I proposed this check to upstream [1] and it has already been
accepted.
Hello.
Great. Please commit it to the llvm-project upstream and I'll make then
the patch cherry-pick.
We can either apply the fix or postpone it until next
Hello,
Okay, I proposed this check to upstream [1] and it has already been
accepted. We can either apply the fix or postpone it until next sync with
upstream.
Anyway the bug doesn't seem so bad if we were the only team who faced it during
all this time.
Best Regards,
Vyacheslav Barinov
[1]:
On Fri, Nov 20, 2020 at 12:30 AM Eric Botcazou wrote:
>
> > Successfully bootstrapped/regtested on x86_64-linux and i686-linux,
> > including make install which looked problematic in PR97911.
> >
> > Ok for trunk?
>
> I cannot really approve, but this looks like a step in the right direction.
Here is what I am testing.
I use your enum proposal as an alias for the bool type. I cannot use it
as template parameter on _M_copy unless I put it at std namespace level
to use it in definition of the outline _M_copy overload.
I also added some tests checking correct usage of
From: Aaron Sawdey
Segher & Bergner -
Thanks for the reviews, here's the updated patch after fixing those things.
We now have an UNSPEC for xxsetaccz, and an accompanying change to
rs6000_rtx_costs to make it be cost 0 so that CSE doesn't try to replace it
with a bunch of register moves.
If
On Linux/x86_64,
d0d8b5d83614d8f0d0e40c0520d4f40ffa01f8d9 is the first bad commit
commit d0d8b5d83614d8f0d0e40c0520d4f40ffa01f8d9
Author: Andrew MacLeod
Date: Thu Nov 19 17:41:30 2020 -0500
Process only valid shift ranges.
caused
FAIL: gcc.dg/pr97515.c scan-tree-dump-times evrp "goto" 1
Hi,
[Paul, there's a PDP11 piece for you further down here and then 29/31.]
This is the much-desired refurbishment of the VAX backend. A little bit
past the end of Stage 1, which I apologise for and which I do hope is not
going to make it a no-no for GCC 11. I feel quite satisfied anyway I
In the VAX ISA INSV bitfield insert instruction is the only computational
operation that keeps the condition codes, held in the PSL or Processor
Status Longword register, intact. The instruction is flexible enough it
could potentially be used for data moves post-reload, but then reportedly
it is
We do not define a comparison operation between floating-point and
integer data, including integer zero constant. Consequently the RTL
instruction stream presented to the post-reload comparison elimination
pass will include, where applicable, floating-point comparison insns
against
The use of a constant double zero is required for post-reload compare
elimination to be able to discard redundant floating-point comparisons,
for example with a VAX RTL instruction stream like:
(insn 34 4 3 2 (parallel [
(set (reg/v:DF 0 %r0 [orig:24 x ] [24])
Use a double colon to introduce the comments like elsewhere throughout
the VAX machine description.
gcc/
* config/vax/vax.md (divmoddisi4, *amulsi4): Make the comment
notation consistent with the rest of the file.
---
gcc/config/vax/vax.md | 38
Correct issues with commented-out insns, which fail to build if enabled:
.../gcc/config/vax/vax.md:503:1: repeated operand number 1
.../gcc/config/vax/vax.md:503:1: repeated operand number 2
and then when the issue with the repeated operands has been corrected:
.../gcc/config/vax/vax.md:107:1:
It makes no sense for insn operand predicates, as long as they accept a
register operand, to be more restrictive than the set of the associated
constraints, because expand will choose the insn based on the relevant
operand being a pseudo register then and reload will keep it happily as
an
It makes no sense for insn operand predicates, as long as they accept a
register operand, to be more restrictive than the set of the associated
constraints, because expand will choose the insn based on the relevant
operand being a pseudo register then and reload keep it happily as a
memory
We have matching insns defined for `sign_extract' and `zero_extract'
expressions, so make the three named patterns for bitfield operations
consistent and make `extv' an expander rather than an insn taking a
SImode, a QImode, and a SImode general operand for the LOC, SIZE, and
POS operands
With the `*insv_aligned', `*extzv_aligned' and `*extv_aligned' insns we
are going to adjust the bitfield location if it is in memory, so only
allow such location addresses that can be offset, excluding external
symbol references in the PIC mode in particular.
This fixes an ICE like:
during RTL
The INSV machine instruction is the only computational operation in the
VAX ISA that keeps condition codes intact. In preparation to MODE_CC
transition keep patterns apart then that make or do not make use of said
instruction. For consistency update EXTV and EXTZV instruction uses
accordingly.
It makes no sense for insn operand predicates, as long as they accept a
register operand, to be more restrictive than the set of the associated
constraints, because expand will choose the insn based on the relevant
operand being a pseudo register then and reload keep it happily as a
memory
The MOVC3 machine instruction has `memmove' semantics[1]:
"The operation of the instruction is such that overlap of the source and
destination strings does not affect the result."
so use it to provide the `movmemhi' instruction as well.
References:
[1] DEC STD 032-0 "VAX Architecture
gcc/testsuite/
* gcc.target/vax/cpymem.c: New test.
---
gcc/testsuite/gcc.target/vax/cpymem.c | 23 +++
1 file changed, 23 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/vax/cpymem.c
diff --git a/gcc/testsuite/gcc.target/vax/cpymem.c
The middle end does not refer to `ctzqi2'/`ctzhi2' or `ffsqi2'/`ffshi2'
patterns by name where `__builtin_ctz' or `__builtin_ffs' respectively
is invoked for an argument of the QImode or HImode type, and instead it
extends the data type before passing it to `ctzsi2' or `ffssi2'.
Avoid the
The FFS machine instruction provides for arbitrary input bitfield widths
so take advantage of this and convert `ffssi2' and `ctzsi2' to templates
for all the three of QI, HI, SI machine modes.
Test cases will be added separately.
gcc/
* config/vax/builtins.md (width): New mode
Our `ffssi2_internal' pattern and the machine FFS instruction, which
technically is a bitfield operation, match the `ctz' operation exactly,
with the result produced for the bitfield source operand of zero equal
to its width as specified with another machine instruction operand, not
directly
Based on gcc.dg/pr61756.c.
gcc/testsuite/
* gcc.target/vax/bbcci.c: New test.
* gcc.target/vax/bbssi.c: New test.
---
gcc/testsuite/gcc.target/vax/bbcci.c | 20
gcc/testsuite/gcc.target/vax/bbssi.c | 20
2 files changed, 40
gcc/testsuite/
* gcc.target/vax/ffssi.c: New test.
---
gcc/testsuite/gcc.target/vax/ffssi.c | 19 +++
1 file changed, 19 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/vax/ffssi.c
diff --git a/gcc/testsuite/gcc.target/vax/ffssi.c
Test cases will follow.
gcc/
* config/vax/vax.md: Include `builtins.md'.
---
gcc/config/vax/vax.md | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/config/vax/vax.md b/gcc/config/vax/vax.md
index e6b217fd0d7..66f03df1932 100644
--- a/gcc/config/vax/vax.md
+++
Remove an ICE like:
during RTL pass: expand
.../libatomic/tas_n.c: In function 'libat_test_and_set_1':
.../libatomic/tas_n.c:39:1: internal compiler error: in patch_jump_insn, at
cfgrtl.c:1298
39 | }
| ^
0x108a09ff patch_jump_insn
.../gcc/cfgrtl.c:1298
0x108a0b07
With mode-specific interlocked branch insns already folded into iterated
templates now fold the two templates into one too, observing that the
only difference between them is the value of the bit branched on, which
is of course reflected both in the RTL expression and the instruction
produced.
Regardless of the machine mode all the interlocked branches of the same
kind, one of the two provided by the ISA, use the same RTL patterns and
machine instructions, except for the memory operand's constraint.
Remove code duplication then and make use of a mode iterator combined
with an attribute
VAX has interlocked branch instructions used for atomic operations and
we want to have them wrapped in UNSPEC_VOLATILE so as not to have code
carried across. This however breaks with jump optimization and leads
to an ICE in the build of libbacktrace like:
.../libbacktrace/mmap.c:190:1: internal
Add wide integer aka 'w' rtx format support to int iterators so that
machine description can iterate over `const_int' expressions.
This is made by expanding standard integer aka 'i' format support,
observing that any standard integer already present in any of our
existing RTL code will also fit
The `builtins.md' machine description fragment is not included anywhere
and is therefore dead code, which has become bitrotten due to non-use.
If actually enabled, it does not build due to the use of an unknown `t'
constraint:
.../gcc/config/vax/builtins.md:42:1: error: undefined
Expression costs are required to be given in terms of COSTS_N_INSNS (n),
which is defined to stand for the count of single fast instructions, and
actually returns `n * 4'. The VAX backend however instead operates on
naked numbers, causing an anomaly for the integer const zero rtx, where
the cost
It makes sense to use what other targets do and run all the VAX test
cases over all the usual optimization levels, so make `vax.exp' use our
`gcc-dg-runtest' rather than the generic `dg-runtest' test driver.
This breaks `pr56875.c' however, which is optimized away at levels above
`-O0' as a
The VAX ELF psABI does not permit the use of all hardware operand modes
for PIC symbol references due to the need to use PC-relative addressing
for symbols that end up local and the need to make references indirect
symbols that end up global.
Therefore symbols referred as immediates may only be
The `c' operand format specifier is handled directly by the middle end
in `output_asm_insn':
%cN means require operand N to be a constant
and print the constant expression with no punctuation.
however it resorts to the target for constants that are not valid
addresses:
else
From: Matt Thomas
Fix an ICE with the handling of RTL expressions like:
(subreg:QI (mem/c:SI (plus:SI (plus:SI (mult:SI (reg/v:SI 0 %r0 [orig:67 i ]
[67])
(const_int 4 [0x4]))
(reg/v/f:SI 7 %r7 [orig:59 doacross ] [59]))
(const_int 40 [0x28])) [1
From: Aaron Sawdey
After building some larger codes using opaque types and some c++ codes
using opaque types it became clear I needed to go through and look for
places where opaque types and modes needed to be handled. A whole pile
of one-liners.
If bootstrap/regtest passes for ppc64le and
When I implemented the code to detect modifying const objects in
constexpr contexts, we couldn't have constexpr destructors, so I didn't
consider them. But now we can and that caused a bogus error in this
testcase: [class.dtor]p5 says that "const and volatile semantics are not
applied on an
From: Aaron Sawdey
After building some larger codes using opaque types and some c++ codes
using opaque types it became clear I needed to go through and look for
places where opaque types and modes needed to be handled. A whole pile
of one-liners.
If bootstrap/regtest passes for ppc64le and
For some reason this patch never showed up on gcc-patches.
Aaron Sawdey, Ph.D. saw...@linux.ibm.com
IBM Linux on POWER Toolchain
> Begin forwarded message:
>
> From: acsaw...@linux.ibm.com
> Subject: [PATCH,rs6000] Make MMA builtins use opaque modes [v2]
> Date: November 19, 2020 at 12:58:47
On Linux/x86_64,
0862d007b564eca8c9a48fca0e689dd3f90db828 is the first bad commit
commit 0862d007b564eca8c9a48fca0e689dd3f90db828
Author: Jan Hubicka
Date: Thu Nov 19 20:16:26 2020 +0100
Fix two bugs in operand_equal_p
caused
FAIL: gcc.dg/vect/vect-35-big-array.c -flto -ffat-lto-objects
[PATCH] PowerPC: Add float128/Decimal conversions.
I accidently posted this patch on an internal IBM mailing list instead of
gcc-patches.
This patch replaces the following two patches:
September 24th, 2020:
Message-ID: <20200924203545.gd31...@ibm-toto.the-meissners.org>
October 22nd, 2020:
[PATCH] PowerPC: Set long double size for IBM/IEEE.
I originally posted this patch to an internal IBM mailing list instead of
gcc-patches.
As I was working with compilers where the long double default was 64-bit, it
became annoying to have to use two options to switch to one of the 128-bit long
[PATCH] PowerPC: Map IEEE 128-bit long double built-in functions.
I posted this patch by accident to an internal IBM mailing list instead of
gcc-patches.
This patch replaces patches previously submitted:
September 24th, 2020:
Message-ID: <20200924203159.ga31...@ibm-toto.the-meissners.org>
On Thu, Nov 19, 2020 at 03:30:37PM -0700, Jeff Law wrote:
> > No, the vast majority of people will *not* (consciously) use them,
> > because the target defaults will set things to useful values.
> >
> > The compiler could use saner "generic" defaults perhaps, but those will
> > still not be
[PATCH] PowerPC: PR 97791: Fix gnu attributes.
Note, I originally posted this to an internal IBM mailing list, not to
gcc-patches. Sorry about that.
This patch does two things to fix setting gnu attribute #4 (long double status)
1) Only set gnu attribute #4 if long double was passed. Passing
On Thu, 2020-11-19 at 23:41 +0100, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> As mentioned in the PR, the previous PR91029 patch was testing
> op2 >= 0 which is unnecessary, even negative op2 values will work the
> same,
> furthermore, from if a % b > 0 we can deduce a > 0 rather than just a
PowerPC: PR libgcc/97543, fix 64-bit long double issues
I meant to post this to the gcc-patches mailing list last Thursday, but I see I
posted this to an internal IBM mailing list.
This patch replaces the previous iterations of this patch:
October 22nd, 2020:
Message-ID:
> Successfully bootstrapped/regtested on x86_64-linux and i686-linux,
> including make install which looked problematic in PR97911.
>
> Ok for trunk?
I cannot really approve, but this looks like a step in the right direction.
--
Eric Botcazou
On Wed, Nov 04, 2020 at 08:44:03AM -0800, Carl Love wrote:
> +#define vec_mulh(a, b) __builtin_vec_mulh (a, b)
> +#define vec_div(a, b) __builtin_vec_div (a, b)
> +#define vec_dive(a, b) __builtin_vec_dive (a, b)
> +#define vec_mod(a, b) __builtin_vec_mod (a, b)
This should be
#define
On 11/19/20 5:41 PM, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, the previous PR91029 patch was testing
op2 >= 0 which is unnecessary, even negative op2 values will work the same,
furthermore, from if a % b > 0 we can deduce a > 0 rather than just a >= 0
(0 % b would be 0), and it actually
When shifting outside the valid range of [0, precision-1], we can choose
to process just the valid ones since the rest is undefined.
This allows us to produce results for x << [0,2][+INF, +INF] by
discarding the invalid ranges and processing just [0,2].
THis is particularly important when
Hi!
As mentioned in the PR, the previous PR91029 patch was testing
op2 >= 0 which is unnecessary, even negative op2 values will work the same,
furthermore, from if a % b > 0 we can deduce a > 0 rather than just a >= 0
(0 % b would be 0), and it actually valid even for other constants than 0,
a %
On Thu, Nov 19, 2020 at 03:50:27PM +0100, Jakub Jelinek via Gcc-patches wrote:
> So, I think the problem is that for make .PHONY targets are just
> "rebuilt" always, so it is very much undesirable for the cc1plus$(exeext)
> etc. dependencies to include .PHONY targets, but I was using
> them -
On Thu, Nov 19, 2020 at 05:30:06PM +0100, Jakub Jelinek via Gcc-patches wrote:
> Tested on x86_64-linux, ok for trunk if it passes full bootstrap/regtest?
Successfully bootstrapped/regtested on both x86_64-linux and i686-linux now.
Jakub
On 11/19/20 1:01 PM, Segher Boessenkool wrote:
> On Thu, Nov 19, 2020 at 12:53:27PM -0700, Jeff Law wrote:
>> On 11/19/20 12:42 PM, Segher Boessenkool wrote:
>>> On Thu, Nov 19, 2020 at 12:13:34PM -0700, Jeff Law wrote:
On 8/31/20 9:33 PM, Jiufu Guo via Gcc-patches wrote:
> guojiufu
Thank you for installing my patch Jeff!
Yes, I intend to contribute regularly. I'm working on getting copyright
assignment/disclaimer paperwork approved by my employer. I'll apply for commit
privs after that.
Eugene
-Original Message-
From: Jeff Law
Sent: Wednesday, November 18,
On 12/11/20 17:34 +, Jonathan Wakely wrote:
On 11/11/20 19:08 +0100, Jakub Jelinek via Libstdc++ wrote:
On Wed, Nov 11, 2020 at 05:24:42PM +, Jonathan Wakely wrote:
--- a/libgcc/gthr-posix.h
+++ b/libgcc/gthr-posix.h
@@ -684,7 +684,14 @@ __gthread_equal (__gthread_t __t1, __gthread_t
This exposes the template specialization table, so the modules
machinery may access it. The hashed entity (tmpl, args & spec) is
available, along with a hash table walker. We also need a way of
finding or inserting entries, along with some bookkeeping fns to deal
with the instantiation and
On Thu, 19 Nov 2020, Uecker, Martin wrote:
> Apparently I did not have enough coffee when
> generalizing this to the other qualifiers.
>
> Ok, with the following test?
OK.
--
Joseph S. Myers
jos...@codesourcery.com
On Thu, Nov 19, 2020 at 11:25:08AM -0600, Pat Haugen wrote:
> > +(define_insn "vmodu_"
> > + [(set (match_operand:VIlong 0 "vsx_register_operand" "=v")
> > + (umod:VIlong (match_operand:VIlong 1 "vsx_register_operand" "v")
> > +(match_operand:VIlong 2 "vsx_register_operand"
Again, I noticed some cleanups on the way to preparing this exposure of
the constexpr hash table. Committing this to trunk
This patch exposes the constexpr hash table so that the modules
machinery can save and load constexpr bodies. While there I noticed
that we could do a little
On 11/19/20 12:58 PM, acsaw...@linux.ibm.com wrote:
> +(define_expand "mma_disassemble_pair"
> + [(match_operand:V16QI 0 "mma_disassemble_output_operand")
> + (match_operand:OO 1 "input_operand")
> + (match_operand 2 "const_0_to_1_operand")]
Maybe we should use vsx_register_operand instead
On Thu, Nov 19, 2020 at 12:53:27PM -0700, Jeff Law wrote:
> On 11/19/20 12:42 PM, Segher Boessenkool wrote:
> > On Thu, Nov 19, 2020 at 12:13:34PM -0700, Jeff Law wrote:
> >> On 8/31/20 9:33 PM, Jiufu Guo via Gcc-patches wrote:
> >>> guojiufu writes:
> When unroll loops, if there are calls
On 11/19/20 12:42 PM, Segher Boessenkool wrote:
> On Thu, Nov 19, 2020 at 12:13:34PM -0700, Jeff Law wrote:
>> On 8/31/20 9:33 PM, Jiufu Guo via Gcc-patches wrote:
>>> guojiufu writes:
When unroll loops, if there are calls inside the loop, those calls
may raise negative impacts for
On Thu, Nov 19, 2020 at 12:13:34PM -0700, Jeff Law wrote:
> On 8/31/20 9:33 PM, Jiufu Guo via Gcc-patches wrote:
> > guojiufu writes:
> >> When unroll loops, if there are calls inside the loop, those calls
> >> may raise negative impacts for unrolling. This patch adds a param
> >>
Am Donnerstag, den 19.11.2020, 18:58 + schrieb Joseph Myers:
> On Thu, 19 Nov 2020, Uecker, Martin wrote:
...
>
> > +void g(void)
> > +{
> > + volatile int j;
> > + typeof((0,j)) i21; i21 = j;;
> > + typeof(+j) i22; i22 = j;;
> > + typeof(-j) i23; i23 = j;;
> > + typeof(1?j:0) i24; i24 = j;;
Hi,
doing some further testing and analysis of icf miscompares I noticed tat
my change for hadling OEP_ADDRESS_OF of COMPONENT_REF had last minute
chnage that made it not effective, since flag is cleared before the
conditional. After some exprimenting it seem cleanest to just use
temporary bool.
On 19/11/20 12:57 -0500, Lewis Hyatt via Libstdc++ wrote:
Hello-
PR61369 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61369) points out
that std::discrete_distribution can return an event even if it has 0
probability, and proposes a simple fix. It seems that this fix was never
applied, because
On 8/31/20 9:33 PM, Jiufu Guo via Gcc-patches wrote:
> guojiufu writes:
>
> Hi,
>
> In this patch, the default value of
> param=max-unrolled-average-calls-x1 is '0', which means to unroll
> a loop, there should be no call inside the body. Do I need to set the
> default value to a bigger
On 19/11/20 13:36 +, Jonathan Wakely wrote:
On 16/11/20 14:43 -0800, Thomas Rodgers wrote:
This patch looks good to me.
Committed now.
This patch was also needed, but I don't understand why I didn't see
the FAILs on gcc135 in teh cfarm.
Anyway, tested x86_64-linux, committed to trunk.
On Thu, 19 Nov 2020, Uecker, Martin wrote:
> Here is another version of the patch. The
> only difference is the additional the check
> using 'tree_ssa_useless_type_conversion'.
The code changes in this one are OK. However, in the test:
> +void f(void)
> +{
> + const int j;
> + typeof((0,j))
Hi!
The documentation for POST_MODIFY says:
Currently, the compiler can only handle second operands of the
form (plus (reg) (reg)) and (plus (reg) (const_int)), where
the first operand of the PLUS has to be the same register as
the first operand of the *_MODIFY.
The following testcase
On Thu, Nov 19, 2020 at 1:54 AM Kewen.Lin wrote:
>
> Hi,
>
> The insn type of p8_mtvsrd_df looks missed to be updated
> with mtvsr. Here I supposed mtvsrd's all usages should
> be with the same insn type.
>
> This patch is to fix its current insn type mfvsr by mtvsr.
>
> Is it ok for trunk?
>
>
On 11/19/20 11:11 AM, Marek Polacek wrote:
Since my r11-3092 the following is rejected with -std=c++20:
struct T { explicit T(); };
void fn(int n) {
new T[1]();
}
with "would use explicit constructor 'T::T()'". It is because since
that change we go into the P1009 block in
On 11/19/20 11:11 AM, Marek Polacek wrote:
Unfortunately, the otherwise beautiful
for (constructor_elt : *CONSTRUCTOR_ELTS (init))
is not immune to an empty constructor, so we have to check
CONSTRUCTOR_ELTS first.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
On 11/17/20 3:44 AM, Jan Hubicka wrote:
On Tue, Nov 17, 2020 at 01:33:48AM -0500, Jason Merrill via Gcc-patches wrote:
Why doesn't the middle-end warning work for inline functions?
It does but only when they're called (and, as usual, also unless
the uninitialized use is eliminated).
Yes,
> "Jonathan" == Jonathan Wakely writes:
Jonathan> Here's a slightly more conservative version of the patch. This moves
Jonathan> std::thread and this_thread::get_id() and this_thread::yield() to a
Jonathan> new header, and makes *most* of std::thread defined without gthreads
Jonathan>
On 29/10/2020 10:03 am, Jakub Jelinek wrote:
I'm actually not sure how this can work correctly.
Let's say we have
int foo () { return 1; }
int bar () { return 2; }
int baz () { return 3; }
int qux () { return 4; }
int a = foo ();
int b = bar ();
int c = baz ();
int *d =
int e = qux ();
int f =
Hello-
PR61369 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61369) points out
that std::discrete_distribution can return an event even if it has 0
probability, and proposes a simple fix. It seems that this fix was never
applied, because there was an expectation of redoing this code anyway to
use
this adds configure tests for features that modules can take advantage
of -- and if they are not present has reduced or fallback functionality.
It is slightly different from the earlier posting, as the server
functionality has been moved from gcc/cp to its own toplevel directory
gcc/
On четвъртък, 19 ноември 2020 г. 2:07:59 EET Jeff Law wrote:
> On 11/13/20 1:07 PM, Dimitar Dimitrov wrote:
> > Add builtins for HALT and LMBD, per Texas Instruments document
> > SPRUHV7C. Use the new LMBD pattern to define an expand for clz.
> >
> > Binutils [1] and sim [2] support for LMBD
On 11/19/20 8:52 AM, Eric Botcazou wrote:
> Hi,
>
> there is a loophole in new string store merging support I added recently: it
> does not check that the stores are consecutive, which is obviously required
> if
> you want to concatenate them... Simple fix attached, the nice thing being
>
On 11/4/20 10:44 AM, Carl Love via Gcc-patches wrote:
> +
> +(define_insn "vdives_"
> + [(set (match_operand:VIlong 0 "vsx_register_operand" "=v")
> +(unspec:VIlong [(match_operand:VIlong 1 "vsx_register_operand" "v")
> + (match_operand:VIlong 2 "vsx_register_operand"
On 19/11/2020 14:40, Wilco Dijkstra via Gcc-patches wrote:
> Hi,
>
As for your second patch, --with-cpu-64 could be a simple alias indeed,
but what is the exact definition/expected behaviour of a --with-cpu-32
on a target that only supports 64-bit code? The AArch64
On 11/19/20 12:28 PM, Slava Barinov via Gcc-patches wrote:
Null pointer in path argument leads to SIGSEGV in interceptor.
Hello.
I can't see we ever had the null check in master. I don't this it was lost
during a merge from master.
Why do we need the hunk?
Thanks,
Martin
Hi!
This is the whole __builtin_clear_padding patchset merged into a single
patch, + 2 new changes - one is that fold_builtin_1 now folds the
1 argument (meant for users) __builtin_clear_padding into an internal
2 argument form, where the second argument is NULL of the first argument's
type, such
Matthew Malcomson writes:
> +/* Emit gimple statements into that take the size given in `len` and
> + generate a size that is guaranteed to be rounded upwards to `align`.
> +
> + This is a helper function for both handle_builtin_alloca and
> + asan_expand_mark_ifn when using HWASAN.
> +
>
Unfortunately, the otherwise beautiful
for (constructor_elt : *CONSTRUCTOR_ELTS (init))
is not immune to an empty constructor, so we have to check
CONSTRUCTOR_ELTS first.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
gcc/cp/ChangeLog:
PR c++/97895
* pt.c
Since my r11-3092 the following is rejected with -std=c++20:
struct T { explicit T(); };
void fn(int n) {
new T[1]();
}
with "would use explicit constructor 'T::T()'". It is because since
that change we go into the P1009 block in build_new (array_p is false,
but nelts is non-null and
On 11/17/20 7:47 AM, Jozef Lawrynowicz wrote:
> In addition to the default config, I would suggest:
> msp430-sim/-mcpu=msp430
> Test the 430 ISA
> msp430-sim/-mlarge/-mcode-region=either
> Test the large memory model with data assumed to be in the lower
> memory region (default,
It turns out there are legitimate cases for the new decl to not have
lang-specific.
PR c++/97905
gcc/cp/
* decl.c (duplicate_decls): Relax new assert.
gcc/testsuite/
* g++.dg/lookup/pr97905.C: New.
pushing to trunk
--
Nathan Sidwell
diff --git
Hi,
PR9 - ICE: in df_refs_verify, at df-scan.c:3991 with -O -ffinite-math-only
-fzero-call-used-regs=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
Is a bug triggered by the new pass zero-call-used-regs, however, it’s an old
bug in the pass “reg-stack”.
This pass does not
Hi,
there is a loophole in new string store merging support I added recently: it
does not check that the stores are consecutive, which is obviously required if
you want to concatenate them... Simple fix attached, the nice thing being
that it can fall back to the regular processing if any hole
We need to include limits.h (or ) in adaint.c because of LLONG_MIN.
Tested on x86-64/Linux, applied on the mainline.
2020-11-19 Eric Botcazou
PR ada/97805
* adaint.c: Include climits in C++ and limits.h otherwise.
--
Eric Botcazoudiff --git a/gcc/ada/adaint.c
Matthew Malcomson writes:
> […]
> +/* hwasan_frame_base_init_seq is the sequence of RTL insns that will
> initialize
> + the hwasan_frame_base_ptr. When the hwasan_frame_base_ptr is requested,
> we
> + generate this sequence but do not emit it. If the sequence was created it
> + is
this patch is slightly modified from the original 07 patch, due to the
cleanup I posted earlier today.
This adds the capability to locate the main file on the user or system
include paths. That's extremely useful to users building header
units. Searching has to be requiested (plain
1 - 100 of 139 matches
Mail list logo
