The default C library is normally computed based on the target
triplet. However, for embedded systems, it can be useful to leave the
triplet alone while changing which C library is used by default. Other
C libraries may still be available on the system so the compiler and
can be used by specifying
This option allows targets to insert an OS library after the C library
in the LIB_PATH spec file fragment. This library maps a few POSIX APIs
used by picolibc to underlying system capabilities.
For example, picolibc provides 'libsemihost' on various targets which
maps these APIs to semihosting cap
Picolibc is a C library for embedded systems based on code from newlib
and avr libc. To connect some system-dependent picolibc functions
(like stdio) to an underlying platform, the platform may provide an OS
library.
This OS library must follow the C library in the link command line. In
current pi
Don't set the DEFAULT_LIBC variable for newlib configurations as that
is how it currently works for systems using newlib as the default.
Signed-off-by: Keith Packard
---
gcc/config.gcc | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/gcc/config.gcc b/gcc/config.g
Richard Sandiford writes:
Thanks much for reviewing this series. I really appreciate it.
> should there be a default case that raises an error for unrecognised
> libcs? Command-line checking for configure isn't very tight, but we
> do raise similar errors for things like invalid --enable-
We don't yet support vectorization on RISC-V.
gcc/testsuite/ChangeLog
* gcc.dg/tree-ssa/gen-vect-34.c: Skip RISC-V targets.
---
gcc/testsuite/gcc.dg/tree-ssa/gen-vect-34.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-34.c
b/g
The current macro has several && and || making it really hard to understand
the first time.
Signed-off-by: Vineet Gupta
---
Since we are on this topic, perhaps get this simplification too.
But I'm not sure if the current checking of local symbol can be simplified
a bit. Isn't the first line enou
On Tue, 2022-08-30 at 16:40 -0400, Marek Polacek wrote:
> This looks good to me, one thing though:
>
> On Thu, Aug 11, 2022 at 09:38:12PM -0400, David Malcolm via Gcc-
> patches wrote:
> > --- a/gcc/c-family/c.opt
> > +++ b/gcc/c-family/c.opt
> > @@ -1439,6 +1439,10 @@ Wwrite-strings
> > C ObjC C
Came across this deprecated symbol when looking around for
-mexplicit-relocs handling in code
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/riscv-c.cc | 5 -
gcc/testsuite/gcc.target/riscv/predef-1.c | 3 ---
gcc/testsuite/gcc.target/riscv/predef-2.c | 3 ---
gcc/testsuite/g
On Sep 02 2022, Vineet Gupta wrote:
> diff --git a/gcc/config/riscv/riscv-c.cc b/gcc/config/riscv/riscv-c.cc
> index eb7ef09297e9..bba72cf77a82 100644
> --- a/gcc/config/riscv/riscv-c.cc
> +++ b/gcc/config/riscv/riscv-c.cc
> @@ -93,9 +93,6 @@ riscv_cpu_cpp_builtins (cpp_reader *pfile)
>bre
Hi!
On Fri, Sep 02, 2022 at 11:43:28AM +0800, HAO CHEN GUI wrote:
> On 2/9/2022 上午 12:07, Segher Boessenkool wrote:
> >> +/* { dg-do compile { target { ! has_arch_pwr9 } } } */
> > Please keep dg-do first thing in the file.
> Could you inform me if it's a must to put dg-do in the first line?
It i
On 8/31/22 13:39, Vineet Gupta wrote:
On 8/31/22 07:57, Palmer Dabbelt wrote:
if (flag_pic)
- riscv_cmodel = CM_PIC;
+ riscv_cmodel = CM_MEDANY;
/* We get better code with explicit relocs for CM_MEDLOW, but
worse code for the others (for now). Pick the best default. */
Came across this deprecated symbol when looking around for
-mexplicit-relocs handling in code
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/riscv-c.cc | 3 ---
gcc/testsuite/gcc.target/riscv/predef-1.c | 3 ---
gcc/testsuite/gcc.target/riscv/predef-2.c | 3 ---
gcc/testsuite/gcc
Dear all,
Jose posted a small patch here that was never reviewed:
https://gcc.gnu.org/pipermail/fortran/2021-April/055982.html
IMHO the patch is fine and nearly obvious.
I inquired in the PR, and Jose did not object to my handling of
his patch. So - unless there are objections - I will commi
Hi!
(Currently still on parental leave, but I just had to...) ;-P
On 2022-05-15T01:02:07+0200, Jan Hubicka via Gcc wrote:
> We are pleased to invite you all to the next GNU Tools Cauldron,
> taking place in [Prague] on September 16-18, 2022. We are looking forward
> to meet you again after thr
Dear all,
I've committed the attached fix for a NULL pointer dereference
as obvious after a discussion with Steve in the PR, and
successful regtesting on x86_64-pc-linux-gnu, as r13-2382.
See also https://gcc.gnu.org/g:b6aa7d45b502c01f8703c8d2cee2690f9aa8e282
Thanks,
Harald
From b6aa7d45b502c01
On 9/2/22 12:23 PM, Segher Boessenkool wrote:
> On Fri, Sep 02, 2022 at 12:02:54PM -0500, Peter Bergner wrote:
>> On 9/2/22 11:31 AM, Segher Boessenkool wrote:
>>> (Did you also look at non-MMA VIEW_CONVERT_EXPR uses btw?)
>>
>> I did. It seemed they were all related to pointers to vectors and I r
On Fri, 2 Sept 2022 at 17:39, Patrick Palka via Libstdc++
wrote:
>
> Now that these internal type traits are again class templates, it's
> better to derive from the trait's ::type (which is either false_type or
> true_type) instead of from the trait itself, for sake of a shallower
> inheritance ch
On 9/1/2022 12:08 PM, Aldy Hernandez via Gcc-patches wrote:
This is kinda obvious.
OK?
gcc/ChangeLog:
* builtins.cc (fold_builtin_inf): Convert use of real_info to dconstinf.
(fold_builtin_fpclassify): Same.
* fold-const-call.cc (fold_const_call_cc): Same.
*
On Tue, Aug 23, 2022 at 04:13:45PM -0500, Segher Boessenkool wrote:
> Please do not send new patches as replies to other patches.
This was sent as a new patch.
> On Thu, Aug 18, 2022 at 05:48:29PM -0400, Michael Meissner wrote:
> > mprove converting between 128-bit modes that use the same format.
On Fri, Sep 02, 2022 at 08:51:01AM +0800, Kewen.Lin wrote:
> on 2022/9/1 23:04, Segher Boessenkool wrote:
> > On Thu, Sep 01, 2022 at 05:05:44PM +0800, Kewen.Lin wrote:
> >> Without any explicit -mpowerpc64 (and -mno-), I think we all agree
> >> that -m64 should set OPTION_MASK_POWERPC64 in opts, c
On Fri, Sep 02, 2022 at 08:50:52AM +0800, Kewen.Lin wrote:
> on 2022/9/1 22:57, Segher Boessenkool wrote:
> > These two are independent, but apparently we have a bug here, which will
> > make what you did malfunction in some cases -- the test will not run for
> > ilp32 if you have RUNTESTFLAGS {-m3
On Fri, Sep 02, 2022 at 12:02:54PM -0500, Peter Bergner wrote:
> On 9/2/22 11:31 AM, Segher Boessenkool wrote:
> > (Did you also look at non-MMA VIEW_CONVERT_EXPR uses btw?)
>
> I did. It seemed they were all related to pointers to vectors and I remember
> you mentioning that as one of the reason
Ping patch:
| Date: Thu, 18 Aug 2022 17:46:51 -0400
| Subject: [PATCH] Rework 128-bit complex multiply and divide.
| Message-ID:
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
On 9/2/22 11:31 AM, Segher Boessenkool wrote:
> I wouldn't worry about backports. If it does make other backports
> easier in the future, we can decide to backport this *then*.
Ok.
> (Did you also look at non-MMA VIEW_CONVERT_EXPR uses btw?)
I did. It seemed they were all related to pointers
Now that these internal type traits are again class templates, it's
better to derive from the trait's ::type (which is either false_type or
true_type) instead of from the trait itself, for sake of a shallower
inheritance chain. We usually do this but not always; this patch makes
us consistently do
Hi!
On Fri, Sep 02, 2022 at 11:22:07AM -0500, Peter Bergner wrote:
> When we cast pointers to our opaque MMA pointers, use NOP_EXPR rather
> than VIEW_CONVERT_EXPR.
> I think this is just a cleanup and not a correctness thing, so I'm assuming a
> backport isn't needed? Or maybe we do to make oth
When we cast pointers to our opaque MMA pointers, use NOP_EXPR rather
than VIEW_CONVERT_EXPR.
This passed bootstrap and regtesting on powerpc64le-linux with no regressions.
Ok for trunk?
I think this is just a cleanup and not a correctness thing, so I'm assuming a
backport isn't needed? Or maybe
On Fri, Sep 02, 2022 at 10:29:35AM -0500, Peter Bergner wrote:
> On 9/1/22 4:52 PM, Segher Boessenkool wrote:
> > On Thu, Sep 01, 2022 at 11:24:00AM +0800, Jiufu Guo wrote:
> >> As mentioned in PR106550, since pli could support 34bits immediate, we
> >> could
> >> use less instructions(3insn would
> IIRC there was discussion about abort on the ML some years ago where folks
> decided to switch to stop N.
> I don't think I participated in that discussion, maybe somebody remembers the
> reasoning or is able to find the thread.
Found it: https://gcc.gnu.org/legacy-ml/fortran/2018-02/msg00105.
Hi!
On Fri, Sep 02, 2022 at 02:56:21PM +0800, Jiufu Guo wrote:
> >> + /* pli 9,high32 + sldi 9,32 + paddi 9,9,low32. */
> >> + else
> >> + {
> >
> > The comment goes here, in the block it refers to. Comments for a block
> > are the first thing *in* the block.
> OK, great! I like the f
Excerpts from Richard Biener's message of September 1, 2022 8:28 am:
> On Wed, Aug 31, 2022 at 9:21 PM Iain Buclaw wrote:
>>
>> Excerpts from Joseph Myers's message of August 31, 2022 7:16 pm:
>> > On Wed, 31 Aug 2022, Iain Buclaw via Gcc-patches wrote:
>> >
>> >> Excerpts from Joseph Myers's mess
On 2 September 2022 17:54:00 CEST, FX wrote:
>Hi Bernhard,
>
>> Please do not call the non-standard abort, but use stop N.
>
>Is there a specific reason? It’s a well-documented GNU extension, and it’s
>useful because it can easily display a backtrace and give line info for the
>failure, unlike S
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
This defines the is_xxx_constructible_v and is_xxx_assignable_v variable
templates by using the built-ins directly. The actual logic for each one
is the same as the corresponding class template, but way using the
variable template doesn't need t
Hi!
On Fri, Sep 02, 2022 at 04:31:38PM +0800, HAO CHEN GUI wrote:
> This patch is for internal issue1136.
This isn't useful to most people. Either just don't mention it here,
or make a public PR for it if that is useful?
> It changes insn condition from
> TARGET_64BIT to TARGET_POWERPC64 for
Hi Bernhard,
> Please do not call the non-standard abort, but use stop N.
Is there a specific reason? It’s a well-documented GNU extension, and it’s
useful because it can easily display a backtrace and give line info for the
failure, unlike STOP.
I’ll replace if there is consensus, but apart fr
Hi,
Thanks for committing the patch. I created PR106816 to track the noreturn/pure
problem.
Regards
Simon Rainer
On Fri, Sep 2, 2022, at 08:03, Richard Biener wrote:
> On Thu, Sep 1, 2022 at 7:51 PM Simon Rainer wrote:
> >
> > Hi,
> >
> > Thanks for taking a look at my patch. I tested some com
On 2 September 2022 13:37:41 CEST, FX via Fortran wrote:
>Hi,
Please do not call the non-standard abort, but use stop N.
IIRC I once had a trivial script..
https://www.mail-archive.com/search?l=gcc-patches@gcc.gnu.org&q=subject:%22%5C%5BPATCH%2C+OpenACC%5C%5D+Fortran+deviceptr%22&o=newest&f=1
On 9/1/22 4:52 PM, Segher Boessenkool wrote:
> On Thu, Sep 01, 2022 at 11:24:00AM +0800, Jiufu Guo wrote:
>> As mentioned in PR106550, since pli could support 34bits immediate, we could
>> use less instructions(3insn would be ok) to build 64bits constant with pli.
>
>> For example, for constant 0x
On Fri, 2022-09-02 at 16:08 +0200, Tim Lange wrote:
> Hi,
>
> below is my patch for the strcpy and strncpy semantics inside the
> analyzer, enabling the out-of-bounds checker to also complain about
> overflows caused by those two functions.
>
> As the plan is to reason about the inequality of sym
On Fri, 2022-09-02 at 16:08 +0200, Tim Lange wrote:
> This patch fixes a bug where maybe_fold_sub_svalue did not fold the
> access of a single char from a string to a char when the offset was
> zero
> because get_relative_concrete_offset did return false for
> cast_regions.
>
> Regrtested on Linux
CONCAT and CONCATN never appear in the insn chain. They are only used
in debug insn. Ignore debug insns with CONCAT and CONCATN for insn
scheduling to avoid different insn orders with and without debug insn.
gcc/
PR rtl-optimization/106746
* sched-deps.cc (sched_analyze_2): Igno
On Fri, 2 Sep 2022, 14:35 Patrick Palka via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> On Fri, 2 Sep 2022, Patrick Palka wrote:
>
> > r13-2230-g390f94eee1ae69 redefined the internal logical operator traits
> > __and_, __or_ and __not as alias templates that directly resolve to
> > true_type or f
Hi,
below is my patch for the strcpy and strncpy semantics inside the
analyzer, enabling the out-of-bounds checker to also complain about
overflows caused by those two functions.
As the plan is to reason about the inequality of symbolic values in the
future, I decided to use eval_condition to com
This patch fixes a bug where maybe_fold_sub_svalue did not fold the
access of a single char from a string to a char when the offset was zero
because get_relative_concrete_offset did return false for cast_regions.
Regrtested on Linux x86_64.
2022-09-02 Tim Lange
gcc/analyzer/ChangeLog:
On Fri, 2 Sep 2022, Patrick Palka wrote:
> r13-2230-g390f94eee1ae69 redefined the internal logical operator traits
> __and_, __or_ and __not as alias templates that directly resolve to
> true_type or false_type. But it turns out using an alias template here
> causes the traits to be less lazy tha
r13-2230-g390f94eee1ae69 redefined the internal logical operator traits
__and_, __or_ and __not as alias templates that directly resolve to
true_type or false_type. But it turns out using an alias template here
causes the traits to be less lazy than before because we now compute
the logical result
The following refactors things sligtly so "utility" use of the RPO VN
machinery gets its own timevar when invoked from other passes.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* timevar.def (TV_TREE_RPO_VN): New.
* tree-ssa-sccvn.c (do_rpo_vn): Remove one overloa
Keith Packard via Gcc-patches writes:
> Picolibc is a C library for embedded systems based on code from newlib
> and avr libc. To connect some system-dependent picolibc functions
> (like stdio) to an underlying platform, the platform may provide an OS
> library.
>
> This OS library must follow the
The dominated_by_p_w_unex function is prone to high compile time.
With GCC 12 we introduced a VN run for uninit diagnostics which now
runs into a degenerate case with bison generated code. Fortunately
this case is easy to fix with a simple extra check - a more
general fix needs more work.
Bootstr
Hi,
These operations were added to Fortran 2018, and correspond to well-defined
IEEE comparison operations, with defined signaling semantics for NaNs. All are
implemented in terms of GCC expressions and built-ins, with no library support
needed.
Bootstrapped and regtested on x86_64-linux, both
On Thu, 2022-09-01 at 18:54 +0800, Xi Ruoyao wrote:
> We'd like to introduce a new codegen option to align with the old
> "-Wa,-mla-global-with-pcrel" and avoid a performance & size regression
> building the Linux kernel with new-reloc toolchain. And it should be
> also useful for building statica
On Fri, 2 Sep 2022, Richard Sandiford wrote:
> vect_optimize_slp_pass always treats the starting layout as valid,
> to avoid having to "optimise" when every possible choice is invalid.
> But it gives the starting layout a high cost if it seems like the
> target might reject it, in the hope that th
On Fri, 2 Sep 2022, Richard Sandiford wrote:
> In the PR we have two REDUC_PLUS SLP instances that share a common
> load of stride 4. Each instance also has a unique contiguous load.
>
> Initially all three loads are out of order, so have a nontrivial
> load permutation. The layout pass puts th
Changes from v1:
(xtensa_expand_epilogue): Fixed forgetting to consider hard_frame_pointer_rtx
when sharing codes.
---
In the example below, 'x' is once placed on the stack frame and then read
into registers as the argument value of bar():
/* example */
struct foo {
int a, b;
LGTM with minor comments, it's time to move forward, thanks Patrick and Palmer.
> +
> +void
> +riscv_subword_address (rtx mem, rtx *aligned_mem, rtx *shift, rtx *mask,
> + rtx *not_mask)
> +{
> + /* Align the memory addess to a word. */
> + rtx addr = force_reg (Pmode, XEXP
vect_optimize_slp_pass always treats the starting layout as valid,
to avoid having to "optimise" when every possible choice is invalid.
But it gives the starting layout a high cost if it seems like the
target might reject it, in the hope that this will encourage other
(valid) layouts.
The testcase
In the PR we have two REDUC_PLUS SLP instances that share a common
load of stride 4. Each instance also has a unique contiguous load.
Initially all three loads are out of order, so have a nontrivial
load permutation. The layout pass puts them in order instead,
For the two contiguous loads it is
Got Jim's review and approval before, but apparently we missed this
last year, rebase and committed to trunk.
On Fri, Jul 30, 2021 at 3:01 AM Palmer Dabbelt wrote:
>
> On Thu, 29 Jul 2021 11:44:09 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
> > ping
> >
> > On Wed, Jul 21, 2021 at 5:28 PM Kito C
On Fri, Sep 2, 2022 at 9:00 AM Martin Liška wrote:
>
> On 9/1/22 13:18, Richard Biener wrote:
> > I presume WarnRemoved will diagnose use of -gstabs but not fail
> > compilation. Will -gstabs then still enable -g (with the default debug
> > format)?
>
> No, it won't set -g option.
That was the u
Hi,
This patch is for internal issue1136. It changes insn condition from
TARGET_64BIT to TARGET_POWERPC64 for VSX scalar extract/insert instructions.
These instructions all use DI registers and can be invoked with -mpowerpc64
in a 32-bit environment.
This patch also changes prototypes of rela
Hi Martin,
On Fri, 2 Sep 2022, Martin Liška wrote:
> +The support for emitting the STABS debugging format has been removed
> + (includes -gstabs and -gxcoff options) which
> means
> + the support for dbx debugger is removed.
how about slightly rephrasing this and breaking up the se
Hi,
I fixed it in a new patch. And added BF vector mode in SUBST_V and
avx512fmaskhalfmode for @vec_interleave_high.
Ok for trunk ?
> > Hi,
> >
> > Handle E_V8BFmode in expand_vec_perm_broadcast_1 and
> ix86_expand_vector_init_duplicate.
> > Ok for trunk?
> >
> > gcc/ChangeLog:
> >
> >
An aggregate may have been rewritten before being seen by the procedure.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* exp_util.adb (Expand_Subtype_From_Expr): Be prepared for
rewritten aggregates as expressions.diff --git a/gcc/ada/exp_util.adb b/gcc/ada/exp_util.
The semantic analyzer was setting the Is_Constr_Subt_For_UN_Aliased flag on
the actual subtype of the object, which is incorrect because the nominal
subtype is constrained. This also adjusts a recent related change.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* exp_util.a
Add loop variants to verify that loops terminate in string handling.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* libgnat/a-strmap.adb: Add variants to simple and while loops.
* libgnat/a-strsea.adb: Idem.diff --git a/gcc/ada/libgnat/a-strmap.adb b/gcc/ada/libgnat
Proof of Scaled_Divide was impacted by changes in provers and Why3.
Recover it partially, leaving some unproved basic inferences to be
further investigated.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* libgnat/s-aridou.adb: Add or rework ghost code.
* libgnat/s-ar
CALL_USED_REGISTERS already set those registers to 1, but I think it
is worth doing some clean up like this to prevent confusion.
On Thu, Sep 1, 2022 at 11:28 AM Palmer Dabbelt wrote:
>
> The V registers are always clobbered on calls.
>
> gcc/ChangeLog
>
> * config/riscv/riscv.cc (riscv_c
Regain the proof of System.Exp_Mod after changes in provers and Why3.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* libgnat/s-expmod.adb (Lemma_Add_Mod): Add new lemma to factor
out a complex sub-proof.
(Exp_Modular): Add assertion to help proof.diff --git
Regain the proof of System.Wid_* after changes in provers and Why3.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* libgnat/s-widthu.adb (Lemma_Euclidean): Lemma to prove the
relation between the quotient/remainder of a division.diff --git a/gcc/ada/libgnat/s-widthu.
The compiler wrongly reports an error about the expected type not
matching the same-named found type in a return statement for a function
whose result type has unknown discriminants when the full type is tagged
and has an undefaulted discriminant, and the return expression is an object
initialized
Refactor specification of the Value* and Image* units and fix proofs.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* libgnat/a-nbnbig.ads: Add Always_Return annotation.
* libgnat/s-vaispe.ads: New ghost unit for the specification of
System.Value_I. Restore p
This documents the limitation of addr2line with Position-Independent Code,
introduces the replacement tool gnatsymbolize and adjusts obsolete stuff.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* doc/gnat_ugn/gnat_and_program_execution.rst
(Non-Symbolic Traceback):
Update the OpenMP status for features that were added in the last months.
Comments/suggestions? Okay to commit?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung
On 9/1/22 14:32, Michael Matz wrote:
Hello,
okay, I'll bite :) DBG_REGISTER_NUMBER? DEBUGGER_REGNO?
Yep, I'm fine with the shorter macro name.
May I install such a change?
Cheers,
Martin
Ciao,
Michael.
Ready for master?
Thanks,
Martin
---
htdocs/gcc-13/changes.html | 3 +++
1 file changed, 3 insertions(+)
diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index c4189c1b..b5e49258 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@ -31,6 +31,9 @@ a wo
On 9/1/22 13:18, Richard Biener wrote:
I presume WarnRemoved will diagnose use of -gstabs but not fail
compilation. Will -gstabs then still enable -g (with the default debug
format)?
No, it won't set -g option.
Please followup with a gcc-13/changes.html entry.
Sure.
I notice we have VM
77 matches
Mail list logo
