.
The attached test code is composed to reveal the issue but is not meant to do
any job. The "#if" alternative in the code can be used to show how warning
disappears.
In a case of meaningful code which causes the warning the code works as
expected.
- g++ version:
g++ (GCC) 11.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96748
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96748
--- Comment #2 from Manuel Lauss ---
Created attachment 49099
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49099=edit
gzipped testcase
Apologies, find the gzip compressed test source attached.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96733
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96748
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
This is another small tweak to the kernels loop annotator. Like the
subject line says, it allows the annotator to consider loops that have
calls to builtins (C/C++) or intrinsics (Fortran). I've committed this
to the OG10 branch since there is no one to review these patches right
now, and it
On 8/20/20 6:33 PM, Segher Boessenkool wrote:
Hi!
On Tue, Aug 18, 2020 at 02:31:41AM -0400, Michael Meissner wrote:
In order to do this, the pass that converts the load address and load/store
must occur late in the compilation cycle.
That does not follow afaics.
Let me see if I can help
Hi Dave,
I actually think using plus_xor_ior operator is useful. It means that if
combine,
inlining or some other RTL simplification generates these variants, these forms
will still be recognized by the backend. It's more typing, but the compiler
produces
better code.
Here's what I have so
Snapshot gcc-10-20200822 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/10-20200822/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
On 2020-08-22 12:01 p.m., Roger Sayle wrote:
> I suspect that the issue with the 64-bit patterns is that the second variant
> of
> pa.md's define_insn "shrpdi4" is unlikely ever to match as (minus:DI
> (const_int 64) x)
> is never "canonical" when x is itself a CONST_INT. Splitting this
>
Hi, Josh
On 08/21, Josh Triplett wrote:
> On Thu, Aug 20, 2020 at 07:00:13PM -0300, Giuliano Belinassi wrote:
> > This patch series add a new flag "-fparallel-jobs=" to control if the
> > compiler should try to compile the current file in parallel.
> [...]
> > Bootstrapped and Regtested on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96737
Dominique d'Humieres changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #2 from
On Sat, Aug 22, 2020 at 10:11 AM Uros Bizjak wrote:
>
> On Sat, Aug 22, 2020 at 6:27 PM H.J. Lu wrote:
> >
> > On Fri, Aug 21, 2020 at 9:45 AM H.J. Lu wrote:
> > >
> > > On Fri, Aug 21, 2020 at 9:35 AM H.J. Lu wrote:
> > > >
> > > > On Fri, Aug 21, 2020 at 9:29 AM Hongtao Liu wrote:
> > > > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96748
Bug ID: 96748
Summary: ICE in get_default_value, at tree-ssa-ccp.c:311
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
On Sat, Aug 22, 2020 at 6:27 PM H.J. Lu wrote:
>
> On Fri, Aug 21, 2020 at 9:45 AM H.J. Lu wrote:
> >
> > On Fri, Aug 21, 2020 at 9:35 AM H.J. Lu wrote:
> > >
> > > On Fri, Aug 21, 2020 at 9:29 AM Hongtao Liu wrote:
> > > >
> > > > On Fri, Aug 21, 2020 at 11:50 PM Uros Bizjak wrote:
> > > > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96747
Bug ID: 96747
Summary: -Wshadow accepts included extern variable shadowing
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96654
--- Comment #2 from Marc Glisse ---
gcc doesn't seem very fond of using 2 different vector bitsizes at the same
time, so VEC_PACK_FIX_TRUNC_EXPR takes 2 vectors of 2 double and gives one
vector of 4 int. At the RTL level, we have a
On Fri, Aug 21, 2020 at 9:45 AM H.J. Lu wrote:
>
> On Fri, Aug 21, 2020 at 9:35 AM H.J. Lu wrote:
> >
> > On Fri, Aug 21, 2020 at 9:29 AM Hongtao Liu wrote:
> > >
> > > On Fri, Aug 21, 2020 at 11:50 PM Uros Bizjak wrote:
> > > >
> > > > On Fri, Aug 21, 2020 at 5:41 PM Hongtao Liu wrote:
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96746
Bug ID: 96746
Summary: Type Casting in template function should not be
type-dependent if the type of the conversion result is
not type-dependent.
Product: gcc
Hi Dave,
Many thanks for your help.
I suspect that the issue with the 64-bit patterns is that the second variant
of
pa.md's define_insn "shrpdi4" is unlikely ever to match as (minus:DI
(const_int 64) x)
is never "canonical" when x is itself a CONST_INT. Splitting this
define_insn
into two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94851
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
PR analyzer/94851 reports various false "NULL dereference" diagnostics.
The first case (comment #1) affects GCC 10.2 but no longer affects
trunk; I believe it was fixed by the state rewrite of
r11-2694-g808f4dfeb3a95f50f15e71148e5c1067f90a126d.
The patch adds a regression test for this case.
The
I have followup patches that add new conditions to store::eval_alias.
Rather than duplicate all conditions for symmetry, split it up and
call it on both (A, B) and (B, A).
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as c199723d7ed0032db095abc75b82a9710eaa5e56.
region_model::push_frame was binding arguments for both the default SSA
name for each parameter, and the underlying parameter.
Simplify the generated states by only binding the default SSA name if
it exists, or the parameter if there is no default SSA name.
Successfully bootstrapped & regrtested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94851
--- Comment #6 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:df2b78d407a3fe8685343f7249b9c31c7e3af44d
commit r11-2807-gdf2b78d407a3fe8685343f7249b9c31c7e3af44d
Author: David Malcolm
Date:
On Sat, 22 Aug 2020, Jonathan Wakely via Gcc-patches wrote:
On Sat, 22 Aug 2020 at 13:13, Jonathan Wakely wrote:
On Sat, 22 Aug 2020 at 10:52, Marc Glisse wrote:
is there a particular reason to handle only __int128 this way, and not all
the non-standard integer types? It looks like it would
On Sat, 15 Aug 2020, Roger Sayle wrote:
Here's version #2 of the patch to recognize bswap32 and bswap64
incorporating your suggestions and feedback. The test cases now confirm
the transformation is applied when int is 32 bits and long is 64 bits,
and should pass otherwise; the patterns now
On Fri, Aug 21, 2020 at 12:04 AM Palmer Dabbelt wrote:
>
> On Wed, 19 Aug 2020 02:25:37 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
> > Hi Andrew:
> >
> > I am not sure the reason why some targets pick different numbers.
> > It seems it's not only target dependent but also OS dependent[1].
> >
>
On Fri, 21 Aug 2020, Roger Sayle wrote:
This simple patch to match.pd optimizes away bit permutation
operations, specifically bswap and rotate, in calls to popcount and
parity.
Good idea.
Although this patch has been developed and tested on LP64,
it relies on there being no truncations or
Hi Roger,
Started a test of your latest version.
It appears we miss 64-bit patterns similar to these:
(define_insn ""
[(set (match_operand:SI 0 "register_operand" "=r")
(match_operator:SI 5 "plus_xor_ior_operator"
[(ashift:SI (match_operand:SI 1 "register_operand" "r")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96745
Bug ID: 96745
Summary: [concepts] internal compiler error: in
type_memfn_rqual, at cp/typeck.c:10389
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity:
On Sat, 22 Aug 2020 at 13:13, Jonathan Wakely wrote:
>
> On Sat, 22 Aug 2020 at 10:52, Marc Glisse wrote:
> > is there a particular reason to handle only __int128 this way, and not all
> > the non-standard integer types? It looks like it would be a bit simpler to
> > avoid a special case.
>
> I
On Sat, 22 Aug 2020 at 13:18, JeanHeyd Meneide wrote:
>
> On Sat, Aug 22, 2020 at 8:14 AM Jonathan Wakely via Gcc-patches
> wrote:
> > I really wish WG14 would just fix the intmax_t mess so we can make
> > them integral types unconditionally.
>
> We're trying, but we're struggling to reach a good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96744
Bug ID: 96744
Summary: [11 Regression] FAIL:
gcc.target/i386/avx512bitalgvl-vpopcntb-1.c execution
test
Product: gcc
Version: 10.2.1
Status:
On Sat, Aug 22, 2020 at 8:14 AM Jonathan Wakely via Gcc-patches
wrote:
> I really wish WG14 would just fix the intmax_t mess so we can make
> them integral types unconditionally.
We're trying, but we're struggling to reach a good consensus. Almost
nobody's fully agreeing on one /particular/
On Sat, 22 Aug 2020 at 10:52, Marc Glisse wrote:
> is there a particular reason to handle only __int128 this way, and not all
> the non-standard integer types? It looks like it would be a bit simpler to
> avoid a special case.
I have no objection to doing it for all of them, it just wasn't
Hi Jose,
Proposed patch to PR96727 - ICE with character length specified using
specification function on assumed-rank array.
Patch tested only on x86_64-pc-linux-gnu.
Add missing default error message for the assumed-rank array case.
Looks good with an adjusted ChangeLog/git commit
Hi Jose,
Proposed patch to PR96726 - ICE with user defined specification function
on assumed-rank array.
OK, you'll need a to work on the ChangeLog format to commit this
(like I wrote in my previous mail).
Thanks for the patch!
Regards
Thomas
On Wed, 19 Aug 2020, Jonathan Wakely via Gcc-patches wrote:
Because __int128 can be used as the difference type for iota_view, we
need to ensure that it meets the requirements of an integer-class type.
The requirements in [iterator.concept.winc] p10 include numeric_limits
being specialized and
Hi Dave,
It's great to hear from you. It's been a long while.
Sorry, doh! yes, there's a mistake in my patch (that I introduced when I
renumbered
the operands in the shd's define_expand to be the more logical 0, 1, 2, 3,
then 4).
Sorry for the inconvenience [due to my lack of familiarity with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96735
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
Hi Andreas,
make: *** No rule to make target
'../build-x86_64-pc-linux-gnu/libiberty/libiberty.a', needed by
'build/genmodes'. Stop.
Looks like you didn't run make in the toplevel. This is created by the
all-build-libiberty target.
That would have been strange, especially since there is no
On Aug 22 2020, Thomas Koenig via Gcc wrote:
> make: *** No rule to make target
> '../build-x86_64-pc-linux-gnu/libiberty/libiberty.a', needed by
> 'build/genmodes'. Stop.
Looks like you didn't run make in the toplevel. This is created by the
all-build-libiberty target.
Andreas.
--
Andreas
Hi,
I recently updated a branch which tracked master to current HEAD, and
got a compilation failure with --enable-maintainer-mode (see PR 96735):
make: *** No rule to make target
'../build-x86_64-pc-linux-gnu/libiberty/libiberty.a', needed by
'build/genmodes'. Stop.
Switching the branch to
i need this site https://gcc.gnu.org/
David Malcolm writes:
> On Wed, 2020-08-19 at 09:24 +0200, Andrea Corallo wrote:
>> Hi all,
>>
>> just a small patch updating some comments that apparently went out of
>> sync a while ago adding gcc_jit_context_new_rvalue_from_long.
>
>> Okay for trunk?
>
> Yes
>
> Thanks for fixing these
>
46 matches
Mail list logo
