On Wed, Nov 18, 2020 at 04:29:09PM -0600, Segher Boessenkool wrote:
> On Wed, Nov 18, 2020 at 10:53:49PM +0100, Jakub Jelinek wrote:
> > On Wed, Nov 18, 2020 at 03:43:20PM -0600, Segher Boessenkool wrote:
> > > Hi!
> > >
> > > On Sun, Nov 15, 2020 at 12:17:47PM -0500, Michael Meissner wrote:
> > >
On Wed, Nov 18, 2020 at 01:27:12PM -0600, Segher Boessenkool wrote:
> Hi!
>
> On Sun, Nov 15, 2020 at 12:23:50PM -0500, Michael Meissner wrote:
> > --- a/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c
> > +++ b/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c
> > @@ -1,4 +1,5 @@
> > /* { dg-skip-
This pattern interferes with *2_1 when TARGET_SSE_MATH
modes are active. Combine pass is able to remove (use) RTXes and transforms
*2_1 to *2_i387_1 where SSE
alternatives are not available.
2020-11-19 Uroš Bizjak
gcc/
PR target/97887
* config/i386/i386.md (*2_i387_1):
Disable for
This fixes complex lowering to not put constants into abnormal
edge PHI values by making sure abnormally used SSA names are
VARYING in its propagation lattice.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed to trunk.
2020-11-19 Richard Biener
PR tree-optimization/97897
Jakub Jelinek via Gcc-patches writes:
> On Wed, Nov 18, 2020 at 12:51:02PM +0100, Tobias Burnus wrote:
>> As noted by Matthias when bootstrapping with AMD GCN support [PR97827]:
>> Assembler source code generated by GCC might no longer assembly with
>> LLVM's 'mc' since LLVM 11.
>>
>> The reason
On Thu, Nov 19, 2020 at 09:51:41AM +, Richard Sandiford wrote:
> > I think we shouldn't do this except when targetting the (buggy) llvm
> > assembler.
> > Specifying section flags just on first .section directive and not others
> > is correct, there is no point repeating that and GNU as (but I
Jakub Jelinek via Gcc-patches writes:
> On Thu, Nov 19, 2020 at 09:51:41AM +, Richard Sandiford wrote:
>> > I think we shouldn't do this except when targetting the (buggy) llvm
>> > assembler.
>> > Specifying section flags just on first .section directive and not others
>> > is correct, there
> On 11/16/20 12:20 AM, Jan Hubicka wrote:
> > This is controlled by -fipa-icf-alias-sets
> >
> > The patch drops too early, so we may end up processing function twice.
> > Also if
> > merging is not performed we lose code quality for no win (this is rare
> > case).
> > My original plan was to
On 18/11/2020 17:16, Pop, Sebastian via Gcc-patches wrote:
> Hi,
>
> On 11/18/20, 10:17 AM, "Wilco Dijkstra" wrote:
>>I presume you're trying to unify the --with- options across most targets?
>
> Yes, my intention was to provide the same configure options on arm64
> as on x86, such that pro
On 11/18/20 3:50 PM, Jan Hubicka wrote:
On 11/13/20 6:50 PM, Jan Hubicka wrote:
Bootstrapped/regtested x86_64-linux. I plan to commit it on monday if there are
no complains.
Hello Honza.
Thank you very much for the patch set.
It's a nice improvement and it will eventually fix the WPA slowness
We need to fold the stmt to canonicalize MEM_REFs which means
we're back to using replace_uses_by. Which means we need dominators
to not require a CFG cleanup upthread.
Bootstrapped / tested on x86_64-unknown-linux-gnu, pushed.
2020-11-19 Richard Biener
PR tree-optimization/97901
Sorry for the late reply. I somehow managed to miss this thread until now
despite being cc:ed.
> > I'm not sure what best to do here, as said accepting "any" (integer) mode as
> > input is desirable (SImode, DImode but eventually also smaller modes). How
> > that can be best achieved I don't kno
Null pointer in path argument leads to SIGSEGV in interceptor.
libsanitizer/ChangeLog:
* sanitizer_common/sanitizer_common_interceptors.inc: Check
path for null before dereference in fopen64 interceptor.
---
Notes:
Apparently check has been lost during merge from upstream
li
On 19/11/20 07:46 +0100, François Dumont via Libstdc++ wrote:
On 18/11/20 12:50 am, Jonathan Wakely wrote:
On 17/11/20 21:51 +0100, François Dumont via Libstdc++ wrote:
This is a change that has been done to _Hashtable and that I
forgot to propose for _Rb_tree.
The _GLIBCXX_XREF macro can
> 2020-11-18 Jakub Jelinek
>
> gcc/
> * configure.ac: Add $lang.prev rules, INDEX.$lang and SERIAL_LIST
and
> SERIAL_COUNT variables to Make-hooks.
> (--enable-link-serialization): New configure option.
> * Makefile.in (DO_LINK_SERIALIZATION, LINK_PROGRESS): New
variab
Richard Biener via Gcc-patches writes:
> On Mon, Nov 16, 2020 at 10:58 AM Richard Sandiford
> wrote:
>> > Does the patch also vectorize with SVE loops that have
>> > unknown loop bound? The documentation isn't entirely
>> > conclusive there.
>>
>> Yeah, for SVE it vectorises. How about changing
On Thu, Nov 19, 2020 at 12:55:42PM +0100, Eric Botcazou wrote:
> > * Make-lang.in (d.serial): New goal.
> > (.PHONY): Add d.serial d.prev.
> > (d21$(exeext)): Depend on d.prev. Call LINK_PROGRESS.
>
> This seems to cause the binaries to be always relinked, for example from the
> gcc/
On 16/07/19 18:40 +0200, François Dumont wrote:
Hi
   I eventually spent much more time working on the inplace_merge
performance bench.
   And the results do not confirm the theory:
Before patch:
inplace_merge.cc           bench 1 / 1 memory          243rÂ
> Does it?
> Only with --enable-link-serialization, or without that too?
It's the default, i.e. without --enable-link-serialization.
> Will have a look.
Thanks.
--
Eric Botcazou
On 11/06/20 08:32 +0200, François Dumont via Libstdc++ wrote:
As we are on patching algos we still have this old one.
   From the original patch I only kept the memory optimization part
as the new performance test was not showing good result for the other
part to change pivot value. I als
This adds dg-options "" to avoid the pedantic error on _Complex int.
2020-11-19 Richard Biener
* gcc.dg/pr97897.c: Add dg-options.
---
gcc/testsuite/gcc.dg/pr97897.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/testsuite/gcc.dg/pr97897.c b/gcc/testsuite/gcc.dg/pr97897.c
ind
This refactors things so assigned ranks are dumped and the cache
is consistently used also for PHIs.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2020-11-19 Richard Biener
* tree-ssa-reassoc.c (get_rank): Refactor to consistently
use the cache and dump ranks as
Hi,
after fixing few issues I gotto stage where 1.4M icf mismatches are due to
comparing two gimple clobber. The problem is that operand_equal_p match
clobber
case CONSTRUCTOR:
/* In GIMPLE empty constructors are allowed in initializers of
aggregates. */
return !CONSTRUCTOR_NELTS (arg0) &
This fixes a typo in the TREE_CODE compare which should
compare against TYPE_DECL, not TYPE_NAME.
Pushed as obvious.
2020-11-19 Richard Biener
* fold-const.c (operand_compare::hash_operand): Fix typo.
---
gcc/fold-const.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
In preparing module patch 7 I realized there was a cleanup I could
make to simplify it. This is that cleanup. Also, when doing the
cleanup I noticed some macros had been turned into inline functions,
but not renamed to the preprocessors internal namespace
(_cpp_$INTERNAL rather than cpp_$USER).
Hi,
this is variant of patch I comitted (with a mistake fixed by Richard, my
apologizes for it). It turned out that the hunk handling OBJ_TYPE_REF
in operand_compare::hash_operand was on a wrong spot in operand_equal_p
that probably happened during mering the patch.
Also with Ada LTO bootstrap I
Hi there,
After offline discussion with Richard I've modified the way in which the
initialisation for the hwasan base pointer is emitted.
Originally it was getting emitted during `expand_used_vars`, and
requiring `handle_builtin_alloca` to register a need for it to be
emitted so that `expand_HWASA
Update to match the change in initialisation for patch 5/X.
MM
---
There are four main features to this change:
1) Check pointer tags match address tags.
When sanitizing for hwasan we now put HWASAN_CHECK internal functions before
memory accesses in the `asan` pass. This checks that a tag in
On 19/11/20 12:31 pm, Jonathan Wakely wrote:
On 19/11/20 07:46 +0100, François Dumont via Libstdc++ wrote:
On 18/11/20 12:50 am, Jonathan Wakely wrote:
On 17/11/20 21:51 +0100, François Dumont via Libstdc++ wrote:
This is a change that has been done to _Hashtable and that I forgot
to propo
On 18/11/20 20:22 +, Jonathan Wakely wrote:
On 18/11/20 00:01 +, Jonathan Wakely wrote:
On 14/11/20 14:23 +, Jonathan Wakely wrote:
On Sat, 14 Nov 2020, 13:30 Mike Crowe wrote:
@@ -195,7 +205,7 @@ namespace
if (__s.count() < 0) [[unlikely]]
return false;
-
On 16/11/20 14:43 -0800, Thomas Rodgers wrote:
This patch looks good to me.
Committed now.
It would be great to find a way to do a similar refactoring of
condition_variable.
Yes, probably once stage 1 opens for GCC 12.
On Nov 12, 2020, at 9:07 AM, Jonathan Wakely via Libstdc++
wrote:
On Thu, 19 Nov 2020, Jan Hubicka wrote:
> Hi,
> after fixing few issues I gotto stage where 1.4M icf mismatches are due to
> comparing two gimple clobber. The problem is that operand_equal_p match
> clobber
>
> case CONSTRUCTOR:
> /* In GIMPLE empty constructors are allowed in initializers of
On Thu, Nov 19, 2020 at 03:08:05AM -0500, Michael Meissner wrote:
> On Wed, Nov 18, 2020 at 04:29:09PM -0600, Segher Boessenkool wrote:
> > Mike, please add a comment, what number it represents? Okay for trunk
> > with that, thanks.
> >
> > (Should those not be define in some header though?)
>
>
On Thu, Nov 19, 2020 at 1:04 PM Richard Sandiford
wrote:
>
> Richard Biener via Gcc-patches writes:
> > On Mon, Nov 16, 2020 at 10:58 AM Richard Sandiford
> > wrote:
> >> > Does the patch also vectorize with SVE loops that have
> >> > unknown loop bound? The documentation isn't entirely
> >> >
On Wed, Nov 18, 2020 at 07:13:04PM -0600, Paul A. Clarke wrote:
> On Wed, Nov 18, 2020 at 04:29:09PM -0600, Segher Boessenkool wrote:
> > Mike, please add a comment, what number it represents? Okay for trunk
> > with that, thanks.
> >
> > (Should those not be define in some header though?)
>
> W
On 11/19/20 1:10 PM, Eric Botcazou wrote:
Does it?
Only with --enable-link-serialization, or without that too?
It's the default, i.e. without --enable-link-serialization.
Will have a look.
Thanks.
I see the same, I don't use --enable-link-serialization.
Just run:
make -j16 && make -j16
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 target cannot
>>> generate AArch32 code, so we shouldn't silently accep
On Wed, Nov 18, 2020 at 1:25 PM Martin Liška wrote:
>
> On 11/16/20 1:21 PM, Richard Biener wrote:
> > but the most trivial thing would be to feed the pass the
> > balanced-tree generated by switch expansion where I
> > would expect us to be able to detect it as the original switch again.
>
> Well
On Thu, Nov 19, 2020 at 01:10:18PM +0100, Eric Botcazou wrote:
> > Does it?
> > Only with --enable-link-serialization, or without that too?
>
> It's the default, i.e. without --enable-link-serialization.
>
> > Will have a look.
>
> Thanks.
So, I think the problem is that for make .PHONY targets
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 header-unit
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 emitt
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 b/gcc/ada/adai
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
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 correctl
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 c/gcc/cp/d
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,
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 w
Unfortunately, the otherwise beautiful
for (constructor_elt &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 (
Matthew Malcomson writes:
> +/* Emit gimple statements into &stmts 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.
>
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
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
libsanitizer/Chang
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 targe
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 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
> t
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 inst
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/
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
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 = &c;
int e = qux ();
int f
> "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> (becaus
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, but
On 11/19/20 11:11 AM, Marek Polacek wrote:
Unfortunately, the otherwise beautiful
for (constructor_elt &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.
gcc
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 build_n
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?
>
> B
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, 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)) i1
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 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 va
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
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.
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;;
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
> >> param_max_unrol
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 un
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 in
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 of
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 constificatio
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" "v"))
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
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 (par
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 __
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, 2020
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 wr
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 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 - cc1pl
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 % b
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 us
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
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 vec_mulh(a,
> 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
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: <2020100510.ga11...@
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
>
[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, 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 satisfa
[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>
Octob
[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
d
[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:
Mess
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
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 P
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 x86_6
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 object
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 x86_6
1 - 100 of 139 matches
Mail list logo
