On Fri, May 24, 2024 at 05:39:45PM +0200, Martin Uecker wrote:
> PR 115157
> PR 115177
>
> gcc/c/
> * c-decl.cc (shadow_tag-warned,parse_xref_tag,start_enum,
> finish_enum): Set SET_TYPE_STRUCTURAL_EQUALITY / TYPE_CANONICAL.
> * c-obj-common.cc
On Wed, May 22, 2024 at 05:23:33PM +0800, YunQiang Su wrote:
> Jakub Jelinek 于2024年5月22日周三 17:14写道：
> >
> > On Wed, May 22, 2024 at 05:05:30PM +0800, YunQiang Su wrote:
> > > > --- gcc/gcc.cc.jj 2024-02-09 14:54:09.141489744 +0100
> > > > +++ gcc/gcc.
On Wed, May 22, 2024 at 05:05:30PM +0800, YunQiang Su wrote:
> > --- gcc/gcc.cc.jj 2024-02-09 14:54:09.141489744 +0100
> > +++ gcc/gcc.cc 2024-02-09 22:04:37.655678742 +0100
> > @@ -2410,8 +2410,7 @@ read_specs (const char *filename, bool m
> > if (*p1++ != '<' || p[-2] !=
On Wed, May 22, 2024 at 09:46:41AM +0200, Richard Biener wrote:
> On Wed, May 22, 2024 at 3:58 AM liuhongt wrote:
> >
> > According to IEEE standard, for conversions from floating point to
> > integer. When a NaN or infinite operand cannot be represented in the
> > destination format and this
infinite (but caller cares about only
the first nbytes bytes) and furthermore, we never know if there is
any '\0' char among those, so *nulterm needs to be always cleared.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk and affected release branches?
2024-05-
, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk and release branches?
2024-05-21 Jakub Jelinek
PR sanitizer/115172
* ubsan.cc (instrument_bool_enum_load): If rhs is not in generic
address space, use qualified version of utype with the right
On Tue, May 21, 2024 at 09:36:05AM +0200, Tobias Burnus wrote:
> Jakub Jelinek wrote:
> > On Mon, May 20, 2024 at 08:31:02AM +0200, Tobias Burnus wrote:
> > > Hmm, there were now two daily bumps: [...] I really wonder why.
> > Because I've done it by hand.
>
> Okay,
On Mon, May 20, 2024 at 08:31:02AM +0200, Tobias Burnus wrote:
> Hmm, there were now two daily bumps:
>
> Date: Mon May 20 00:16:30 2024 +
>
> Date: Sun May 19 18:15:28 2024 +
>
> I really wonder why.
Because I've done it by hand.
I have in ~gccadmin a gcc-changelog copy and
On Sat, May 18, 2024 at 02:53:20PM +0800, Kefu Chai wrote:
> libstdc++-v3/ChangeLog:
>
> * include/bits/unicode.h (enable_borrowed_range): Call ++(*this)
> instead of ++this
This should be already fixed, see https://gcc.gnu.org/PR115119
Jakub
On Fri, May 03, 2024 at 11:08:04AM -0600, Tom Tromey wrote:
> DWARF is not especially clear on the distinction between
> DW_TAG_namespace and DW_TAG_module, but I think that DW_TAG_module is
> more appropriate for Ada. This patch changes the compiler to do this.
> Note that the Ada compiler does
Hi!
I'd like to ping the
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651199.html
patch.
Thanks.
On Thu, May 09, 2024 at 08:12:30PM +0200, Jakub Jelinek wrote:
> The C++26 P2662R3 Pack indexing paper mentions that both GCC
> and MSVC don't handle T...[10] parameter declaration
On Thu, May 16, 2024 at 12:14:09PM +0200, Aldy Hernandez wrote:
> Wait, what's the preferred way of reverting a patch? I followed what I saw
> in:
Reverting a patch (that isn't a reversion) just push git revert.
The important part is not to modify the This reverts commit line from what
git
On Thu, May 16, 2024 at 12:01:01PM +0200, Aldy Hernandez wrote:
> This reverts commit d7bb8eaade3cd3aa70715c8567b4d7b08098e699 and enables
> prange
> support again.
Please don't do this.
This breaks ChangeLog generation, will need to handle it tomorrow by hand again.
Both the ammendments to the
with reduction clause(s).
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk.
2024-05-15 Jakub Jelinek
PR c/115103
gcc/c/
* c-typeck.cc (c_finish_omp_clauses): Diagnose grainsize
used together with num_tasks.
gcc/cp
to tell callers the comparison is now unconditional).
The following patch just disables the optimization in that case.
Bootstrapped/regtested on x86_64-linux and i686-linux, preapproved by
Segher in the PR, committed to trunk so far.
2024-05-15 Jakub Jelinek
PR rtl-optimization/114902
On Wed, May 15, 2024 at 01:41:04PM +0200, Richard Biener wrote:
> PR middle-end/111422
> * cfgexpand.cc (add_scope_conflicts_2): Handle PHIs
> by recursing to their arguments.
> ---
> gcc/cfgexpand.cc | 21 +
> 1 file changed, 17 insertions(+), 4 deletions(-)
On Tue, May 07, 2024 at 10:37:55AM +0800, HAO CHEN GUI wrote:
> The former patch adds isfinite optab for __builtin_isfinite.
> https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649339.html
>
> Thus the builtin might not be folded at front end. The range op for
> isfinite is needed for
On Tue, May 14, 2024 at 03:47:46PM +0200, Tom de Vries wrote:
> On aarch64, I get this failure:
> ...
> FAIL: gcc.dg/pr115066.c scan-assembler \\.byte\\t0xb\\t# Define macro strx
> ...
>
> This happens because we expect to match:
> ...
> .byte 0xb # Define macro strx
> ...
> but
On Tue, May 14, 2024 at 03:47:46PM +0200, Tom de Vries wrote:
> On aarch64, I get this failure:
> ...
> FAIL: gcc.dg/pr115066.c scan-assembler \\.byte\\t0xb\\t# Define macro strx
> ...
>
> This happens because we expect to match:
> ...
> .byte 0xb # Define macro strx
> ...
> but
On Tue, May 14, 2024 at 01:35:30PM +0200, Tom de Vries wrote:
> Consider a hello world, compiled with -gsplit-dwarf and dwarf version 4, and
> -g3:
> ...
> $ gcc -gdwarf-4 -gsplit-dwarf /data/vries/hello.c -g3 -save-temps -dA
> ...
>
> In section .debug_macro.dwo, we have:
> ...
>
On Fri, May 10, 2024 at 03:59:25PM -0400, Jason Merrill wrote:
> > 2024-05-09 Jakub Jelinek
> > Jason Merrill
> >
> > PR lto/113208
> > * cp-tree.h (maybe_optimize_cdtor): Remove.
> > * decl2.cc (tentative_decl_linkage): Call mayb
On Thu, May 09, 2024 at 01:42:15PM -0400, David Malcolm wrote:
> I've pushed the following changes to releases/gcc-13
> as r13-8741-g89feb3557a0188 through r13-8761-gb7a2697733d19a.
Unfortunately many of the commits contained git commit message wording
that update_git_version can't cope with.
linux, ok for trunk?
2024-05-13 Jakub Jelinek
PR middle-end/113982
* tree-ssa-math-opts.cc (arith_overflow_check_p): Also return 1
for RSHIFT_EXPR by precision of maxval if shift result is only
used in a cast or comparison against zero.
(match_arith
On Thu, May 09, 2024 at 02:58:52PM -0400, Marek Polacek wrote:
> On Thu, May 09, 2024 at 08:20:00PM +0200, Jakub Jelinek wrote:
> > --- gcc/cp/decl.cc.jj 2024-05-09 10:30:54.804505130 +0200
> > +++ gcc/cp/decl.cc 2024-05-09 17:07:08.400110018 +0200
> >
sts for -fsanitize=undefined need to go into
gcc.dg/ubsan/ or g++.dg/ubsan/, even when they are target specific.
Tested on x86_64-linux with
make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} i386.exp=pr84508*
ubsan.exp=pr84508*'
and committed to trunk as obvious.
2024-05-09 Jakub Jel
, we can cast always to
get_cxa_atexit_fn_ptr_type () type, because this is in use_dtor guarded code
and use_dtor is ob_parm && CLASS_TYPE_P (type), so when use_dtor is true,
ob_parm is also true.
Ok for trunk if it passes another bootstrap/regtest?
2024-05-09 Jakub Jelinek
PR target/11
CC 14 and delay this approach to 15. Your v1 patch is OK for 14.
Ok, here is an updated patch, which sets DECL_SAVED_TREE to void_node for
the aliases together with reversion of the earlier committed patch.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-05-09
in cp_parser_direct_declarator.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-05-09 Jakub Jelinek
PR c++/115012
* parser.cc (cp_parser_direct_declarator): Handle
abstract declarator starting with ... followed by [
or (.
* g++.dg/cpp0x
On Thu, May 09, 2024 at 12:14:43PM +0200, Jakub Jelinek wrote:
> On Thu, May 09, 2024 at 12:04:38PM +0200, Rainer Orth wrote:
> > I just noticed that gcc/DATESTAMP wasn't updated yesterday and today,
> > staying at 20240507.
>
> I think it is because of the r15-268
On Thu, May 09, 2024 at 12:04:38PM +0200, Rainer Orth wrote:
> I just noticed that gcc/DATESTAMP wasn't updated yesterday and today,
> staying at 20240507.
I think it is because of the r15-268 commit, we do support
This reverts commit ...
when the referenced commit contains a ChangeLog message,
after testing it on x86_64-linux with
make check-g++ RUNTESTFLAGS='--target_board=unix\{-m32/-mno-sse,-m32,-m64\}
dg-torture.exp=vector-subaccess-1.C'
and backported all the way to 11 branch.
2024-05-09 Jakub Jelinek
PR c++/89224
* g++.dg/torture/vector-subaccess-1.C: Add -Wno
for the cleanup,
uses that type for that wrapper so that it agrees on calling convention.
Bootstrapped/regtested on x86_64-linux and i686-linux and Liu Hao tested
it on mingw32, ok for trunk?
2024-05-09 Jakub Jelinek
PR target/114968
gcc/
* target.def (use_atexit_for_cxa_atexit
<= 48U - 43U) if ((1UL << exp) & mask1))
or need to subtract lowi from the shift counter, i.e.
if ((1UL << (exp - 43)) & mask2)
but can't do both unless r.upper_bound () is < prec.
The following patch ensures that.
Bootstrapped/regtested on x86_64-linux and i686-linux,
On Tue, May 07, 2024 at 08:57:00PM +0200, Richard Biener wrote:
>
>
> > Am 07.05.2024 um 18:02 schrieb Jakub Jelinek :
> >
> > Hi!
> >
> > The HF and BF modes have the same size/precision and neither is
> > a subset nor superset of the other.
> >
to switch to using what is available rather than
adding new entrypoints to libgcc, even alias, because this is backportable.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-05-07 Jakub Jelinek
PR middle-end/114907
* expr.cc (convert_mode_scalar): Use
only
late after ipa, but as the following testcase the .ASAN_MARK ifn calls
gimplifier adds can result in ICEs.
Fixed by dropping those during inlining, similarly to how we drop
.TSAN_FUNC_EXIT calls.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-05-07 Jakub Jelinek
On Tue, May 07, 2024 at 02:12:07PM +0100, Andre Vieira (lists) wrote:
> Hey Jakub,
>
> This what ya had in mind?
Yes.
> diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
> index
> ca5174de991bb088f653468f77485c15a61526e6..924e045a15a78b5702a0d6997953f35c6b47efd1
> 100644
>
On Fri, May 03, 2024 at 09:11:20PM +0200, Martin Uecker wrote:
> > TYPE_CANONICAL as used by the middle-end cannot express this but
>
> Hm. so how does it work now for arrays?
Do you have a testcase which doesn't work correctly with the arrays?
E.g. same_type_for_tbaa has
type1 =
On Fri, May 03, 2024 at 08:04:18PM +0200, Martin Uecker wrote:
> A change that is not optimal but would avoid a lot of trouble is to
> only use the tag of the struct for computing a TYPE_CANONICAL, which
> could then be set already for incomplete types and never needs to
> change again. We would
On Fri, May 03, 2024 at 05:32:12PM +0200, Martin Uecker wrote:
> Am Freitag, dem 03.05.2024 um 14:13 +0200 schrieb Richard Biener:
> > TYPE_STRUCTURAL_EQUALITY_P is part of our type system so we have
> > to make sure to include that into the type unification done via
> > type_hash_canon. This
oop to parse the further friend type
specifiers.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-05-03 Jakub Jelinek
PR c++/114459
gcc/c-family/
* c-cppbuiltin.cc (c_cpp_builtins): Predefine
__cpp_variadic_friend=202403L for C++26.
gcc
On Fri, May 03, 2024 at 04:06:28PM +0100, Jonathan Wakely wrote:
> I agree it should be mentioned, but I would put it in the caveats
> section at the top, not as the last item of the C section.
>
> How about this? OK for wwwdocs?
LGTM.
> commit fe5fd75ea5a7a08eee0831cadbdd05689e9408db
> Author:
On Fri, May 03, 2024 at 09:31:08AM -0400, David Malcolm wrote:
> Jakub, Richi, Rainer: this is a non-trivial change that cleans up
> analyzer C++ testsuite results on Solaris, but has a slight risk of
> affecting analyzer behavior on other targets. As such, I was thinking
> to hold off on
On Fri, May 03, 2024 at 12:58:55PM +0200, Richard Biener wrote:
> When building a type and type_hash_canon returns an existing type
> avoid changing it, in particular its TYPE_CANONICAL.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu for all languages.
>
> OK for trunk?
>
> Thanks,
>
or
not, it just fixes the behavior when we inline them despite those checks.
The stack save/restore restores the behavior that alloca acquired regions
are freed at the end of the containing call.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-05-03 Jakub Jelinek
PR
On Thu, May 02, 2024 at 12:52:59PM -0700, Ken Matsui wrote:
> > This seems to be the prevailing sentiment, so let's continue that way.
> > Thanks for the input.
>
> I actually found that we have two built-in type traits prefixed with
> __builtin: __builtin_is_corresponding_member and
That is a
On Thu, May 02, 2024 at 01:53:21PM +0100, Iain Sandoe wrote:
> My testing of the GCC-14 release branch revealed an Objective-C
> regression in code-gen, the fix has been tested on x86_64, i686
> and powerpc darwin, pushed to trunk.
>
> I will shortly apply this to the open branches, since they
On Thu, May 02, 2024 at 12:28:29PM +0200, Marc Poulhiès wrote:
> Single argument static_assert is C++17 only.
>
> gcc/ChangeLog:
>
> * value-range.h: fix static_assert to use 2 arguments.
> ---
>
> Ok for master?
Yes.
Jakub
support, but we still list those as offloading devices).
Committed to trunk.
2024-05-02 Jakub Jelinek
* testsuite/libgomp.c/declare-variant-4.h (gfx90c, gfx1036, gfx1103):
New functions.
(f): Add #pragma omp declare variant directives for those.
* testsuite/libgomp.c
On Wed, May 01, 2024 at 12:55:25PM -0700, H.J. Lu wrote:
> Since bfloat16 has the same range as float32, _Float16 to bfloat16
> conversion is an extension, not a truncation. Rename trunchfbf2.c
> to extendhfbf2.c to provide __extendhfbf2, instead of __trunchfbf2.
>
> Since _Float16 to bfloat16
reason. If preferred it could
be say TREE_LIST with the reason STRING_CST and RID_DELETE identifier or
something similar instead, but that would need more compile time memory when
it is used.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-05-01 Jakub Jelinek
On Tue, Apr 30, 2024 at 11:12:30PM +0200, Martin Jambor wrote:
> Would the following then perhaps describe the situation accurately?
> Note that I have moved the whole thing to C++ section because it seems
> porting issues in C because of this are quite unlikely.
>
> Michal, I assume that the
On Tue, Apr 30, 2024 at 09:30:00AM +0200, Richard Biener wrote:
> On Mon, Apr 29, 2024 at 5:30 PM H.J. Lu wrote:
> >
> > On Mon, Apr 29, 2024 at 6:47 AM liuhongt wrote:
> > >
> > > The Fortran standard does not specify what the result of the MAX
> > > and MIN intrinsics are if one of the
, %zmm5, %zmm0{%k2}
vmaxpd %zmm0, %zmm3, %zmm5{%k1}
in the vectorized loops of the first and second subroutine.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and
14.1?
2024-04-30 Jakub Jelinek
Hongtao Liu
PR tree-optimization/114883
. Anyway, didn't feel I should touch that right now.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Shall it go to 14.1, or wait for 14.2?
2024-04-30 Jakub Jelinek
PR tree-optimization/114876
* gimple-ssa-sprintf.cc (format_character): For min == 0 &
suspect this has caused link failures in the glibc testsuite for Hurd,
> which still has separate libpthread.
>
> https://sourceware.org/pipermail/libc-testresults/2024q2/012556.html
So like this then? I can't really test it on Hurd, but will certainly
test on x86_64-linux/i686-
On Fri, Apr 26, 2024 at 11:10:12PM +, Christophe Lyon wrote:
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/mve/pr114801.c
> @@ -0,0 +1,36 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target arm_v8_1m_mve_ok } */
> +/* { dg-add-options arm_v8_1m_mve } */
> +/* { dg-final {
On Sun, Apr 28, 2024 at 10:37:06PM +0100, Paul Richard Thomas wrote:
> Could this be looked at quickly? The timing of this regression is more than
> a little embarrassing on the eve of the 14.1 release. The testcase and the
> comment in gfc_trans_class_init_assign explain what this problem is all
On Mon, Apr 29, 2024 at 10:07:42AM +0200, Rainer Orth wrote:
> This patch updates the Solaris baselines for the GLIBCXX_3.4.33 version
> added in GCC 14.0.
>
> Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (32 and 64-bit
> each), together with the GLIBCXX_3.4.32 update, on both gcc-14
On Mon, Apr 29, 2024 at 10:02:56AM +0200, Rainer Orth wrote:
> This patch updates the Solaris baselines for the GLIBCXX_3.4.32 version
> added in GCC 13.2.
>
> Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (32 and 64-bit
> each) on the gcc-13 branch and (together with the GLIBCXX_3.4.33
On Mon, Apr 29, 2024 at 03:47:05PM +0800, Kito Cheng wrote:
> Hi Jakub:
>
> Is this OK for GCC 14 branch? it's fix ICE on valid code, thanks :)
Ok.
Jakub
]],
just whether it is parsed properly, second on gnu::deprecated, which
works. Haven't used deprecated attribute because the paper said that
attribute is for further investigation.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-04-29 Jakub Jelinek
PR c++/114456
nd in stage1 will
post an incremental diff.
Thanks.
2024-04-25 Jakub Jelinek
Jason Merrill
PR lto/113208
* decl2.cc (tentative_decl_linkage): Call maybe_make_one_only
for implicit instantiations of maybe in charge ctors/dtors
dec
on x86_64-linux and i686-linux (with glibc 2.35), ok
for trunk?
2024-04-25 Jakub Jelinek
* gthr.h (GTHREAD_USE_WEAK): Redefine to 0 for GLIBC 2.34 or later.
--- libgcc/gthr.h.jj2024-01-03 12:07:28.623363560 +0100
+++ libgcc/gthr.h 2024-04-25 12:09:39.708622613 +0200
@@ -141,6
.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed so far to
trunk.
2024-04-25 Jakub Jelinek
PR fortran/114825
* tree-nested.cc (get_debug_decl): New function.
(get_nonlocal_debug_decl): Use it.
(get_local_debug_decl): Likewise.
* gfortran.dg
On Thu, Apr 25, 2024 at 02:02:32PM +0200, Jakub Jelinek wrote:
> I've tried the following patch, but unfortunately that lead to large
> number of regressions:
> +FAIL: g++.dg/cpp0x/initlist25.C -std=c++17 (test for excess errors)
So the reduced testcase for this is
template struct A
On Thu, Apr 25, 2024 at 02:34:22PM +0200, Martin Jambor wrote:
> when looking at a package build issue with GCC 14, Michal Jireš noted a
> different behavior of pragma GCC Target. This snippet tries to describe
> the gist of the problem. I have left it in the C section even though it
> is not
rors are like:
func-params-08.C:(.text._ZNSt12_Vector_baseIiSaIiEEC2Ev[_ZNSt12_Vector_baseIiSaIiEEC5Ev]+0x14):
undefined reference to
`_ZNSt12_Vector_baseIiSaIiEE12_Vector_implC1EvQ26is_default_constructible_vIN9__gnu_cxx14__alloc_traitsIT0_NS5_10value_typeEE6rebindIT_E5otherEE'
Though, libstdc++.so.6 abilist is the same.
Trying to debug it now.
2024-04-24 Jakub Jelinek
Jason Merrill
PR lto/113208
also used 202000L for -std=c2x but
Clang 18+ uses 202311L as specified in the latest C23 drafts.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2024-04-25 Jakub Jelinek
* init.cc (cpp_init_builtins): Change __STDC_VERSION__
for C23 from 202000L to 202311L
On Wed, Apr 24, 2024 at 06:39:33PM -0400, Jason Merrill wrote:
> > --- gcc/cp/decl2.cc.jj 2024-04-23 14:49:41.933186265 +0200
> > +++ gcc/cp/decl2.cc 2024-04-24 15:17:09.043625729 +0200
> > @@ -3314,7 +3314,16 @@ tentative_decl_linkage (tree decl)
> > to mark the functions at this
oup, so that when
some comdat group has been chosen already it doesn't try to use some
different one.
Bootstrapped/regtested on x86_64-linux and i686-linux, this one doesn't
regress anything unlike the earlier patch.
2024-04-24 Jakub Jelinek
PR lto/113208
* decl2.c
stale or misplaced until next release in the default case (if people provide
their own root it will be always accurate), we don't need to do anything
further (except perhaps enable the autoregen CI on 14 branch).
2024-04-24 Jakub Jelinek
PR other/114738
* opts.cc (get_option
c++ to preserve
previously exported symbols.
Still, feels like a risky change this late if it wouldn't break ABI of other
libraries.
2024-04-23 Jakub Jelinek
PR lto/113208
* decl2.cc (tentative_decl_linkage): Use comdat_linkage also
for implicit instantiations of maybe i
On Mon, Apr 15, 2024 at 02:19:36PM +0200, Jakub Jelinek wrote:
> They weren't the same, one was trying to evaluate the convert_from_reference
> with vc_glvalue, the other evaluates it without that and with vc_prvalue.
> Now, I guess the
> + /* Undo convert_for_arg_passi
r is used just for -m64/-mx32.
Tried to reduce the testcase further, but it wasn't easily possible.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-04-23 Jakub Jelinek
PR target/114810
* config/i386/i386.md (*andn3_doubleword_bmi): Split the =,r,ro
On Tue, Apr 23, 2024 at 11:40:55AM -0400, David Malcolm wrote:
> > So, I think at least for the MAJOR.MINOR.0 releases we want to use
> > URLs like above rather than the trunk ones and we can use the same
> > process
> > of updating *.opt.urls as well for that.
>
> Would it make sense to instead
Hi!
The nullability-00.m* tests unfortunately check the exact spelling of
the diagnostics I've changed earlier today.
Tested on x86_64-linux and i686-linux, committed to trunk as obvious.
2024-04-23 Jakub Jelinek
* objc.dg/attributes/nullability-00.m: Adjust expected diagnostic
On Tue, Apr 23, 2024 at 04:18:49PM +0200, Jakub Jelinek wrote:
> Then you have two tests (ctestg and ctesta) doing exactly the same thing,
> that can't be right.
> I guess it might be fine to use zlib when it is an alias to zlib-gabi,
> but zlib-gnu shouldn't be replaced.
>
>
On Tue, Apr 23, 2024 at 04:05:07PM +0200, Rainer Orth wrote:
> I noticed that libbacktrace make check FAILs on Solaris with the native
> ld already when building the tests:
>
> libtool: link: /var/gcc/regression/master/11.4-gcc/build/./gcc/xgcc
> -B/var/gcc/r
>
On Tue, Apr 23, 2024 at 11:32:08AM +0100, Jonathan Wakely wrote:
> On Mon, 22 Apr 2024 at 22:30, Jakub Jelinek wrote:
> Yup:
> https://gcc.gnu.org/codingconventions.html#Spelling
>
> That spelling is explicitly mentioned at the link above, so they
> should be "ize"
e"
msgid "recognise the specified suffix as implementation and module filenames"
"initialiser for a dylib."
msgid "%qE attribute argument %qE is not recognised"
2024-04-22 Jakub Jelinek
* config/epiphany/epiphany.opt (may-round-for-trunc)
On Fri, Apr 19, 2024 at 05:54:11PM -0400, Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> I can defer to 15 if needed, of course.
>
> -- >8 --
> When the compiler defaults to -freport-bug, a few dg-ice tests fail
> with:
>
> Excess errors:
> Preprocessed
ped/regtested on x86_64-linux and i686-linux, ok for trunk?
Do you want to copy other flags (and which ones and in which places),
is that ok to be deferred till stage 1?
2024-04-22 Jakub Jelinek
PR c++/114784
* method.cc (implicitly_declare_fn): Call clone_at
On Wed, Apr 17, 2024 at 09:42:47AM +0200, Jakub Jelinek wrote:
> When expand_or_defer_fn is called at_eof time, it calls import_export_decl
> and then maybe_clone_body, which uses DECL_ONE_ONLY and comdat name in a
> couple of places to try to optimize cdtors which are known to have t
) __ ## fld
#endif
...
typedef union
{
double __ctx(d);
float __ctx(f);
} fpreg_t;
and g++ predefining -D_GNU_SOURCE which implies define __USE_MISC.
The following patch adds a workaround for this on the libstdc++ testsuite
side, ok for trunk?
2024-04-22 Jakub Jelinek
just it is a VEX only
encoded instruction and so can't allow APX EGPR regs in the memory operand.
The following patch fixes it, so that we don't force one of the == operands
into memory all the time.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk as
obvious.
2024-04-
Hi!
During backporting I've noticed I've missed one return spot for the
restoration of the original flag_trapv flag value.
Tested on x86_64-linux, committed to trunk as obvious. Sorry.
2024-04-19 Jakub Jelinek
PR middle-end/114753
* internal-fn.cc (expand_arith_overflow
ss not warning about that would be even safer,
but what GCC does I think follows the spec more closely, even when in a
valid program one shouldn't be able to observe the difference.
Ok for trunk and later 13.3 if it passes bootstrap/regtest (so far just
checked on the sentinel related C/C++ tests)?
2024-
On Fri, Apr 19, 2024 at 12:23:03PM +0200, Thomas Schwinge wrote:
> On 2024-04-19T08:24:03+0200, Jakub Jelinek wrote:
> > --- gcc/testsuite/gcc.dg/pr114768.c.jj 2024-04-18 15:37:49.139433678
> > +0200
> > +++ gcc/testsuite/gcc.dg/pr114768.c 2024-04-18 15:43:30.389730
cks it on the source.
The following patch adds the missing side_effects_p checks.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-04-19 Jakub Jelinek
PR rtl-optimization/114768
* rtlanal.cc (set_noop_p): Don't return true for MEM <- MEM
sets
nux, ok for trunk?
2024-04-19 Jakub Jelinek
PR libgcc/114762
* libgcc2.c (__divmodbitint4): Don't decrement vn if all bits
below the most significant limb are zero.
* gcc.dg/torture/bitint-70.c: New test.
--- libgcc/libgcc2.c.jj 2024-04-18 09:48:55.172538667 +0
On Thu, Apr 18, 2024 at 11:25:43AM +0200, Christophe Lyon wrote:
> On Thu, 18 Apr 2024 at 09:37, Jakub Jelinek wrote:
> > The following testcase aborts on aarch64-linux but does not on x86_64-linux.
> > In both cases there is UB in the __divmodbitint4 implemenetation.
>
-linux, plus tested with
make check-gcc -j32 -k GCC_TEST_RUN_EXPENSIVE=1
RUNTESTFLAGS="GCC_TEST_RUN_EXPENSIVE=1 dg.exp='*bitint* pr112673.c
builtin-stdc-bit-*.c pr112566-2.c pr112511.c' dg-torture.exp=*bitint*
dfp.exp=*bitint*"
on aarch64-linux, ok for trunk?
2024-04-18 Jakub Jelin
use some RAII sentinel, but I don't think
we have one in the middle-end.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-04-18 Jakub Jelinek
PR middle-end/114753
* internal-fn.cc (expand_mul_overflow): Save flag_trapv and
temporarily clear
On Wed, Apr 17, 2024 at 01:16:43PM -0400, Eric Gallager wrote:
> > --- a/libcpp/configure
> > +++ b/libcpp/configure
> > @@ -2670,6 +2670,9 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
> >
> >
> >
> > +
> > +
> > +
>
> So, this is kind of a minor style nitpick, but personally, it kind of
> bothers me
On Wed, Apr 17, 2024 at 04:34:07PM +0200, Jan Hubicka wrote:
> I think for most scenarios this is OK, but I am not sure about
> incremental linking (both LTO and non-LTO). What seems wrong is that we
> produce C5 comdat that is not exporting what it should and thus breaking
> the invariant that in
On Wed, Apr 17, 2024 at 03:26:53PM +0200, Jan Hubicka wrote:
> >
> > I've tried to see what actually happens during linking without LTO, so
> > compiled
> > pr113208_0.C with -O1 -fkeep-inline-functions -std=c++20 with vanilla trunk
> > (so it has those 2 separate comdats, one for C2 and one for
On Wed, Apr 17, 2024 at 02:01:55PM +, Christophe Lyon wrote:
> As discussed in the PR, aclocal.m4 and configure were incorrectly
> regenerated at some point.
>
> 2024-04-17 Christophe Lyon
>
> PR preprocessor/114748
> libcpp/
> * aclocal.m4: Regenerate.
> *
On Wed, Apr 17, 2024 at 11:04:26AM +0200, Jan Hubicka wrote:
> > The reason the optimization doesn't trigger when the constructor is
> > constexpr is that expand_or_defer_fn is called in that case much earlier
> > than when it is not constexpr; in the former case it is called when we
> > try to
to the root of the tree which contains the right docs?
Then such changes would go into gcc/configure.ac, some case based on
"$gcc_version", from that decide if it is a release branch or trunk.
2024-04-17 Jakub Jelinek
PR other/114738
* opts.cc (get_option_url):
1 - 100 of 18997 matches
Mail list logo
