Hi all,
In some targets, initialization code for char array may be split into two
parts even if the initialization consists of all zeros:
/* example */
extern void foo(char*);
void test(void) {
char a[256] = { 0, 0, 0, 0, 0, 0, 0, 0, 0 };
foo(a);
}
;; Xtensa (xtensa-lx106)
.LC0:
Hi Haochen,
on 2022/5/31 09:52, HAO CHEN GUI wrote:
> Hi,
>This patch adds V1TI mode into a new mode iterator used in vector
> comparison shift and rotation expands. Without the patch, the comparisons
> between two vector __int128 are converted to scalar comparisons and
> code is suboptimal.
Hi,
This patch adds V1TI mode into a new mode iterator used in vector
comparison shift and rotation expands. Without the patch, the comparisons
between two vector __int128 are converted to scalar comparisons and
code is suboptimal. The patch fixes the issue. Now all comparisons
between two
On Linux/x86_64,
43201f2c2173894bf7c423cad6da1c21567e06c0 is the first bad commit
commit 43201f2c2173894bf7c423cad6da1c21567e06c0
Author: Roger Sayle
Date: Mon May 30 21:20:09 2022 +0100
PR target/70321: Split double word equality/inequality after STV on x86.
caused
FAIL:
On 5/30/2022 2:28 AM, Richard Sandiford wrote:
Jeff Law via Gcc-patches writes:
On 5/29/2022 3:43 PM, H.J. Lu wrote:
On Sat, May 28, 2022 at 11:37 AM Jeff Law via Gcc-patches
wrote:
On 5/26/2022 2:43 PM, H.J. Lu via Gcc-patches wrote:
On Thu, May 26, 2022 at 04:14:17PM +0100, Richard
Hi
Here is the patch to use cxx11 abi for the versioned namespace mode.
It is still suffering from a side effect on gdb pretty printers with 3
errors like:
got: type =
std::unique_ptrstd::__8::char_traits, std::__8::allocator >>[]>>[99]>
FAIL: libstdc++-prettyprinters/80276.cc whatis p4
Hi Tobias,
Am 30.05.22 um 09:33 schrieb Tobias Burnus:
On 28.05.22 22:25, Harald Anlauf via Fortran wrote:
the PR rightfully complained that we did not differentiate errors on
ALLOCATE(...,stat=,errmsg=) for failures from allocation of already
allocated objects or insufficient virtual memory.
On Mon, May 30, 2022 at 10:12 PM Uros Bizjak wrote:
>
> On Mon, May 30, 2022 at 3:22 PM Roger Sayle
> wrote:
> >
> >
> > This patch is a form of insurance policy in case my patch for PR 7061 runs
> > into problems on non-x86 targets; the middle-end can add an extra check
> > that the backend is
On Mon, May 30, 2022 at 3:22 PM Roger Sayle wrote:
>
>
> This patch is a form of insurance policy in case my patch for PR 7061 runs
> into problems on non-x86 targets; the middle-end can add an extra check
> that the backend is happy placing SCmode and DImode values in the same
> register, before
On Mon, May 30, 2022 at 7:50 PM Roger Sayle wrote:
>
>
> This patch resolves PR rtl-optimization/101617 where we should generate
> the exact same code for (X ? -1 : 1) as we do for ((X ? -1 : 0) | 1).
> The cause of the current difference on x86_64 is actually in
> ix86_expand_int_movcc that
i386: Remove constraints when used with constant integer predicates, take 2
const_int_operand and other const*_operand predicates do not need
constraints when the constraint is inherited from the range of
constant integer predicate. Remove the constraint in case all
alternatives use the same
This patch resolves PR rtl-optimization/101617 where we should generate
the exact same code for (X ? -1 : 1) as we do for ((X ? -1 : 0) | 1).
The cause of the current difference on x86_64 is actually in
ix86_expand_int_movcc that doesn't know that negl;sbbl can be used
to create a -1/0 result
On Mon, May 30, 2022 at 10:43:30PM +0800, Chung-Lin Tang wrote:
> > This feels like you only accept a single allocator in the new syntax,
> > but that isn't my reading of the spec, I'd understand it as:
> > uses_allocators (memspace(omp_high_bw_mem_space), traits(foo_traits) : bar,
> > baz, qux)
On Fri, May 27, 2022 at 02:04:11AM +0200, Mohamed Atef wrote:
> libgomp/ChangeLog
>
> 2022-05-27 Mohamed Atef
>
> * libgompd.map (ompd_get_display_control_vars,
> ompd_rel_display_control_vars): New global symbol versions.
> * env.c: (gompd_buffer, gompd_env_buff_size): New Variables.
>
On 5/30/22 09:27, Aldy Hernandez wrote:
Now that we have generic ranges, we need a way to define generic local
temporaries on the stack for intermediate calculations in the ranger
and elsewhere. We need temporaries analogous to int_range_max, but
for any of the supported types (currently just
On 5/30/2022 7:46 AM, Roger Sayle wrote:
GCC's middle-end provides a default cost model for RTL expressions, for
backends that don't specify their own instruction timings, that can be
summarized as multiplications are COSTS_N_INSNS(4), divisions are
COSTS_N_INSNS(7) and all other operations
Hi Jakub,
this is v3 of the uses_allocators patch.
On 2022/5/20 1:46 AM, Jakub Jelinek wrote:
On Tue, May 10, 2022 at 07:29:23PM +0800, Chung-Lin Tang wrote:
@@ -15624,6 +15626,233 @@ c_parser_omp_clause_allocate (c_parser *parser, tree
list)
return nl;
}
+/* OpenMP 5.2:
+
GCC's middle-end provides a default cost model for RTL expressions, for
backends that don't specify their own instruction timings, that can be
summarized as multiplications are COSTS_N_INSNS(4), divisions are
COSTS_N_INSNS(7) and all other operations are COSTS_N_INSNS(1).
This patch tweaks the
Finally, the meat of the work. Convert ranger and associated clients
to vrange.
Everything's relatively mechanical given the previous patches. I did
include a minor cleanup in the edge code. There's no need to check
that the type of the switch is an integer as non-integer switches are
invalid.
This patch provides the infrastructure to make range-ops type agnostic.
First, the range_op_handler function has been replaced with an object
of the same name. It's coded in such a way to minimize changes to the
code base, and to encapsulate the dispatch code.
Instead of:
This patch revamps the range allocator to handle generic vrange's.
I've cleaned it up somehow to make it obvious the various things you
can allocate with it. I've also moved away from overloads into
distinct names when appropriate.
The various entry points are now:
// Allocate a range of
Now that we have generic ranges, we need a way to define generic local
temporaries on the stack for intermediate calculations in the ranger
and elsewhere. We need temporaries analogous to int_range_max, but
for any of the supported types (currently just integers, but soon
integers, pointers, and
This is a series of patches making ranger type agnostic in preparation
for contributing support for other types of ranges (pointers and
floats initially).
The first step in this process is to implement vrange, an abstract
class that will be exclusively used by ranger, and from which all
ranges
This patch is a form of insurance policy in case my patch for PR 7061 runs
into problems on non-x86 targets; the middle-end can add an extra check
that the backend is happy placing SCmode and DImode values in the same
register, before creating a SUBREG. Unfortunately, ix86_modes_tieable_p
In unswitching we use ranger to simplify switch statements so we
have to avoid doing anything for abnormals.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2022-05-30 Richard Biener
PR tree-optimization/105763
* tree-ssa-loop-unswitch.cc
On Sun, May 29, 2022 at 5:59 PM Di Zhao OS
wrote:
>
> Hi, attached is a new version of the patch. The changes are:
> - Skip using temporary equivalences for floating-point values, because
> folding expressions can generate incorrect values. For example,
> operations on 0.0 and -0.0 may have
On Fri, May 27, 2022 at 9:34 PM Andi Kleen via Gcc-patches
wrote:
>
> Andrew MacLeod via Gcc-patches writes:
> >
> > diff --git a/gcc/gimple-range-side-effect.cc
> > b/gcc/gimple-range-side-effect.cc
> > index 2c8c77dc569..548e4bea313 100644
> > --- a/gcc/gimple-range-side-effect.cc
> > +++
Whilst investigating PR 55278, I noticed that the tree-ssa optimizers
aren't eliminating the promotions of shifts to "int" as inserted by the
c-family front-ends, instead leaving this simplification to be left to
the RTL optimizers. This patch allows match.pd to do this itself earlier,
narrowing
On Sat, May 28, 2022 at 7:52 AM Alexandre Oliva via Gcc-patches
wrote:
>
>
> The patch for PR 100810 tested for undefined SSA_NAMEs appearing
> directly in the base expression of the potential IV candidate, but
> that's not enough. The testcase for PR105665 shows an undefined
> SSA_NAME has the
On Fri, Dec 10, 2021 at 05:37:34PM +, Kwok Cheung Yeung wrote:
> From e9bb138d4c3f560e48e408facce2361533685a98 Mon Sep 17 00:00:00 2001
> From: Kwok Cheung Yeung
> Date: Mon, 6 Dec 2021 22:58:01 +
> Subject: [PATCH 5/7] openmp: Add C++ support for parsing metadirectives
>
> This adds
On Fri, Dec 10, 2021 at 05:36:20PM +, Kwok Cheung Yeung wrote:
> 2021-12-10 Kwok Cheung Yeung
>
> gcc/
> * Makefile.in (OBJS): Add omp-expand-metadirective.o.
> * gimple-streamer-in.c (input_gimple_stmt): Add case for
> GIMPLE_OMP_METADIRECTIVE. Handle
On Fri, Dec 10, 2021 at 05:35:05PM +, Kwok Cheung Yeung wrote:
> 2021-12-10 Kwok Cheung Yeung
>
> gcc/
> * gimplify.c (expand_omp_metadirective): New.
> * omp-general.c: Include tree-pretty-print.h.
> (DELAY_METADIRECTIVES_AFTER_LTO): New macro.
>
On Fri, Dec 10, 2021 at 05:33:25PM +, Kwok Cheung Yeung wrote:
> 2021-12-10 Kwok Cheung Yeung
>
> gcc/
> * gimple-low.c (lower_omp_metadirective): New.
> (lower_stmt): Handle GIMPLE_OMP_METADIRECTIVE.
> * gimple-pretty-print.c (dump_gimple_omp_metadirective): New.
>
Hi Haochen,
on 2022/5/26 15:35, HAO CHEN GUI wrote:
> Hi,
> This patch fixes the ICE reported in PR100736. It removes the condition
> check of finite math only flag not setting in "*_cc" pattern.
> With or without this flag, we still can use "cror" to check if either
> two bits of CC is set or
Ping. I'd like to see libgccjit working on LoongArch so I would be able
to submit a Rust port to upstream.
If the result is NACK I'd like to know alternative approaches to fix the
build failure.
I doubt if "j...@gcc.gnu.org" is really used, so CC'ed the JIT maintainer
listed in MAINTAINERS.
On
This patch addresses the issue in comment #6 of PR rtl-optimization/7061
(a four digit PR number) from 2006 where on x86_64 complex number arguments
are unconditionally spilled to the stack.
For the test cases below:
float re(float _Complex a) { return __real__ a; }
float im(float _Complex a) {
Hi Haochen,
on 2022/5/18 16:52, HAO CHEN GUI wrote:
> Hi,
> This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000.
> Tests show that outputs of xs[min/max]dp are consistent with the standard
> of C99 fmin/max.
>
> This patch also binds __builtin_vsx_xs[min/max]dp to
On Mon, 30 May 2022, Hongtao Liu wrote:
> On Mon, May 30, 2022 at 3:44 PM Alexander Monakov wrote:
> >
> > On Mon, 30 May 2022, Hongtao Liu wrote:
> >
> > > On Mon, May 30, 2022 at 2:22 PM Alexander Monakov via Gcc-patches
> > > wrote:
> > > > >
> > > > > The spill is mainly decided by 3 insns
On Mon, May 30, 2022 at 11:18 AM Uros Bizjak wrote:
>
> On Mon, May 30, 2022 at 11:11 AM Roger Sayle
> wrote:
> >
> >
> > Hi Uros,
> > This is a ping of my patch from April, which as you've suggested should be
> > submitted
> > for review even if there remain two missed-optimization regressions
On Mon, May 30, 2022 at 11:11 AM Roger Sayle wrote:
>
>
> Hi Uros,
> This is a ping of my patch from April, which as you've suggested should be
> submitted
> for review even if there remain two missed-optimization regressions on ia32
> (to
> allow reviewers to better judge if those fixes are
Hi Uros,
This is a ping of my patch from April, which as you've suggested should be
submitted
for review even if there remain two missed-optimization regressions on ia32
(to
allow reviewers to better judge if those fixes are appropriate/the best
solution).
> > In order to build GNAT, the Ada compiler, you need a working GNAT
> > -compiler (GCC version 4.7 or later).
> > +compiler (GCC version 5.1 or later).
> >
> > This includes GNAT tools such as @command{gnatmake} and
> > @command{gnatlink}, since the Ada front end is written in Ada and
>
>
"H.J. Lu" writes:
> On Thu, May 26, 2022 at 04:14:17PM +0100, Richard Sandiford wrote:
>> "H.J. Lu" writes:
>> > On Wed, May 25, 2022 at 12:30 AM Richard Sandiford
>> > wrote:
>> >>
>> >> "H.J. Lu via Gcc-patches" writes:
>> >> > On Mon, May 23, 2022 at 12:38:06PM +0200, Richard Biener wrote:
On Mon, May 30, 2022 at 3:44 PM Alexander Monakov wrote:
>
> On Mon, 30 May 2022, Hongtao Liu wrote:
>
> > On Mon, May 30, 2022 at 2:22 PM Alexander Monakov via Gcc-patches
> > wrote:
> > > >
> > > > The spill is mainly decided by 3 insns related to r92
> > > >
> > > > 283(insn 3 61 4 2 (set
Code cleanup; semantics is unaffected.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* osint.adb (Locate_File): Change variable to constant and
initialize it by concatenation of directory, file name and NUL.diff --git a/gcc/ada/osint.adb b/gcc/ada/osint.adb
---
Without this patch, gnat would use `-gnatw?` as the default option for
some of the default warnings.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* erroutc.adb (Get_Warning_Option): Don't consider `?` as a
valid option switch.diff --git a/gcc/ada/erroutc.adb
This enables better integration with tools that handle GNAT's output.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* erroutc.ads (Get_Warning_Option): New function returning the
option responsible for a warning if it exists.
* erroutc.adb
Remove a minor duplication in Post of a function of formal doubly linked
lists.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* libgnat/a-cfdlli.ads (Insert): Remove the duplication.diff --git a/gcc/ada/libgnat/a-cfdlli.ads b/gcc/ada/libgnat/a-cfdlli.ads
---
When implementing structural subprogram variants we ignored them in
expansion of the pragma itself, but not in expansion of a recursive
subprogram call. Now fixed.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* exp_ch6.adb (Check_Subprogram_Variant): Ignore structural
The GNAT behaviour regarding the Ada RM requirement to support Address
clauses for imported subprograms was documented twice: in section about
packed types (which was a mistake) and in section about address clauses
(where it belongs).
Cleanup related to the use of packed arrays for bitset
This enables tools that ingest GNAT's output to properly classify these
messages.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* inline.adb (Check_Package_Body_For_Inlining): Add insertion
character.diff --git a/gcc/ada/inline.adb b/gcc/ada/inline.adb
---
This enables tools that ingest GNAT's output to properly classify these
messages.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* freeze.adb (Warn_Overlay): Add 'o' insertion character.
* sem_ch13.adb (Analyze_Attribute_Definition_Clause): Likewise.
*
This caused tools ingesting GNAT's output to mislabel these messages.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_warn.adb (Warn_On_Useless_Assignment): Fix insertion
character.diff --git a/gcc/ada/sem_warn.adb b/gcc/ada/sem_warn.adb
---
This caused tools ingesting GNAT's output to mislabel these messages.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_disp.adb (Warn_On_Late_Primitive_After_Private_Extension):
Fix insertion character.diff --git a/gcc/ada/sem_disp.adb b/gcc/ada/sem_disp.adb
---
While cleaning up and modifying code for unreferenced warnings we
removed all calls to Defer_Reference, which was the only routine that
populated the Deferred_References table. Consequently, all the code
related to this table became dead.
Tested on x86_64-pc-linux-gnu, committed on trunk
This caused these warnings not to be tagged with the switch causing
them, which is an issue for tools ingesting GNAT's output.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_elab.adb (Process_Conditional_ABE_Access_Taken): Add '.f'
insertion characters.diff
This patch fixes a bug whereby if a function body has local objects that
are finalizable, and has a return statement that requires generation of
transient finalizable temps, and there are dynamic-sized objects
requiring pushing/popping the (primary) stack at run time, and the
function body has
This patch corrects an error in the compiler whereby spurious
unreferenced warnings are generated on formal parameters of null generic
subprograms.
These changes also fix the parsing of aspects on formal parameters such
that the aspects now get properly set for all formal parameters in a
Both the `System.Mmap` and `System.Object_Reader` packages are defining
entities named `Offset` and they are both `use`d at the top of
s-dwalin.adb.
Therefore, the references to `Offset` throughout this file are
ambiguous, and GNAT is supposed to complain. Since it does not for the
moment, we fix
The expression given in a Static_Predicate aspect specification is
required to be predicate-static. The implementation of this compile-time
check was incorrect in some cases. There were problems in both
directions: expressions that are not predicate-static were incorrectly
treated as though they
The presence of the discriminants prevents the values associated with the
components of the parent type from being put into the sub-aggregate built
for the _Parent component.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* exp_aggr.adb
The left-overs of the old freezing code in Make_DT are now redundant since
the semantic analyzer performs the same task for the 'Access attribute.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* exp_disp.adb (Make_DT): Remove remaining freezing code.diff --git
There is no need to analyze expression functions that are primitives of a
tagged type for its dispatch table because they will be analyzed at the end
of the current scope.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_attr.adb (Resolve_Attribute) : Don't analyze
To handle code common to the old and the new CCG code generator.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* gnat1drv.adb, opt.ads, sem_ch7.adb: Introduce CCG_Mode.diff --git a/gcc/ada/gnat1drv.adb b/gcc/ada/gnat1drv.adb
--- a/gcc/ada/gnat1drv.adb
+++
Changes in GNATprove (translation to Why3 and provers) result in proofs
being much less automatic, and requiring ghost code to detail
intermediate steps. In some cases, it is better to use the new By
mechanism to prove assertions in steps, as this avoids polluting the
proof context for other
Mention when security hardening features are available in other
languages.
Expand the strub documentation a little, for clarity and completeness.
Add missing 'aliased' and attribute to variables in strub example.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
*
Minor fix in a recently added comment.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* libgnat/a-cofuse.ads (Empty_Set): Fix typo in comment.diff --git a/gcc/ada/libgnat/a-cofuse.ads b/gcc/ada/libgnat/a-cofuse.ads
--- a/gcc/ada/libgnat/a-cofuse.ads
+++
When static dispatch tables are built for library-level tagged types, the
primitives (the subprogram themselves) are frozen; that's necessary because
their address is taken. However, their profile, i.e. all the types present
therein, is also frozen, which is not necessary after AI05-019 and is
The previous change introduced a backward incompatibility in the handling
of a user-defined "=" operator for a class-wide type of a tagged type: it
would previously hide the predefined "=" operator of the tagged type in
the private case, but it no longer does in this case, while it still does
in
After changes in GNATprove, adapt proof. Simply move an assertion up
before it is first needed here.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* libgnat/s-arit32.adb (Scaled_Divide32): Move assertion up.diff --git a/gcc/ada/libgnat/s-arit32.adb
The internal unit System.Generic_Array_Operations defines only generic
subprograms. Thus, pragma Assertion_Policy inside the spec has no
effect, as each instantiation is only subject to the assertion policy at
the program point of the instantiation. Remove this confusing pragma,
and add the pragma
As a result of other recent changes, the Convert_To_Return_False flag
is never set. The flag can be therefore be deleted.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* exp_ch11.adb (Expand_N_Raise_Expression): Remove
Convert_To_Return_False test.
*
This patch adds empty constructors to the functional containers so that
we can use them in expression functions.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* libgnat/a-cofuma.ads, libgnat/a-cofuma.adb,
libgnat/a-cofuse.ads, libgnat/a-cofuse.adb,
Removal of the previous kernel registration scheme unearthed mistakes in
the new one, which were:
- The new kernel registration code relied on the binder expansion phase,
which didn't happen because the registration code was already
generated by the binder.
- The kernel handle passed to
Jeff Law via Gcc-patches writes:
> On 5/29/2022 3:43 PM, H.J. Lu wrote:
>> On Sat, May 28, 2022 at 11:37 AM Jeff Law via Gcc-patches
>> wrote:
>>>
>>>
>>> On 5/26/2022 2:43 PM, H.J. Lu via Gcc-patches wrote:
On Thu, May 26, 2022 at 04:14:17PM +0100, Richard Sandiford wrote:
> "H.J. Lu"
On Mon, May 30, 2022 at 9:59 AM Jan Beulich wrote:
>
> On 27.05.2022 11:05, Uros Bizjak wrote:
> > On Fri, May 27, 2022 at 10:13 AM Jan Beulich wrote:
> >>
> >> Like noticed for gas as well (binutils-gdb commit c8cad9d389b7), the
> >> "absolute difference" aspect of the insns makes their source
(Sorry for the slow reply, was off on Friday)
Richard Biener writes:
> On Wed, May 25, 2022 at 10:24 PM Prathamesh Kulkarni
> wrote:
>>
>> On Thu, 26 May 2022 at 00:37, Richard Biener
>> wrote:
> [...]
>> > x86 now accepts V4SI V8SI permutes because we don’t ask it correctly and
>> > thus my
On Mon, 30 May 2022 at 13:04, Christophe Lyon wrote:
>
> Hi Prathamesh,
>
>
> On 5/27/22 09:11, Prathamesh Kulkarni via Gcc-patches wrote:
> > Hi,
> > I forgot to adjust prototype for arm_vectorize_vec_perm_const, which,
> > resulted in following
> > build error:
> >
> > # 00:05:33 make[3]:
On 27.05.2022 11:05, Uros Bizjak wrote:
> On Fri, May 27, 2022 at 10:13 AM Jan Beulich wrote:
>>
>> Like noticed for gas as well (binutils-gdb commit c8cad9d389b7), the
>> "absolute difference" aspect of the insns makes their source operands
>> commutative.
>
> You will need to expand via
On Mon, 30 May 2022, Hongtao Liu wrote:
> On Mon, May 30, 2022 at 2:22 PM Alexander Monakov via Gcc-patches
> wrote:
> > >
> > > The spill is mainly decided by 3 insns related to r92
> > >
> > > 283(insn 3 61 4 2 (set (reg/v:SF 92 [ x ])
> > > 284(reg:SF 102)) "test3.c":7:1 142
Hi Prathamesh,
On 5/27/22 09:11, Prathamesh Kulkarni via Gcc-patches wrote:
Hi,
I forgot to adjust prototype for arm_vectorize_vec_perm_const, which,
resulted in following
build error:
# 00:05:33 make[3]: [Makefile:1787:
armv8l-unknown-linux-gnueabihf/bits/largefile-config.h] Error 1
On 28.05.22 22:25, Harald Anlauf via Fortran wrote:
the PR rightfully complained that we did not differentiate errors on
ALLOCATE(...,stat=,errmsg=) for failures from allocation of already
allocated objects or insufficient virtual memory.
It is even worse: The error message states the wrong
On Mon, May 30, 2022 at 2:22 PM Alexander Monakov via Gcc-patches
wrote:
>
> > > In the PR, the spill happens in the initial basic block of the function,
> > > i.e.
> > > the one with the highest frequency.
> > >
> > > Also as noted in the PR, swapping the 'unlikely' branch to 'likely'
> > >
Hi Xi, thanks for pointing this out. I'd definitely say that the
https://clang.llvm.org/docs/ThreadSanitizer.html documentation is outdated.
According to
https://github.com/google/sanitizers/wiki/ThreadSanitizerCppManual#supported-platforms
TSAN is supported on Mips64. Furthermore, there are
Hi Thomas,
On 29.05.22 22:49, Thomas Schwinge wrote:
Not sure if that's what you had in mind, but what do you think about the
attached "nvptx: forward '-v' command-line option to assembler, linker"?
OK to push to GCC master branch (after merging
> > In the PR, the spill happens in the initial basic block of the function,
> > i.e.
> > the one with the highest frequency.
> >
> > Also as noted in the PR, swapping the 'unlikely' branch to 'likely' avoids
> > the spill,
> > even though it does not affect the frequency of the initial basic
86 matches
Mail list logo
