[Bug gcov-profile/89469] [GCOV] wrong frequencies for the first statement in the for(;;) block

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89469 Sunil Kumar changed: What|Removed |Added CC||sunil.kumar3 at ltts dot com --- Comment

[Bug target/97939] ICE on sparc64 with UBsan for "i + 4096" on long: unrecognizable insn during RTL pass: vregs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97939 --- Comment #5 from Dennis Clarke --- Not sure how useful this is but all of the following toss the same ICE : long f(long arg){return arg + 4096;} long f(long arg){return arg - 4096;} long f(long arg){return 4096 + arg;}

[Bug preprocessor/98021] #warning issues redundant diagnostic lines

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed|

[Bug target/98018] Option to force frame pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98018 --- Comment #4 from Richard Biener --- Note always_inline inlining cannot be disabled. Should it disable function splitting and IPA transforms that require thunks? Thus any transform that might add or remove a frame? Even if the thunk might

[Bug target/98018] Option to force frame pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98018 Richard Biener changed: What|Removed |Added Target||x86_64-*-* i?86-*-*

[Bug tree-optimization/22326] promotions (from float to double) are not removed when they should be able to

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326 --- Comment #15 from rguenther at suse dot de --- On Fri, 27 Nov 2020, luoxhu at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326 > > --- Comment #14 from luoxhu at gcc dot gnu.org --- > (In reply to luoxhu from

[Bug tree-optimization/22326] promotions (from float to double) are not removed when they should be able to

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326 --- Comment #14 from luoxhu at gcc dot gnu.org --- (In reply to luoxhu from comment #13) > > 2) mad2.c > > float foo (double x, float y, float z) > { >return ( y * fabs (x) + z ); > } > > > mad2.c.098t.cunrolli: > > foo (double x,

[Bug tree-optimization/22326] promotions (from float to double) are not removed when they should be able to

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326 --- Comment #13 from luoxhu at gcc dot gnu.org --- Tried implementation with backprop, found that this model seems not suitable for double promotion remove with BACK propagation. i.e: 1) mad1.c float foo (float x, float y, float z) {

[Bug preprocessor/98021] #warning issues redundant diagnostic lines

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org

[Bug gcov-profile/85163] [GCOV] A call statement with '==' , '||', and '&&' operators is wrongly marked as executed twice

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85163 Yibiao Yang changed: What|Removed |Added CC||cs.yang.yibiao at gmail dot com ---

[Bug gcov-profile/85163] [GCOV] A call statement with '==' , '||', and '&&' operators is wrongly marked as executed twice

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85163 Sunil Kumar changed: What|Removed |Added CC||sunil.kumar3 at ltts dot com --- Comment

[Bug fortran/98023] ICE: free_expr0(): Bad expr type

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

Re: [PATCH v2 01/31] PR target/58901: reload: Handle SUBREG of MEM with a mode-dependent address

On Thu, 26 Nov 2020, Maciej W. Rozycki wrote: > > > PR target/58901 > > > * reload.c (push_reload): Also reload the inner expression of a > > > SUBREG for pseudos associated with a mode-dependent memory > > > reference. > > > (find_reloads): Force a reload likewise. > > > > Thanks for

[Bug fortran/98023] New: ICE: free_expr0(): Bad expr type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98023 Bug ID: 98023 Summary: ICE: free_expr0(): Bad expr type Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran

[Bug fortran/98022] New: ICE in gfc_assign_data_value, at fortran/data.c:468

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98022 Bug ID: 98022 Summary: ICE in gfc_assign_data_value, at fortran/data.c:468 Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal

Re: [RFC] Increase libstdc++ line length to 100(?) columns

在 2020/11/27 上午7:50, Jonathan Wakely via Gcc 写道: > I've touched on the subject a few times, e.g. > https://gcc.gnu.org/pipermail/gcc/2019-December/230993.html > and https://gcc.gnu.org/pipermail/gcc/2019-December/231013.html > > Libstdc++ code is indented by 2 columns for the enclosing namespace,

[Bug preprocessor/98021] #warning issues redundant diagnostic lines

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021 --- Comment #2 from eggert at cs dot ucla.edu --- (In reply to Andrew Pinski from comment #1) > so you are asking not to show the source file for #warning ? That's the possibility I suggested, yes. Another possibility would be to not show the

Re: [PATCH, rs6000] Add non-relative jump table support on Power Linux

Segher,   Thanks for your comments. I have modified the patch according to your advice and committed. On 24/11/2020 上午 6:25, Segher Boessenkool wrote: Hi! Sorry this took so long. On Thu, Oct 15, 2020 at 04:46:01PM +0800, HAO CHEN GUI wrote: On 29/9/2020 上午 6:46, Segher Boessenkool wrote:

Re: [PATCH 3/4] rs6000: Enable vec_insert for P8 with rs6000_expand_vector_set_var_p8

Hi Segher, Thanks for the approval of [PATCH 1/4] and [PATCH 2/4], what's your opinion of this [PATCH 3/4] for P8, please? xxinsertw only exists since v3.0, so we had to implement by another way. Xionghu On 2020/10/10 16:08, Xionghu Luo wrote: > gcc/ChangeLog: > > 2020-10-10 Xionghu Luo

Re: [committed obvious][arm] Add test that was missing from old commit [PR91816]

On 26/11/2020 09:01, Christophe Lyon wrote: On Wed, 25 Nov 2020 at 14:24, Stam Markianos-Wright via Gcc-patches wrote: Hi all, A while back I submitted GCC10 commit: 44f77a6dea2f312ee1743f3dde465c1b8453ee13 for PR91816. Turns out I was an idiot and forgot to include the test in the

[Bug preprocessor/98021] #warning issues redundant diagnostic lines

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021 --- Comment #1 from Andrew Pinski --- so you are asking not to show the source file for #warning ? I don't see why this warning should be treated as any different from any other warning.

[committed] libstdc++: Define (and use) _GLIBCXX_HAVE_ATOMIC_WAIT

In order to simplify the preprocessor checks for whether __atomic_wait is available, this commit does: -#if defined _GLIBCXX_HAS_GTHREADS || _GLIBCXX_HAVE_LINUX_FUTEX +#ifdef _GLIBCXX_HAVE_ATOMIC_WAIT The original was wrong anyway, as it should have used 'defined' to check

[Bug preprocessor/98021] New: #warning issues redundant diagnostic lines

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021 Bug ID: 98021 Summary: #warning issues redundant diagnostic lines Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[RFC] Increase libstdc++ line length to 100(?) columns

I've touched on the subject a few times, e.g. https://gcc.gnu.org/pipermail/gcc/2019-December/230993.html and https://gcc.gnu.org/pipermail/gcc/2019-December/231013.html Libstdc++ code is indented by 2 columns for the enclosing namespace, usually another two for being in a template, and is full

Re: [committed] libstdc++: Add "futex" and "gthreads" effective-target keywords

On 26/11/20 17:10 +, Jonathan Wakely wrote: On 26/11/20 16:25 +, Jonathan Wakely wrote: +# Return 1 if futex syscall is available +proc check_effective_target_gthreads { } { +return [check_v3_target_gthreads_timed] Oops, I've just noticed the comment is wrong and this calls the

Re: More new AIX errors

On 26/11/20 22:33 +, Jonathan Wakely wrote: On 26/11/20 15:33 -0500, David Edelsohn via Libstdc++ wrote: Hi, Jonathan Thanks for the recent fixes. I still see a few errors that have crept in on AIX. All the same: FAIL: 17_intro/headers/c++2020/all_no_rtti.cc (test for excess errors)

Re: [PATCH] fold-const: Don't consider NaN non-negative [PR97965]

On Thu, Nov 26, 2020 at 01:56:03PM -, Roger Sayle wrote: > --- a/gcc/match.pd > +++ b/gcc/match.pd > @@ -3998,7 +3998,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) > (cmp @0 { build_real (TREE_TYPE (@1), dconst0); })) > /* x != NaN is always true, other ops are always false. */ > (if

[Bug fortran/97589] Segementation fault when allocating coarrays.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589 --- Comment #22 from Thomas Koenig --- Hi Toon, it took some time, but we finally figured out that it is actually a bug in your program that is causing problems. It has (shortened) nxglobal = 72; This sets the coarray nxglobal to 72 on every

gcc-8-20201126 is now available

Snapshot gcc-8-20201126 is now available on https://gcc.gnu.org/pub/gcc/snapshots/8-20201126/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch

Re: [PATCH] libgfortran: Correct FP feature macro checks

On Thu, 26 Nov 2020, Thomas Koenig wrote: > If you want to look at something quite close to the standard, you can > check out https://j3-fortran.org/doc/year/18/18-007r1.pdf . Thanks! Maciej

[Bug fortran/91300] Wrong runtime error message with allocate and errmsg=

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91300 --- Comment #6 from anlauf at gcc dot gnu.org --- Currently the only generated STAT code is 5014 for LIBERROR_ALLOCATION. This is ambiguous. Shall we add another enum value to libgfortran_error_codes, such as LIBERROR_VIRTUAL_MEMORY,

[Bug middle-end/93644] [10/11 Regression] spurious -Wreturn-local-addr with PHI of PHI

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93644 --- Comment #10 from eggert at cs dot ucla.edu --- The generic workaround that Bruno describes ran into problems in Gnulib, as it's enabled only when compiled with -DGCC_LINT, and some users don't compile it that way. So we now have a more

Re: [PATCH] configury : Fix LEB128 support for non-GNU assemblers.

Rainer Orth wrote: maybe this is enough to cover all bases without having to do any version or target checks. (untested) objdump is not available on quite a few Darwin versions with perfectly functional uleb128 - so I don’t want to punt on those for absence of it. We already check for

Re: [PATCH] libgfortran: Correct FP feature macro checks

On Thu, 26 Nov 2020, Thomas Koenig wrote: > > What do you need this information for anyway? > > It's a check if the simplification to constants of these > floating point types is done correctly. Well, GCC's handling of the various FP formats is in the middle end (see gcc/real.c and the

Re: [PATCH] configury : Fix LEB128 support for non-GNU assemblers.

Hi Iain, > maybe this is enough to cover all bases without having to do any version or > target checks. (untested) > > objdump is not available on quite a few Darwin versions with perfectly > functional > uleb128 - so I don’t want to punt on those for absence of it. We already > check for >

[Bug fortran/95342] [9/10/11 Regression] ICE in gfc_match_subroutine, at fortran/decl.c:7913

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

[PATCH fortran/95342] - [9/10/11 Regression] ICE in gfc_match_subroutine, at fortran/decl.c:7913

Dear all, two almost obvious, trivial issues issues with NULL pointer dereferences. Steve found the locations, but his solution changes the error messages as compared to 7/8. I've chosen the conservative way which keeps the documented intent of the source code. Regtested on x86_64-pc-linux-gnu.

Re: [PATCH/RFC] rs6000: Disable HTM for Power10 and later

Hi! On Thu, Nov 26, 2020 at 06:15:04PM +0800, Kewen.Lin wrote: > During previous Power10 testing, I noticed that ISA 3.1 has > dropped TM support. I think we should not generate TM > related instructions for Power10 and later, or no? > > This patch is to turn off HTM support once we know the

Re: [PATCH] configury : Fix LEB128 support for non-GNU assemblers.

Hi folks, Rainer Orth wrote: On Thu, Nov 26, 2020 at 02:26:58PM +0100, Rainer Orth wrote: which shows that the problem is detected in the depths of libbacktrace's DWARF reader. There's something completely off in places, like line numbers well beyond the end of dwarf.c. TBH, I don't

Re: [PATCH] libgfortran: Correct FP feature macro checks

Am 26.11.20 um 19:05 schrieb Maciej W. Rozycki: What do you need this information for anyway? It's a check if the simplification to constants of these floating point types is done correctly. Another interesting thing to look at would be selected_real_kind. selected_real_kind(precision,

Re: [PATCH] libgfortran: Correct FP feature macro checks

Am 26.11.20 um 18:34 schrieb Maciej W. Rozycki: Yeah, I've seen it my Fortran reference (not an official standard though; I don't remember where to get them from and given I don't seem to have a copy, I suspect they are charged for). If you want to look at something quite close to the

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

On Thu, 26 Nov 2020, Maciej W. Rozycki wrote: > > Also, this is amazing work! > > Thanks, appreciated, although I've been doing this kind of things for > some 20 years now (and much longer when it comes to all kinds of computer > programming and fiddling with microprocessors), so it's bread

[PATCH] Introduce can_vec_cmp_compare_p

Bootstrapped and regtested on x86_64-redhat-linux and s390x-redhat-linux. Ok for master? This is the same as dcd2ca63ec5c ("Introduce can_vcond_compare_p function"), but for vec_cmp. The reason it's needed is that since 5d9ade39b872 ("IBM Z: Fix PR97326: Enable fp compares in vec_cmp") and

[PATCH] rtl_dump_bb: fix segfault when reporting internal error

Bootstrapped and regtested on x86_64-redhat-linux and s390x-redhat-linux. Ok for master? During ICE reporting, sometimes rtl_dump_bb is called on partially initialized basic blocks. This produces another ICE, obscuring the original problem. Fix by checking that that basic blocks are

[PATCH] profopt-execute: unset testname_with_flags if create_gcov fails

Bootstrapped and regtested on x86_64-redhat-linux and s390x-redhat-linux. Ok for master? When diffing test results, there sometimes occur spurious "New tests that PASS" / "Old tests that passed, that have disappeared" messages. The reason is that if create_gcov is not installed, then the

[Bug target/98020] New: PPC: mfvsrwz+extsw not merge to mtvsrwa

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98020 Bug ID: 98020 Summary: PPC: mfvsrwz+extsw not merge to mtvsrwa Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target

[Bug rtl-optimization/97459] __uint128_t remainder for division by 3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459 --- Comment #18 from Jakub Jelinek --- Created attachment 49633 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49633=edit gcc11-pr97459-wip.patch Completely untested patch, so far only for double-word unsigned modulo.

[r11-5398 Regression] FAIL: gcc.target/i386/pr96906-1.c scan-assembler-times \tvpminuw[^\n\r]*ymm 2 on Linux/x86_64

On Linux/x86_64, 32b0abb24b8702ec9954448739682ace6fa5ccf5 is the first bad commit commit 32b0abb24b8702ec9954448739682ace6fa5ccf5 Author: Jakub Jelinek Date: Thu Nov 26 08:44:15 2020 +0100 i386: Optimize psubusw compared to 0 into pminuw compared to op0 [PR96906] caused FAIL:

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

On Wed, 25 Nov 2020, Joseph Myers wrote: > > For the other pieces that are missing perhaps my work I did many years > > ago to port glibc 2.4 (the last one I was able to cook up without NPTL), > > and specifically libm within, to the never-upstreamed VAX/Linux target > > might be useful to

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

On Thu, Nov 26, 2020 at 06:01:31PM +, Maciej W. Rozycki wrote: > The VAX/NetBSD port however does use hardware FP in their libm as far as > I can tell, so I guess it would be reasonable for libgfortran to do so as > well. I haven't checked how correct their implementation actually is, but

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

On Thu, 26 Nov 2020, Ian Lance Taylor wrote: > I just want to note that as far as I can tell this is not a bug in the > Go frontend code. Ack. I thought it might be the case as the file in question hasn't changed for a while now, so it wasn't a Go frontend change that triggered the warning.

Re: [PATCH] libgfortran: Correct FP feature macro checks

On Thu, 26 Nov 2020, Thomas Koenig wrote: > On my (IEEE) box, this prints > > r = 3.402823e+38 d = 1.797693e+308 i = 4 > > so if you have a working printf (or some other way to display > floating-point-variables) for C, you can examine the > values. This prints: r = 1.701412e+38 d =

Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

On Wed, 25 Nov 2020, co...@sdf.org wrote: > I've been building successfully with setting: > export ac_cv_func_freelocale=no > export ac_cv_func_newlocale=no > export ac_cv_func_uselocale=no It's a workaround really, though surely one that works; I've done things like this myself regularly,

[Bug tree-optimization/97953] [8/9/10 Regression] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #22 from Chris Clayton --- I've applied Richard's patch to the 20201122 snapshot and can happily report that the build now completes successfully. My thanks to Martin and Richard.

Re: [PATCH] libgfortran: Correct FP feature macro checks

On Wed, 25 Nov 2020, Tobias Burnus wrote: > > Well, it does not link, for the somewhat unsurprising reason of a missing > > libgfortran runtime. I have modified the program with whatever little > > Fortran skills I gained a while ago to get something that can be parseable > > for a human being

[Bug fortran/98016] Host association problem

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98016 --- Comment #5 from kargl at gcc dot gnu.org --- Index: gcc/gcc/fortran/expr.c === --- gcc/gcc/fortran/expr.c (revision 280157) +++ gcc/gcc/fortran/expr.c (working copy) @@

Re: [PATCH] libgfortran: Verify the presence of all functions for POSIX 2008 locale

On Wed, 25 Nov 2020, Tobias Burnus wrote: > Patch looks good to me. This has now been committed, thank you for your review. > PS: Are there still remaining issues to be solved? Or does libgfortran > now build? Sadly this is not enough for VAX/NetBSD, but as I gather from a comment in the

[PATCH] aarch64: Introduce --param=aarch64-autovec-preference to select autovec preference in backend

Hi all, This is a patch that introduces the aarch64-autovec-preference that can take values from 0 - 4, 0 being the default. It can be used to override the autovectorisation preferences in the backend: 0 - use default scheme 1 - only use Advanced SIMD 2 - only use SVE 3 - use Advanced SIMD and

Re: [PATCH] libgfortran: Correct FP feature macro checks

On Wed, 25 Nov 2020, Tobias Burnus wrote: > LGTM. Applied now, thank you for your review. Maciej

Re: [PATCH v2 01/31] PR target/58901: reload: Handle SUBREG of MEM with a mode-dependent address

On Tue, 24 Nov 2020, Eric Botcazou wrote: > > First posted at: . > > > > 2020-11-24 Matt Thomas > > Maciej W. Rozycki > > > > gcc/ > > PR target/58901 > > * reload.c (push_reload): Also reload the inner expression of a >

[Bug c++/98019] Concepts: compound requirement expression from 'requires' expression is considered discarded-value expression for [[nodiscard]], false positive warning emitted

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98019 --- Comment #1 from Egor Suvorov --- Also, I would expect a warning in this case: requires { foo(); // Looks like a statement. }; but not this: requires { static_cast(foo()); }; or this: requires { { foo() }; // expression

Re: [committed] libstdc++: Add "futex" and "gthreads" effective-target keywords

On 26/11/20 16:25 +, Jonathan Wakely wrote: +# Return 1 if futex syscall is available +proc check_effective_target_gthreads { } { +return [check_v3_target_gthreads_timed] Oops, I've just noticed the comment is wrong and this calls the wrong proc. It should be check_v3_target_gthreads

[Bug d/98019] New: Concepts: compound requirement expression from 'requires' expression is considered discarded-value expression for [[nodiscard]], false positive warning emitted

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98019 Bug ID: 98019 Summary: Concepts: compound requirement expression from 'requires' expression is considered discarded-value expression for [[nodiscard]], false positive warning

Re: [07/23] Add a class that multiplexes two pointer types

Martin Sebor writes: > I do have one concern: the tendency to prioritize efficiency > over safety (this can be said about most GCC code). Specifically > in this class, the address bit twiddling makes me uneasy. I don't > think the object model in either language (certainly not C but > I don't

Re: [PATCH] arm: [testsuite] fix lob tests for -mfloat-abi=hard

"Richard Earnshaw (lists)" writes: > On 26/11/2020 13:53, Andrea Corallo via Gcc-patches wrote: >> Hi all, >> >> I'd like to submit the following simple patch to clean some Low Loop >> Overhead test failing on hard float configurations. >> >> lob2.c and lob5.c are failing with:

Re: [PATCH] clean up more -Wformat-diag (PR 94982)

H.J. Lu via Gcc-patches wrote: On Tue, Nov 24, 2020 at 5:13 PM Martin Sebor via Gcc-patches wrote: The attached patch cleans up most remaining -Wformat-diag instances in an x86_64-build. I tried to minimize using #pragma diagnostic so I tweaked the code instead. A preferable solution might

[PATCH] doc: Fix description of dg-require-effective-target

The optional target selector for the dg-require-effective-target directive needs to be { target selector } not just { selector } as currently documented. gcc/ChangeLog: * doc/sourcebuild.texi (Directives): Fix description of dg-require-effective-target to include "target" in

Re: [PATCH] libstdc++: Add C++2a synchronization support

On 25/11/20 18:39 +, Jonathan Wakely wrote: On 25/11/20 10:35 +, Jonathan Wakely wrote: I've pushed that as ad9cbcee543ecccd79fa49dafcd925532d2ce210 but there are still other FAILs to be fixed. I think the other FAILs are due to a race condition in the tests, fixed by this patch.

[committed] libstdc++: Set dg-timeout-factor for some slow tests

These tests are very, very slow to compile. If the testsuite is run with a low tool_timeout value they are likely to fail. By adding a multiplication factor to those tests, it's still possible to use a low timeout without spurious failures. libstdc++-v3/ChangeLog: *

[committed] libstdc++: Allow dejagnu tool_timeout to be overridden

This allows the default timeout for libstdc++ tests to be set by the user, either in ~/.dejagnurc or a site.exp file that $DEJAGNU names. libstdc++-v3/ChangeLog: * testsuite/lib/libstdc++.exp (libstdc++_init): Only set tool_timeout if it hasn't been set by the user already.

[committed] libstdc++: Add "futex" and "gthreads" effective-target keywords

This adds a new "futex" effective-target keyword that can be used to selectively enable/disable tests based on _GLIBCXX_HAVE_LINUX_FUTEX, instead of checking for that macro in the code. It also adds "gthreads" as another one, to make the result of the dg-require-gthreads directive usable in

[Bug libstdc++/97936] [11 Regression] 30_threads/latch/3.cc hangs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97936 --- Comment #11 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:10522ed1089277e2aa6cd708205aa5c730179cf0 commit r11-5447-g10522ed1089277e2aa6cd708205aa5c730179cf0 Author: Jonathan Wakely

[Bug target/98018] Option to force frame pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98018 --- Comment #3 from H.J. Lu --- -fforce-frame-pointer should disable 1. Tail call. 2. Inlining. Should inlining be totally disabled? Which inlining should be disabled? What do do with static inline and extern inline? 3. Frame pointer

Re: [07/23] Add a class that multiplexes two pointer types

Jeff Law writes: > On 11/13/20 1:14 AM, Richard Sandiford via Gcc-patches wrote: >> This patch adds a pointer_mux class that provides similar >> functionality to: >> >> union { T1 *a; T2 *b; }; >> ... >> bool is_b_rather_than_a; >> >> except that the is_b_rather_than_a tag is stored

[Bug target/98018] Option to force frame pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98018 --- Comment #2 from Uroš Bizjak --- I vote for -fforce-frame-pointer.

Re: [00/23] Make fwprop use an on-the-side RTL SSA representation

Thanks for the reviews. Jeff Law via Gcc-patches writes: > On 11/13/20 1:10 AM, Richard Sandiford via Gcc-patches wrote: >> Just after GCC 10 stage 1 closed (oops), I posted a patch to add a new >> combine pass. One of its main aims was to allow instructions to move >> around where necessary in

[Bug target/98018] Option to force frame pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98018 --- Comment #1 from H.J. Lu --- Something like, -fneed-frame-pointer, -fforce-frame-pointer or -fgenerate-frame-pointer.

[SPARC] Fix PR target/96607

After 15 years trying to find out what can go into the delay slot of the call to __tls_get_addr with the Solaris linker, it's time to concede defeat. As Vita says in the PR: "Solaris linker doesn't expect anything in the branch delay slot of the above call instruction. An optimized sequence

Re: [PATCH] clean up more -Wformat-diag (PR 94982)

On Tue, Nov 24, 2020 at 5:13 PM Martin Sebor via Gcc-patches wrote: > > The attached patch cleans up most remaining -Wformat-diag instances > in an x86_64-build. I tried to minimize using #pragma diagnostic > so I tweaked the code instead. A preferable solution might be to > introduce a new

[Bug target/96607] GCC feeds SPARC/Solaris linker with unrecognized TLS sequences

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96607 --- Comment #9 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:294e72e9acbd0ff15ef5b18895de62cc173464ca commit r11-5445-g294e72e9acbd0ff15ef5b18895de62cc173464ca Author: Eric Botcazou Date:

[Bug target/97902] x86 frame pointer missing with -fno-omit-frame-pointer (-mno-omit-leaf-frame-pointer)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97902 --- Comment #15 from Jan Smets --- Thanks. See 98018.

[Bug target/98018] New: Option to force frame pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98018 Bug ID: 98018 Summary: Option to force frame pointer Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target

[Bug tree-optimization/97997] Missed optimization: Multiply of extended integer cannot overflow

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97997 --- Comment #5 from Matthijs Kooijman --- Awesome, thanks for the quick response and fix!

[Bug target/97902] x86 frame pointer missing with -fno-omit-frame-pointer (-mno-omit-leaf-frame-pointer)

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

Re: [PATCH 1/7] arm: Auto-vectorization for MVE: vand

Hi Andre, Thanks for the quick feedback. On Wed, 25 Nov 2020 at 18:17, Andre Simoes Dias Vieira wrote: > > Hi Christophe, > > Thanks for these! See some inline comments. > > On 25/11/2020 13:54, Christophe Lyon via Gcc-patches wrote: > > This patch enables MVE vandq instructions for

[Bug target/97902] x86 frame pointer missing with -fno-omit-frame-pointer (-mno-omit-leaf-frame-pointer)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97902 --- Comment #13 from Jan Smets --- H.J, There are still some very basic backtrace implementations that rely on frame pointers. (No DWARF based things or any other forms of 'assistance'). A missing stack frame means the "previous" function is not

[Bug tree-optimization/97997] Missed optimization: Multiply of extended integer cannot overflow

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

[Bug tree-optimization/97997] Missed optimization: Multiply of extended integer cannot overflow

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97997 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a3ebc13492ff238873f2c6a7a3e51abefec1d052 commit r11-5444-ga3ebc13492ff238873f2c6a7a3e51abefec1d052 Author: Jakub Jelinek Date:

[Bug tree-optimization/97953] [8/9/10 Regression] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 Richard Biener changed: What|Removed |Added Known to work||11.0 Priority|P3

[Bug tree-optimization/98015] [11 regression] ICE in gimple_expand_vec_cond_expr since g:fddc7f0080f1f056c4d145451608ebd3e807422a

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

[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #20 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:c76b3f9e83353a4cd437ca137c1fb835c9b5c21f commit r11-5443-gc76b3f9e83353a4cd437ca137c1fb835c9b5c21f Author: Richard Biener Date:

[PATCH] tree-optimization/97953 - fix bougs range recorded by EVRP

EVRP records some ranges from asserts into SSA_NAME_RANGE_INFO but fails to assert that the condition the range is derived from is always true after the SSA names definition. The patch implements the simplest post-dominance check, basic-block equality. Bootstrapped and tested on

[PATCH] tree-optimization/98015 - fix VEC_COND_EXPR lowering condition

This fixes the condition to match the comment and only lower VECTOR_BOOLEAN_TYPE_P VEC_COND_EXPRs. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. 2020-11-26 Richard Biener * gimple-isel.c (gimple_expand_vec_cond_expr): Only lower VECTOR_BOOLEAN_TYPE_P

[Bug fortran/98016] Host association problem

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98016 --- Comment #4 from Dominique d'Humieres --- I confirm that the test in comment O compiles without any error. However if I replace real y(n) with dimension y(n) I get the error Error: Variable 'n' cannot appear in the expression at

Re: [PATCH] gimple-fold: Fix another __builtin_clear_padding ICE

On Thu, 26 Nov 2020, Jakub Jelinek wrote: > Hi! > > When playing with __builtin_bit_cast, I have noticed __builtin_clear_padding > ICE on the G class below. The artificial field with D type has offset 0 > and size 8 bytes, but the following artificial field with E type has offset > 0 and size

[PATCH] c++: v3: Add __builtin_bit_cast to implement std::bit_cast [PR93121]

On Wed, Nov 25, 2020 at 07:52:44PM -0500, Jason Merrill wrote: > > > I think you want to check DECL_PADDING_P here; the C and C++ front ends > > > set > > > it on unnamed bit-fields, and that's what is_empty_type looks at. > > > > Ok, changed in my copy. I'll also post a patch for > >

Re: [PATCH] configury : Fix LEB128 support for non-GNU assemblers.

Hi Jakub, > On Thu, Nov 26, 2020 at 02:26:58PM +0100, Rainer Orth wrote: >> which shows that the problem is detected in the depths of >> libbacktrace's DWARF reader. There's something completely off in >> places, like line numbers well beyond the end of dwarf.c. >> >> TBH, I don't

[PATCH] gimple-fold: Fix another __builtin_clear_padding ICE

Hi! When playing with __builtin_bit_cast, I have noticed __builtin_clear_padding ICE on the G class below. The artificial field with D type has offset 0 and size 8 bytes, but the following artificial field with E type has offset 0 and size 0, so it triggers the asserts that we don't move current

Re: [PATCH] configury : Fix LEB128 support for non-GNU assemblers.

On 26/11/2020 14:48, Iain Sandoe wrote: Rainer Orth wrote: unfortunately, Solaris/SPARC results are miserable: So without further investigation, we cannot use the leb128 directives with Solaris/SPARC as. I think Andrew was running GCN (not sure of the results there) - but, I suppose

[Bug fortran/98016] Host association problem

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98016 --- Comment #3 from Jürgen Reuter --- Ah wait, the version I committed works, the original version from c.l.f. still fails, because it uses implicit typing, so not real :: y(3) and real :: y(n), but dimension y(3) $ cat clf_20201126.f90

  1   2   3   >