在 2022/6/30 下午2:55, Richard Biener 写道:
On Thu, Jun 30, 2022 at 5:00 AM Xi Ruoyao via Gcc-patches
wrote:
Hi,
We've made a consensus [1] that not to enable trapping for division by
zero by default for LLVM, and we think GCC should behave similarly.
The main rationales:
1. Division by zero is
On Sat, 2022-07-02 at 15:39 +0800, Lulu Cheng wrote:
> diff --git a/gcc/common/config/loongarch/loongarch-common.cc
> b/gcc/common/config/loongarch/loongarch-common.cc
> index b6cbd84b873..f8b4660fabf 100644
> --- a/gcc/common/config/loongarch/loongarch-common.cc
> +++ b/gcc/common/config/loongar
在 2022/7/2 下午4:24, Xi Ruoyao 写道:
On Sat, 2022-07-02 at 15:39 +0800, Lulu Cheng wrote:
diff --git a/gcc/common/config/loongarch/loongarch-common.cc
b/gcc/common/config/loongarch/loongarch-common.cc
index b6cbd84b873..f8b4660fabf 100644
--- a/gcc/common/config/loongarch/loongarch-common.cc
+++
Hi Mikael,
Feel free to comment, do we need this?
Thanks for taking this on.
One thought: If we have to bite the bullet and break the ABI, why not go
all the way and use the C descriptors in ISO_Fortran_binding.h as
gfortran's native format?
Best regards
Thomas
Le 02/07/2022 à 13:18, Thomas Koenig a écrit :
>
> One thought: If we have to bite the bullet and break the ABI, why not go
> all the way and use the C descriptors in ISO_Fortran_binding.h as
> gfortran's native format?
>
As far as I know, CFI descriptors are mutually exclusive with
non-negative
On 6/26/2022 6:55 AM, Roger Sayle wrote:
Hi Jeff,
Sorry for the long delay getting back to this, but after deeper
investigation, it turns out that your tingling spider senses that
the original patch wasn't updating everywhere that was required
were spot on. Although my nvptx testing showed no
Hi everyone,
I've added myself to write after approval and DCO section.
- Tim
2022-07-02 Tim Lange
ChangeLog:
* MAINTAINERS: Add myself.
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3c448ba9eb6..17bebefa2db 100644
--- a/MAINT
On Linux/x86_64,
e6c3bb379f515b27268d08e62b4b3e5d7200b437 is the first bad commit
commit e6c3bb379f515b27268d08e62b4b3e5d7200b437
Author: Tim Lange
Date: Fri Jul 1 00:02:17 2022 +0200
analyzer: add allocation size checker [PR105900]
caused
FAIL: gcc.dg/analyzer/allocation-size-4.c note a
Hi,
thanks for the mail! Embarrassingly, I did not account for the different
sizes types may have on different systems. I've switched all testcases
to the fixed-width types of stdint.h.
Does this patch need an approval?
- Tim
The patch changes the types inside the tests for the allocation size
On Sun, 2022-07-03 at 01:20 +0200, Tim Lange wrote:
> Hi,
>
> thanks for the mail! Embarrassingly, I did not account for the
> different
> sizes types may have on different systems. I've switched all
> testcases
> to the fixed-width types of stdint.h.
>
> Does this patch need an approval?
Argua
On Sat, 2022-07-02 at 16:35 +0800, Lulu Cheng wrote:
> 在 2022/7/2 下午4:24, Xi Ruoyao 写道:
> >
> > I'll commit the patch with the hook removed after another regtest on
> > loongarch64-linux-gnu. I just rebuilt the entire system on my
> > 3A5000,
> > so I need some time to set it up. Expectation tim
This patch implements a storage class that will be used to stream out
ranges to long term storage, initially in SSA_NAME_RANGE_INFO, but it
is flexible enough to use with our obstack allocator. For instance,
in the future we could use it in the ranger cache to save memory.
The current size of ran
12 matches
Mail list logo