[Bug gcov-profile/88994] [GCOV] encoding (or unicode) error with gcov/gcc9 when generating filename

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88994 --- Comment #2 from Robin --- Nice :) Feel free to ask me any additionnal things if it may help.

[Bug gcov-profile/88994] [GCOV] encoding (or unicode) error with gcov/gcc9 when generating filename

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88994 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|

[Bug c/88993] GCC 9 -Wformat-overflow=2 should reflect real libc limits

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88993 --- Comment #4 from Florian Weimer --- (In reply to Jakub Jelinek from comment #3) > Rather than warning about this the bugs should be fixed, there is no reason > why glibc needs to malloc memory for these cases. I completely agree. The

[Bug d/89004] mtype.c:2329:33: error: comparison of integer expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long unsigned int’} [-Werror=sign-compare]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89004 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug d/89004] mtype.c:2329:33: error: comparison of integer expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long unsigned int’} [-Werror=sign-compare]

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

Re: [RFC] -Weverything

On Wed, Jan 23, 2019 at 08:17:00AM +0100, Thomas König wrote: > > > > Am 23.01.2019 um 01:53 schrieb Martin Sebor : > > > I often wish GCC supported it -- not in the hopes of finding every > > conceivable bug or transgression against known coding styles but > > as a tool to discover warnings

[Bug d/89004] New: mtype.c:2329:33: error: comparison of integer expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long unsigned int’} [-Werror=sign-compare]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89004 Bug ID: 89004 Summary: mtype.c:2329:33: error: comparison of integer expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long unsigned int’}

[Bug c/88993] GCC 9 -Wformat-overflow=2 should reflect real libc limits

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88993 --- Comment #3 from Jakub Jelinek --- Rather than warning about this the bugs should be fixed, there is no reason why glibc needs to malloc memory for these cases. For "%.65535s" I don't actually see where it would allocate memory, I see memory

Re: [RFC] -Weverything

> Am 23.01.2019 um 01:53 schrieb Martin Sebor : > I often wish GCC supported it -- not in the hopes of finding every > conceivable bug or transgression against known coding styles but > as a tool to discover warnings that have to be explicitly enabled > either by using their own options or by

[Bug target/88998] bad codegen with mmx instructions for unordered_map

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88998 David Zmick changed: What|Removed |Added CC||dpzmick at gmail dot com --- Comment #2

[Bug ipa/88985] [9 Regression] ICE in estimate_edge_devirt_benefit, at ipa-fnsummary.c:2585

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88985 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned

[Bug fortran/40598] Some missed optimizations in array assignment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40598 Jürgen Reuter changed: What|Removed |Added CC||juergen.reuter at desy dot de ---

[Bug tree-optimization/88713] Vectorized code slow vs. flang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713 --- Comment #33 from Marc Glisse --- (In reply to Chris Elrod from comment #32) > (In reply to Marc Glisse from comment #31) > > What we need to understand is why gcc doesn't try to generate rsqrt Without -mavx512er, we do not have an expander

[Bug tree-optimization/88713] Vectorized code slow vs. flang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713 --- Comment #32 from Chris Elrod --- (In reply to Marc Glisse from comment #31) > (In reply to Chris Elrod from comment #30) > > gcc caclulates the rsqrt directly > > No, vrsqrt14ps is just the first step in calculating sqrt here (slightly >

[Bug c++/89003] New: Return inside a statement expression while initializing a static local variable fails to cleanup cxa_guard

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89003 Bug ID: 89003 Summary: Return inside a statement expression while initializing a static local variable fails to cleanup cxa_guard Product: gcc Version: 5.4.1

[Bug target/88998] bad codegen with mmx instructions for unordered_map

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88998 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug tree-optimization/88713] Vectorized code slow vs. flang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713 --- Comment #31 from Marc Glisse --- (In reply to Chris Elrod from comment #30) > gcc caclulates the rsqrt directly No, vrsqrt14ps is just the first step in calculating sqrt here (slightly different formula than rsqrt). vrcp14ps shows that it

[Bug tree-optimization/88713] Vectorized code slow vs. flang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713 --- Comment #30 from Chris Elrod --- gcc still (In reply to Marc Glisse from comment #29) > The main difference I can see is that clang computes rsqrt directly, while > gcc first computes sqrt and then computes the inverse. Also gcc seems afraid

[Bug tree-optimization/88713] Vectorized code slow vs. flang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713 --- Comment #29 from Marc Glisse --- The main difference I can see is that clang computes rsqrt directly, while gcc first computes sqrt and then computes the inverse. Also gcc seems afraid of getting NaN for sqrt(0) so it masks out this value.

Re: About GSOC.

I built gcc as a debuggable compiler as given using -g3. I am using gdb and loaded the cc1 using: gdb --args cc1 with output as: Successfully loaded GDB hooks for GCC But I really dont know how to inspect a file like real.h (real_value)/real.c? Thanks. -Tejas On Wed, 23 Jan 2019 at 08:28,

Re: About GSOC.

> differ. (It's the unoptimized, stage1 cc1 that should be run under a > debugger. See for more details.) Hello. I normally configure GCC by (as you told) /configure --enable-languages=c,c++ --disable-bootstrap --disable-multilib And further as told in

[Bug tree-optimization/89002] New: ICE in scan_omp_1_op, at omp-low.c:3166

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89002 Bug ID: 89002 Summary: ICE in scan_omp_1_op, at omp-low.c:3166 Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: openmp Severity: normal Priority: P3

[Bug tree-optimization/88975] ICE: Segmentation fault (in verify_ssa or gimple_code)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88975 --- Comment #1 from Arseny Solokha --- --- xsihfn9u.c 2019-01-23 09:46:02.954589253 +0700 +++ msyweyyj.c 2019-01-23 09:46:13.439477032 +0700 @@ -4,7 +4,7 @@ int ij[gy]; int sk; -#pragma omp taskloop reduction(+:ij) +#pragma omp taskloop

Re: [PATCH] x86-64: Use TI->SF and TI->DF conversions in soft-fp

On Mon, Jan 21, 2019 at 6:03 PM Joseph Myers wrote: > > On Mon, 21 Jan 2019, H.J. Lu wrote: > > > The testcase at > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88931 > > > > with -frounding-math. __floattisf and __floattidf from libgcc2.c give > > the wrong results for FE_UPWARD and

Ms Mayes Williams delegate under United Nations

Hello Dear, It's my pleasure to meet you. My name is Ms Mayes Williams, from UK and I work as assistant coordinator delegate to Sub-Saharan under United Nations. I got your contact online when I’m searching for someone to set a partnership establishment with in your country, the terms of

[Bug c++/88986] [7/8/9 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in member_vec_binary_search, at cp/name-lookup.c:1136

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88986 --- Comment #2 from Marek Polacek --- Started with r244246.

[Bug c++/88986] [7/8/9 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in member_vec_binary_search, at cp/name-lookup.c:1136

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

[Bug c++/88987] [9 Regression] ICE: unexpected expression '(bool)sm' of kind implicit_conv_expr

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88987 --- Comment #2 from Marek Polacek --- Started with r266874.

[Bug c++/88987] [9 Regression] ICE: unexpected expression '(bool)sm' of kind implicit_conv_expr

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

Re: [PATCH] avoid assuming arrays have nonzero size (PR 88956)

On Tue, 22 Jan 2019, Martin Sebor wrote: > PS In GCC 10, unless there is an important use case that escapes > me, I think GCC should warn for zero-length non-member array > objects, or perhaps even for internal struct members (those followed > by another member). Not to avoid these sorts of bugs

[PATCH] avoid assuming arrays have nonzero size (PR 88956)

The enhancement to treat char initializer-lists as STRING_CSTs committed earlier last year introduced an assumption that array elements have a non-zero size. As it turns out, the zero-length array extension that makes it possible to define even multi- dimensional zero-length array objects breaks

Re: Fortran vector math header

On Tue, 22 Jan 2019, Richard Biener wrote: > > Or instead just come up with target specific strings to determine the ABI, > > say i386, x86_64 and x32 for the 3 ABIs on x86, powerpc{,64}{,le} on rs6000 > > etc. > > Yeah, I would even suggest to use a target hook multilib_ABI_active_p > (const

[Bug c++/89001] New: g++ uses wrong mangling for lifetime-extended temporaries

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89001 Bug ID: 89001 Summary: g++ uses wrong mangling for lifetime-extended temporaries Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal

[Bug ipa/88985] [9 Regression] ICE in estimate_edge_devirt_benefit, at ipa-fnsummary.c:2585

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

Re: [RFC] -Weverything

On 1/22/19 11:34 AM, Thomas Koenig wrote: Hi, What would people think about a -Weverything option which turns on every warning there is? I think that could be quite useful in some circumstances, especially to find potential bugs with warnings that people, for some reason or other, found too

[Bug libstdc++/88996] Implement P0439R0 - Make std::memory_order a scoped enumeration.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88996 --- Comment #6 from emsr at gcc dot gnu.org --- Created attachment 45502 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45502=edit New patch, C++20 only, several fixes, no memory_order ops. Retesting.

[Bug libstdc++/88996] Implement P0439R0 - Make std::memory_order a scoped enumeration.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88996 --- Comment #5 from emsr at gcc dot gnu.org --- I was a bit surprised I "needed" these. There are apparently some uses of these. I'll roll back and show you... /home/ed/obj/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/atomic_base.h:104:7:

[Bug gcov-profile/89000] New: gcov --function-summaries says No branches/No calls, only the File summary is correct

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89000 Bug ID: 89000 Summary: gcov --function-summaries says No branches/No calls, only the File summary is correct Product: gcc Version: 8.2.0 Status: UNCONFIRMED

[PATCH] rs6000: Fix PR87604

A libgomp test demonstrated a problem with reduction code in the Power back end (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87064) for little-endian code. The define_insn_and_split at the heart of the problem depends on big-endian data layout, and should have been disabled when

[Bug tree-optimization/88713] Vectorized code slow vs. flang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713 --- Comment #28 from Chris Elrod --- Created attachment 45501 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45501=edit Minimum working example of the rsqrt problem. Can be compiled with: gcc -Ofast -S -march=skylake-avx512

[Bug libstdc++/88999] New: [9 Regression] testcases using in_avail() fail on nios2-elf

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88999 Bug ID: 88999 Summary: [9 Regression] testcases using in_avail() fail on nios2-elf Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal

[Bug c++/88998] New: bad codegen with mmx instructions for unordered_map

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88998 Bug ID: 88998 Summary: bad codegen with mmx instructions for unordered_map Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3

[PATCH] Fix -fsplit-paths documentation

It is enabled at -O3, but the doc currently says -O2. This fixes it. Committing to trunk. Segher 2019-01-22 Segher Boessenkool * doc/invoke.texi (-fsplit-paths): This is enabled by default at -O3. --- gcc/doc/invoke.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[Bug libstdc++/88996] Implement P0439R0 - Make std::memory_order a scoped enumeration.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88996 --- Comment #4 from Jonathan Wakely --- + inline constexpr memory_order + operator&(memory_order __m1, memory_order __m2) + { return memory_order(int(__m1) & int(__m2)); } + + inline constexpr memory_order + operator|(memory_order __m1,

[Bug c++/88997] New: Implicit constructors created with line numbers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88997 Bug ID: 88997 Summary: Implicit constructors created with line numbers Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug libstdc++/88996] Implement P0439R0 - Make std::memory_order a scoped enumeration.

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

[Bug c/88993] GCC 9 -Wformat-overflow=2 should reflect real libc limits

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

Re: [EXT] Re: [Patch 2/4][Aarch64] v2: Implement Aarch64 SIMD ABI

Hi Steve, No we are using aarch64_be-*-* but this is the only one that popped up as a failure which is why I didn't change the others. But now I'm wondering why... I'll check the log file manually tomorrow to be sure. Cheers, Tamar From: Steve Ellcey

Re: [libbacktrace] Use size_t for low_offset/high_offset fields of struct unit

On Tue, Jan 22, 2019 at 2:03 PM Tom de Vries wrote: > > [ was: Re: [PATCH 7/9] [libbacktrace] Handle DW_FORM_GNU_ref_alt ] > On 18-01-19 15:25, Ian Lance Taylor wrote: > > On Thu, Jan 17, 2019 at 6:14 AM Tom de Vries wrote: > >> > >> On 17-01-19 01:35, Ian Lance Taylor wrote: > >>> On Wed, Jan

[Bug tree-optimization/88916] [x86] suboptimal code generated for integer comparisons joined with boolean operators

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88916 --- Comment #3 from Wojciech Mula --- A similar case: ---sign.c--- int different_sign(long a, long b) { return (a >= 0 && b < 0) || (a < 0 && b >= 0); } ---eof-- This is compiled into: different_sign: notq%rdi movq

[Bug d/88989] ICE in resolvePropertiesX, at d/dmd/expression.c:251

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88989 --- Comment #2 from Iain Buclaw --- I thought that the test case looked familiar. https://issues.dlang.org/show_bug.cgi?id=18057 I had fixed this before in the D implementation branch.

[Bug target/88965] powerpc64le vector builtin hits ICE in verify_gimple

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88965 --- Comment #8 from Jakub Jelinek --- Fixed on the trunk so far.

[Bug middle-end/88968] [8 Regression] Stack overflow in gimplify_expr

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88968 Jakub Jelinek changed: What|Removed |Added Summary|[8/9 Regression] Stack |[8 Regression] Stack

RE: North American Farm & Power Show - Attendees Info

Hi, I hope you are the right person to discuss about North American Farm & Power Show Attendees complete info? North American Farm & Power Show of 5,000+ attendees with complete details and verified email addresses. List will be provided for unlimited usage. Interested? Email me

Re: [EXT] Re: [Patch 2/4][Aarch64] v2: Implement Aarch64 SIMD ABI

On Mon, 2019-01-21 at 18:00 +, Tamar Christina wrote: > > > That would need to be aarch64*-*-* to include big-endian. Fixing that here > > and in the other tests is OK under the obvious rule. > > Ah, true, I didn't look at the testcase. I tested the ILP32 case and > committed the fix for

[committed] Fix rs6000_gimple_fold_builtin (PR target/88965)

Hi! As mentioned in the PR, gimple_build can return some trees that aren't valid in MEM_REF's operand (in particular, SSA_NAMEs are allowed there, but only a subset of invariants). The following patch forces the address into a SSA_NAME if it fails the MEM_REF operand's predicate.

[Bug target/88965] powerpc64le vector builtin hits ICE in verify_gimple

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88965 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Tue Jan 22 22:30:44 2019 New Revision: 268166 URL: https://gcc.gnu.org/viewcvs?rev=268166=gcc=rev Log: PR target/88965 * config/rs6000/rs6000.c: Include tree-vrp.h and

[committed] Fix OpenMP atomic gimplification on bitfield with non-integral representative (PR middle-end/88968)

Hi! BIT_INSERT_EXPR is only defined for integral and vector types, so if we have an array type which is bitfield representative if there is no integral type, this fails to gimplify. This still uses BIT_INSERT_EXPR with those types to hold the expressions between c-omp.c and gimplification, but

[Bug middle-end/88968] [8/9 Regression] Stack overflow in gimplify_expr

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88968 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Tue Jan 22 22:28:42 2019 New Revision: 268165 URL: https://gcc.gnu.org/viewcvs?rev=268165=gcc=rev Log: PR middle-end/88968 * gimplify.c (gimplify_omp_atomic): Handle

[Bug target/87064] [9 regression] libgomp.oacc-fortran/reduction-3.f90 fails starting with r263751

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87064 --- Comment #24 from Jakub Jelinek --- Author: jakub Date: Tue Jan 22 22:27:32 2019 New Revision: 268164 URL: https://gcc.gnu.org/viewcvs?rev=268164=gcc=rev Log: PR target/87064 * config/rs6000/vsx.md (*vsx_reduc__v2df_scalar):

[PATCH] Fix gimple-loop-interchange ICE (PR tree-optimization/88964)

Hi! SCEV can analyze not just integral/pointer IVs, but (scalar) float ones as well. Calling build_int_cst on such types results in ICE, build_zero_cst works. Though the loop invariant PHI IVs, if we represent them as using +0.0 step, aren't correct if honoring signed zeros, as + 0.0 will make

[C++ PATCH] Fix switch genericization ICE (PR c++/88984)

Hi! The following testcase ICEs, because we assert that if during parsing we haven't found any break; stmts in SWITCH_STMT_BODY, the switch statement break label will not be used. It is used in this case though, because while during parsing we expect break stmts only from switch body to go to

[C++ PATCH] Change similarly also loop genericization (PR c/44715)

Hi! This patch adjusts genericize_cp_loop similarly to the PR88984 change in genericize_switch_stmt, so that the following testcase now behaves the same in both C and C++, plus adds the testcase and documentation. Bootstrapped/regtested on {x86_64,i686,powerpc64{,le}}-linux, ok for trunk?

[Bug c++/88995] [8/9 Regression] internal compiler error: in lookup_template_class_1, at cp/pt.c:9471

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88995 H.J. Lu changed: What|Removed |Added Known to work||8.2.0 Target Milestone|---

Re: [PR c++/86610] lambda captures in templates

On Wed, Jan 16, 2019 at 2:32 PM Jason Merrill wrote: > > On 1/16/19 4:48 PM, Nathan Sidwell wrote: > > This PR reports a bug where we select a non-const operator function and > > then apply it to a const object. That's happening because the > > expression 'c[0]' is not dependent, so we figure

[Bug libstdc++/88996] Implement P0439R0 - Make std::memory_order a scoped enumeration.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88996 --- Comment #2 from emsr at gcc dot gnu.org --- Still testing BTW.

[Bug libstdc++/88996] Implement P0439R0 - Make std::memory_order a scoped enumeration.

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

[Bug target/88981] [nvptx, openacc, libgomp] How to handle async regions without corresponding wait

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88981 --- Comment #3 from Tom de Vries --- Thomas, any comments to add from OpenACC perspective? What is correct or desirable behaviour? Thanks, - Tom

[libbacktrace] Use size_t for low_offset/high_offset fields of struct unit

[ was: Re: [PATCH 7/9] [libbacktrace] Handle DW_FORM_GNU_ref_alt ] On 18-01-19 15:25, Ian Lance Taylor wrote: > On Thu, Jan 17, 2019 at 6:14 AM Tom de Vries wrote: >> >> On 17-01-19 01:35, Ian Lance Taylor wrote: >>> On Wed, Jan 16, 2019 at 4:17 PM Tom de Vries wrote: this handles

[Bug libstdc++/88996] New: Implement P0439R0 - Make std::memory_order a scoped enumeration.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88996 Bug ID: 88996 Summary: Implement P0439R0 - Make std::memory_order a scoped enumeration. Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: enhancement

Re: testsuite result updates for x86_64-w64-mingw32

> So looking at it again, this seems to be happening during stage3. Yes, I should have realized it a while ago, you don't compile g-exptty.adb for the compiler but only for the runtime... The backtrace seems to show that the abort at libgcc/unwind-dw2.c:1386 is raised: int size =

[Bug c++/88995] New: [8/9 Regression] internal compiler error: in lookup_template_class_1, at cp/pt.c:9471

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88995 Bug ID: 88995 Summary: [8/9 Regression] internal compiler error: in lookup_template_class_1, at cp/pt.c:9471 Product: gcc Version: 8.2.1 Status: UNCONFIRMED

Re: [PATCH 9/9] [libbacktrace] Add printdwarftest_dwz_cmp.sh test-case

On 19-01-19 01:54, Ian Lance Taylor wrote: > On Fri, Jan 18, 2019 at 4:45 PM Tom de Vries wrote: >> >> On 18-01-19 15:23, Ian Lance Taylor wrote: >>> On Thu, Jan 17, 2019 at 5:59 AM Tom de Vries wrote: now that the rest of the patch series has been committed, here's an updated

Re: [PR88579, patch] Calculating power of powers of two

Hi Harald, here's my revised patch for the treatment of (2**e) ** n and (- 2**e) ** n, trying to take into account the bitwidth of the result. I've also extended the testcase to sample different integer kinds. ChangeLogs see below. Note: I don't have commit rights, so please somebody else

[Bug fortran/88579] Calculating power of powers of two

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88579 --- Comment #5 from Thomas Koenig --- Author: tkoenig Date: Tue Jan 22 21:23:57 2019 New Revision: 268163 URL: https://gcc.gnu.org/viewcvs?rev=268163=gcc=rev Log: 2019-01-22 Harald Anlauf PR fortran/88579 * trans-expr.c

Re: [PATCH, d] Committed merge with upstream dmd

On Tue, 22 Jan 2019 at 11:08, Andreas Schwab wrote: > > In file included from ../../gcc/d/d-system.h:23, > from ../../gcc/d/dmd/root/dsystem.h:24, > from ../../gcc/d/dmd/mtype.c:11: > ../../gcc/d/dmd/mtype.c: In member function 'Identifier* >

[Bug fortran/57553] [F08] Valid use of STORAGE_SIZE rejected, bad error message for invalid use

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57553 --- Comment #7 from Harald Anlauf --- Patch submitted for review: https://gcc.gnu.org/ml/fortran/2019-01/msg00201.html

[PR fortran/57553, patch] - bad error message for invalid use of STORAGE_SIZE

The above PR had a partial fix by Tobias Burnus for a valid use of STORAGE_SIZE, but did not properly handle an error situation. The attached simple fix adds a list of allowed intrinsics for use in specification inquiries in F2008+. Testcase by Tobias. Regtested on x86_64-pc-linux-gnu. OK for

Re: C++ PATCH for c++/78244 - narrowing conversion in template not detected, part 2

On Mon, Jan 21, 2019 at 03:14:53PM -0500, Jason Merrill wrote: > On 1/18/19 9:12 AM, Marek Polacek wrote: > > On Thu, Jan 17, 2019 at 04:17:29PM -0500, Jason Merrill wrote: > > > On 1/17/19 2:09 PM, Marek Polacek wrote: > > > > This patch ought to fix the rest of 78244, a missing narrowing warning

[patch, fortran] Move some array packing to front end

Hello world, the attached patch moves the packing / unpacking of arrays to the front end when optimizing, but not for size. Rationale: internal_pack and internal_unpack are opaque to the compiler. This can lead to a lot of information loss for inlining and inter- procedural optimization, and in

Re: [RFC] -Weverything

On Tue, Jan 22, 2019 at 1:35 PM Thomas Koenig wrote: > > What would people think about a -Weverything option which turns on > every warning there is? I tried to use -Weverything on a C++ project with about 350 source files. It was a failed experiment. It created too much noise to be useful.

[Bug gcov-profile/88994] New: [GCOV] encoding (or unicode) error with gcov/gcc9 when generating filename

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88994 Bug ID: 88994 Summary: [GCOV] encoding (or unicode) error with gcov/gcc9 when generating filename Product: gcc Version: 9.0 Status: UNCONFIRMED Severity:

Re: testsuite result updates for x86_64-w64-mingw32

Hi Eric, So looking at it again, this seems to be happening during stage3. And there aren't any special flags being set. Regards, Tamar From: Eric Botcazou Sent: Tuesday, January 22, 2019 12:23 PM To: Tamar Christina Cc: gcc@gcc.gnu.org; Óscar Fuentes;

[Bug c++/87999] Constexpr eval. in static_assert makes string_view comparison non constexpr

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87999 Justin Meyer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

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

On Tue, 22 Jan 2019 at 17:29, Maya Rashish wrote: > > libphobos/libdruntime changes were contributed upstream: > https://github.com/dlang/druntime/pull/2472 > (caveat: pending a change to netbsd/execinfo.d) > > One missing patch is needed for GDC to work. > > gcc/config.gcc (*-*-netbsd*): add

[PATCH] Simplify sinh (x) / cosh (x)

This patch simplifies the expression sinh (x) / cosh (x) to tanh (x). This rule is mathematically valid. There's a slight difference in the result when applying this optimization with x in the interval 0 < x <= 1e-4951. With the optimization, the result using long double is -0 and without the

[Bug c/88993] GCC 9 -Wformat-overflow=2 should reflect real libc limits

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88993 --- Comment #1 from Richard W.M. Jones --- Sorry, forgot the version. It's: gcc-9.0.0-0.3.fc30.x86_64

[Bug c/88993] New: GCC 9 -Wformat-overflow=2 should reflect real libc limits

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88993 Bug ID: 88993 Summary: GCC 9 -Wformat-overflow=2 should reflect real libc limits Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal

[Bug target/88497] Improve Accumulation in Auto-Vectorized Code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88497 --- Comment #7 from kelvin at gcc dot gnu.org --- Here is the original program that motivated my simplified reproducer: extern void first_dummy (); extern void dummy (double sacc, int n); extern void other_dummy (); extern float opt_value;

[PATCH, rtl-optimization]: Fix PR88948, store-motion pass creates unrecognisable insn

Hello! RTL store motion pass transforms: (insn 19 18 20 4 (parallel [ (set (mem/c:SI (symbol_ref:SI ("bar_arg") [flags 0x2] ) [1 bar_arg+0 S4 A32]) (fix:SI (reg:DF 89))) (clobber (scratch:XF)) ]) "stdarg-3.c":63:7 156 {fix_truncsi_i387_fisttp}

[Bug d/88989] ICE in resolvePropertiesX, at d/dmd/expression.c:251

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88989 --- Comment #1 from Iain Buclaw --- Thanks. Out of curiosity, are you fuzz testing?

[Bug rtl-optimization/88347] ICE in begin_move_insn, at sched-ebb.c:175

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88347 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED CC|

Re: [PATCH] Disable *vsx_reduc__v2df_scalar on little endian (PR target/87064)

Hi Jakub, On Tue, Jan 22, 2019 at 05:31:58PM +0100, Jakub Jelinek wrote: > The following patch disables *vsx_reduc__v2df_scalar > define_insn_and_split for little endian, because it both generates > wrong code there (fixable), but also even if fixed, emit much worse code > than when it is not

Re: [RFC] -Weverything

On Tue, 22 Jan 2019 at 18:56, Jonathan Wakely wrote: > > On Tue, 22 Jan 2019 at 18:46, Marc Glisse wrote: > > > > On Tue, 22 Jan 2019, Thomas Koenig wrote: > > > > > Hi, > > > > > > What would people think about a -Weverything option which turns on > > > every warning there is? > > > > > > I

Re: [RFC] -Weverything

On Tue, 22 Jan 2019 at 18:46, Marc Glisse wrote: > > On Tue, 22 Jan 2019, Thomas Koenig wrote: > > > Hi, > > > > What would people think about a -Weverything option which turns on > > every warning there is? > > > > I think that could be quite useful in some circumstances, especially > > to find

Re: [RFC] -Weverything

On Tue, 22 Jan 2019, Thomas Koenig wrote: Hi, What would people think about a -Weverything option which turns on every warning there is? I think that could be quite useful in some circumstances, especially to find potential bugs with warnings that people, for some reason or other, found too

[testsuite, committed] require fpic effective target for tests with -fpic

On nios2, PIC relocations are defined only for the GNU/Linux ABI, so nios2-elf gives a "sorry" with -fpic. That was causing some failures in some new testcases explicitly passing -fpic or -fPIC in dg-options. I've fixed these tests by adding dg-require-effective-target fpic, which is how I've

[Bug target/88963] gcc generates terrible code for vectors of 64+ length which are not natively supported

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963 --- Comment #10 from Devin Hussey --- I also want to add that aarch64 shouldn't even be spilling; it has 32 NEON registers and with 128 byte vectors it should only use 24.

[Bug c++/88984] [9 Regression] ICE in genericize_switch_stmt, at cp/cp-gimplify.c:377

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88984 --- Comment #2 from Jakub Jelinek --- Created attachment 45498 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45498=edit gcc9-pr88984.patch Untested fix.

[RFC] -Weverything

Hi, What would people think about a -Weverything option which turns on every warning there is? I think that could be quite useful in some circumstances, especially to find potential bugs with warnings that people, for some reason or other, found too noisy for -Wextra. The name could be

  1   2   3   4   >