Am Donnerstag, dem 23.02.2023 um 19:21 -0600 schrieb Serge E. Hallyn:
> On Fri, Feb 24, 2023 at 01:02:54AM +0100, Alex Colomar wrote:
> > Hi Martin,
> >
> > On 2/23/23 20:57, Martin Uecker wrote:
> > > Am Donnerstag, dem 23.02.2023 um 20:23 +0100 schrieb Alex Colomar:
> > > > Hi Martin,
> > > >
Am Freitag, dem 24.02.2023 um 02:42 +0100 schrieb Alex Colomar:
> Hi Serge, Martin,
>
> On 2/24/23 02:21, Serge E. Hallyn wrote:
> > > Does all this imply that the following is well defined behavior (and shall
> > > print what one would expect)?
> > >
> > > free(p);
> > >
> > > (void)
Am Freitag, dem 24.02.2023 um 03:01 + schrieb Peter Lafreniere:
...
>
> > Maybe it could do an exception for printing, that is, reading a pointer
> > is not a problem in itself, a long as you don't compare it, but I'm not
> > such an expert about this.
>
> One last thought: with the above
Hi,
My name is Ken Matsui. I am highly interested in contributing to the
project idea, "C++: Implement compiler built-in traits for the
standard library traits." To understand how to implement those traits,
could you please give me some example implementations of the compiler
built-in traits, as
On Fri, Feb 24, 2023 at 09:36:45AM +0100, Martin Uecker wrote:
> Am Donnerstag, dem 23.02.2023 um 19:21 -0600 schrieb Serge E. Hallyn:
> > On Fri, Feb 24, 2023 at 01:02:54AM +0100, Alex Colomar wrote:
> > > Hi Martin,
> > >
> > > On 2/23/23 20:57, Martin Uecker wrote:
> > > > Am Donnerstag, dem
Hi! I've been interested in compiler development for a while, and would love to
work with any of you as part of GSoC, or even just as a side-project on my own.
I'm an 18 year-old student going into university next year with a passion for
all
things open source and low level. I consider myself
On Fri, Feb 24, 2023 at 02:42:32AM +0100, Alex Colomar wrote:
> Hi Serge, Martin,
>
> On 2/24/23 02:21, Serge E. Hallyn wrote:
> > > Does all this imply that the following is well defined behavior (and shall
> > > print what one would expect)?
> > >
> > >free(p);
> > >
> > >(void) //
Am Freitag, dem 24.02.2023 um 10:01 -0600 schrieb Serge E. Hallyn:
> On Fri, Feb 24, 2023 at 09:36:45AM +0100, Martin Uecker wrote:
> > Am Donnerstag, dem 23.02.2023 um 19:21 -0600 schrieb Serge E. Hallyn:
...
> >
> > Yes, but one comment about terminology:. The C standard
> > differentiates
Snapshot gcc-11-20230224 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/11-20230224/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55218
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108920
--- Comment #3 from Agner Fog ---
It seems to work with gcc 9.4.0.
Thank you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #1 from Andrew Pinski ---
>The committer also claims "fixes ieee_2.f90 testsuite failure" but I have no
>idea where to find this testsuite.
./testsuite/gfortran.dg/ieee/ieee_2.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55658
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
Hello Segher:
On 24/02/23 8:41 pm, Segher Boessenkool wrote:
> Hi!
>
> For future patches: please don't send patches as replies to existing
> threads. Just start a new thread for a new patch (series). You can
> mark it as [PATCH v2] in the subject, if you want.
>
> On Fri, Feb 24, 2023 at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66364
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55658
Andrew Pinski changed:
What|Removed |Added
CC||rogero at howzatt dot co.uk
--- Comment
> diff --git a/gcc/config/riscv/riscv-opts.h b/gcc/config/riscv/riscv-opts.h
> index cf0cd669be4..5cd3f7673f0 100644
> --- a/gcc/config/riscv/riscv-opts.h
> +++ b/gcc/config/riscv/riscv-opts.h
> @@ -215,4 +215,7 @@ enum stack_protector_guard {
> #define TARGET_XTHEADMEMPAIR ((riscv_xthead_subext
> > +(define_memory_constraint "Qmx"
> > + "@internal
> > + An address valid for GPR."
> > + (and (match_code "mem")
> > + (match_test "!riscv_legitimize_address_index_p (
> > + XEXP (op, 0), GET_MODE (op), false)")))
>
> Check TARGET_XTHEADFMEMIDX, and I don't quite
On Fri, 24 Feb 2023 at 09:50, Jonathan Wakely wrote:
>
> On Fri, 24 Feb 2023 at 09:49, Jakub Jelinek wrote:
> >
> > Assuming a compiler handles the T m_vecdata[1]; as flexible array member
> > like (which we need because standard C++ doesn't have flexible array members
> > nor [0] arrays), I
On 23/02/2023 21:20, Alexandre Oliva wrote:
On Feb 23, 2023, Alexandre Oliva wrote:
On Feb 23, 2023, Richard Earnshaw wrote:
On 22/02/2023 19:57, Alexandre Oliva wrote:
On Feb 21, 2023, Richard Earnshaw wrote:
Rather than scanning for the triplet, a better test would be
{ xfail {
On Fri, Feb 24, 2023 at 11:02:07AM +0100, Jakub Jelinek via Gcc-patches wrote:
> Maybe this would work, vl_relative even could be vl_embed.
> Because vl_embed I believe is used in two spots, part of
> auto_vec where it is followed by m_data and on heap or GGC
> allocated memory where vec<...,
On Fri, 24 Feb 2023 at 10:24, Jakub Jelinek wrote:
>
> On Fri, Feb 24, 2023 at 11:02:07AM +0100, Jakub Jelinek via Gcc-patches wrote:
> > Maybe this would work, vl_relative even could be vl_embed.
> > Because vl_embed I believe is used in two spots, part of
> > auto_vec where it is followed by
On Fri, Feb 24, 2023 at 11:59:53AM +0100, Jakub Jelinek via Gcc-patches wrote:
> > This needs to be alignas(T) unsigned char m_data[sizeof(T) * N];
>
> unsigned char m_data[MAX (N, 2) * sizeof (T)];
>
> if we want to preserve current behavior I think.
>
> I've screwed up, when I was about to
On 2/24/23 10:32, Benson Muite via Gcc-patches wrote:
> On 2/24/23 04:02, Gerald Pfeifer wrote:
>> On Thu, 23 Feb 2023, Tobias Burnus wrote:
>>> PS: I also removed a stray , but admittedly only after the
>>> commit. I found it by manually running those through the w3 validator
>>> site. However, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #26 from ibuclaw at gcc dot gnu.org ---
Comparing the D and C++ trees side by side.
At the point of `finish_function` for the ::vis() method, I see the following:
D: type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #25 from Iain Sandoe ---
(In reply to ibuclaw from comment #24)
> (In reply to Iain Sandoe from comment #23)
> > So the ABIs differ in this (as noted on IRC, the Darwin 32b ABIs are not the
> > same as Linux).
> I'm still yet to
On Fri, Feb 24, 2023 at 10:00:01AM +0100, Martin Liška wrote:
> As mentioned in the PR, when we use LTO, we wrongly use ltrans output
> file name as a module name of a global variable. That leads to a
> non-reproducible output.
>
> After the suggested change, we emit context name of normal global
On Fri, Feb 24, 2023 at 10:01 AM Kito Cheng wrote:
>
> Got one fail:
>
> FAIL: gcc.target/riscv/xtheadmempair-1.c -O2 scan-assembler-times
> th.luwd\t 4
>
> It should scan lwud rather than luwd?
Yes, this should be th.lwud.
Must have been introduced after testing.
I also ran the whole
On Fri, Feb 24, 2023 at 09:34:46AM +, Richard Biener wrote:
> > Looking at vec::operator[] which just does
> >
> > template
> > inline const T &
> > vec::operator[] (unsigned ix) const
> > {
> > gcc_checking_assert (ix < m_vecpfx.m_num);
> > return m_vecdata[ix];
> > }
> >
> > the whole
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108854
--- Comment #13 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:2f1691be517fcdcabae9cd671ab511eb0e08b1d5
commit r13-6319-g2f1691be517fcdcabae9cd671ab511eb0e08b1d5
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108854
Jakub Jelinek changed:
What|Removed |Added
Summary|[10/11/12/13 Regression]|[10/11/12 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108921
Bug ID: 108921
Summary: ICE: using the result of an impure function in
automatic character allocation
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
From: Christoph Müllner
This patch documents the new T-Head CPU support for RISC-V.
Signed-off-by: Christoph Müllner
---
htdocs/gcc-13/changes.html | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-13/changes.html
[The following is about Fortran pointers as actual argument to a CFI taking
procedure.]
The issue has been marked as 12/13 regression but the issue is just a
diagnostic one.
To disentangle:
(A) Bogus warning
[Now tracked as middle-end https://gcc.gnu.org/PR108906 ]
Assume:
nullify(p)
As preparation to remove m_vecdata in the vl_embed vector this
changes references to it into calls to address ().
As I was here it also fixes ::contains to avoid repeated bounds
checking and the same issue in ::lower_bound which also suffers
from unnecessary copying around values.
*
On Fri, Feb 24, 2023 at 12:44:44PM +0100, Richard Biener wrote:
> --- a/gcc/vec.h
> +++ b/gcc/vec.h
> @@ -586,8 +586,8 @@ public:
>unsigned allocated (void) const { return m_vecpfx.m_alloc; }
>unsigned length (void) const { return m_vecpfx.m_num; }
>bool is_empty (void) const { return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
Bug ID: 108922
Summary: fmod() 13x slowdown in gcc 4.8->4.9 dropping "fprem"
and calling fmod()
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108919
Bug ID: 108919
Summary: pure nested function may clobber its static chain
pointer in windowed ABI on xtensa
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63357
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
On Thu, 23 Feb 2023, Jakub Jelinek wrote:
> On Thu, Feb 23, 2023 at 03:02:01PM +, Richard Biener wrote:
> > > > * vec.h (auto_vec): Turn m_data storage into
> > > > uninitialized unsigned char.
> > >
> > > Given that we actually never reference the m_data array anywhere,
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108881
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:0ccfa3884f638816af0f5a3f0ee2695e0771ef6d
commit r13-6318-g0ccfa3884f638816af0f5a3f0ee2695e0771ef6d
Author: Jakub Jelinek
Date:
On Fri, Feb 24, 2023 at 10:54 AM Kito Cheng wrote:
>
> My impression is that md patterns will use first-match patterns? so
> the zba will get higher priority than xtheadba if both patterns are
> matched?
Yes, I was just about to write this.
/opt/riscv-thead/bin/riscv64-unknown-linux-gnu-gcc -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107409
--- Comment #21 from Rama Malladi ---
I did another triage for perf loss on Graviton 2 processor (neoverse-n1) based
instance and found this commit: `a9a4edf0e71bbac9f1b5dcecdcf9250111d16889` to
be the reason. As I had indicated in my earlier
On Fri, 24 Feb 2023 at 11:52, Jakub Jelinek wrote:
>
> On Fri, Feb 24, 2023 at 12:44:44PM +0100, Richard Biener wrote:
> > --- a/gcc/vec.h
> > +++ b/gcc/vec.h
> > @@ -586,8 +586,8 @@ public:
> >unsigned allocated (void) const { return m_vecpfx.m_alloc; }
> >unsigned length (void) const {
On Fri, Feb 24, 2023 at 11:54:54AM +, Jonathan Wakely wrote:
> > The comment needs adjustment and don't we need
> > alignas (T) alignas (vec_prefix) ?
>
> Yes. If alignas(T) is less than the natural alignment then this will
> be an error. We want it to be the larger of the two alignments, so
As mentioned in the PR, when we use LTO, we wrongly use ltrans output
file name as a module name of a global variable. That leads to a
non-reproducible output.
After the suggested change, we emit context name of normal global
variables. And for artificial variables (like .Lubsan_data3), we use
Hi Thomas / Arthur!
On Wed, 2023-02-22 15:30:37 +0100, Arthur Cohen
wrote:
[..]
> > > --target=msp430-elfbare
> > > ~
> > >
> > > /var/lib/laminar/run/gcc-msp430-elfbare/24/toolchain-build/./gcc/xgcc
> > >
Hi Thomas / Arthur!
On Wed, 2023-02-22 15:30:37 +0100, Arthur Cohen
wrote:
[..]
> > > --target=msp430-elfbare
> > > ~
> > >
> > > /var/lib/laminar/run/gcc-msp430-elfbare/24/toolchain-build/./gcc/xgcc
> > >
Hi!
The following testcase ICEs on x86_64-linux with -m32. The problem is
we create an artificial thunk and because of -fPIC, ia32 and thunk
destination which doesn't bind locally can't use a mi thunk.
The ICE is because during expansion to RTL we see SSA_NAME for a PARM_DECL,
but the PARM_DECL
On Fri, 24 Feb 2023 at 09:49, Jakub Jelinek wrote:
>
> Assuming a compiler handles the T m_vecdata[1]; as flexible array member
> like (which we need because standard C++ doesn't have flexible array members
> nor [0] arrays), I wonder if we instead of the m_auto followed by m_data
> trick couldn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108881
--- Comment #6 from Jakub Jelinek ---
Fixed on the trunk so far.
I think we want to backport to 10/11/12, though in that case it won't be v*bf
but v*hi.
On Fri, Feb 24, 2023 at 8:37 AM Kito Cheng wrote:
>
> > diff --git a/gcc/config/riscv/thead.md b/gcc/config/riscv/thead.md
> > index 158e9124c3a..2c684885850 100644
> > --- a/gcc/config/riscv/thead.md
> > +++ b/gcc/config/riscv/thead.md
> > @@ -29,3 +29,14 @@ (define_insn "*th_addsl"
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108920
Bug ID: 108920
Summary: Condition falsely optimized out
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
> On 24 Feb 2023, at 10:23, Richard Earnshaw via Gcc-patches
> wrote:
>
>
>
> On 23/02/2023 21:20, Alexandre Oliva wrote:
>> On Feb 23, 2023, Alexandre Oliva wrote:
>>> On Feb 23, 2023, Richard Earnshaw wrote:
On 22/02/2023 19:57, Alexandre Oliva wrote:
> On Feb 21, 2023,
On Fri, Feb 24, 2023 at 10:30:00AM +, Jonathan Wakely wrote:
> On Fri, 24 Feb 2023 at 10:24, Jakub Jelinek wrote:
> >
> > On Fri, Feb 24, 2023 at 11:02:07AM +0100, Jakub Jelinek via Gcc-patches
> > wrote:
> > > Maybe this would work, vl_relative even could be vl_embed.
> > > Because vl_embed
Hi all,
With the cleanup of the arch features in GCC 13 the comment on the FLAGS field
in aarch64-cores.def
is now outdated. It's now a comma-separated list rather than a bitwise or.
Spotted while reviewing an aarch64-cores.def patch.
Update the comment.
Pushing to trunk.
Thanks,
Kyrill
The following avoids default-initializing auto_vec storage for
non-POD T since that's not what the allocated storage fallback
will do and it's also not expected for existing cases like
auto_vec, 64> elts;
which exist to optimize the allocation.
It also fixes the array accesses done by vec to
On Fri, 24 Feb 2023, Jonathan Wakely wrote:
> On Fri, 24 Feb 2023 at 11:52, Jakub Jelinek wrote:
> >
> > On Fri, Feb 24, 2023 at 12:44:44PM +0100, Richard Biener wrote:
> > > --- a/gcc/vec.h
> > > +++ b/gcc/vec.h
> > > @@ -586,8 +586,8 @@ public:
> > >unsigned allocated (void) const { return
Hi!
I've noticed the description of these wasn't updated when the mask2
argument has been added in 2019.
Committed to trunk as obvious.
2023-02-24 Jakub Jelinek
* config/i386/i386-builtin.def: Update description of BDESC
and BDESC_FIRST in file comment to include mask2.
---
Got one fail:
FAIL: gcc.target/riscv/xtheadmempair-1.c -O2 scan-assembler-times
th.luwd\t 4
It should scan lwud rather than luwd?
Hi!
The builtins used in avx512bf16vlintrin.h implementation need both
avx512bf16 and avx512vl ISAs, which the header ensures for them, but
the builtins weren't actually requiring avx512vl, so when used by hand
with just -mavx512bf16 -mno-avx512vl it resulted in ICEs.
Fixed by adding
On Fri, 24 Feb 2023, Richard Biener wrote:
> On Thu, 23 Feb 2023, Jakub Jelinek wrote:
>
> > On Thu, Feb 23, 2023 at 03:02:01PM +, Richard Biener wrote:
> > > > > * vec.h (auto_vec): Turn m_data storage into
> > > > > uninitialized unsigned char.
> > > >
> > > > Given that we
On Fri, 24 Feb 2023, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs on x86_64-linux with -m32. The problem is
> we create an artificial thunk and because of -fPIC, ia32 and thunk
> destination which doesn't bind locally can't use a mi thunk.
> The ICE is because during expansion to
My impression is that md patterns will use first-match patterns? so
the zba will get higher priority than xtheadba if both patterns are
matched?
On Fri, Feb 24, 2023 at 2:52 PM Andrew Pinski via Gcc-patches
wrote:
>
> On Thu, Feb 23, 2023 at 9:55 PM Christoph Muellner
> wrote:
> >
> > From:
On Fri, Feb 24, 2023 at 09:50:33AM +, Jonathan Wakely wrote:
> On Fri, 24 Feb 2023 at 09:49, Jakub Jelinek wrote:
> >
> > Assuming a compiler handles the T m_vecdata[1]; as flexible array member
> > like (which we need because standard C++ doesn't have flexible array members
> > nor [0]
On Fri, Feb 24, 2023 at 09:55:13AM +, Jonathan Wakely wrote:
> > You would still be accessing past the end of the
> > vec::m_vecdata array which is UB.
>
> My thinking is something like:
>
> // New tag type
> struct vl_relative { };
>
> // This must only be used as a member subobject of
On Fri, Feb 24, 2023 at 11:05 AM Christoph Müllner
wrote:
>
> On Fri, Feb 24, 2023 at 10:54 AM Kito Cheng wrote:
> >
> > My impression is that md patterns will use first-match patterns? so
> > the zba will get higher priority than xtheadba if both patterns are
> > matched?
>
> Yes, I was just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63357
--- Comment #9 from Manuel López-Ibáñez ---
(In reply to David Binderman from comment #8)
> This could probably be extended to other operators.
Please open a new PR mentioning this one.
On Fri, Feb 24, 2023 at 9:09 AM Kito Cheng wrote:
>
> Hi Christoph:
>
> OK for trunk for the 1~8, feel free to commit 1~8 after you address
> those minor comments, and could you also prepare release notes for
> those extensions?
I addressed the comment regarding XTheadBs.
But I have not done
On Fri, Feb 24, 2023 at 12:32:45PM +0100, Richard Biener via Gcc-patches wrote:
> --- a/gcc/vec.h
> +++ b/gcc/vec.h
> @@ -614,7 +614,7 @@ public:
>T *bsearch (const void *key, int (*compar)(const void *, const void *));
>T *bsearch (const void *key,
> int (*compar)(const void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108695
--- Comment #18 from Kurt Garloff ---
dd_rescue-1.99.13 has been released including the fix to XORN.
(Fix uses uint* casts rather than uchar*.)
Hi,
In patch https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612168.html,
we improved the bictcast from lowpart/highpart of DI to SF by using mtvsrws
or mtvsrd.
As investigating this functionality, we may improve the related code by using
bitcast subreg from SI to SF, and avoid
Hello All:
Here is the patch that uses xxlor instead of fmr where possible.
Performance results shows that fmr is better in power9 and
power10 architectures whereas xxlor is better in power7 and
power 8 architectures.
Bootstrapped and regtested powepc64-linux-gnu.
Thanks & Regards
Ajit
Hi Christoph:
OK for trunk for the 1~8, feel free to commit 1~8 after you address
those minor comments, and could you also prepare release notes for
those extensions?
And 9~11 needs to take a few more rounds of review and test.
On Fri, Feb 24, 2023 at 1:52 PM Christoph Muellner
wrote:
>
>
ASAN: keep support for Global::location
We as GCC still emit __asan_global_source_location for global variables
and we would like to use it in the future. On other hand, we don't
support llvm-symbolizer and the default libbacktraace symbolizer
does not support location info.
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #24 from ibuclaw at gcc dot gnu.org ---
(In reply to Iain Sandoe from comment #23)
> So the ABIs differ in this (as noted on IRC, the Darwin 32b ABIs are not the
> same as Linux).
I'm still yet to work out why D on 32-bit Darwin
On Fri, Feb 24, 2023 at 12:15:04PM +, Richard Biener wrote:
> > > Also, I think it needs to be MAX (N, 2) instead of N, because auto_vec
> > > ctors use MAX (N, 2). We could also change all those to MAX (N, 1)
> > > now, but it can't be N because m_data[sizeof (T) * 0] is invalid in
> > >
On Fri, 24 Feb 2023, Jakub Jelinek wrote:
> On Fri, Feb 24, 2023 at 12:32:45PM +0100, Richard Biener via Gcc-patches
> wrote:
> > --- a/gcc/vec.h
> > +++ b/gcc/vec.h
> > @@ -614,7 +614,7 @@ public:
> >T *bsearch (const void *key, int (*compar)(const void *, const void *));
> >T *bsearch
> Hi!
>
> The following testcase ICEs on x86_64-linux with -m32. The problem is
> we create an artificial thunk and because of -fPIC, ia32 and thunk
> destination which doesn't bind locally can't use a mi thunk.
> The ICE is because during expansion to RTL we see SSA_NAME for a PARM_DECL,
> but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329
Gustaw Smolarczyk changed:
What|Removed |Added
CC||wielkiegie at gmail dot com
---
On Fri, Feb 24, 2023 at 02:47:39PM +0100, Richard Biener wrote:
> * vec.h (vec::m_vecdata): Remove.
> (vec::m_vecpfx): Align as T to avoid
> changing alignment of vec and simplifying
> address.
> (vec::address): Compute as this + 1.
> (vec::embedded_size): Use
On Fri, 24 Feb 2023, Jakub Jelinek wrote:
> On Fri, Feb 24, 2023 at 02:47:39PM +0100, Richard Biener wrote:
> > * vec.h (vec::m_vecdata): Remove.
> > (vec::m_vecpfx): Align as T to avoid
> > changing alignment of vec and simplifying
> > address.
> > (vec::address): Compute as
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This is an order of magnitude faster than calling inet_ntop (and not
only because we now avoid allocating a string that is one byte larger
than the SSO buffer).
libstdc++-v3/ChangeLog:
* include/experimental/internet
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The TS says the arguments to these constructors shall meet the Executor
requirements, so it's undefined if they don't. Constraining on a subset
of those requirements won't affect valid cases, but prevents the
majority of invalid cases from trying to
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/experimental/internet (network_v4::netmask()): Avoid
undefined shift.
(network_v4::broadcast()): Optimize and fix for targets with
uint_least32_t wider than 32 bits.
Tested x86_64-linux. Pushed to trunk.
-- >8 --
I messed up the endianness of the address_v4::bytes_type array, which
should always be in network byte order. We can just use bit_cast to
convert the _M_addr member to/from bytes_type.
libstdc++-v3/ChangeLog:
*
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/experimental/internet (basic_endpoint): Add missing
constexpr to comparison operators.
* testsuite/experimental/net/internet/endpoint/cons.cc: New test.
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105224
--- Comment #2 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:3d1d3ece9bc5a1baa2feb4bf231b709c097b8434
commit r13-6329-g3d1d3ece9bc5a1baa2feb4bf231b709c097b8434
Author: Alexandre Oliva
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108545
--- Comment #3 from Tobias Burnus ---
Fortran: Same issue (ICE) also with:
!$omp target enter data map(to: x)
Crucial is the VOLATILE attribute.
* * *
The following C code already gives an ICE with GCC 12, it works with GCC 11.
(Either
Hi!
For future patches: please don't send patches as replies to existing
threads. Just start a new thread for a new patch (series). You can
mark it as [PATCH v2] in the subject, if you want.
On Fri, Feb 24, 2023 at 01:41:49PM +0530, Ajit Agarwal wrote:
> Here is the patch that uses xxlor
On 2/24/23 10:07, Jakub Jelinek wrote:
> On Fri, Feb 24, 2023 at 10:00:01AM +0100, Martin Liška wrote:
>> As mentioned in the PR, when we use LTO, we wrongly use ltrans output
>> file name as a module name of a global variable. That leads to a
>> non-reproducible output.
>>
>> After the suggested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #4
Could you move those thead_* and th_* functions into thead.cc
> +static bool
> +thead_mempair_operand_p (rtx mem, machine_mode mode)
> +{
> + if (!MEM_SIZE_KNOWN_P (mem))
> +return false;
> +
> + /* Only DI or SI mempair instructions exist. */
add gcc_assert (mode == SImode || mode ==
As preparation to remove m_vecdata in the vl_embed vector this
changes references to it into calls to address ().
As I was here it also fixes ::contains to avoid repeated bounds
checking and the same issue in ::lower_bound which also suffers
from unnecessary copying around values.
*
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/constraints.md (Wb1): New constraint.
* config/riscv/predicates.md
(vector_least_significant_set_mask_operand): New predicate.
(vector_broadcast_mask_operand): Ditto.
* config/riscv/riscv-protos.h (enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107884
--- Comment #8 from Michael N. Moran ---
I tried to build with after patching with
https://gcc.gnu.org/bugzilla/attachment.cgi?id=53980 and now get an assembler
failure.
/tmp/cc2C1wMh.s: Assembler messages:
/tmp/cc2C1wMh.s:82060: Error: value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108545
--- Comment #4 from Tobias Burnus ---
For the C/C++ testcase of comment 3, bisecting points to
commit r12-5835-g0ab29cf0bb68960c1f87405f14b4fb2109254e2f
"openmp: Improve OpenMP target support for C++ (PR92120)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108925
Bug ID: 108925
Summary: memory leak of gfc_get_namespace result
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108906
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-02-24
Ever confirmed|0
1 - 100 of 173 matches
Mail list logo
