So far z16 was identified as arch14. After the machine has been
announced we can now add the real name.
gcc/ChangeLog:
* common/config/s390/s390-common.cc: Rename PF_ARCH14 to PF_Z16.
* config.gcc: Add z16 as march/mtune switch.
* config/s390/driver-native.cc (s390_host_de
Trivial initialization shouldn't bump a variable out of .rodata; if the
result of build_aggr_init is an empty STATEMENT_LIST, throw it away.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/104142
gcc/cp/ChangeLog:
* decl.cc (check_initializer): Check TREE_SIDE_EFFECTS.
gc
In a template class A we normally add an implicit using A::operator= as a
placeholder for the implicitly declared operator whose signature we don't
know yet. In my patch for PR92918 I stopped doing that if the class has an
explicit operator=, but that was wrong; an operator= taking an unrelated
ty
on 2022/4/11 11:42 PM, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Apr 11, 2022 at 04:29:40PM +0800, Kewen.Lin wrote:
>> on 2022/4/9 1:31 AM, Segher Boessenkool wrote:
>>> On Fri, Apr 08, 2022 at 10:09:44AM +0800, Kewen.Lin wrote:
>>> For me it fails during combine: the unspec suddenly doesn't rec
gcc.target/powerpc/fold-vec-insert-double.c is compiled with -mvsx,
while the expected asm output depends on target has_arch_pwr7, which
is tested for without -mvsx.
In some of our configurations, that have altivec and vsx disabled by
default, the former defines up to _ARCH_PWR7, while the latte
If neither 128-bit long double format is available, skip pr60203.c.
Tested with gcc-11 targeting ppc64-vx7r2, with neither long double
format enabled. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.target/powerpc/pr60203.c: Skip on no 128-bit long double.
---
gcc/testsuite/gcc.ta
On Fri, 2022-04-08 at 16:37 -0400, Antoni Boucher wrote:
> On Fri, 2022-04-08 at 15:36 -0400, David Malcolm wrote:
[...snip...]
>
>
> > So I think I'm waiting on an updated version of the sized-integer-
> > types
> > patch, and some nit-fixes for the other patches (but am
> > disappearing
> >
On Apr 7, 2022, HAO CHEN GUI via Gcc-patches wrote:
> Gentle ping this:
>https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590958.html
> Thanks
>> On 28/2/2022 上午 11:17, HAO CHEN GUI wrote:
>>> This patch corrects the match pattern in pr56605.c. The former pattern
>>> is wrong and
On Tue, Apr 05, 2022 at 10:33:14PM -0500, Peter Bergner wrote:
> On 4/5/22 5:32 PM, Segher Boessenkool wrote:
> >> + gcc_assert (rs6000_pcrel_p ());
> >> + func_desc = rs6000_longcall_ref (func_desc, tlsarg);
> >> +}
> >> + else
> >> +gcc_assert (INTVAL (cookie) == 0);
> >
> > S
On Mon, Apr 11, 2022 at 05:08:04PM -0500, Peter Bergner wrote:
> Done and pushed. Thanks! We need this on GCC11 and GCC10 as well.
> With GCC11 due soon, I'd like this in there. Ok for backports after
> a day or so of trunk burn-in?
Yes, thanks! Please make sure you have tested things very th
On Thu, Apr 07, 2022 at 07:59:27PM -0400, Michael Meissner wrote:
> I have tested this patch on a little endian power10 system. I have tested
> previous versions on little endian power9 and big endian power8 systems.
Please test on at least p8 as well.
> I will want to backport the patch to GCC
On 4/11/22 4:13 PM, Segher Boessenkool wrote:
> On Wed, Apr 06, 2022 at 02:33:52PM -0500, Peter Bergner wrote:
>> On 4/5/22 10:33 PM, Peter Bergner via Gcc-patches wrote:
>>> On 4/5/22 5:32 PM, Segher Boessenkool wrote:
On Tue, Apr 05, 2022 at 05:06:50PM -0500, Peter Bergner wrote:
>> So the u
On Thu, Apr 07, 2022 at 02:10:48AM +0500, Frolov Daniil wrote:
> Hello! Thanks for your feedback. I've tried to take into account your
> comments. New patch applied to the letter.
Thanks.
> The only thing I have not removed is the check_std_c2x () function. From my
> point of view -Wformat-overf
The standard says, as we quote in the comment just above, that if we don't
find operator new in the allocated type, it should be looked up in the
global scope. This is specifically ::, not just any namespace, and we
already give an error for an operator new declared in any other namespace.
Tested
On Mon, 11 Apr 2022 at 18:03, Jonathan Wakely via Libstdc++
wrote:
> // Precondition: _M_frames == nullptr
> pointer
> _M_allocate(allocator_type& __alloc, size_type __n) noexcept
> {
> __try
> {
> - _M_frames = __n ? __alloc.alloca
On Wed, Apr 06, 2022 at 02:33:52PM -0500, Peter Bergner wrote:
> On 4/5/22 10:33 PM, Peter Bergner via Gcc-patches wrote:
> > On 4/5/22 5:32 PM, Segher Boessenkool wrote:
> >> On Tue, Apr 05, 2022 at 05:06:50PM -0500, Peter Bergner wrote:
> So the updated change looks like below with the ChangeLog
The _dm alternative works fine for soft-float, but the _nodm variant
pattern is missing that alternative. So, let's add that.
There probably should be an r,r,i alternative as well (or we can make it
rm,r,i), but that is for later.
Tested on powerpc64-linux {-m32,-m64}. Pushed to trunk.
Segher
On 4/8/22 15:21, Marek Polacek wrote:
On Wed, Apr 06, 2022 at 04:55:54PM -0400, Jason Merrill wrote:
On 4/1/22 15:14, Marek Polacek wrote:
Attribute format takes three arguments: archetype, string-index, and
first-to-check. The last two specify the position in the function
parameter list. r63
On Mon, Apr 11, 2022 at 6:52 PM Jakub Jelinek wrote:
>
> Hi!
>
> While working on the PR105214 patch, I've noticed incorrect formatting
> for a bunch of functions where the function names aren't at the start of
> lines.
>
> The following patch fixes it, though of course it isn't a regression.
>
>
On Mon, Apr 11, 2022 at 6:50 PM Jakub Jelinek wrote:
>
> Hi!
>
> The following testcase ICEs, because ix86_emit_i387_log1p attempts to
> emit something like
> if (cond)
> some_code1;
> else
> some_code2;
> and emits a conditional jump using emit_jump_insn (standard way in
> the file) a
Ian Lance Taylor wrote:
> What I was hoping from my earlier question was that you could tell me
> the exact lines to write in the current sources that will compile on
> MUSL. Don't include , don't refer to earlier patches as
> that is what I tried to do earlier but failed, don't add new #define
>
On Mon, Apr 11, 2022 at 10:26 AM Sören Tempel wrote:
>
> Any updates no this?
>
> Sorry I keep bothering you with this but we are quite literally only a
> few lines away from having the go-signal.c code compile on PPC64 musl :)
>
> Let me know if you need more information to get this fixed.
What
Hi,
Any updates no this?
Sorry I keep bothering you with this but we are quite literally only a
few lines away from having the go-signal.c code compile on PPC64 musl :)
Let me know if you need more information to get this fixed.
Greetings,
Sören
Sören Tempel wrote:
> Ian Lance Taylor wrote:
> Am 11.04.2022 um 18:45 schrieb Jakub Jelinek via Gcc-patches
> :
>
> Hi!
>
> The expansion of __builtin_iround{,f,l} etc. builtins in some cases
> emits calls to a different fallback builtin. To locate the right builtin
> it uses mathfn_built_in_1 with the type of the first argument.
> If
Tested x86_64-linux, pushed to trunk.
-- >8 --
The PR points out that there is a non-constant condition used for an
if-constexpr statement, but there are several other problems with the
copy, move and swap members of std::basic_stacktrace.
libstdc++-v3/ChangeLog:
PR libstdc++/105031
Tested x86_64-linux, pushed to trunk.
-- >8 --
This prevents inlining the current() function to guarantee that it is
present in the stacktrace, then tells libbacktrace to skip that frame.
To avoid overflow in the int argument to __glibcxx_backtrace_simple, we
need to check if the skip parameter
> Am 11.04.2022 um 19:00 schrieb Jakub Jelinek :
>
> Hi!
>
> In the PR104639 optimization, I've added code to emit
> # DEBUG D#1 => arg != carg ? arg : oarg
> instruction and replace debug uses of the phi with that debug
> temp, so that the debug info is still accurrate.
> Unfortunately, tha
Hi!
In the PR104639 optimization, I've added code to emit
# DEBUG D#1 => arg != carg ? arg : oarg
instruction and replace debug uses of the phi with that debug
temp, so that the debug info is still accurrate.
Unfortunately, that is only correct if the middle-bb and
phi bb contain 1 and 2 predece
Hi!
While working on the PR105214 patch, I've noticed incorrect formatting
for a bunch of functions where the function names aren't at the start of
lines.
The following patch fixes it, though of course it isn't a regression.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk or
Hi!
The following testcase ICEs, because ix86_emit_i387_log1p attempts to
emit something like
if (cond)
some_code1;
else
some_code2;
and emits a conditional jump using emit_jump_insn (standard way in
the file) and an unconditional jump using emit_jump.
The problem with that is that if
Hi!
The expansion of __builtin_iround{,f,l} etc. builtins in some cases
emits calls to a different fallback builtin. To locate the right builtin
it uses mathfn_built_in_1 with the type of the first argument.
If its TYPE_MAIN_VARIANT is {float,double,long_double}_type_node, all is
fine, but on the
In commit a2a919aa501e3 (2003), built-ins for modf and modff were added.
In extend.texi, section "Other Builtins", "modf" was added to the paragraph
"There are also built-in versions of the ISO C99 functions [...]" and
"modf" was also added to the paragraph "The ISO C90 functions [...]".
"modff" wa
v2:
- Remove redundant num_zero_width_bf_seen and num_fields_seen
tracking. (Thanks Stefan Schulze-Frielinghaus)
Re-tested with testsuite and ABI tests.
For IBM Z in particular there is a problem with structs like:
struct A { float a; int :0; };
Our ABI document allows passing a struct in
Hi!
On Mon, Apr 11, 2022 at 04:29:40PM +0800, Kewen.Lin wrote:
> on 2022/4/9 1:31 AM, Segher Boessenkool wrote:
> > On Fri, Apr 08, 2022 at 10:09:44AM +0800, Kewen.Lin wrote:
> > For me it fails during combine: the unspec suddenly doesn't recog
> > anymore. That might be that "d" thing yes, that
We migrate the default ISA spec version from 2.2 to 20191213, but those scripts
aren't updated at the same time, this patch is making both scripts support
different ISA spec versions.
gcc/ChangeLog:
PR target/104853
* config.gcc: Pass -misa-spec to arch-canonicalize and
mu
Currently we are sync that manually, but I guess we should re-implement
arch-canonicalize in C++, so that we could reuse the stuffs from
riscv-common.cc.
gcc/ChangeLog:
* config/riscv/arch-canonicalize: Add TODO item.
(IMPLIED_EXT): Sync.
(arch_canonicalize): Checking unti
On Apr 9, 2022, Jason Merrill wrote:
>>> how about handling it in set_cleanup_locs instead?
>> Like this? That seems reasonable to me. I'll give it a spin.
> Yes, or perhaps STRIP_NOPS and set the location on whatever is left.
> OK either way.
Hmm, I'm not sure leaving the loc unset on the
On Apr 9, 2022, Jason Merrill wrote:
>> goto ;
>> (void) S::~S (&((struct T *) this)->D.4458)
>> Now, ISTM that the goto target selected for the return stmt bypasses the
>> subobject dtor call and the full-object clobber. That sounds like
>> another bug, no?
> The subobject cleanup and clobbe
Xi Ruoyao writes:
> Another brown paper bag fix for MIPS :(.
>
> This failure was not detected running mips.exp=pr102024-* with a cross
> compiler, so I just spotted it now running the test natively.
>
> ---
>
> The body of func is optimized away with -flto -fno-fat-lto-objects, so
> the psABI inf
On Mon, Apr 11, 2022 at 10:53 AM Alexandre Oliva wrote:
>
>
> The testcase was missing dg- before require-effective-target.
>
> While at that, I'm also pruning the excess-error warning I got when
> the test failed to be disabled because of the above. I suppose it
> might be useful for some target
Pushed to trunk.
-- >8 --
This matches where the feature is defined in the current draft.
libstdc++-v3/ChangeLog:
* testsuite/20_util/stacktrace/entry.cc: Moved to...
* testsuite/19_diagnostics/stacktrace/entry.cc: ...here.
* testsuite/20_util/stacktrace/synopsis.cc: Mov
Tested x86_64-linux, pushed to trunk.
-- >8 --
This fixes some errors with clang caused by instantiating vector<_Cmpt>
before the _Cmpt type is complete.
libstdc++-v3/ChangeLog:
* include/experimental/bits/fs_path.h (path): Define special
members after path::_Cmpt is complete.
-
The testcase was missing dg- before require-effective-target.
While at that, I'm also pruning the excess-error warning I got when
the test failed to be disabled because of the above. I suppose it
might be useful for some target variants.
Tested with target powerpc64-wrs-vxworks7r2. Ok to inst
On Mon, 11 Apr 2022, Tamar Christina wrote:
> Hi All,
>
> Previously ifcvt used to enforce that a mask A and the inverse of said mask be
> represented as ~A. So for the masks
>
> _25 = _6 != 0;
> _44 = _4 != 0;
>
> ifcvt would produce for an operation requiring the inverse of said mask
>
>
Hi All,
Previously ifcvt used to enforce that a mask A and the inverse of said mask be
represented as ~A. So for the masks
_25 = _6 != 0;
_44 = _4 != 0;
ifcvt would produce for an operation requiring the inverse of said mask
_26 = ~_25;
_43 = ~_44;
but now that VN is applied to the ent
Gerald Pfeifer writes:
> I pushed this for now.
>
> Gaius, if you want to make changes to that section of readings.html,
> absolutely be free doing so (and I'll be happy help, too).
>
> Gerald
>
> ---
> htdocs/readings.html | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/htdocs/readings.
On 4/7/22 16:17, Thomas Schwinge wrote:
Hi!
On 2022-03-31T09:40:47+0200, Tom de Vries via Gcc-patches
wrote:
Newer versions of CUDA no longer support sm_30, and nvptx-tools as
currently doesn't handle that gracefully when verifying
( https://github.com/MentorEmbedded/nvptx-tools/issues/30 ).
On Wed, Apr 6, 2022 at 4:26 PM Jason Merrill via Gcc-patches
wrote:
>
> This bug was an object/value confusion; we are interested in the size
> of *b.ip, but instead the code was calculating the size of b.ip itself.
>
> This seems to be because compute_objsize will compute the size of whatever
> o
> Thank you all for your feedback and guidance. I have taken Eric's
> feedback and deleted the relevant entry.
>
> Since I do not have write access, I cannot add myself to the
> MAINTAINERS file. Therefore, I want to explicitly state that I am
> submitting these patches under the DCO. I have read
Hi Segher,
on 2022/4/9 1:31 AM, Segher Boessenkool wrote:
> On Fri, Apr 08, 2022 at 10:09:44AM +0800, Kewen.Lin wrote:
>> As Jakub noted here, we don't have the soft-float support for both m32 and
>> m64
>> before, as the bifs are always guarded under hard-float previously.
>
> But that bug was
Hi,
As PR103623 shows, it's a regression failure due to new built-in
function framework, previously we guard __builtin_{un,}pack_{longdouble,
ibm128} built-in functions under hard float, so they are unavailable
with the given configuration. While with new bif infrastructure, it
becomes available
From: chenglulu
gcc/ChangeLog:
* config/loongarch/loongarch.cc: Fix bug for
tmpdir-g++.dg-struct-layout-1/t033.
---
gcc/config/loongarch/loongarch.cc | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/gcc/config/loongarch/loongarch.cc
b/gcc/config/loong
52 matches
Mail list logo
