Re: AW: AW: AW: Problem using gcov

On 02/26/2018 03:41 PM, Alexander Fichtinger wrote: > Ok, thanks for the info. > > I just saw the description in the bug-report. > When we document this for our customers, it's ok, I think. Thanks for understanding. I would just note that there's couple of similar issues you probably want to

AW: AW: AW: AW: Problem using gcov

Ok, thanks for the information. Do we get all coverage-related problems when we monitor the Bugs with the Component "gcov-profile"? Or are there other components concerning coverage? We are using gcov in our Testframework (used for Automotive software) in order to determine the Code-Coverage,

Re: GCC interpretation of C11 atomics (DR 459)

On Tue, 2018-02-27 at 16:40 +, Simon Wright wrote: > On 27 Feb 2018, at 12:56, Ruslan Nikolaev via gcc wrote: > > > > And all this mess to accommodate almost non-existent case when someone > > wants to use atomic_load on read-only memory for wide types, in which no > >

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On Tue, 2018-02-27 at 13:16 +, Ruslan Nikolaev via gcc wrote: > > 3) Torvald pointed out further considerations such as users expecting > > lock-free atomic loads to be faster than stores. > > Is it even true? Is it faster to use some global lock (implemented through > RMW) than a single

Re: GCC interpretation of C11 atomics (DR 459)

On 27 Feb 2018, at 12:56, Ruslan Nikolaev via gcc wrote: > > And all this mess to accommodate almost non-existent case when someone wants > to use atomic_load on read-only memory for wide types, in which no good > solution exists anyway Sorry to butt in, but - if it's ROM why

Re: Fw: GCC interpretation of C11 atomics (DR 459)

Torvald, thank you for your output, but I think, this discussion gets a little pointless. There is nothing else I can add since gcc folks are reluctant to this change anyway. In my opinion, there is no compelling reason against such an implementation (it is perfectly fine with the standard,

Re: GCC interpretation of C11 atomics (DR 459)

> Consider a producer-consumer relationship between two processes where > the producer doesn't want to wait for the consumer.  For example, the > producer could be an application that's being traced, and the consumer > is a trace aggregation tool.  The producer can provide a read-only > mapping

Re: GCC interpretation of C11 atomics (DR 459)

On Tue, 2018-02-27 at 17:29 +, Ruslan Nikolaev wrote: > > > > Consider a producer-consumer relationship between two processes where > > the producer doesn't want to wait for the consumer. For example, the > > producer could be an application that's being traced, and the consumer > > is a

Re: GCC interpretation of C11 atomics (DR 459)

On 02/27/2018 05:40 PM, Simon Wright wrote: Sorry to butt in, but - if it's ROM why would you need atomic load anyway? (of course, if it's just a constant view of the object, reason is obvious) On many systems, the read-only nature of a memory region is a thread-local or process-local

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On Tue, 2018-02-27 at 13:04 +, Szabolcs Nagy wrote: > the solutions is to add a language extension I think this only needs a library interface, at least when we're just considering the __atomic builtins. On the C/C++ level, it might amount to just another atomic type, which only has a CAS

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On Tue, 2018-02-27 at 12:56 +, Ruslan Nikolaev via gcc wrote: > But, of course, it is kind of annoying that double-width types (and that also > includes potentially 64-bit on some 32-bit processors, e.g. i586 also has > cmpxchg8b and no official way to read atomically otherwise) need special

Re: GCC interpretation of C11 atomics (DR 459)

On 27 Feb 2018, at 17:07, Torvald Riegel wrote: > > On Tue, 2018-02-27 at 16:40 +, Simon Wright wrote: >> On 27 Feb 2018, at 12:56, Ruslan Nikolaev via gcc wrote: >>> >>> And all this mess to accommodate almost non-existent case when someone >>> wants

Autodesk Users List.

Hi, I would like to know if you are interested in acquiring Network Software Users List. Information fields we provide for each contact in the list: MYVRMS, Volanté Systems, TravelNet Solutions, Givex, InnQuest Software, TurfCare Supply Corp, Software Developers Inc, and Software

Re: GCC interpretation of C11 atomics (DR 459)

> But we're not talking about that special case of 128b types here.  The > majority of synchronization doesn't need more than machine word size. Then why do you worry about read-only access for 128b types? (it is a special case anyway). > No, such a program would have a bug anyway.  It

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On Mon, 2018-02-26 at 19:39 +, Ruslan Nikolaev via gcc wrote: > Torvald, I definitely do not want to insist on this design choice, but it > makes sense to at least seriuously consider it given the concerns I > described. And especially because IFFUNC in libatomic already redirects to >

Run (some?) ELF constructors after applying RELRO protection

I think it would be a nice addition to the toolchain if it were possible to programatically initialize data in the RELRO section. We do this in glibc, but I don't think this is currently supported for general use. One important application is to allocate a memory region with mmap, on which

Re: GCC interpretation of C11 atomics (DR 459)

On 02/26/2018 07:36 PM, Janne Blomqvist wrote: There is no such architectural guarantee. At least on some micro-architecture (AMD Opteron "Istanbul") it's possible to construct a test which fails, proving that at least on that micro-arch SSE2 load/store isn't guaranteed to be atomic. Looks

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On Mon, Feb 26, 2018 at 10:45 PM, Ruslan Nikolaev via gcc wrote: > Thanks, everyone, for the output, it is very useful. I am just proposing to > consider the change unless there are clear roadblocks. (Either design choice > is probably OK with respect to the standard formally

Re: AW: AW: AW: AW: Problem using gcov

On 02/27/2018 09:13 AM, Alexander Fichtinger wrote: > Ok, thanks for the information. > > Do we get all coverage-related problems when we monitor the Bugs with the > Component "gcov-profile"? > Or are there other components concerning coverage? Yes, I mark all gcov bugs with this component. >

AW: AW: AW: AW: AW: Problem using gcov

Ok, thank you. Alexander -Ursprüngliche Nachricht- Von: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] Im Auftrag von Martin Liška Gesendet: Dienstag, 27. Februar 2018 13:39 An: Alexander Fichtinger ; gcc@gcc.gnu.org Betreff: Re: AW: AW: AW: AW:

Both GCC and GDB buildbot use gcc114

Hi Paulo, I noticed that GDB buildbot pending build queue on aarch64-linux becomes longer and longer, https://gdb-build.sergiodj.net/builders/Ubuntu-AArch64-m64 as it takes longer to finish each build and test. Looks that you deployed aarch64-linux buildslave for GCC buildbot on gcc114 as well,

Re: Fw: GCC interpretation of C11 atomics (DR 459)

Formally speaking, either implementation satisfies C11 because the standard allows much leeway in the interpretation here. But, of course, it is kind of annoying that double-width types (and that also includes potentially 64-bit on some 32-bit processors, e.g. i586 also has cmpxchg8b and no

Re: GSoC

On Mon, Feb 26, 2018 at 5:35 PM, Dushyant Pratap Singh wrote: > Hello GCC community, > My name is Dushyant and I am interested in Gsoc at GCC .I am pursuing > Integrated B.Tech (Computer Science) and M.Tech (software engineering) from > Gautam Buddha University, India.

Re: determining aggregate member from MEM_REF

On Mon, Feb 26, 2018 at 9:04 PM, Jeff Law wrote: > On 02/26/2018 08:44 AM, Martin Sebor wrote: >> >> Folding things to MEM_REF (or rather, folding them too early) >> makes all kinds of analysis harder: not just warnings but even >> optimization. I've raised a whole slew of bugs

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On 27/02/18 12:56, Ruslan Nikolaev wrote: Formally speaking, either implementation satisfies C11 because the standard allows much leeway in the interpretation here. no, 1) your proposal would make gcc non-conforming to iso c unless it changes how static const objects are emitted. 2) the two

Re: Fw: GCC interpretation of C11 atomics (DR 459)

> 1) your proposal would make gcc non-conforming to iso c unless it changes how > static const objects are emitted. I do not think, ISO C requires to put const objects to .rodata. And it is easily solved by not placing it there for _Atomic objects that cannot be safely loaded from read-only

Re: GSOC 2018 - Textual LTO dump tool project

On Sun, Feb 25, 2018 at 10:46 AM, Martin Jambor wrote: > Hello Hrishikesh, > > I apologize for replying to you this late, this has been a busy week > and now I am traveling. > > On Mon, Feb 19 2018, Hrishikesh Kulkarni wrote: >> Hi, >> >> I am Hrishikesh Kulkarni currently

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On Tue, 2018-02-27 at 10:22 +, Ramana Radhakrishnan wrote: > The way to fix this in AArch64 if there is a > guarantee from the standard that there are no problems with read-only > locations is to implement the change in libatomic. Even though the standard doesn't specify read-only memory, I

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On Mon, 2018-02-26 at 22:45 +, Ruslan Nikolaev via gcc wrote: > Thanks, everyone, for the output, it is very useful. I am just proposing to > consider the change unless there are clear roadblocks. (Either design choice > is probably OK with respect to the standard formally speaking, but

Re: Both GCC and GDB buildbot use gcc114

On 27/02/18 13:53, Yao Qi wrote: > Hi Paulo, > I noticed that GDB buildbot pending build queue on aarch64-linux > becomes longer and longer, > https://gdb-build.sergiodj.net/builders/Ubuntu-AArch64-m64 > as it takes longer to finish each build and test. > > Looks that you deployed aarch64-linux

Re: finding bugs deferred from previous releases

On Feb 8, 2018, Richard Biener wrote: > Add a 'defered' keyword? Done: deferred: This bug was deemed too risky to attempt to fix during stabilization stages. Deferred to a development stage of a subsequent release. -- Alexandre Oliva, freedom fighter

Re: GCC interpretation of C11 atomics (DR 459)

Torvald, I think this discussion, indeed, gets pointless. Some of your responses clearly take my comments out of larger picture and context of the discussion. One thing is clear that either implementation is fine with the standard (formally speaking) simply because the standard allows too much

Re: Create a new mirror

Hello Gerald, We added missing cronjob to update it. It should be updated in less than 6 hours. Regards Martin Hi Martin, On Mon, 6 Nov 2017, KoDDoS Mirror wrote: The mirror is setup. Here is a patch as I do not have write access to push it. I was just going to commit the following patch

Re: GCC interpretation of C11 atomics (DR 459)

On Tue, 2018-02-27 at 19:32 +, Ruslan Nikolaev wrote: > > > But we're not talking about that special case of 128b types here. The > > majority of synchronization doesn't need more than machine word size. > Then why do you worry about read-only access for 128b types? (it is a special > case

Re: [PATCH] [Microblaze]: PIC Data Text Relative

Thanks Micheal for your response. I shall re-submit patches separately after re-running the whole GCC Test suite and re-checking code conventions. For sending to gdb-patches, it was a conflict from my side as actually I thought it is also for binutils. On Tue, Feb 27, 2018 at 2:07 AM, Michael

[Bug c++/84582] [8 Regression] Rejected valid C++ code since r257961

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84582 Martin Liška changed: What|Removed |Added Known to work||7.3.0 Target Milestone|---

[Bug c++/84582] New: [8 Regression] Rejected valid C++ code since r257961

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84582 Bug ID: 84582 Summary: [8 Regression] Rejected valid C++ code since r257961 Product: gcc Version: unknown Status: UNCONFIRMED Keywords: rejects-valid Severity: normal

Re: [v3 PATCH] Implement the missing bits of LWG 2769

On 26 February 2018 at 22:52, Jonathan Wakely wrote: > On 25/02/18 23:22 +0200, Ville Voutilainen wrote: >> >> Tested partially on Linux-x64, will test with the full suite on >> Linux-PPC64. >> Ok for trunk and the gcc-7 branch? This is theoretically a breaking change > This

[Bug tree-optimization/84468] [8 Regression] bogus -Wstringop-truncation despite assignment after conditional strncpy

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84468 --- Comment #15 from Romain Geissler --- Hi, This latest patch seems to fix the occurences I have in my own code. Thanks ;) Cheers, Romain

[PATCH] Fix debug for -mcall-ms2sysv-xlogues stubs fallout (PR target/83917)

On Mon, Feb 26, 2018 at 08:05:56PM -0600, Daniel Santos wrote: > >>> --- libgcc/config/i386/cygwin.S.jj2018-01-03 10:42:56.309763515 > >>> +0100 > >>> +++ libgcc/config/i386/cygwin.S 2018-02-22 15:30:34.597925496 +0100 > >>> @@ -23,31 +23,13 @@ > >>> * .

[Bug tree-optimization/84562] -faggressive-loop-optimizations makes decisions based on weak data structures

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84562 --- Comment #4 from rguenther at suse dot de --- On Tue, 27 Feb 2018, jnordholz at sect dot tu-berlin.de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84562 > > Jan Nordholz changed: > >What|Removed

[Bug target/84528] [8 Regression] gcc.c-torture/execute/960419-2.c -O3 fails with -fno-omit-frame-pointer

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

[Bug target/84528] [8 Regression] gcc.c-torture/execute/960419-2.c -O3 fails with -fno-omit-frame-pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84528 --- Comment #5 from rsandifo at gcc dot gnu.org --- Created attachment 43519 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43519=edit Alternative fix Here's an alternative fix that I'll run through multi-target testing. It's more

[Bug c++/84599] New: following code gives different output for normal compilation and -O2 compiler.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84599 Bug ID: 84599 Summary: following code gives different output for normal compilation and -O2 compiler. Product: gcc Version: 4.8.4 Status: UNCONFIRMED Severity:

[Bug c++/84496] [6/7 Regression] Internal compiler error with lambda, static and auto since r236615

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84496 --- Comment #3 from Jason Merrill --- Author: jason Date: Tue Feb 27 15:31:29 2018 New Revision: 258037 URL: https://gcc.gnu.org/viewcvs?rev=258037=gcc=rev Log: PR c++/84496 - ICE with generic lambda in lambda. * pt.c

[Bug fortran/51434] ICE with scalar init of an array parameter, used in DT default init with transfer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51434 --- Comment #19 from Steve Kargl --- On Tue, Feb 27, 2018 at 01:54:11PM +, dominiq at lps dot ens.fr wrote: > > In addition, I don't understand why > > type t > character :: z > end type t > type(t), parameter :: s(5) = t('a') >

[arm-embedded] Allow -mcpu=cortex-m33+nodsp

Hi, we decided to apply the following patch to ARM/embedded-7-branch to support -mcpu=cortex-m33+nodsp. DSP instructions are optional for Arm Cortex-M33, yet its -mcpu option does not allow +nodsp. Users are thus left with using -march=armv8-m.main -mtune=cortex-m33. This patch creates a new cpu

[Bug c++/84582] [8 Regression] Rejected valid C++ code since r257961

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84582 --- Comment #6 from Marek Polacek --- (In reply to Jason Merrill from comment #5) > (In reply to Jakub Jelinek from comment #2) > > Given: > > class C { > > static const long b = 0; > > static const unsigned c = (b); > > }; > > class D { > >

RE: [PATCH] RL78 one_cmplhi2 improvement

HI DJ, > One thing to try is to use (subreg:QI in a define_expand, so that > there's a one_cmplhi2 pattern that expands to two QImode insns that > operate on HImode input/outputs via SUBREGs. Thank you for the suggestion! After several attempts the following is the only successful one, however

[Bug target/84534] [8 regression] several powerpc test cases fail starting with r257915

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84534 Peter Bergner changed: What|Removed |Added CC||bergner at gcc dot gnu.org --- Comment

[Bug tree-optimization/84485] [6/7 Regression] Vectorising zero-stride rmw operation

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

[PATCH] Fix gcc.target/i386/pr84309.c testcase (PR target/84575)

[Bug testsuite/84597] New: [8 regression] test case g++.dg/ext/timevar2.C fails starting with r258029

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84597 Bug ID: 84597 Summary: [8 regression] test case g++.dg/ext/timevar2.C fails starting with r258029 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity:

[Bug c++/84598] New: internal compiler error: Segmentation fault (cp_default_conversion())

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84598 Bug ID: 84598 Summary: internal compiler error: Segmentation fault (cp_default_conversion()) Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal

[Bug c++/84599] following code gives different output for normal compilation and -O2 compiler.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84599 --- Comment #1 from Marc Glisse --- Did you try -fsanitize=undefined before reporting?

[Bug c++/84599] following code gives different output for normal compilation and -O2 compiler.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84599 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|

[Bug target/52991] [6/7/8 Regression] attribute packed broken on mingw32?

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

[Bug c++/84588] internal compiler error: Segmentation fault (contains_struct_check())

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84588 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug tree-optimization/84595] __builtin_trap() causes optimizer to remove code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84595 --- Comment #2 from Andrew Pinski --- https://github.com/scottt/debugbreak

[Bug c/84600] New: function inlining is confused by char * type cast

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84600 Bug ID: 84600 Summary: function inlining is confused by char * type cast Product: gcc Version: 6.3.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug testsuite/83983] FAIL: g++.dg/lto/pr83121 (test for LTO warnings, pr83121_0.C line 8)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83983 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org ---

[Bug target/52991] [6/7/8 Regression] attribute packed broken on mingw32?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991 --- Comment #29 from Jakub Jelinek --- Created attachment 43522 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43522=edit gcc8-pr52991.patch Full untested patch (except for make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}

[Bug c++/84596] New: internal compiler error: unexpected expression '(bool)c' of kind implicit_conv_expr (cxx_eval_constant_expression)

om git fdae6180ad24fa6303fa046114f3e4b66b8db34d Version 7.3.0 don't seem to be affected AFAICS. gcc trunk on godbolt.org (8.0.1 20180227) gives: : In function 'void b(int)': :3:23: error: non-constant condition for static assertion static_assert(c); ^ :3:23: internal compiler

[Bug target/84528] [8 Regression] gcc.c-torture/execute/960419-2.c -O3 fails with -fno-omit-frame-pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84528 --- Comment #6 from rsandifo at gcc dot gnu.org --- (In reply to rsand...@gcc.gnu.org from comment #5) > Created attachment 43519 [details] > Alternative fix > > Here's an alternative fix that I'll run through multi-target testing. > It's more

Re: [PATCH] PR preprocessor/84517 allow double-underscore macros after string literals

On 27 February 2018 at 16:59, Jonathan Wakely wrote: > On 27 February 2018 at 16:49, Tim Song wrote: >> On Tue, Feb 27, 2018 at 9:41 AM, Jonathan Wakely >> wrote: >>> Since the fix for PR c++/80955 any suffix on a string

[Bug c++/84596] [8 Regression] internal compiler error: unexpected expression '(bool)c' of kind implicit_conv_expr (cxx_eval_constant_expression)

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

[Bug tree-optimization/84595] __builtin_trap() causes optimizer to remove code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84595 --- Comment #4 from Andrew Pinski --- (In reply to Daniel Gutson from comment #3) > OK. That was my second suggested alternative. > BTW I didn't see __builtin_trap documented as noreturn in the documentation. Depends on the reading of

Re: [PATCH] PR preprocessor/84517 allow double-underscore macros after string literals

On Tue, Feb 27, 2018 at 9:41 AM, Jonathan Wakely wrote: > Since the fix for PR c++/80955 any suffix on a string literal that > begins with an underscore is assumed to be a user-defined literal > suffix, not a macro. This assumption is invalid for a suffix beginning > with

Re: [PATCH] Fix gcc.target/i386/pr84309.c testcase (PR target/84575)

On Tue, Feb 27, 2018 at 1:01 AM, Jakub Jelinek wrote: > NOPATCH. -- H.J.

[Bug target/84534] [8 regression] several powerpc test cases fail starting with r257915

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84534 --- Comment #2 from seurer at gcc dot gnu.org --- xxlor counting failures are really common for powerpc test cases. Perhaps we should look at all the ones that do that to see if those xxlor count checks are actually testing for anything useful?

C++ PATCH for c++/84489, dependent default template argument

The logic in type_unification_real for handling template parms that depend on earlier template parms is a bit complicated. It already recognizes when the type of the parm depends on something not available yet, and it dealt with the case where substituting partial args left some template parm

[Bug c++/84489] [6/7/8 Regression] Non-type template parameter dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84489 --- Comment #2 from Jason Merrill --- Author: jason Date: Tue Feb 27 17:26:47 2018 New Revision: 258039 URL: https://gcc.gnu.org/viewcvs?rev=258039=gcc=rev Log: PR c++/84489 - dependent default template argument * pt.c

[Bug target/84534] [8 regression] several powerpc test cases fail starting with r257915

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84534 --- Comment #3 from Vladimir Makarov --- Actually, it is not a failure. I believe it is an improvement. We have less move insns now. The easiest way to fix is to change the expected move insns to the current number. I'd prefer changing the

[Bug target/84482] 437.leslie3d regresses on Haswell and SandyBridge at -O3 and -Ofast with generic march and tuning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84482 --- Comment #6 from Richard Biener --- So we vectorize less. Given the caused revision I wonder if this is the same issue as in PR84512 where I just committed a fix for? So ... fixed?

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 84512, which changed state. Bug 84512 Summary: [8 Regression] Missed optimization: should be precalculated in compile-time https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84512 What|Removed

[Bug tree-optimization/84512] [8 Regression] Missed optimization: should be precalculated in compile-time

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84512 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug tree-optimization/84595] __builtin_trap() causes optimizer to remove code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84595 --- Comment #1 from Andrew Pinski --- What you want is __builtin_breakpoint (if that existed). Trap is considered as noreturn just like abort/exit.

[PATCH] Fix PR c++/71546 - lambda capture fails with "was not declared in this scope"

Hi GCC developers, I have attached a proposed patch for fixing PR c++/71546 - lambda capture fails with "was not declared in this scope". The patch clears the parser scope after each lambda capture in cp_parser_lambda_introducer in parser.c. This is based on the following observations: Comment

[Bug c++/84588] internal compiler error: Segmentation fault (contains_struct_check())

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84588 --- Comment #2 from David Malcolm --- Both testcases used to ICE with -std=c++11, but that was fixed sometime between r218865 (ICE) and r218948 (no ICE). Both testcases ICE on trunk with -std=c++14, in both cases starting with r208426.

Re: [PATCH] PR preprocessor/84517 allow double-underscore macros after string literals

On 27 February 2018 at 16:49, Tim Song wrote: > On Tue, Feb 27, 2018 at 9:41 AM, Jonathan Wakely > wrote: >> Since the fix for PR c++/80955 any suffix on a string literal that >> begins with an underscore is assumed to be a user-defined literal >>

[Bug c++/84578] [6/7/8 Regression] ICE with flexible array member and constexpr

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84578 Martin Sebor changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code --- Comment #2 from

[Bug c++/84582] [8 Regression] Rejected valid C++ code since r257961

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84582 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #5

[Bug libstdc++/84601] New: std::optional<std::pair<int, int>> is not assignment copyable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84601 Bug ID: 84601 Summary: std::optional> is not assignment copyable Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal

Re: [PATCH] Fix PR c++/71546 - lambda capture fails with "was not declared in this scope"

Hi, I only have a simple comment about the testcase: On 27/02/2018 17:42, Håkon Sandsmark wrote: +++ gcc/testsuite/g++.dg/cpp1y/pr71546.C @@ -0,0 +1,11 @@ +// PR c++/71546 +// { dg-do compile { target c++14 } } +// { dg-options "" } + +#include + +int main() +{ + int x1; + [e =

Re: [C++] [PR84231] overload on cond_expr in template

On Feb 15, 2018, Jason Merrill wrote: > On Thu, Feb 8, 2018 at 9:09 PM, Alexandre Oliva wrote: >> + /* If it was supposed to be an rvalue but it's not, adjust >> +one of the operands so that any overload resolution >> +taking

[Bug c++/84496] [6 Regression] Internal compiler error with lambda, static and auto since r236615

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84496 Jason Merrill changed: What|Removed |Added Depends on||81045 Summary|[6/7

[Bug tree-optimization/84595] __builtin_trap() causes optimizer to remove code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84595 --- Comment #3 from Daniel Gutson --- (In reply to Andrew Pinski from comment #1) > What you want is __builtin_breakpoint (if that existed). Trap is considered > as noreturn just like abort/exit. OK. That was my second suggested alternative.

[Bug tree-optimization/84595] __builtin_trap() causes optimizer to remove code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84595 --- Comment #5 from Daniel Gutson --- (In reply to Andrew Pinski from comment #4) > (In reply to Daniel Gutson from comment #3) > > OK. That was my second suggested alternative. > > BTW I didn't see __builtin_trap documented as noreturn in the

[Bug target/52991] [6/7/8 Regression] attribute packed broken on mingw32?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991 --- Comment #28 from Jakub Jelinek --- Trying: --- gcc/stor-layout.c.jj2018-02-22 14:35:33.135216198 +0100 +++ gcc/stor-layout.c 2018-02-27 17:32:17.934820133 +0100 @@ -1038,7 +1038,7 @@ update_alignment_for_field (record_layou

[Bug tree-optimization/84512] [8 Regression] Missed optimization: should be precalculated in compile-time

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84512 --- Comment #2 from Richard Biener --- Author: rguenth Date: Tue Feb 27 15:25:33 2018 New Revision: 258036 URL: https://gcc.gnu.org/viewcvs?rev=258036=gcc=rev Log: 2018-02-27 Richard Biener PR

[Bug tree-optimization/84595] New: __builtin_trap() causes optimizer to remove code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84595 Bug ID: 84595 Summary: __builtin_trap() causes optimizer to remove code Product: gcc Version: 7.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug c++/84596] [8 Regression] internal compiler error: unexpected expression '(bool)c' of kind implicit_conv_expr (cxx_eval_constant_expression)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84596 Marek Polacek changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #2 from

Re: [PATCH] RL78 one_cmplhi2 improvement

"Sebastian Perta" writes: > Is this similar to what you had in mind? Yes. Did it affect code size in any of the larger tests? I was hoping that it wouldn't force too much into 8-bit registers and cause more moves to be needed elsewhere. (and even if it didn't, I

[Bug tree-optimization/84470] test for address of member being null not eliminated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84470 --- Comment #4 from Martin Sebor --- When p is null p->a is not valid if it's evaluated. offsetof (along with sizeof and alignof and the like) don't evaluate their operands so they are exempt.

[Bug c/84563] GCC interpretation of C11 atomics (DR 459)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84563 torvald at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

[Bug c++/84582] [8 Regression] Rejected valid C++ code since r257961

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84582 --- Comment #7 from Jason Merrill --- (In reply to Marek Polacek from comment #6) > So do you think that we don't want the patch in Comment 3? Correct, that patch is wrong.

[Bug c++/84598] internal compiler error: Segmentation fault (cp_default_conversion())

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84598 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

Re: [C++] [PR84231] overload on cond_expr in template

On Tue, Feb 27, 2018 at 1:05 PM, Alexandre Oliva wrote: > On Feb 15, 2018, Jason Merrill wrote: > >> On Thu, Feb 8, 2018 at 9:09 PM, Alexandre Oliva wrote: >>> + /* If it was supposed to be an rvalue but it's not, adjust >>> +

[Bug libstdc++/84601] [8 Regression] std::optional<std::pair<int, int>> is not assignment copyable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84601 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug c++/84426] [8 Regression] ICE with conflicting class member names

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84426 --- Comment #2 from Nathan Sidwell --- Author: nathan Date: Tue Feb 27 20:52:15 2018 New Revision: 258042 URL: https://gcc.gnu.org/viewcvs?rev=258042=gcc=rev Log: [PR c++/84426] ICE after conflicting member decl

  1   2   3   4   >