Re: Question about git: merging to gccgo branch

On Mon, 30 Mar 2020, Ian Lance Taylor via Gcc wrote: > On Mon, Mar 30, 2020 at 10:54 AM Joseph Myers wrote: > > > > On Mon, 30 Mar 2020, Martin Liška wrote: > > > > > Can you please disable email sending for user branch? Or does it make any > > > sense? > > > > Email sending for user branches

Re: Question about git: merging to gccgo branch

On Mon, Mar 30, 2020 at 10:54 AM Joseph Myers wrote: > > On Mon, 30 Mar 2020, Martin Liška wrote: > > > Can you please disable email sending for user branch? Or does it make any > > sense? > > Email sending for user branches makes perfect sense, to make visible the > development going on. It's

Re: Question about git: merging to gccgo branch

On 1/22/20 7:38 PM, Joseph Myers wrote: On Wed, 22 Jan 2020, Ian Lance Taylor wrote: I don't want to send 581 e-mails. I would be happy not sending any e-mails at all. I would also be happy sending 1 e-mail. This is the issue we've discussed in

Re: [QUESTION] About RTL optimization at forward propagation

On Sat, Mar 28, 2020 at 4:19 AM xiezhiheng wrote: > > Hi, > I find there exists some restricts in function fwprop preventing it to > forward propagate addresses into loops. > /* Go through all the uses. df_uses_create will create new ones at the >end, and we'll go through them as well. >

Re: GSoC: Implementation of OMPD

Hi! I appreciate you are interested in this GSoC topic! On Tue, Mar 24, 2020 at 09:18:50PM -0400, y2s1982 . via Gcc wrote: > > The OMPD project idea might be the most ambitious from the whole lot. > > Basically, the goal is to come up with a prototype implementation of > > chapter 5 of OpenMP

-stdlib=libc++?

I think this would be great to support LLVM’s libc++ by be compatible with -stdlib=libc++ on clang. Sent from Mail for Windows 10

Re: -stdlib=libc++?

unlvsur unlvsur via Gcc wrote: I think this would be great to support LLVM’s libc++ by be compatible with -stdlib=libc++ on clang. I have a patch for this, for next stage 1. (we are in stage 4 now, so not the right time for new features). thanks Iain

Re: Question about git: merging to gccgo branch

On Mon, 30 Mar 2020, Martin Liška wrote: > Can you please disable email sending for user branch? Or does it make any > sense? Email sending for user branches makes perfect sense, to make visible the development going on. It's specifically email sending for merges of commits already present in

Re: Can we please have the old mailing list back

On Sat, 2020-03-28 at 18:46 +, Maciej W. Rozycki wrote: > On Fri, 27 Mar 2020, Jeff Law via Gcc wrote: > > > As an ex IT guy, I've gone both directions depending on the project I was > > supporting and certainly see the pros and cons of going highly customized vs > > as > > generic as

[Bug c++/94418] New: Please make reverse_iterator nothrow constructible when possible

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94418 Bug ID: 94418 Summary: Please make reverse_iterator nothrow constructible when possible Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal

[Bug tree-optimization/94375] 548.exchange2_r run time is 8-18% worse than GCC 9 at -Ofast -march=native

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94375 --- Comment #4 from Hongtao.liu --- (In reply to Martin Jambor from comment #3) > (In reply to Hongtao.liu from comment #1) > > Try -mprefer-vector-width=128,256-bit vectorization is not helpful for 548 > > according to our experience. > > I

[Bug tree-optimization/94401] [10 Regression] pr92420.c fails on aarch64 since r10-7415

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94401 --- Comment #5 from Kewen Lin --- Created attachment 48150 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48150=edit untested patch This can fix the REG failures on aarch64.

[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94386 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org ---

[Bug c++/94418] Please make reverse_iterator nothrow constructible when possible

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94418 --- Comment #1 from Rafael Avila de Espindola --- For what it is worth, libc++ implements this. Given static_assert(std::is_nothrow_copy_constructible_v::reverse_iterator>); With libstdc++: $ clang -S test3.cc -std=c++17 test3.cc:3:1: error:

[Bug c/89990] request warning: Use of out of scope compound literals

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89990 Andrew D'Addesio changed: What|Removed |Added CC||modchipv12 at gmail dot com ---

[Bug fortran/94411] E0.d not supported

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94411 --- Comment #2 from Bill Long --- Thanks for the quick reply. Is there a predicted release date for 10.1?

[Bug gcov-profile/94394] [GCOV]It will cause random kernel panic during collecting kernel code coverage

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94394 --- Comment #5 from ammy.yi --- (In reply to Martin Liška from comment #4) > (In reply to ammy.yi from comment #3) > > Actually, there is some random kernel panic here. > > > > The following steps may reproduce this issue: > > > > 1. Enable

[Bug sanitizer/94307] Provide a way to declare the *SAN exception handler -fsanitize-undefined-trap-on-error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94307 --- Comment #5 from Kees Cook --- Hi! I recently learned that Clang has -fsanitizer-minimal-runtime that is very close to what I was expecting to use: https://bugs.llvm.org/show_bug.cgi?id=45295 That is close to what you're already suggesting.

[Bug fortran/94411] E0.d not supported

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94411 --- Comment #3 from Steve Kargl --- On Tue, Mar 31, 2020 at 04:47:04AM +, longb at cray dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94411 > > --- Comment #2 from Bill Long --- > Thanks for the quick reply. Is there a

[Bug target/94420] New: ICE error: insn does not satisfy its constraints

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94420 Bug ID: 94420 Summary: ICE error: insn does not satisfy its constraints Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal

[Bug tree-optimization/94401] [10 Regression] pr92420.c fails on aarch64 since r10-7415

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94401 Kewen Lin changed: What|Removed |Added CC||segher at gcc dot gnu.org,

[Bug ada/94419] New: accepting wrong programs because compiler error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94419 Bug ID: 94419 Summary: accepting wrong programs because compiler error Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3

[Bug target/94417] -fcf-protection -mcmodel=large/-mforce-indirect-call is broken

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94417 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0

[Bug tree-optimization/94375] 548.exchange2_r run time is 8-18% worse than GCC 9 at -Ofast -march=native

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94375 --- Comment #5 from Hongtao.liu --- (In reply to Hongtao.liu from comment #4) > (In reply to Martin Jambor from comment #3) > > (In reply to Hongtao.liu from comment #1) > > > Try -mprefer-vector-width=128,256-bit vectorization is not helpful

[Bug target/94417] -fcf-protection -mcmodel=large/-mforce-indirect-call is broken

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94417 H.J. Lu changed: What|Removed |Added Summary|-fcf-protection |-fcf-protection

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 --- Comment #23 from Fangrui Song --- (In reply to Andrew Pinski from comment #18) > (In reply to Yuxuan Shui from comment #17) > > Sorry, I am here to report a bug, not to find a workaround for my use case. > > I gave you the correct usage for

Re: [PATCH V3][gcc] libgccjit: introduce version entry points

On Mon, 2020-03-30 at 12:09 -0400, David Malcolm via Gcc-patches wrote: > On Sun, 2020-03-29 at 21:31 +0100, Andrea Corallo wrote: > > David Malcolm writes: > > > > > On Wed, 2020-03-18 at 23:51 +0100, Andrea Corallo wrote: > > > Please add the new test to the header in its alphabetical > > >

Re: [PATCH] c++: Fix ICE in tsubst_default_argument [PR92010]

On Mon, 30 Mar 2020, Jason Merrill wrote: > On 3/30/20 3:58 PM, Patrick Palka wrote: > > On Thu, 26 Mar 2020, Jason Merrill wrote: > > > > > On 3/22/20 9:21 PM, Patrick Palka wrote: > > > > This patch relaxes an assertion in tsubst_default_argument that exposes > > > > a > > > > latent > > > >

Re: [PATCH], Make PowerPC -mcpu=future enable -mpcrel on linux ELFv2

Hi! On Mon, Mar 30, 2020 at 12:50:43PM -0500, will schmidt wrote: > On Fri, 2020-03-27 at 21:31 -0400, Michael Meissner via Gcc-patches > > * config/rs6000/rs6000.c (PCREL_SUPPORTED_BY_OS): New macro. > > (rs6000_option_override_internal): Set the -mprefixed and > > -mpcrel > >

Re: [PATCH] lra: set insn_code_data to NULL when freeing

On 2020-03-30 12:06 p.m., David Malcolm wrote: It's a double-free bug in lra.c, albeit one that requires being used in a multithreaded way from libgccjit to be triggered. libgccjit's test-threads.c repeatedly compiles and runs numerous tests, each in a separate thread. Attempting to add an

[Bug fortran/94411] E0.d not supported

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94411 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org ---

[Bug c++/94415] New: Implement DR 2237: Can a template-id name a constructor?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94415 Bug ID: 94415 Summary: Implement DR 2237: Can a template-id name a constructor? Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal

[Bug c++/94415] Implement DR 2237: Can a template-id name a constructor?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94415 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|

[Bug tree-optimization/94416] New: passing a restricted pointer to a function can be assumed not to modify an accessed object

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94416 Bug ID: 94416 Summary: passing a restricted pointer to a function can be assumed not to modify an accessed object Product: gcc Version: 10.0 Status: UNCONFIRMED

[Bug c/94389] __attribute__((warn_unused_result)) will warn if the result is discarded as an optimisation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94389 --- Comment #7 from Segher Boessenkool --- (In reply to felix from comment #6) > I don’t mind the transformation being applied. That is not what I said. I said the **language frontend** should not do this. A language frontend should give an

[Bug c/93573] [8/9/10 Regression] internal compiler error: in force_constant_size, at gimplify.c:733

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93573 --- Comment #7 from joseph at codesourcery dot com --- Passing a variable-size struct or union by value to a non-nested function seems very questionable (the function couldn't be declared with a matching prototype), but perhaps that doesn't

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 --- Comment #17 from Yuxuan Shui --- (In reply to H.J. Lu from comment #16) > (In reply to Yuxuan Shui from comment #15) > > Your code is going to dereference the value stored in the ABS symbol as an > > address (e.g. if the symbol has value 10,

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 --- Comment #20 from Yuxuan Shui --- (In reply to Andrew Pinski from comment #18) > (In reply to Yuxuan Shui from comment #17) > > Sorry, I am here to report a bug, not to find a workaround for my use case. > > I gave you the correct usage for

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 --- Comment #18 from Andrew Pinski --- (In reply to Yuxuan Shui from comment #17) > Sorry, I am here to report a bug, not to find a workaround for my use case. I gave you the correct usage for your use case. If you don't like it is not my

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 Yuxuan Shui changed: What|Removed |Added Resolution|WORKSFORME |--- Status|RESOLVED

[Bug c++/93431] FAIL: g++.dg/cpp2a/lambda-uneval9.C -std=c++2a (test for excess errors)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93431 --- Comment #2 from John David Anglin --- Does this test need -fcommon option?

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

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

[Bug c/94392] [10 Regression] Infinite loops are optimized away for C99

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94392 --- Comment #3 from joseph at codesourcery dot com --- I'm not sure the existing infinite loop removal is valid for any C standard version. The C (C11 and later) rule against infinite loops only applies when the loop is written as an

[Bug target/94417] New: -fcf-protection -mcmodel=large is broken

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94417 Bug ID: 94417 Summary: -fcf-protection -mcmodel=large is broken Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 Yuxuan Shui changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #22 from Yuxuan Shui

Re: PATCH -- Fix degree trignometric functions

On Mon, Mar 30, 2020 at 4:53 PM Tobias Burnus wrote: > > Hi Fritz, > > On 3/30/20 10:20 PM, Fritz Reese via Fortran wrote: > > >>> * All included files need dependency; I do not quickly > >>>see whether that' the case. > > If one looks at the build, the dependency is automatically > obtained

[Bug c++/90711] [9/10 Regression] Failing SFINAE from unrelated struct since r9-6794

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90711 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:5830f753559f25a5dabcc3507bffa611c6b575a6 commit r10-7465-g5830f753559f25a5dabcc3507bffa611c6b575a6 Author: Jason Merrill Date:

[Bug fortran/94408] Spurious error: ‘rw_nl_grid’ must be a module procedure or an external procedure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94408 --- Comment #3 from michalak at ucar dot edu --- Thank you, I've verified that removing the interface definitions works for this test program and provides a workaround for the original code from which this example was pulled. I'm not sure that

[Bug sanitizer/71962] error: ‘((& x) != 0u)’ is not a constant expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71962 S. Davis Herring changed: What|Removed |Added CC||herring at lanl dot gov --- Comment

[Bug c++/94414] New: only `--` gives constexpr

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94414 Bug ID: 94414 Summary: only `--` gives constexpr Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee:

[Bug target/94364] 505.mcf_r is 8% faster when compiled with -mprefer-vector-width=128

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94364 --- Comment #1 from Richard Biener --- Huh, looks like this is the (patched by us) memory copying done in spec_qsort? I wonder if you can re-measure with our patching undone but then with -fno-strict-aliasing (though I think that only was

[Bug fortran/94397] [10 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94397 Richard Biener changed: What|Removed |Added Keywords||rejects-valid Target Milestone|---

Re: [PATCH] lower-subreg: PR94123, SVN r273240, causes gcc.target/powerpc/pr87507.c to fail

Peter Bergner via Gcc-patches writes: > The pr87507.c test case regressed due to Segher's commit that added > -fsplit-wide-types-early. The issue is that the lower-subreg pass only > decomposes the TImode code in the example if there is a pseudo reg to pseudo > reg copy. When the lower-subreg

[Bug c/94389] __attribute__((warn_unused_result)) will warn if the result is discarded as an optimisation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94389 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #1

Re: [PATCH 2/2] Fix alignment for local variable [PR90811]

On Fri, Mar 27, 2020 at 7:27 PM Jakub Jelinek wrote: > > On Sat, Mar 28, 2020 at 02:06:56AM +0800, Kito Cheng wrote: > > PR target/90811 > > * ipa-increase-alignment.cc (increase_alignment_local_var): New. > > (increase_alignment_global_var): New. > >

[Bug libstdc++/94268] std::filebuf is extremely (at least 10x) slow on windows compared to Linux. Even much slower MSVC STL with terrible ABI.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94268 --- Comment #9 from fdlbxtqi --- https://github.com/microsoft/WSL/issues/3898

[PATCH] ICE: in vectorizable_load, at tree-vect-stmts.c:9173

Hi, New bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94398 With -mstrict-align, aarch64_builtin_support_vector_misalignment will returns false when misalignment factor is unknown at compile time. Then vect_supportable_dr_alignment returns dr_unaligned_unsupported, which triggers the ICE.

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 --- Comment #11 from Yuxuan Shui --- (In reply to Andrew Pinski from comment #8) > Also it is wrong for a person to assume a normal C variable could be > SHN_ABS; that is the bug here. It is a bug in the user code. > I showed up to fix it by

[Bug tree-optimization/94398] ICE: in vectorizable_load, at tree-vect-stmts.c:9173

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94398 --- Comment #3 from rsandifo at gcc dot gnu.org --- (In reply to Richard Biener from comment #2) > But the ICE happens because the result from the function at transform time > does not match that at analysis time. > > Richard? Looks like

Re: [PATCH 2/2] Fix alignment for local variable [PR90811]

> But I wonder if we can instead fix the memcpy inlining issue by > making the predicates involved honor LOCAL_ALIGNMENT > instead of relying on DECL_ALIGN? The memcpy inlining issue is not the only one affected by alignment issue, I guess? So I think it would be better to fix DECL_ALIGN? On

[Bug tree-optimization/94398] ICE: in vectorizable_load, at tree-vect-stmts.c:9173

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94398 rsandifo at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed|

[Bug target/94400] 531.deepsjeng_r is 7% slower at -O2 -march=znver2 than GCC 9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94400 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 CC|

[Bug rtl-optimization/94368] [9/10 Regression] ICE in final_scan_insn_1, at final.c:3074(error: could not split insn) on aarch64-linux-gnu since r9-3744

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94368 Richard Biener changed: What|Removed |Added Priority|P3 |P2

Re: [PATCH, 9/10 Regression] fortran : ICE in gfc_resolve_findloc PR93498

OK (both GCC 9 + 10). Thanks for the packaging the patch and to Steven for the patch. Tobias On 3/30/20 9:00 AM, Mark Eggleston wrote: Please find attached patch for PR93498. OK to commit? gcc/fortran/ChangeLog: Steven G. Kargl PR fortran/93498 * check.c (gfc_check_findloc):

[Bug gcov-profile/94394] [GCOV]It will cause random kernel panic during collecting kernel code coverage

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94394 --- Comment #3 from ammy.yi --- Actually, there is some random kernel panic here. The following steps may reproduce this issue: 1. Enable gcov in kconfig 2. build kernel and boot to system 3. Do following load/unload modules steps modprobe

[Bug tree-optimization/94375] 548.exchange2_r run time is 8-18% worse than GCC 9 at -Ofast -march=native

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94375 Richard Biener changed: What|Removed |Added Blocks||53947 --- Comment #2 from Richard

[Bug target/94383] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383 Richard Biener changed: What|Removed |Added Priority|P3 |P2

[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94386 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0

[PATCH] Check DECL_CONTEXT of new/delete operators.

Hi. The patch ensures that a deleted new/delete pair has a same context. That will fix the issue presented in the PR. Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Ready to be installed? Thanks, Martin gcc/ChangeLog: 2020-03-30 Martin Liska PR c++/94314

[Bug fortran/94397] [10 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94397 Martin Liška changed: What|Removed |Added Known to fail||10.0 Ever confirmed|0

Re: [PATCH] Check DECL_CONTEXT of new/delete operators.

On Mon, 30 Mar 2020, Martin Liška wrote: The patch ensures that a deleted new/delete pair has a same context. That will fix the issue presented in the PR. DECL_CONTEXT seems good for that example (assuming it is still available in the middle-end), but shouldn't we also check if both are

[Bug middle-end/87528] Popcount changes caused 531.deepsjeng_r run-time regression on Skylake

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87528 --- Comment #8 from Martin Jambor --- Do I understand correctly that this is fixed?

[Bug target/94368] [9/10 Regression] ICE in final_scan_insn_1, at final.c:3074(error: could not split insn) on aarch64-linux-gnu since r9-3744

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94368 Jakub Jelinek changed: What|Removed |Added CC||rth at gcc dot gnu.org --- Comment #6

[Bug target/94368] [9/10 Regression] ICE in final_scan_insn_1, at final.c:3074(error: could not split insn) on aarch64-linux-gnu since r9-3744

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94368 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org

Re: [PATCH 2/2] Fix alignment for local variable [PR90811]

Hi Jakub: I saw the omp and oacc related passes are in the head of all_passes, so I plan added after pass_omp_target_link, does it late enough? diff --git a/gcc/passes.def b/gcc/passes.def index 2bf2cb78fc5..92cbe587a8a 100644 --- a/gcc/passes.def +++ b/gcc/passes.def @@ -183,6 +183,7 @@ along

Re: [PATCH] Fix PR94043 by making vect_live_op generate lc-phi

On Mon, Mar 30, 2020 at 12:24 PM Kewen.Lin wrote: > > Hi, > > As PR94043 shows, my commit r10-4524 exposed one issue in > vectorizable_live_operation, which inserts one extra BB > before the single exit, leading unexpected operand expansion > and unexpected loop depth assertion. As Richi

[Bug c/94392] [10 Regression] Infinite loops are optimized away for C99

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94392 Richard Biener changed: What|Removed |Added Summary|Infinite loops are |[10 Regression] Infinite

[Bug tree-optimization/94398] New: ICE: in vectorizable_load, at tree-vect-stmts.c:9173

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94398 Bug ID: 94398 Summary: ICE: in vectorizable_load, at tree-vect-stmts.c:9173 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug tree-optimization/94398] ICE: in vectorizable_load, at tree-vect-stmts.c:9173

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94398 Richard Biener changed: What|Removed |Added Target||aarch64 CC|rguenther

[Bug target/94400] New: 531.deepsjeng_r is 7% slower at -O2 -march=znver2 than GCC 9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94400 Bug ID: 94400 Summary: 531.deepsjeng_r is 7% slower at -O2 -march=znver2 than GCC 9 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal

Re: [PATCH] tree: Fix -fcompare-debug issues due to protected_set_expr_location [PR94323]

On Fri, Mar 27, 2020 at 09:09:42PM +0100, Richard Biener wrote: > Sounds worth a try. Unfortunately that FAILed miserably: +FAIL: g++.dg/cpp0x/constexpr-object1.C -std=c++11 (test for excess errors) +FAIL: g++.dg/cpp0x/constexpr-object1.C -std=c++14 (test for excess errors) +FAIL:

[Bug gcov-profile/94369] 505.mcf_r is 6-7% slower at -Ofast -march=native with PGO+LTO than with just LTO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94369 --- Comment #2 from Richard Biener --- The profile looks unconclusive, the # samples differ but evenly increase. The overall number of samples is missing - does that increase by 6-7%?

Re: [Patch, 9/10 Regression] fortran: ICE in build_entry_thunks PR93814

Hi Mark, the error message does not make sense – and I also currently do not see why that example should be invalid. Regarding the error message: "uses the same global identifier" In the test program (attached or PR) I do see one function "f" and one entry "g" – and both "f" and "g" is only

Re: [Patch][Fortran] Fix error cleanup of select rank (PR93522)

Early *ping*. Tobias On 3/27/20 11:06 AM, Tobias Burnus wrote: Hi all, here, the reject_statement cleanup and the freeing of the namespace both remove the symbol. Solution: Remove it first, then clean the namespace – then the reject_statement has no (deleted) statement to cleanup. As select

[Bug gcov-profile/94394] [GCOV]It will cause random kernel panic during collecting kernel code coverage

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94394 --- Comment #4 from Martin Liška --- (In reply to ammy.yi from comment #3) > Actually, there is some random kernel panic here. > > The following steps may reproduce this issue: > > 1. Enable gcov in kconfig > 2. build kernel and boot to

Re: [PATCH 2/2] Fix alignment for local variable [PR90811]

On Mon, Mar 30, 2020 at 11:09:40AM +0200, Richard Biener wrote: > On Fri, Mar 27, 2020 at 7:27 PM Jakub Jelinek wrote: > > > > On Sat, Mar 28, 2020 at 02:06:56AM +0800, Kito Cheng wrote: > > > PR target/90811 > > > * ipa-increase-alignment.cc (increase_alignment_local_var): New. > > >

[Bug tree-optimization/94398] ICE: in vectorizable_load, at tree-vect-stmts.c:9173

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94398 --- Comment #1 from z.zhanghaijian at huawei dot com --- (gdb) bt #0 aarch64_builtin_support_vector_misalignment (mode=E_VNx4SFmode, type=0xb79ec2a0, misalignment=-1, is_packed=false) at ../../gcc-git/gcc/config/aarch64/aarch64.c:17510

[Bug c/94399] New: analyzer reports false positives for stuff freed using __attribute__((cleanup()))

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94399 Bug ID: 94399 Summary: analyzer reports false positives for stuff freed using __attribute__((cleanup())) Product: gcc Version: 10.0 Status: UNCONFIRMED

Re: [PATCH 2/2] Fix alignment for local variable [PR90811]

Hi Andrew: > > + FOR_EACH_FUNCTION_WITH_GIMPLE_BODY (node) > > +{ > > + function *fun = node->get_fun (); > > + FOR_EACH_LOCAL_DECL (fun, i, var) > > + { > > + align = LOCAL_DECL_ALIGNMENT (var); > > + > > + SET_DECL_ALIGN (var, align); > > > I think this is

[PATCH] Fix PR94043 by making vect_live_op generate lc-phi

Hi, As PR94043 shows, my commit r10-4524 exposed one issue in vectorizable_live_operation, which inserts one extra BB before the single exit, leading unexpected operand expansion and unexpected loop depth assertion. As Richi suggested, this patch is to teach vectorizable_live_operation to

[Bug target/94373] 548.exchange2_r run time is 7-12% worse than GCC 9 at -O2 and generic march/mtune

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94373 --- Comment #4 from Richard Biener --- Note the cited commit simply caused more complete unrolling to happen. Too much actually which is why I reverted it. Note GCC 9.2 does not have that more unrolling so the difference must be something else

[Bug middle-end/94387] Excess read instructions are generated in case of writing to fields of volatile + packed type (structure)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94387 --- Comment #5 from Richard Biener --- volatile semantics on misaligned fields and strict-align targets cannot be honored. I suggest you add appropriate __attribute__((aligned(..))) if you know the whole structure is aligned and just want

[Bug target/94396] [8/9/10 Regression] fp16 feature bits not passed on to assembler from Armv8.4-a and up.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94396 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.5

[Bug middle-end/94387] Excess read instructions are generated in case of writing to fields of volatile + packed type (structure)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94387 --- Comment #6 from Petro Karashchenko --- Richard Biener thank you for suggestion, but __attribute__((aligned(..))) is applied only to the base address of the struct, hence to the first field only, so if I'm having other fields tightly packed

[Bug tree-optimization/90332] New test case gcc.dg/vect/slp-reduc-sad-2.c in r270847 fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90332 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment

Re: [PATCH 2/2] Fix alignment for local variable [PR90811]

On Mon, Mar 30, 2020 at 06:24:32PM +0800, Kito Cheng wrote: > Hi Jakub: > > I saw the omp and oacc related passes are in the head of all_passes, > so I plan added after pass_omp_target_link, does it late enough? Yes, that is ok. > diff --git a/gcc/passes.def b/gcc/passes.def > index

[Bug tree-optimization/90332] New test case gcc.dg/vect/slp-reduc-sad-2.c in r270847 fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90332 --- Comment #11 from rguenther at suse dot de --- On Mon, 30 Mar 2020, clyon at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90332 > > Christophe Lyon changed: > >What|Removed

[Bug c++/94314] [10 Regression] Optimizing mismatched new/delete pairs since r10-2106-g6343b6bf3bb83c87

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94314 --- Comment #7 from Martin Liška --- > It should be sufficient to check whether they have the same DECL_CONTEXT. This seems to work. I'm testing a patch candidate.

Re: [PATCH, 8/9/10 Regression] fortran: ICE equivalence with an element of an array PR94030

OK. Thanks, Tobias On 3/30/20 9:30 AM, Mark Eggleston wrote: Please find attached patch for PR94030. OK to commit? gcc/fortran/ChangeLog: Steven G. Kargl PR fortran/94030 * resolve.c (resolve_equivalence): Correct formatting around the label "identical_types". Instead

Re: [PATCH] Check DECL_CONTEXT of new/delete operators.

On Mon, Mar 30, 2020 at 10:41 AM Martin Liška wrote: > > Hi. > > The patch ensures that a deleted new/delete pair has a same context. > That will fix the issue presented in the PR. > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. I think this will break the DCE with LTO

  1   2   3   >