https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642
--- Comment #10 from Arsen Arsenović ---
ah, yeah, seems that the common thread is checking. my system compiler is
built with --enable-checking=yes,extra,rtl.
'make -j17 CXXFLAGS=-fno-checking' also seems to work around it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111650
Bug ID: 111650
Summary: ICE in build_deref, at d/d-codegen.cc:1650
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111768
--- Comment #6 from Arsen Arsenović ---
this poses another problem too, though: should big and little cores ever differ
in ISA support levels, building on big cores (which seems like a reasonable
thing to do) with -march=native could lead to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111768
--- Comment #8 from Arsen Arsenović ---
(In reply to Alexander Monakov from comment #7)
> I'm afraid hybrid CPUs with varying ISA feature sets are not practical for
> the current ecosystem: you wouldn't be able to reschedule from a higher- to
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106188
Arsen Arsenović changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106713
Arsen Arsenović changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109602
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109602
Arsen Arsenović changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
Arsen Arsenović changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109625
--- Comment #2 from Arsen Arsenović ---
almost certainly started with r14-92-g58b7dbf865b146, of course
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109625
--- Comment #1 from Arsen Arsenović ---
related code (folly/Traits.h)
#if FOLLY_HAS_BUILTIN(__type_pack_element)
template
using type_pack_element_t = __type_pack_element;
#else
template
using type_pack_element_t =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108171
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109686
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109686
--- Comment #3 from Arsen Arsenović ---
no problem, thank you for reporting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109473
Bug ID: 109473
Summary: ICE during GIMPLE pass: vect: verify_gimple failed
with -m32
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109473
Arsen Arsenović changed:
What|Removed |Added
Summary|ICE during GIMPLE pass: |ICE during GIMPLE pass:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109473
--- Comment #7 from Arsen Arsenović ---
LGTM - the original, unreduced, case builds on trunk. thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954
--- Comment #20 from Arsen Arsenović ---
I agree, it's probably better to just update all references to be clear that
-m32 generates IA32 code, rather than i?86 code.
IMO, for multilib, it's reasonable to target the same CPU as -m64 in terms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110789
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109814
--- Comment #13 from Arsen Arsenović ---
(In reply to Jonathan Wakely from comment #12)
> I suppose we could enable if hosted || newlib, but that wouldn't
> always be right because (IIUC) you can configure newlib without any of the
> libm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110427
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109814
--- Comment #10 from Arsen Arsenović ---
(In reply to lesto fante from comment #9)
> To be fair I have no idea what would be the impact of removing freestanding,
> from a quick test does not seems to have a realistic impact.
>
> I guess what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108250
--- Comment #13 from Arsen Arsenović ---
as an update, we've recently gotten valgrind working on a ppc32 machine, and we
get the following:
==2738== Conditional jump or move depends on uninitialised value(s)
==2738==at 0x17E55C: __eq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109864
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109814
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109783
Bug ID: 109783
Summary: missing warning (due to a wrong suppression) when
va_end is not in the same function
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
--- Comment #9 from Arsen Arsenović ---
(In reply to Jakub Jelinek from comment #8)
> I certainly work on stage 1 all the time, that is where I develop everything
> I do
> (of course once something is written, I test it with full bootstrap, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112997
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113019
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534
--- Comment #10 from Arsen Arsenović ---
Created attachment 56915
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56915=edit
[PATCH] toplevel: don't override gettext-runtime/configure-discovered build
args
here's a preliminary patch,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534
--- Comment #9 from Arsen Arsenović ---
removing EXTRA_HOST_FLAGS from the gettext targets fixed the build on my
cfarm112.
overall, I'm not sure overriding what subconfigures discover and adjust CC and
CFLAGS with is a good idea. it seems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534
--- Comment #12 from Arsen Arsenović ---
(In reply to seurer from comment #11)
> Did it work?
yes, I sent it on the ML:
https://inbox.sourceware.org/gcc-patches/20231221193243.368541-1-ar...@aarsen.me/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87950
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113283
--- Comment #9 from Arsen Arsenović ---
(In reply to cqwrteur from comment #6)
> if someone writes an operating system or libc，he can ensure the abi being
> the same.
that's a job of theirs. they can and should add OS defines for their OS.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108849
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113283
--- Comment #11 from Arsen Arsenović ---
could be implemented in libstdc++ when no libc impl is present
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113283
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534
--- Comment #6 from Arsen Arsenović ---
(In reply to Jakub Jelinek from comment #5)
> The problem is that the toplevel configure (which is autoconf 2.69 as pretty
> much everything in gcc) uses the older AC_PROG_CC, which only checks for
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534
--- Comment #8 from Arsen Arsenović ---
(In reply to Jakub Jelinek from comment #7)
> Exporting say CC or CXX to the host CC/CXX in stage1 and previous-stage/xgcc
> -B previous-stage/ and similar is obviously required, otherwise bootstrap
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112826
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112671
--- Comment #3 from Arsen Arsenović ---
hm, actually, I think I confused reports - sorry.
do you know if this worked a short while ago? and if so, how did such a
configuration look?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534
--- Comment #4 from Arsen Arsenović ---
(In reply to Bruno Haible from comment #2)
> > gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC)
> > gcc -std=gnu99 ...
> > error: unknown type name 'max_align_t'
>
> The type 'max_align_t' exists in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112671
--- Comment #1 from Arsen Arsenović ---
yes, this also came up from the binutils side. see
https://inbox.sourceware.org/binutils/874jhg2x6p@adacore.com/
I will restore the modifications in the shared tree with the few other patches
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114206
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114529
--- Comment #2 from Arsen Arsenović ---
full build.log also:
https://dev.gentoo.org/~arsen/gcc-14.0.1_pre20240331-Werror-odr-build.log.gz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534
--- Comment #14 from Arsen Arsenović ---
indeed, system gettext should be unaffected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114748
--- Comment #5 from Arsen Arsenović ---
hm, that's odd, my local machine can also regenerate to Cristophes version also
today.. I wonder why it did not back then.. what should we do about it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114866
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114940
--- Comment #5 from Arsen Arsenović ---
imo, creating a divergent code path for this case isn't worth it, especially
for something that isn't trivial. I'd opt for checking for sized dealloc in
version.def.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114940
--- Comment #7 from Arsen Arsenović ---
(In reply to Jonathan Wakely from comment #6)
> What would be needed to work without it? It looks like the allocation would
> have to be larger so the size could be stored as a cookie at the start of
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115175
Bug ID: 115175
Summary: GCC fails to bootstrap with
--with-build-config='bootstrap-O3 bootstrap-lto' at
r15-698-g38d1761c0c94b7
Product: gcc
Version: 15.0
54 matches
Mail list logo
