[Bug tree-optimization/93781] Optimizer produces suboptimal code related to -ftree-vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93781
--- Comment #2 from vfdff ---
For more test, I find the following case2 can get the expect result, while the
case1 can't.
== [case1] ==
unsigned int foo (unsigned int arg)
{
unsigned int C03FE = 4;
if ((int)(arg -3) < 0)
C03FE = 0x1 << arg;
return C03FE < 5;
}
== [case2] ==
unsigned int foo (unsigned int arg)
{
unsigned int C03FE = 4;
if (arg < 3)
C03FE = 0x1 << arg;
return C03FE < 5;
}
[Bug target/94059] [10 Regression] m68k: Bootstrap fails configuring libiberty with 'cannot compute sizeof (long long)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94059 --- Comment #3 from John Paul Adrian Glaubitz --- (In reply to Jeffrey A. Law from comment #2) > Also note I bootstrap m68k regularly, last build was: > > 8e6d0dba166324f4b257329bd4b4ddc2b4522359 > > Without more relevant data, there's nothing we can do here. I'm testing now whether this might have been caused by r10-6919-gf3ce088645e5305d932380c7520809181b2d2eb9 as well.
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #36 from John Paul Adrian Glaubitz --- The m68k bootstrap also recently got broken (PR/94059). Currently testing whether this is also a result of this change (r10-6919-gf3ce088645e5305d932380c7520809181b2d2eb9).
[Bug tree-optimization/94084] Optimizer produces suboptimal code related to loop-invariant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94084 --- Comment #3 from Andrew Pinski --- (In reply to vfdff from comment #2) > thanks very much, you are right. The same problem is here.
[Bug tree-optimization/94084] Optimizer produces suboptimal code related to loop-invariant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94084
--- Comment #2 from vfdff ---
thanks very much, you are right.
I try the case2 with global pointer and it get similar result with case1.
extern int base;
extern int *dest, *src;
void foo (int n)
{
int i;
// #pragma no_swp
for (i=0; i < n; i++)
dest[base+i] = src[base+i];
}
[Bug target/94085] New: pdp11-aout puts initial variable into .text section rather than .data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94085
Bug ID: 94085
Summary: pdp11-aout puts initial variable into .text section
rather than .data
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: casner at acm dot org
Target Milestone: ---
The assembler output for a C program compiled for the pdp11-aout target begins
with a .text directive. If that program begins with a variable that is not
initialized to a nonzero value, that variable will be left if the .text section
rather than being allocated to the .data section. If the first variable is
initialized to a nonzero value, then a .data directive is inserted after the
.text directive to switch sections. This bug matters for formats where the
text section is read-only or with split instruction and data spaces.
I selected component target, but I don't know if this problem is specific to
the pdp11-aout target.
Here is a simple example showing this problem:
Command: pdp11-aout-gcc -ffreestanding -nostdlib -S -o zero.s zero.c
static int zero = 0;
static int one = 1;
int main() {}
.text
.even
_zero: .=.+ 02
.data
.even
_one:
.word 01
.text
.even
.globl _main
_main:
setd
seti
mov r5,-(sp)
mov sp,r5
jsr pc,___main
nop
mov (sp)+,r5
rts pc
If the first variable is initialized to a nonzero value, the output is correct:
Command: pdp11-aout-gcc -ffreestanding -nostdlib -S -o one.s one.c
static int one = 1;
static int zero = 0;
int main() {}
.text
.data
.even
_one:
.word 01
.even
_zero: .=.+ 02
.text
.even
.globl _main
_main:
setd
seti
mov r5,-(sp)
mov sp,r5
jsr pc,___main
nop
mov (sp)+,r5
rts pc
My environment is a macOS host and pdp11-aout target.
GNU C17 (GCC) version 10.0.1 20200303 (experimental) (pdp11-aout)
compiled by GNU C version 4.2.1 Compatible Apple LLVM 11.0.0
(clang-1100.0.33.17), GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0,
isl version isl-0.20-GMP
Configured with: ../configure --target=pdp11-aout --prefix=/usr/local
--disable-libstdc++-v3 --disable-libssp --disable-libgfortran --disable-libobjc
--disable-libbacktrace --with-gmp=/opt/local/ --with-mpfr=/opt/local/
--with-mpc=/opt/local/
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #35 from Andrew Pinski --- (In reply to Martin Liška from comment #15) > Started with r10-6919-gf3ce088645e5305d932380c7520809181b2d2eb9. This change goes against what HONOR_REG_ALLOC_ORDER is documented on doing (I Mean the false case of HONOR_REG_ALLOC_ORDER): Normally, IRA tries to estimate the costs for saving a register in the prologue and restoring it in the epilogue. This discourages it from using call-saved registers. If a machine wants to ensure that IRA allocates registers in the order given by REG_ALLOC_ORDER even if some call-saved registers appear earlier than call-used ones, then define this macro as a C expression to nonzero. Default is 0. Since r8 is still a caller-saved register, HONOR_REG_ALLOC_ORDER should not make a difference here. The order for rs6000 is: MAYBE_R2_AVAILABLE \ 9, 10, 8, 7, 6, 5, 4,\ 3, EARLY_R12 11, 0, \ Still that should apply here rather than register number based. Really doing cost based on register # seems incorrect anyways. These are all caller-saved registers IIRC. r0 is special in rs6000 where it sometimes cannot show up; e.g. base+reg base cannot be r0.
[Bug c/94075] When using linker-generated list, bad optimization performed in -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94075
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Andrew Pinski ---
GCC think incrementing start will never get to end.
So you need to hide that from GCC.
The best way is doing:
({ static const int foo[0] __attribute__((aligned(4), section(".foo_1")));
const int *a = &foo[0]; __asm__("":"+r"(a)); a});
libgcc does that in crtstuff.c:
fn = _ITM_deregisterTMCloneTable;
__asm ("" : "+r" (fn));
[Bug tree-optimization/94084] Optimizer produces suboptimal code related to loop-invariant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94084 Andrew Pinski changed: What|Removed |Added Component|rtl-optimization|tree-optimization Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- dest could alias base in the first case. Though it could only be if n == 1,
[Bug libstdc++/94080] -mabi=ieeelongdouble and -mfloat128 cause libstc++ header breakage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94080 Andrew Pinski changed: What|Removed |Added Component|c++ |libstdc++ --- Comment #1 from Andrew Pinski --- I suspect you need to configure gcc originally to use that abi. Otherwise libstdc++ config header is not correct.
[Bug other/91139] Attempts, fails to rebuild doc/gcc.info in tarball release build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91139 --- Comment #4 from Daniel Richard G. --- (In reply to Martin Liška from comment #3) > > So is the issue fixed or not? Not fixed as of 9.2.0, I'm afraid: [...] if [ xinfo = xinfo ]; then \ makeinfo --split-size=500 --split-size=500 --split-size=500 --no-split -I . -I ../../gcc--9.2.0/gcc/doc \ -I ../../gcc--9.2.0/gcc/doc/include -o doc/cpp.info ../../gcc--9.2.0/gcc/doc/cpp.texi; \ fi if [ xinfo = xinfo ]; then \ makeinfo --split-size=500 --split-size=500 --split-size=500 --no-split -I . -I ../../gcc--9.2.0/gcc/doc \ -I ../../gcc--9.2.0/gcc/doc/include -o doc/gcc.info ../../gcc--9.2.0/gcc/doc/gcc.texi; \ fi ../../gcc--9.2.0/gcc/doc//invoke.texi:1783: @include `/users/cport/tmp/gcc-build/gcc/../../gcc-9.2.0/gcc/../libiberty/at-file.texi': No such file or directory. ../../gcc--9.2.0/gcc/doc//extend.texi:7097: warning: `.' or `,' must follow @xref, not `f'. ../../gcc--9.2.0/gcc/doc//extend.texi:8181: warning: `.' or `,' must follow @xref, not `f'. makeinfo: Removing output file `doc/gcc.info' due to errors; use --force to preserve. Makefile:3228: recipe for target 'doc/gcc.info' failed gmake[3]: *** [doc/gcc.info] Error 1 gmake[3]: Leaving directory '/home/skunk/tmp/gcc-build/gcc' Makefile:4661: recipe for target 'all-stage1-gcc' failed gmake[2]: *** [all-stage1-gcc] Error 2 gmake[2]: Leaving directory '/home/skunk/tmp/gcc-build' Makefile:22313: recipe for target 'stage1-bubble' failed gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory '/home/skunk/tmp/gcc-build' Makefile:22649: recipe for target 'bootstrap' failed gmake: *** [bootstrap] Error 2 (Note the reference to "gcc-9.2.0" when the actual path is "gcc--9.2.0")
[Bug c/94084] New: Optimizer produces suboptimal code related to loop-invariant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94084
Bug ID: 94084
Summary: Optimizer produces suboptimal code related to
loop-invariant
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
For the following case1 and case2, we can known the global value base is a loop
invariant value, so the load insn can be lifted out of the loop kernel.
But we can find that the case1 and case2 have different result, and the code of
case1 need more optimization.
test base on the x86-64 with https://gcc.godbolt.org/
== [case1] ==
extern int base;
void foo (int dest[], int src[], int n)
{
int i;
// #pragma no_swp
for (i=0; i < n; i++)
dest[base+i] = src[base+i];
}
foo:
testedx, edx
jle .L1
xor ecx, ecx
.L3:
mov eax, DWORD PTR base[rip] /* expected exist out of loop */
add eax, ecx
add ecx, 1
cdqe
mov r8d, DWORD PTR [rsi+rax*4]
mov DWORD PTR [rdi+rax*4], r8d
cmp edx, ecx
jne .L3
.L1:
ret
== [case2] ==
extern int base;
extern int dest[], src[];
void foo (int n)
{
int i;
// #pragma no_swp
for (i=0; i < n; i++)
dest[base+i] = src[base+i];
}
foo:
testedi, edi
jle .L1
movsx rdx, DWORD PTR base[rip] /* already exist out of loop */
lea ecx, [rdi-1]
lea rcx, [rdx+1+rcx]
lea rax, [0+rdx*4]
sal rcx, 2
.L3:
mov edx, DWORD PTR src[rax]
add rax, 4
mov DWORD PTR dest[rax-4], edx
cmp rax, rcx
jne .L3
.L1:
ret
[Bug middle-end/94083] inefficient soft-float x!=Inf code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94083 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|normal |minor --- Comment #1 from Andrew Pinski --- Most people don't use soft-float these days except for the low-end embedded folks. And even then, the low-end embedded folks try to avoid floating point. So I don't know many people who cares about soft-float.
[Bug middle-end/94083] New: inefficient soft-float x!=Inf code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94083
Bug ID: 94083
Summary: inefficient soft-float x!=Inf code
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: wilson at gcc dot gnu.org
Target Milestone: ---
Given a testcase like this
int foo(void) {
volatile float f;
intn;
f = __builtin_huge_valf();
n += 1 - (f != __builtin_huge_valf());
return n;
}
and compiling for soft-float, we end up with a call to __unordsf2 followed by a
call to __lesf2. This means the floats have to be unpacked twice and checked
for nan twice. This gives both poor performance and poor code size. I've
confirmed this for x86, arm, and riscv.
Folding in the C front end is creating an unordered less then or equal
comparison against FLT_MAX. From the 004.original file
n = SAVE_EXPR + n;
This optimization is coming from a rule in the match.pd file.
/* x != +Inf is always equal to !(x > DBL_MAX), but this introduces
an exception for x a NaN so use an unordered comparison. */
When we generate rtl, we call do_compare_rtx_and_jump which notices that we
don't have an operation for UNLE_EXPR, but decides we can't reverse it because
it is unsafe. It tries swapping arguments, but we don't have UNGE_EXPR either.
So it emits two libcalls.
Converting a NE compare to a UNLE compare looks like an odd optimization. If
we want to consider unordered operations as canonical operations, then maybe we
should add libgcc support for the unordered operations. Or maybe we should
check to see if unordered operations are handled by the target before
converting a simple NE into a UNLE.
The match.pd rule was changed to use UNLE in the patch for PR 64811 which fixed
a problem with handling NaNs. This happened 2018-01-09. The optimization
dates back to 2003-05-22 but was originally using LE which is OK for
soft-float. It wasn't until the NaN bug was fixed by using UNLE instead of LE
that this became an optimization problem.
Maybe we just shouldn't perform this optimization when honoring NaNs? That
would avoid generating the problematic unordered operation early in the
optimizer.
[Bug libstdc++/94033] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033 --- Comment #5 from Rafael Avila de Espindola --- Created attachment 47994 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47994&action=edit reduced testcase I have reduced it a bit further.
[Bug c++/94082] New: __builtin_memcpy in constexpr context should compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94082
Bug ID: 94082
Summary: __builtin_memcpy in constexpr context should compile
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: D.Bahadir at GMX dot de
Target Milestone: ---
Compilation fails with the following code:
```
#include
#include
#include
constexpr std::uint32_t extract(const std::uint8_t* data) noexcept
{
std::uint32_t num;
__builtin_memcpy(&num, data, sizeof(std::uint32_t));
return num;
}
int main()
{
constexpr std::array a1 {{ 0xff, 0xff, 0xff, 0xff }};
constexpr auto val = extract(a1.data()); // <--- Error in constexpr
context
return val;
}
```
I would have expected that using `__builtin_memcpy` in a `constexpr` context
would compile just fine and be probably completely optimized out. However,
compilation fails.
Interestingly, GCC is able to fully optimize the above code when omitting the
`constexpr` in the marked line (and therefore not calling the function from a
`constexpr` context). (Whether the function is marked `constexpr`, `inline` or
neither does not matter. It will be fully optimized in non-`constexpr` context.
However, writing some similar `constexpr` function with `__builtin_bswap32` in
it and calling that from a `constexpr` context, succeeds and will be fully
optimized.
For demonstration of this issue and a nice comparison between
`__builtin_bswap32` and `__builtin_memcpy` in `constexpr` context see Compiler
Explorer: https://godbolt.org/z/qtMmqw
Note: The following StackOverflow question touches the same issue:
https://stackoverflow.com/q/60572199/3115457
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 kargl at gcc dot gnu.org changed: What|Removed |Added CC|kargl at gcc dot gnu.org | --- Comment #44 from kargl at gcc dot gnu.org --- I have posted a large patch that fixes all problems that I am aware of. Feel free to use it or ignore. https://gcc.gnu.org/ml/fortran/2020-03/msg00024.html
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #34 from Segher Boessenkool --- Yeah, 16 (or really 12-ish, not all are available) I call "tiny" :-) It is very surprising (and not pleasantly so) that this overrides REG_ALLOC_ORDER. We allocate GPR0 last (of the volatile GPRs), on purpose. Other volatile registers we also do not do in order at all, and this has been heavily tuned over the years. And for non-GPRs it is even more wild, like CRs are 0 7 5 6 1 (and yes, this matters). We don't want HONOR_REG_ALLOC_ORDER, it is way *too* strict, but all else being equal, we probably(*) want our order to be followed, as it was before. (*) I didn't actually benchmark things yet!
[Bug c/94081] New: -Waddress-of-packed-member doesn’t take variable attributes or __builtin_assume_aligned into account
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94081
Bug ID: 94081
Summary: -Waddress-of-packed-member doesn’t take variable
attributes or __builtin_assume_aligned into account
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: felix.von.s at posteo dot de
Target Milestone: ---
In this code:
#include
struct foo {
uint16_t a, b;
} __attribute__((packed));
extern struct foo *f(void);
extern void g(uint16_t *p);
void h(void) {
struct foo *s0 = __builtin_assume_aligned(f(), 16);
g(&s0->a);
struct foo s1 __attribute__ ((aligned(16)));
g(&s1.a);
}
GCC will warn about taking the address of s0->a and s1.a, even though it has
enough information to recognise those as false positives.
On many platforms, variables on the stack are naturally aligned at a 32-bit
boundary, so I believe &s1.a is a false positive on those platforms as well,
but I’m less sure if skipping the warning for this case is desirable.
[Bug c++/94074] bogus modifying a const object error with const COMPONENT_REF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94074
--- Comment #2 from Marek Polacek ---
And this should be diagnosed but isn't:
struct X {
int i;
};
template
struct S {
const X x;
constexpr S(int) : x{}
{
const_cast(x).i = 19; // { dg-error "modifying a const object" }
}
};
constexpr S p = { 10 }; // { dg-message "originally declared" }
[Bug c++/94080] New: -mabi=ieeelongdouble and -mfloat128 cause libstc++ header breakage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94080 Bug ID: 94080 Summary: -mabi=ieeelongdouble and -mfloat128 cause libstc++ header breakage Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: murphyp at linux dot vnet.ibm.com Target Milestone: --- Target: powerpc64le When both -mfloat128 and -mabi=ieeelongdouble are used, various libstc++ headers break. I suspect more headers have similar problems. I.e "#include ": cc1plus: warning: Using IEEE extended precision long double [-Wpsabi] In file included from /home/murp/glibc-scratch/install/compilers/powerpc64le-linux-gnu/powerpc64le-glibc-linux-gnu/include/c++/9.2.1/bits/move.h:55, from /home/murp/glibc-scratch/install/compilers/powerpc64le-linux-gnu/powerpc64le-glibc-linux-gnu/include/c++/9.2.1/bits/stl_pair.h:59, from /home/murp/glibc-scratch/install/compilers/powerpc64le-linux-gnu/powerpc64le-glibc-linux-gnu/include/c++/9.2.1/utility:70, from /home/murp/glibc-scratch/install/compilers/powerpc64le-linux-gnu/powerpc64le-glibc-linux-gnu/include/c++/9.2.1/algorithm:60, from foo.c:1: /home/murp/glibc-scratch/install/compilers/powerpc64le-linux-gnu/powerpc64le-glibc-linux-gnu/include/c++/9.2.1/type_traits:346:12: error: redefinition of ‘struct std::__is_floating_point_helper’ 346 | struct __is_floating_point_helper<__float128> |^~ /home/murp/glibc-scratch/install/compilers/powerpc64le-linux-gnu/powerpc64le-glibc-linux-gnu/include/c++/9.2.1/type_traits:341:12: note: previous definition of ‘struct std::__is_floating_point_helper’ 341 | struct __is_floating_point_helper |^~~ In file included from /home/murp/glibc-scratch/install/compilers/powerpc64le-linux-gnu/powerpc64le-glibc-linux-gnu/include/c++/9.2.1/cstdlib:77, from /home/murp/glibc-scratch/install/compilers/powerpc64le-linux-gnu/powerpc64le-glibc-linux-gnu/include/c++/9.2.1/bits/stl_algo.h:59, from /home/murp/glibc-scratch/install/compilers/powerpc64le-linux-gnu/powerpc64le-glibc-linux-gnu/include/c++/9.2.1/algorithm:62, from foo.c:1: /home/murp/glibc-scratch/install/compilers/powerpc64le-linux-gnu/powerpc64le-glibc-linux-gnu/include/c++/9.2.1/bits/std_abs.h:103:3: error: redefinition of ‘constexpr long double std::abs(long double)’ 103 | abs(__float128 __x) | ^~~ /home/murp/glibc-scratch/install/compilers/powerpc64le-linux-gnu/powerpc64le-glibc-linux-gnu/include/c++/9.2.1/bits/std_abs.h:79:3: note: ‘constexpr long double std::abs(long double)’ previously defined here 79 | abs(long double __x) | ^~~
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #33 from Vladimir Makarov --- (In reply to Segher Boessenkool from comment #32) > So it sounds like this helps for targets with tiny register sets? I guess it helps for any target but of course more for ones with smaller register sets. I'd call 16 reg file (x86-64, 32-bit arm) is small. Tiny one for me would be for i386.
[Bug libstdc++/94063] filesystem::path concatenation doesn't work for Windows root-paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94063
--- Comment #2 from Jonathan Wakely ---
Oops, the testcase is missing "using std::filesystem::path;"
There's a similar problem for Cygwin with path("/") += "/"
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #32 from Segher Boessenkool --- So it sounds like this helps for targets with tiny register sets?
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #31 from Vladimir Makarov --- (In reply to Segher Boessenkool from comment #30) > r10-6919 isn't good for Power, btw. Why would it *ever* be a good idea? This heuristic avoid creating small gaps in hard reg file which prevent assignments for multi-reg pseudos. It decreases average SPEC2000 code size and improves performance at least for Intel i7-9700K (0.5% for SPECINT2000 and about 1% for SPECFP2000). It also solves some recent arm testsuite failures (expected use of callee-clobbered hard regs for multi-regs pseudos). I understand the frustration. Sorry for creating it. Unfortunately in RA heuristic patches there is no a perfect solution. Somebody will always be upset.
[Bug rtl-optimization/93974] [10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974 --- Comment #15 from rsandifo at gcc dot gnu.org --- (In reply to Peter Bergner from comment #14) > (In reply to Vladimir Makarov from comment #13) > > Sorry, I have no good knowledge of decompose_address. The original author > > is Richard Sandiford and it is even not in RA sources (it is in rtlanal.c). > > > > I'd recommend to ask Richard may be he has some insights or just modify to > > make it work in this case. I can only say it is a sensitive code which can > > affect a lot of targets if something is not done right. We had such problems > > with this code in the past. > > Ah, ok, CCing Richard. > > Richard, can you comment on the findings in Comment #4? Do we just need to > add support for seeing a (plus (and: ) (const int 8)) type of address or > should we have never created anything like that in the first place or ??? Sorry for the slow reply, been a bit of a hectic week. I think both fixes would be valid. Like you say, the address parsing code isn't yet ready to handle addresses that apply an offset *before* the address "mutations". That's because no target has yet wanted to support such an address. So as things stand, the current address is not valid and shouldn't have been created. In some ways this is similar to creating an invalid highpart subreg for the upper word of a doubleword vector hard register, or a subreg that falls foul of some simplify_subreg_regno rule. The RA has code to avoid doing that, see init_subregs_of_mode and its users. We could do something similar here for REG_EQUIV MEMs. One option would be to key off whether strip_address_mutations is a no-op on the address. Another would be to check whether each required sub-MEM is valid for its mode and offset. The latter would be more elaborate but might produce better code in general, not just for cases like this. Like you say in comment 4, even the zero-offset half isn't actually a valid address for PowerPC, so either of the two options should give better code as well as fixing the bug. On the other hand, the idea was always that address_info and its users could be extended if new targets have new requirements. So if we want to make this operation valid then that would be OK too.
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #30 from Segher Boessenkool --- r10-6919 isn't good for Power, btw. Why would it *ever* be a good idea?
[Bug testsuite/94079] New: gfortran.dg/vect/pr83232.f90 fails on power 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94079 Bug ID: 94079 Summary: gfortran.dg/vect/pr83232.f90 fails on power 7 Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:be43a8877e2f2f4590ba667b27a24a0cfdf8141d, r9-3621 This is an old one but I am trying to clean up the failing tests on powerpc 64 that have just been ignored. This isn't really a regression as it looks like it has never worked right on power 7. It works OK on other power hardware including other BE. I am pretty sure it is just something not supported on power 7. make -k check-gcc RUNTESTFLAGS=vect.exp=gfortran.dg/vect/pr83232.f90 # of expected passes1 # of unexpected failures1 FAIL: gfortran.dg/vect/pr83232.f90 -O scan-tree-dump-times slp1 "vectorizing stmts using SLP" 3 commit be43a8877e2f2f4590ba667b27a24a0cfdf8141d Author: Richard Biener Date: Wed Oct 24 11:46:58 2018 + re PR tree-optimization/87105 (Autovectorization [X86, SSE2, AVX2, DoublePrecision]) 2018-10-24 Richard Biener PR tree-optimization/87105 * tree-vect-data-refs.c (vect_analyze_group_access_1): Adjust dump classification. (vect_analyze_data_ref_accesses): Handle duplicate loads and stores by splitting the affected group after the fact. * tree-vect-slp.c (vect_build_slp_tree_2): Dump when we fail the SLP build because of size constraints. * gcc.dg/vect/bb-slp-39.c: New testcase. * gfortran.dg/vect/pr83232.f90: Un-XFAIL. From-SVN: r265457
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
Segher Boessenkool changed:
What|Removed |Added
Assignee|marxin at gcc dot gnu.org |segher at gcc dot
gnu.org
--- Comment #29 from Segher Boessenkool ---
I found the problem.
We have
===
/* Implement TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS. */
void
rs6000_disqualify_components (sbitmap components, edge e,
sbitmap edge_components, bool /*is_prologue*/)
{
/* Our LR pro/epilogue code moves LR via R0, so R0 had better not be
live where we want to place that code. */
if (bitmap_bit_p (edge_components, 0)
&& bitmap_bit_p (DF_LIVE_IN (e->dest), 0))
{
if (dump_file)
fprintf (dump_file, "Disqualifying LR because GPR0 is live "
"on entry to bb %d\n", e->dest->index);
bitmap_clear_bit (components, 0);
}
}
===
But looks at LIVE_IN for the epilogue as well, which is wrong (should be
LIVE_OUT then, epilogue is placed at the end of the BB).
[Bug c++/94027] [10 Regression] ice in comptypes, at cp/typeck.c:1489 since r10-6907
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94027 --- Comment #3 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:191bcd0f30dd37dec773efb0125afdcae9bd90ef commit r10-7074-g191bcd0f30dd37dec773efb0125afdcae9bd90ef Author: Nathan Sidwell Date: Fri Mar 6 10:51:26 2020 -0800 Fix mangling ICE [PR94027] PR c++/94027 * mangle.c (find_substitution): Don't call same_type_p on template args that cannot match. Now same_type_p rejects argument packs, we need to be more careful calling it with template argument vector contents. The mangler needs to do some comparisons to find the special substitutions. While that code looks a little ugly, this seems the smallest fix.
[Bug c++/94027] [10 Regression] ice in comptypes, at cp/typeck.c:1489 since r10-6907
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94027 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Nathan Sidwell --- Fixed 191bcd0f30dd37dec773efb0125afdcae9bd90ef
[Bug target/91598] [8/9/10 regression] 60% speed drop on neon intrinsic loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91598 --- Comment #6 from CVS Commits --- The master branch has been updated by Wilco Dijkstra : https://gcc.gnu.org/g:0b8393221177617f19e7c5c5c692b8c59f85fffb commit r10-7073-g0b8393221177617f19e7c5c5c692b8c59f85fffb Author: Wilco Dijkstra Date: Fri Mar 6 18:29:02 2020 + [AArch64] Use intrinsics for widening multiplies (PR91598) Inline assembler instructions don't have latency info and the scheduler does not attempt to schedule them at all - it does not even honor latencies of asm source operands. As a result, SIMD intrinsics which are implemented using inline assembler perform very poorly, particularly on in-order cores. Add new patterns and intrinsics for widening multiplies, which results in a 63% speedup for the example in the PR, thus fixing the reported regression. gcc/ PR target/91598 * config/aarch64/aarch64-builtins.c (TYPES_TERNOPU_LANE): Add define. * config/aarch64/aarch64-simd.md (aarch64_vec_mult_lane): Add new insn for widening lane mul. (aarch64_vec_mlal_lane): Likewise. * config/aarch64/aarch64-simd-builtins.def: Add intrinsics. * config/aarch64/arm_neon.h: (vmlal_lane_s16): Expand using intrinsics rather than inline asm. (vmlal_lane_u16): Likewise. (vmlal_lane_s32): Likewise. (vmlal_lane_u32): Likewise. (vmlal_laneq_s16): Likewise. (vmlal_laneq_u16): Likewise. (vmlal_laneq_s32): Likewise. (vmlal_laneq_u32): Likewise. (vmull_lane_s16): Likewise. (vmull_lane_u16): Likewise. (vmull_lane_s32): Likewise. (vmull_lane_u32): Likewise. (vmull_laneq_s16): Likewise. (vmull_laneq_u16): Likewise. (vmull_laneq_s32): Likewise. (vmull_laneq_u32): Likewise. * config/aarch64/iterators.md (Vcondtype): New iterator for lane mul. (Qlane): Likewise.
[Bug c++/94027] [10 Regression] ice in comptypes, at cp/typeck.c:1489 since r10-6907
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94027 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug fortran/93827] fails to initialize logical variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93827 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to dan hayes from comment #2) > u say "unlike C only occurs once..." Yea so what I know that and it's > not consistently doing that. This is not a recursive routine. What is your > point? > Please use English in your responses. Please find a reference on the Fortran program language. Mark's response is correct. If you use logical*1 :: fl=.false. in a function (or subroutine), then the first time that the function is called the variable 'fl is initialized to .false. When the function or subroutine returns, the variable 'fl' retains whatever its last value was. The next invocation of that function will used that *retained value*. This has nothing to do with recursion. It is the semantics of the language. If 'fl' needs to be .false. at the start of then function on every invocation, then you need to use an assignment.
[Bug libstdc++/94033] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033 --- Comment #4 from Avi Kivity --- Type in build instructions, should be g++ -std=gnu++17 -c database.cc
[Bug libstdc++/94033] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033 --- Comment #3 from Avi Kivity --- Created attachment 47993 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47993&action=edit reduced test case Reduced test case, build with g++ -std=gnu++17 -c database works on gcc 9.2.1, fails on gcc 10.
[Bug c++/94078] New: bogus and missing -Wmismatched-tags on an instance of a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94078 Bug ID: 94078 Summary: bogus and missing -Wmismatched-tags on an instance of a template Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- The test case below shows GCC gets confused by the declarations of the template instances below: it issues -Wmismatched-tags for the wrong declaration and fails to diagnose the one it's supposed to, and it doesn't issue -Wredundant-tags for either of them. $ cat t.C && gcc -Wall -Wextra -Wmismatched-tags -Wredundant-tags -S t.C template struct S; extern class S si;// missing -Wmismatched-tags extern struct S si; // bogus -Wmismatched-tags t.C:3:15: warning: ‘S’ declared with a mismatched class-key ‘struct’ [-Wmismatched-tags] 3 | extern struct S si; // bogus -Wmismatched-tags | ^~ t.C:3:15: note: replace the class-key with ‘class’ t.C:2:14: note: ‘S’ first declared as ‘class’ here 2 | extern class S si;// missing -Wmismatched-tags | ^~ Clang points out the correct declarations: t.C:2:8: warning: class 'S' was previously declared as a struct; this is valid, but may result in linker errors under the Microsoft C++ ABI [-Wmismatched-tags] extern class S si;// missing -Wmismatched-tags ^ t.C:1:25: note: previous use is here template struct S; ^
[Bug sanitizer/94076] libsanitizer fails with 64-bit time_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94076 --- Comment #2 from Arnd Bergmann --- I'm not at the point of the bootstrap where I can attempt building llvm, but I opened another report at https://bugs.llvm.org/show_bug.cgi?id=45138 anyway.
[Bug target/91638] powerpc -mlong-double-NN (documentation) issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91638 --- Comment #6 from Carl Love --- Yea, I like that a bit better. It is a bit shorter, mine was a bit verbose. I updated the patch to print: -mlong-double- Use -mlong-double-64 for 64-bit IEEE floating point format. Use -mlong-double-128 for 128-bit floating point format (either IEEE or IBM). I will post the patch to the mailing list for review/acceptance on mainline.
[Bug target/94077] New: gcc.dg/gomp/pr82374.c fails on power 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94077 Bug ID: 94077 Summary: gcc.dg/gomp/pr82374.c fails on power 7 Product: gcc Version: 8.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- This is an old one but I am trying to clean up the failing tests on powerpc 64 that have just been ignored. This isn't really a regression as it looks like it has never worked right on power 7. It works OK on other power hardware including other BE. I am pretty sure it is just something not supported on power 7. make -k check-gcc RUNTESTFLAGS=gomp.exp=gcc.dg/gomp/pr82374.c # of expected passes1 # of unexpected failures1 FAIL: gcc.dg/gomp/pr82374.c scan-tree-dump-times vect "vectorized 1 loops" 2 g:5c38262d95bedc091083cc881d9e21cd1f215a9a, r8-3584 Author: Jakub Jelinek Date: Wed Oct 4 09:50:38 2017 +0200 re PR tree-optimization/82374 (#pragma GCC optimize is not applied to openmp-generated functions) PR tree-optimization/82374 * omp-low.c (create_omp_child_function): Copy DECL_ATTRIBUTES, DECL_FUNCTION_SPECIFIC_OPTIMIZATION, DECL_FUNCTION_SPECIFIC_TARGET and DECL_FUNCTION_VERSIONED from current_function_decl to the new decl. * gcc.dg/gomp/pr82374.c: New test. From-SVN: r253395
[Bug sanitizer/94076] libsanitizer fails with 64-bit time_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94076 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-03-06 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Can you see the same on llvm? Note that libsanitizer library is taken from LLVM, so I would recommend to report that to upstream.
[Bug target/94065] AIX rs6000 NO_SUM_IN_TOC and NO_FP_IN_TOC disable logic reversed in aix config files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94065 --- Comment #2 from CVS Commits --- The master branch has been updated by David Edelsohn : https://gcc.gnu.org/g:3dcf51ad7b0a9cacba1a056755c16cc1cf7984ee commit r10-7070-g3dcf51ad7b0a9cacba1a056755c16cc1cf7984ee Author: David Edelsohn Date: Thu Mar 5 20:41:08 2020 -0500 rs6000: Correct logic to disable NO_SUM_IN_TOC and NO_FP_IN_TOC [PR94065] aix61.h, aix71.h and aix72.h intends to prevent SUM_IN_TOC and FP_IN_TOC when cmodel=large. This patch defines the variables associated with the target options to 1 to _enable_ NO_SUM_IN_TOC and enable NO_FP_IN_TOC. Bootstrapped on powerpc-ibm-aix7.2.0.0 2020-03-06 David Edelsohn PR target/94065 * config/rs6000/aix61.h (TARGET_NO_SUM_IN_TOC): Set to 1 for cmodel=large. (TARGET_NO_FP_IN_TOC): Same. * config/rs6000/aix71.h: Same. * config/rs6000/aix72.h: Same.
[Bug sanitizer/94076] New: libsanitizer fails with 64-bit time_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94076 Bug ID: 94076 Summary: libsanitizer fails with 64-bit time_t Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: arnd at linaro dot org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- I tried bootstrapping a debian armhf system with an experimental glibc configured with a 64-bit time_t/off_t/ino_t, and saw several failed assertions on 'struct dirent' and 'struct timeb': 339 | typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1] | ^ ../../../../src/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:333:30: note: in expansion of macro 'IMPL_COMPILER_ASSERT' 333 | #define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__) | ^~~~ ../../../../src/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h:1495:3: note: in expansion of macro 'COMPILER_CHECK' 1495 | COMPILER_CHECK(sizeof(__sanitizer_##TYPE) == sizeof(TYPE)) | ^~ ../../../../src/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:1213:1: note: in expansion of macro 'CHECK_TYPE_SIZE' 1213 | CHECK_TYPE_SIZE(timeb); | ^~~ ../../../../src/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:339:70: warning: size of array 'assertion_failed__1213' is not an integral constant-expression [-Wpedantic] In particular: CHECK_SIZE_AND_OFFSET(dirent, d_ino); CHECK_SIZE_AND_OFFSET(dirent, d_off); CHECK_SIZE_AND_OFFSET(dirent, d_reclen); CHECK_TYPE_SIZE(timeb); CHECK_SIZE_AND_OFFSET(timeb, time); CHECK_SIZE_AND_OFFSET(timeb, millitm); CHECK_SIZE_AND_OFFSET(timeb, timezone); CHECK_SIZE_AND_OFFSET(timeb, dstflag); The same thing will likely hit on architectures that always set them to 64-bit, as riscv32 and arc, on musl-1.2+, and on upstream glibc once that the time64 interfaces get enabled there.
[Bug fortran/93827] fails to initialize logical variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93827 --- Comment #2 from dan hayes --- u say "unlike C only occurs once..." Yea so what I know that and it's not consistently doing that. This is not a recursive routine. What is your point? On Wednesday, February 19, 2020, 10:36:43 AM CST, markeggleston at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93827 markeggleston at gcc dot gnu.org changed: What |Removed |Added Status|UNCONFIRMED |RESOLVED CC| |markeggleston at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from markeggleston at gcc dot gnu.org --- Unlike C the initialisation of a local variable at declaration only occurs once on the first entry to the subroutine. See http://www.cs.rpi.edu/~szymansk/OOF90/bugs.html see the section on locally initialised variables.
[Bug d/92792] [10 Regression] symbols dropped from libphobos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92792 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4 CC||law at redhat dot com
[Bug lto/91027] [10 regression] SEGV in hash_table::find_slot_with_hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91027 Jeffrey A. Law changed: What|Removed |Added Priority|P1 |P4 CC||law at redhat dot com --- Comment #10 from Jeffrey A. Law --- Concur with Jakub on this. We don't even consider Fortran or Ada bugs as release blockers and I'm pretty sure it's used more than D. Adjusting accordingly.
[Bug rtl-optimization/93996] [10 Regression] ICE in lookup_page_table_entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93996 --- Comment #11 from CVS Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:e6ce69cae5059dfd715edd4e26653c23baf4cb0f commit r10-7069-ge6ce69cae5059dfd715edd4e26653c23baf4cb0f Author: Andrew Pinski Date: Fri Mar 6 08:34:01 2020 -0700 Avoid putting a REG_NOTE on anything other than an INSN in haifa-sched.c PR rtl-optimization/93996 * haifa-sched.c (remove_notes): Be more careful when adding REG_SAVE_NOTE.
[Bug rtl-optimization/93996] [10 Regression] ICE in lookup_page_table_entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93996 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Jeffrey A. Law --- Resolved on the trunk. Likely latent in older releases, but not currently planning to backport.
[Bug c/94075] New: When using linker-generated list, bad optimization performed in -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94075
Bug ID: 94075
Summary: When using linker-generated list, bad optimization
performed in -O2
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: fabrice.girardot at flowbird dot group
Target Milestone: ---
Created attachment 47992
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47992&action=edit
Test case + Makefile to reproduice bug
GCC does a wrong optimization in -O2 when using linker-generated lists, when
such a list is empty.
Linker-generated lists are convenient to automatically group items at link
time.
A 0-sized item array is located at start of list (section ".foo_1").
A 0-sized item array is located at end of list (section ".foo_3").
All other items with section ".foo_2" will automatically be located between the
top and bottom tags.
When there is *NO* item with section ".foo_2", the list is empty, the start and
end addresses are the same.
When compiling with "-O2", gcc assumes start and end addresses can't be equal,
and always enter the for() loop in the attached example.
If attached example is compiled with "-O0" (please edit Makefile), then
generated code is correct.
This bug was found on arm-none-eabi-gcc version 6.2.1 with a real linker script
for STM32 micro-controller, and the result is an embedded hard fault.
For convenient testing under Linux, the Makefile in the attached zip file
automatically generates a linker script to add a section for linker-generated
lists.
==
Correct output result (example compiled with -O0):
--
$ make clean && make
rm -rf output
gcc -dumpversion
5.4.0
gcc -c -std=c99 -O0 -DOPTIMIZE="\"-O0\"" -o output/main.o src/main.c
ld --verbose \
| sed -n '/===/,$p' \
| sed '/===/d' \
| sed -e '/.rodata[ ]*:/a .foobar : { KEEP(*(SORT(.foo_*))); } ' \
> output/test.ld
gcc -Wl,-Map=output/test.map -T output/test.ld -o output/test output/main.o
$ output/test
I am compiled with '-O0' !
start = 0x4006a0
end = 0x4006a0
==
Wrong optimization (example compiled with -O2)
--
$ make clean && make
rm -rf output
gcc -dumpversion
5.4.0
gcc -c -std=c99 -O2 -DOPTIMIZE="\"-O2\"" -o output/main.o src/main.c
ld --verbose \
| sed -n '/===/,$p' \
| sed '/===/d' \
| sed -e '/.rodata[ ]*:/a .foobar : { KEEP(*(SORT(.foo_*))); } ' \
> output/test.ld
gcc -Wl,-Map=output/test.map -T output/test.ld -o output/test output/main.o
$ output/test
I am compiled with '-O2' !
start = 0x400680
end = 0x400680
[0] p = 0x400680 ; *p = 0
[1] p = 0x400684 ; *p = 52
[2] p = 0x400688 ; *p = 5
[3] p = 0x40068c ; *p = -736
[4] p = 0x400690 ; *p = 128
[5] p = 0x400694 ; *p = -672
[6] p = 0x400698 ; *p = 168
[7] p = 0x40069c ; *p = -480
[8] p = 0x4006a0 ; *p = 80
[9] p = 0x4006a4 ; *p = -224
Aborting...
==
[Bug c++/94074] bogus modifying a const object error with const COMPONENT_REF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94074 Marek Polacek changed: What|Removed |Added Keywords||rejects-valid Priority|P3 |P1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-03-06 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |10.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- This breaks Chromium.
[Bug c++/94074] New: bogus modifying a const object error with const COMPONENT_REF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94074
Bug ID: 94074
Summary: bogus modifying a const object error with const
COMPONENT_REF
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
typedef decltype (sizeof (0)) size_t;
template
struct array
{
constexpr const E &operator[](size_t n) const noexcept { return elems[n]; }
E elems[N];
};
template
struct S {
using U = array;
U m;
constexpr S(int) : m{}
{
const_cast(const_cast(m)[0]) = 42;
}
};
constexpr S p = { 10 };
$ ./cc1plus -quiet q.C
q.C:20:27: in ‘constexpr’ expansion of ‘S(10)’
q.C:16:52: error: modifying a const object ‘(int&)(&(&(const
U&)(&((S*)this)->S::m))->array::operator[](0))’ is not
allowed in a constant expression
16 | const_cast(const_cast(m)[0]) = 42;
| ~~~^~~~
q.C:20:27: note: originally declared ‘const’ here
20 | constexpr S p = { 10 };
| ^
ISTM we shouldn't error here.
[Bug target/92379] rs6000.c:5598:13: runtime error: shift exponent 64 is too large for 64-bit type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92379 acsawdey at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||acsawdey at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |acsawdey at gcc dot gnu.org --- Comment #6 from acsawdey at gcc dot gnu.org --- I've reproduced this with current trunk, going to see if I can cook up a patch quick.
[Bug other/94073] New: ibm-ldouble-format: the given maximum value of the IBM long double format is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94073 Bug ID: 94073 Summary: ibm-ldouble-format: the given maximum value of the IBM long double format is incorrect Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: vincent-gcc at vinc17 dot net Target Milestone: --- The IBM long double format (double-double) is specified in libgcc/config/rs6000/ibm-ldouble-format, which says: | Each long double is made up of two IEEE doubles. The value of the | long double is the sum of the values of the two parts (except for | -0.0). The most significant part is required to be the value of the | long double rounded to the nearest double, as specified by IEEE. For | Inf values, the least significant part is required to be one of +0.0 | or -0.0. No other requirements are made; so, for example, 1.0 may be | represented as (1.0, +0.0) or (1.0, -0.0), and the low part of a NaN | is don't-care. Thus the maximum value that can be represented is x_h + x_l with x_h = 2^1024 - 2^971 (= DBL_MAX) x_l = 2^970 - 2^917 (the maximum value less than 1/2 ulp(x_h)) The binary representation of the significand is 111...1110111...111, with 53 bits 1 in both parts. If x_l >= 1/2 ulp(x_h) = 2^970, then the value of the long double x_h + x_l would round as a double to infinity, instead of x_h as required above. This contradicts Section "Limits", which says: The maximum representable long double is 2^1024-2^918. Indeed, this value is too large to satisfy the above constraints.
[Bug target/94072] New: [10 Regression] ICE: SIGSEGV due to infinite recursion in expand_expr/expand_expr_real_1 with -msve-vector-bits=512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94072 Bug ID: 94072 Summary: [10 Regression] ICE: SIGSEGV due to infinite recursion in expand_expr/expand_expr_real_1 with -msve-vector-bits=512 Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: aarch64-unknown-linux-gnu Created attachment 47991 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47991&action=edit reduced testcase Compiler output: $ aarch64-unknown-linux-gnu-gcc -msve-vector-bits=512 testcase.c aarch64-unknown-linux-gnu-gcc: internal compiler error: Segmentation fault signal terminated program cc1 Please submit a full bug report, with preprocessed source if appropriate. See <https://gcc.gnu.org/bugs/> for instructions. (gdb) bt #0 0x00d4420a in native_interpret_vector_part (type=0x77507498, bytes=0x7bfff420 "", len=8, npatterns=1, nelts_per_pattern=1) at /repo/gcc-trunk/gcc/tree.h:3402 #1 0x00d5e2b5 in fold_view_convert_vector_encoding (expr=0x772efc60, type=0x77507498) at /repo/gcc-trunk/gcc/vec.h:1432 #2 fold_view_convert_expr (expr=0x772efc60, type=0x77507498) at /repo/gcc-trunk/gcc/fold-const.c:8497 #3 const_unop (code=, type=0x77507498, arg0=0x772efc60) at /repo/gcc-trunk/gcc/fold-const.c:1757 #4 0x00d54391 in fold_unary_loc (loc=loc@entry=0, code=code@entry=VIEW_CONVERT_EXPR, type=0x77507498, op0=op0@entry=0x772efc60) at /repo/gcc-trunk/gcc/fold-const.c:8597 #5 0x00d0ed01 in expand_expr_real_1 (exp=0x772efc60, target=, tmode=E_XImode, modifier=EXPAND_NORMAL, alt_rtl=0x0, inner_reference_p=) at /repo/gcc-trunk/gcc/expr.c:10244 #6 0x00d0b2e6 in expand_expr (modifier=EXPAND_NORMAL, mode=E_XImode, target=0x7754ab70, exp=) at /repo/gcc-trunk/gcc/expr.h:282 #7 expand_expr_real_1 (exp=, target=, tmode=E_XImode, modifier=EXPAND_NORMAL, alt_rtl=0x0, inner_reference_p=) at /repo/gcc-trunk/gcc/expr.c:10440 #8 0x00d0b2e6 in expand_expr (modifier=EXPAND_NORMAL, mode=E_XImode, target=0x7754ab70, exp=) at /repo/gcc-trunk/gcc/expr.h:282 #9 expand_expr_real_1 (exp=, target=, tmode=E_XImode, modifier=EXPAND_NORMAL, alt_rtl=0x0, inner_reference_p=) at /repo/gcc-trunk/gcc/expr.c:10440 #10 0x00d0b2e6 in expand_expr (modifier=EXPAND_NORMAL, mode=E_XImode, target=0x7754ab70, exp=) at /repo/gcc-trunk/gcc/expr.h:282 #11 expand_expr_real_1 (exp=, target=, tmode=E_XImode, modifier=EXPAND_NORMAL, alt_rtl=0x0, inner_reference_p=) at /repo/gcc-trunk/gcc/expr.c:10440 ... $ aarch64-unknown-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r10-7065-20200306122437-g4cdcb2c92a1-checking-yes-rtl-df-extra-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/10.0.1/lto-wrapper Target: aarch64-unknown-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --with-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu --with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld --with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r10-7065-20200306122437-g4cdcb2c92a1-checking-yes-rtl-df-extra-aarch64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.0.1 20200306 (experimental) (GCC)
[Bug target/94059] [10 Regression] m68k: Bootstrap fails configuring libiberty with 'cannot compute sizeof (long long)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94059 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #2 from Jeffrey A. Law --- Also note I bootstrap m68k regularly, last build was: 8e6d0dba166324f4b257329bd4b4ddc2b4522359 Without more relevant data, there's nothing we can do here.
[Bug libstdc++/93978] A snippet using views::join fails to compile with -O1, but succeeds with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93978
--- Comment #2 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:6d082cd90131a9c0ce3142217e84194a5bf0de27
commit r10-7066-g6d082cd90131a9c0ce3142217e84194a5bf0de27
Author: Patrick Palka
Date: Thu Mar 5 10:04:06 2020 -0500
libstdc++: Give ranges::empty() a concrete return type (PR 93978)
This works around PR 93978 by avoiding having to instantiate the body of
ranges::empty() when checking the constraints of view_interface::operator
bool(). When ranges::empty() has an auto return type, then we must
instantiate
its body in order to determine whether the requires expression {
ranges::empty(_M_derived()); } is well-formed. But this means
instantiating
view_interface::empty() and hence view_interface::_M_derived(), all before
we've
yet deduced the return type of join_view::end(). (The reason
view_interface::operator bool() is needed in join_view::end() in the first
place
is because in this function we perform direct initialization of
join_view::_Sentinel from a join_view, and so we try to find a conversion
sequence from the latter to the former that goes through this conversion
operator.)
Giving ranges::empty() a concrete return type of bool should be safe
according
to [range.prim.empty]/4 which says "whenever ranges::empty(E) is a valid
expression, it has type bool."
This fixes the test case in PR 93978 when compiling without -Wall, but with
-Wall
the test case still fails due to the issue described in PR c++/94038, I
think.
I still don't quite understand why the test case doesn't fail without -O.
libstdc++-v3/ChangeLog:
PR libstdc++/93978
* include/bits/range_access.h (__cust_access::_Empty::operator()):
Declare return type to be bool instead of auto.
* testsuite/std/ranges/adaptors/93978.cc: New test.
[Bug c++/94038] Compiling with -Wall causes function template body to get needlessly instantiated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94038
--- Comment #3 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:6d082cd90131a9c0ce3142217e84194a5bf0de27
commit r10-7066-g6d082cd90131a9c0ce3142217e84194a5bf0de27
Author: Patrick Palka
Date: Thu Mar 5 10:04:06 2020 -0500
libstdc++: Give ranges::empty() a concrete return type (PR 93978)
This works around PR 93978 by avoiding having to instantiate the body of
ranges::empty() when checking the constraints of view_interface::operator
bool(). When ranges::empty() has an auto return type, then we must
instantiate
its body in order to determine whether the requires expression {
ranges::empty(_M_derived()); } is well-formed. But this means
instantiating
view_interface::empty() and hence view_interface::_M_derived(), all before
we've
yet deduced the return type of join_view::end(). (The reason
view_interface::operator bool() is needed in join_view::end() in the first
place
is because in this function we perform direct initialization of
join_view::_Sentinel from a join_view, and so we try to find a conversion
sequence from the latter to the former that goes through this conversion
operator.)
Giving ranges::empty() a concrete return type of bool should be safe
according
to [range.prim.empty]/4 which says "whenever ranges::empty(E) is a valid
expression, it has type bool."
This fixes the test case in PR 93978 when compiling without -Wall, but with
-Wall
the test case still fails due to the issue described in PR c++/94038, I
think.
I still don't quite understand why the test case doesn't fail without -O.
libstdc++-v3/ChangeLog:
PR libstdc++/93978
* include/bits/range_access.h (__cust_access::_Empty::operator()):
Declare return type to be bool instead of auto.
* testsuite/std/ranges/adaptors/93978.cc: New test.
[Bug c++/94068] [9/10 Regression] Internal compiler error when trying to resolve function overload since r9-2384
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94068 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Most likely a dup, should be fixed by my https://gcc.gnu.org/ml/gcc-patches/2020-02/msg01712.html overhaul. But more tests are always welcome.
[Bug c++/94057] [9/10 Regression] -std=gnu++20 causes failure naming nested templated class since r9-4536
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94057 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-03-06 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug tree-optimization/94071] Missed optimization with endian and alignment independent memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94071 Richard Biener changed: What|Removed |Added Keywords||easyhack, ||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2020-03-06 Version|unknown |10.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Hmm, bswap load is supposed to detect this. Not sure what it doesn't like here - eventually the (int) promotion before the shift (wider representation than what it likely initializes the lattice from (uint16). Shouldn't be hard to fix. [local count: 1073741824]: _1 = data[addr_10(D)]; _2 = (signed short) _1; _3 = addr_10(D) + 1; _4 = data[_3]; _5 = (int) _4; _6 = _5 << 8; _7 = (signed short) _6; _8 = _2 | _7; _11 = (uint16_t) _8; return _11;
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #28 from Martin Liška --- Created attachment 47990 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47990&action=edit Attempt to self-contained test-case There's a PRE that needs to be triggered for error_mark_node and I was unable to force it to do..
[Bug libstdc++/94069] [9 Regression] doesn't compile unless PTHREAD_RWLOCK_INITIALIZER is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94069 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jonathan Wakely --- Fixed for 9.3
[Bug libstdc++/94069] [9 Regression] doesn't compile unless PTHREAD_RWLOCK_INITIALIZER is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94069 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:39bdebf3725d7681e5e9ba06e3862f8facef3572 commit r9-8353-g39bdebf3725d7681e5e9ba06e3862f8facef3572 Author: Jonathan Wakely Date: Fri Mar 6 12:52:51 2020 + libstdc++: Fix call to __glibcxx_rwlock_init (PR 94069) When the target doesn't define PTHREAD_RWLOCK_INITIALIZER we use a wrapper around pthread_wrlock_init, but the wrapper only takes one argument and we try to call it with two. This went unnnoticed on most targets because they do define the PTHREAD_RWLOCK_INITIALIZER macro, but it causes a bootstrap failure on darwin8. Backport from mainline 2020-03-06 Jonathan Wakely PR libstdc++/94069 * include/std/shared_mutex [!PTHREAD_RWLOCK_INITIALIZER] (__shared_mutex_pthread::__shared_mutex_pthread()): Remove incorrect second argument to __glibcxx_rwlock_init. * testsuite/30_threads/shared_timed_mutex/94069.cc: New test.
[Bug c++/88086] gcc only allows valid expressions as unknown C++ attribute argument clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88086
Gábor Buella changed:
What|Removed |Added
CC||gbuella at gmail dot com
--- Comment #1 from Gábor Buella ---
This did come up for me as well, when trying to compile:
enum [[clang::enum_extensibility(closed)]] dummy { a, b };
$ g++-8 dummy.cc
y.cc:2:34: error: ‘closed’ was not declared in this scope
enum [[clang::enum_extensibility(closed)]] dummy { a, b };
^~
y.cc:2:34: note: suggested alternative: ‘class’
enum [[clang::enum_extensibility(closed)]] dummy { a, b };
^~
class
y.cc:2:44: warning: ‘clang::enum_extensibility’ scoped attribute directive
ignored [-Wattributes]
enum [[clang::enum_extensibility(closed)]] dummy { a, b };
^
It is rather annoying, the attribute is ignored, but there is a compile error.
[Bug tree-optimization/94071] New: Missed optimization with endian and alignment independent memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94071
Bug ID: 94071
Summary: Missed optimization with endian and alignment
independent memory access
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: moritz.struebe at redheads dot de
Target Milestone: ---
When copying consecutive bytes from memory into a local variable, this is done
byte wise, even on platforms that support unaligned access.
Code Example (Including more examples): https://godbolt.org/z/kFh6nc
Related: Bug 54733 (Same issue, but with a local variable)
Code
#include
uint8_t data[1024];
uint16_t getU16(int addr) {
return
(uint16_t) data[addr]
| (uint16_t) data[addr + 1] << 8;
}
Expected: (e.g. LLVM)
movsxd rax, edi
movzx eax, word ptr [rax + data]
ret
Actual: (g++ (Compiler-Explorer-Build) 10.0.1 20200305 (experimental))
lea eax, [rdi+1]
movsx rdi, edi
cdqe
movzx eax, BYTE PTR data[rax]
sal eax, 8
mov edx, eax
movzx eax, BYTE PTR data[rdi]
or eax, edx
ret
I found this on ARM, where this probably hurts more than on x86.
[Bug fortran/94070] Assumed-rank arrays – bounds mishandled, SIZE/SHAPE/UBOUND/LBOUND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94070 --- Comment #4 from Tobias Burnus --- José's PR (which came earlier then mine, hmm) has also an extensive test case in attachment 47960 for assumed-size arrays.
[Bug fortran/94070] Assumed-rank arrays – bounds mishandled, SIZE/SHAPE/UBOUND/LBOUND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94070 --- Comment #3 from Tobias Burnus --- *** Bug 94020 has been marked as a duplicate of this bug. ***
[Bug fortran/94020] Size, shape, possibly other intrinsics non standard conforming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94020 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||burnus at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Tobias Burnus --- I know your PR came first – but I have admittedly not found it when searching for "assumed rank". As the other PR (PR94070) shows there is a more general issue with bounds and not only with assumed-shape arguments. I think my PR has a more complete test case – but I will mention yours there as well. *** This bug has been marked as a duplicate of bug 94070 ***
[Bug rtl-optimization/94045] [i686] Compiler hang with -O2 -g -m32 -march=i686 -mtune=generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94045 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- Created attachment 47989 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47989&action=edit gcc10-pr94045.patch Patch I'll be testing.
[Bug fortran/94070] Assumed-rank arrays – bounds mishandled, SIZE/SHAPE/UBOUND/LBOUND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94070 --- Comment #2 from Tobias Burnus --- (In reply to Tobias Burnus from comment #0) > Testing shows that assumed-rank arrays are mishandled in several ways Additionally, with assumed-size arrays passed to assumed-rank dummies: both size(x) and size(x,dim=3) use "0" instead of "-1" for the last dimension (and hence: -20 in the first case). – That was the originally found issue by José.
[Bug fortran/94070] Assumed-rank arrays – bounds mishandled, SIZE/SHAPE/UBOUND/LBOUND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94070 --- Comment #1 from Tobias Burnus --- Created attachment 47988 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47988&action=edit … with assumed_rank_19.f90
[Bug fortran/94070] New: Assumed-rank arrays – bounds mishandled, SIZE/SHAPE/UBOUND/LBOUND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94070 Bug ID: 94070 Summary: Assumed-rank arrays – bounds mishandled, SIZE/SHAPE/UBOUND/LBOUND Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: jrfsousa at gmail dot com Target Milestone: --- Created attachment 47987 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47987&action=edit assumed_rank_19_aux.c – to be used with … As found by José and reported at https://gcc.gnu.org/ml/fortran/2020-03/msg00016.html Testing shows that assumed-rank arrays are mishandled in several ways * When required by the standard, the lower bound is not always shifted to "1" – this causes misreported bounds. * Likewise, for BIND(C), the bounds are not always the expected 0. * When allocatable/pointer, the argument cannot be assumed-rank; hence, "-1" is a perfectly valid upper and lower bound and size()/shape() shall report >= 0 and not a negative value! Likewise for dim[rank-1].extent with bind(C): the value shall not be negative. See attached test case. All code which works uses STOP and assert(). All code which doesn't uses (__builtin_)print(f) diagnostic. Caveat: I hope I haven't made any mistake when writing the test code. * * * Compile with: gfortran assumed_rank_19.f90 assumed_rank_19_aux.c When using DejaGNU/before committing: use the commented ISO_Fortran_binding.h #include as otherwise the testsuite may fail to find that file.
[Bug libstdc++/94069] [9 Regression] doesn't compile unless PTHREAD_RWLOCK_INITIALIZER is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94069 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.3
[Bug libstdc++/94069] [9 Regression] doesn't compile unless PTHREAD_RWLOCK_INITIALIZER is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94069 --- Comment #4 from Jonathan Wakely --- Fixed in commit r10-7064-gb0815713a32c5cc062bd41fa75dac4d4408215fb but I put the wrong PR number in the commit log.
[Bug libstdc++/94069] [9 Regression] doesn't compile unless PTHREAD_RWLOCK_INITIALIZER is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94069 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:4cdcb2c92a128d2a30a6110084b7ab2f9995c683 commit r10-7065-g4cdcb2c92a128d2a30a6110084b7ab2f9995c683 Author: Jonathan Wakely Date: Fri Mar 6 12:24:37 2020 + libstdc++: Fix PR number in ChangeLog (PR 94069)
[Bug libstdc++/93244] std::filesystem::path::generic_string doesn't convert the first slash on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93244 --- Comment #9 from Jonathan Wakely --- Doh, copy&paste error from the previous commit. That belongs to PR 94069.
[Bug libstdc++/93244] std::filesystem::path::generic_string doesn't convert the first slash on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93244 --- Comment #8 from Orgad Shaneh --- (In reply to CVS Commits from comment #7) > The master branch has been updated by Jonathan Wakely : > > https://gcc.gnu.org/g:b0815713a32c5cc062bd41fa75dac4d4408215fb > > commit r10-7064-gb0815713a32c5cc062bd41fa75dac4d4408215fb > Author: Jonathan Wakely > Date: Fri Mar 6 12:03:17 2020 + > > libstdc++: Fix call to __glibcxx_rwlock_init (PR 93244) > > When the target doesn't define PTHREAD_RWLOCK_INITIALIZER we use a > wrapper around pthread_wrlock_init, but the wrapper only takes one > argument and we try to call it with two. > > This went unnnoticed on most targets because they do define the > PTHREAD_RWLOCK_INITIALIZER macro, but it causes a bootstrap failure on > darwin8. > > PR libstdc++/93244 > * include/std/shared_mutex [!PTHREAD_RWLOCK_INITIALIZER] > (__shared_mutex_pthread::__shared_mutex_pthread()): Remove incorrect > second argument to __glibcxx_rwlock_init. > * testsuite/30_threads/shared_timed_mutex/94069.cc: New test. Wrong bug?
[Bug c++/94068] [9/10 Regression] Internal compiler error when trying to resolve function overload since r9-2384
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94068
--- Comment #2 from Jakub Jelinek ---
Reduced testcase with -std=c++17 or -std=c++2a:
enum class A { A1, A2 };
A foo ();
long foo (int);
template
void
bar ()
{
const auto c{foo ()};
}
[Bug libstdc++/94069] [9 Regression] doesn't compile unless PTHREAD_RWLOCK_INITIALIZER is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94069 Jonathan Wakely changed: What|Removed |Added Summary|[9/10 Regression] |[9 Regression] | doesn't | doesn't |compile unless |compile unless |PTHREAD_RWLOCK_INITIALIZER |PTHREAD_RWLOCK_INITIALIZER |is defined |is defined --- Comment #2 from Jonathan Wakely --- Fixed on master so far.
[Bug libstdc++/93244] std::filesystem::path::generic_string doesn't convert the first slash on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93244 --- Comment #7 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:b0815713a32c5cc062bd41fa75dac4d4408215fb commit r10-7064-gb0815713a32c5cc062bd41fa75dac4d4408215fb Author: Jonathan Wakely Date: Fri Mar 6 12:03:17 2020 + libstdc++: Fix call to __glibcxx_rwlock_init (PR 93244) When the target doesn't define PTHREAD_RWLOCK_INITIALIZER we use a wrapper around pthread_wrlock_init, but the wrapper only takes one argument and we try to call it with two. This went unnnoticed on most targets because they do define the PTHREAD_RWLOCK_INITIALIZER macro, but it causes a bootstrap failure on darwin8. PR libstdc++/93244 * include/std/shared_mutex [!PTHREAD_RWLOCK_INITIALIZER] (__shared_mutex_pthread::__shared_mutex_pthread()): Remove incorrect second argument to __glibcxx_rwlock_init. * testsuite/30_threads/shared_timed_mutex/94069.cc: New test.
[Bug c++/94068] [9/10 Regression] Internal compiler error when trying to resolve function overload since r9-2384
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94068 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2020-03-06 CC||jakub at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Target Milestone|--- |9.3 Summary|Internal compiler error |[9/10 Regression] Internal |when trying to resolve |compiler error when trying |function overload |to resolve function ||overload since r9-2384 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r9-2384-ged4f2c001a883b2456fc607a33f1c59f9c4ee65d
[Bug libstdc++/94069] [9/10 Regression] doesn't compile unless PTHREAD_RWLOCK_INITIALIZER is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94069 --- Comment #1 from Jonathan Wakely --- This causes a bootstrap failure on darwin8 for gcc-9 and master.
[Bug libstdc++/94069] [9/10 Regression] doesn't compile unless PTHREAD_RWLOCK_INITIALIZER is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94069 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-03-06 Known to work||8.4.0 Ever confirmed|0 |1 Known to fail||10.0, 9.2.1
[Bug libstdc++/94069] New: [9/10 Regression] doesn't compile unless PTHREAD_RWLOCK_INITIALIZER is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94069
Bug ID: 94069
Summary: [9/10 Regression] doesn't compile
unless PTHREAD_RWLOCK_INITIALIZER is defined
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: redi at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
If we simulate a target without PTHREAD_RWLOCK_INITIALIZER then
cannot be compiled:
#include
#undef PTHREAD_RWLOCK_INITIALIZER
#include
In file included from sm.cc:3:
/home/jwakely/gcc/10/include/c++/10.0.1/shared_mutex: In constructor
'std::__shared_mutex_pthread::__shared_mutex_pthread()':
/home/jwakely/gcc/10/include/c++/10.0.1/shared_mutex:163:57: error: too many
arguments to function 'int std::__glibcxx_rwlock_init(pthread_rwlock_t*)'
163 | int __ret = __glibcxx_rwlock_init(&_M_rwlock, NULL);
| ^
/home/jwakely/gcc/10/include/c++/10.0.1/shared_mutex:82:3: note: declared here
82 | __glibcxx_rwlock_init (pthread_rwlock_t *__rwlock)
| ^
The code path used when the initializer is not defined needs this fix:
--- a/libstdc++-v3/include/std/shared_mutex
+++ b/libstdc++-v3/include/std/shared_mutex
@@ -160,7 +160,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
public:
__shared_mutex_pthread()
{
- int __ret = __glibcxx_rwlock_init(&_M_rwlock, NULL);
+ int __ret = __glibcxx_rwlock_init(&_M_rwlock);
if (__ret == ENOMEM)
__throw_bad_alloc();
else if (__ret == EAGAIN)
[Bug libstdc++/93244] std::filesystem::path::generic_string doesn't convert the first slash on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93244 --- Comment #6 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:180eeeaeb200a07f7f24e1f203cd026880ff861c commit r10-7062-g180eeeaeb200a07f7f24e1f203cd026880ff861c Author: Jonathan Wakely Date: Fri Mar 6 11:27:34 2020 + libstdc++: Fix failing filesystem::path tests (PR 93244) The checks for PR 93244 don't actually pass on Windows (which is the target where the bug is present) because of a different bug, PR 94063. This adjusts the tests to not be affected by 94063 so that they verify that 93244 was fixed. PR libstdc++/93244 * testsuite/27_io/filesystem/path/generic/generic_string.cc: Adjust test to not fail due to PR 94063. * testsuite/27_io/filesystem/path/generic/utf.cc: Likewise. * testsuite/27_io/filesystem/path/generic/wchar_t.cc: Likewise.
[Bug libstdc++/94063] filesystem::path concatenation doesn't work for Windows root-paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94063 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:180eeeaeb200a07f7f24e1f203cd026880ff861c commit r10-7062-g180eeeaeb200a07f7f24e1f203cd026880ff861c Author: Jonathan Wakely Date: Fri Mar 6 11:27:34 2020 + libstdc++: Fix failing filesystem::path tests (PR 93244) The checks for PR 93244 don't actually pass on Windows (which is the target where the bug is present) because of a different bug, PR 94063. This adjusts the tests to not be affected by 94063 so that they verify that 93244 was fixed. PR libstdc++/93244 * testsuite/27_io/filesystem/path/generic/generic_string.cc: Adjust test to not fail due to PR 94063. * testsuite/27_io/filesystem/path/generic/utf.cc: Likewise. * testsuite/27_io/filesystem/path/generic/wchar_t.cc: Likewise.
[Bug c++/94068] New: Internal compiler error when trying to resolve function overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94068
Bug ID: 94068
Summary: Internal compiler error when trying to resolve
function overload
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: plexando at protonmail dot com
Target Milestone: ---
The following program crashes GCC 20200304 (experimental):
#include
enum class Enum { A };
Enum f(const char&) { return Enum::A; }
Enum f(const std::string& s) { return f(s[0]); }
template
void ExtractFile(const std::string& s) { const auto e { f(s) }; } // const auto
e = f(s) works;
int main() {}
Error message is:
prog.cc: In function 'void ExtractFile(const string&)':
prog.cc:9:62: internal compiler error: unexpected expression 'f' of kind
overload
9 | void ExtractFile(const std::string& s) { const auto e { f(s) }; } //
const auto e = f(s) works
| ^
0x632228 cxx_eval_constant_expression
../../source/gcc/cp/constexpr.c:6208
0x62c57d cxx_eval_call_expression
../../source/gcc/cp/constexpr.c:2055
0x62f61c cxx_eval_constant_expression
../../source/gcc/cp/constexpr.c:5397
0x632610 cxx_eval_outermost_constant_expr
../../source/gcc/cp/constexpr.c:6409
0x635915 maybe_constant_value(tree_node*, tree_node*, bool, bool)
../../source/gcc/cp/constexpr.c:6697
0x77e941 check_narrowing(tree_node*, tree_node*, int, bool)
../../source/gcc/cp/typeck2.c:984
0x662dd9 reshape_init(tree_node*, tree_node*, int)
../../source/gcc/cp/decl.c:6503
0x664f5a check_initializer
../../source/gcc/cp/decl.c:6702
0x678ff8 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../source/gcc/cp/decl.c:7618
0x6fad51 cp_parser_init_declarator
../../source/gcc/cp/parser.c:20839
0x6ddc72 cp_parser_simple_declaration
../../source/gcc/cp/parser.c:13689
0x6df82a cp_parser_declaration_statement
../../source/gcc/cp/parser.c:13121
0x6e03e5 cp_parser_statement
../../source/gcc/cp/parser.c:11434
0x6e11f8 cp_parser_statement_seq_opt
../../source/gcc/cp/parser.c:11800
0x6e12b0 cp_parser_compound_statement
../../source/gcc/cp/parser.c:11750
0x6f6db0 cp_parser_function_body
../../source/gcc/cp/parser.c:22992
0x6f6db0 cp_parser_ctor_initializer_opt_and_function_body
../../source/gcc/cp/parser.c:23043
0x6fa39d cp_parser_function_definition_after_declarator
../../source/gcc/cp/parser.c:28891
0x6fb2f7 cp_parser_function_definition_from_specifiers_and_declarator
../../source/gcc/cp/parser.c:28807
0x6fb2f7 cp_parser_init_declarator
../../source/gcc/cp/parser.c:20607
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/94067] [10 Regression] ICE on rotate with -Wconversion since r10-6527
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94067 --- Comment #2 from Jakub Jelinek --- Created attachment 47986 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47986&action=edit gcc10-pr94067.patch Untested fix.
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #27 from Martin Liška --- @Segher: Any of -fno-shrink-wrap-separate, -fno-shrink-wrap removes the problem.
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #26 from Martin Liška --- Created attachment 47985 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47985&action=edit RTL dump files for the function - good
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #25 from Martin Liška --- Created attachment 47984 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47984&action=edit RTL dump files for the function - bad
[Bug c++/94067] [10 Regression] ICE on rotate with -Wconversion since r10-6527
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94067 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-03-06 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |10.0 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- I guess in this case we should add the rotates to both potential_* and cxx_eval_*, one just have to worry what other trees created during cp_fold, including match.pd and fold-const.c folding, might appear and we don't handle.
[Bug c++/94067] New: [10 Regression] ICE on rotate with -Wconversion since r10-6527
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94067
Bug ID: 94067
Summary: [10 Regression] ICE on rotate with -Wconversion since
r10-6527
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Since r10-6527-gaaa26bf496a646778ac861aed124d960b5bf549f we ICE with
-Wconversion on
static inline unsigned short
swap (unsigned short x)
{
return (x >> 8) | static_cast(x << 8);
}
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #24 from Andrew Pinski --- (In reply to Martin Liška from comment #23) > (In reply to Andrew Pinski from comment #20) > > The return value of the first _Z11tsubst_exprP9tree_nodeS0_iS0_b.part.0 was > > being copied into r8 and then copied back into r3 (return value), but not r0 > > is used and that r0 is used for mtlr (moving back the return address). > > This is the correct explanation, thanks Adrew. > > In good version >│0x104c9128 <._Z19tsubst_template_argP9tree_nodeS0_iS0_+104> bl > 0x1049f300 <._Z11tsubst_exprP9tree_nodeS0_iS0_b.part.0> > > sets return value to $r3, which is then returned ($r8 = $r3, $r3 = $r8): > (gdb) p /x $r3 > $60 = 0x3fffaf3814d0 > > while in bad version we return value of: >│0x104c9134 <._Z19tsubst_template_argP9tree_nodeS0_iS0_+116> mtlr > r0 > (gdb) p /x $r3 > $31 = 0x104c92a4 > > which is the return address (can be seen in back-trace). Note I bet after LRA, there is a move between r0 and r3 after the call to _Z11tsubst_exprP9tree_nodeS0_iS0_b.part.0 but it gets removed as r0 is clobbered by the load. So we need to understand why LRA/IRA assigns the r_5/_34/_21 as r0 and then what also decides to use r0 for load/storing the LR.
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #23 from Martin Liška --- (In reply to Andrew Pinski from comment #20) > The return value of the first _Z11tsubst_exprP9tree_nodeS0_iS0_b.part.0 was > being copied into r8 and then copied back into r3 (return value), but not r0 > is used and that r0 is used for mtlr (moving back the return address). This is the correct explanation, thanks Adrew. In good version │0x104c9128 <._Z19tsubst_template_argP9tree_nodeS0_iS0_+104> bl 0x1049f300 <._Z11tsubst_exprP9tree_nodeS0_iS0_b.part.0> sets return value to $r3, which is then returned ($r8 = $r3, $r3 = $r8): (gdb) p /x $r3 $60 = 0x3fffaf3814d0 while in bad version we return value of: │0x104c9134 <._Z19tsubst_template_argP9tree_nodeS0_iS0_+116> mtlrr0 (gdb) p /x $r3 $31 = 0x104c92a4 which is the return address (can be seen in back-trace).
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #22 from Martin Liška --- > > good code stores: > 0x104c9124 <._Z19tsubst_template_argP9tree_nodeS0_iS0_+100> std > r0,144(r1) > (gdb) p /x $r0 > $38 = 0x104c9294 > > but the wrong one into a different memory address: > (gdb) p /x $r0 > $28 = 0x104c92a4 > No this is correct, it's return value and it corresponds to backtraces: #0 0x104c90c4 in ._Z19tsubst_template_argP9tree_nodeS0_iS0_ () #1 0x104c9294 in ._Z20tsubst_template_argsP9tree_nodeS0_iS0_ () #2 0x1049a3dc in ._ZL25get_partial_spec_bindingsP9tree_nodeS0_S0_ () vs. #0 0x104c90c4 in ._Z19tsubst_template_argP9tree_nodeS0_iS0_ () #1 0x104c92a4 in ._Z20tsubst_template_argsP9tree_nodeS0_iS0_ () #2 0x1049a3dc in ._ZL25get_partial_spec_bindingsP9tree_nodeS0_S0_ ()
[Bug middle-end/94035] Wrong optimization: conditional equivalence vs. values with several representations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94035
--- Comment #6 from rguenther at suse dot de ---
On Thu, 5 Mar 2020, ch3root at openwall dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94035
>
> --- Comment #5 from Alexander Cherepanov ---
> I see. But the problem with decimal floating-point formats remains...
>
> Based on bug 93806, comment 41, here is an example with equal but different
> values:
>
> --
> #include
>
> __attribute__((noipa)) // imagine it in a separate TU
> static _Decimal32 opaque(_Decimal32 d) { return d; }
>
> int main()
> {
> _Decimal32 x = opaque(1.0DF);
> unsigned char *p = (unsigned char *)&x;
>
> if (x == 1.00DF)
> printf("%d\n", p[0]);
> printf("%d\n", p[0]);
> }
> --
> $ gcc -std=c2x -pedantic -Wall -Wextra test.c && ./a.out
> 10
> 10
> $ gcc -std=c2x -pedantic -Wall -Wextra -O3 test.c && ./a.out
> 100
> 10
> --
> gcc x86-64 version: gcc (GCC) 10.0.1 20200305 (experimental)
> --
>
> And then there are non-canonical representations for DFP values...
From an implementation perspective it should be a FP format helper
that tells us whether the format has multiple representations
for values considered equal (eventually even for a specific
representation of one value), MODE_HAS_AMBIGUITY_FOR(MODE, VAL)
or so (where a NULL VAL should return whether there's any such value).
Then we can easily test that before doing equivalence substitution.
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #21 from Martin Liška --- (In reply to Andrew Pinski from comment #20) > The return value of the first _Z11tsubst_exprP9tree_nodeS0_iS0_b.part.0 was > being copied into r8 and then copied back into r3 (return value), but not r0 > is used and that r0 is used for mtlr (moving back the return address). Yes, I can confirm the $r0 is screwed. The value is equal in good/bad binary at the beginning of the function: (gdb) p /x $r0 $37 = 0x1049a3dc good code stores: 0x104c9124 <._Z19tsubst_template_argP9tree_nodeS0_iS0_+100> std r0,144(r1) (gdb) p /x $r0 $38 = 0x104c9294 but the wrong one into a different memory address: (gdb) p /x $r0 $28 = 0x104c92a4 So yes, $r0 is used first here in bad version here: │0x104c90f4 <._Z19tsubst_template_argP9tree_nodeS0_iS0_+52> ld r0,0(r9)
[Bug c++/94066] [8/9/10 Regression] ICE (starting/ending union member lifetime) in cxx_eval_bare_aggregate, at cp/constexpr.c:3790 since r6-7592
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94066 --- Comment #3 from Jakub Jelinek --- clang++ diagnostics is assignment to member 'y' of union with active member 'a' is not allowed in a constant expression Note, in C++17 things are clear and we shouldn't reject all changes of union active member, there is diagnostics for that e.g. since PR89336 (though unsure, do we need to mark the member as active as soon as we start evaluating its NSDMI?), but C++20 dropped the requirement that in constant expressions the active member can't be changed, so what exactly is the basis of this being invalid?
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #20 from Andrew Pinski --- The return value of the first _Z11tsubst_exprP9tree_nodeS0_iS0_b.part.0 was being copied into r8 and then copied back into r3 (return value), but not r0 is used and that r0 is used for mtlr (moving back the return address).
