Re: [PATCH] middle-end IFN_ASSUME support [PR106654]

Am Samstag, den 15.10.2022, 10:53 +0200 schrieb Jakub Jelinek: > On Sat, Oct 15, 2022 at 10:07:46AM +0200, Martin Uecker wrote: > > But why? Do we really want to encourage people to > > write such code? > > Of course these ++ cases inside of expressions are just obfuscation. > But the point is to

Re: [PATCH 4/6] Support Intel AVX-NE-CONVERT

On Fri, Oct 14, 2022 at 3:58 PM Haochen Jiang via Gcc-patches wrote: > > From: Kong Lingling > > gcc/ChangeLog: > > * common/config/i386/i386-common.cc > (OPTION_MASK_ISA2_AVXNECONVERT_SET, > OPTION_MASK_ISA2_AVXNECONVERT_UNSET): New. > (ix86_handle_option):

RE: [r13-3172 Regression] FAIL:libgomp.oacc-c../../libgomp.oacc-c-c..-common/kernels-loop-g.c -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -O2 (test for excess errors) on Linux/x86_64

If that has been fixed, just ignore that mail. It is run through by a script and got the result few days ago. However, the sendmail service was down on that machine and I just noticed that issue. So I sent that result manually today in case that is not fixed. Sorry for the disturb! BRs,

RE: [r13-3172 Regression] FAIL:libgomp.oacc-c../../libgomp.oacc-c-c..-common/kernels-loop-g.c -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -O2 (test for excess errors) on Linux/x86_64

That commit had a bug that was fixed in https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=80f414e6d73f9f1683f93d83ce63a6a482e54bee Was that fix included in your GCC build? From: Jiang, Haochen Sent: Sunday, October 16, 2022 8:09 PM To: gcc-patches@gcc.gnu.org; Eugene Rozenfeld ; Jiang, Haochen ;

Re: [PATCH 2/6] Support Intel AVX-VNNI-INT8

On Fri, Oct 14, 2022 at 3:57 PM Haochen Jiang via Gcc-patches wrote: > > From: Kong Lingling > > gcc/ChangeLog > > * common/config/i386/cpuinfo.h (get_available_features): Detect > avxvnniint8. > * common/config/i386/i386-common.cc >

[Bug testsuite/107240] [13 Regression] FAIL: gcc.dg/vect/vect-bitfield-write-2.c since r13-3219-g25413fdb2ac249

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107240 Kewen Lin changed: What|Removed |Added CC||linkw at gcc dot gnu.org --- Comment #6

Re: [PATCH] Move scanning pass of forwprop-19.c to dse1 for r13-3212-gb88adba751da63

On Mon, Oct 17, 2022 at 11:26 AM Liwei Xu via Gcc-patches wrote: > > gcc/testsuite/ChangeLog: > > * gcc.dg/tree-ssa/forwprop-19.c: Move scanning pass from forwprop1 to > dse1, This fixs > the test case fail. Looks like an obvious fix to me. > --- >

[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172 --- Comment #34 from Hongtao.liu --- There's 2 similar issues in PR107273 and PR107269.

[Bug tree-optimization/107269] wrong code at -O1 and above with "-fno-tree-ccp" on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107269 Hongtao.liu changed: What|Removed |Added CC||crazylht at gmail dot com --- Comment #3

[PATCH] Move scanning pass of forwprop-19.c to dse1 for r13-3212-gb88adba751da63

gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/forwprop-19.c: Move scanning pass from forwprop1 to dse1, This fixs the test case fail. --- gcc/testsuite/gcc.dg/tree-ssa/forwprop-19.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[Bug tree-optimization/107273] wrong code at -O3 on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107273 Hongtao.liu changed: What|Removed |Added CC||crazylht at gmail dot com --- Comment #4

[r13-3212 Regression] FAIL: gcc.dg/tree-ssa/forwprop-19.c scan-tree-dump-not forwprop1 .VEC_PERM_EXPR. on Linux/x86_64

On Linux/x86_64, b88adba751da635c6f0c353c5bc51bbe2ecf4c89 is the first bad commit commit b88adba751da635c6f0c353c5bc51bbe2ecf4c89 Author: Liwei Xu liwei...@intel.com Date: Fri Sep 23 13:46:02 2022 +0800 Optimize nested permutation to single VEC_PERM_EXPR [PR54346]

[Bug middle-end/107284] New: Option properties Mask infrastructure can be extended with wide_int_bitmask

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107284 Bug ID: 107284 Summary: Option properties Mask infrastructure can be extended with wide_int_bitmask Product: gcc Version: 13.0 Status: UNCONFIRMED Severity:

[r13-3172 Regression] FAIL:libgomp.oacc-c../../libgomp.oacc-c-c..-common/kernels-loop-g.c -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -O2 (test for excess errors) on Linux/x86_64

On Linux/x86_64, f30e9fd33e56a5a721346ea6140722e1b193db42 is the first bad commit commit f30e9fd33e56a5a721346ea6140722e1b193db42 Author: Eugene Rozenfeld mailto:ero...@microsoft.com>> Date: Thu Apr 21 16:43:24 2022 -0700 Set discriminators for call stmts on the same line within the same

Re: [PATCH 0/6] Add Intel Sierra Forest Instructions

On Mon, Oct 17, 2022 at 9:30 AM Bernhard Reutner-Fischer wrote: > > On 17 October 2022 03:02:22 CEST, Hongtao Liu via Gcc-patches > > >> >> Do you have this series as a branch somewhere that I can try on one of > >> >> the > >> >> like affected platforms? > >> > > >> > Not yet. > >> > Do we have

compile only

hey, what about not compiling functions, that arent called...and also , what about precompiled functions that arent changed thanks in advance andre

Re: [PATCH 0/6] Add Intel Sierra Forest Instructions

On 17 October 2022 03:02:22 CEST, Hongtao Liu via Gcc-patches >> >> Do you have this series as a branch somewhere that I can try on one of the >> >> like affected platforms? >> > >> > Not yet. >> > Do we have any external place to put those patches so folks from the >> > community can validate

Re: [PATCH v3] Re: OpenMP: Generate SIMD clones for functions with "declare target"

On 9/30/22 04:37, Jakub Jelinek wrote: We've discussed this at Cauldron. Especially for this patch, but less urgently for explicit declare simd on non-exported functions (less urgently just because people don't mark everything declare simd usually) solving the above is essential. I don't say

Re: [PATCH 2/2] Initial Meteorlake Support

On Fri, Oct 14, 2022 at 3:41 PM Haochen Jiang via Gcc-patches wrote: > > From: "Hu, Lin1" > > gcc/ChangeLog: > > * common/config/i386/cpuinfo.h: > (get_intel_cpu): Handle Meteorlake. > * common/config/i386/i386-common.cc: > (processor_alias_table): Add Meteorlake.

Re: [PATCH 1/2] Initial Raptorlake Support

On Fri, Oct 14, 2022 at 3:41 PM Haochen Jiang via Gcc-patches wrote: > > gcc/ChangeLog: > > * common/config/i386/cpuinfo.h: > (get_intel_cpu): Handle Raptorlake. > * common/config/i386/i386-common.cc: > (processor_alias_table): Add Raptorlake. Ok. > --- >

Re: [PATCH 0/6] Add Intel Sierra Forest Instructions

On Fri, Oct 14, 2022 at 4:36 PM Iain Sandoe wrote: > > > > > On 14 Oct 2022, at 09:30, Hongtao Liu wrote: > > > > On Fri, Oct 14, 2022 at 4:24 PM Iain Sandoe wrote: > >> > >> > >> > >>> On 14 Oct 2022, at 09:20, Hongtao Liu wrote: > >>> > >>> On Fri, Oct 14, 2022 at 4:14 PM Iain Sandoe via

[Bug tree-optimization/107283] conversions u/int64_t to float64/32_t are not vectorized

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107283 --- Comment #2 from g.peterh...@t-online.de --- That will be right. I had reported something similar many years ago - but it was not fixed. thx Gero

[Bug tree-optimization/107283] conversions u/int64_t to float64/32_t are not vectorized

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107283 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization

[Bug c++/107283] New: conversions u/int64_t to float64/32_t are not vectorized

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107283 Bug ID: 107283 Summary: conversions u/int64_t to float64/32_t are not vectorized Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal

[Bug c++/107282] New: ICE on valid code template + overloaded + visit

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107282 Bug ID: 107282 Summary: ICE on valid code template + overloaded + visit Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

gcc-13-20221016 is now available

Snapshot gcc-13-20221016 is now available on https://gcc.gnu.org/pub/gcc/snapshots/13-20221016/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 13 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch

Re: [PATCH, v2] Fortran: handle bad array ctors with typespec [PR93483, , PR107216, PR107219]

Le 15/10/2022 à 22:15, Harald Anlauf via Fortran a écrit : Dear all, here is an updated version of the patch that includes suggestions and comments by Mikael in PR93483. Basic new features are: - a new enum value ARITH_NOT_REDUCED to keep track if we encountered   an expression that was not

[Bug target/107281] comparisations with u/int64_t constants not generate vector-result

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107281 --- Comment #2 from Uroš Bizjak --- Try to compile the testcase with -msse4.2.

Re: [PATCH] Fortran: check type of operands of logical operations, comparisons [PR107272]

Le 16/10/2022 à 20:46, Harald Anlauf via Fortran a écrit : Dear all, this PR is actually very related to PR107217 that addressed ICEs with bad array constructors with typespec when used in arithmetic expressions. The present patch extends the checking to logical operations and to comparisons

[Bug target/107281] comparisations with u/int64_t constants not generate vector-result

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107281 --- Comment #1 from Andrew Pinski --- Created attachment 53711 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53711=edit testcase

[PATCH] Don't print discriminators for -fcompare-debug.

With -gstatement-frontiers we may end up with different IR coming from the front end with and without debug information turned on. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100733 for details. That may result in differences in discriminator values and -fcompare-debug failures. This patch

[Bug c++/107281] New: comparisations with u/int64_t constants not generate vector-result

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107281 Bug ID: 107281 Summary: comparisations with u/int64_t constants not generate vector-result Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal

Re: [Patch] Fortran: Fixes for kind=4 characters strings [PR107266]

Hi Tobias, the patch LGTM. Regarding testcase char4_decl-2.f90, I played a little and found that one could in addition check the storage_size of aa, pp in the main and compare with storage_size (4_'foo') etc. Without your patch the storage sizes look odd. (Strictly speaking, a comparison like

[Bug target/101697] [11/12/13 regression] ICE compiling uClibc-ng for h8300-linux

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101697 --- Comment #6 from Jeffrey A. Law --- So this issue has come up again in the context of LRA conversion which happens to trip over the same bug, but with a different testcase. At the core of this problem is reload and LRA will both generate

[Bug c++/107280] New: ICE: tree check: expected constructor, have view_convert_expr in cxx_eval_store_expression, at cp/constexpr.cc:5928

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107280 Bug ID: 107280 Summary: ICE: tree check: expected constructor, have view_convert_expr in cxx_eval_store_expression, at cp/constexpr.cc:5928 Product: gcc

[Bug fortran/107272] ICE in gfc_compare_string and others (related to pr107217)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107272 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot

[PATCH] Fortran: check type of operands of logical operations, comparisons [PR107272]

Dear all, this PR is actually very related to PR107217 that addressed ICEs with bad array constructors with typespec when used in arithmetic expressions. The present patch extends the checking to logical operations and to comparisons and catches several ICE-on-invalid as well as a few cases of

[PATCH] microblaze: use strverscmp() in MICROBLAZE_VERSION_COMPARE()

Currently, combining '-mxl-multiply-high' with -mcpu=v11.0 produces the following bogus warning: echo "int main(){}" | ./microblazeel-linux-gnu-gcc -mxl-multiply-high \ -mno-xl-soft-mul -mcpu=v11.0 -nostdlib -x c - warning: '-mxl-multiply-high' can be used only with '-mcpu=v6.00.a' or

Re: [PATCH] [X86_64]: Enable support for next generation AMD Zen4 CPU

On Thu, Oct 13, 2022 at 5:33 PM Joshi, Tejas Sanjay wrote: > > [Public] > > Hi all, > > PFA, the patch that enables support for the next generation AMD Zen4 CPU via > -march=znver4. > This is a basic enablement patch and as of now the costings, tunings are kept > same as znver3. > > Good for

[Bug tree-optimization/107206] Bogus -Wuninitialized in std::optional

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107206 --- Comment #6 from rguenther at suse dot de --- > Am 14.10.2022 um 18:53 schrieb jamborm at gcc dot gnu.org > : > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107206 > > --- Comment #5 from Martin Jambor --- > I believe this is fallout

[committed] Add new constraints for upcoming autoinc fixes on the H8

GCC does not allow a the operand of an autoinc addressing mode to overlap with another soure operand in the same insn.  This is primarly enforced with insn conditions.  However, cases can slip through LRA and reload.  To address those scenarios we'll take an idea from the pdp11 port for

[Bug c++/107279] __builtin_complex is not supported

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107279 --- Comment #2 from Andrew Pinski --- I don't care which way this gets fixed. That is the documentation could be changed or we support this in the C++ front-end.

[Bug c++/107279] __builtin_complex is not supported

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107279 --- Comment #1 from Andrew Pinski --- Link to the current documentation: https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Complex.html#index-_005f_005fbuiltin_005fcomplex

[Bug c++/107279] New: __builtin_complex is not supported

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107279 Bug ID: 107279 Summary: __builtin_complex is not supported Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority:

[Bug c++/107278] fails to correctly parse template default function declarations.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107278 Jonathan changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #8 from Jonathan ---

[Bug c++/107278] fails to correctly parse template default function declarations.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107278 --- Comment #7 from Andrew Pinski --- (In reply to Andrew Pinski from comment #6) > Dup of bug 103593. > > CWG2237 is the defect report #. >From that defect report: ``` (Note that this resolution is a change for C++20, NOT a defect report

[Bug c++/107278] fails to correctly parse template default function declarations.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107278 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c++/103593] [11/12 Regression] Naming the constructor of a template class without using the injected-class-name causes parse error with C++20

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103593 Andrew Pinski changed: What|Removed |Added CC||ky4ct at arrl dot net --- Comment #6

[Bug c++/107278] fails to correctly parse template default function declarations.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107278 --- Comment #5 from Jonathan --- (In reply to Andrew Pinski from comment #4) > Clang might not implement the defect report after all ... This is why I asked for a link to it so I could understand this issue at its core; at any rate, thanks for

[Bug c++/107278] fails to correctly parse template default function declarations.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107278 --- Comment #4 from Andrew Pinski --- Clang might not implement the defect report after all ...

[Bug c++/107278] fails to correctly parse template default function declarations.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107278 --- Comment #3 from Jonathan --- (In reply to Andrew Pinski from comment #1) > Iirc there was a defect report against the c++ standard here and you should > just foo instead of foo kd5eax@KY4CT CLANG64 ~ $ cat test.cpp template class foo {

[Bug c++/107278] fails to correctly parse template default function declarations.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107278 --- Comment #2 from Jonathan --- (In reply to Andrew Pinski from comment #1) > Iirc there was a defect report against the c++ standard here and you should > just foo instead of foo kd5eax@KY4CT CLANG64 ~ $ cat test.cpp template class foo {

[Bug c++/107278] fails to correctly parse template default function declarations.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107278 --- Comment #1 from Andrew Pinski --- Iirc there was a defect report against the c++ standard here and you should just foo instead of foo

[committed] Rename "Z" constraint on H8/300 to "Zz".

I want to use Z for multi-letter constraints.  So first we have to adjust the existing use of Z.  This does not affect code generation. Pushed to the trunk, Jeff commit 709b2160bcd8f6f57c8754c73d40550895339c7b Author: Jeff Law Date: Sun Oct 16 10:58:52 2022 -0400 Rename "z"

[Bug c++/107278] New: fails to correctly parse template default function declarations.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107278 Bug ID: 107278 Summary: fails to correctly parse template default function declarations. Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal

[RFC PATCH] libstdc++, v2: Partial library support for std::float{16,32,64,128}_t

Hi! As the __bf16 support is now in at least on x86_64/i686, I've updated my patch to cover bfloat16_t as well and implemented almost everything for - the only thing missing I'm aware of is std::nextafter std::float16_t and std::bfloat16_t overloads (I think we probably need to implement that

[PATCH] builtins: Add various __builtin_*f{16,32,64,128,32x,64x,128x} builtins

Hi! When working on libstdc++ extended float support in , I found that we need various builtins for the _Float{16,32,64,128,32x,64x,128x} types. Glibc 2.26 and later provides the underlying libm routines (except for _Float16 and _Float128x for the time being) and in libstdc++ I think we need at

Re: Error: attempt to get value of unresolved symbol `L0'

On Tuesday 11 October 2022 19:07:55 Pali Rohár wrote: > On Tuesday 11 October 2022 15:33:59 Nick Clifton wrote: > > Hi Pali, Hi Richard, > > > > > Having file name and line number would be also useful as it took me > > > some time to figure out where is the issue... > > > > Right - I have tried

[Bug c/107277] New: Spurious -Wformat-overflow when combined with __builtin_expect()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107277 Bug ID: 107277 Summary: Spurious -Wformat-overflow when combined with __builtin_expect() Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal

[Bug c++/107267] ice in cp_gimplify_init_expr, at cp/cp-gimplify.cc:253

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107267 David Binderman changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment

[Bug c++/107267] ice in cp_gimplify_init_expr, at cp/cp-gimplify.cc:253

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107267 --- Comment #6 from David Binderman --- (In reply to David Binderman from comment #5) > (In reply to David Binderman from comment #4) > > Trying a git bisect with git hash 93b3ab6c0c6a44df. > > Seems good. Trying eb491ea5c10955c6. Seems good.

[Bug c++/107267] ice in cp_gimplify_init_expr, at cp/cp-gimplify.cc:253

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107267 --- Comment #5 from David Binderman --- (In reply to David Binderman from comment #4) > Trying a git bisect with git hash 93b3ab6c0c6a44df. Seems good. Trying eb491ea5c10955c6.

[Bug c++/107267] ice in cp_gimplify_init_expr, at cp/cp-gimplify.cc:253

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107267 --- Comment #4 from David Binderman --- Trying a git bisect with git hash 93b3ab6c0c6a44df.