Re: [PATCH] AIX struct alignment (PR 99557)

On Wed, Mar 24, 2021 at 4:23 PM David Edelsohn wrote: > > On Wed, Mar 24, 2021 at 3:51 AM Richard Biener > wrote: > > > > On Wed, Mar 24, 2021 at 3:03 AM David Edelsohn wrote: > > > > > > On Mon, Mar 22, 2021 at 4:10 AM Richard Biener > > > wrote: > > > > > > > Oh, and for a type like > > > >

Re: [Patch][wwwdocs] gcc-11/changes.html – GCN – Mention gfx908

Hi Gerald, thanks for the comments – I added id=amdgcn (matching GCC 11) and the present-perfect tense – and I fixed the gfx908 string-typo ... https://gcc.gnu.org/gcc-11/changes.html#amdgcn Tobias On 24.03.21 23:09, Gerald Pfeifer wrote: On Wed, 24 Mar 2021, Tobias Burnus wrote: Hi Andrew,

Re: [Patch] OpenMP: Handle order(concurrent) clause in gfortran

Hi! On 2020-07-29T18:30:16+0200, Tobias Burnus wrote: > Adds 'order(concurrent)'. OpenMP 5.0 also permits it > for 'loop' but gfortran does not yet support 'loop'. > > (That the argument is passed on to the ME can be > seen by the testcases as the errors are emitted > by the ME.) This later got

Re: Patch ping

On Wed, 24 Mar 2021, Martin Sebor wrote: > On 3/24/21 10:40 AM, Jakub Jelinek wrote: > > On Wed, Mar 24, 2021 at 09:45:31AM -0600, Martin Sebor via Gcc-patches > > wrote: > >> E.g., OEP_IGNORE_MEMBER_OFFSET or OEP_SAME_MEMBER_OFFSET (for > >> the converse of the first) or something like that, but

Re: require et random_device for cons token test

On Mar 24, 2021, Jonathan Wakely wrote: > Does vxworks provide any platform-specific source of randomness, like > Linux getrandom(2) or BSD arc4random(3) or Windows rand_s? If yes, we > should add support for that (in the next stage 1). There appears to be a randNumGenCtl syscall that appears

[PATCH] c++, v2: Fix ICE with nsdmi [PR99705]

On Tue, Mar 23, 2021 at 04:51:52PM -0400, Jason Merrill via Gcc-patches wrote: > > + if (TREE_CODE (*tp) == DECL_EXPR > > + && VAR_P (DECL_EXPR_DECL (*tp)) > > + && DECL_ARTIFICIAL (DECL_EXPR_DECL (*tp)) > > + && !TREE_STATIC (DECL_EXPR_DECL (*tp)) > > + && DECL_CONTEXT

Re: [PATCH, OpenMP 5.0] More implementation of the requires directive

Hi! On 2021-01-13T23:07:44+0800, Chung-Lin Tang wrote: > this patch provides more implementation of the requires directive, basically: > > (1) The collection of the reverse_offload, unified_address, and > unified_shared_memory > clauses into a .gnu.gomp_requires section > > (2) libgomp checking

Re: [PATCH] x86: Skip ISA check for always_inline in system headers

On Wed, Mar 24, 2021 at 6:23 PM H.J. Lu wrote: > > For always_inline in system headers, we don't know if caller's ISAs are > compatible with callee's ISAs until much later. Skip ISA check for > always_inline in system headers if caller has target attribute. > > gcc/ > > PR target/98209 >

[PATCH] tree-optimization/99746 - avoid confusing hybrid code

This avoids confusing the hybrid vectorization code with SLP patterns by not marking SLP pattern covered stmts as patterns (they are marked as SLP patterns already). This means that loop vectorization will vectorize the scalar stmt rather than the SLP pattern stmt (which it can't anyway).

Re: require et random_device for cons token test

On Mar 24, 2021, Jonathan Wakely wrote: > This works for me on x86_64-linux and powerpc64le-linux, and also on > x86_64-linux when I kluge the config macros so that the new code path > gets used. Does this work for VxWorks? Thanks. I (trivially) backported it to apply on our gcc-10 tree, and

[PATCH] c++: Diagnose bare parameter packs in bitfield widths [PR99745]

Hi! The following invalid tests ICE because we don't diagnose (and drop) bare parameter packs in bitfield widths. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2021-03-24 Jakub Jelinek PR c++/99745 * decl2.c (grokbitfield): Diagnose

Re: require et random_device for cons token test

On Mar 24, 2021, Jonathan Wakely wrote: > diff --git a/libstdc++-v3/testsuite/util/testsuite_random.h > b/libstdc++-v3/testsuite/util/testsuite_random.h > index 0b670bfb771..c8323078492 100644 > --- a/libstdc++-v3/testsuite/util/testsuite_random.h > +++

[PATCH] tree-optimization/96109 - fix vectorizer alignment computation

This fixes bogus alignment computation for negative strided grouped accesses which we now can vectorize but only through SLP. The biasing for negative strided non-grouped accesses as supported via VMAT_CONTIGUOUS_REVERSE does not apply there and instead causes alignment analysis to compute wrong

Re: [WIP] Re: [PATCH] openmp: Fix intermittent hanging of task-detach-6 libgomp tests [PR98738]

Hi! On 2021-03-11T17:52:55+0100, I wrote: > On 2021-02-23T22:52:38+0100, Jakub Jelinek via Gcc-patches > wrote: >> On Tue, Feb 23, 2021 at 09:43:51PM +, Kwok Cheung Yeung wrote: >>> On 19/02/2021 7:12 pm, Kwok Cheung Yeung wrote: >>> > I have included the current state of my patch. All

Re: [PATCH] x86: Skip ISA check for always_inline in system headers

On Thu, Mar 25, 2021 at 02:21:21PM +0100, Richard Biener wrote: > Err, but _which_ mismatches do you ignore with such new attribute? We'd need to define it. > If I have __rdtsc and compile that into a -mno-rdtsc unit/function would > that be OK? There is no -mno-rdtsc or -mrdtsc, rdtsc insn is

Re: [PATCH] slp tree vectorizer: Re-calculate vectorization factor in the case of invalid choices [PR96974]

On 24/03/2021 13:46, Richard Biener wrote: On Wed, 24 Mar 2021, Stam Markianos-Wright wrote: Hi all, This patch resolves bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96974 This is achieved by forcing a re-calculation of *stmt_vectype_out if an incompatible combination of

Re: require et random_device for cons token test

On 25/03/21 08:00 -0300, Alexandre Oliva wrote: On Mar 24, 2021, Jonathan Wakely wrote: Does vxworks provide any platform-specific source of randomness, like Linux getrandom(2) or BSD arc4random(3) or Windows rand_s? If yes, we should add support for that (in the next stage 1). There

New French PO file for 'gcc' (version 11.1-b20210321)

Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the French team of translators. The file is available at: https://translationproject.org/latest/gcc/fr.po (This file,

Re: [PATCH] tree-optimization/96109 - fix vectorizer alignment computation

On Thu, 25 Mar 2021, Richard Biener wrote: > This fixes bogus alignment computation for negative strided > grouped accesses which we now can vectorize but only through SLP. > The biasing for negative strided non-grouped accesses as supported > via VMAT_CONTIGUOUS_REVERSE does not apply there and

Re: [PATCH] x86: Skip ISA check for always_inline in system headers

On Wed, Mar 24, 2021 at 10:23:44AM -0700, H.J. Lu via Gcc-patches wrote: > For always_inline in system headers, we don't know if caller's ISAs are > compatible with callee's ISAs until much later. Skip ISA check for > always_inline in system headers if caller has target attribute. > > gcc/ > >

Re: [PATCH] x86: Skip ISA check for always_inline in system headers

On Thu, Mar 25, 2021 at 1:54 PM Jakub Jelinek wrote: > > On Wed, Mar 24, 2021 at 10:23:44AM -0700, H.J. Lu via Gcc-patches wrote: > > For always_inline in system headers, we don't know if caller's ISAs are > > compatible with callee's ISAs until much later. Skip ISA check for > > always_inline

Re: [PATCH] tree-optimization/96109 - fix vectorizer alignment computation

Richard Biener writes: > Whether a vector DR is aligned or not depends on the vectorization > scheme but at the point of computing peeling for alignment > that has not been determined so we try to work with scalar DRs. > > For the uses by vectorizable_load/store I pondered to pass > the

Re: [PATCH] x86: Skip ISA check for always_inline in system headers

On Thu, Mar 25, 2021 at 6:13 AM Jakub Jelinek wrote: > > On Thu, Mar 25, 2021 at 02:02:16PM +0100, Uros Bizjak wrote: > > > Aren't *intrin.h system headers too? > > > > I was under impression that they are not, since they live outside of > > /usr/include. > > Yes, they aren't in /usr/include, but

Re: [PATCH, V3] Require GLIBC 2.32 for Decimal/_Float128 conversions.

Hi! On Mon, Mar 22, 2021 at 02:06:27PM -0300, Matheus Castanho wrote: > > Cross builds on Advance Toolchain have been broken since GCC commit > '781183595ac Add conversions between _Float128 and Decimal' [0]. This is a problem in AT's build system. See

Re: [PATCH] Complete __gnu_debug::basic_string

On 24/03/21 22:48 +0100, François Dumont wrote: On 23/03/21 4:42 pm, Jonathan Wakely wrote: On 20/03/21 22:32 +0100, François Dumont wrote: Following your feedback here is the simplified version. I grouped it with the patch I submitted before. On 19/03/21 8:41 pm, Jonathan Wakely wrote: I

Re: [PATCH] x86: Skip ISA check for always_inline in system headers

On Thu, Mar 25, 2021 at 02:02:16PM +0100, Uros Bizjak wrote: > > Aren't *intrin.h system headers too? > > I was under impression that they are not, since they live outside of > /usr/include. Yes, they aren't in /usr/include, but they are still system headers. If I preprocess something that

Re: [PATCH] x86: Skip ISA check for always_inline in system headers

On Thu, Mar 25, 2021 at 2:25 PM H.J. Lu via Gcc-patches wrote: > > On Thu, Mar 25, 2021 at 6:13 AM Jakub Jelinek wrote: > > > > On Thu, Mar 25, 2021 at 02:02:16PM +0100, Uros Bizjak wrote: > > > > Aren't *intrin.h system headers too? > > > > > > I was under impression that they are not, since

Re: [PATCH] slp tree vectorizer: Re-calculate vectorization factor in the case of invalid choices [PR96974]

On Thu, 25 Mar 2021, Stam Markianos-Wright wrote: > On 24/03/2021 13:46, Richard Biener wrote: > > On Wed, 24 Mar 2021, Stam Markianos-Wright wrote: > > > >> Hi all, > >> > >> This patch resolves bug: > >> > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96974 > >> > >> This is achieved by

Re: [PATCH] x86: Skip ISA check for always_inline in system headers

On Thu, Mar 25, 2021 at 2:39 PM Jakub Jelinek wrote: > > On Thu, Mar 25, 2021 at 02:21:21PM +0100, Richard Biener wrote: > > Err, but _which_ mismatches do you ignore with such new attribute? > > We'd need to define it. > > > If I have __rdtsc and compile that into a -mno-rdtsc unit/function

Re: [PATCH] x86: Skip ISA check for always_inline in system headers

On Thu, Mar 25, 2021 at 03:24:38PM +0100, Richard Biener wrote: > Well, but in all of those cases the program was invalid (and is diagnosed). > So it simply means "always inline". That we abuse the always-inline > (error) diagnostic to tell users about possible problems (and in HJs case > and the

Re: require et random_device for cons token test

On 25/03/21 08:03 -0300, Alexandre Oliva wrote: On Mar 24, 2021, Jonathan Wakely wrote: diff --git a/libstdc++-v3/testsuite/util/testsuite_random.h b/libstdc++-v3/testsuite/util/testsuite_random.h index 0b670bfb771..c8323078492 100644 --- a/libstdc++-v3/testsuite/util/testsuite_random.h +++

Re: [PATCH] tree-optimization/96109 - fix vectorizer alignment computation

On Thu, 25 Mar 2021, Richard Sandiford wrote: > Richard Biener writes: > > Whether a vector DR is aligned or not depends on the vectorization > > scheme but at the point of computing peeling for alignment > > that has not been determined so we try to work with scalar DRs. > > > > For the uses by

Re: [PATCH] x86: Skip ISA check for always_inline in system headers

On Thu, Mar 25, 2021 at 7:59 AM Uros Bizjak wrote: > > On Wed, Mar 24, 2021 at 6:23 PM H.J. Lu wrote: > > > > For always_inline in system headers, we don't know if caller's ISAs are > > compatible with callee's ISAs until much later. Skip ISA check for > > always_inline in system headers if

Re: require et random_device for cons token test

On 25/03/21 07:17 -0300, Alexandre Oliva wrote: On Mar 24, 2021, Jonathan Wakely wrote: This works for me on x86_64-linux and powerpc64le-linux, and also on x86_64-linux when I kluge the config macros so that the new code path gets used. Does this work for VxWorks? Thanks. I (trivially)

Re: [PATCH] x86: Skip ISA check for always_inline in system headers

On Thu, Mar 25, 2021 at 2:14 PM Jakub Jelinek via Gcc-patches wrote: > > On Thu, Mar 25, 2021 at 02:02:16PM +0100, Uros Bizjak wrote: > > > Aren't *intrin.h system headers too? > > > > I was under impression that they are not, since they live outside of > > /usr/include. > > Yes, they aren't in

Re: [PATCH 1/4] Remove build dependence on HSA run-time

Hi! On 2021-01-19T12:37:56+0100, Martin Jambor wrote: > On Thu, Jan 14 2021, Thomas Schwinge wrote: >> I'm raising here an issue with HSA libgomp plugin code changes from a >> while ago. While HSA is now no longer relevant for GCC master branch, >> the same code has also been copied into the

Re: [PATCH, V3] Require GLIBC 2.32 for Decimal/_Float128 conversions.

Hi Mike, On Thu, Mar 04, 2021 at 04:01:35PM -0500, Michael Meissner wrote: > [PATCH V3] Require GLIBC 2.32 for Decimal/_Float128 conversions. > > In the patch that I applied on March 2nd, I had code to provide support for > Decimal/_Float128 conversions if the user did not use at least GLIBC

Re: [PATCH] x86: Skip ISA check for always_inline in system headers

On Thu, Mar 25, 2021 at 3:32 PM Jakub Jelinek wrote: > > On Thu, Mar 25, 2021 at 03:24:38PM +0100, Richard Biener wrote: > > Well, but in all of those cases the program was invalid (and is diagnosed). > > So it simply means "always inline". That we abuse the always-inline > > (error) diagnostic

Re: [PATCH 1/2] openacc: Fix lowering for derived-type mappings through array elements

Hi! On 2021-02-12T07:46:48-0800, Julian Brown wrote: > --- /dev/null > +++ b/libgomp/testsuite/libgomp.oacc-fortran/derivedtypes-arrays-1.f90 > @@ -0,0 +1,109 @@ > +[...] > +!$acc serial present(var3%t2(5)%t1%arr1) > +var3%t2(5)%t1%arr1(:,:) = 6 > +!$acc end serial > +[...] I've pushed

Re: [PATCH] x86: Skip ISA check for always_inline in system headers

On Thu, Mar 25, 2021 at 2:03 PM Uros Bizjak via Gcc-patches wrote: > > On Thu, Mar 25, 2021 at 1:54 PM Jakub Jelinek wrote: > > > > On Wed, Mar 24, 2021 at 10:23:44AM -0700, H.J. Lu via Gcc-patches wrote: > > > For always_inline in system headers, we don't know if caller's ISAs are > > >

Re: [PATCH] Complete __gnu_debug::basic_string

On 25/03/21 13:05 +, Jonathan Wakely wrote: On 24/03/21 22:48 +0100, François Dumont wrote: I still need to find out why, when running test on __gnu_debug::basic_string after the std::basic_string one, the generate(sz) call always returns sz. The "random" generator will always return the

Re: [PATCH] x86: Skip ISA check for always_inline in system headers

On Thu, Mar 25, 2021 at 03:40:51PM +0100, Richard Biener wrote: > I think the "proper" way to do this is to have 'open' above end up > refering to the out-of-line 'open' in the DSO, _not_ to emit the > fortification wrapper out-of-line. But then, yes, it shouldn't > be always-inline then. It

Re: [PATCH] Complete __gnu_debug::basic_string

On 25/03/21 14:48 +, Jonathan Wakely wrote: On 25/03/21 13:05 +, Jonathan Wakely wrote: On 24/03/21 22:48 +0100, François Dumont wrote: I still need to find out why, when running test on __gnu_debug::basic_string after the std::basic_string one, the generate(sz) call always returns

Re: [PATCH] Complete __gnu_debug::basic_string

On 25/03/21 18:45 +0100, François Dumont via Libstdc++ wrote: On 25/03/21 4:29 pm, Jonathan Wakely wrote: On 25/03/21 14:48 +, Jonathan Wakely wrote: On 25/03/21 13:05 +, Jonathan Wakely wrote: On 24/03/21 22:48 +0100, François Dumont wrote: I still need to find out why, when running

Re: [PATCH] Complete __gnu_debug::basic_string

On 25/03/21 4:29 pm, Jonathan Wakely wrote: On 25/03/21 14:48 +, Jonathan Wakely wrote: On 25/03/21 13:05 +, Jonathan Wakely wrote: On 24/03/21 22:48 +0100, François Dumont wrote: I still need to find out why, when running test on __gnu_debug::basic_string after the std::basic_string

Re: [PATCH] lra: Canonicalize mult to shift in address reloads

"Maciej W. Rozycki" writes: > On Wed, 26 Aug 2020, Vladimir Makarov via Gcc-patches wrote: > >> On 2020-08-26 5:06 a.m., Richard Sandiford wrote: >> > >> > I don't think we should we restrict this to (plus (mult X Y) Z), >> > since addresses can be more complicated than that. One way to >> >

Re: [PATCH] x86: Skip ISA check for always_inline in system headers

On Thu, Mar 25, 2021 at 7:54 AM Jakub Jelinek via Gcc-patches wrote: > > On Thu, Mar 25, 2021 at 03:40:51PM +0100, Richard Biener wrote: > > I think the "proper" way to do this is to have 'open' above end up > > refering to the out-of-line 'open' in the DSO, _not_ to emit the > > fortification

Re: [PATCH] AIX struct alignment (PR 99557)

On Wed, Mar 24, 2021 at 11:30 AM Iain Sandoe wrote: > > David Edelsohn via Gcc-patches wrote: > > > On Wed, Mar 24, 2021 at 3:51 AM Richard Biener > > wrote: > >> On Wed, Mar 24, 2021 at 3:03 AM David Edelsohn wrote: > >>> On Mon, Mar 22, 2021 at 4:10 AM Richard Biener > >>> wrote: > >>> >

Re: Problem building libstdc++ for the avr target

On 25/03/21 12:36 +, Jonathan Wakely wrote: On 25/03/21 10:27 +0100, Vladimir V wrote: Hello. Recently I tried the 'freestanding' build of the libstdc++ for the avr to verify that my fixes were sufficient for it as well. Unfortunately, I encountered the following error:

Re: [PATCH v2] c++: -Wconversion vs value-dependent expressions [PR99331]

On Tue, Mar 23, 2021 at 04:59:53PM -0400, Jason Merrill via Gcc-patches wrote: > On 3/8/21 7:34 PM, Marek Polacek wrote: > > On Fri, Mar 05, 2021 at 05:03:45PM -0500, Jason Merrill wrote: > > > On 3/4/21 9:37 PM, Marek Polacek wrote: > > > > This PR complains that we issue a -Wconversion warning

Re: [PATCH] c++, v2: Fix ICE with nsdmi [PR99705]

On 3/25/21 4:33 PM, Jakub Jelinek wrote: On Thu, Mar 25, 2021 at 04:20:54PM -0400, Jason Merrill wrote: but it is also cp_walk_subtrees DECL_EXPR handling: case DECL_EXPR: /* User variables should be mentioned in BIND_EXPR_VARS and their initializers and sizes walked

Re: [PATCH] dwarf2cfi: Defer queued register saves some more [PR99334]

On 3/24/21 5:31 AM, Jakub Jelinek wrote: Hi! On the testcase in the PR with -fno-tree-sink -O3 -fPIC -fomit-frame-pointer -fno-strict-aliasing -mstackrealign we have prologue: <_func_with_dwarf_issue_>: 0: 4c 8d 54 24 08 lea0x8(%rsp),%r10 5: 48 83 e4 f0

[committed] add test for PR tree-optimization/48483

All the test cases in the bug but one pass. The one that doesn't seems sufficiently different to track separately. I've committed a test with the test cases in r11-7840 and resolved the bug. Martin

Re: [PATCH] c++: Diagnose bare parameter packs in bitfield widths [PR99745]

On 3/25/21 6:52 AM, Jakub Jelinek wrote: Hi! The following invalid tests ICE because we don't diagnose (and drop) bare parameter packs in bitfield widths. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? OK. 2021-03-24 Jakub Jelinek PR

Re: [PATCH] c++, v2: Fix source_location inconsistency between calls from templates and non-templates [PR99672]

On 3/23/21 6:40 PM, Jakub Jelinek wrote: On Tue, Mar 23, 2021 at 04:53:54PM -0400, Jason Merrill via Gcc-patches wrote: It's simpler to use iloc_sentinel for this. Indeed, it is. Here is the new version, bootstrapped on x86_64-linux and i686-linux, so far regtested on i686-linux, regtest on

Re: [PATCH] c++, v2: Fix ICE with nsdmi [PR99705]

On Thu, Mar 25, 2021 at 04:20:54PM -0400, Jason Merrill wrote: > > but it is also cp_walk_subtrees DECL_EXPR handling: > > case DECL_EXPR: > >/* User variables should be mentioned in BIND_EXPR_VARS > > and their initializers and sizes walked when walking > > the

Re: [PATCH] dwarf2out: Fix debug info for 2 byte floats [PR99388]

On 3/5/21 4:21 AM, Jakub Jelinek wrote: Hi! Aarch64, ARM and a couple of other architectures have 16-bit floats, HFmode. As can be seen e.g. on void foo (void) { __fp16 a = 1.0; asm ("nop"); a = 2.0; asm ("nop"); a = 3.0; asm ("nop"); } testcase, GCC mishandles this on the

Re: [PATCH] c++: ICE on invalid with inheriting constructors [PR94751]

On 3/5/21 5:50 PM, Marek Polacek wrote: This is an ICE on invalid where we crash because since r269032 we keep error_mark_node around instead of using noexcept_false_spec when things go wrong; see the walk_field_subobs hunk. We crash in deduce_inheriting_ctor which calls synthesized_method_walk

Re: [PATCH] c++, v2: Fix ICE with nsdmi [PR99705]

On 3/25/21 6:50 AM, Jakub Jelinek wrote: On Tue, Mar 23, 2021 at 04:51:52PM -0400, Jason Merrill via Gcc-patches wrote: + if (TREE_CODE (*tp) == DECL_EXPR + && VAR_P (DECL_EXPR_DECL (*tp)) + && DECL_ARTIFICIAL (DECL_EXPR_DECL (*tp)) + && !TREE_STATIC (DECL_EXPR_DECL (*tp)) +

[commit] [OG10] amdgcn: Add gfx908 support

Hello I have backported commit 3535402e20118655b2ad4085a6e1d4f1b9c46e92 (amdgcn: Add gfx908 support) from mainline to the devel/omp/gcc-10 branch as commit bb55967ccde0b48f285150caf6443a327159b4a2. This adds support for the gfx908 GPU type. Kwok

[committed] add test for PR 44547

PR tree-optimization/44547 - -Wuninitialized reports false warning in nested switch statements, has been resolved for some time. In r11-7839 I've committed the test and resolved the bug as fixed. Martin

improve future::poll calibration loop

The calibration loop I've recently added to the libstdc++ future/members/poll.cc tests could still select iteration counts that might yield zero-time measurements for the wait_for when ready loop. Waiting for a future that has already had a value set is presumably uniformly faster than a

[committed] new test for PR 55060

The bug was fixed in GCC 5.0 but never resolved. I've added a test case in the commit below and resolved it: https://gcc.gnu.org/g:e88ca9f42306e291d3cb2d34dd7f2b017a3c1e52 Martin

Re: [PATCH] PING implement pre-c++20 contracts

On 3/1/21 8:12 AM, Jeff Chapman wrote: On 1/18/21, Jason Merrill wrote: On 1/4/21 9:58 AM, Jeff Chapman wrote: Ping. re: https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561135.html

Re: [PATCH v2] c++: -Wconversion vs value-dependent expressions [PR99331]

On 3/25/21 3:02 PM, Marek Polacek wrote: On Tue, Mar 23, 2021 at 04:59:53PM -0400, Jason Merrill via Gcc-patches wrote: On 3/8/21 7:34 PM, Marek Polacek wrote: On Fri, Mar 05, 2021 at 05:03:45PM -0500, Jason Merrill wrote: On 3/4/21 9:37 PM, Marek Polacek wrote: This PR complains that we

[PATCH] vect: Init inside_cost in vect_model_reduction_cost

Hi, I happened to find this possible use of uninitialized inside_cost during checking the cost for reduction. Before r11-6587, all the if/else if/else arms will assign values to inside_cost, so it was fine. But from r11-6587 the else path won't assign any more, it leads the inside_cost possibly

Re: [PATCH] vect: Init inside_cost in vect_model_reduction_cost

On 3/25/2021 12:04 AM, Kewen.Lin via Gcc-patches wrote: Hi, I happened to find this possible use of uninitialized inside_cost during checking the cost for reduction. Before r11-6587, all the if/else if/else arms will assign values to inside_cost, so it was fine. But from r11-6587 the else