Sebastian Huber writes:
> On 16/06/2020 12:42, Richard Sandiford wrote:
>
>> [...]
>> 2020-06-16 Richard Sandiford
>>
>> gcc/
>> * coretypes.h (first_type): New alias template.
>> * recog.h (insn_gen_fn::operator()): Use it instead of a decltype.
>> Remove spurious “...” and spli
On 18/06/2020 09:09, Richard Sandiford wrote:
Sebastian Huber writes:
On 16/06/2020 12:42, Richard Sandiford wrote:
[...]
2020-06-16 Richard Sandiford
gcc/
* coretypes.h (first_type): New alias template.
* recog.h (insn_gen_fn::operator()): Use it instead of a decltype.
Hi.
We should check for gassign before doing gimple_assign_rhs_code and friends.
Ready to be installed after proper testing?
Thanks,
Martin
gcc/ChangeLog:
* tree-vect-generic.c (expand_vector_condition): Check
for gassign before inspecting RHS.
---
gcc/tree-vect-generic.c | 5
Hi.
This breaks quite some powerpc.exp tests. Right now VEC_COND_EXPR expects first
argument to be a SSA_NAME (or constant) and so the patch fixes that.
Using the patch, I survive powerpc.exp test-suite.
Ready for master?
Martin
gcc/ChangeLog:
* config/rs6000/rs6000-call.c (fold_build_
Sebastian Huber writes:
> On 18/06/2020 09:09, Richard Sandiford wrote:
>
>> Sebastian Huber writes:
>>> On 16/06/2020 12:42, Richard Sandiford wrote:
>>>
[...]
2020-06-16 Richard Sandiford
gcc/
* coretypes.h (first_type): New alias template.
* recog.h (insn
Hi!
On Thu, Jun 18, 2020 at 09:44:58AM +0200, Martin Liška wrote:
> This breaks quite some powerpc.exp tests. Right now VEC_COND_EXPR expects
> first
> argument to be a SSA_NAME (or constant) and so the patch fixes that.
What does this mean? All context is missing here.
Also, is expecting that
Hi,
Noticed two places in tree-vect-data-refs.c where we can use function
vect_relevant_for_alignment_p.
Looks like these two are missed when we were introducing the function.
Bootstrapped and tested on aarch64-linux-gnu. OK to go?
ChangeLog modification is contained in the patch.
Than
On Thu, Jun 18, 2020 at 9:42 AM Martin Liška wrote:
>
> Hi.
>
> We should check for gassign before doing gimple_assign_rhs_code and friends.
>
> Ready to be installed after proper testing?
OK.
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> * tree-vect-generic.c (expand_vector_condition): Chec
We should have generated:
+2020-06-17 Harald Anlauf
+
+ Backported from master:
+ 2020-06-14 Harald Anlauf
+
+ PR fortran/95088
+ * gfortran.dg/pr95088.f90: New file.
but the script did:
+2020-06-17 Harald Anlauf
+
+ Backported from master:
+ 2020-06
On 6/17/20 3:15 PM, Richard Biener wrote:
On Wed, Jun 17, 2020 at 10:50 AM Richard Biener
wrote:
On Mon, Jun 15, 2020 at 2:20 PM Martin Liška wrote:
On 6/15/20 1:59 PM, Richard Biener wrote:
On Mon, Jun 15, 2020 at 1:19 PM Martin Liška wrote:
On 6/15/20 9:14 AM, Richard Biener wrote:
O
Please find attached fix for PR95585.
OK to commit and backport?
Commit message:
Fortran : ICE in gfc_check_reshape PR95585
Issue an error where an array is used before its definition
instead of an ICE.
2020-06-18 Steven G. Kargl
gcc/fortran/
PR fortran/PR95585
*check.c (gfc_che
On 6/18/20 10:00 AM, Segher Boessenkool wrote:
Hi!
On Thu, Jun 18, 2020 at 09:44:58AM +0200, Martin Liška wrote:
This breaks quite some powerpc.exp tests. Right now VEC_COND_EXPR expects
first
argument to be a SSA_NAME (or constant) and so the patch fixes that.
What does this mean? All conte
On Thu, Jun 18, 2020 at 10:10 AM Martin Liška wrote:
>
> On 6/17/20 3:15 PM, Richard Biener wrote:
> > On Wed, Jun 17, 2020 at 10:50 AM Richard Biener
> > wrote:
> >>
> >> On Mon, Jun 15, 2020 at 2:20 PM Martin Liška wrote:
> >>>
> >>> On 6/15/20 1:59 PM, Richard Biener wrote:
> On Mon, Jun
On Thu, Jun 18, 2020 at 10:21 AM Martin Liška wrote:
>
> On 6/18/20 10:00 AM, Segher Boessenkool wrote:
> > Hi!
> >
> > On Thu, Jun 18, 2020 at 09:44:58AM +0200, Martin Liška wrote:
> >> This breaks quite some powerpc.exp tests. Right now VEC_COND_EXPR expects
> >> first
> >> argument to be a SSA_
On 6/18/20 10:52 AM, Richard Biener wrote:
On Thu, Jun 18, 2020 at 10:10 AM Martin Liška wrote:
On 6/17/20 3:15 PM, Richard Biener wrote:
On Wed, Jun 17, 2020 at 10:50 AM Richard Biener
wrote:
On Mon, Jun 15, 2020 at 2:20 PM Martin Liška wrote:
On 6/15/20 1:59 PM, Richard Biener wrote:
On 18/06/20 08:55 +0100, Richard Sandiford wrote:
Sebastian Huber writes:
On 18/06/2020 09:09, Richard Sandiford wrote:
Sebastian Huber writes:
On 16/06/2020 12:42, Richard Sandiford wrote:
[...]
2020-06-16 Richard Sandiford
gcc/
* coretypes.h (first_type): New alias template.
On 18/06/20 07:34 +0100, Richard Sandiford wrote:
Thanks for the comments, just had a question about one of them…
Jonathan Wakely writes:
On 16/06/20 15:14 +0100, Richard Sandiford wrote:
Martin Li?ka writes:
On 6/16/20 10:50 AM, Richard Sandiford wrote:
Hmm, sounds like a nice abstraction
This avoids early assembler output via the gimplifier creating
new static CTORs. The output machinery seems to be prepared to
output constants recursively and it's just a matter of
appropriately defering or not defering output.
This also has the advantage of not outputting .string for
optimized a
This just changes Optimize_Length_Comparison to accept 32-bit values in
the full unsigned range, so that the length of all arrays with a 32-bit
or smaller index can be optimized.
Tested on x86_64-pc-linux-gnu, committed on trunk
2020-06-18 Eric Botcazou
gcc/ada/
* exp_ch4.adb (Optimi
The Get_Integer_Type function is used by the expander when generating
code for the Enum_Rep and Pos attributes applied to an enumeration type.
The expansion generates a direct conversion from the enumeration type
to the result type, which is nominally Universal_Integer; therefore,
in order to prese
An assignment with a slice indexed by a subtype_indication, e.g.:
Y : T := X (Positive range Low .. High);
is expanded into:
[subtype S is Positive range Low .. High;]
Y : S := X (Positive range Low .. High);
The bounds of the target subtype S were queried with Scalar_Range, which
migh
The definition of constants can be nested inside declare expressions in
which case they cannot be considered as valid contexts for calls to
volatile functions and access to volatile variable.
Tested on x86_64-pc-linux-gnu, committed on trunk
2020-06-18 Claire Dross
gcc/ada/
* sem_uti
This patch implements storage streams, as specified by three Ada Issues:
AI12-0293-1, AI12-0329-1, and AI12-0361-1.
Tested on x86_64-pc-linux-gnu, committed on trunk
2020-06-18 Bob Duff
gcc/ada/
* libgnat/a-strsto.ads, libgnat/a-ststbo.adb,
libgnat/a-ststbo.ads, libgnat/a-sts
Aspect Relaxed_Initialization and attribute Initialized are now listed
as implementation-defined with a reference to the SPARK RM, where their
full description will appear shortly.
Tested on x86_64-pc-linux-gnu, committed on trunk
2020-06-18 Piotr Trojanek
gcc/ada/
* doc/gnat_rm/impl
Not treating 'pragma Compile_Time_Warning' warnings as errors even with
the -gnatwe switch makes sense because if users desire errors, they
can use the Compile_Time_Error pragma.
Tested on x86_64-pc-linux-gnu, committed on trunk
2020-06-18 Ghjuvan Lacambre
gcc/ada/
* erroutc.ads: Dec
The frontend does not report an error on the illegal use of a non
class-wide subprogram with class-wide aspects Input and Output;
similarly it also skips reporting the error when a class-wide subprogram
is used with the non class-wide aspects. As a consequence of not
reporting these errors at comp
This adds a second warning related to the new C_Variadic_n convention,
for the cases where the aspect/pragma is applied to a subprogram with
exactly n parameters since, in this case, the aspect/pragma is useless.
The warning is given as such:
btest.ads:16:05: warning: subprogram should have at le
The main goal of this change is to improve the evaluation at compile
time of the ranges of values that an expression can have at run time
and to apply it in as many cases as possible during the compilation.
It turns out that the front-end contains two separate engines that
can evaluate value range
This ACATS test shows that:
- GNAT does not allow a named access type in the universal access
"=" operator.
- GNAT does not enforce the static matching requirement for designated
elementary and array types.
- GNAT does not allow designated types where one covers the other.
- GNAT does not enfo
The check applied to the expression of the To_Address attribute in
the case where it is static is done with the address size of the
host instead of the target, resulting in missing error messages.
Tested on x86_64-pc-linux-gnu, committed on trunk
2020-06-18 Eric Botcazou
gcc/ada/
* s
This makes a couple of changes in the code dealing with a call to a
derived subprogram: first, it removes useless calls to Relocate_Node
before calls to OK_Convert_To and Unchecked_Convert_To (these functions
already call Relocate_Node on their second operand) and merge calls to
Analyze and Resolve
GNAT does not count warnings originating from a Compile_Time_Warning
pragma as an error anymore, even if the -gnatwe flag is provided. This
requires updating the output of its error summary.
Tested on x86_64-pc-linux-gnu, committed on trunk
2020-06-18 Ghjuvan Lacambre
gcc/ada/
* erro
Currently we provide a separate implementation of Stream_Attributes via
s-stratt__xdr.adb which needs to be recompiled manually.
This change introduces instead a new binder switch to choose at bind
time which stream implementation to use and replaces s-stratt__xdr.adb
by a new unit System.Stream_A
The goal of this enhancement is to make it possible for the expander
to rewrite both arithmetic and comparison operations that have been
resolved to a large type, namely Universal_Integer, into equivalent
operations in a smaller type, namely Integer (or Long_Long_Integer).
In certain contexts invo
Default initialization is not performed when an imported object is
declared, so there should also be no Default_Initial_Condition check
generated for such an object declaration.
Tested on x86_64-pc-linux-gnu, committed on trunk
2020-06-18 Steve Baird
gcc/ada/
* exp_ch3.adb (Expand_N_
This consolidates the constraint checking code for allocators in only
two places, Expand_Allocator_Expression for the qualified expression
case and Expand_N_Allocator for the subtype indication case, getting
rid of some duplication and plugging some loopholes in the process.
Tested on x86_64-pc-li
This fixes a few minor glitches in the part of the expander dealing
with attributes: missing check for Component_Size, alphabetization
issues and wrong classification of few other attributes.
No functional changes.
Tested on x86_64-pc-linux-gnu, committed on trunk
2020-06-18 Eric Botcazou
gc
AI12-0032 modifies/clarifies many of the rules pertaining to uses of the
Old attribute. Most of these 7 changes were already implemented by GNAT
but a couple having to do with accessibility were not. Implement those
unimplemented rules.
Tested on x86_64-pc-linux-gnu, committed on trunk
2020-06-18
The procedure Expand_Array_Equality has an optimization whereby the
equality operation for an array of 2 elements is expanded into a
simple conjunction of two component comparisons instead of into
the generic loop.
But this special circuitry reuses the same expression list for the
indexed componen
This test shows that GNAT was missing formal subprogram conformance
checking in some cases, now fixed.
Tested on x86_64-pc-linux-gnu, committed on trunk
2020-06-18 Arnaud Charlet
gcc/ada/
* sem_ch6.ads, sem_ch6.adb (Check_Formal_Conformance): New
subprogram.
(Check_Co
The procedure Get_Size_For_Range does not need to return the smallest
size for a signed integer type covering the range, the important thing
is instead to return a size lower than that of the original type; this
saves a bunch of lookups in the power-of-two table of the Uint unit.
The change also b
On 18/06/20 10:02 +0100, Jonathan Wakely wrote:
On 18/06/20 08:55 +0100, Richard Sandiford wrote:
Sebastian Huber writes:
On 18/06/2020 09:09, Richard Sandiford wrote:
Sebastian Huber writes:
On 16/06/2020 12:42, Richard Sandiford wrote:
[...]
2020-06-16 Richard Sandiford
gcc/
On 6/18/20 11:02 AM, Martin Liška wrote:
Now I've got it.
I've just reduced that to:
$ cat pr50310.c
double s1[4], s2[4], s3[64];
int
main ()
{
s1[0] = 5.0;
s1[1] = 6.0;
s1[2] = 5.0;
s1[3] = __builtin_nan ("");
s2[0] = 6.0;
s2[1] = 5.0;
s2[2] = 5.0;
s2[3] = 5.0;
asm volatil
Hi!
As the following testcase shows, the exception for the aarch64
vec_pack_trunc_di is not sufficient on x86, the halfvectype
"vectors" have SImode but the x86 vec_pack_trunc_si meant for
the bool bitmasks combines 2x SImode into DImode, while in the
testcase the halfvectype is 1x SImode "vector"
Hi!
As discussed in the PR, the
x < 0x8000U to (int) x >= 0
optimization stands in the way of minmax_replacement optimization,
so for comparisons with most of the constants it works well, but when the
above mentioned optimization triggers, it is unable to do it.
The match.pd (cond (cmp (conver
On Thu, Jun 18, 2020 at 11:08:53AM +0200, Richard Biener wrote:
> This avoids early assembler output via the gimplifier creating
> new static CTORs. The output machinery seems to be prepared to
> output constants recursively and it's just a matter of
> appropriately defering or not defering output
nline/install/opt/codesourcery/x86_64-none-linux-gnu/bin --with-build-time-tools=/net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/install/opt/codesourcery/x86_64-none-linux-gnu/bin SED=sed
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 17 June 2020 17:17
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH][GCC-10 Backport] arm: Fix MVE scalar shift intrinsics code-
> gen.
>
> Hello,
>
> This patch modifies the MVE scalar shift RTL patterns.
On 18/06/20 00:55 +0100, Jonathan Wakely wrote:
Does your reverse iterator work correctly? It looks to me like it will
fail to visit the region_begin statement, because this loop will
terminate when the reverse iterator reaches the end() value, and will
not actually process that gsi:
- gimp
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 17 June 2020 18:32
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH][GCC-10 Backport] arm: Fix the MVE ACLE vaddq_m
> polymorphic variants.
>
> Hello,
>
> This patch fixes the MVE ACLE vaddq_m polymorphic v
On Thu, 18 Jun 2020, Jakub Jelinek wrote:
> Hi!
>
> As the following testcase shows, the exception for the aarch64
> vec_pack_trunc_di is not sufficient on x86, the halfvectype
> "vectors" have SImode but the x86 vec_pack_trunc_si meant for
> the bool bitmasks combines 2x SImode into DImode, whil
On Thu, 18 Jun 2020, Jakub Jelinek wrote:
> Hi!
>
> As discussed in the PR, the
> x < 0x8000U to (int) x >= 0
> optimization stands in the way of minmax_replacement optimization,
> so for comparisons with most of the constants it works well, but when the
> above mentioned optimization trigger
Richard Biener writes:
> On Thu, 18 Jun 2020, Jakub Jelinek wrote:
>
>> Hi!
>>
>> As the following testcase shows, the exception for the aarch64
>> vec_pack_trunc_di is not sufficient on x86, the halfvectype
>> "vectors" have SImode but the x86 vec_pack_trunc_si meant for
>> the bool bitmasks com
On Thu, 18 Jun 2020, Jakub Jelinek wrote:
> On Thu, Jun 18, 2020 at 11:08:53AM +0200, Richard Biener wrote:
> > This avoids early assembler output via the gimplifier creating
> > new static CTORs. The output machinery seems to be prepared to
> > output constants recursively and it's just a matter
On Thu, Jun 18, 2020 at 12:03:26PM +0200, Richard Biener wrote:
> Shortly thought about it but then went with int because of the
> pre-existing interface of output_constant_def which "interferes"
> with this (ripples down into users in expr.c as well).
>
> If you insist I'll hunt them all down ...
On Jun 18, 2020, Tobias Burnus wrote:
> On 6/18/20 8:10 AM, Alexandre Oliva wrote:
>> Could you possibly give this *completely* untested patch a try and let
>> me know whether it does any good?
> Otherwise, see attachment. I now added also the @/tmp file which is
> passed to mkoffload.
Thanks.
Howdy.
This moves all the simplification code from vr_values into a separate
class (simplify_using_ranges). In doing so, we get rid of a bunch of
dependencies on the internals of vr_values. The goal is to (a) remove
unnecessary interdependendcies (b) be able to use this engine with any
rang
FTR, I'm running into this ICE when attempting to build the Linux Kernel
for arm64.
More specifically:
/repos/linux-arm/kernel/bpf/core.c:1368:1: internal compiler error:
‘global_options’ are modified in local context
1368 | {
| ^
0xc0554b cl_optimization_compare(gcc_options*, gcc_opti
This delays asm_out_file initialization to until after IPA.
OK, not actually for LTO for which the situation is more complicated
since during IPA phases we write LTO IL and very early we output
early debug DIEs.
The RTL FE bits are a bit ugly and require checking for
multiple invocations of init_a
On 6/18/20 12:39 PM, Alexandre Oliva wrote:
Thanks. I see the main problem besides the dumppfx constness is the
double dot before target, fixed in the revised patch below.
With this, I think the libgomp testsuite might work with offloading
again.
Thanks. I have only tried the first one of the
The patch addresses need to generate ChangeLog for a vendor branch
(redhat/gcc-10-branch) that can contain merge commits.
Tested on c518050989be3a224a04a8b33d73f37a16c30fbb and current active branches.
Jakub: Can you please test it?
Martin
contrib/ChangeLog:
* gcc-changelog/git_update_
On 6/18/20 1:32 PM, Luis Machado wrote:
FTR, I'm running into this ICE when attempting to build the Linux Kernel for
arm64.
Hello.
Thanks for the report.
More specifically:
/repos/linux-arm/kernel/bpf/core.c:1368:1: internal compiler error:
‘global_options’ are modified in local context
On Thu, Jun 18, 2020 at 02:16:32PM +0200, Martin Liška wrote:
> The patch addresses need to generate ChangeLog for a vendor branch
> (redhat/gcc-10-branch) that can contain merge commits.
>
> Tested on c518050989be3a224a04a8b33d73f37a16c30fbb and current active
> branches.
> Jakub: Can you please
On 6/18/20 2:28 PM, Jakub Jelinek wrote:
On Thu, Jun 18, 2020 at 02:16:32PM +0200, Martin Liška wrote:
The patch addresses need to generate ChangeLog for a vendor branch
(redhat/gcc-10-branch) that can contain merge commits.
Tested on c518050989be3a224a04a8b33d73f37a16c30fbb and current active
This fixes an order of commands.
Installed to master.
contrib/ChangeLog:
* gcc-changelog/git_update_version.py: First checkout and then
run git pull ---rebase.
---
contrib/gcc-changelog/git_update_version.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/co
This fixes the omission of moving the expansion result to the
target.
Bootstrapped and tested on x86_64-unknown-linux-gnu, fixes the
observed -m32 FAIL.
2020-06-18 Richard Biener
PR middle-end/95739
* internal-fn.c (expand_vect_cond_optab_fn): Move the result
to the ta
I'm pushing the following fix that caused occasional ICEs:
gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr68714.c -O3 -c
during GIMPLE pass: reassoc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr68714.c: In
function ‘f’:
/home/marxin/Programming/gcc/gcc/testsuit
On 6/18/20 2:47 PM, Richard Biener wrote:
This fixes the omission of moving the expansion result to the
target.
Thank you for the fix, it's new for me that this can happen.
Martin
Bootstrapped and tested on x86_64-unknown-linux-gnu, fixes the
observed -m32 FAIL.
2020-06-18 Richard Biener
OpenMP 4.5 does not permit allocatable components in
list items of the map clause. (OpenMP 5 does.)
As OpenMP 5 support is not implemented, let's avoid
generating wrong code by diagnosing this (until
implemented).
OK?
Tobias
PS: I wonder whether something similar is needed
for 'private' and 'fi
On Thu, Jun 18, 2020 at 03:08:53PM +0200, Tobias Burnus wrote:
> OpenMP 4.5 does not permit allocatable components in
> list items of the map clause. (OpenMP 5 does.)
> As OpenMP 5 support is not implemented, let's avoid
> generating wrong code by diagnosing this (until
> implemented).
>
> OK?
Ok
Hello,
In GCC testsuite the MVE scalar shift execution tests
(mve_scalar_shifts[1-4].c) are failings
because of executing them on target hardware which doesn't support MVE
instructions. This patch
restricts those tests to execute only on target hardware that support MVE
instructions.
Regressio
Hi,
On Thu, 18 Jun 2020 at 15:30, Srinath Parvathaneni
wrote:
>
> Hello,
>
> In GCC testsuite the MVE scalar shift execution tests
> (mve_scalar_shifts[1-4].c) are failings
> because of executing them on target hardware which doesn't support MVE
> instructions. This patch
> restricts those tes
This patch is now backported to the devel/omp/gcc-10 branch.
Andrew
On 17/06/2020 10:13, Andrew Stubbs wrote:
This upgrades the compiler to emit HSA Code Object v3 binaries. This
means changing the assembler directives, and linker command line options.
The gcn-run and libgomp loaders need co
On Thu, Jun 18, 2020 at 10:21:00AM +0200, Martin Liška wrote:
> All right, let's do it better.
Thanks!
(Btw, the MIME sub-type of "x-patch" makes this unviewable on many
browsers, in the gcc-patches@ archive (and unusable in many mail
clients of course). Anything "x-*" should never be used on pu
Hi,
On Wed, 17 Jun 2020 at 15:16, Patrick Palka via Gcc-patches
wrote:
>
> The recent PR41437 fix exposed a latent use of an inaccessible member in
> the below testcase.
>
> Committed as obvious after verifying that the testcase no longer fails to
> compile due to the reported access error.
>
I'
Hi,
> -Original Message-
> From: Christophe Lyon
> Sent: 18 June 2020 14:38
> To: Srinath Parvathaneni
> Cc: gcc Patches
> Subject: Re: [PATCH][GCC] arm: Fix the failing mve scalar shift execution
> tests.
>
> Hi,
>
>
> On Thu, 18 Jun 2020 at 15:30, Srinath Parvathaneni
> wrote:
>
On 6/18/20 11:43 AM, Jonathan Wakely wrote:
On 18/06/20 00:55 +0100, Jonathan Wakely wrote:
Does your reverse iterator work correctly? It looks to me like it will
fail to visit the region_begin statement, because this loop will
terminate when the reverse iterator reaches the end() value, and wil
On 18/06/20 16:25 +0200, Martin Liška wrote:
On 6/18/20 11:43 AM, Jonathan Wakely wrote:
On 18/06/20 00:55 +0100, Jonathan Wakely wrote:
Does your reverse iterator work correctly? It looks to me like it will
fail to visit the region_begin statement, because this loop will
terminate when the rev
On Thu, 18 Jun 2020, Christophe Lyon wrote:
> Hi,
>
> On Wed, 17 Jun 2020 at 15:16, Patrick Palka via Gcc-patches
> wrote:
> >
> > The recent PR41437 fix exposed a latent use of an inaccessible member in
> > the below testcase.
> >
> > Committed as obvious after verifying that the testcase no lo
In the recent fix to avoid false positives due to compute_objsize
(PR 95353) where I removed the call to compute_builtin_object_size
when computing object sizes for calls to string functions like
strcpy, I kept it out of a misplaced abundance of caution when
doing the same for the more permissive
On Thu, 2020-06-18 at 14:21 +0200, Martin Liška wrote:
> On 6/18/20 1:32 PM, Luis Machado wrote:
> > FTR, I'm running into this ICE when attempting to build the Linux Kernel
> > for arm64.
>
> Hello.
>
> Thanks for the report.
>
> > More specifically:
> >
> > /repos/linux-arm/kernel/bpf/core.c
Hi,
On Thu, 18 Jun 2020 at 11:43, Kyrylo Tkachov wrote:
>
>
>
> > -Original Message-
> > From: Srinath Parvathaneni
> > Sent: 17 June 2020 17:17
> > To: gcc-patches@gcc.gnu.org
> > Cc: Kyrylo Tkachov
> > Subject: [PATCH][GCC-10 Backport] arm: Fix MVE scalar shift intrinsics code-
> > ge
This ICE-on-invalid goes back to GCC 6. In finish_template_variable,
if coerce_innermost_template_parms returns error_mark_node, we pass
it down to constraints_satisfied_p and that error_mark_node flows
down to various satisfy_* functions and then to various tsubst_*
functions, where we crash. di
On Thu, 2020-06-18 at 08:56 -0600, Martin Sebor via Gcc-patches wrote:
> In the recent fix to avoid false positives due to compute_objsize
> (PR 95353) where I removed the call to compute_builtin_object_size
> when computing object sizes for calls to string functions like
> strcpy, I kept it out of
On Thu, 18 Jun 2020 at 16:56, Patrick Palka wrote:
>
> On Thu, 18 Jun 2020, Christophe Lyon wrote:
>
> > Hi,
> >
> > On Wed, 17 Jun 2020 at 15:16, Patrick Palka via Gcc-patches
> > wrote:
> > >
> > > The recent PR41437 fix exposed a latent use of an inaccessible member in
> > > the below testcase
Hi,
> -Original Message-
> From: Christophe Lyon
> Sent: 18 June 2020 16:06
> To: Kyrylo Tkachov
> Cc: Srinath Parvathaneni ; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH][GCC-10 Backport] arm: Fix MVE scalar shift intrinsics
> code-gen.
>
> Hi,
>
> On Thu, 18 Jun 2020 at 11:43, Ky
On 6/18/20 5:02 PM, Jeff Law wrote:
On Thu, 2020-06-18 at 14:21 +0200, Martin Liška wrote:
On 6/18/20 1:32 PM, Luis Machado wrote:
FTR, I'm running into this ICE when attempting to build the Linux Kernel for
arm64.
Hello.
Thanks for the report.
More specifically:
/repos/linux-arm/kernel/
I see the following ICE for aarch64 kernel build:
$ cat neon.i
#pragma GCC push_options
#pragma GCC target "arch=armv8.2-a+bf16"
#pragma GCC pop_options
$ ./xgcc -B. ~/Programming/testcases/neon.i -c -mbranch-protection=pac-ret
/home/marxin/Programming/testcases/neon.i:3:9: internal compiler err
On Thu, 18 Jun 2020 at 17:34, Srinath Parvathaneni
wrote:
>
> Hi,
>
> > -Original Message-
> > From: Christophe Lyon
> > Sent: 18 June 2020 16:06
> > To: Kyrylo Tkachov
> > Cc: Srinath Parvathaneni ; gcc-
> > patc...@gcc.gnu.org
> > Subject: Re: [PATCH][GCC-10 Backport] arm: Fix MVE scal
On 6/18/20 11:11 AM, Marek Polacek wrote:
This ICE-on-invalid goes back to GCC 6. In finish_template_variable,
if coerce_innermost_template_parms returns error_mark_node, we pass
it down to constraints_satisfied_p and that error_mark_node flows
down to various satisfy_* functions and then to var
On 6/18/20 12:40 PM, Martin Liška wrote:
I see the following ICE for aarch64 kernel build:
$ cat neon.i
#pragma GCC push_options
#pragma GCC target "arch=armv8.2-a+bf16"
#pragma GCC pop_options
$ ./xgcc -B. ~/Programming/testcases/neon.i -c -mbranch-protection=pac-ret
/home/marxin/Programming/t
On 6/18/20 5:47 PM, Luis Machado wrote:
That's another one I noticed alongside the first one I reported. That's good
that you managed to reproduce it.
Can you please send me your .config and I can reproduce that locally.
Thanks,
Martin
On Wed, 2020-06-17 at 14:46 -0500, Bill Schmidt wrote:
> I posted a version of these patches back in stage 4 (February),
> but we agreed that holding off until stage 1 was a better idea.
> Since then I've made more progress and reorganized the patches
> accordingly. This group of patches lays grou
Hi,
> -Original Message-
> From: Christophe Lyon
> Sent: 18 June 2020 16:44
> To: Srinath Parvathaneni
> Cc: gcc-patches@gcc.gnu.org; Kyrylo Tkachov
> Subject: Re: [PATCH][GCC-10 Backport] arm: Fix MVE scalar shift intrinsics
> code-gen.
>
> On Thu, 18 Jun 2020 at 17:34, Srinath Parvat
On 6/18/20 1:02 PM, Martin Liška wrote:
On 6/18/20 5:47 PM, Luis Machado wrote:
That's another one I noticed alongside the first one I reported.
That's good that you managed to reproduce it.
Can you please send me your .config and I can reproduce that locally.
Thanks,
Martin
Here it is. It
Hello Jeff,
pinging the patch.
Regards,
Paul.
On 3/26/20 01:49, Jeff Law wrote:
> On Mon, 2020-02-10 at 19:22 +0300, Paul Gofman wrote:
>> ChangeLog:
>> PR target/91489
>> * config/i386/i386.md (simple_return): Also check
>> for ms_hook_prologue function attribute.
>>
The mode of ZERO_EXTRACT RTX should match the mode of its LOC register
operand. The mode should be HI, SI or DImode to enable combine to synthesize
extractions from HImode and DImode operands, in addition to existing SImode.
Further, these changes tighten allowed modes for extv, extzv and insv
nam
Hi!
On Tue, 9 Jun 2020 12:41:21 +0200
Thomas Schwinge wrote:
> Hi Julian!
>
> On 2020-06-05T21:31:08+0100, Julian Brown
> wrote:
> > On Fri, 5 Jun 2020 13:17:09 +0200
> > Thomas Schwinge wrote:
> >> On 2019-12-17T21:03:47-0800, Julian Brown
> >> wrote:
> >> > This part contains the libgo
From: Nicholas Krause
Changelog:gcc/
*var-tracking.c(variable_tracking_main): Update
numbers for both number of basic blocks per
function and number of edges per function to
basic blocks to more sane numbers, in order to
avoid extra edge cases.
Signed-of
On 6/18/20 7:18 PM, Luis Machado wrote:
On 6/18/20 1:02 PM, Martin Liška wrote:
On 6/18/20 5:47 PM, Luis Machado wrote:
That's another one I noticed alongside the first one I reported. That's good
that you managed to reproduce it.
Can you please send me your .config and I can reproduce that
1 - 100 of 121 matches
Mail list logo
