[Bug c++/96162] New: [11 Regression] ICE in discriminator_for_local_entity, at cp/mangle.c:1910

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96162 Bug ID: 96162 Summary: [11 Regression] ICE in discriminator_for_local_entity, at cp/mangle.c:1910 Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords:

Accessing result data of target options without Mask or Var properties

Hi, How would I access the result data of target options that don't have Mask or Var properties? For example, how would I access the result ISA string in the -march option for the RISC-V target? Here is the relevant option code inside the .opt file: march= Target Report RejectNegative Joined

Re: [PATCH] RISC-V: Fix regular expression in target-specific test

On Fri, Jul 10, 2020 at 6:53 AM Simon Cook wrote: > Some square brackets were missing escape characters, causing DejaGnu to > try and call a proc with the name "at". > > gcc/testsuite/ChangeLog: > > * gcc.target/riscv/read-thread-pointer.c: Fix escaping on > regular expression.

[Bug bootstrap/96160] Building gcc with multiple make jobs fails with: gcc/xgcc: No such file or directory

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96160 --- Comment #4 from plevine457 at gmail dot com --- The offending command is > /var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/./gcc/xgcc > -B/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/./gcc/ -xc++ -nostdinc > /dev/null -S -o

[Bug middle-end/77373] __attribute__((vector_size(N))) fails on AIX in symtab_node::get

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77373 David Edelsohn changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

Re: [PATCH] rs6000: Define movsf_from_si2 to extract high part SF element from DImode[PR89310]

Hi! On Fri, Jul 10, 2020 at 09:39:40AM +0800, luoxhu wrote: > OK, seems the md file needs a format tool too... Heh. Just make sure it looks good (that is, does what it looks like), looks like the rest, etc. It's hard to do anything nice with unspecs, [ ] lists do not format well. > >> +

[Bug fortran/96158] Symbols not emitted for module common variables

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

Re: [PATCH 2/2] rs6000: Define define_insn_and_split to split unspec sldi+or to rldimi

Hi! On Thu, Jul 09, 2020 at 09:14:45PM -0500, Xiong Hu Luo wrote: > * config/rs6000/rs6000.md (rotl_unspec): New > define_insn_and_split. > +; rldimi with UNSPEC_SI_FROM_SF. > +(define_insn_and_split "*rotl_unspec" Please have rotldi3_insert in the name. "unspec" in the name

[Bug jit/96066] Cannot use values from some builtins because they are of void type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96066 --- Comment #2 from Antoni --- An attempt to use, let's say, __atomic_fetch_add_4, will result in a error like: libgccjit.so: error: unimplemented primitive type for builtin (type: BT_I4)

Re: [PATCH 1/2] rs6000: Init V4SF vector without converting SP to DP

Hi! On Thu, Jul 09, 2020 at 09:14:44PM -0500, Xiong Hu Luo wrote: > Move V4SF to V4SI, init vector like V4SI and move to V4SF back. > Better instruction sequence could be generated on Power9: > The point is to use lwz to avoid converting the single-precision to > double-precision upon load, pack

[Bug c++/59135] Incorrect ambiguity in constexpr function overloads

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59135 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to fail|

[PATCH] rs6000: add effective-target test ppc_mma_hw

Add a test for dejagnu to determine if execution of MMA instructions is supported in the test environment. Add an execution test to make sure that __builtin_cpu_supports("mma") is true if we can execute MMA instructions. OK for trunk and backport to 10? Thanks! Aaron gcc/testsuite/

[Bug libstdc++/96161] istream::ignore sets eofbit too soon

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96161 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2020-07-10 See Also|

gcc-9-20200710 is now available

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

[Bug target/95581] [11 Regression] ICE in gimple_call_arg, at gimple.h:3260 since r11-959-gb825a22890740f341eae566af27e18e528cd29a7

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95581 --- Comment #15 from CVS Commits --- The releases/gcc-10 branch has been updated by Bill Seurer : https://gcc.gnu.org/g:21d3be2159f1b55e903caa2b1f80369d3681902b commit r10-8463-g21d3be2159f1b55e903caa2b1f80369d3681902b Author: Bill Seurer

[Bug fortran/96158] Symbols not emitted for module common variables

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96158 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords|

[Bug bootstrap/96160] Building gcc with multiple make jobs fails with: gcc/xgcc: No such file or directory

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96160 --- Comment #3 from plevine457 at gmail dot com --- > Which make version are you using? GNU Make 4.3

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492 --- Comment #34 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549880.html

[PATCH] x86: Require Linux target for PR target/93492 tests

Since -fpatchable-function-entry is only supported on Linux and used by Linux kernel, require Linux target for PR target/93492 tests. PR target/93492 * gcc.target/i386/pr93492-1.c: Require Linux target. * gcc.target/i386/pr93492-2.c: Likewise. *

Re: New x86-64 micro-architecture levels

On Fri, Jul 10, 2020 at 10:30 AM Florian Weimer wrote: > > Most Linux distributions still compile against the original x86-64 > baseline that was based on the AMD K8 (minus the 3DNow! parts, for Intel > EM64T compatibility). > > There has been an attempt to use the existing AT_PLATFORM-based

[Bug c++/92812] Implement P1975R0: Fixing the wording of parenthesized aggregate-initialization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92812 --- Comment #6 from Marek Polacek --- Actually make that using T = int[1]; T&& arr = static_cast(42);

[Bug c++/92812] Implement P1975R0: Fixing the wording of parenthesized aggregate-initialization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92812 --- Comment #5 from Marek Polacek --- I don't know if this is supposed to be valid now too: int arr[1] = static_cast(42); or using T = int[]; int arr[1] = static_cast(42); but it seems so.

[Bug bootstrap/96160] Building gcc with multiple make jobs fails with: gcc/xgcc: No such file or directory

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96160 --- Comment #2 from Andrew Pinski --- Makefile.in: GCC_PASSES=xgcc$(exeext) specs SELFTEST_DEPS = $(GCC_PASSES) stmp-int-hdrs $(srcdir)/testsuite/selftests c/Make-lang.in C_SELFTEST_DEPS = cc1$(exeext) $(SELFTEST_DEPS) ... s-selftest-c:

[Bug libstdc++/96161] New: istream::ignore sets eofbit too soon

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96161 Bug ID: 96161 Summary: istream::ignore sets eofbit too soon Product: gcc Version: 10.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++

Re: Ping Re: c: Add C2X BOOL_MAX and BOOL_WIDTH to limits.h

On Thu, 2020-07-09 at 15:40 +, Joseph Myers wrote: > Ping for this limits.h patch > ;. OK. jeff

Re: [PATCH] rs6000: Add execution tests for mma builtins [v4]

Hi! On Fri, Jul 10, 2020 at 03:49:02PM -0500, Aaron Sawdey via Gcc-patches wrote: > This patch adds execution tests that use the MMA builtins and > check for the right answer, and new tests that checks whether > __builtin_cpu_supports and __builtin_cpu_is return sane > answers for power10. >

Re: [PATCH 4/6] Testsuite: Make it easier to debug environment setting functions

On Thu, 2020-07-09 at 10:56 +0100, Tamar Christina wrote: > Hi All, > > This adds verbose output to dg-set-compiler-env-var and dg-set-target-env-var > so you can actually see what they're setting when you add -v -v. > > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. > > Ok for

Re: [PATCH 5/6] Docs: Document environment setting directives for testsuite

On Thu, 2020-07-09 at 10:57 +0100, Tamar Christina wrote: > Hi All, > > This document some of the existing DejaGnu directives to modify > environment variables before test or compiler invocations. > > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. > > Ok for master? > >

[Bug bootstrap/96160] Building gcc with multiple make jobs fails with: gcc/xgcc: No such file or directory

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96160 --- Comment #1 from plevine457 at gmail dot com --- Created attachment 48861 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48861=edit gcc-10.1.0-xgcc-selftest-makeopts.patch This patch appears to resolve the issue on my end

[Bug bootstrap/96160] New: Building gcc with multiple make jobs fails with: gcc/xgcc: No such file or directory

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96160 Bug ID: 96160 Summary: Building gcc with multiple make jobs fails with: gcc/xgcc: No such file or directory Product: gcc Version: 10.1.0 Status: UNCONFIRMED

[PATCH] rs6000: Add execution tests for mma builtins [v4]

This patch adds execution tests that use the MMA builtins and check for the right answer, and new tests that checks whether __builtin_cpu_supports and __builtin_cpu_is return sane answers for power10. I've now cleaned up and separated things out so there are 4 test cases: * MMA single precision

[Bug translation/96159] atomic creates incorrect code for possible isaligned struct

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96159 --- Comment #2 from Martin Uecker --- Clang produces a call to __atomic_load. Also here is a godbolt link: https://godbolt.org/z/39PE1G

[Bug translation/96159] atomic creates incorrect code for possible isaligned struct

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96159 --- Comment #1 from Martin Uecker --- On x86-64 the following struct has alignment 4 but gcc creates a single mov instruction which according to my understanding may fail to be atomic when it crosses a cache line boundary. Documentation

[Bug translation/96159] New: atomic creates incorrect code for possible isaligned struct

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96159 Bug ID: 96159 Summary: atomic creates incorrect code for possible isaligned struct Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal

Re: [PATCH] Improve shrink-wrapping debug output

On Sat, 2020-07-04 at 16:07 +0300, Alexander Popov wrote: > Currently if requires_stack_frame_p() returns true for some insn, > the shrink-wrapping debug output contains only the number of a block > containing that insn. > > But it is very useful to see the particular insn that requires the >

Re: [PATCH, part 2] PR fortran/95980 - ICE in get_unique_type_string, at fortran/class.c:485

Hi Harald, This is not a regression, so I don't think we will need a backport. understood. On the downside, another patch I was working on unfortunately partially overlaps with the present one in resolve.c. At some point, there will be a conflict between the work involved in either

Re: [PATCH] contrib: Don't pass wget options to curl

On Tue, 2020-07-07 at 18:44 -0400, Mike Nolta via Gcc-patches wrote: > This is a harmless bug, as the script still works, but curl's '-O' > option isn't the same as wget's. > > contrib/ChangeLog: > > * download_prerequisites: Don't pass wget options to curl. THanks. I've pushed this to

[Bug fortran/96158] New: Symbols not emitted for module common variables

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96158 Bug ID: 96158 Summary: Symbols not emitted for module common variables Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

Aw: Re: [PATCH, part 2] PR fortran/95980 - ICE in get_unique_type_string, at fortran/class.c:485

Hi Thomas, > This is not a regression, so I don't think we will need a backport. understood. On the downside, another patch I was working on unfortunately partially overlaps with the present one in resolve.c. At some point, there will be a conflict between the work involved in either producing

[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95980 --- Comment #17 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:70c884a4b82733027ac0e2620d09169b177080d7 commit r11-2026-g70c884a4b82733027ac0e2620d09169b177080d7 Author: Harald Anlauf Date:

libgo patch committed: Update to Go 1.14.4 release

This patch updates libgo to the Go 1.14.4 release. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed to trunk and GCC 10 branch. Ian 2b6d99468d4d988fd5f5ea3e9be41a3dc95a1291 diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE index ecef60400cc..64b13f410e0 100644

Re: New x86-64 micro-architecture levels

On Fri, 10 Jul 2020, Florian Weimer via Gcc wrote: > * Level A > > CMPXCHG16B, LAHF/SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3 > > This is one step above the K8 baseline and corresponds to a mainline CPU > model ca. 2008 to 2011. It is also implemented by recent-ish > generations of Intel Atom

Re: Future debug options: -f* or -g*?

On 7/9/20 3:28 PM, Fangrui Song via Gcc wrote: Fix email addresses:) IMHO the -f ones are misnamed. -fFOO -> affect generated code (non-target-specific) or language feature -gFOO -> affect debug info -mFOO -> machine-specific option the -fdump options are misnamed btw, I remember Jeff Law

[Bug fortran/96086] ICE in gfc_match_select_rank, at fortran/match.c:6645

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96086 --- Comment #3 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:8a0b69f0b089c05d233b8e1a941825b1ceac93bd commit r11-2025-g8a0b69f0b089c05d233b8e1a941825b1ceac93bd Author: Harald Anlauf Date:

Re: [PATCH] aarch64: Change costs for TX2 to expose more vectorization opportunities

Anton Youdkevitch writes: > Richard, > > Can you approve the backporting of the patch to GCC10? > Also, since I don't have the commit permission can you push > it if approved? Yeah, that's fine. Now pushed there too. Thanks, Richard

[Bug c++/92789] Non-obvious ?: behaviour with structurally equivalent types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92789 rsandifo at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED

[Bug middle-end/96151] [11 Regression] bootstrap fails due to ICE in c_omp_split_clauses

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96151 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug c++/92789] Non-obvious ?: behaviour with structurally equivalent types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92789 --- Comment #6 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:efe99cca78215e339ba79f0a900a896b4c0a3d36 commit r11-2022-gefe99cca78215e339ba79f0a900a896b4c0a3d36 Author: Richard Sandiford

[Bug middle-end/96151] [11 Regression] bootstrap fails due to ICE in c_omp_split_clauses

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96151 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:510125d2272175f47b26227fbe9b8c8c5abfd988 commit r11-2023-g510125d2272175f47b26227fbe9b8c8c5abfd988 Author: Richard Sandiford

[Bug c++/95726] ICE with aarch64 __Float32x4_t as template argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726 --- Comment #11 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:efe99cca78215e339ba79f0a900a896b4c0a3d36 commit r11-2022-gefe99cca78215e339ba79f0a900a896b4c0a3d36 Author: Richard Sandiford

Re: [PATCH] implement pre-c++20 contracts

Hello again :) Attached is a new squashed revision of the patch sans ChangeLogs. The current work is now being done on github: https://github.com/lock3/gcc/tree/contracts-jac-alt Please let me know if there's a better way to share revisions. >>> + /* Check that assertions are null statements.

[Bug c++/92812] Implement P1975R0: Fixing the wording of parenthesized aggregate-initialization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92812 --- Comment #4 from Marek Polacek --- This already works: // P1975R0 struct Aggr { int x; int y; }; int main () { Aggr a = static_cast(1); if (a.x != 1 || a.y != 0) __builtin_abort (); } but we generate q.C: In function ‘int

Re: [PATCH][RFC] vector creation from two parts of two vectors produces TBL rather than ins (PR93720)

Hi, thank you for reviewing it. Please check updated version(attached) with all comments addressed. Thanks, Dmitrij On Tue, Jun 23, 2020 at 06:10:52PM +0100, Richard Sandiford wrote: ... > > I think it would be better to test this as part of the loop below. > done ... > I think it'd be

Re: [PATCH] Fortran : ICE in gfc_find_array_ref(): No ref found PR95981

Hi Mark, Fortran  :  ICE in gfc_find_array_ref(): No ref found PR95981 OK for master. With regards to backporting, copy & paste my remarks from the previous e-mails :-) Best regards Thomas

New x86-64 micro-architecture levels

Most Linux distributions still compile against the original x86-64 baseline that was based on the AMD K8 (minus the 3DNow! parts, for Intel EM64T compatibility). There has been an attempt to use the existing AT_PLATFORM-based loading mechanism in the glibc dynamic linker to enable a selection of

Re: [PATCH] Fortran : Implicitly type parameter causes an invalid error, PR96038

Am 09.07.20 um 10:00 schrieb Mark Eggleston: Please find attached patch for fix PR.  The original patch was provided by Steve Kargl in the initial problem report. OK to commit to master and backport? OK for master. Same remark as just - not a regression, so if you decide to backport,

Re: [PATCH] Fortran : accepts pointer initialization of DT dummy args, PR45337

Am 09.07.20 um 09:51 schrieb Mark Eggleston: Please find attached a fix for this PR. I think the discussion of intent muddied the waters for this PR. As I understand it initialisation of variables implies the save attribute. The save attribute is incompatible with the dummy attribute so an

RE: [PATCH] arm: Treat GNU and Advanced SIMD vectors as distinct [PR92789, PR95726]

> -Original Message- > From: Richard Sandiford > Sent: 10 July 2020 17:54 > To: gcc-patches@gcc.gnu.org > Cc: ni...@redhat.com; Richard Earnshaw ; > Ramana Radhakrishnan ; Kyrylo > Tkachov > Subject: [PATCH] arm: Treat GNU and Advanced SIMD vectors as distinct > [PR92789, PR95726] > >

Re: [PATCH] PR fortran/96086 - ICE in gfc_match_select_rank, at fortran/match.c:6645

Am 06.07.20 um 22:11 schrieb Harald Anlauf: More NULL pointer dereferences on invalid code, detected by Gerhard. Regtested on x86_64-pc-linux-gnu. OK for master? OK. This is actually a regression (does not occur with gcc-8), so if you feel like it, feel free to backport this. However, if

Re: [PATCH, part 2] PR fortran/95980 - ICE in get_unique_type_string, at fortran/class.c:485

Hi Harald, As Dominique pointed out in the PR, the committed patch (part 1) fixed only one of the provided testcases, but not the original one. That turned out to be a long and winding road, requiring further checks for NULL pointer dereferences. The resulting attached changes have been

[patch, fortran] Fix PR 96018, wrong code caused by implicit_pure

Hello world, the attached patch fixes a 9/10/11 regression where we left over an implicit_pure attribute when a non-implicit_pure procedure was called. The fix is explained in the ChangeLog. If there is a quick review, please also indicate if you think it is still suitable for gcc 10.2. If

[PATCH] arm: Treat GNU and Advanced SIMD vectors as distinct [PR92789, PR95726]

This is an arm version of aarch64 patch r11-1741. The approach is essentially identical, not much more than s/aarch64/arm/. To recap, PR95726 is about template look-up for things like: foo foo The immediate cause of the problem is that the hash function usually returns different hashes

Patch RFA: In C++ demangler don't treat lambda as substitution candidate

As discussed in PR 96143, the C++ frontend and the demangler disagree as to whether a lambda is a substitution candidate. According to the ABI, the C++ frontend is behaving correctly. This patch changes the demangler accordingly. This caused the demangling of several existing test cases to

[Bug middle-end/96151] [11 Regression] bootstrap fails due to ICE in c_omp_split_clauses

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96151 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.0 Summary|bootstrap fails

Re: [PATCH] expr: Move reduce_bit_field target mode check [PR96151]

This fixed the ICE I was seeing, thanks. Aaron Sawdey, Ph.D. saw...@linux.ibm.com IBM Linux on POWER Toolchain > On Jul 10, 2020, at 10:40 AM, Richard Sandiford > wrote: > > In some cases, expand_expr_real_2 prefers to use the mode of the > caller-suggested target instead of the mode of the

[PATCH] ipa-fnsummary: Fix ICE with switch predicates [PR96130]

Hi! The following testcase ICEs since r10-3199. There is a switch with default label, where the controlling expression has range just 0..7 and there are case labels for all those 8 values, but nothing has yet optimized away the default. Since r10-3199, set_switch_stmt_execution_predicate sets the

Re: [PATCH] c++: Fix tentative parsing of enum-specifier [PR96077]

On Fri, Jul 10, 2020 at 05:53:21PM +0200, Jakub Jelinek wrote: > On Fri, Jul 10, 2020 at 11:43:59AM -0400, Marek Polacek via Gcc-patches wrote: > > diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c > > index 528b41b7170..ee6a956aea9 100644 > > --- a/gcc/cp/parser.c > > +++ b/gcc/cp/parser.c > > @@

Re: [PATCH] expr: Move reduce_bit_field target mode check [PR96151]

On Fri, 2020-07-10 at 16:40 +0100, Richard Sandiford wrote: > In some cases, expand_expr_real_2 prefers to use the mode of the > caller-suggested target instead of the mode of the expression when > passing values to reduce_to_bit_field_precision. E.g.: > > else if (target == 0) >

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492 --- Comment #33 from Mike Stump --- Please, unless you expect it to work in an OS independent way, please conditionalize on the systems it is known to work on, meaning, it important for it to work on it, you think all the work for it to work on

Re: [PATCH] c++: Fix tentative parsing of enum-specifier [PR96077]

On Fri, Jul 10, 2020 at 11:43:59AM -0400, Marek Polacek via Gcc-patches wrote: > diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c > index 528b41b7170..ee6a956aea9 100644 > --- a/gcc/cp/parser.c > +++ b/gcc/cp/parser.c > @@ -19412,7 +19412,12 @@ cp_parser_enum_specifier (cp_parser* parser) >

Announce: GNU MPFR 4.1.0 is released

GNU MPFR 4.1.0 ("épinards à la crème"), a C library for multiple-precision floating-point computations with correct rounding, is now available for download from the MPFR web site: https://www.mpfr.org/mpfr-4.1.0/ from InriaForge: https://gforge.inria.fr/projects/mpfr/ and from the GNU FTP

[Bug c++/96077] GCC accepts ill-legal local enum definition

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96077 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #6 from Marek Polacek

[PATCH] c++: Fix tentative parsing of enum-specifier [PR96077]

Here's an interesting issue: in this code a ) is missing: enum { E = (2 } e; but we compile the code anyway, and E is set to 0 in build_enumerator, which is sneaky. The problem is that cp_parser_enum_specifier parses tentatively, because when we see the enum keyword, we don't know yet if

[PATCH] expr: Move reduce_bit_field target mode check [PR96151]

In some cases, expand_expr_real_2 prefers to use the mode of the caller-suggested target instead of the mode of the expression when passing values to reduce_to_bit_field_precision. E.g.: else if (target == 0) op0 = convert_to_mode (mode, op0,

[Bug d/96157] d: No NRVO when returning an array of a non-POD struct

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96157 --- Comment #1 from Iain Buclaw --- If I were to propagate TREE_ADDRESSABLE from S to the static array, then the assert doesn't trigger. However, there lots of breakages that occur elsewhere within the front-end, so a little more extra handling

[Bug target/96125] __attribute__((target("cpu=power10,mma"))) does not set TARGET_MMA

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96125 Peter Bergner changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

[Bug d/96157] New: d: No NRVO when returning an array of a non-POD struct

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96157 Bug ID: 96157 Summary: d: No NRVO when returning an array of a non-POD struct Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug c/96151] bootstrap fails due to ICE in c_omp_split_clauses

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

[Bug d/96156] New: d: No RVO when returning struct literals initialized with constructor.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96156 Bug ID: 96156 Summary: d: No RVO when returning struct literals initialized with constructor. Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal

[Bug c++/96155] "throw" that is not executed in constexpr function fails to compile

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96155 Marek Polacek changed: What|Removed |Added Keywords||rejects-valid Ever confirmed|0

Re: [PATCH] rs6000: Allow MMA built-in initialization regardless of compiler options

On 7/9/20 4:10 PM, Peter Bergner wrote: > I verified the updated test case passes on both LE and BE, so I've > pushed this now. I'll let Bill Seurer's nightly testing try this > on a wider variety of builds before backporting this to GCC10. > I'll try and do that tomorrow. Bill's nightly

[Bug c++/94554] spurious -Waddress warning within "if constexpr" function-null compares

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94554 Klaus Rudolph changed: What|Removed |Added CC||lts-rudolph at gmx dot de --- Comment

[Bug target/96125] __attribute__((target("cpu=power10,mma"))) does not set TARGET_MMA

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96125 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Peter Bergner : https://gcc.gnu.org/g:45b7f80f2e591d4f674d2f0798d31d51a7e46a72 commit r10-8458-g45b7f80f2e591d4f674d2f0798d31d51a7e46a72 Author: Peter Bergner

[Bug c++/96155] New: "throw" that is not executed in constexpr function fails to compile

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96155 Bug ID: 96155 Summary: "throw" that is not executed in constexpr function fails to compile Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal

[Bug c/96151] bootstrap fails due to ICE in c_omp_split_clauses

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96151 --- Comment #1 from acsawdey at gcc dot gnu.org --- This compile is successful like this but fails if I add -mcpu=power9. /home2/sawdey/work/gcc/mamboCI/build-mambo/./prev-gcc/xg++ -B/home2/sawdey/work/gcc/mamboCI/build-mambo/./prev-gcc/

[Bug d/96154] New: d: Add -Wvarargs warning flag to compiler

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96154 Bug ID: 96154 Summary: d: Add -Wvarargs warning flag to compiler Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d

Re: [PATCH] middle-end: Call get_constant_section with DECL not EXP.

On Fri, Jul 10, 2020 at 2:55 AM Richard Biener wrote: > > On Thu, Jul 9, 2020 at 8:29 PM David Edelsohn wrote: > > > > output_constant_def_contents() can call get_constant_section() with an > > EXP that is a CONSTRUCTOR, which is not a declaration. This can hit > > asserts in GCC machinery to

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492 --- Comment #32 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #31 from H.J. Lu --- >> If this is a Linux-only feature, shouldn't the tests rather be >> restricted to Linux instead? It certainly also fails on freebsd, >> darwin,

[Bug d/96153] New: d: struct literals have non-deterministic hash values

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96153 Bug ID: 96153 Summary: d: struct literals have non-deterministic hash values Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug d/96152] New: d: associative array literals don't have alignment holes filled.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96152 Bug ID: 96152 Summary: d: associative array literals don't have alignment holes filled. Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal

Re: testsuite: missed testcase

On 7/10/20 10:28 AM, Christophe Lyon wrote: Hi, On Tue, 7 Jul 2020 at 20:47, Nathan Sidwell wrote: I discovered I'd missed applying a testcase when fixing up the EOF token location a while back. gcc/testsuite/ * c-c++-common/cpp/pragma-eof.c: New The new testcase

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492 --- Comment #31 from H.J. Lu --- (In reply to r...@cebitec.uni-bielefeld.de from comment #30) > > --- Comment #29 from H.J. Lu --- > > (In reply to r...@cebitec.uni-bielefeld.de from comment #28) > >> > --- Comment #27 from H.J. Lu --- > >> >

Re: [PATCH 2/2] openacc: Adjust dynamic reference count semantics

Hi Julian! On 2020-07-09T17:06:59-0700, Julian Brown wrote: > This patch adjusts how dynamic reference counts work so that they match > the semantics of the source program more closely, instead of representing > "excess" reference counts beyond those that represent pointers in the > internal

[Bug c/96151] New: bootstrap fails due to ICE in c_omp_split_clauses

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96151 Bug ID: 96151 Summary: bootstrap fails due to ICE in c_omp_split_clauses Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

Re: testsuite: missed testcase

Hi, On Tue, 7 Jul 2020 at 20:47, Nathan Sidwell wrote: > > I discovered I'd missed applying a testcase when fixing up the EOF token > location a while back. > > gcc/testsuite/ > * c-c++-common/cpp/pragma-eof.c: New > The new testcase fails on targets that do not support

Re: [PATCH 1/2] openacc: Helper functions for enter/exit data using single mapping

Hi Julian! On 2020-07-09T17:06:58-0700, Julian Brown wrote: > This patch factors out the parts of goacc_enter_datum and > goacc_exit_datum that can be shared with goacc_enter_data_internal > and goacc_exit_data_internal respectively (in the next patch), > without overloading function return

[Bug ipa/96130] [10/11 Regression] ICE in analyze_function_body at gcc/ipa-fnsummary.c:2769 since r10-3199-g351e7c3b5fbd45bd

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96130 --- Comment #7 from Jakub Jelinek --- Created attachment 48858 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48858=edit gcc11-pr96130.patch So, my fix would be like this (untested except on the testcase so far).

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492 --- Comment #30 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #29 from H.J. Lu --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #28) >> > --- Comment #27 from H.J. Lu --- >> > (In reply to r...@cebitec.uni-bielefeld.de

[Bug ipa/96130] [10/11 Regression] ICE in analyze_function_body at gcc/ipa-fnsummary.c:2769 since r10-3199-g351e7c3b5fbd45bd

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96130 --- Comment #6 from Jakub Jelinek --- My understanding of the problem is that set_switch_stmt_execution_predicate figures out that the default: is unreachable (operand is a bitfield with values 0 to 7 and there are cases for all 8) and notes

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492 --- Comment #29 from H.J. Lu --- (In reply to r...@cebitec.uni-bielefeld.de from comment #28) > > --- Comment #27 from H.J. Lu --- > > (In reply to r...@cebitec.uni-bielefeld.de from comment #26) > >> > --- Comment #25 from H.J. Lu --- > >> >

  1   2   3   >