Re: Backports to 8.x branch

On Sat, Feb 09, 2019 at 09:52:52AM +0100, Jakub Jelinek wrote: > And two further ones now, bootstrapped/regtested on powerpc64{,le}-linux > and committed. 4 further ones, bootstrapped/regtested on x86_64-linux and i686-linux. Jakub 2019-02-14 Jakub Jelinek Backported from

[Bug middle-end/89303] [7 Regression] memory leak with shared_ptr and enable_shared_from_this

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89303 Jakub Jelinek changed: What|Removed |Added Target Milestone|8.3 |7.5 Summary|[7/8 Regression]

[Bug target/89290] [8 Regression] ICE in change_address_1, at emit-rtl.c:2286

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89290 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug middle-end/89303] [7/8 Regression] memory leak with shared_ptr and enable_shared_from_this

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89303 --- Comment #26 from Jakub Jelinek --- Author: jakub Date: Thu Feb 14 07:41:51 2019 New Revision: 268866 URL: https://gcc.gnu.org/viewcvs?rev=268866=gcc=rev Log: Backported from mainline 2019-02-13 Jakub Jelinek PR

[Bug middle-end/89281] [9 Regression] gcc/optabs.c:3901:30: runtime error: shift exponent 32 is too large for 32-bit type 'int'

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89281 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Thu Feb 14 07:40:33 2019 New Revision: 268865 URL: https://gcc.gnu.org/viewcvs?rev=268865=gcc=rev Log: Backported from mainline 2019-02-13 Jakub Jelinek PR

[Bug middle-end/89246] LTO produces references to cloned symbols which the compiler failed to clone

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89246 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Thu Feb 14 07:38:52 2019 New Revision: 268863 URL: https://gcc.gnu.org/viewcvs?rev=268863=gcc=rev Log: Backported from mainline 2019-02-09 Jakub Jelinek PR

[Bug target/89290] [8 Regression] ICE in change_address_1, at emit-rtl.c:2286

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89290 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Thu Feb 14 07:39:46 2019 New Revision: 268864 URL: https://gcc.gnu.org/viewcvs?rev=268864=gcc=rev Log: Backported from mainline 2019-02-13 Jakub Jelinek PR

[Bug middle-end/89284] gcc -fsanitize=undefined inhibits -Wuninitialized

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89284 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Thu Feb 14 07:31:14 2019 New Revision: 268862 URL: https://gcc.gnu.org/viewcvs?rev=268862=gcc=rev Log: PR middle-end/89284 * passes.def: Swap pass_ubsan and

Re: [PATCH] Swap ubsan and early uninit warning passes (PR middle-end/89284)

On February 14, 2019 12:10:54 AM GMT+01:00, Jakub Jelinek wrote: >Hi! > >The ubsan pass makes early uninit warning harder (and often doesn't >warn), >because e.g. for enum/bool loads we add instrumentation and the reads >from >the fields isn't easily visible to the uninit pass, we have > _7 =

[Bug go/89321] cross build with riscv64 gccgo compilation failed due to assert in constructor_expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89321 --- Comment #6 from Ian Lance Taylor --- Thanks very much for reducing the test case. I sent out the fix for review at https://golang.org/cl/162618. It should be committed shortly.

[Bug other/89347] gc-sections doesn't remove unused bss section variables.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89347 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c

[Bug c/89347] gc-sections doesn't remove unused bss section variables.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89347 Maninder Singh changed: What|Removed |Added CC||maninder1.s at samsung dot com ---

[Bug c/89347] New: gc-sections doesn't remove unused bss section variables.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89347 Bug ID: 89347 Summary: gc-sections doesn't remove unused bss section variables. Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal

[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 89337, which changed state. Bug 89337 Summary: Bogus "exceeds maximum object size" on unreachable code https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89337 What|Removed |Added

[Bug testsuite/86153] [8 regression] test case g++.dg/pr83239.C fails starting with r261585

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86153 Martin Sebor changed: What|Removed |Added CC||rafael at espindo dot la --- Comment #15

[Bug middle-end/89337] Bogus "exceeds maximum object size" on unreachable code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89337 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[PATCH] i386: Properly encode xmm16-xmm31/ymm16-ymm31 for vector move

On Mon, Feb 11, 2019 at 05:24:24PM +0100, Jakub Jelinek wrote: > On Mon, Feb 11, 2019 at 04:56:45PM +0100, Uros Bizjak wrote: > > > Let's first define what MODE_XI means in standard_sse_constant_opcode > > > as well as in all these mov patterns for with and without AVX512VL. > > > Without > > >

V2 [PATCH] driver: Also prune joined switches with negation

On Thu, Feb 14, 2019 at 12:15:53AM +0100, Jakub Jelinek wrote: > On Wed, Feb 13, 2019 at 03:08:01PM -0800, H.J. Lu wrote: > > > How does this test verify that both -fno-builtin-* options are in effect? > > > That is, how does it fail if you remove either or both of those options? > > > > > > >

[Bug target/87532] bad results from vec_extract(unsigned char, foo) dependent upon function inline

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87532 --- Comment #15 from Bill Schmidt --- I kindasorta thought that's what I want. ;-) But now that I understand what you're saying, I believe I agree with you that this is probably a problem in our gimple folding. I am going to shut up now and

[Bug rtl-optimization/89271] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|

[Bug rtl-optimization/89271] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271 --- Comment #3 from Alan Modra --- I believe this is a bug in rs6000_register_move_cost. Testing a fix.

[Bug c++/89244] __builtin_is_constant_evaluated not documented

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89244 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #5 from Martin Sebor

Go patch committed: Compile thunks with -Os

Nikhil Benesch noticed that changes in the GCC backend were making the use of defer functions that call recover less efficient. A defer thunk is a generated function that looks like this (this is the entire function body): if !runtime.setdeferretaddr() { deferredFunction() } L:

[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 89337, which changed state. Bug 89337 Summary: Bogus "exceeds maximum object size" on unreachable code https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89337 What|Removed |Added

[Bug middle-end/89337] Bogus "exceeds maximum object size" on unreachable code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89337 Rafael Avila de Espindola changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED

[Bug middle-end/89337] Bogus "exceeds maximum object size" on unreachable code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89337 Rafael Avila de Espindola changed: What|Removed |Added Attachment #45704|0 |1 is obsolete|

Re: [PR fortran/88248, patch] - [F18] Bogus warning about obsolescent feature: Labeled DO statement

On 2/13/19 2:38 PM, Harald Anlauf wrote: The attached patch moves the check for labeled DO statements to the place where a label is referenced instead of where a label was defined, which lead to false positives. Regtested on x86_64-pc-linux-gnu. OK for trunk? Thanks Harald, All OK with

Re: [-fcompare-debug] var tracking options are not optimization options

> 2019-02-13 Ian Lance Taylor > > * optc-save-gen.awk: Set var_opt_hash for initial optimizations > and set current index for other optimizations. > > 2019-02-13 Ian Lance Taylor > > * gcc.dg/func-attr-1.c: New test. I went ahead and committed this patch. Ian

[Bug go/89321] cross build with riscv64 gccgo compilation failed due to assert in constructor_expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89321 --- Comment #5 from sean.wang at wdc dot com --- Created attachment 45709 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45709=edit code sample for reproducing reported error code sample for reproducing reported error is attached.

[Patch, aarch64] Issue warning/error for mixing functions with/without aarch64_vector_pcs attribute

Szabolcs pointed out that my SIMD ABI patches that implement the aarch64_vector_pcs attribute do not generate a warning or error when being mixed with functions that do not have the attribute because the 'affects_type_identity' field was false in the attribute table. This patch fixes that. I

[PATCH] document __builtin_is_constant_evaluated

The attached patch adds the __builtin_is_constant_evaluated newly introduced in GCC 9 to the Other Builtins section in the manual. I followed the example of __builtin_setjmp and __builtin_longjmp by encouraging the use of std::is_constant_evaluated over making use of the built-in directly.

[Bug fortran/89344] uncaught programmer error: polymorphic variable is INTENT(IN) but assigned to without error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89344 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

Re: PING^1: [PATCH] driver: Also prune joined switches with negation

On Wed, Feb 13, 2019 at 03:08:01PM -0800, H.J. Lu wrote: > > How does this test verify that both -fno-builtin-* options are in effect? > > That is, how does it fail if you remove either or both of those options? > > > > Without -fno-builtin-free -fno-builtin-malloc As you haven't discovered any

[PATCH] Swap ubsan and early uninit warning passes (PR middle-end/89284)

Hi! The ubsan pass makes early uninit warning harder (and often doesn't warn), because e.g. for enum/bool loads we add instrumentation and the reads from the fields isn't easily visible to the uninit pass, we have _7 = _8 = MEM[(_Bool *)_7]; instead etc. As the early uninit warning pass

Re: PING^1: [PATCH] driver: Also prune joined switches with negation

On Wed, Feb 13, 2019 at 2:54 PM Joseph Myers wrote: > > On Wed, 13 Feb 2019, H.J. Lu wrote: > > > Like this? > > This patch is missing any updates to options.texi to discuss the > interation of Negative and RejectNegative with Joined. I will add something. > > diff --git

[PATCH] PR rtl-optimization/88308 Update LABEL_NUSES in move_insn_for_shrink_wrap

I've tracked pr/88308 down to move_insn_for_shrink_wrap(). This function moves an insn from one BB to another by copying it and deleting the old one. Unfortunately this does the LABEL_NUSES count on labels referenced because deleting the old instruction decrements the count and nothing in this

Re: [PATCH 37/40] i386: Allow MMX intrinsic emulation with SSE

On Wed, Feb 13, 2019 at 2:51 PM Uros Bizjak wrote: > > On Wed, Feb 13, 2019 at 9:21 PM H.J. Lu wrote: > > > > On Tue, Feb 12, 2019 at 4:07 AM Uros Bizjak wrote: > > > > > > On Mon, Feb 11, 2019 at 11:55 PM H.J. Lu wrote: > > > > > > > > Allow MMX intrinsic emulation with SSE/SSE2/SSSE3. Don't

[C++ PATCH] Fix cxx_eval_store_expression (PR c++/89336)

Hi! As the following testcases shows, cxx_eval_store_expression mishandles the case when constexpr evaluation of the rhs (init) modifies part of the ctor that the store stores into. Except for unions (see below) I believe it is fine the way the outer refs are handled, because we advance into

Re: PING^1: [PATCH] driver: Also prune joined switches with negation

On Wed, 13 Feb 2019, H.J. Lu wrote: > Like this? This patch is missing any updates to options.texi to discuss the interation of Negative and RejectNegative with Joined. > diff --git a/gcc/testsuite/gcc.dg/pr69471-1.c > b/gcc/testsuite/gcc.dg/pr69471-1.c > new file mode 100644 > index

Re: [PATCH 37/40] i386: Allow MMX intrinsic emulation with SSE

On Wed, Feb 13, 2019 at 9:21 PM H.J. Lu wrote: > > On Tue, Feb 12, 2019 at 4:07 AM Uros Bizjak wrote: > > > > On Mon, Feb 11, 2019 at 11:55 PM H.J. Lu wrote: > > > > > > Allow MMX intrinsic emulation with SSE/SSE2/SSSE3. Don't enable MMX ISA > > > by default with TARGET_MMX_WITH_SSE. > > > > >

Re: [PR fortran/88248, patch] - [F18] Bogus warning about obsolescent feature: Labeled DO statement

Sorry, forgot to attach the patch to the revised testcase f2018_obs.f90. Here it is. Regards, Harald Adjusted ChangeLog: 2019-02-13 Harald Anlauf PR fortran/88248 * gfortran.dg/pr88248.f90: New test. * gfortran.dg/f2018_obs.f90: Updated test. On 02/13/19 23:38,

[Bug rtl-optimization/89271] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271 --- Comment #2 from Segher Boessenkool --- Thanks for the analysis! (In reply to Vladimir Makarov from comment #1) > The very first ira-costs pass runs in sched1 and it generates the following > costs > r125 costs: BASE_REGS:1

F #Trending Recipes

#Trending Recipes   View In The Web  

[Bug fortran/88248] [F18] Bogus warning about obsolescent feature: Labeled DO statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88248 --- Comment #7 from Harald Anlauf --- Patch submitted: https://gcc.gnu.org/ml/fortran/2019-02/msg00112.html

[PR fortran/88248, patch] - [F18] Bogus warning about obsolescent feature: Labeled DO statement

The attached patch moves the check for labeled DO statements to the place where a label is referenced instead of where a label was defined, which lead to false positives. Regtested on x86_64-pc-linux-gnu. OK for trunk? Thanks, Harald 2019-02-13 Harald Anlauf PR fortran/88248

[Bug target/89346] New: Unnecessary EVEX encoding

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89346 Bug ID: 89346 Summary: Unnecessary EVEX encoding Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target

[Bug libstdc++/89345] gcc9 uses constexpr token, can you change to _GLIBCXX_CONSTEXPR ?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89345 --- Comment #4 from mib.bugzilla at gmail dot com --- thank you!

[Bug libstdc++/89345] gcc9 uses constexpr token, can you change to _GLIBCXX_CONSTEXPR ?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89345 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Wed Feb 13 22:13:45 2019 New Revision: 268856 URL: https://gcc.gnu.org/viewcvs?rev=268856=gcc=rev Log: PR libstdc++/89345 Only define std::destroying_delete for C++2a Clang defines the

[PATCH] PR libstdc++/89345 Only define std::destroying_delete for C++2a

Clang defines the __cpp_impl_destroying_delete macro unconditionally, so that the feature is supported whenever the library type is defined. This is incompatible with the current definition in libstdc++ because we use constexpr and inline variables, which will give an error for older -std modes.

[Bug libstdc++/89345] gcc9 uses constexpr token, can you change to _GLIBCXX_CONSTEXPR ?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89345 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug c++/67491] [meta-bug] concepts issues

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 89300, which changed state. Bug 89300 Summary: C++ requires statement does not fail silently for const void * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89300 What|Removed |Added

[Bug c++/78173] Hard error subtracting pointers to incomplete type in SFINAE context

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

[Bug c++/89300] C++ requires statement does not fail silently for const void *

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89300 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug c++/78173] Hard error subtracting pointers to incomplete type in SFINAE context

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78173 Jonathan Wakely changed: What|Removed |Added CC||svenja.mehringer at gmail dot com

[Bug fortran/89344] uncaught programmer error: polymorphic variable is INTENT(IN) but assigned to without error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89344 --- Comment #3 from kargl at gcc dot gnu.org --- Created attachment 45708 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45708=edit Patch that detects and issues an error. Patch that detects and issues an error. Trunk is in stage 4, so

[Bug target/89343] Some MMX instructions aren't properly marked

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89343 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug fortran/89344] uncaught programmer error: polymorphic variable is INTENT(IN) but assigned to without error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89344 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC|

[PATCH, i386]: Fix vec_set and vec_concat patterns

Hello! Attached patch fixes operand predicates of several vec_set patterns and uses correct constraints and attributes for various alternatives. 2019-02-13 Uroš Bizjak * config/i386/sse.md (vec_set_0): Use nonimmediate_operand as operand 2 predicate. (vec_set_0): Ditto.

[Bug libstdc++/89345] gcc9 uses constexpr token, can you change to _GLIBCXX_CONSTEXPR ?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89345 --- Comment #1 from Jonathan Wakely --- I already started fixing this after your update to the phabricator update pinged me an email. I'm just going to make it conditional on __cplusplus > 201703L.

[Bug libstdc++/89345] gcc9 uses constexpr token, can you change to _GLIBCXX_CONSTEXPR ?

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

Re: [PATCH,GDC] Add netbsd support to GDC

On Mon, 11 Feb 2019 at 09:28, wrote: > > On Wed, Jan 23, 2019 at 09:35:03AM +, co...@sdf.org wrote: > > > Is this necessary? I'd prefer to not set this field if it can be > > > avoided. The same goes for the others, I intend to remove them at > > > soonest convenience once the problematic

[PATCH] document __has_attribute and __has_include

The attached patch adds documentation for the __has_attribute (and __has_cpp_attribute) and __has_include operators added in r215752. I was a little unsure where to add this, whether the preprocessor manual or the GCC manual, or both. It seems that it belongs in the preprocessor manual but

[Bug c++/89297] [9 Regression] ICE: unexpected expression 'id' of kind overload

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89297 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug target/89229] Unnecessary ZMM in movoi_internal_avx/movti_internal

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89229 H.J. Lu changed: What|Removed |Added Attachment #45705|0 |1 is obsolete|

Re: PING^1: [PATCH] driver: Also prune joined switches with negation

On Wed, Feb 13, 2019 at 12:02 AM Jakub Jelinek wrote: > > On Wed, Feb 13, 2019 at 08:43:45AM +0100, Jakub Jelinek wrote: > > > It seems right in the march= case to handle that combination as > > > -march=foobar - but it's less clear if that must always be the case for > > > Joined options with

[Bug c++/89297] [9 Regression] ICE: unexpected expression 'id' of kind overload

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89297 --- Comment #3 from Marek Polacek --- Author: mpolacek Date: Wed Feb 13 21:39:18 2019 New Revision: 268854 URL: https://gcc.gnu.org/viewcvs?rev=268854=gcc=rev Log: PR c++/89297 - ICE with OVERLOAD in template. * semantics.c

Re: C++ PATCH for c++/89297 - ICE with OVERLOAD in template

On Wed, Feb 13, 2019 at 4:03 PM Marek Polacek wrote: > On Wed, Feb 13, 2019 at 11:59:05AM -0500, Marek Polacek wrote: > > On Wed, Feb 13, 2019 at 11:44:42AM -0500, Jason Merrill wrote: > > > On 2/13/19 12:13 AM, Marek Polacek wrote: > > > > Here we ICE because we're in a template and the

Re: RFA: PATCH to gimple-fold.c for c++/80916, bogus "static but not defined" warning

Ping^2 On Mon, Feb 4, 2019 at 4:09 PM Jason Merrill wrote: > > Ping > > On Fri, Jan 25, 2019 at 10:06 AM Jason Merrill wrote: > > > > Here we warn because i::dispatch has internal linkage (because l > > does) and is never instantiated (because the vtable is never emitted). > > The regression

[Bug rtl-optimization/89271] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271 --- Comment #1 from Vladimir Makarov --- > This is because IRA does > > r125: preferred NO_REGS, alternative NO_REGS, allocno NO_REGS > >a1(r125,l0) costs: BASE_REGS:14004,14004 GENERAL_REGS:14004,14004- >LINK_REGS:24010,24010

Re: C++ PATCH for c++/89297 - ICE with OVERLOAD in template

On Wed, Feb 13, 2019 at 11:59:05AM -0500, Marek Polacek wrote: > On Wed, Feb 13, 2019 at 11:44:42AM -0500, Jason Merrill wrote: > > On 2/13/19 12:13 AM, Marek Polacek wrote: > > > Here we ICE because we're in a template and the constructor contains an > > > OVERLOAD, so calling check_narrowing ->

[Bug c++/89300] C++ requires statement does not fail silently for const void *

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89300 Casey Carter changed: What|Removed |Added CC||Casey at Carter dot net --- Comment #1

Re: [PATCH 37/40] i386: Allow MMX intrinsic emulation with SSE

On Tue, Feb 12, 2019 at 4:07 AM Uros Bizjak wrote: > > On Mon, Feb 11, 2019 at 11:55 PM H.J. Lu wrote: > > > > Allow MMX intrinsic emulation with SSE/SSE2/SSSE3. Don't enable MMX ISA > > by default with TARGET_MMX_WITH_SSE. > > > > For pr82483-1.c and pr82483-2.c, "-mssse3 -mno-mmx" compiles in

[Bug tree-optimization/89283] [8/9 Regression] ICE: Segmentation fault (in stmt_could_throw_1_p)

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

Re: Provide __start_minfo/__stop_minfo for linkers that don't (PR d/87864)

On Tue, 29 Jan 2019 at 13:24, Rainer Orth wrote: > > Solaris ld only gained support for section bracketing in Solaris 11.4. > Fortunately, in gdc it is only used for the minfo section, so it's easy > to provide a workaround by adding two additional startup files > drt{begin,end}.o which define

Re: [PATCH] Avoid assuming valid_constant_size_p argument is a constant expression (PR 89294)

On 2/12/19 4:43 PM, Rainer Orth wrote: Hi Martin, The attached patch removes the assumption introduced earlier today in my fix for bug 87996 that the valid_constant_size_p argument is a constant expression. I couldn't come up with a C/C++ test case where this isn't true but apparently it can

[Bug c++/89336] internal compiler error when compiling a constexpr function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89336 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned

[Bug c/89341] ICE in get, at cgraph.h:1332

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

[Bug c++/89345] New: gcc9 uses constexpr token, can you change to _GLIBCXX_CONSTEXPR ?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89345 Bug ID: 89345 Summary: gcc9 uses constexpr token, can you change to _GLIBCXX_CONSTEXPR ? Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal

[Bug fortran/89344] uncaught programmer error: polymorphic variable is INTENT(IN) but assigned to without error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89344 urbanjost at comcast dot net changed: What|Removed |Added Keywords||diagnostic

[Bug target/87532] bad results from vec_extract(unsigned char, foo) dependent upon function inline

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87532 --- Comment #14 from kelvin at gcc dot gnu.org --- To reconcile comments 12 and 13, the subtle issue is that we don't even get into the altivec_resolve_overloaded_builtin function for the following code: vec_extract (vi, 10); The gimple

[Bug fortran/89344] New: intent

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89344 Bug ID: 89344 Summary: intent Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at

[Bug middle-end/89337] Bogus "exceeds maximum object size" on unreachable code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89337 --- Comment #3 from Rafael Avila de Espindola --- > GCC can't see that drop3() cannot be called with name.size() < 3, and in > resize, the condition (n > size()) can only be true only when name.size() < > 3 so n - size() is unavoidably too

[Bug c++/86379] [8 Regression] Class member access of |using|'d field goes horribly awry in presence of templates

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86379 Alexandre Oliva changed: What|Removed |Added Known to work||9.0 Summary|[8/9

Re: [PATCH] Fix up and improve allow_blank_lines testsuite handling (PR other/69006, PR testsuite/88920, take 2)

On Wed, 2019-02-13 at 20:08 +0100, Iain Buclaw wrote: > On Wed, 13 Feb 2019 at 14:37, Jakub Jelinek wrote: > > > > On Wed, Feb 13, 2019 at 10:22:14AM +, Andrew Stubbs wrote: > > > On 13/02/2019 09:09, Jakub Jelinek wrote: > > > > To make it work together with doing llvm_binutils only once, >

[Bug middle-end/89337] Bogus "exceeds maximum object size" on unreachable code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89337 Martin Sebor changed: What|Removed |Added Keywords||diagnostic

[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 89337, which changed state. Bug 89337 Summary: Bogus "exceeds maximum object size" on unreachable code https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89337 What|Removed |Added

[Bug c++/86379] [8/9 Regression] Class member access of |using|'d field goes horribly awry in presence of templates

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86379 --- Comment #5 from Alexandre Oliva --- Author: aoliva Date: Wed Feb 13 19:08:52 2019 New Revision: 268851 URL: https://gcc.gnu.org/viewcvs?rev=268851=gcc=rev Log: [PR86379] do not use TREE_TYPE for USING_DECL_SCOPE It's too risky to reuse the

Re: [PATCH] Fix up and improve allow_blank_lines testsuite handling (PR other/69006, PR testsuite/88920, take 2)

On Wed, 13 Feb 2019 at 14:37, Jakub Jelinek wrote: > > On Wed, Feb 13, 2019 at 10:22:14AM +, Andrew Stubbs wrote: > > On 13/02/2019 09:09, Jakub Jelinek wrote: > > > To make it work together with doing llvm_binutils only once, the global > > > now > > > has multiple values > > > 0 - disallow

Re: [PATCH 36/40] i386: Allow MMX vector expanders with TARGET_MMX_WITH_SSE

On Tue, Feb 12, 2019 at 12:29 PM Uros Bizjak wrote: > > On 2/12/19, H.J. Lu wrote: > > >> This way, it is clear that we enable alternative 0 only for native > >> mmx. It looks to me that we need to add similar treatment to a couple > >> of other patterns in sse.md, where we allow "y" constraint,

[Bug target/89343] New: Some MMX instructions aren't properly marked

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89343 Bug ID: 89343 Summary: Some MMX instructions aren't properly marked Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

Re: [PATCH] Fix up norm2 simplification (PR middle-end/88074)

On Wed, Feb 13, 2019 at 10:51:07AM -0800, Steve Kargl wrote: > To get Richard's emin/emax patch into the tree so adequate > testing can be done prior to the 9.1 release, I'll suggest > that we XFAIL norm2_3.f90 while we work out the details for > norm2. > > Yesteraday, I looked at Jakub's patch,

Re: [PATCH] Fix up norm2 simplification (PR middle-end/88074)

On Wed, Feb 13, 2019 at 07:30:53PM +0100, Jakub Jelinek wrote: > On Wed, Feb 13, 2019 at 07:17:53PM +0100, Thomas Koenig wrote: > > > Bootstrapped/regtested on x86_64-linux and i686-linux (together with > > > Richard's patch), ok for trunk? > > > > A couple of points: > > > > with this patch, we

[Bug target/88308] ICE in maybe_record_trace_start, at dwarf2cfi.c:2309

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88308 --- Comment #5 from acsawdey at gcc dot gnu.org --- After some more digging, it appears that the problem is move_insn_for_shrink_wrap() is deleting and re-creating insns to move them from one BB to another. The label reference count gets

Re: [C++PATCH] [PR86379] do not use TREE_TYPE for USING_DECL_SCOPE

On 2/13/19 12:36 PM, Alexandre Oliva wrote: On Feb 8, 2019, Jason Merrill wrote: On 2/8/19 4:07 AM, Alexandre Oliva wrote: On Feb 7, 2019, Jason Merrill wrote: In protected_accessible_p and shared_member_p, if we're left with a USING_DECL after strip_using_decl, we can't give a

Re: [PATCH] Fix up norm2 simplification (PR middle-end/88074)

On Wed, Feb 13, 2019 at 07:17:53PM +0100, Thomas Koenig wrote: > > Bootstrapped/regtested on x86_64-linux and i686-linux (together with > > Richard's patch), ok for trunk? > > A couple of points: > > with this patch, we will have an algorithm that will evaluate NORM2 > in a different way than

[Bug c++/87322] [8 Regression] GCC fails to parse captured lambda of 2nd inner lambda if the captured lambda has "," (having 2 arguments)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87322 Alexandre Oliva changed: What|Removed |Added Known to work||9.0 Summary|[8/9

[Bug c/89342] New: ICE in maybe_default_option, at opts.c:347

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89342 Bug ID: 89342 Summary: ICE in maybe_default_option, at opts.c:347 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug go/89321] cross build with riscv64 gccgo compilation failed due to assert in constructor_expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89321 --- Comment #4 from sean.wang at wdc dot com --- The assert it reached was this I think: gcc_assert(field == NULL_TREE); Thanks, Ian. It is helpful. I think I found a way to reproduce this issue on a smaller set of code. Will provide an example

[Bug inline-asm/89334] unsupported size for integer register

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89334 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org ---

Re: [PATCH] Fix up norm2 simplification (PR middle-end/88074)

Hi Jakub, Bootstrapped/regtested on x86_64-linux and i686-linux (together with Richard's patch), ok for trunk? A couple of points: with this patch, we will have an algorithm that will evaluate NORM2 in a different way than before, possibly leading to regressions in some cases where we

  1   2   3   >