https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #25 from Andreas Schwab ---
I don't think this is wrong, as long as DECIMAL_DIG <= 37.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99494
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96307
--- Comment #10 from Andreas Schwab ---
This disables the CC_HAS_KASAN_GENERIC config of the kernel, making KASAN
unavailable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96307
Andreas Schwab changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99891
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99896
--- Comment #3 from Andreas Schwab ---
regcomp and re_search are always incompatible.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99896
--- Comment #5 from Andreas Schwab ---
The bug is in gdb because re_search cannot be paired with regcomp.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989
Bug ID: 99989
Summary: [11 regression] False maybe-uninitialized warning
breaks bootstrap on riscv64
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989
Andreas Schwab changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989
Andreas Schwab changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 99989, which changed state.
Bug 99989 Summary: [11 regression] -Wmaybe-uninitialized warning breaks
bootstrap on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98265
Bug 98265 depends on bug 99989, which changed state.
Bug 99989 Summary: [11 regression] -Wmaybe-uninitialized warning breaks
bootstrap on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100014
--- Comment #2 from Andreas Schwab ---
According to the autoconf docs, it should work also when cross-compiling:
This macro runs a test-case if endianness cannot be determined
from the system header files. When cross-compiling, the t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100049
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100096
--- Comment #7 from Andreas Schwab ---
That's just the consequence of text relocations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100177
Andreas Schwab changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100177
Andreas Schwab changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97409
--- Comment #6 from Andreas Schwab ---
You need to configure binutils with the same target as the compiler you want to
build.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504
--- Comment #1 from Andreas Schwab ---
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556477.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504
Andreas Schwab changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97651
Andreas Schwab changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97682
Bug ID: 97682
Summary: Miscompiled tail call with -fPIC
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97682
--- Comment #1 from Andreas Schwab ---
Looks like the miscompilation happens in the pro_and_epilog pass.
Before:
(insn 2520 2519 2521 320 (set (reg:DI 6 t1)
(symbol_ref/i:DI
("_ZNSt6vectorIN4llvm26BlockFrequencyInfoImplBase13FrequencyDa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97682
--- Comment #2 from Andreas Schwab ---
I think the bug is really that riscv_legitimize_call_address uses
RISCV_PROLOGUE_TEMP, which can conflict with its uses in the epilogue, as seen.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97692
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97692
--- Comment #7 from Andreas Schwab ---
https://gcc.gnu.org/install/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97793
Bug ID: 97793
Summary: Bogus return-type warning
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97817
--- Comment #2 from Andreas Schwab ---
But when it's 6 it's truncated.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840
Bug ID: 97840
Summary: [11 regression] Bogus -Wmaybe-uninitialized
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97853
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840
Andreas Schwab changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97884
--- Comment #11 from Andreas Schwab ---
2147483648 does not fit in 32 bits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97907
--- Comment #1 from Andreas Schwab ---
f1 invokes undefined behaviour by modifying an input-only asm operand.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97907
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97948
--- Comment #1 from Andreas Schwab ---
See also PR81358.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97982
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98004
--- Comment #1 from Andreas Schwab ---
Output: terminate called after throwing an instance of 'std::system_error'
what(): Unknown error -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98005
--- Comment #1 from Andreas Schwab ---
/daten/aranym/gcc/gcc-20201125/libstdc++-v3/testsuite/std/ranges/adaptors/sizeof.cc:45:
error: static assertion failed
/daten/aranym/gcc/gcc-20201125/libstdc++-v3/testsuite/std/ranges/adaptors/sizeof.cc:47:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98005
--- Comment #3 from Andreas Schwab ---
Objects of type ranges::take_while_view or
ranges::transform_view do have the correct size, though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98005
--- Comment #4 from Andreas Schwab ---
Except that those are not the failing assertions.
sizeof(ranges::take_while_view) and
sizeof(ranges::transform_view) are both 10, probably
because sizeof(pred_l) and sizeof(func_l) are 1, and padding is dif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021
--- Comment #5 from Andreas Schwab ---
> For '#warning "xxx"' they're the same
That is not true. There can be comments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021
--- Comment #6 from Andreas Schwab ---
Also, the source may come from a different place than the directive.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021
--- Comment #8 from Andreas Schwab ---
That still doesn't handle the case when the source comes from a different
place.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021
--- Comment #10 from Andreas Schwab ---
See the #line directive.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021
--- Comment #12 from Andreas Schwab ---
> GCC already treats that case differently
In which way?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021
--- Comment #14 from Andreas Schwab ---
I don't follow. It works exactly the same way.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021
--- Comment #16 from Andreas Schwab ---
There is no difference between these cases. GCC will always show the source
lines that are available. Of course, it will never pull anything out of thin
air, but that is obvious.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98127
Bug ID: 98127
Summary: [11 regression] libada lacks objects needed for
128-bit types
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98152
Bug ID: 98152
Summary: [11 regression] /usr/bin/env: 'python': No such file
or directory
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98152
Andreas Schwab changed:
What|Removed |Added
Target Milestone|--- |11.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83466
--- Comment #6 from Andreas Schwab ---
The same issue exists for SYMBOL_SMALL_TLSIE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98290
Andreas Schwab changed:
What|Removed |Added
Resolution|FIXED |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98320
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97264
--- Comment #5 from Andreas Schwab ---
Why doesn't gcc warn about that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97308
--- Comment #1 from Andreas Schwab ---
You need to attach the config.log file in `/home/tkoenig/trunk-bin/gmp'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
--- Comment #16 from Andreas Schwab ---
On powerpc64:
FAIL: gfortran.dg/pr96711.f90 -O0 (internal compiler error)
FAIL: gfortran.dg/pr96711.f90 -O0 (test for excess errors)
Excess errors:
f951: internal compiler error: Could not find real
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
--- Comment #18 from Andreas Schwab ---
Any ICE is a bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
--- Comment #20 from Andreas Schwab ---
Any ICE is a bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98389
--- Comment #1 from Andreas Schwab ---
The list just needs to be updated.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98395
--- Comment #1 from Andreas Schwab ---
What does size tell?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98504
--- Comment #2 from Andreas Schwab ---
Does it also fail without LTO?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98511
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98510
--- Comment #1 from Andreas Schwab ---
*** Bug 98511 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98627
--- Comment #1 from Andreas Schwab ---
How did you configure the compiler?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98627
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98627
Andreas Schwab changed:
What|Removed |Added
Resolution|FIXED |INVALID
--- Comment #5 from Andreas Sch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98627
Andreas Schwab changed:
What|Removed |Added
Resolution|FIXED |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98702
Andreas Schwab changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823
--- Comment #2 from Andreas Schwab ---
go_load is defined in lib/gcc-dg.exp.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823
--- Comment #4 from Andreas Schwab ---
That's standard part of dejagnu.
/usr/share/dejagnu/standard.exp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823
--- Comment #5 from Andreas Schwab ---
And for the unix board, its implementation is in
/usr/share/dejagnu/config/unix.exp.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823
--- Comment #7 from Andreas Schwab ---
Perhaps the test is blocking or ignoring SIGTERM, or handling it in some
incompatible way.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98902
--- Comment #1 from Andreas Schwab ---
What's your target? There is supposed to be ".set a2,a1" at the end.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98902
Andreas Schwab changed:
What|Removed |Added
Resolution|FIXED |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98921
Bug ID: 98921
Summary: [11 regression] libphobos: junk in generated symbol
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98921
Andreas Schwab changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98923
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98921
Andreas Schwab changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98921
--- Comment #2 from Andreas Schwab ---
diff --git a/gcc/d/dmd/dmangle.c b/gcc/d/dmd/dmangle.c
index f6eee52afbf..73d9ac5367f 100644
--- a/gcc/d/dmd/dmangle.c
+++ b/gcc/d/dmd/dmangle.c
@@ -822,7 +822,7 @@ public:
void visit(IntegerExp *e)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99143
--- Comment #3 from Andreas Schwab ---
If you want to save space you should use -Os, not -O2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99143
--- Comment #5 from Andreas Schwab ---
That's still sacrificing speed for space.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100412
--- Comment #1 from Andreas Schwab ---
Or just change the test name to make it unique.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100404
--- Comment #6 from Andreas Schwab ---
EFAULT is always optional. POSIX is clear about that:
[EFAULT]
Bad address. The system detected an invalid address in attempting to use an
argument of a call. The reliable detection of this error cannot b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100473
--- Comment #1 from Andreas Schwab ---
$ git grep 'optimize >= 2'
gcc/ChangeLog-2008: 100 for optimize >= 2.
gcc/ChangeLog-2010: only conditionally on optimize >= 2.
gcc/ada/gcc-interface/trans.c:&& optimize >= 2
gcc/c-family/c-o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100591
Bug ID: 100591
Summary: -fsanitize=undefined fails to detect undefined
floating to integer conversion
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100597
Andreas Schwab changed:
What|Removed |Added
Host|x86_64-linux-gnu|
--- Comment #1 from Andreas Schwab -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100597
Andreas Schwab changed:
What|Removed |Added
Status|WAITING |NEW
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100597
--- Comment #6 from Andreas Schwab ---
Reverting ca9bb74a5f8 fixes bootstrap for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100805
--- Comment #1 from Andreas Schwab ---
The C++ standard says: [lex.icon] "If an integer literal cannot be represented
by any type in its list and an extended integer type (6.8.1) can represent its
value, it may have that extended integer type."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108405
--- Comment #3 from Andreas Schwab ---
NPTL does not have the alignment restriction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108433
--- Comment #2 from Andreas Schwab ---
The target libraries should not be built in a canadian cross build, they were
already produced while building the cross compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108472
--- Comment #3 from Andreas Schwab ---
You are mixing two different ada compilers:
/opt/imed/gcc12/bin/gcc -c -g -gnatpg -gnatwns -W -Wall -I- -I.
-Iada/generated -Iada -I../../gcc-12.2.0/gcc/ada
../../gcc-12.2.0/gcc/ada/gnat1drv.adb -o ada/g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108515
--- Comment #7 from Andreas Schwab ---
Are you sure this isn't due to the binutils patch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108538
--- Comment #1 from Andreas Schwab ---
It depends on the selected C++ standard. C++11 does not allow narrowing
conversions unconditionally.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108700
--- Comment #3 from Andreas Schwab ---
The grammar doesn't tell everything, though currently only storage-class
specifiers are expected to occur at the beginning.
>From c-parser.cc:c_parser_declspecs:
/* TODO: Distinguish between func
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108723
Andreas Schwab changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #1 from Andreas Schwab ---
Can you use __builtin_frame_address instead?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #3 from Andreas Schwab ---
Perhaps it works if you declare the register variable in file scope.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108989
Andreas Schwab changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108682
--- Comment #3 from Andreas Schwab ---
libgo/goarch.sh is missing LoongArch support.
1 - 100 of 534 matches
Mail list logo
