On 5/26/21 2:21 AM, sunil.k.pandey wrote:
On Linux/x86_64,
41ddc5b0a6b44a9df53a259636fa3b534ae41cbe is the first bad commit
commit 41ddc5b0a6b44a9df53a259636fa3b534ae41cbe
Author: Aldy Hernandez
Date: Tue May 25 08:36:44 2021 +0200
Fix selftest for targets where short and int are
On Wed, May 26, 2021 at 12:12 PM Andrew Pinski wrote:
>
> On Tue, May 25, 2021 at 6:17 PM Hongtao Liu wrote:
> >
> > Update patch:
> > The new patch simplify (vec_duplicate (not (nonimmedaite_operand)))
> > to (not (vec_duplicate (nonimmedaite_operand))). This is not a
> > straightforward
On Tue, May 25, 2021 at 6:24 PM Richard Biener
wrote:
>
> On Mon, May 24, 2021 at 11:52 AM Hongtao Liu wrote:
> >
> > Hi:
> > Details described in PR.
> > Bootstrapped and regtest on
> > x86_64-linux-gnu{-m32,}/x86_64-linux-gnu{-m32\
> > -march=cascadelake,-march=cascadelake}
> > Ok for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100762
Bug ID: 100762
Summary: [mips+msa] ICE when comparing 64 bit vectors
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
On Tue, May 25, 2021 at 6:17 PM Hongtao Liu wrote:
>
> Update patch:
> The new patch simplify (vec_duplicate (not (nonimmedaite_operand)))
> to (not (vec_duplicate (nonimmedaite_operand))). This is not a
> straightforward simplification, just adding some tendency to pull not
> out of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100761
Bug ID: 100761
Summary: [mips+msa] ICE when using __builtin_convertvector to
convert from u8x8 to u8x16
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97248
--- Comment #1 from Evan Nemerson ---
SImilar issue with right shift:
typedef long a;
typedef struct {
a b __attribute__((__vector_size__(64)));
} c;
void d() {
int e;
c f, g;
f.b = g.b >> e;
}
$ mips64el-linux-gnuabi64-g++-10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100759
--- Comment #1 from seurer at gcc dot gnu.org ---
actually, there are a bunch of failures from this revision:
FAIL: g++.dg/torture/pr81360.C -Os (internal compiler error)
FAIL: g++.dg/torture/pr81360.C -Os (internal compiler error)
FAIL:
gcc/ChangeLog:
* config/csky/csky.c (ck810_legitimate_index_p): Modified for
support "base + index" with DF mode.
* config/csky/constraints.md ("Y"): New constraint for memory operands
without index register.
* config/csky/csky_insn_fpuv2.md
>> The attached patch v2 use the structure by considering the above
>> advice and the (code == CONSTRUCTOR || code == VECTOR_CST) part
>> can be shared with VIEW_CONVERT_EXPR handlings as below:
>>
>> op0 gathering (leave V_C_E in code if it's met)
>>
>> else if (code == CONSTRUCTOR || code
I checked the source of protobuf 3.0.0 and it didn't contain the
operator[] in RepeatedField. Need to install a newer version of
protobuf.
Thanks,
Wei.
On Tue, May 25, 2021 at 1:49 PM Eugene Rozenfeld
wrote:
>
> Both are 3.0.0-9.1ubuntu1:
>
> eugene@eugene-Virtual-Machine:~/autofdo1/build$ apt
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562015.html
BR,
Kewen
on 2021/5/7 上午10:45, Kewen.Lin via Gcc-patches wrote:
> Hi Segher,
>
>>>
>>> I think this should be postponed to stage 1 though? Or is there
>>> anything very urgent in it?
>>>
>>
>> Yeah, I
On Linux/x86_64,
a6e94287d31525b3ad0963ad22a92e9f3dbcd3cf is the first bad commit
commit a6e94287d31525b3ad0963ad22a92e9f3dbcd3cf
Author: Andrew MacLeod
Date: Tue May 25 14:59:54 2021 -0400
Remove the logical stmt cache for now.
caused
FAIL: libgomp.c++/task-reduction-8.C execution test
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/569792.html
BR,
Kewen
on 2021/5/7 上午10:30, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> For some cases that when we load unsigned char/short values from
> the appropriate unsigned char/short memories and convert them to
Hi,
This is the updated version of patch to deal with the bwaves_r
degradation due to vector construction fed by strided loads.
As Richi's comments [1], this follows the similar idea to over
price the vector construction fed by VMAT_ELEMENTWISE or
VMAT_STRIDED_SLP. Instead of adding the extra
Is any test case for these instructions?
On 4/30/21 9:04 PM, Geng Qi wrote:
gcc/ChangeLog:
* config/csky/csky.c (ck810_legitimate_index_p): Modified for
support "base + index" with DF mode.
* config/csky/constraints.md ("Y"): New constraint for memory operands
merged.
On 5/25/21 6:45 PM, Geng Qi wrote:
gcc/
* config/csky/csky.md (cskyv2_sextend_ldbs): New insn.
gcc/testsuite/
* gcc/testsuite/gcc.target/csky/ldbs.c: New.
---
gcc/config/csky/csky.md | 10 ++
gcc/testsuite/gcc.target/csky/ldbs.c | 11 +++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100760
Bug ID: 100760
Summary: [mips + msa] ICE: maximum number of generated reload
insns per insn achieved
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Update patch:
The new patch simplify (vec_duplicate (not (nonimmedaite_operand)))
to (not (vec_duplicate (nonimmedaite_operand))). This is not a
straightforward simplification, just adding some tendency to pull not
out of vec_duplicate.
For i386, it will enable below opt
from
notl
On Linux/x86_64,
41ddc5b0a6b44a9df53a259636fa3b534ae41cbe is the first bad commit
commit 41ddc5b0a6b44a9df53a259636fa3b534ae41cbe
Author: Aldy Hernandez
Date: Tue May 25 08:36:44 2021 +0200
Fix selftest for targets where short and int are the same size.
caused
FAIL:
@David: PING
As far as I know, the only remaining question is about using `ssize_t`
for the return type of some functions.
Here's why I use this type:
That seemed off to return NULL for the functions returning a
size_t to indicate an error. So I changed it to return -1 (and return
type to
I updated the patch according to the comments by Tom Tromey.
There's one question left about your question regarding
C_MAYBE_CONST_EXPR, David:
I am not sure if we can get a C_MAYBE_CONST_EXPR from libgccjit, and it
indeed seems like it's only created in c-family.
However, we do use it in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100755
--- Comment #5 from afernandez at odyhpc dot com ---
I just tried -std=legacy but it made no difference.
I introduced fur_source a week ago or so to act as the source for
operands of fold_stmt.. ie, it encapsulated a range_query source to get
operands for the arguments of a stmt when fold_stmt was invoked.
One of the API points was an internal ranger version which contains a
reference to a
We added the logical stmt depth limit back in January I think, and the
logical stmt cache is not currently in use. This patch removes that
code so it doesn't have too be maintained thru these changes.
Bootstraps on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
>From
First step in moving gori_compute to range_query is to standardize its
queries to be stmt based rather than block based. gori_compute works
from the bottom of the block back towards the top, so it always has a
stmt available for a range_of_expr query, there is no need to use a
non-standard
Just some minor tweaking of the location of calls to non_null_deref_p,
as well as debug output.
Bootstraps on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
>From 35c78c6fc54721e067ed3a30ddd9184b45c5981d Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 25 May 2021 14:41:16
The patch removes the custom temporal cache from GCC11 and replaces it
with a simple timestamp vector and utilizes the direct dependants from
gori_compute.
This allows the registration of said dependencies to be handled
generically by the simplified fold_stmt class thru the gori_compute
This patch introduced imports to range_def, and corrects some minor
issues with export calculation.
When gori-compute is evaluating sequences in a block:
- an "export" is defined as any ssa_name which may have a range
calculated on an outgoing edge. If the edge may CHANGE the value of
Ranger wants to prepopulate all the export blocks so that it has an initial
invariant set of names. GORI consumers shouldn't be penalized for ranger
requirements. This way any gori client remains lightweight.
Bootstraps on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
>From
This is the first in a set of, well, many patches. It ultimately
changes the gori-compute model into a consumer of the range_query class,
which allows for much simpler and consistent interaction with the
fold_stmt class. I'm basically evolving all the code base to
consistently interact with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100759
Bug ID: 100759
Summary: [12 regression] ICE for g++.dg/torture/pr81360.C after
r12-1039 at gcc/options-save.c:13626
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100755
--- Comment #4 from Dominique d'Humieres ---
> If I'm understanding correctly and this is an extension being deprecated,
> is there any option to push the compilation with gcc11.1 through?
Did you try -std=legcy?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573
--- Comment #20 from Jakub Jelinek ---
Yeah, that is likely what happens, I'll debug tomorrow.
Bootstrapped and tested it on powerpc64 power 7 and 8 BE and 8, 9, and
10 LE and saw nothing untoward.
On 5/19/21 5:28 AM, Richard Biener wrote:
The first release candidate for GCC 9.4 is available from
https://sourceware.org/pub/gcc/snapshots/9.4.0-RC-20210519/
and shortly its mirrors. It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100755
--- Comment #3 from afernandez at odyhpc dot com ---
Sorry for the delay. The system is AArch64 and running CentOS8.3. I have 2 GCC
installations, one is 8.3.1 and the second is 11.1.0. NCEPLIBS builds with the
former but not with the second.
On 25/05/21 23:01 +0200, François Dumont wrote:
On 25/05/21 11:58 am, Jonathan Wakely wrote:
On 22/05/21 22:08 +0200, François Dumont via Libstdc++ wrote:
Here is the part of the libbacktrace patch with the enhancement to
the rendering of assert message.
It only contains one real fix, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100656
--- Comment #3 from anlauf at gcc dot gnu.org ---
The following patch seems to fix the issue:
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 6d38ea78273..7eeef554c0f 100644
--- a/gcc/fortran/trans-array.c
+++
On 25/05/21 11:58 am, Jonathan Wakely wrote:
On 22/05/21 22:08 +0200, François Dumont via Libstdc++ wrote:
Here is the part of the libbacktrace patch with the enhancement to
the rendering of assert message.
It only contains one real fix, the rendering of address. In 2 places
it was done with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66742
--- Comment #15 from Jonathan Wakely ---
Fixed downstream in my fork:
https://gitlab.com/jonathan-wakely/gcc/-/commit/18d78721bf3afaed243252a01a4f4909c17531b2
On 5/25/21 3:04 AM, Richard Biener wrote:
On Tue, May 25, 2021 at 2:53 AM Martin Sebor via Gcc-patches
wrote:
On 5/24/21 5:08 PM, David Malcolm wrote:
On Mon, 2021-05-24 at 16:02 -0600, Martin Sebor wrote:
The rare expressions that have no location
continue to have just one bit[1].
Both are 3.0.0-9.1ubuntu1:
eugene@eugene-Virtual-Machine:~/autofdo1/build$ apt list protobuf-compiler
Listing... Done
protobuf-compiler/bionic,now 3.0.0-9.1ubuntu1 amd64 [installed]
eugene@eugene-Virtual-Machine:~/autofdo1/build$ apt list libprotobuf-dev
Listing... Done
libprotobuf-dev/bionic,now
On Linux/x86_64,
fd97aeb494cdcffe0d21e7f15ab4593662e065bd is the first bad commit
commit fd97aeb494cdcffe0d21e7f15ab4593662e065bd
Author: Eric Botcazou
Date: Tue May 25 18:30:29 2021 +0200
Remove stalled TREE_READONLY flag on automatic variable
caused
FAIL:
On 5/25/21 1:12 PM, Patrick Palka wrote:
On Mon, 24 May 2021, Jason Merrill wrote:
On 5/24/21 1:48 PM, Patrick Palka wrote:
In the testcase below, the initializer for C::b inside C's default
constructor is encoded as a TARGET_EXPR wrapping the CALL_EXPR f() in
C++17 mode. During massaging of
The GCC manual's documentation of -fno-trampolines was apparently
written from an Ada point of view. However, when I read it I
understandably mistook it to say that -fno-trampolines also works for
C, C++, etc. It doesn't: it is silently ignored for these languages,
and I assume for any language
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573
--- Comment #19 from Alexander Monakov ---
Ah, does the issue arise because foo._omp_fn.0 is (before the patch) callable
in two contexts, in one it's called from host and should be 'omp target
entrypoint', and in the other it's called from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100551
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100551
--- Comment #7 from CVS Commits ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:de55a48960d2f08266cba1222e233507015dd620
commit r11-8469-gde55a48960d2f08266cba1222e233507015dd620
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573
--- Comment #18 from Tobias Burnus ---
I think the problem is:
create_omp_child_function(omp_context*, bool)
...
1916 DECL_ATTRIBUTES (decl) = DECL_ATTRIBUTES (current_function_decl);
The code removes then 'omp declare simd' but not 'omp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573
--- Comment #17 from Alexander Monakov ---
Yes, I'd agree normally it's present in the offload table, but ideally if
you're trying to stub out the call, it should not be present in the offload
table.
I think Tobias is saying that on GIMPLE
On Tue, 25 May 2021, Martin Liška wrote:
> +@quotation
> +aix@var{version}, amdhsa, aout, cygwin, darwin@var{version}
Missing comma at the end of this line.
> +eabi, eabialtivec, eabisim, eabisimaltivec, elf, elf32,
> +elfbare, elfoabi, freebsd@var{version}gnu, hpux, hpux@var{version},
Missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573
--- Comment #16 from Jakub Jelinek ---
(In reply to Alexander Monakov from comment #14)
> I would break in gdb on cuModuleGetFunction and
>
> x/s $rdx
>
> to print the failing symbol (it's the third argument to the function).
>
> It seems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96555
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
*PING*
> Gesendet: Dienstag, 18. Mai 2021 um 20:36 Uhr
> Von: "Harald Anlauf"
> An: "fortran" , "gcc-patches"
> Betreff: [PATCH] PR fortran/100602 - [11/12 Regression] Erroneous "pointer
> argument is not associated" runtime error
>
> The generation of the new runtime check picked up the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573
--- Comment #15 from Jakub Jelinek ---
(In reply to Tobias Burnus from comment #13)
> (In reply to Tobias Burnus from comment #9)
> > not found name: 'test_d_normal._omp_fn.0.kd'
>
> I think the problem is the following:
>
> (a) working:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573
--- Comment #14 from Alexander Monakov ---
I would break in gdb on cuModuleGetFunction and
x/s $rdx
to print the failing symbol (it's the third argument to the function).
It seems the "inner" entrypoint (which your patch attempted to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100662
--- Comment #11 from ripero84 at gmail dot com ---
Thank you very much for the information and your help.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573
--- Comment #13 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #9)
> not found name: 'test_d_normal._omp_fn.0.kd'
I think the problem is the following:
(a) working:
foo()
#pragma target
bar()
Here, 'foo._omp_fn.0' as as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96088
François Dumont changed:
What|Removed |Added
Target Milestone|--- |12.0
Resolution|---
Ping….
Qing
On May 12, 2021, at 12:16 PM, Qing Zhao via Gcc-patches
mailto:gcc-patches@gcc.gnu.org>> wrote:
Hi,
This is the 3rd version of the patch for the new security feature for GCC.
Please take look and let me know your comments and suggestions.
thanks.
Qing
**Compare with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100724
--- Comment #6 from Jan Hubicka ---
> Could the manual entry for -fwhole-program just be amended to clarify that
> it's
> a fallback for when a linker plugin isn't available for -flto. That may be
> what it was intended to say, but it's not
From: Matthias Kretz
Ensure dump_template_decl for function templates never prints template
parameters after the function name (it did with -fno-pretty-templates) and
skip output of irrelevant & confusing "[with T = T]" in dump_substitution.
gcc/cp/ChangeLog:
PR c++/100716
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100734
--- Comment #9 from Martin Sebor ---
(In reply to John David Anglin from comment #5)
> Breakpoint 1, attr_access::from_mode_char (
> c=)
> at ../../gcc/gcc/attribs.h:304
> 304 gcc_unreachable ();
This error says that is null. c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100734
--- Comment #8 from Martin Sebor ---
The plus character should always be followed by a nonempty string. John, can
you please attach a translation unit to see if by chance I can reproduce with a
cross-compiler? In parallel, I wonder if there's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100755
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords|ice-on-valid-code |ice-on-invalid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100716
--- Comment #2 from Matthias Kretz (Vir) ---
I'd like to revise my opinion above. dump_template_decl should never print the
template parameter list of functions. I.e. it should be 'template f()'
not 'template f()'. Because it's also declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100751
--- Comment #8 from Gejoe ---
(In reply to Martin Liška from comment #6)
> Yes, __gcov_reset is supposed to be called at the beginning when an
> application wants to start
> profiling. Again, you don't need to call it manually.
But reset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100734
--- Comment #7 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Richard Biener from comment #3)
> > Possibly a dup of PR100727?
>
> I think it is unrelated.
>
> The problem is the fix for PR 100619, sets the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100758
Bug ID: 100758
Summary: __builtin_cpu_supports does not (always) detect "sse2"
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100734
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573
--- Comment #12 from Jakub Jelinek ---
With incremental
--- gcc/omp-offload.c.jj2021-05-25 13:43:01.341137265 +0200
+++ gcc/omp-offload.c 2021-05-25 20:07:01.934506823 +0200
@@ -2696,8 +2696,16 @@ pass_omp_target_link::execute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573
Jakub Jelinek changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100734
--- Comment #5 from John David Anglin ---
Breakpoint 1, attr_access::from_mode_char (
c=)
at ../../gcc/gcc/attribs.h:304
304 gcc_unreachable ();
(gdb) bt
#0 attr_access::from_mode_char (
c=)
at ../../gcc/gcc/attribs.h:304
On 5/25/21 10:17 AM, Aldy Hernandez via Gcc-patches wrote:
Adjustments per discussion.
OK pending tests?
Aldy
I have no concern with the alloca changes. The xfail removals from
the two tests in this patch (a nice improvement) don't seem to be
related to alloca so I'd expect them to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100626
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100731
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100626
--- Comment #7 from CVS Commits ---
The releases/gcc-11 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:6be2c12e37b167890d68587086a2186358b64c02
commit r11-8468-g6be2c12e37b167890d68587086a2186358b64c02
Author: Uros Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100731
--- Comment #9 from Jonathan Wakely ---
r230324 changed the dependency for std::to_string from _GLIBCXX_USE_C99 to
_GLIBCXX_USE_C99_STDIO, which means it's enabled for more targets (you don't
need the full C99 math library, for example!) That
On Mon, 24 May 2021, Jason Merrill wrote:
> On 5/24/21 1:48 PM, Patrick Palka wrote:
> > In the testcase below, the initializer for C::b inside C's default
> > constructor is encoded as a TARGET_EXPR wrapping the CALL_EXPR f() in
> > C++17 mode. During massaging of this constexpr constructor,
>
On 5/25/2021 10:36 AM, Aldy Hernandez wrote:
Ok, let's use build_nonstandard_integer_type which works for everyone
and gets you unblocked.
Just to be clear, I'm not blocked on xstormy16. The upstream GCC
tester flagged the failure and I did enough triage to blame you :-) In
my day job I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100757
--- Comment #2 from Alex Coplan ---
Could be, I'm bisecting it now...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100757
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
Ok, let's use build_nonstandard_integer_type which works for everyone
and gets you unblocked.
Pushed.
Aldy
On Tue, May 25, 2021 at 3:15 PM Jeff Law wrote:
>
>
>
> On 5/25/2021 12:44 AM, Aldy Hernandez wrote:
> > avr-elf seems to use HImode for both integer_type_node and
> >
> LGTM.
Thanks, but a bit too bold because gimplify_and_add can promote the non-static
DECL to static memory and reinstate DECL_INITIAL, so first hunk adjusted.
* gimplify.c (gimplify_decl_expr): Clear TREE_READONLY on the DECL
when really creating an initialization statement
On 5/25/2021 10:17 AM, Aldy Hernandez wrote:
Adjustments per discussion.
OK pending tests?
The latest revision of #2-#5 are OK once #1 is ACK'd.
Jeff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100731
--- Comment #8 from Harald van Dijk ---
I take it that means there's no need for me to continue with what Richard asked
me to do?
At any rate, it looks like this fix won't be enough for GCC 12, but that's an
issue with the environment, not GCC
/src/gcc/configure
--prefix=/data_sdb/toolchain/cc1s/arm --enable-languages=c,c++
--disable-bootstrap --target=arm-eabi
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210525 (experimental) (GCC)
$ cat test.c
extern int a[];
int n;
void foo(int x, _Bool b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340
--- Comment #9 from Iain Sandoe ---
JFTR the Apple OSS folks comment:
"I checked with the clang team — it appears this was an unintentional
consequence of an upstream change: https://reviews.llvm.org/D75203. This
difference between debug vs
This patch adds support for the reduc_plus_scal optab with MVE, which
maps to the vaddv instruction.
It moves the reduc_plus_scal_ expander from neon.md to
vec-common.md and adds support for MVE to it.
Since vaddv uses a 32-bits accumulator, we have to truncate it's
result.
For instance:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100756
Bug ID: 100756
Summary: vect: Superfluous epilog created on s390x
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
No changes needed for this patch.
OK pending tests?
Aldy
Adjustments per discussion.
OK pending tests?
Aldy
>From d701627d2b0a3cdfea7a11b3b4cf4105db08dcf5 Mon Sep 17 00:00:00 2001
From: Aldy Hernandez
Date: Wed, 19 May 2021 18:44:08 +0200
Subject: [PATCH 4/5] Convert remaining passes to get_range_query.
This patch converts the remaining users of
Adjustments per discussion.
OK pending tests?
Aldy
>From 1c275296ab64cd877bce795b9964532c8655fa3f Mon Sep 17 00:00:00 2001
From: Aldy Hernandez
Date: Tue, 25 May 2021 17:44:51 +0200
Subject: [PATCH 2/5] Convert evrp pass to get_range_query.
gcc/ChangeLog:
* gimple-ssa-evrp.c
Adjustments per discussion.
OK pending tests?
Aldy
>From 97bedf7dc0a7860802461b5fd3e72b687076ae30 Mon Sep 17 00:00:00 2001
From: Aldy Hernandez
Date: Wed, 19 May 2021 18:27:47 +0200
Subject: [PATCH 3/5] Convert Walloca pass to get_range_query.
This patch converts the Walloca pass to use an
It looks like some version problem about protobuf-compiler and
libprotobuf-dev. Could you check what is the installed version on your
end for those two packages and see if they are consistent?
On my platform, they are both 3.12.4.
On Tue, May 25, 2021 at 12:01 AM Eugene Rozenfeld
wrote:
>
>
The interface is now an inline function for get_range_query() and an
external function for get_global_range_query), as discussed.
There are no magic cfun uses behind the scenes.
The annoying downcast is gone.
Passes can now decide if they want to export global ranges after they
use a ranger.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573
--- Comment #10 from Jakub Jelinek ---
I didn't have the nvidia binary module loaded and cuda installed when doing the
light testing, now I've installed that and see
FAIL: libgomp.c/../libgomp.c-c++-common/for-3.c execution test
FAIL:
On 5/25/21 11:15 AM, Martin Sebor wrote:
On 5/25/21 4:38 AM, Robin Dapp wrote:
Hi Martin and Jason,
The removal of the dead code looks good to me. The change to
"re-init lastalign" doesn't seem right. When it's zero it means
the conflict is between two attributes on the same declaration,
in
Martin Sebor wrote:
On 5/25/21 8:01 AM, Iain Sandoe via Gcc-patches wrote:
Hi Martin
Martin Sebor via Gcc-patches wrote:
The attached patch replaces the uses of TREE_NO_WARNING in
the Objective-C front end.
I’ve been gradually trying to improve/add locations in the ObjC stuff.
To that
1 - 100 of 255 matches
Mail list logo
