Re: [PATCH] Fix PR84003

On Fri, 26 Jan 2018, Richard Biener wrote: > On Fri, 26 Jan 2018, Richard Sandiford wrote: > > > Richard Biener writes: > > > On Thu, 25 Jan 2018, Richard Sandiford wrote: > > > > > >> Richard Sandiford writes: > > >> > Richard Biener

[Bug middle-end/84034] [6/7/8 Regression] incomplete warning message with dos line endings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84034 --- Comment #3 from Bernd Edlinger --- Author: edlinger Date: Sat Jan 27 06:44:25 2018 New Revision: 257120 URL: https://gcc.gnu.org/viewcvs?rev=257120=gcc=rev Log: 2018-01-27 Bernd Edlinger PR

[Bug middle-end/84040] [8 regression] compilation time of gcc.c-torture/compile/limits-blockid.c is 50x slower

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

[Bug middle-end/84040] [8 regression] compilation time of gcc.c-torture/compile/limits-blockid.c is 50x slower

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84040 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Sat Jan 27 06:28:15 2018 New Revision: 257119 URL: https://gcc.gnu.org/viewcvs?rev=257119=gcc=rev Log: PR middle-end/84040 * sched-deps.c (sched_macro_fuse_insns): Return

Re: [PATCH] Avoid O(n^2) compile time issue in sched2 with debug insns (PR middle-end/84040)

On 01/26/2018 06:15 PM, Jakub Jelinek wrote: Hi! On a testcase which has 10 consecutive debug insns sched2 spends a lot of time calling prev_nonnote_nondebug_insn on each of the debug insns, even when it is completely useless, because no target wants to fuse a non-debug insn with some

[Bug fortran/82994] ICE in gfc_match_deallocate, at fortran/match.c:4478

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

[Bug fortran/68746] FAIL: gfortran.dg/read_dir.f90 -O0 execution test

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68746 --- Comment #9 from dave.anglin at bell dot net --- On 2018-01-26 8:29 PM, dominiq at lps dot ens.fr wrote: > By the xfail? Can the PR be closed? I'll have to investigate...

[Bug fortran/68746] FAIL: gfortran.dg/read_dir.f90 -O0 execution test

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68746 --- Comment #8 from Dominique d'Humieres --- > I don't have a recent gcc-6 set of test results but the bug is fixed in > gcc-7 and gcc-8. By the xfail? Can the PR be closed?

[Bug libstdc++/58931] condition_variable::wait_until overflowed by large time_point

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58931 --- Comment #5 from Aaron Graham --- Created attachment 43261 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43261=edit Patch to check for overflow

[Bug fortran/68746] FAIL: gfortran.dg/read_dir.f90 -O0 execution test

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68746 --- Comment #7 from dave.anglin at bell dot net --- I don't have a recent gcc-6 set of test results but the bug is fixed in gcc-7 and gcc-8.

[Bug c++/83342] extern marked variable template with later definition emits error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83342 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug fortran/68746] FAIL: gfortran.dg/read_dir.f90 -O0 execution test

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68746 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING --- Comment #6 from

[Bug fortran/66833] ICE on assumed-rank character actual argument to intrinsic functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66833 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4

[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 --- Comment #12 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #11) > (In reply to Ben Woodard from comment #10) > > Also note: > > https://connect.microsoft.com/VisualStudio/feedback/details/742775 > > > > My reading of: >

[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122 --- Comment #11 from Jonathan Wakely --- (In reply to Ben Woodard from comment #10) > Also note: https://connect.microsoft.com/VisualStudio/feedback/details/742775 > > My reading of: > https://wg21.link/lwg2381 > > is that if the first part of

[Bug fortran/56691] [OOP] Allocatable array: wrong offset when passing to CLASS dummy

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56691 --- Comment #10 from Dominique d'Humieres --- The test in comment 3 has likely been fixed by revision r222361 (pr60322).

[Bug c++/83835] [7/8 Regression] constexpr constructor rejected in c++17 mode (regression WRT c++14)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83835 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug fortran/56691] [OOP] Allocatable array: wrong offset when passing to CLASS dummy

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56691 Dominique d'Humieres changed: What|Removed |Added CC||vladimir.fuka at gmail dot com

[Bug fortran/84074] Incorrect indexing of array when actual argument is an array expression and dummy is polymorphic

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84074 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug target/84039] x86 retpolines and CFI

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84039 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed|

[Bug middle-end/84048] [8 Regression] FAIL: gcc.dg/torture/tls/run-ld.c -O0 -pie -fPIE execution test

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84048 John David Anglin changed: What|Removed |Added CC||doko at gcc dot gnu.org --- Comment

[Bug testsuite/83881] FAIL: c-c++-common/Wrestrict.c -std=gnu++98 (test for excess errors)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83881 John David Anglin changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|---

[Bug fortran/60322] [OOP] Incorrect bounds on polymorphic dummy array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60322 Dominique d'Humieres changed: What|Removed |Added CC||frank.otto at pci dot

[Bug fortran/58043] [OOP] Incorrect behaviour of polymorphic array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58043 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug target/56010] Powerpc, -mcpu=native and -mtune=native use the wrong name for target 7450

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56010 --- Comment #10 from Segher Boessenkool --- (In reply to Peter Bergner from comment #9) > (In reply to Segher Boessenkool from comment #8) > >> This kernel AT_PLATFORM name should strip the '+' off: > >> .platform = "power7+", -> "power7" > >

[Bug c++/83870] template parameter pack followed by another template parameter does not error when following parameter can not be deduced

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83870 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug fortran/84074] Incorrect indexing of array when actual argument is an array expression and dummy is polymorphic

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84074 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4

[PATCH] RISC-V: Allow register pairs for 64-bit target.

This was noticed while looking at some 64-bit libgcc code. Some functions like negti had a stack frame allocated, but did not use the stack. The 32-bit equivalent negdi did not have a stack frame allocated. This is because a 128-bit local variable got allocated to the stack and then optimized

Go patch committed: Show readable names in escape analysis messages

This patch to the Go frontend shows readable names in the messages printed for escape analysis. This will print names like `x` instead of `.p.x`. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline. Ian Index: gcc/go/gofrontend/MERGE

[Bug fortran/56765] [OOP] compilation errors/ICE with polymorphic array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56765 --- Comment #7 from Dominique d'Humieres --- > On my environment, all tests compile now without an ICE. Confirmed.

[Bug c++/83873] adjacent digit separators are accepted in the exponent-part of floating-point literals

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83873 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

Re: [PATCH] i386: Use const reference of struct ix86_frame to avoid copy

On Thu, Jan 18, 2018 at 12:23 AM, Uros Bizjak wrote: > On Wed, Jan 17, 2018 at 5:00 PM, H.J. Lu wrote: >> We can use const reference of struct ix86_frame to avoid making a local >> copy of ix86_frame. ix86_expand_epilogue makes a local copy of struct >>

[Bug fortran/83633] gfortran internal compiler error for explicit-shape array with non-constant bounds

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

Re: [PATCH] Extend lazy computation of expensive preprocessor macros to FLOATN*

On Sat, 27 Jan 2018, Jakub Jelinek wrote: > Works for me, this tests fine on a couple of tests, ok for trunk if it > passes bootstrap/regtest? > > 2018-01-27 Jakub Jelinek > > * c-cppbuiltin.c (c_cpp_builtins): Use ggc_strdup for the fp_suffix > argument. >

Re: [PATCH] Extend lazy computation of expensive preprocessor macros to FLOATN*

On Fri, Jan 26, 2018 at 11:22:04PM +, Joseph Myers wrote: > On Sat, 27 Jan 2018, Jakub Jelinek wrote: > > Honza reported today on IRC that we spent (again) significant time > > of empty file compilation computing preprocessor *_MAX/*_MIN etc. macros. > > In 2010 I've added lazy computation for

[PATCH] PR fortran/83633 -- check for nonconstant explicit shape array

The attached patch implements a check for F2015:C830. The wording of the F2008:C531 is nearly identical, but the restriction on BLOCK is noted in the normative test. The 3 lines in the new testcase show be sufficient to see the issue. In regression testing, I needed to adjust the regex pattern

Re: Bugzilla timing out

On 01/26/2018 04:08 PM, Frank Ch. Eigler wrote: Hi - Many copies of a 5 MB message have apparently been timing out in sourceware's spam processing, resulting in sourceware repeatedly accepting the message while the sender's mail server also times out (sooner) and keeps resending it. [...]

[Bug fortran/84074] New: Incorrect indexing of array when actual argument is an array expression and dummy is polymorphic

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84074 Bug ID: 84074 Summary: Incorrect indexing of array when actual argument is an array expression and dummy is polymorphic Product: gcc Version: 7.2.1 Status: UNCONFIRMED

[Bug c++/83936] [feature request] Allow constexpr char* as target argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83936 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

Re: [PATCH] Extend lazy computation of expensive preprocessor macros to FLOATN*

On Sat, 27 Jan 2018, Jakub Jelinek wrote: > Hi! > > Honza reported today on IRC that we spent (again) significant time > of empty file compilation computing preprocessor *_MAX/*_MIN etc. macros. > In 2010 I've added lazy computation for these, only when they are first used > except for -dD, but

Re: C++ PATCH to fix ICE with vector expr folding (PR c++/83659)

On Fri, Jan 26, 2018 at 02:11:19PM +0100, Richard Biener wrote: > >> POINTER_PLUS_EXPR offets are to be interpreted as signed (ptrdiff_t) > >> so using uhwi and then performing an unsigned division is wrong code. > >> See mem_ref_offset how to deal with this (ugh - poly-ints...). Basically > >>

[PATCH] Avoid creating >= 8GB EXPR_CONSTANT initializers for ilp32 targets (PR fortran/84065)

Hi! resolve_charlen is going to error on ilp32 target charlens above what can fit into 32-bit signed int, but add_init_expr_to_sym is done before resolve_charlen, allocating huge amounts of memory in those cases when we'll error later is just waste of compile time if running on 64-bit host with

[Bug c++/84055] warning: ignoring attributes on template argument ‘cl_uint {aka unsigned int}’ [-Wignored-attributes]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84055 --- Comment #6 from Kip Warner --- Hey Martin. Yes, you are right. I see it now in cl_platform.h.

[PATCH] Avoid O(n^2) compile time issue in sched2 with debug insns (PR middle-end/84040)

Hi! On a testcase which has 10 consecutive debug insns sched2 spends a lot of time calling prev_nonnote_nondebug_insn on each of the debug insns, even when it is completely useless, because no target wants to fuse a non-debug insn with some debug insn after it, it makes sense only for two

[Bug fortran/84073] In -fc-prototypes fixed (nonzero) length strings are mapped to plain char in prototype.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84073 --- Comment #2 from Dominique d'Humieres --- See also https://gcc.gnu.org/onlinedocs/gfortran/Further-Interoperability-of-Fortran-with-C.html#Further-Interoperability-of-Fortran-with-C > Using assumed-shape, assumed-rank and deferred-shape

[PATCH] Extend lazy computation of expensive preprocessor macros to FLOATN*

Hi! Honza reported today on IRC that we spent (again) significant time of empty file compilation computing preprocessor *_MAX/*_MIN etc. macros. In 2010 I've added lazy computation for these, only when they are first used except for -dD, but reserved just 12 entries for those, as only

Re: Bugzilla timing out

Hi - > Many copies of a 5 MB message have apparently been timing out in > sourceware's spam processing, resulting in sourceware repeatedly accepting > the message while the sender's mail server also times out (sooner) and > keeps resending it. [...] Thanks for the pointer. I tightened up

[Bug middle-end/84071] [7/8 regression] nonzero_bits1 of subreg incorrect

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84071 --- Comment #1 from Andrew Pinski --- I think this is related to PR 81443. Can you see if the 7.3 release has it fixed?

[Bug fortran/84073] In -fc-prototypes fixed (nonzero) length strings are mapped to plain char in prototype.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84073 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4

[Bug middle-end/84071] [7/8 regression] nonzero_bits1 of subreg incorrect

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84071 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Target|

[Bug target/83712] [6/7/8 Regression] "Unable to find a register to spill" when compiling for thumb1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83712 Vladimir Makarov changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org ---

[Bug c/83955] false positive implicit-fallthrough warning on switch enum

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83955 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

Re: [PATCH] fix for diagnostic/84034

On Thu, 2018-01-25 at 18:53 +, Bernd Edlinger wrote: > Hi, > > as PR diagnostic/84034 shows, source files with > dos style line endings can cause a glitch in the > terminal emulation that erases the source line that > is supposed to be shown. > > That happens when the colorizing escape

[Bug debug/83758] ICE building gccgo on powerpc64le --with-cpu=power8

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758 --- Comment #26 from acsawdey at gcc dot gnu.org --- A little bit more info: It appears the parameter asmhdr in this function is at the center of this: func (tools gccgoToolchain) gc(b *Builder, a *Action, archive string, importcfg []byte,

[Bug c++/84027] new-expression does not accept an attribute-specifier-seq

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84027 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

Re: Bugzilla timing out

On Fri, 26 Jan 2018, Frank Ch. Eigler wrote: > Hi - > > > Thanks for looking into it. I'm still (or again) seeing very > > poor responsiveness. Right now, bringing up an existing bug > > takes an entire minute. > > There has been quite a burst in activity on sourceware.org over the > last few

[Bug c++/84030] Name lookup in presence of namespace

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84030 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

Re: Bugzilla timing out

Hi - > Thanks for looking into it. I'm still (or again) seeing very > poor responsiveness. Right now, bringing up an existing bug > takes an entire minute. There has been quite a burst in activity on sourceware.org over the last few hours. Will look further into why, but quite a bit of it may

[Bug c++/84055] warning: ignoring attributes on template argument ‘cl_uint {aka unsigned int}’ [-Wignored-attributes]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84055 --- Comment #5 from Martin Sebor --- Here's what I see in attachment #43249: $ cat -n minimal.ii | grep -E -e 'typedef *[^ ]+ *cl_uint' -e uint32_t | grep typedef 66 typedef unsigned int __uint32_t; 186 typedef __uint32_t uint32_t;

Re: Bugzilla timing out

On Fri, Jan 26, 2018 at 1:52 PM, Martin Sebor wrote: > On 01/22/2018 11:08 AM, Frank Ch. Eigler wrote: >> >> Hi - >> >>> Problems are still occurring for me; Bugzilla gives me 504 Gateway >>> Time-outs when I try to access it tonight... >> >> >> OK, we reworked some of the

Re: Bugzilla timing out

On 01/22/2018 11:08 AM, Frank Ch. Eigler wrote: Hi - Problems are still occurring for me; Bugzilla gives me 504 Gateway Time-outs when I try to access it tonight... OK, we reworked some of the database routine maintenance workload, e.g., a nightly cleanup pass that was quite likely

[Bug target/83946] [7/8 Regression] Safe Indirect Jumps broken on AIX

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83946 --- Comment #11 from Segher Boessenkool --- Author: segher Date: Fri Jan 26 21:31:37 2018 New Revision: 257110 URL: https://gcc.gnu.org/viewcvs?rev=257110=gcc=rev Log: rs6000: Fix safe-indirect-jump-[18].c Thist patch merges the

[PATCH] RISC-V: Add --specs=nosys.specs support.

This makes --specs=nosys.specs work correctly. Without this patch, libnosys is ignored because libgloss gets pulled in first. We may have to revisit this in the future when we have some proper BSPs defined for various RISC-V hardware. Meanwhile, adding libgloss by default makes things easier

[Bug middle-end/84034] [6/7/8 Regression] incomplete warning message with dos line endings

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

Re: gcc generated memcpy calls symbol version

On Fri, Jan 26, 2018 at 1:17 PM, Tom Mason wrote: > I'm not entirely sure I understand that issue. From what I understand, calls > to a function in a shared library should always use the PLT? > Also, I don't understand the purpose of applying hidden visibility to an >

Re: gcc generated memcpy calls symbol version

I'm not entirely sure I understand that issue. From what I understand, calls to a function in a shared library should always use the PLT? Also, I don't understand the purpose of applying hidden visibility to an extern symbol, But anyway, doesn't matter terribly much if I understand :p On Fri, Jan

[Bug c++/60336] empty struct value is passed differently in C and C++

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 --- Comment #52 from H.J. Lu --- *** Bug 69846 has been marked as a duplicate of this bug. ***

[Bug target/69846] empty struct value fails to pass properly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69846 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug target/69846] empty struct value fails to pass properly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69846 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug c++/84036] [8 Regression] ICE on valid code in C++14, variadic lambda capture in a template function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84036 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug c++/83956] [8 regression] error: use of deleted function ‘{anonymous}::a::~a()’

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83956 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

C++ PATCH for c++/83956, wrong error with anon union and deleted dtor

Here, when we walk the subobjects to determine the exception specification of a defaulted destructor in order to apply it to a user-provided destructor, we shouldn't look at variant members dtors, which aren't called. We really shouldn't be looking at variant members here at all except to

[Bug c++/83956] [8 regression] error: use of deleted function ‘{anonymous}::a::~a()’

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83956 --- Comment #4 from Jason Merrill --- Author: jason Date: Fri Jan 26 20:47:32 2018 New Revision: 257107 URL: https://gcc.gnu.org/viewcvs?rev=257107=gcc=rev Log: PR c++/83956 - wrong dtor error with anonymous union * method.c

[Bug target/55258] SSE register isn't used for 16byte copy

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55258 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug rtl-optimization/83530] [8 Regression] ICE in reset_sched_cycles_in_current_ebb, at sel-sched.c:7150

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83530 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed|

Re: [PATCH] rs6000: Fix safe-indirect-jump-[18].c

On Fri, Jan 26, 2018 at 2:27 PM, Segher Boessenkool wrote: > Thist patch merges the safe-indirect-jump-1.c and -8.c testcases, > since they do the same thing. On the 64-bit and AIX ABIs the indirect > call is not a sibcall, since there is code generated after the call

Re: gcc generated memcpy calls symbol version

On Fri, Jan 26, 2018 at 12:29 PM, Tom Mason wrote: > Hi, > I've got a project here: https://github.com/wheybags/glibc_version_header > which uses .symver directives to link to a specified version of glibc, so > long as it's older than the version on your system. > This

[Bug fortran/84073] New: In -fc-prototypes fixed (nonzero) length strings are mapped to plain char in prototype.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84073 Bug ID: 84073 Summary: In -fc-prototypes fixed (nonzero) length strings are mapped to plain char in prototype. Product: gcc Version: 8.0 Status: UNCONFIRMED

gcc generated memcpy calls symbol version

Hi, I've got a project here: https://github.com/wheybags/glibc_version_header which uses .symver directives to link to a specified version of glibc, so long as it's older than the version on your system. This works, but a problem I'm having is that gcc itself will sometimes insert calls to memcpy

Re: [PATCH, fortran] Support Fortran 2018 teams

Committed revision 257105. Thanks. On Wed, Jan 24, 2018 at 3:17 PM, Jakub Jelinek wrote: > On Wed, Jan 24, 2018 at 08:19:58PM +, Paul Richard Thomas wrote: >> (Jakub, This is all hidden behind the -fcoarray option. To my mind >> this is safe for release.) > > Ok from RM

[Bug c++/84055] warning: ignoring attributes on template argument ‘cl_uint {aka unsigned int}’ [-Wignored-attributes]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84055 --- Comment #4 from Kip Warner --- Thanks Martin. I'm curious where the __int32 type was even coming from. cl_platform.h has the following typedef, among others that use it... typedef unsigned __int32cl_uint; ...but no where can I

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81763 --- Comment #48 from Uroš Bizjak --- (In reply to Mike Lothian from comment #47) > With the patch you've committed to gcc master, applied on top of GCC 7.3 I'm > now seeing the following error building Clang: I don't think this is related to

[Bug target/84072] New: [meta-bug] -mindirect-branch=thunk issues

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84072 Bug ID: 84072 Summary: [meta-bug] -mindirect-branch=thunk issues Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target

[Bug c++/84055] warning: ignoring attributes on template argument ‘cl_uint {aka unsigned int}’ [-Wignored-attributes]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84055 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug fortran/83998] [8 Regression] ICE in gfc_conv_intrinsic_dot_product, at fortran/trans-intrinsic.c:4403

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83998 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED

[Bug fortran/83998] [8 Regression] ICE in gfc_conv_intrinsic_dot_product, at fortran/trans-intrinsic.c:4403

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83998 --- Comment #2 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Jan 26 19:33:16 2018 New Revision: 257104 URL: https://gcc.gnu.org/viewcvs?rev=257104=gcc=rev Log: 2018-01-26 Steven G. Kargl PR

[PATCH] rs6000: Fix safe-indirect-jump-[18].c

Thist patch merges the safe-indirect-jump-1.c and -8.c testcases, since they do the same thing. On the 64-bit and AIX ABIs the indirect call is not a sibcall, since there is code generated after the call (the restore of r2). On the 32-bit non-AIX ABIs it is a sibcall. Tested on powerpc64-linux

[Bug c/84046] [6/7/8 Regression] global zero-sized objects may have same address

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84046 --- Comment #4 from Jakub Jelinek --- If you want aggregate with size 1 and isn't used to store information, use typedef struct { char : 1; } zero; instead.

[Bug lto/83967] LTO removes C functions declared as weak in assembler(depending on files order in linking)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83967 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug c/84046] [6/7/8 Regression] global zero-sized objects may have same address

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84046 --- Comment #3 from Martin Uecker --- (In reply to Richard Biener from comment #1) > Confirmed. I think the C language doesn't specify this since zero-sized > arrays are a GNU extension and thus in C no zero-sized types/decls exist? > > So

[Bug c++/83503] [8 Regression] bogus -Wattributes for const and pure on function template specialization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83503 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug c++/83502] [6/7/8 Regression] bogus -Wattributes for always_inline and noinline on function template specialization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83502 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug tree-optimization/84053] [6/7/8 Regression] missing -Warray-bounds accessing a struct array member

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84053 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug middle-end/84071] New: [7/8 regression] nonzero_bits1 of subreg incorrect

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84071 Bug ID: 84071 Summary: [7/8 regression] nonzero_bits1 of subreg incorrect Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: major Priority: P3 Component:

[Bug tree-optimization/84051] [6/7/8 Regression] missing -Warray-bounds on an out-of-bounds access via an array pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84051 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

It might be worth checking what MPFR is linking with in the test suite. I seemed to see it linking with the system libs when built in tree, rather than the in tree ones. This seems a regression in the MPFR test suite compared with 3.1.6 Andrew On 26/01/18 14:22, Rainer Orth wrote: I've

[Bug lto/83967] LTO removes C functions declared as weak in assembler(depending on files order in linking)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83967 --- Comment #12 from H.J. Lu --- (In reply to Richard Biener from comment #8) > and then I get > > > gcc-7 t2.s t1.c -flto > /tmp/ccGhH7Cp.o:(.data+0x0): undefined reference to `Handler' > collect2: error: ld returned 1 exit status > > gcc-7

[Bug tree-optimization/83776] [6/7/8 Regression] missing -Warray-bounds indexing past the end of a string literal

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83776 --- Comment #5 from Martin Sebor --- (In reply to Aldy Hernandez from comment #4) > Isn't this a duplicate of pr84047? My patch on that seems to fix this bug > as well. > > I think we should merge these PRs somehow. This bug was introduced by

[Bug tree-optimization/84050] [6/7/8 Regression] missing -Warray-bounds accessing a struct array member

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84050 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81763 --- Comment #47 from Mike Lothian --- With the patch you've committed to gcc master, applied on top of GCC 7.3 I'm now seeing the following error building Clang: [294/954] /usr/bin/x86_64-pc-linux-gnu-g++ -m32 -D_FILE_OFFSET_BITS=64

  1   2   3   >