On Wed, Mar 24, 2021 at 7:56 AM Alexandre Oliva wrote:
>
>
> The gcc.target/i386 test sse2-mmx-maskmovq.c requires the mmap
> feature, but that's not enough for the test to be able to call
> sysconf.
>
> I've combined the target triplets used in other sysconf-calling tests,
> omitting non-x86 ones
On Wed, Mar 24, 2021 at 8:17 AM Uros Bizjak wrote:
>
> On Wed, Mar 24, 2021 at 7:56 AM Alexandre Oliva wrote:
> >
> >
> > The gcc.target/i386 test sse2-mmx-maskmovq.c requires the mmap
> > feature, but that's not enough for the test to be able to call
> > sysconf.
> >
> > I've combined the target
On Wed, Mar 24, 2021 at 3:03 AM David Edelsohn wrote:
>
> On Mon, Mar 22, 2021 at 4:10 AM Richard Biener
> wrote:
>
> > Oh, and for a type like
> >
> > struct { struct { struct { ... { double x; } } } } } };
> >
> > the layout now looks quadratic in work (each field layout will look at
> > the n
On Mar 24, 2021, Uros Bizjak wrote:
> On Mar 24, 2021, Uros Bizjak wrote:
>> There are several other tests in gcc.target/i386 directory that call sysconf:
Ooh, indeed, thanks, good catch.
The reason I didn't catch them was that the full test results analysis
that got me started at it was in a
MVE has different constraints than Neon for load/store: we should use
the Ux constraint instead of Um.
2021-03-24 Christophe Lyon
PR target/99727
gcc/
* config/arm/mve.md (movmisalign_mve_store): Use Ux
constraint.
(movmisalign_mve_load): Likewise.
On 24/03/21 03:53 -0300, Alexandre Oliva wrote:
On target systems that don't support any random_device, not even the
default one,
It should be impossible to have no random_device. As a fallback a
pseudo random number generator should be used.
other random_device constructor tests are disable
On Mar 24, 2021, Uros Bizjak wrote:
> Other than above, can you please introduce
> check_effectve_target_sysconf to lib/target-supports.exp (similar to
> existing check_effective_target_mmap) and use it instead of target
> selectors?
Here it is. I've tested the affected tests with it. I'll giv
On Wed, Mar 24, 2021 at 10:14 AM Alexandre Oliva wrote:
>
> On Mar 24, 2021, Uros Bizjak wrote:
>
> > Other than above, can you please introduce
> > check_effectve_target_sysconf to lib/target-supports.exp (similar to
> > existing check_effective_target_mmap) and use it instead of target
> > sele
Hi!
On the testcase in the PR with
-fno-tree-sink -O3 -fPIC -fomit-frame-pointer -fno-strict-aliasing
-mstackrealign
we have prologue:
<_func_with_dwarf_issue_>:
0: 4c 8d 54 24 08 lea0x8(%rsp),%r10
5: 48 83 e4 f0 and$0xfff0,%rsp
Hi!
The following patch fixes similar issues as in PR98849 -
in older gcc versions, the expanders were present in neon.md guarded
with TARGET_NEON, but they got moved to vec-common.md and guarded with
ARM_HAVE__ARITH so that they handle both MVE and Neon.
The macros are enabled for some modes even
On Wed, 24 Mar 2021 at 10:45, Jakub Jelinek wrote:
>
> Hi!
>
> The following patch fixes similar issues as in PR98849 -
> in older gcc versions, the expanders were present in neon.md guarded
> with TARGET_NEON, but they got moved to vec-common.md and guarded with
> ARM_HAVE__ARITH so that they han
> -Original Message-
> From: Jakub Jelinek
> Sent: 24 March 2021 09:45
> To: Richard Earnshaw ; Ramana
> Radhakrishnan ; Kyrylo Tkachov
>
> Cc: gcc-patches@gcc.gnu.org; Christophe Lyon
> Subject: [PATCH] arm: Fix some more vec-common.md patterns for iwmmxt
> [PR99724]
>
> Hi!
>
> Th
On Mar 24, 2021, Uros Bizjak wrote:
> FYI, testsuite patches do not need a full bootstrap.
*nod*, it was the "along with other patches" that was the key. But
yeah, this was a patch that was extremely unlikely to introduce
fails in the testsuite, so I went ahead and put it in, after fixing
typos
On Mar 24, 2021, Jonathan Wakely wrote:
> It should be impossible to have no random_device. As a fallback a
> pseudo random number generator should be used.
> If the default constructor throws then that suggests your target is
> misconfigured. Why isn't the mt19937 PRNG being used?
This is an x
On 24/03/21 08:59 +, Jonathan Wakely via Libstdc++ wrote:
On 24/03/21 03:53 -0300, Alexandre Oliva wrote:
On target systems that don't support any random_device, not even the
default one,
It should be impossible to have no random_device. As a fallback a
pseudo random number generator shou
On 24/03/21 07:33 -0300, Alexandre Oliva wrote:
On Mar 24, 2021, Jonathan Wakely wrote:
It should be impossible to have no random_device. As a fallback a
pseudo random number generator should be used.
If the default constructor throws then that suggests your target is
misconfigured. Why isn
Hi!
I'd like to ping the
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566821.html
P1 PR99565 fix.
Marek has acked the gcc/c/ and gcc/c-family/ part of that patch, but it still
has gcc/cp/ and gcc/ parts that weren't acked.
If you have suggestions for better OEP_* flag name, I can change i
> On Mar 24, 2021, at 4:59 AM, Jonathan Wakely via Gcc-patches
> wrote:
>
> On 24/03/21 03:53 -0300, Alexandre Oliva wrote:
>>
>> On target systems that don't support any random_device, not even the
>> default one,
>
> It should be impossible to have no random_device.
Not true; deeply embe
Hi all,
This patch resolves bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96974
This is achieved by forcing a re-calculation of *stmt_vectype_out if an
incompatible combination of TYPE_VECTOR_SUBPARTS is detected, but with
an extra introduced max_nunits ceiling.
I am not 100% sure if thi
On 24/03/21 13:22 +, Koning, Paul via Libstdc++ wrote:
On Mar 24, 2021, at 4:59 AM, Jonathan Wakely via Gcc-patches
wrote:
On 24/03/21 03:53 -0300, Alexandre Oliva wrote:
On target systems that don't support any random_device, not even the
default one,
It should be impossible to hav
On Wed, 24 Mar 2021, Stam Markianos-Wright wrote:
> Hi all,
>
> This patch resolves bug:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96974
>
> This is achieved by forcing a re-calculation of *stmt_vectype_out if an
> incompatible combination of TYPE_VECTOR_SUBPARTS is detected, but with an
Hi!
As mentioned in the PR, before the
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ba6eb62ff0ea9843a018cfd7cd06777bd66ae0a0
fix from March 1st, PECOFF ld.bfd didn't know about .debug_loclists,
.debug_rnglists and other debug sections new in DWARF 5. Unfortunately,
unlike for ELF lin
On 24/03/21 11:27 +, Jonathan Wakely wrote:
On 24/03/21 07:33 -0300, Alexandre Oliva wrote:
On Mar 24, 2021, Jonathan Wakely wrote:
It should be impossible to have no random_device. As a fallback a
pseudo random number generator should be used.
If the default constructor throws then th
> -Original Message-
> From: Gcc-patches On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 24 March 2021 08:59
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH] arm: Fix MVE constraints for movmisalign [PR target/99727]
>
> MVE has different constraints than Neon for load/store: we
On Wed, Mar 24, 2021 at 3:51 AM Richard Biener
wrote:
>
> On Wed, Mar 24, 2021 at 3:03 AM David Edelsohn wrote:
> >
> > On Mon, Mar 22, 2021 at 4:10 AM Richard Biener
> > wrote:
> >
> > > Oh, and for a type like
> > >
> > > struct { struct { struct { ... { double x; } } } } } };
> > >
> > > the
David Edelsohn via Gcc-patches wrote:
On Wed, Mar 24, 2021 at 3:51 AM Richard Biener
wrote:
On Wed, Mar 24, 2021 at 3:03 AM David Edelsohn wrote:
On Mon, Mar 22, 2021 at 4:10 AM Richard Biener
wrote:
Oh, and for a type like
struct { struct { struct { ... { double x; } } } } } };
the la
On 3/24/21 5:44 AM, Jakub Jelinek via Gcc-patches wrote:
Hi!
I'd like to ping the
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566821.html
P1 PR99565 fix.
Marek has acked the gcc/c/ and gcc/c-family/ part of that patch, but it still
has gcc/cp/ and gcc/ parts that weren't acked.
If you
On Wed, Mar 24, 2021 at 1:44 AM Xionghu Luo wrote:
>
> l2 cache size for Power8 is 512kB, correct the copy paste error from Power7.
> Tested no performance change for SPEC2017.
>
> gcc/ChangeLog:
>
> 2021-03-24 Xionghu Luo
>
> * config/rs6000/rs6000.c (struct processor_costs): Change to
On 3/24/2021 5:44 AM, Jakub Jelinek via Gcc-patches wrote:
Hi!
I'd like to ping the
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566821.html
P1 PR99565 fix.
Marek has acked the gcc/c/ and gcc/c-family/ part of that patch, but it still
has gcc/cp/ and gcc/ parts that weren't acked.
If
On Wed, Mar 24, 2021 at 09:45:31AM -0600, Martin Sebor via Gcc-patches wrote:
> E.g., OEP_IGNORE_MEMBER_OFFSET or OEP_SAME_MEMBER_OFFSET (for
> the converse of the first) or something like that, but hopefully
> you get the idea.
Neither of these look like a good name to me, OEP_IGNORE_MEMBER_OFFSE
On 3/24/21 10:40 AM, Jakub Jelinek wrote:
On Wed, Mar 24, 2021 at 09:45:31AM -0600, Martin Sebor via Gcc-patches wrote:
E.g., OEP_IGNORE_MEMBER_OFFSET or OEP_SAME_MEMBER_OFFSET (for
the converse of the first) or something like that, but hopefully
you get the idea.
Neither of these look like a
For always_inline in system headers, we don't know if caller's ISAs are
compatible with callee's ISAs until much later. Skip ISA check for
always_inline in system headers if caller has target attribute.
gcc/
PR target/98209
PR target/99744
* config/i386/i386.c (ix86_can_i
On Wed, 26 Aug 2020, Vladimir Makarov via Gcc-patches wrote:
> On 2020-08-26 5:06 a.m., Richard Sandiford wrote:
> >
> > I don't think we should we restrict this to (plus (mult X Y) Z),
> > since addresses can be more complicated than that. One way to
> > search for all MULTs is:
> >
> >sub
Hi Andrew,
this patch adds gfx908 to the change log.
OK? — Is there anything else to add? Other wording suggestions?
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
Thürauf
It started with g:3e2ae3ee285a57455d5a23bd352a68c289130186 where
new entry was added to processor_alias_table after generic node:
+ {"amdfam19h", PROCESSOR_GENERIC, CPU_GENERIC, 0,
+M_CPU_TYPE (AMDFAM19H), P_NONE},
and then the following is violated:
/* NB: processor_alias_table stops at t
> It started with g:3e2ae3ee285a57455d5a23bd352a68c289130186 where
> new entry was added to processor_alias_table after generic node:
>
> + {"amdfam19h", PROCESSOR_GENERIC, CPU_GENERIC, 0,
> +M_CPU_TYPE (AMDFAM19H), P_NONE},
>
> and then the following is violated:
>
> /* NB: processor_alias
On Wed, Mar 24, 2021 at 11:30 AM Iain Sandoe wrote:
>
> David Edelsohn via Gcc-patches wrote:
>
> > On Wed, Mar 24, 2021 at 3:51 AM Richard Biener
> > wrote:
> >> On Wed, Mar 24, 2021 at 3:03 AM David Edelsohn wrote:
> >>> On Mon, Mar 22, 2021 at 4:10 AM Richard Biener
> >>> wrote:
> >>>
> >>>
On 23/03/21 4:42 pm, Jonathan Wakely wrote:
On 20/03/21 22:32 +0100, François Dumont wrote:
Following your feedback here is the simplified version. I grouped it
with the patch I submitted before.
On 19/03/21 8:41 pm, Jonathan Wakely wrote:
I think we could just define on partial specializati
On Wed, 24 Mar 2021, Tobias Burnus wrote:
> Hi Andrew,
>
> this patch adds gfx908 to the change log.
> OK? — Is there anything else to add? Other wording suggestions?
We tend to use present perfect tense ("has been added"), but that's
a minor note.
Would you like to add an id to the heading, so
On Wed, Mar 24, 2021 at 3:46 PM David Edelsohn wrote:
>
> On Wed, Mar 24, 2021 at 11:30 AM Iain Sandoe wrote:
> >
> > David Edelsohn via Gcc-patches wrote:
> >
> > > On Wed, Mar 24, 2021 at 3:51 AM Richard Biener
> > > wrote:
> > >> On Wed, Mar 24, 2021 at 3:03 AM David Edelsohn wrote:
> > >>>
Various false positives from -fanalyzer involve SSA names in loops,
where sm-state associated with an SSA name from one iteration is
erroneously reused in a subsequent iteration.
For example, PR analyzer/99716 describes a false
"double 'fclose' of FILE 'fp'"
on:
for (i = 0; i < 2; ++i) {
On 2021/3/24 23:56, David Edelsohn wrote:
On Wed, Mar 24, 2021 at 1:44 AM Xionghu Luo wrote:
l2 cache size for Power8 is 512kB, correct the copy paste error from Power7.
Tested no performance change for SPEC2017.
gcc/ChangeLog:
2021-03-24 Xionghu Luo
* config/rs6000/rs6000.c (str
On Wed, Mar 24, 2021 at 11:32 PM Xionghu Luo wrote:
>
> On 2021/3/24 23:56, David Edelsohn wrote:
> > On Wed, Mar 24, 2021 at 1:44 AM Xionghu Luo wrote:
> >> l2 cache size for Power8 is 512kB, correct the copy paste error from
> >> Power7.
> >> Tested no performance change for SPEC2017.
> >>
> >
Hi,
I happened to find this possible use of uninitialized inside_cost during
checking the cost for reduction. Before r11-6587, all the if/else if/else
arms will assign values to inside_cost, so it was fine. But from r11-6587
the else path won't assign any more, it leads the inside_cost possibly
On 3/25/2021 12:04 AM, Kewen.Lin via Gcc-patches wrote:
Hi,
I happened to find this possible use of uninitialized inside_cost during
checking the cost for reduction. Before r11-6587, all the if/else if/else
arms will assign values to inside_cost, so it was fine. But from r11-6587
the else pa
On Wed, Mar 24, 2021 at 6:23 PM H.J. Lu wrote:
>
> For always_inline in system headers, we don't know if caller's ISAs are
> compatible with callee's ISAs until much later. Skip ISA check for
> always_inline in system headers if caller has target attribute.
>
> gcc/
>
> PR target/98209
>
46 matches
Mail list logo
