From: chenglulu
* contrib/config-list.mk: Add LoongArch triplet.
* gcc/doc/install.texi: Add LoongArch options section.
* gcc/doc/invoke.texi: Add LoongArch options section.
* gcc/doc/md.texi: Add LoongArch options section.
---
contrib/config-list.mk | 5 +-
From: chenglulu
* config/picflag.m4: Default add build option '-fpic' for LoongArch.
* configure: Add LoongArch tuples.
* configure.ac: Like wise.
---
config/picflag.m4 | 3 +++
configure | 10 +-
configure.ac | 10 +-
3 files changed, 21
From: chenglulu
gcc/testsuite/
* g++.dg/cpp0x/constexpr-rom.C: Add build options for LoongArch.
* g++.old-deja/g++.abi/ptrmem.C: Add LoongArch support.
* g++.old-deja/g++.pt/ptrmem6.C: xfail for LoongArch.
* gcc.dg/20020312-2.c: Add LoongArch support.
*
From: chenglulu
libgomp/
* configure.tgt: Add LoongArch triplet.
---
libgomp/configure.tgt | 4
1 file changed, 4 insertions(+)
diff --git a/libgomp/configure.tgt b/libgomp/configure.tgt
index d4f1e741b5a..2cd7272fcd8 100644
--- a/libgomp/configure.tgt
+++ b/libgomp/configure.tgt
From: chenglulu
libgcc/
* config/loongarch/crtfastmath.c: New file.
* config/loongarch/crti.S: Like wise.
* config/loongarch/crtn.S: Like wise.
* config/loongarch/lib2funcs.c: Like wise.
* config/loongarch/linux-unwind.h: Like wise.
*
From: chenglulu
---
libgcc/configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libgcc/configure b/libgcc/configure
index 4919a56f518..150ea04cb3d 100755
--- a/libgcc/configure
+++ b/libgcc/configure
@@ -5066,7 +5066,7 @@ $as_echo "$libgcc_cv_cfi" >&6; }
# word size
From: chenglulu
gcc/
* config/loongarch/larchintrin.h: New file.
* config/loongarch/loongarch-builtins.c: New file.
---
gcc/config/loongarch/larchintrin.h| 413 +
gcc/config/loongarch/loongarch-builtins.c | 511 ++
2 files changed,
From: chenglulu
gcc/
*config/loongarch/loongarch-c.c
---
gcc/config/loongarch/loongarch-c.c | 136 +
1 file changed, 136 insertions(+)
create mode 100644 gcc/config/loongarch/loongarch-c.c
diff --git a/gcc/config/loongarch/loongarch-c.c
From: chenglulu
gcc/
* common/config/loongarch/loongarch-common.c: New file.
* config/loongarch/genopts/genstr.sh: New file.
* config/loongarch/genopts/loongarch-strings: New file.
* config/loongarch/genopts/loongarch.opt.in: New file.
*
From: chenglulu
---
gcc/configure | 63 ++-
1 file changed, 57 insertions(+), 6 deletions(-)
diff --git a/gcc/configure b/gcc/configure
index a5160da83ec..2c95ceec398 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -7865,6 +7865,9 @@ else
The LoongArch architecture (LoongArch) is an Instruction Set
Architecture (ISA) that has a Reduced Instruction Set Computer (RISC)
style.
The documents are on
https://loongson.github.io/LoongArch-Documentation/README-EN.html
The ELF ABI Documents are on:
Jiufu Guo writes:
> Richard Biener writes:
>
>> On Mon, 18 Oct 2021, Jiufu Guo wrote:
>>
>>> With reference the discussions in:
>>> https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574334.html
>>> https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572006.html
>>>
Hi,
This patch updates the gdc codegen interface for the new front-end.
Bootstrapped and regression tested on x86_64-linux-gnu, committed to
mainline.
Regards,
Iain.
---
gcc/d/ChangeLog:
* Make-lang.in (D_FRONTEND_OBJS): Add d/root-optional.o.
* d-attribs.cc
On Linux/x86_64,
f8463b0e3ec2438b4cfb8c9a468d59761db2c8a0 is the first bad commit
commit f8463b0e3ec2438b4cfb8c9a468d59761db2c8a0
Author: Jonathan Wakely
Date: Thu Dec 2 13:19:41 2021 +
libstdc++: Disable over-zealous warnings about std::string copies [PR103332]
caused
FAIL:
Tested uild-x86_64-pc-linux-gnu, pushed to trunk and gcc-11.
On Thu, Nov 25, 2021 at 1:24 PM Jonathan Wakely wrote:
> On Wed, 24 Nov 2021 at 01:27, Thomas Rodgers wrote:
> >
> > const qualification was also missing in the free functions for
> wait/wait_explicit/notify_one/notify_all. Revised
On 12/9/21 5:38 PM, Martin Sebor wrote:
On 12/9/21 4:24 PM, Jonathan Wakely via Gcc-patches wrote:
These warnings are triggered by perfectly valid code using std::string.
They're particularly bad when --enable-fully-dynamic-string is used,
because even std::string().begin() will give a warning.
On Wed, Dec 8, 2021 at 6:10 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 12/7/2021 2:55 AM, Jakub Jelinek wrote:
> > Hi!
> >
> > The following patch adds support for relocation of the PCH blob on PCH
> > restore if we don't manage to get the preferred map slot for it.
> > The GTY stuff knows
Hi,
This patch aligns all D defined methods to MINIMUM_METHOD_BOUNDARY,
improving interoperability with C++ methods.
Bootstrapped and regression tested on x86_64-linux-gnu, committed to
mainline and backported to the release branches.
Regards,
Iain.
gcc/d/ChangeLog:
* decl.cc
On 12/9/21 4:24 PM, Jonathan Wakely via Gcc-patches wrote:
These warnings are triggered by perfectly valid code using std::string.
They're particularly bad when --enable-fully-dynamic-string is used,
because even std::string().begin() will give a warning.
Use pragmas to stop the troublesome
On 12/9/21 3:58 PM, Jim Wilson wrote:
On Mon, Nov 29, 2021 at 5:21 PM Martin Sebor via Gcc-patches
mailto:gcc-patches@gcc.gnu.org>> wrote:
There are some other "unusual" cases worth a look, such as missing
context of any kind except for like and column:
elfnn-riscv.c:3346:7:
On Thu, Dec 09, 2021 at 09:42:04AM -0700, Martin Sebor wrote:
> On 12/6/21 12:40 PM, Segher Boessenkool wrote:
> >Named address spaces are completely target-specific.
>
> My understanding of these kernel/user address spaces that David
> is adding for the benefit of the analyzer is that the
Tested powerpc64le-linux, pushed to trunk.
Since r11-1571 (c++: Refinements to "more constrained") was changed in
the front end, the following comment from stl_iterator.h stopped being
true:
// These extra overloads are not needed in C++20, because the ones above
// are constrained with a
Tested powerpc64le-linux, pushed to trunk.
This test no longer has additional errors for C++20 mode, so remove the
dg-error that is now failing, and the unnecessary dg-prune-output.
libstdc++-v3/ChangeLog:
* testsuite/20_util/scoped_allocator/69293_neg.cc: Remove
dg-error for
Tested powerpc64le-linux, pushed to trunk.
This allows std::make_exception_ptr to be used in a translation unit
compiled with -fno-exceptions. This works because the new implementation
added for PR 68297 doesn't need to throw or catch anything. The catch is
there to handle exceptions from the
Tested powerpc64le-linux, pushed to trunk.
This restores support for std::make_exception_ptr and for using
std::exception_ptr in C++98.
Because the new non-throwing implementation needs to use std::decay to
handle references the original throwing implementation is used for
C++98.
We also need
Tested powerpc64le-linux, pushed to trunk.
This implements my P2467R0 proposal to support opening an fstream in
exclusive mode. The new constant is also supported pre-C++23 as
std::ios_base::__noreplace.
This proposal hasn't been approved for C++23 yet, but I am confident it
will be, as this is
On Wed, 8 Dec 2021 at 17:26, Jonathan Wakely wrote:
>
> On Wed, 8 Dec 2021 at 00:36, Jonathan Wakely wrote:
> >
> > On Tue, 7 Dec 2021 at 21:52, Florian Weimer wrote:
> > >
> > > * Jonathan Wakely:
> > >
> > > > On Tue, 7 Dec 2021, 21:20 Florian Weimer via Libstdc++,
> > > >
> > > > wrote:
> > >
Tested powerpc64le-linux, pushed to trunk.
Inserting a pair into a map will allocate a new
node and construct a pair in the node, then check if
the Key is already present in the map. That is because pair
is not the same type as the map's value_type. But it only differs in the
const-qualification
On Thu, 2 Dec 2021 at 17:21, Jonathan Wakely via Libstdc++
wrote:
>
> Apart from "don't bother changing the COW string", does anybody see a
> reason we shouldn't do this? This passes all tests for normal COW
> strings and fully-dynamic COW strings.
Pushed to trunk.
>
> When non-const
On Thu, 2 Dec 2021 at 17:22, Jonathan Wakely via Libstdc++
wrote:
>
> I'd like to push this to trunk to fix PR64135.
The attached patch is what I've pushed to trunk, which adds some doc updates.
> It think this fixes the use of a non-reserved name, while preserving the
> ABI as far as class
These warnings are triggered by perfectly valid code using std::string.
They're particularly bad when --enable-fully-dynamic-string is used,
because even std::string().begin() will give a warning.
Use pragmas to stop the troublesome warnings for copies done by
std::char_traits.
On 12/9/21 15:15, Jakub Jelinek wrote:
On Wed, Dec 08, 2021 at 08:53:03AM -0500, Jason Merrill wrote:
As mentioned in the PR, the varpool/middle-end code is trying to be
conservative with address comparisons of different vars if those vars
don't bind locally, because of possible aliases in
On Mon, Nov 29, 2021 at 5:21 PM Martin Sebor via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> There are some other "unusual" cases worth a look, such as missing
> context of any kind except for like and column:
>
> elfnn-riscv.c:3346:7: warning: statement after return is not reachable
>
On 11/13/21 1:37 PM, David Malcolm via Gcc-patches wrote:
This patch adds a new:
__attribute__((untrusted))
for use by the C front-end, intended for use by the Linux kernel for
use with "__user", but which could be used by other operating system
kernels, and potentialy by other projects.
The conversion of a MEM address to ptr_mode in
try_store_by_multiple_pieces was misguided: copy_addr_to_reg expects
Pmode for addresses.
Regstrapped on x86_64-linux-gnu, testcase verified with a cross to
aarch64. Ok to install?
for gcc/ChangeLog
PR target/100518
*
The testcase confuses the code that detects min and max len for the
memset, so max_len ends up less than min_len. That shouldn't be
possible, but the testcase requires us to handle this case.
The store-by-mult-pieces algorithm actually relies on min and max
lengths, so if we find them to be
Excerpts from Andreas Schwab's message of December 9, 2021 11:09 am:
> Breaks aarch64:
>
> ../../../../libphobos/libdruntime/core/sys/linux/unistd.d:10:15: error:
> module 'core.sys.linux.syscalls' import 'SystemCall' not found
>10 | public import core.sys.linux.syscalls : SystemCall;
>
Hi Mikael,
Am 08.12.21 um 10:32 schrieb Mikael Morin:
On 07/12/2021 21:46, Harald Anlauf wrote:
Hi Mikael,
Am 07.12.21 um 21:17 schrieb Mikael Morin:
The existing code looks dubious to me (or at least difficult to
understand), and your patch doesn’t make that any better.
I would rather try
>
> Ah, indeed, good idea. FYI, clang++ seems to constant fold
> (x) != (y) already, so Jonathan could use it even for
> clang++ in the constexpr operator==. But it folds even
> extern int ,
> constexpr bool c = !=
> regardless of whether some other TU has
> int a;
> int b
Hello,
On 09/12/2021 21:05, Harald Anlauf via Fortran wrote:
Dear all,
I had thought that we had fixed this in the past (see PR31001),
but it did fail for me with all gcc versions I have tried (7-12)
for a slightly more elaborate case as in the old testcase.
The loop in pack_internal did try
On Sun, 2021-11-21 at 16:44 -0500, Antoni Boucher wrote:
> Thanks for the review!
> I updated the patch.
>
> See notes below.
Thanks; the updated patch looks good for trunk.
Dave
On Wed, Dec 08, 2021 at 08:53:03AM -0500, Jason Merrill wrote:
> > As mentioned in the PR, the varpool/middle-end code is trying to be
> > conservative with address comparisons of different vars if those vars
> > don't bind locally, because of possible aliases in other TUs etc.
>
> Would it make
Dear all,
I had thought that we had fixed this in the past (see PR31001),
but it did fail for me with all gcc versions I have tried (7-12)
for a slightly more elaborate case as in the old testcase.
The loop in pack_internal did try to access the first element of
the array argument to PACK even
On Mon, 2021-12-06 at 10:47 +, Petter Tomner via Gcc-patches wrote:
> Hi!
>
> Attached is a patch with changes in line with the review of the prior
> patch.
> The patch adds support for initialization of global variables with
> rvalues as well
> as rvalue constructors for structs, arrays and
I forgot to point out that this patch is dependent on the pending patches
to remove the old builtins code.
Thanks,
Bill
On 12/9/21 12:33 PM, Bill Schmidt via Gcc-patches wrote:
> Hi!
>
> While replacing the built-in machinery, we agreed to defer some necessary
> refactoring of the overload
Hi!
While replacing the built-in machinery, we agreed to defer some necessary
refactoring of the overload processing. This patch cleans it up considerably.
I've put in one FIXME for an additional level of cleanup that should be done
independently. The various helper functions (resolve_VEC_*)
Hi, Martin,
Thanks a lot for your review and comments.
> On Dec 9, 2021, at 11:43 AM, Martin Sebor wrote:
>>
>> diff --git a/gcc/tree-ssa-uninit.c b/gcc/tree-ssa-uninit.c
>> index 1df0bcc42c0..85d1ba866fc 100644
>> --- a/gcc/tree-ssa-uninit.c
>> +++ b/gcc/tree-ssa-uninit.c
>> @@ -182,9 +182,22
Hello,
This fixes a basic mistake in the relative path used to reference
a rs6000 specific Makefile fragment in the libgcc configuration bits
for powerpc*-vxworks7*.
This addresses build failures from link errors observed
during preliminary work on the support for shared libraries
on powerpc64.
On 12/7/21 8:36 AM, Qing Zhao via Gcc-patches wrote:
Hi,
This patch is to resolve the following two issues in the current implemenation
of -ftrivial-auto-var-init:
1. The 3rd parameter of function .DEFERRED_INIT is IS_VLA currently, which is
not needed at all;
2. The address taken variable
Richard Earnshaw via Gcc-patches writes:
> On 28/10/2021 12:43, Tejas Belagod via Gcc-patches wrote:
>>
>>> -Original Message-
>>> From: Gcc-patches >> bounces+belagod=gcc.gnu@gcc.gnu.org> On Behalf Of Tejas Belagod via
>>> Gcc-patches
>>> Sent: Friday, October 8, 2021 1:18 PM
>>>
On 12/9/2021 10:20 AM, Robin Dapp wrote:
Hi Jeff,
thanks for looking into this.
NP. I'd been watching this set evolve and I think it'll help our target
as well, so it seemed natural to handle the review :-)
What if the condition has a side effect? Doesn't this drop the side
effect by
Commit 13b6c7639cf assumed that registers in a span will be in a certain
order. But that assumption is not true at least for the big endian targets.
Currently amdgcn is probably only target where CFA is split into multiple
registers so build_span_loc is only gets called for it. However, the
Hi Jeff,
thanks for looking into this.
> What if the condition has a side effect? Doesn't this drop the side
> effect by converting the conditional move into a simple move?
Hmm, good point, if the condition does more than a CC compare, it might
get tricky as we are not canonicalizing here (on
Hi!
On Thu, Dec 09, 2021 at 05:42:10PM +0100, Christophe Lyon wrote:
> This also broke aarch64 I think:
> In file included from
> /tmp/6140018_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/config/aarch64/aarch64-sve-builtins.cc:3920:0:
> ./gt-aarch64-sve-builtins.h: In function 'void
>
On 12/8/21 1:08 PM, Jeff Law wrote:
On 12/6/2021 10:32 AM, Martin Sebor wrote:
Attached is subset of the patch in part (4) below: factor out
PHI handling. It applies on top of patch 3/5.
On 12/3/21 5:00 PM, Jeff Law wrote:
On 11/8/2021 7:34 PM, Martin Sebor via Gcc-patches wrote:
The
Hello,
The attached patch tightens the CPU macro definitions issued
for VxWorks system headers on aarch64 to incorporate the common
VX_CPU_PREFIX facility, as the powperpc port does.
The net effect for current configurations is the addition
of an actual "_VX_" prefix to the references to
On 12/9/2021 9:42 AM, Christophe Lyon via Gcc-patches wrote:
Hi Jakub,
On Thu, Dec 9, 2021 at 4:00 PM Jakub Jelinek via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
On Wed, Dec 08, 2021 at 08:00:03AM +, Iain Sandoe wrote:
On 7 Dec 2021, at 14:50, Jakub Jelinek via Gcc-patches <
Hi Jakub,
On Thu, Dec 9, 2021 at 4:00 PM Jakub Jelinek via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> On Wed, Dec 08, 2021 at 08:00:03AM +, Iain Sandoe wrote:
> > > On 7 Dec 2021, at 14:50, Jakub Jelinek via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
> > The attached patch should
On 2021/12/4 12:47 AM, Jakub Jelinek wrote:
On Tue, Nov 16, 2021 at 08:43:27PM +0800, Chung-Lin Tang wrote:
2021-11-16 Chung-Lin Tang
PR middle-end/92120
gcc/cp/ChangeLog:
...
+ if (allow_zero_length_array_sections)
+ {
+ /* When allowing
On 12/6/21 12:40 PM, Segher Boessenkool wrote:
On Mon, Dec 06, 2021 at 11:12:00AM -0700, Martin Sebor wrote:
On 11/13/21 1:37 PM, David Malcolm via Gcc-patches wrote:
Approach 1: Custom Address Spaces
=
GCC's C frontend supports target-specific address spaces;
> > I plan to reduce the value during before christmas after bit more testing
> > since
> > it seems to be overall win even if we trade fatigue2 performance, but I
> > would
> > like to get more testing on larger C++ APPs first.
>
> Will this hurt -Os -finline-limit=0 ?
Why do you use
On 12/8/21 18:23, Marek Polacek wrote:
On Wed, Dec 08, 2021 at 03:09:00PM -0500, Jason Merrill wrote:
On 12/8/21 13:32, Marek Polacek wrote:
On Wed, Dec 08, 2021 at 09:15:05AM -0500, Jason Merrill wrote:
On 12/7/21 19:25, Marek Polacek wrote:
On Mon, Dec 06, 2021 at 04:44:06PM -0500, Jason
On 12/4/21 12:23, Anthony Sharp wrote:
Hi Jason,
Hope you are well. Apologies for not coming back sooner.
>I'd put it just above the definition of saved_token_sentinel in parser.c.
Sounds good, done.
>Maybe cp_parser_require_end_of_template_parameter_list? Either way is
fine.
Even
Changes from original patch:
1. Make mentioned changes to changelog.
2. Add namespace-end comments.
3. Add #error for when arm-mve-builtins.def is included without
defining DEF_MVE_TYPE.
4. Make placement of '#undef DEF_MVE_TYPE' consistent.
---
This patch moves the implementation of MVE
On 12/7/21 03:15, Kewen.Lin wrote:
Hi,
For a function with optimize pragma, it's possible that the target
options change as optimization options change. Now we create one
optimization option node when parsing pragma optimize, but don't
create target option node for possible target option
> On 9 Dec 2021, at 14:59, Jakub Jelinek wrote:
>
> On Wed, Dec 08, 2021 at 08:00:03AM +, Iain Sandoe wrote:
>>> On 7 Dec 2021, at 14:50, Jakub Jelinek via Gcc-patches
>>> wrote:
>> The attached patch should be applied before (or merged with) the change for
>> relocation when it is
On Wed, Dec 08, 2021 at 08:00:03AM +, Iain Sandoe wrote:
> > On 7 Dec 2021, at 14:50, Jakub Jelinek via Gcc-patches
> > wrote:
> The attached patch should be applied before (or merged with) the change for
> relocation when it is applied - since the operation of the PCH hooks needs
> some
>
On 12/9/21 07:59, Martin Liška wrote:
On 12/3/21 15:09, Andrew MacLeod wrote:
On 12/2/21 11:02, Martin Liška wrote:
On 12/2/21 15:27, Andrew MacLeod wrote:
ranger->gori().outgoing_edge_range_p (irange , edge e, tree name,
*get_global_range_query ());
Thank you! It works for me!
Martin
Hi!
The following patch is an attempt to fix various time_get related issues.
Sorry, it is long...
One of them is PR78714. It seems _M_extract_via_format has been written
with how strftime behaves in mind rather than how strptime behaves.
There is a significant difference between the two, for
On 11/30/21 12:17, Richard Biener wrote:
I'd like to see the gswitch support - that's what was posted before stage3
close, this patch on its own doesn't seem worth pushing for. That said,
I have some comments below (and the already raised ones about how
things might need to change with gswitch
On 12/3/21 15:09, Andrew MacLeod wrote:
On 12/2/21 11:02, Martin Liška wrote:
On 12/2/21 15:27, Andrew MacLeod wrote:
ranger->gori().outgoing_edge_range_p (irange , edge e, tree name,
*get_global_range_query ());
Thank you! It works for me!
Martin
btw, this applies to names not on the
On Thu, Dec 09, 2021 at 11:41:46AM +, Andrew Stubbs wrote:
> gcc/ChangeLog:
>
> * config/gcn/mkoffload.c (process_asm): Process the variable table
> completely differently.
> (process_obj): Encode the varaible data differently.
>
> include/ChangeLog:
>
> *
Hi Jonathan,
>> > Ah yes, so we need to disable this optimization. Patch coming up ...
>>
>> Gah, I remembered to check that:
>>
>> constexpr bool __double_word
>> = sizeof(long long) == 2 * sizeof(_Atomic_word);
>> // The ref-count members follow the vptr, so are aligned to
On 02/12/2021 16:43, Jakub Jelinek wrote:
On Thu, Dec 02, 2021 at 04:31:36PM +, Andrew Stubbs wrote:
On 02/12/2021 16:05, Andrew Stubbs wrote:
On 02/12/2021 12:58, Jakub Jelinek wrote:
I've tried modifying offload_handle_link_vars but that spot
doesn't catch
the omp_data_sizes variables
Hi,
Apologies for interrupting your busy schedule, I'm following up to check if you
had a chance to review my previous email. Do let me know your interest and we
shall provide you further details for your perusal.
Waiting for your response.
Best Regards,
Taylor Germain
From: Taylor Germain
Breaks aarch64:
../../../../libphobos/libdruntime/core/sys/linux/unistd.d:10:15: error: module
'core.sys.linux.syscalls' import 'SystemCall' not found
10 | public import core.sys.linux.syscalls : SystemCall;
| ^
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key
On 12/3/21 10:28, Jan Hubicka wrote:
|Do you know how to get that name? With the numbers it is not too hard to find
the dump, but I do not mind having it either way.|
Hello.
Let's keep the names as they are. I've just added the tracking to all LNT
instances.
Cheers,
Martin
On Thu, Dec 9, 2021 at 7:59 AM Cui,Lili wrote:
>
> Hi Uros,
>
> This patch is to update mtune for tremont.
>
> Bootstrap is ok, and no regressions for i386/x86-64 testsuite.
>
> OK for master?
OK.
Thanks,
Uros.
>
>
> Silvermont has a special handle in add_stmt_cost function, because it has in
78 matches
Mail list logo
