[Bug middle-end/88784] Middle end is missing some optimizations about unsigned

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88784 --- Comment #11 from Qi Feng --- I tried 2 patterns for the following test /* 1. x > y && x != 0 --> x > y */ /* 2. y < x && x != 0 --> y < x */ /* 3. x != 0 && x > y --> x > y */ /* 4. x != 0 && y

Add GCC support to ENQCMD.

Hi Uros and all: This patch is about to enable support for ENQCMD(Enqueue Command) which will be in Willow Cove. There are two instructions for ENQCMD: ENQCMD and ENQCMDS. More details please refer to

[PATCH] PR c/86407 - Add option to ignore fndecl attributes on function pointers

--- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86407#c6 --- gcc/c-family/c.opt | 4 gcc/c/c-decl.c | 4 +++- gcc/config/i386/i386-options.c | 12 ++-- gcc/testsuite/c-c++-common/pr86407-1.c | 23 +++

[Bug c++/79008] missing detail in -Wbuiltin-declaration-mismatch

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79008 --- Comment #4 from Eric Gallager --- (In reply to Martin Sebor from comment #2) > > One example of an incompatibility is the following declaration: > > int __attribute__ ((pure)) abs (int); > > where abs() the built-in is actually declared

Re: [PATCH] rs6000: Call flow implementation for PC-relative addressing

Hm, I got ahead of myself on this one.  I haven't done the regstrap yet, so please hold off reviewing for now. Sorry for the noise.  I shouldn't post when I'm tired... Thanks, Bill On 5/23/19 9:11 PM, Bill Schmidt wrote: > Hi, > > This patch contains the changes to implement call flow for

[PATCH] rs6000: Call flow implementation for PC-relative addressing

Hi, This patch contains the changes to implement call flow for PC-relative addressing. It's an amalgam of several internal patches that Alan and I worked on, and as a result it's hard to tease apart individual pieces much further. So I apologize that this patch is a little larger than the

Re: [PATCH] Move VEC_PERM_EXPR folding to match.pd

On 20 May 2019 12:31:46 CEST, Richard Biener wrote: > >So the following is what I have applied. Typo in the guard? s/GCC_VEC_PERN_INDICES_H/GCC_VEC_PERM_INDICES_H/ ? I.e. not pern but perm, with an 'M' thanks, >Bootstrapped / tested on x86_64-unknown-linux-gnu. > >Richard. > >2019-05-20

Re: Fix alias oracle stats

Hi honza, On 20 May 2019 11:38:14 CEST, Richard Biener wrote: >On Mon, 20 May 2019, Jan Hubicka wrote: > >> Hi, >> at the moment the alias stats outputs mostly 0 for res_may_alias_p >> (which is supposed to be main entry point to the alias oracle). >> I think this is because of code refactoring

gcc-7-20190523 is now available

Snapshot gcc-7-20190523 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20190523/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

On Tue, 21 May 2019, Segher Boessenkool wrote: > > I think having author names and email addresses is a basic requirement of > > any reasonable repository conversion > > Yes, and they should be the same as they were in the original repository. That's what the "changelogs" feature in

Re: On-Demand range technology [3/5] - The Prototype

> While I agree that symbolic ranges are a complication and that most > cases it currently handles are not "value-range" things I do not agree > with the idea that we can simply remove handling them and deal > with the fallout in some later point in the future. Eric may also be > able to show you

Re: *Ping* Re: [PATCH] PR c/43673 - Incorrect warning in dfp printf.

On Tue, 21 May 2019, Jeff Law wrote: > On 5/20/19 6:56 PM, luoxhu wrote: > > Ping for GCC-10. > I thought this was a NAK in its current form. > > See Ryan's c#1 in the BZ. I don't see that as relevant to this bug report. That comment is about the question of how GCC can know whether libc's

[Bug target/90600] incompatible 64-bit-types in x86-intrinsics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90600 Marc Glisse changed: What|Removed |Added Keywords|ssemmx | --- Comment #5 from Marc Glisse --- (In

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 --- Comment #41 from joseph at codesourcery dot com --- It's likely that caring about exceptions would actually be worse for optimization than caring about rounding modes (because exceptions mean that floating-point operations can write global

[PATCH] Fix testsuite bugs

One of the static assertions in 20_util/function_objects/invoke/1.cc was wrong, but didn't fail because by default it was compiled with -std=gnu++14 which didn't use that static assertion. Split out the C++17 parts to a new file that always runs with -std=gnu++17, so those checks are always done.

[PATCH] LWG 2996 add rvalue overloads for shared_ptr aliasing and casting

* doc/xml/manual/intro.xml: Document LWG DR 2996 change. * doc/html/*: Regenerate. * include/bits/shared_ptr.h (shared_ptr(shared_ptr&&, T*)): Add rvalue aliasing constructor. (static_pointer_cast, const_pointer, dynamic_pointer_cast)

[PATCH] LWG 2921 remove packaged_task constructors taking allocators

* doc/xml/manual/evolution.xml: Document LWG DR 2921 change. * doc/xml/manual/intro.xml: Likewise. * include/std/future (__create_task_state): Add default arguments to make providing an allocator optional. (packaged_task::packaged_task(F&&)): Call

[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883 --- Comment #8 from joseph at codesourcery dot com --- Given how often such issues are in target-specific code, for targets that only get built as cross compilers, in practice we'll need someone building for all architectures *using a native

[PATCH] Allow fusion of stack_protect_test_ with adjacent conditional jump (PR target/90568)

Hi! On Thu, May 23, 2019 at 12:40:51AM +0200, Jakub Jelinek wrote: > Incrementally, we should consider handling e.g. *subsi_2{,_zext} and similar > patterns and also this stack_protect_test_[sd]i in ix86_macro_fusion_pair_p, > not sure if unconditionally, or only when tuning for skylake+ /

[PATCH} rs6000: Enable PC-relative by default and test

Hi, This is a short patch that enables PC-relative support by default, and provides a test case to ensure that the correct .localentry name,1 directive is produced iff PC-relative support is enabled. Bootstrapped and tested on powerpc64le-unknown-linux-gnu. Okay for trunk? Thanks, Bill

[PATCH] Add LABEL_REF_P to rtl.h

Hi, This patch just adds a convenience macro to be used in subsequent patches. Bootstrapped successfully on powerpc64le-unknown-linux-gnu. Okay for trunk? Thanks, Bill 2019-05-23 Michael Meissner * rtl.h (LABEL_REF_P): New #define. Index: gcc/rtl.h

Re: Fixed: "required ftruncate or chsize support not present" in gfortran testsuite

On Thu, May 23, 2019 at 5:21 AM Hans-Peter Nilsson wrote: > > There was a regression for gfortran.dg/fmt_en.f90 for cris-elf > that on inspection was due to it having acquired a truncation > call through the runtime. I updated that and the new tests that > had "Fortran runtime error: required

Re: [PATCH,RFC 0/3] Support for CTF in GCC

On 05/22/2019 02:04 AM, Richard Biener wrote: The CTF debug information is kept in a CTF container distinct from the frontend structures. HashMaps are used to avoid generation of duplicate CTF and to book-keep the generated CTF. OK. So I wonder how difficult it is to emit CTF by walking

What are the optimizations that contribute to ~70% improvement on SPEC06 hmmer benchmark?

Recently I happen to notice that there is more than 70% performance improvement for SPEC06 hmmer benchmark from Linaro GCC 5.2-2015.11-2 to GCC 10.0 on ARM platforms. I did some quick searching and think loop

[PATCH, i386]: Fix PR90552, attribute((optimize(3))) not overriding -Os

Hello! As explained in the PR, ix86_cost switches to ix86_size_cost when -Os is used. This defeats the intention of speed variable to ix86_rtx_costs, which is set according to the optimization level at the point of insn insertion. 2019-05-23 Uroš Bizjak PR target/90552 *

[Bug target/90552] attribute((optimize(3))) not overriding -Os

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90552 --- Comment #5 from uros at gcc dot gnu.org --- Author: uros Date: Thu May 23 19:46:56 2019 New Revision: 271576 URL: https://gcc.gnu.org/viewcvs?rev=271576=gcc=rev Log: PR target/90552 * config/i386/i386.c (gen_rtx_cost):

[Bug target/90600] incompatible 64-bit-types in x86-intrinsics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90600 --- Comment #4 from g.peterh...@t-online.de --- Am 23.05.19 um 20:11 schrieb glisse at gcc dot gnu.org: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90600 > > --- Comment #3 from Marc Glisse --- > Intel documents that it uses "unsigned

[C++ Patch] A few more grokdeclarator locations fixes

Hi, one more, rather straightforward, simply use the location stored in the declarator. Tested x86_64-linux. Thanks, Paolo. /cp 2019-05-23 Paolo Carlini * decl.c (grokdeclarator): Use declarator->id_loc in five error error_at calls. /testsuite

[Bug middle-end/90607] [10 regression] gcc.dg/pr53265.c FAILs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90607 Rainer Orth changed: What|Removed |Added Target Milestone|--- |10.0

[Bug middle-end/90607] New: [10 regression] gcc.dg/pr53265.c FAILs

20190522 (r271513) and 20190523 (r271572), gcc.dg/pr53265.c began to FAIL on a couple of targets: +FAIL: gcc.dg/pr53265.c (test for excess errors) Excess errors: cc1: warning: '__builtin_memcpy' forming offset [17, 24] is out of the bounds [0, 16] of object 'c' with type 'unsigned char[16

[Bug c++/90606] New: Replace mfence with faster xchg for std::memory_order_seq_cst.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90606 Bug ID: 90606 Summary: Replace mfence with faster xchg for std::memory_order_seq_cst. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal

[Bug middle-end/90605] [10 regression] ICE: in gimplify_cond_expr, at gimplify.c:3998

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90605 Rainer Orth changed: What|Removed |Added Target Milestone|--- |10.0

[Bug middle-end/90605] New: [10 regression] ICE: in gimplify_cond_expr, at gimplify.c:3998

Between 20190522 (r271513) and 20190523 (r271572), three D tests began to FAIL on Solaris 11/SPARC and x86, both 32 and 64-bit: +FAIL: gdc.test/runnable/link15017.d (internal compiler error) +FAIL: gdc.test/runnable/link15017.d -O2 (internal compiler error) +FAIL: gdc.test/runnable/link15017.d -O2

[Bug target/90600] incompatible 64-bit-types in x86-intrinsics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90600 --- Comment #3 from Marc Glisse --- Intel documents that it uses "unsigned __int64" but I don't see where they document what __int64 is. We could take a "void *out" argument and cast it inside the function, but that would lose useful diagnostics

[Bug target/90600] incompatible 64-bit-types in x86-intrinsics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90600 --- Comment #2 from g.peterh...@t-online.de --- Am 23.05.19 um 19:04 schrieb jakub at gcc dot gnu.org: > Note, clang agrees with gcc here, and I don't think it is a good idea to > change > this incompatibly. I think it would be better if there

[Bug c++/90590] enumeration value not handled in switch warning for std::ios_base::seek_dir

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

[Bug d/90604] New: ICE in sizemask, at d/dmd/mtype.c:2542

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90604 Bug ID: 90604 Summary: ICE in sizemask, at d/dmd/mtype.c:2542 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d

[Bug d/90603] New: ICE in functionParameters, at d/dmd/expression.c:1553

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90603 Bug ID: 90603 Summary: ICE in functionParameters, at d/dmd/expression.c:1553 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug d/90602] New: ICE: null field

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90602 Bug ID: 90602 Summary: ICE: null field Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at

[Bug d/90601] New: ICE: gimplification failed (gimplify.c at 13436)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90601 Bug ID: 90601 Summary: ICE: gimplification failed (gimplify.c at 13436) Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

Re: *ping* Re: [PATCH] PR fortran/89100 Default widths for i, f and g format specifiers in format strings

On Thu, May 23, 2019 at 05:26:53PM +0200, Christophe Lyon wrote: > On Thu, 23 May 2019 at 15:54, Mark Eggleston > wrote: > > > > > > The logs contain: > > > /gcc/testsuite/gfortran.dg/fmt_f_default_field_width_1.f90:15:11: > > > Error: Kind 16 not supported for type REAL at (1) > > > > > >

[Bug target/90600] incompatible 64-bit-types in x86-intrinsics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90600 Jakub Jelinek changed: What|Removed |Added CC||hjl.tools at gmail dot com,

Re: -Wformat-diag: floating-point or floating point?

On Wed, 22 May 2019, Martin Sebor wrote: > ISO C does not support decimal floating point And as a tangential point, that's not accurate for C2X, where DFP is an optional standard feature, but it's probably reasonable to keep the diagnostic saying "ISO C does not support" under its existing

[Bug c++/90598] [9/10 Regression] Return type of explicit destructor call wrong

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90598 --- Comment #4 from Jakub Jelinek --- Another possibility is to return clk_none from lvalue_kind when seeing a MODIFY_EXPR with VOID_TYPE_P (TREE_TYPE (ref)).

[Bug c++/90598] [9/10 Regression] Return type of explicit destructor call wrong

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90598 --- Comment #3 from Jakub Jelinek --- The problem is that by the time finish_decltype_type is called, the destructor call is already folded into a TARGET_EXPR = {CLOBBER}; The following untested patch fixes it for me: 2019-05-23 Jakub Jelinek

Re: [PATCH] netbsd EABI support

On Thu, May 23, 2019 at 05:11:30PM +0100, Richard Earnshaw (lists) wrote: > On 23/05/2019 17:01, Richard Earnshaw (lists) wrote: > > On 23/05/2019 15:11, Richard Earnshaw (lists) wrote: > >> On 23/05/2019 15:03, Richard Earnshaw (lists) wrote: > >>> On 20/05/2019 20:24, Jeff Law wrote: > On

Re: [PATCH v2] rs6000: Entry point generation for functions using PC-relative addressing

On Thu, May 23, 2019 at 10:21:44AM -0500, Bill Schmidt wrote: > Functions using PC-relative addressing do not use a TOC, so there is no need > for > a global entry point for TOC setup. Ensure we never generate a global entry > point, and use a .localentry directive that sets the upper st_other

[Bug c++/90598] [9/10 Regression] Return type of explicit destructor call wrong

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90598 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug target/90513] asm thunks do not work on PowerPC64/VxWorks (kernel mode)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513 --- Comment #16 from Eric Botcazou --- > you mean ,the target-independent code in the C++ front end will generate a > less efficient heavyweight thunk that calls function instead of jumping to > it ? The cgraphunit code

[Bug target/90600] New: incompatible 64-bit-types in x86-intrinsics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90600 Bug ID: 90600 Summary: incompatible 64-bit-types in x86-intrinsics Product: gcc Version: 9.1.1 Status: UNCONFIRMED Keywords: ssemmx Severity: normal Priority:

Re: [PATCH] netbsd EABI support

On 23/05/2019 17:01, Richard Earnshaw (lists) wrote: > On 23/05/2019 15:11, Richard Earnshaw (lists) wrote: >> On 23/05/2019 15:03, Richard Earnshaw (lists) wrote: >>> On 20/05/2019 20:24, Jeff Law wrote: On 4/9/19 10:36 AM, Richard Earnshaw (lists) wrote: > On 09/04/2019 16:04, Jeff Law

Re: [PATCH] netbsd EABI support

On Thu, May 23, 2019 at 3:12 PM Richard Earnshaw (lists) wrote: > > On 23/05/2019 15:03, Richard Earnshaw (lists) wrote: > > On 20/05/2019 20:24, Jeff Law wrote: > >> On 4/9/19 10:36 AM, Richard Earnshaw (lists) wrote: > >>> On 09/04/2019 16:04, Jeff Law wrote: > On 4/8/19 9:17 AM,

[Bug tree-optimization/90576] [10 regression] SPEC CPU2006 450.soplex miscompiled with -Os -flto after r271413

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90576 --- Comment #3 from Jan Hubicka --- Author: hubicka Date: Thu May 23 16:07:07 2019 New Revision: 271572 URL: https://gcc.gnu.org/viewcvs?rev=271572=gcc=rev Log: PR tree-optimization/90576 * tree-ssa-alias.c (compare_sizes):

[PATCH] Add missing feature test macro to C++17 status table

* doc/xml/manual/status_cxx2017.xml: Add feature test macro for P0040R3. * doc/html/*: Regenerate. Committed to trunk. commit f58762124c374887a5785a6f4a812af64fe5b2f1 Author: Jonathan Wakely Date: Thu May 23 17:00:37 2019 +0100 Add missing feature test macro to

Re: [PATCH] netbsd EABI support

On 23/05/2019 15:11, Richard Earnshaw (lists) wrote: > On 23/05/2019 15:03, Richard Earnshaw (lists) wrote: >> On 20/05/2019 20:24, Jeff Law wrote: >>> On 4/9/19 10:36 AM, Richard Earnshaw (lists) wrote: On 09/04/2019 16:04, Jeff Law wrote: > On 4/8/19 9:17 AM, co...@sdf.org wrote: >>

[Bug c++/90590] enumeration value not handled in switch warning for std::ios_base::seek_dir

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90590 --- Comment #6 from Marek Polacek --- (In reply to Jonathan Wakely from comment #5) > (In reply to Marek Polacek from comment #4) > > Suppressing the warning when the enumerator comes from a system header > > should be fairly easy using

[Bug c++/90590] enumeration value not handled in switch warning for std::ios_base::seek_dir

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90590 --- Comment #5 from Jonathan Wakely --- (In reply to Marek Polacek from comment #4) > Suppressing the warning when the enumerator comes from a system header > should be fairly easy using in_system_header_at. Yes, I got that working myself

[Bug c++/90590] enumeration value not handled in switch warning for std::ios_base::seek_dir

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90590 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment

[Bug libstdc++/85998] feature request: support C++17 parallel STL

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

[Bug libstdc++/88740] [7 Regression] libstdc++ tests no longer print assertion failure messages

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

[Bug libstdc++/88740] [7 Regression] libstdc++ tests no longer print assertion failure messages

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88740 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Thu May 23 15:34:37 2019 New Revision: 271569 URL: https://gcc.gnu.org/viewcvs?rev=271569=gcc=rev Log: PR libstdc++/88740 Print assertion messages to stderr Backport from mainline

[Bug libstdc++/89466] [7/8 Regression] Accessing the Internet while boostrapping

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

[Bug libstdc++/89466] [7/8 Regression] Accessing the Internet while boostrapping

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89466 --- Comment #21 from Jonathan Wakely --- Author: redi Date: Thu May 23 15:34:42 2019 New Revision: 271570 URL: https://gcc.gnu.org/viewcvs?rev=271570=gcc=rev Log: PR libstdc++/89466 avoid slow xsltproc command in configure Certain broken

[Bug libstdc++/89466] [7/8 Regression] Accessing the Internet while boostrapping

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89466 --- Comment #20 from Jonathan Wakely --- Author: redi Date: Thu May 23 15:34:25 2019 New Revision: 271568 URL: https://gcc.gnu.org/viewcvs?rev=271568=gcc=rev Log: PR libstdc++/89466 avoid slow xsltproc command in configure Certain broken

[Bug c++/90598] [9/10 Regression] Return type of explicit destructor call wrong

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90598 Jonathan Wakely changed: What|Removed |Added CC||jason at gcc dot gnu.org Target

Re: [PATCH, X86] Revise fuse-caller-save-* to avoid XPASSes on PIC targets.

On Thu, May 23, 2019 at 8:25 AM Iain Sandoe wrote: > > > > On 23 May 2019, at 16:17, H.J. Lu wrote: > > > > On Thu, May 23, 2019 at 6:09 AM Uros Bizjak wrote: > >> > >> On Thu, May 23, 2019 at 11:25 AM Iain Sandoe wrote: > >> > These changes are OK as long as they don't regress HJ's

Re: *ping* Re: [PATCH] PR fortran/89100 Default widths for i, f and g format specifiers in format strings

On Thu, 23 May 2019 at 15:54, Mark Eggleston wrote: > > On 23/05/2019 11:38, Christophe Lyon wrote: > > On Wed, 22 May 2019 at 13:57, Janne Blomqvist > > wrote: > >> On Wed, May 22, 2019 at 10:58 AM Mark Eggleston > >> wrote: > >>> On 13/05/2019 10:45, Mark Eggleston wrote: >

[Bug middle-end/90599] New: Inefficient code for __builtin_memset

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90599 Bug ID: 90599 Summary: Inefficient code for __builtin_memset Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end

[Bug c++/90598] New: Return type of explicit destructor call wrong

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90598 Bug ID: 90598 Summary: Return type of explicit destructor call wrong Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

Re: [PATCH, X86] Revise fuse-caller-save-* to avoid XPASSes on PIC targets.

> On 23 May 2019, at 16:17, H.J. Lu wrote: > > On Thu, May 23, 2019 at 6:09 AM Uros Bizjak wrote: >> >> On Thu, May 23, 2019 at 11:25 AM Iain Sandoe wrote: >> These changes are OK as long as they don't regress HJ's x86_64 and i686 autotesters. >>> >>> Applied as r271544, will

[PATCH v2] rs6000: Entry point generation for functions using PC-relative addressing

Hi, Functions using PC-relative addressing do not use a TOC, so there is no need for a global entry point for TOC setup. Ensure we never generate a global entry point, and use a .localentry directive that sets the upper st_other bits to 1. Also change a function name for clarity, and move a var

Re: [PATCH, X86] Revise fuse-caller-save-* to avoid XPASSes on PIC targets.

On Thu, May 23, 2019 at 6:09 AM Uros Bizjak wrote: > > On Thu, May 23, 2019 at 11:25 AM Iain Sandoe wrote: > > > > These changes are OK as long as they don't regress HJ's x86_64 and > > > i686 autotesters. > > > > Applied as r271544, will look out for such fails. > > > > > Double points if they

Re: [PATCH] rs6000: Entry point generation for functions using PC-relative addressing

On Thu, May 23, 2019 at 08:56:23AM -0500, Bill Schmidt wrote: > On 5/23/19 6:06 AM, Segher Boessenkool wrote: > > On Wed, May 22, 2019 at 06:39:55PM -0500, Bill Schmidt wrote: > >> @@ -26191,6 +26191,10 @@ rs6000_global_entry_point_needed_p (void) > >>if (TARGET_SINGLE_PIC_BASE) > >>

[Bug libstdc++/90220] std::any_cast misbehaves for function and array types

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

[Bug libstdc++/90220] std::any_cast misbehaves for function and array types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90220 --- Comment #10 from Jonathan Wakely --- Author: redi Date: Thu May 23 15:08:58 2019 New Revision: 271565 URL: https://gcc.gnu.org/viewcvs?rev=271565=gcc=rev Log: PR libstdc++/90220 Fix any_cast for non-object types Backport from mainline

Re: [RFC PATCH] Coalesce host to device transfers in libgomp

On Thu, May 23, 2019 at 04:40:14PM +0200, Thomas Schwinge wrote: > Hi! > > On Tue, 24 Oct 2017 11:55:27 +0200, Jakub Jelinek wrote: > > The following patch implements coalescing of transfers (only those that are > > copied into the freshly allocated device buffer) into one or multiple larger > >

[Bug libstdc++/90220] std::any_cast misbehaves for function and array types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90220 --- Comment #8 from Jonathan Wakely --- Author: redi Date: Thu May 23 14:49:15 2019 New Revision: 271561 URL: https://gcc.gnu.org/viewcvs?rev=271561=gcc=rev Log: PR libstdc++/90220 Fix any_cast for non-object types Backport from mainline

[Bug c++/90569] __STDCPP_DEFAULT_NEW_ALIGNMENT__ is wrong for i386-pc-solaris2.11

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90569 --- Comment #9 from Jonathan Wakely --- (In reply to Florian Weimer from comment #8) > The problem is that popular mallocs do not care about ABI and return > unaligned pointers for allocations smaller than the max_align_t alignment. > As a

Re: [PATCH] A jump threading opportunity for condition branch

Richard Biener writes: > On Thu, 23 May 2019, Jiufu Guo wrote: > >> Hi, >> >> Richard Biener writes: >> >> > On Tue, 21 May 2019, Jiufu Guo wrote: >> > >> >> Hi, >> >> >> >> This patch implements a new opportunity of jump threading for PR77820. >> >> In this optimization, conditional jumps

Re: [RFC PATCH] Coalesce host to device transfers in libgomp

Hi! On Tue, 24 Oct 2017 11:55:27 +0200, Jakub Jelinek wrote: > The following patch implements coalescing of transfers (only those that are > copied into the freshly allocated device buffer) into one or multiple larger > transfers. The patch doesn't coalesce > 32KB transfers or transfers where >

[Bug c++/90569] __STDCPP_DEFAULT_NEW_ALIGNMENT__ is wrong for i386-pc-solaris2.11

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90569 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #8

[Bug preprocessor/90581] provide an option to adjust the maximum depth of nested #include

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90581 --- Comment #2 from qinzhao at gcc dot gnu.org --- (In reply to Richard Biener from comment #1) > Confirmed. Just curious - were you able to simply up this limit > successfully? Yes, one of our applications' depth of nested #include is 202

[Bug libstdc++/90220] std::any_cast misbehaves for function and array types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90220 --- Comment #7 from Jonathan Wakely --- Author: redi Date: Thu May 23 14:18:13 2019 New Revision: 271558 URL: https://gcc.gnu.org/viewcvs?rev=271558=gcc=rev Log: PR libstdc++/90220 fix experimental::any_cast for non-object types This

[Bug middle-end/90597] New: FAIL: gcc.dg/attr-vector_size.c (internal compiler error)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90597 Bug ID: 90597 Summary: FAIL: gcc.dg/attr-vector_size.c (internal compiler error) Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal

[PATCH] Make any_cast compare typeinfo as well as function pointers

It's possible for the function pointer comparison to fail even though the type is correct, because the function could be defined multiple times with different addresses when shared libraries are in use. Retain the function pointer check for the common case where the check succeeds, but compare

Re: [PATCH] netbsd EABI support

On 23/05/2019 15:03, Richard Earnshaw (lists) wrote: > On 20/05/2019 20:24, Jeff Law wrote: >> On 4/9/19 10:36 AM, Richard Earnshaw (lists) wrote: >>> On 09/04/2019 16:04, Jeff Law wrote: On 4/8/19 9:17 AM, co...@sdf.org wrote: > Pinging again in the hope of getting the patch in, I'd like

Re: On-Demand range technology [5/5] - Looking to the future.

On Thu, May 23, 2019 at 3:30 AM Andrew MacLeod wrote: > > A primary goal of this approach is to try to pull the various aspects of > VRP apart and make them individually viable so they can be used at > appropriate places as needed. The various components of VRP were > identified as: > -

Re: [PATCH] netbsd EABI support

On 20/05/2019 20:24, Jeff Law wrote: > On 4/9/19 10:36 AM, Richard Earnshaw (lists) wrote: >> On 09/04/2019 16:04, Jeff Law wrote: >>> On 4/8/19 9:17 AM, co...@sdf.org wrote: Pinging again in the hope of getting the patch in, I'd like to have less outstanding patches :) (I have quite a

Re: *ping* Re: [PATCH] PR fortran/89100 Default widths for i, f and g format specifiers in format strings

On Thu, May 23, 2019 at 12:38:12PM +0200, Christophe Lyon wrote: > On Wed, 22 May 2019 at 13:57, Janne Blomqvist > wrote: > > > > > > * gfortran.dg/fmt_f_default_field_width_1.f90: New test. > > > > * gfortran.dg/fmt_f_default_field_width_2.f90: New test. > > > > *

Re: [PATCH] rs6000: Entry point generation for functions using PC-relative addressing

On 5/23/19 6:06 AM, Segher Boessenkool wrote: > Hi! > > On Wed, May 22, 2019 at 06:39:55PM -0500, Bill Schmidt wrote: >> @@ -26191,6 +26191,10 @@ rs6000_global_entry_point_needed_p (void) >>if (TARGET_SINGLE_PIC_BASE) >> return false; >> >> + /* PC-relative functions never generate a

Re: *ping* Re: [PATCH] PR fortran/89100 Default widths for i, f and g format specifiers in format strings

On 23/05/2019 11:38, Christophe Lyon wrote: On Wed, 22 May 2019 at 13:57, Janne Blomqvist wrote: On Wed, May 22, 2019 at 10:58 AM Mark Eggleston wrote: On 13/05/2019 10:45, Mark Eggleston wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89100 see comment 4 Please can someone commit the

[Bug libgomp/90596] New: 'GOACC_parallel_keyed' should use 'GOMP_MAP_VARS_TARGET'

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90596 Bug ID: 90596 Summary: 'GOACC_parallel_keyed' should use 'GOMP_MAP_VARS_TARGET' Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: openacc

Re: [PATCH] tree-ssa-uninit: suppress more spurious warnings

Iain Sandoe writes: >> On 22 May 2019, at 16:19, Jeff Law wrote: >> >> On 5/22/19 8:44 AM, Vladislav Ivanishin wrote: >>> Christophe, Rainer, >>> >>> Rainer Orth writes: >>> Hi Christophe, > On Fri, 17 May 2019 at 10:12, Vladislav Ivanishin wrote: >> > As you have

[Bug libstdc++/90220] std::any_cast misbehaves for function and array types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90220 --- Comment #6 from Jonathan Wakely --- Author: redi Date: Thu May 23 13:39:06 2019 New Revision: 271556 URL: https://gcc.gnu.org/viewcvs?rev=271556=gcc=rev Log: PR libstdc++/90220 fix experimental::any_cast for non-object types This

[PATCH] PR libstdc++/90220 fix experimental::any_cast for non-object types

This corresponds to the fixes done for std::any_cast, but has to be done without if-constexpr. The dummy specialization of _Manager_internal<_Op> is used to avoid instantiating the real _Manager_internal::_S_manage function just to compare its address. PR libstdc++/90220 *

Re: [PATCH] rs6000: Add basic infrastructure for PC-relative addressing

On 5/23/19 4:27 AM, Segher Boessenkool wrote: > Hi! > > On Wed, May 22, 2019 at 03:29:17PM -0500, Bill Schmidt wrote: >> + /* -mpcrel requires the prefixed load/store support on FUTURE systems. */ >> + if (!TARGET_FUTURE && TARGET_PCREL) >> +{ >> + if ((rs6000_isa_flags_explicit &

Re: On-Demand range technology [4/5] - Performance results

On Thu, May 23, 2019 at 3:29 AM Andrew MacLeod wrote: > > We have done extensive performance analysis to help address concerns > about the nature of an on-demand model. LLVM made an attempt at > something similar, but suffered from significant performance issues > they could not solve with their

[Bug tree-optimization/90571] Missed optimization opportunity when returning function pointers based on run-time boolean

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90571 --- Comment #4 from Vittorio Romeo --- > I wonder how the "original" testcase looked like - the one in this bug is probably simplified from real-world code? This is what the original author of the code (Filipp Gelman) said: > I was reviewing

Re: [PATCH v2] rs6000: Infrastructure for future arch

On Thu, May 23, 2019 at 04:27:34AM -0500, Bill Schmidt wrote: > This patch introduces the infrastructure to support -mcpu=future, used for > features > in a future architecture, as yet unnamed. Reworked to incorporate comments > from > Segher and Alan. Thanks for the reviews! > > Bootstrapped

Re: Fix simulator timeout for testsuite/26_numerics/random/poisson_distribution/operators/values.cc

On 23/05/19 15:14 +0200, Hans-Peter Nilsson wrote: This test regressed for cris-elf (testing in a simulator) with the fixing of libstdc++/83237, as the part suggested to be wrapped in #ifndef was *added* to the existing test and causes a timeout. Tsk tsk. Please don't pile-on existing tests,

  1   2   3   >