[Bug libfortran/96886] [10 Regression] valgrind error with optional character argument of unknown length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96886 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||burnus at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org Last reconfirmed||2020-09-02 Summary|valgrind error with |[10 Regression] valgrind |optional character argument |error with optional |of unknown length |character argument of ||unknown length --- Comment #1 from Martin Liška --- Confirmed, started with r10-8137-g8aeffc4c9f47dd09ccc6a82d9fae35931414eb4d.
[Bug lto/94311] LTO produces line info entries with invalid line numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311 --- Comment #13 from Richard Biener --- Note we can still overflow locations so I wonder if we can have a more forgiving failure mode? Return UNKNOWN_LOCATION maybe.
[Bug lto/94311] LTO produces line info entries with invalid line numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311 --- Comment #12 from Richard Biener --- For PHIs we could use the cache but I see we're simply dropping the BLOCKs there (now that block location is encoded in the location we _do_ have a location BLOCK there as well). At least /* Do not cache a location - we do not have API to get pointer to the location in PHI statement and we may trigger reallocation. */ the comment is wrong in both regards. The API is gimple_phi_arg which yields a phi_arg_d * which has the location member. And re-allocation shouldn't happen because len = EDGE_COUNT (bb->preds); result = create_phi_node (phi_result, bb); so preds are set up and create_phi_node ensures there's enough capacity. So it boils down to the same issue that BLOCKs are not handled by the location cache. I don't remember exactly but in principle we do not need any BLOCKs on stmts in LTRANS (inline diagnostics uses it though). Amending the location cache with a BLOCK pointer should be possible but I wonder how to sort them? I guess same location usually means same BLOCK. Otherwise sort after BLOCK_NUMBER? That is, the idea would then be to apply the location cache only at the end of input_function.
[Bug sanitizer/96885] "member call on misaligned address" when calling a second base member through a pointer to member of derived class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96885 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-09-02 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed.
[Bug lto/94311] LTO produces line info entries with invalid line numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311 --- Comment #14 from Richard Biener --- so void lto_location_cache::input_location_and_block (location_t *loc, tree *block, struct bitpack_d *bp, class lto_input_block *ib, class data_in *data_in); and use that. Should be able to drop stream_input_location_now completely then. In apply location cache then handle the case of NULL and non-NULL block pointers, I think we can mix those freely.
[Bug c/96834] [9/10/11 Regression] Segmentation fault signal terminated program cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96834 Richard Biener changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=91403 --- Comment #6 from Richard Biener --- PR91403 was that other similar bug.
[Bug target/96892] New: wrong __stack_chk_guard for comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96892
Bug ID: 96892
Summary: wrong __stack_chk_guard for comparison
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dongjianqiang2 at huawei dot com
Target Milestone: ---
Simpile testcase:
#include
int main ()
{
int i;
char buf[20];
for (i = 0; i < 20; i++)
{
buf[i] = 'a';
printf("%c ,%d", buf[i], i);
}
return 0;
}
Compile with following command:
arm-linux-gnueabi-gcc -static -fno-PIE -no-pie main.c -fstack-protector-all -g3
gdb ./a.out
0x000105f8 <+124>: mov r3, #0
0x000105fc <+128>: movwr2, #11800 ; 0x2e18
0x00010600 <+132>: movtr2, #6
0x00010604 <+136>: ldr r1, [r2]
0x00010608 <+140>: ldr r2, [r11, #-8]
=> 0x0001060c <+144>: eorsr1, r2, r1
0x00010610 <+148>: beq 0x10618
0x00010614 <+152>: bl 0x3257c <__stack_chk_fail>
0x00010618 <+156>: mov r0, r3
0x0001061c <+160>: sub sp, r11, #4
0x00010620 <+164>: pop {r11, pc}
End of assembler dump.
(gdb) p __stack_chk_guard
$8 = 3363780352 // this is canary value
(gdb) p /x $r1
$9 = 0x8ab20 // Comparing the address of __stack_chk_guard ???
(gdb) p /x $r2
$10 = 0x8ab20
(gdb) p &__stack_chk_guard // address of __stack_chk_guard
$11 = (uintptr_t *) 0x8ab20 <__stack_chk_guard>
Confirmed as a 7.5 regression. The most likely change of those comparison is
pr85434.
[Bug tree-optimization/96881] [8/9/10/11 Regression] Clobbers on NULL vs. DCE since r8-1519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96881 Richard Biener changed: What|Removed |Added Last reconfirmed||2020-09-02 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Target Milestone|--- |8.5 Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Richard Biener --- Mine eventually.
[Bug fortran/96886] [10 Regression] valgrind error with optional character argument of unknown length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96886 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.3 Priority|P3 |P4 Component|libfortran |fortran
[Bug target/96893] New: aarch64:Segmentation fault signal terminated program cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96893
Bug ID: 96893
Summary: aarch64:Segmentation fault signal terminated program
cc1
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: z.zhanghaijian at huawei dot com
Target Milestone: ---
The case like:
test.c:
int f31() { }
void f30() { printf("30\n"); f31(); }
void f29() { printf("29\n"); f30(); }
void f28() { printf("28\n"); f29(); }
void f27() { printf("27\n"); f28(); }
...
void f10() { printf("10\n"); f11(); }
void f9() {printf("9\n"); f10(); }
void f8() {printf("8\n"); f9(); }
void f7() {printf("7\n"); f8(); }
void f6() {printf("6\n"); f7(); }
void f5() {printf("5\n"); f6(); }
void f4() {printf("4\n"); f5(); }
void f3() {printf("3\n"); f4(); }
void f2() {printf("2\n"); f3(); }
void f1() {printf("1\n"); f2(); }
int main(int argc, char** argv){ f1(); }
This produces the error on aarch64:
gcc test.c -S -w
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.
gcc version 11.0.0 20200902 (experimental) (GCC)
[Bug analyzer/96894] New: Analyzer assumes pointer is NULL, even if pointer was tested to be non-null before
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96894 Bug ID: 96894 Summary: Analyzer assumes pointer is NULL, even if pointer was tested to be non-null before Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- Created attachment 49174 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49174&action=edit fibheap.c, preprocessed version from gdb/binutils master Using gcc-11 (SUSE Linux) 11.0.0 20200901 (experimental) [revision b1850c617b14eedaf60b358f3b7d4707cff73b8a]. Invoked like this: ... $ gcc-11 fibheap.c -fanalyzer -S ... We have: ... fibheap.c: In function ‘fibnode_remove’: fibheap.c:3122:42: warning: dereference of NULL ‘*(node).parent’ [CWE-690] [-Wanalyzer-null-dereference] 3122 | && node->parent->child == node) | ^~~ ... Looking at the source code, we have: ... 3118if (node->parent != 3119 3120 ((void *)0) 3121 3122&& node->parent->child == node) 3123 node->parent->child = ret; ... So, just before dereferencing node->parent, we check that it's non-null, so the warning that node->parent is dereferenced while it's null makes no sense.
[Bug c/96834] [9/10/11 Regression] Segmentation fault signal terminated program cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96834
--- Comment #7 from z.zhanghaijian at huawei dot com ---
(In reply to Richard Biener from comment #5)
> (In reply to z.zhanghaij...@huawei.com from comment #4)
> > The case like:
> > test.c:
> > int f31() { }
> > void f30() { printf("30\n"); f31(); }
> > void f29() { printf("29\n"); f30(); }
> > void f28() { printf("28\n"); f29(); }
> > void f27() { printf("27\n"); f28(); }
> > ...
> > void f10() { printf("10\n"); f11(); }
> > void f9() {printf("9\n"); f10(); }
> > void f8() {printf("8\n"); f9(); }
> > void f7() {printf("7\n"); f8(); }
> > void f6() {printf("6\n"); f7(); }
> > void f5() {printf("5\n"); f6(); }
> > void f4() {printf("4\n"); f5(); }
> > void f3() {printf("3\n"); f4(); }
> > void f2() {printf("2\n"); f3(); }
> > void f1() {printf("1\n"); f2(); }
> > int main(int argc, char** argv){ f1(); }
> >
> > This can also produces the error on aarch64:
> >
> > gcc test.c -S
> > gcc: internal compiler error: Segmentation fault signal terminated program
> > cc1
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See
[Bug fortran/96886] [10 Regression] valgrind error with optional character argument of unknown length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96886 Martin Liška changed: What|Removed |Added Known to fail||10.2.0 Known to work||10.1.0, 11.0 Summary|[10/11 Regression] valgrind |[10 Regression] valgrind |error with optional |error with optional |character argument of |character argument of |unknown length |unknown length --- Comment #2 from Martin Liška --- Apparently, the current master is fine.
[Bug fortran/96886] [10 Regression] valgrind error with optional character argument of unknown length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96886 --- Comment #3 from Tobias Burnus --- (In reply to Andy May from comment #0) > Looks like a regression between 10.1.0 and 10.2.0. test.f90: I think that's the same issue as reported in PR 94672 comment 12 last week – which has been fixed very recently: last Friday in r11-2923 and Monday, three days ago, in r10-8691. Thus, I believe it is fine now. – Thanks for the report and sorry for the breakage. (In reply to Martin Liška from comment #2) > Apparently, the current master is fine. Unsurprisingly, given that I has been fixed just a few days ago. You need to update your bisecter :-) And thanks for doing all this bisecting and bug triages!
[Bug target/96882] Wrong assembly code generated with arm-none-eabi-gcc -flto -mfloat-abi=hard options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96882
--- Comment #5 from emilie.feral at numworks dot com ---
When compiling without the lto using the command:
arm-none-eabi-gcc main.c -Os -mfloat-abi=hard -mthumb -mcpu=cortex-m4
-ffreestanding -nostdlib -lgcc -save-temps -o a.elf
I get the following instructions for CalledFunction:
Dump of assembler code for function CalledFunction:
0x8000 <+0>: push{r4, r5, lr}
0x8002 <+2>: ldr r5, [pc, #52] ; (0x8038 )
0x8004 <+4>: ldmia r5!, {r0, r1, r2, r3}
0x8006 <+6>: sub sp, #100; 0x64
0x8008 <+8>: add r4, sp, #32
0x800a <+10>:stmia r4!, {r0, r1, r2, r3}
0x800c <+12>:ldmia.w r5, {r0, r1, r2, r3}
0x8010 <+16>:add r5, sp, #32
0x8012 <+18>:stmia.w r4, {r0, r1, r2, r3}
0x8016 <+22>:ldmia r5!, {r0, r1, r2, r3}
0x8018 <+24>:add r4, sp, #64 ; 0x40
0x801a <+26>:stmia r4!, {r0, r1, r2, r3}
0x801c <+28>:ldmia.w r5, {r0, r1, r2, r3}
0x8020 <+32>:stmia.w r4, {r0, r1, r2, r3}
0x8024 <+36>:vldrd0, [sp, #64] ; 0x40
0x8028 <+40>:vldrd1, [sp, #72] ; 0x48
0x802c <+44>:vldrd2, [sp, #80] ; 0x50
0x8030 <+48>:vldrd3, [sp, #88] ; 0x58
0x8034 <+52>:add sp, #100; 0x64
0x8036 <+54>:pop {r4, r5, pc}
0x8038 <+56>:strhr0, [r3, #2]
0x803a <+58>:movsr0, r0
End of assembler dump.
Which seems correct to me: the result is returned through registers d0-d3.
Interesting fact, if I keep the lto but remove the mfloat-abi=hard option:
arm-none-eabi-gcc main.c -Os -flto -mthumb -mcpu=cortex-m4 -ffreestanding
-nostdlib -lgcc -save-temps -o a.elf
The compilation also seems correct: the result is written at the address given
by r0 and the address is returned through r0.
Dump of assembler code for function CalledFunction:
0x8000 <+0>: push{r4, r5, r6, lr}
0x8002 <+2>: ldr r5, [pc, #20] ; (0x8018 )
0x8004 <+4>: mov r6, r0
0x8006 <+6>: mov r4, r0
0x8008 <+8>: ldmia r5!, {r0, r1, r2, r3}
0x800a <+10>:stmia r4!, {r0, r1, r2, r3}
0x800c <+12>:ldmia.w r5, {r0, r1, r2, r3}
0x8010 <+16>:stmia.w r4, {r0, r1, r2, r3}
0x8014 <+20>:mov r0, r6
0x8016 <+22>:pop {r4, r5, r6, pc}
0x8018 <+24>:strhr0, [r5, #0]
0x801a <+26>:movsr0, r0
End of assembler dump.
[Bug tree-optimization/96888] Missing vectorization opportunity depending on integer type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96888 Richard Biener changed: What|Removed |Added Blocks||53947 Status|UNCONFIRMED |NEW Last reconfirmed||2020-09-02 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Confirmed. We currently do not support promoting/demoting the shift amount vector operand when vectorizing shifts. Note the fact that we turn word & (1ul<> j likely triggers this issue - this does not happen when you write word & (1u
[Bug target/96893] aarch64:Segmentation fault signal terminated program cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96893 Richard Biener changed: What|Removed |Added Last reconfirmed||2020-09-02 Target||aarch64 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #1 from Richard Biener --- Please provide a script to generate the testcase. A backtrace would be nice as well, likely the stack blows up.
[Bug target/96895] New: ABI of returning V1DF differs between GCC and clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96895
Bug ID: 96895
Summary: ABI of returning V1DF differs between GCC and clang
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
clang and GCC differ in returning v1df:
typedef double v1df __attribute__((vector_size(8)));
v1df foo (v1df x)
{
return x;
}
clang returns in %xmm0 while GCC returns by invisible reference (thus in
memory).
v1df arguments are passed on the stack with both compilers.
GCC behaves this way because the v1df type has BLKmode. If we assign
the type DFmode (V1DFmode is unavailable) then GCC passes and returns in %xmm0.
The target should likely not work on modes here but on types.
[Bug target/96895] ABI of returning V1DF differs between GCC and clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96895
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
Keywords||ABI
CC||hjl at gcc dot gnu.org,
||matz at gcc dot gnu.org
--- Comment #1 from Richard Biener ---
I guess the psABI does not say anything about "non-standard" vector types.
Note v1sf seems to be returned in %xmm0 with GCC but %eax with clang which
passes v1sf in general regs as well while GCC passes in %xmm0.
typedef float v1df __attribute__((vector_size(4)));
v1df foo (v1df x)
{
return x;
}
[Bug analyzer/96608] Build failure due to cast to type long on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608
Pekka S changed:
What|Removed |Added
CC||p...@gcc-bugzilla.mail.kaps
||i.fi
--- Comment #9 from Pekka S ---
Any updates on this? --disable-analyzer does not unfortunately resolve this
problem as analyzer objects are always built and ENABLE_ANALYZER does not gate
any header files that would be required by the code.
The quick and dirty way of resolving this problem would be:
hashval_t hash () const
{
-return (binding_key::impl_hash () ^ (long)m_region);
+return (binding_key::impl_hash () ^ (long)(uintptr_t)m_region);
}
But perhaps that would simply suppress a valid error if the implementation
expects that no precision is lost.
[Bug c++/96877] Erroneous warning when default initializing function pointer types defined using std::declval
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96877 --- Comment #5 from Jonathan Wakely --- (In reply to Ian Henriksen from comment #3) > The goal of doing it that way was get the exception specification onto the > pointer type in C++11 and C++14. The intent was to get the equivalent of > > typedef void(*function_type)(void*) noexcept; > > but with standards earlier than C++17. But you can't do that. There is no difference between void(*)(void*) noexcept and void(*)(void*) in C++14, they're the same type. It doesn't matter whether you write the type out, or do remove_reference_t())>, the type is the same. Concretely, it doesn't work: #include using function_type = decltype(std::declval()); static_assert( noexcept(std::declval()(nullptr)), "" ); The assertion fails before C++17, because the type does not have noexcept in it. (In reply to Ian Henriksen from comment #4) > It's worth noting that, with g++ > > using function_type = void (*)(void*) noexcept; > > actually works, You can write that declaration, but the noexcept still isn't part of the type: #include using function_type = void (*)(void*) noexcept; static_assert( noexcept(std::declval()(nullptr)), "" ); If you need C++17 then use C++17.
[Bug libstdc++/96851] operator< on std::array does not work in constexpr, for sizeof(T) == 1, and N > 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96851 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-09-02 Ever confirmed|0 |1 Target Milestone|--- |10.3 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug lto/94311] LTO produces line info entries with invalid line numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- Comment #15 from Jakub Jelinek ---
Short reproducer:
$ cat pr94311.c
#line 210
static inline __attribute__((always_inline)) void
foo (void)
{
int a = 23;
}
#line 65570
volatile int v;
#define A { int b = 42; foo (); }
#define B A A A A A A A A A A
#define C B B B B B B B B B B
#define D C C C C C C C C C C
__attribute__((used, noipa)) void
baz (void)
{
D D D
v++;
D
v++;
}
int
main ()
{
baz ();
}
$ ./xgcc -B ./ -flto -O2 -g pr94311.c -o pr94311 -save-temps; readelf -wl
pr94311 | grep 'Advance Line by [0-9][0-9][0-9][0-9][0-9][0-9]'
[0xa56c] Advance Line by 254236696 to 254302276
[Bug tree-optimization/94301] Missed vector-vector CTOR / permute simplification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94301
--- Comment #2 from Richard Biener ---
OK, so the ICE is the vectorizers fault in generating BLKmode vectors.
What remains is the missed optimization on __VEC_PERM:
typedef double v2df __attribute__((vector_size(16)));
typedef double v4df __attribute__((vector_size(32)));
typedef long long v4di __attribute__((vector_size(32)));
v4df __GIMPLE(ssa) foo (v2df x, v2df z)
{
v4df y;
__BB(2):
y_2 = _Literal (v4df) { x_1(D), _Literal (v2df) { 0.0, 0.0 } };
y_3 = _Literal (v4df) { z_4(D), _Literal (v2df) { 0.0, 0.0 } };
y_5 = __VEC_PERM (y_2, y_3, _Literal (v4di) { 0l, 1l, 4l, 5l });
return y_5;
}
remains
y_2 = {x_1(D), { 0.0, 0.0 }};
y_3 = {z_4(D), { 0.0, 0.0 }};
y_5 = VEC_PERM_EXPR ;
but should become just
y_5 = {x_1(D), z_4(D)};
forwprop in simplify_permutation resorts to fold_ternary of
VEC_PERM_EXPR <{x_1(D), { 0.0, 0.0 }}, {z_4(D), { 0.0, 0.0 }}, { 0, 1, 4, 5 }>
which eventually ends up in fold_vec_perm which fails because
vec_cst_ctor_to_array cannot handle the vector typed component x_1(D).
[Bug target/96759] ICE in extract_insn, at recog.c:2294
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96759 --- Comment #2 from Kito Cheng --- It work on GCC 9, GCC will split that into two plain move instead of move from a (subreg (parallel [(reg) (reg)])). (insn 23 22 24 (set (reg:SI 83) (reg:SI 10 a0)) "g++.target/riscv/pr96759.C":8:38 -1 (nil)) (insn 24 23 25 (set (reg:DF 84) (reg:DF 42 fa0)) "g++.target/riscv/pr96759.C":8:38 -1 (nil)) But it will ICE after GCC 10, try to bisect to figure out the reason.
[Bug libstdc++/96851] operator< on std::array does not work in constexpr, for sizeof(T) == 1, and N > 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96851 --- Comment #2 from Jonathan Wakely --- The instructions at https://gcc.gnu.org/bugs are clear about providing the commands used to compile, please remember to state that you used -std=c++20 (a godbolt URL is not sufficient). The branch using memcmp shouldn't be used during constant evaluation, but it also shouldn't be used for signed chars, so I'll fix that too.
[Bug target/96893] aarch64:Segmentation fault signal terminated program cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96893
--- Comment #2 from z.zhanghaijian at huawei dot com ---
(In reply to Richard Biener from comment #1)
> Please provide a script to generate the testcase. A backtrace would be nice
> as well, likely the stack blows up.
cat gen.sh
#!/bin/bash
echo 'int f301() { }' > test.c
for i in {30..1}
do
j=$(($i+1))
echo "void f$i() {printf(\"$i\\n\"); f$j(); }" >> test.c
done
echo "int main(int argc, char** argv){ f1(); }" >> test.c
The script can generate the testcase.
[Bug lto/94311] LTO produces line info entries with invalid line numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311 --- Comment #16 from Jakub Jelinek --- One possible way at the libcpp side is to make sure we don't deplete the location_t stuff too much once we are above highest > LINE_MAP_MAX_LOCATION_WITH_COLS. I mean, the comment above this if block says: /* Allocate the new line_map. However, if the current map only has a single line we can sometimes just increase its column_bits instead. */ and with these > 0x6000 locations, column_bits and range_bits is 0 anyway and in that case we are not going to increase its column_bits. Now, I've bootstrapped a slightly different version overnight, which instead had || column_bits == 0, and that regressed the g++.dg/diagnostic/pr77949.C testcase which has a 4KB+ line and thus disables columns and expects no fixit hint. Or perhaps use || (highest > ... && (to_line - ORDINARY_MAP_STARTING_LINE_NUMBER (map)) > 100) or something similar, allow some growth, but not unlimited? David, your thoughts on this? 2020-09-02 Jakub Jelinek PR lto/94311 * line-map.c (linemap_line_start): For single-line map don't try to extend it if highest > LINE_MAP_MAX_LOCATION_WITH_COLS. --- libcpp/line-map.c.jj2020-07-28 15:39:10.127754591 +0200 +++ libcpp/line-map.c 2020-09-02 11:08:50.421816848 +0200 @@ -742,7 +742,8 @@ linemap_line_start (line_maps *set, line (to_line - ORDINARY_MAP_STARTING_LINE_NUMBER (map)) >= (((uint64_t) 1) << (CHAR_BIT * sizeof (linenum_type) - column_bits))) - || range_bits < map->m_range_bits) + || range_bits < map->m_range_bits + || highest > LINE_MAP_MAX_LOCATION_WITH_COLS) map = linemap_check_ordinary (const_cast (linemap_add (set, LC_RENAME,
[Bug target/96607] GCC feeds SPARC/Solaris linker with unrecognized TLS sequences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96607 Eric Botcazou changed: What|Removed |Added CC|ebotcazou at gcc dot gnu.org | Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #4 from Eric Botcazou --- Fixing.
[Bug target/96607] GCC feeds SPARC/Solaris linker with unrecognized TLS sequences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96607 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-09-02 --- Comment #3 from Eric Botcazou --- It looks like the logic has been flawed since day #1 and we should be testing the insn which *has* the delay slot instead of the insn which is in the delay slot.
[Bug target/96882] Wrong assembly code generated with arm-none-eabi-gcc -flto -mfloat-abi=hard options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96882 --- Comment #6 from Richard Earnshaw --- Yes, the problem is related to returning values in memory and the ABI variants we have. If we have hardware floating-point we generally use registers to return values; if we don't, then we have to return in memory. However, when we have a function that is not inlinable, but is private to the compilation unit we can optimize the ABI in some circumstances. That's what is happening here. Unfortunately, it appears that function that decides whether or not the result should be returned in memory or in registers lacks important information as to whether or not the function is private and this in turn leads to two parts of the compiler making different choices - with the disastrous consequences you've discovered. I'm not sure if this is restricted to M-profile parts or if it's more wide-spread - I'm still investigating.
[Bug fortran/96896] New: Bogus 'Different ranks in pointer assignment' with 'array-variable = scalar' if LHS is a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96896 Bug ID: 96896 Summary: Bogus 'Different ranks in pointer assignment' with 'array-variable = scalar' if LHS is a function Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- The following program fails with: Error: Different ranks in pointer assignment Function calls returning a pointer are regarded as variable, hence, the following boils down to array_variable = scalar which should be fine. program reshape_test implicit none real, target, dimension (1:9) :: b b = 0.0 ! needed otherwise triggers a FIXME myshape(b) = 0.0 ! LHS: 3x3 array, RHS: scalar contains function myshape(b) real, target, dimension (1:9) :: b real, pointer :: myshape(:,:) myshape(1:3,1:3) => b end function myshape end program reshape_test
[Bug fortran/96859] Wrong answer with intrinsic merge_bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96859 --- Comment #11 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:b567d3bd302933adb253aba9069fd8120c485441 commit r11-2978-gb567d3bd302933adb253aba9069fd8120c485441 Author: Jakub Jelinek Date: Wed Sep 2 12:18:46 2020 +0200 fortran: Fix o'...' boz to integer/real conversions [PR96859] The standard says that excess digits from boz are truncated. For hexadecimal or binary, the routines copy just the number of digits that will be needed, but for octal we copy number of digits that contain one extra bit (for 8-bit, 32-bit or 128-bit, i.e. kind 1, 4 and 16) or two extra bits (for 16-bit or 64-bit, i.e. kind 2 and 8). The clearing of the first bit is done correctly by changing the first digit if it is 4-7 to one smaller by 4 (i.e. modulo 4). The clearing of the first two bits is done by changing 4 or 6 to 0 and 5 or 7 to 1, which is incorrect, because we really want to change the first digit to 0 if it was even, or to 1 if it was odd, so digits 2 and 3 are mishandled by keeping them as is, rather than changing 2 to 0 and 3 to 1. 2020-09-02 Jakub Jelinek PR fortran/96859 * check.c (gfc_boz2real, gfc_boz2int): When clearing first two bits, change also '2' to '0' and '3' to '1' rather than just handling '4' through '7'. * gfortran.dg/pr96859.f90: New test.
[Bug c++/93689] ICE with default argument in lambda used as non type template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93689
bastien penavayre changed:
What|Removed |Added
CC||bastien.penavayre at epitech
dot e
||u
--- Comment #6 from bastien penavayre ---
It seems that it's the cast '(int)0' that causes the issue.
If we remove the cast it works fine:
```
template <
auto Z = [](int l = 0) -> int { return l; }
>
int f() {
return Z();
}
int main() {
return f();
}
```
https://godbolt.org/z/zq3E7M
[Bug fortran/96896] Bogus 'Different ranks in pointer assignment' with 'array-variable = scalar' if LHS is a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96896 --- Comment #1 from Tobias Burnus --- The error occurs for the LHS of: myshape(b) = 0.0 reshape_test:_F.DA0 => myshape[[((reshape_test:b(FULL)))]] (gfc_debug_expr output) (gdb) p lvalue->rank $9 = 0 (gdb) p rvalue->rank $10 = 2 Maybe something like --- a/gcc/fortran/resolve.c +++ b/gcc/fortran/resolve.c @@ -11598 +11598 @@ resolve_ptr_fcn_assign (gfc_code **code, gfc_namespace *ns) - tmp_ptr_expr = get_temp_from_expr ((*code)->expr2, ns); + tmp_ptr_expr = get_temp_from_expr ((*code)->expr1, ns); Or if expr2->rank == 0 and expr1->rank > 0, it has to be updated afterwards. At the moment, I do not see whether 'expr1' or 'expr2' makes more sense in terms of polymorphic variables etc. However, at a glance, expr1 seems to be more sensible...
[Bug c++/93689] ICE with default argument in lambda used as non type template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93689 --- Comment #7 from bastien penavayre --- somewhat related 93595 ( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93595 ) is still in UNCONFIRMED state.
[Bug tree-optimization/96897] New: Failure to optimize not+not+dec+and+not to add+or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96897
Bug ID: 96897
Summary: Failure to optimize not+not+dec+and+not to add+or
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int f(int x)
{
return ~(~x & (~x - 1));
}
This can be optimized to `return (x + 1) | x;`. This transformation is done by
LLVM, but not by GCC.
[Bug tree-optimization/96897] Failure to optimize not+not+dec+and+not to add+or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96897 --- Comment #1 from Marc Glisse --- We already transform to return ~(-2 - x) | x; so this is really asking for ~(-2 - x) --> x + 1
[Bug target/96898] New: [nvptx] libatomic support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96898 Bug ID: 96898 Summary: [nvptx] libatomic support Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- When building gcc for nvptx, we get: ... checking for libatomic support... no ... As mentioned here ( https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553142.html ), could be useful.
[Bug target/96893] aarch64:Segmentation fault signal terminated program cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96893 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- Confirmed, it's a stack overflow and it happens only on x86_64. I'm trying to reduce that.
[Bug target/96893] aarch64:Segmentation fault signal terminated program cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96893 Martin Liška changed: What|Removed |Added Status|WAITING |NEW --- Comment #4 from Martin Liška --- It's hard to reduce, but one can see a stack overflow in GGC collect.
[Bug target/96895] ABI of returning V1DF differs between GCC and clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96895 --- Comment #2 from Michael Matz --- The psABI doesn't say anything about such types, no. Maybe it could in some additional info pages, but it's always a problem to codify behaviour retroactively in it, when conflicting implementations already exist. It is about extension types, though, so we might be fine. FWIW, even ignoring the obvious relation of v1Xf to Xf, GCC behaviour for float and clang behaviour for double is the most logical one: this extended type is most similar to a struct containing one float/double, and such are passed in XMM registers per psABI. As this is also consistent with how a single top-level float is passed, this choice is the most consistent one. This is also what the psABI _would_ say, if we had written it into it, so at least both compilers would need a change to implement it.
[Bug target/96895] ABI of returning V1DF differs between GCC and clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96895 H.J. Lu changed: What|Removed |Added URL||https://gitlab.com/x86-psAB ||Is/x86-64-ABI/-/issues/1 --- Comment #3 from H.J. Lu --- I opened: https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/1
[Bug target/96895] ABI of returning V1DF differs between GCC and clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96895 --- Comment #4 from H.J. Lu --- (In reply to Michael Matz from comment #2) > The psABI doesn't say anything about such types, no. Maybe it could in some > additional info pages, but it's always a problem to codify behaviour > retroactively > in it, when conflicting implementations already exist. It is about > extension types, though, so we might be fine. > > FWIW, even ignoring the obvious relation of v1Xf to Xf, GCC behaviour for > float and clang behaviour for double is the most logical one: this extended > type is most > similar to a struct containing one float/double, and such are passed in XMM > registers per psABI. As this is also consistent with how a single > top-level float is passed, this choice is the most consistent one. This is > also > what the psABI _would_ say, if we had written it into it, so at least both > compilers would need a change to implement it. It makes senses to me. It isn't the first time that GCC changes the ABI. This is why there is -Wabi is.
[Bug target/96899] New: [10.2 Regression] [SH] Bootstrap fails when building libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96899 Bug ID: 96899 Summary: [10.2 Regression] [SH] Bootstrap fails when building libgomp Product: gcc Version: 10.2.0 URL: https://buildd.debian.org/status/fetch.php?pkg=gcc-10&; arch=sh4&ver=10.2.0-6&stamp=1598935952&raw=0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: glaubitz at physik dot fu-berlin.de CC: jrtc27 at jrtc27 dot com, kkojima at rr dot iij4u.or.jp, oleg.e...@t-online.de Target Milestone: --- Target: sh*-*-* With gcc-10.2, the bootstrap has started to fail on Debian/sh4, please see: > https://buildd.debian.org/status/fetch.php?pkg=gcc-10&arch=sh4&ver=10.2.0-6&stamp=1598935952&raw=0 It's failing when building libgomp, not sure exactly what the problem is. I have not yet bisected which commit broke the build. Might do that later. I cannot copy and paste the partial build log because that triggers the spam filter and locks my bugzilla account :(.
[Bug lto/94311] LTO produces line info entries with invalid line numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311 --- Comment #17 from Jakub Jelinek --- Created attachment 49175 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49175&action=edit gcc11-pr94311.patch Untested patch which implements location and block caching and the above test passes with it (even with the libcpp patch reverted).
[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #8 from acsawdey at gcc dot gnu.org ---
Another small test case, reduced from my compile failure of c/c-typeck.c and
modified to provoke truncation from POImode to various other modes:
typedef int *a;
struct b { a ba; };
enum c { c1=1 };
struct e {
union eu {
char f_char;
short f_short;
int f_int;
long f_long;
int *f_ptr;
long long f_ll;
} u;
c g;
a h;
b i;
};
a d(bool, bool, bool);
e j(int, e, bool, bool);
void k() {
int l;
for (;;) {
e expr;
l = sizeof(struct e);
expr = j(l, expr, true, false);
d(expr.u.f_char, false, __null);
d(expr.u.f_short, false, __null);
d(expr.u.f_int, false, __null);
d(expr.u.f_long, false, __null);
d(expr.u.f_ptr, false, __null);
d(expr.u.f_ll, false, __null);
}
}
[Bug target/96895] ABI of returning V1DF differs between GCC and clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96895
--- Comment #5 from Richard Biener ---
(In reply to Michael Matz from comment #2)
> The psABI doesn't say anything about such types, no. Maybe it could in some
> additional info pages, but it's always a problem to codify behaviour
> retroactively
> in it, when conflicting implementations already exist. It is about
> extension types, though, so we might be fine.
>
> FWIW, even ignoring the obvious relation of v1Xf to Xf, GCC behaviour for
> float and clang behaviour for double is the most logical one: this extended
> type is most
> similar to a struct containing one float/double, and such are passed in XMM
> registers per psABI. As this is also consistent with how a single
> top-level float is passed, this choice is the most consistent one. This is
> also
> what the psABI _would_ say, if we had written it into it, so at least both
> compilers would need a change to implement it.
So vector types with element type T and N, a power-of-two, not otherwise
specified are passes the same as
struct S { T a[N] };
? I guess there's mismatch then for AVX types with -mno-avx then at least
(AVX512 are probably too big to be passed in registers).
[Bug target/96899] [10.2 Regression] [SH] Bootstrap fails when building libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96899 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.3
[Bug target/96895] ABI of returning V1DF differs between GCC and clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96895
--- Comment #6 from Richard Biener ---
(In reply to Richard Biener from comment #5)
> (In reply to Michael Matz from comment #2)
> > The psABI doesn't say anything about such types, no. Maybe it could in some
> > additional info pages, but it's always a problem to codify behaviour
> > retroactively
> > in it, when conflicting implementations already exist. It is about
> > extension types, though, so we might be fine.
> >
> > FWIW, even ignoring the obvious relation of v1Xf to Xf, GCC behaviour for
> > float and clang behaviour for double is the most logical one: this extended
> > type is most
> > similar to a struct containing one float/double, and such are passed in XMM
> > registers per psABI. As this is also consistent with how a single
> > top-level float is passed, this choice is the most consistent one. This is
> > also
> > what the psABI _would_ say, if we had written it into it, so at least both
> > compilers would need a change to implement it.
>
> So vector types with element type T and N, a power-of-two, not otherwise
> specified are passes the same as
>
> struct S { T a[N] };
>
> ? I guess there's mismatch then for AVX types with -mno-avx then at least
> (AVX512 are probably too big to be passed in registers).
Ugh. We pass struct S { double a[4]; } in %rdi _and_ on the stack?! And
return by invisible reference _and_ in %eax?
typedef struct S { double a[4]; } v4df;
v4df foo (v4df x)
{
return x;
}
foo:
.LFB0:
.cfi_startproc
movq%rdi, %rax
movdqu 8(%rsp), %xmm0
movups %xmm0, (%rdi)
movdqu 24(%rsp), %xmm1
movups %xmm1, 16(%rdi)
ret
but a two-element array is passed/returned in two %xmm regs
[Bug target/96899] [10 Regression] [SH] Bootstrap fails when building libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96899 Richard Biener changed: What|Removed |Added Summary|[10.2 Regression] [SH] |[10 Regression] [SH] |Bootstrap fails when|Bootstrap fails when |building libgomp|building libgomp Keywords||build --- Comment #1 from Richard Biener --- Did it work with GCC 10.1?
[Bug tree-optimization/96897] Failure to optimize not+not+dec+and+not to add+or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96897 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-09-02
[Bug target/96899] [10 Regression] [SH] Bootstrap fails when building libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96899 --- Comment #2 from John Paul Adrian Glaubitz --- (In reply to Richard Biener from comment #1) > Did it work with GCC 10.1? Yes. I'm currently performing some test builds and will hopefully start bisecting soon.
[Bug target/96895] ABI of returning V1DF differs between GCC and clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96895
--- Comment #7 from Michael Matz ---
(In reply to Richard Biener from comment #5)
> So vector types with element type T and N, a power-of-two, not otherwise
> specified are passes the same as
>
> struct S { T a[N] };
>
> ?
No. structs, if they are larger than 16 bytes are of class memory. vector
types
larger than 16 bytes (which came only after the original psABI was written) are
passed different than the corresponding struct would have been (namely in the
appropriate vector registers, when those types are native to the hardware!).
That also explains your other observation:
> Ugh. We pass struct S { double a[4]; } in %rdi _and_ on the stack?! And
> return by invisible reference _and_ in %eax?
Yes, a double[4] is larger than 16 bytes, hence memory, hence passed on the
stack
and returned via implicit reference. You're mis-reading the assembler code
when
you think it's passed in %rdi and stack. %rdi contains the address of the
caller
allocated return slot, i.e. the implicit reference. %rax contains that same
address on return.
[Bug tree-optimization/96822] [11 regression] Starting with r11-2883 ICE in decompose, at wide-int.h:984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96822 seurer at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from seurer at gcc dot gnu.org --- The patch for that other one did fix this. Thanks!
[Bug libstdc++/96851] operator< on std::array does not work in constexpr, for sizeof(T) == 1, and N > 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96851 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:2f983fa69005b603ea1758a013b4134d5b0f24a8 commit r11-2981-g2f983fa69005b603ea1758a013b4134d5b0f24a8 Author: Jonathan Wakely Date: Wed Sep 2 15:17:24 2020 +0100 libstdc++: Fix three-way comparison for std::array [PR 96851] The spaceship operator for std::array uses memcmp when the __is_byte trait is true, but memcmp isn't usable in constexpr contexts. Also, memcmp should only be used for unsigned byte types, because it gives the wrong answer for signed chars with negative values. We can simply check std::is_constant_evaluated() so that we don't use memcmp during constant evaluation. To fix the problem of using memcmp for inappropriate types, this patch adds new __is_memcmp_ordered and __is_memcmp_ordered_with traits. These say whether using memcmp will give the right answer for ordering operations such as lexicographical_compare and three-way comparisons. The new traits can be used in several places, and can also be used to implement my suggestion in PR 93059 comment 37 to use memcmp for unsigned integers larger than one byte on big endian targets. libstdc++-v3/ChangeLog: PR libstdc++/96851 * include/bits/cpp_type_traits.h (__is_memcmp_ordered): New trait that says if memcmp can be used for ordering. (__is_memcmp_ordered_with): Likewise, for two types. * include/bits/deque.tcc (__lex_cmp_dit): Use new traits instead of __is_byte and __numeric_traits. (__lexicographical_compare_aux1): Likewise. * include/bits/ranges_algo.h (__lexicographical_compare_fn): Likewise. * include/bits/stl_algobase.h (__lexicographical_compare_aux1) (__is_byte_iter): Likewise. * include/std/array (operator<=>): Likewise. Only use memcmp when std::is_constant_evaluated() is false. * testsuite/23_containers/array/comparison_operators/96851.cc: New test. * testsuite/23_containers/array/tuple_interface/get_neg.cc: Adjust dg-error line numbers.
[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059 --- Comment #46 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:2f983fa69005b603ea1758a013b4134d5b0f24a8 commit r11-2981-g2f983fa69005b603ea1758a013b4134d5b0f24a8 Author: Jonathan Wakely Date: Wed Sep 2 15:17:24 2020 +0100 libstdc++: Fix three-way comparison for std::array [PR 96851] The spaceship operator for std::array uses memcmp when the __is_byte trait is true, but memcmp isn't usable in constexpr contexts. Also, memcmp should only be used for unsigned byte types, because it gives the wrong answer for signed chars with negative values. We can simply check std::is_constant_evaluated() so that we don't use memcmp during constant evaluation. To fix the problem of using memcmp for inappropriate types, this patch adds new __is_memcmp_ordered and __is_memcmp_ordered_with traits. These say whether using memcmp will give the right answer for ordering operations such as lexicographical_compare and three-way comparisons. The new traits can be used in several places, and can also be used to implement my suggestion in PR 93059 comment 37 to use memcmp for unsigned integers larger than one byte on big endian targets. libstdc++-v3/ChangeLog: PR libstdc++/96851 * include/bits/cpp_type_traits.h (__is_memcmp_ordered): New trait that says if memcmp can be used for ordering. (__is_memcmp_ordered_with): Likewise, for two types. * include/bits/deque.tcc (__lex_cmp_dit): Use new traits instead of __is_byte and __numeric_traits. (__lexicographical_compare_aux1): Likewise. * include/bits/ranges_algo.h (__lexicographical_compare_fn): Likewise. * include/bits/stl_algobase.h (__lexicographical_compare_aux1) (__is_byte_iter): Likewise. * include/std/array (operator<=>): Likewise. Only use memcmp when std::is_constant_evaluated() is false. * testsuite/23_containers/array/comparison_operators/96851.cc: New test. * testsuite/23_containers/array/tuple_interface/get_neg.cc: Adjust dg-error line numbers.
[Bug target/96814] [11 Regression] wrong code with -march=cascadelake since r11-1445-g502d63b6d6141597
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96814
Martin Liška changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #2 from Martin Liška ---
So before the revision we generated:
_1 = { 0, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 };
_2 = VEC_COND_EXPR <_1, { -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-1, -1, -1 }, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }>;
_3 = VIEW_CONVERT_EXPR(_2);
x = _3;
but now we have:
:
_1 = { -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
_24 = VIEW_CONVERT_EXPR(_1);
_25 = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
_26 = BIT_FIELD_REF <_25, 1, 0>;
_27 = _26;
_28 = { -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 };
_29 = BIT_FIELD_REF <_28, 1, 0>;
_30 = _29;
_31 = _24 & 1;
_32 = _31 != 0 ? _27 : _30;
...
_151 = _24 & 32768;
_152 = _151 != 0 ? _147 : _150;
_2 = {_32, _40, _48, _56, _64, _72, _80, _88, _96, _104, _112, _120, _128,
_136, _144, _152};
_3 = .VCOND_MASK (_2, { -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-1, -1, -1 }, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 });
_4 = VIEW_CONVERT_EXPR(_3);
x = _4;
i_15 = 0;
goto ; [INV]
It's because veclower sees:
_1 = { -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
_2 = VEC_COND_EXPR <_1, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, {
-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 }>;
_3 = VEC_COND_EXPR <_2, { -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-1, -1, -1 }, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }>;
_4 = VIEW_CONVERT_EXPR(_3);
and if I see correctly the creation of the mask _2 is broken in RTL (probably
one can't build one from a vector costructor)?
Anyway SSA_NAMEs like _128 don't have any use.
@Richi: Can you please help me with that? I'm looking into it for quite some
time :/
[Bug libstdc++/96851] operator< on std::array does not work in constexpr, for sizeof(T) == 1, and N > 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96851 --- Comment #4 from milasudril at gmail dot com --- Actually, I did not even try without the c++20 flag: template< class T, std::size_t N > bool operator<( const std::array& lhs, const std::array& rhs ); (3) (until C++20) ... template< class T, std::size_t N > constexpr /* see below */ operator<=>( const std::array& lhs, const std::array& rhs ); (7) (since C++20) https://en.cppreference.com/w/cpp/container/array/operator_cmp Thus I wouldn't expect it to work in C++17 or below. If it did, it could be considered a bug.
[Bug libstdc++/96851] operator< on std::array does not work in constexpr, for sizeof(T) == 1, and N > 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96851 --- Comment #5 from Jonathan Wakely --- (In reply to milasudril from comment #4) > Actually, I did not even try without the c++20 flag: That's irrelevant. The bug happens when using c++20, so the bug report should include the options necessary to reproduce it. Whether you tried without c++20 is irrelevant, what matters is that you *did* use c++20 when encountering the bug. So the bug report should say so. > Thus I wouldn't expect it to work in C++17 or below. If it did, it could be > considered a bug. Yes, but that doesn't mean you don't need to say which options you used when encountering the bug. People trying to reproduce the bug should not need to guess how to reproduce the bug. *I* know it needs C++20 and *you* know it needs C++20, but knowing the details of each C++ feature should not be necessary for other people to triage bug reports or try to reproduce them.
[Bug tree-optimization/96897] Failure to optimize sub+not involving constant to add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96897
Gabriel Ravier changed:
What|Removed |Added
Summary|Failure to optimize |Failure to optimize sub+not
|not+not+dec+and+not to |involving constant to add
|add+or |
--- Comment #2 from Gabriel Ravier ---
Better test case (I'd assume) :
int f(int x)
{
return ~(constant - x);
}
which should be optimizable to `x + ~constant`.
[Bug c++/60304] Including disables -Wconversion-null in C++ 98 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304 --- Comment #26 from Jonathan Wakely --- (In reply to Manuel López-Ibáñez from comment #22) > My point is that the fix cannot be only limited to tweaking stdbool.h, as > long as any C++ mode still defines false as a macro. As I said in comment 18, C++ programs can't do that. Ever. I'm going to try again to remove those macros from for C++ ...
[Bug libstdc++/96851] operator< on std::array does not work in constexpr, for sizeof(T) == 1, and N > 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96851 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:33c34c4c2466fd4fd050ed8e2d5996c35ebdeef6 commit r10-8702-g33c34c4c2466fd4fd050ed8e2d5996c35ebdeef6 Author: Jonathan Wakely Date: Wed Sep 2 15:17:24 2020 +0100 libstdc++: Fix three-way comparison for std::array [PR 96851] The spaceship operator for std::array uses memcmp when the __is_byte trait is true, but memcmp isn't usable in constexpr contexts. Also, memcmp should only be used for unsigned byte types, because it gives the wrong answer for signed chars with negative values. We can simply check std::is_constant_evaluated() so that we don't use memcmp during constant evaluation. To fix the problem of using memcmp for inappropriate types, this patch adds new __is_memcmp_ordered and __is_memcmp_ordered_with traits. These say whether using memcmp will give the right answer for ordering operations such as lexicographical_compare and three-way comparisons. The new traits can be used in several places. Unlike the trunk commit this was backported from, this commit for the branch doesn't extend the memcmp optimisations to all unsigned integers on big endian targets. Only narrow character types and std::byte will use memcmp. libstdc++-v3/ChangeLog: PR libstdc++/96851 * include/bits/cpp_type_traits.h (__is_memcmp_ordered): New trait that says if memcmp can be used for ordering. (__is_memcmp_ordered_with): Likewise, for two types. * include/bits/ranges_algo.h (__lexicographical_compare_fn): Use new traits instead of __is_byte and __numeric_traits. * include/bits/stl_algobase.h (__lexicographical_compare_aux1) (__is_byte_iter): Likewise. * include/std/array (operator<=>): Likewise. Only use memcmp when std::is_constant_evaluated() is false. * testsuite/23_containers/array/comparison_operators/96851.cc: New test. * testsuite/23_containers/array/tuple_interface/get_neg.cc: Adjust dg-error line numbers. (cherry picked from commit 2f983fa69005b603ea1758a013b4134d5b0f24a8)
[Bug libstdc++/96851] operator< on std::array does not work in constexpr, for sizeof(T) == 1, and N > 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96851 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Jonathan Wakely --- Fixed for GCC 10.3, thanks for the report.
[Bug c++/60304] Including disables -Wconversion-null in C++ 98 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304 --- Comment #27 from Jonathan Wakely --- The original testcase gets a warning even for -std=c++98 now, thanks to dmalcolm's r268589 (included in GCC 9.1).
[Bug c++/60304] Including disables -Wconversion-null in C++ 98 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
Jonathan Wakely changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment #28 from Jonathan Wakely ---
However, the preprocessed version doesn't warn even with current trunk:
# 1 "b.C"
# 1 "/home/jwakely/gcc/9/lib/gcc/x86_64-pc-linux-gnu/9.3.1/include/stdbool.h" 1
3 4
# 2 "b.C" 2
int * foo() {return
# 2 "b.C" 3 4
false
# 2 "b.C"
;}
Dave, any idea why your fix for PR 71302 causes us to warn for the following,
but not when it's already been preprocessed (as above)?
#include
int* foo() {return false;}
It's not a big deal, since we do issue the expected warning during normal
compilation, and I'm going to try to remove the macros from anyway.
[Bug c++/93317] return type deduction fails for templated unary function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93317 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Jonathan Wakely --- Fixed on trunk by r11-2420, so this looks like a dup of PR 69194. *** This bug has been marked as a duplicate of bug 69194 ***
[Bug target/69194] [5/6 Regression] internal compiler error: in extract_insn, at recog.c:2286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69194 Jonathan Wakely changed: What|Removed |Added CC||max.kan...@nu-cost.com --- Comment #7 from Jonathan Wakely --- *** Bug 93317 has been marked as a duplicate of this bug. ***
[Bug libstdc++/92978] std::gcd mishandles mixed-signedness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92978 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:c71644776f4e8477289a4de16239dbb420db6945 commit r11-2983-gc71644776f4e8477289a4de16239dbb420db6945 Author: Jonathan Wakely Date: Wed Sep 2 17:20:37 2020 +0100 libstdc++: Fix test to use correct function This was copied from a test for std::lcm but I forgot to change one of the calls to use the experimental version of the function. libstdc++-v3/ChangeLog: PR libstdc++/92978 * testsuite/experimental/numeric/92978.cc: Use experimental::lcm not std::lcm.
[Bug libstdc++/92978] std::gcd mishandles mixed-signedness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92978 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:31782bd45331ef3006f624d7b1cc9cd11b4abb84 commit r10-8703-g31782bd45331ef3006f624d7b1cc9cd11b4abb84 Author: Jonathan Wakely Date: Fri Aug 28 22:45:24 2020 +0100 libstdc++: Fix std::gcd and std::lcm for unsigned integers [PR 92978] This fixes a bug with mixed signed and unsigned types, where converting a negative value to the unsigned result type alters the value. The solution is to obtain the absolute values of the arguments immediately and to perform the actual GCD or LCM algorithm on two arguments of the same type. In order to operate on the most negative number without overflow when taking its absolute, use an unsigned type for the result of the abs operation. For example, -INT_MIN will overflow, but -(unsigned)INT_MIN is (unsigned)INT_MAX+1U which is the correct value. libstdc++-v3/ChangeLog: PR libstdc++/92978 * include/std/numeric (__abs_integral): Replace with ... (__detail::__absu): New function template that returns an unsigned type, guaranteeing it can represent the most negative signed value. (__detail::__gcd, __detail::__lcm): Require arguments to be unsigned and therefore already non-negative. (gcd, lcm): Convert arguments to absolute value as unsigned type before calling __detail::__gcd or __detail::__lcm. * include/experimental/numeric (gcd, lcm): Likewise. * testsuite/26_numerics/gcd/gcd_neg.cc: Adjust expected errors. * testsuite/26_numerics/lcm/lcm_neg.cc: Likewise. * testsuite/26_numerics/gcd/92978.cc: New test. * testsuite/26_numerics/lcm/92978.cc: New test. * testsuite/experimental/numeric/92978.cc: New test. (cherry picked from commit 82db1a42e9254c9009bbf8ac01366da4d1ab6df5)
[Bug c++/64194] [C++14] for function template with auto return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64194 Jonathan Wakely changed: What|Removed |Added CC||max.kan...@nu-cost.com --- Comment #13 from Jonathan Wakely --- *** Bug 93317 has been marked as a duplicate of this bug. ***
[Bug c++/93317] return type deduction fails for templated unary function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93317 --- Comment #3 from Jonathan Wakely --- Oops, wrong bug number, I meant PR 64194 *** This bug has been marked as a duplicate of bug 64194 ***
[Bug middle-end/96900] New: bogus -Warray-bounds on strlen with valid pointer obtained from just-past-the-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96900
Bug ID: 96900
Summary: bogus -Warray-bounds on strlen with valid pointer
obtained from just-past-the-end
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
When a valid pointer into an array that has been derived from a past-the-end
pointer to a member array of an initialized constant struct is used in a call
to a string built-in like strlen GCC issues a bogus -Warray-bounds warning
indicating that the offset into the array is out of its bounds.
$ cat q.c && gcc -S -Wall q.c
struct S { char n, a[3]; };
const char a[3] = { 2, 1, 0 };
const struct S s = { 3, { 2, 1, 0 } };
int f (void)
{
const char *p = &a[sizeof a];
return __builtin_strlen (p - sizeof a); // no warning (good)
}
int g (void)
{
const char *p = &s.a[sizeof s.a];
return __builtin_strlen (p - sizeof s.a);// bogus -Warray-bounds
}
q.c: In function ‘g’:
q.c:15:10: warning: offset ‘1’ outside bounds of constant string
[-Warray-bounds]
15 | return __builtin_strlen (p - sizeof s.a);// bogus -Warray-bounds
| ^
q.c:4:16: note: ‘s’ declared here
4 | const struct S s = { 3, { 2, 1, 0 } };
|^
[Bug c++/96877] Erroneous warning when default initializing function pointer types defined using std::declval
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96877 --- Comment #6 from Ian Henriksen --- Thanks, this makes sense. I originally got this idea from https://stackoverflow.com/a/27489923. The discussion there implied there was some kind of ambiguity in the standard and showed some examples where exception specification appeared to be carried through as a part of the type in order to satisfy the rules about assigning to function pointers with noexcept specifiers. After revisiting their examples I've found that there's actually inconsistency with how actual values are handled vs how values from std::declval are handled. For example, the following is accepted as valid C++11 by both gcc and clang: #include #include void (*function_ptr)(void *) noexcept = nullptr; using function_type = decltype(function_ptr); using function_type_2 = std::remove_reference())>::type; function_type thing1; function_type_2 thing2; static_assert(noexcept(thing1(nullptr)), ""); static_assert(!noexcept(thing2(nullptr)), ""); static_assert(std::is_same::value, ""); See https://godbolt.org/z/YbzGM3. It's not obvious to me what the correct behavior would be based off of the actual wording of the standard, but this is bizarre. This behavior is consistent across clang and the last 3 major gcc releases, but the implicit inclusion of the exception specification in the type does not seem like something that should be relied upon.
[Bug c++/96901] New: [11 Regression] Many libstdc++ tests FAIL on i686-linux due to a PCH FE bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96901 Bug ID: 96901 Summary: [11 Regression] Many libstdc++ tests FAIL on i686-linux due to a PCH FE bug Product: gcc Version: 11.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: --- I'm seeing following regressions between Monday and Tuesday evening CET trunk bootstraps: Running target unix +FAIL: 20_util/bind/42593.cc (test for excess errors) +FAIL: 20_util/bind/48698.cc (test for excess errors) +FAIL: 20_util/is_compound/value.cc (test for excess errors) +FAIL: 20_util/is_fundamental/value.cc (test for excess errors) +FAIL: 20_util/is_signed/value.cc (test for excess errors) +FAIL: 20_util/is_unsigned/value.cc (test for excess errors) +FAIL: 20_util/unique_ptr/assign/nullptr.cc (test for excess errors) +UNRESOLVED: 20_util/unique_ptr/assign/nullptr.cc compilation failed to produce executable +FAIL: 20_util/unique_ptr/cons/convertible_neg.cc (test for excess errors) +FAIL: 20_util/unique_ptr/cons/incomplete.cc (test for excess errors) +FAIL: 20_util/unique_ptr/cons/nullptr.cc (test for excess errors) +UNRESOLVED: 20_util/unique_ptr/cons/nullptr.cc compilation failed to produce executable +FAIL: 20_util/unique_ptr/requirements/explicit_instantiation/explicit_instantiation.cc (test for excess errors) +FAIL: 21_strings/basic_string/allocator/wchar_t/noexcept.cc (test for excess errors) +FAIL: 22_locale/conversions/string/requirements/typedefs-2.cc (test for excess errors) +FAIL: 23_containers/list/allocator/noexcept.cc (test for excess errors) +FAIL: 23_containers/map/modifiers/insert/2.cc (test for excess errors) +UNRESOLVED: 23_containers/map/modifiers/insert/2.cc compilation failed to produce executable +FAIL: 23_containers/map/modifiers/insert/5.cc (test for excess errors) +UNRESOLVED: 23_containers/map/modifiers/insert/5.cc compilation failed to produce executable +FAIL: 23_containers/multimap/modifiers/insert/2.cc (test for excess errors) +UNRESOLVED: 23_containers/multimap/modifiers/insert/2.cc compilation failed to produce executable +FAIL: 23_containers/multimap/modifiers/insert/22102.cc (test for excess errors) +UNRESOLVED: 23_containers/multimap/modifiers/insert/22102.cc compilation failed to produce executable +FAIL: 23_containers/multimap/modifiers/insert/4.cc (test for excess errors) +UNRESOLVED: 23_containers/multimap/modifiers/insert/4.cc compilation failed to produce executable +FAIL: 23_containers/multiset/allocator/swap.cc (test for excess errors) +UNRESOLVED: 23_containers/multiset/allocator/swap.cc compilation failed to produce executable +FAIL: 23_containers/set/allocator/swap.cc (test for excess errors) +UNRESOLVED: 23_containers/set/allocator/swap.cc compilation failed to produce executable +FAIL: 23_containers/unordered_map/insert/map_single_move-2.cc (test for excess errors) +UNRESOLVED: 23_containers/unordered_map/insert/map_single_move-2.cc compilation failed to produce executable +FAIL: 23_containers/unordered_map/modifiers/reserve.cc (test for excess errors) +UNRESOLVED: 23_containers/unordered_map/modifiers/reserve.cc compilation failed to produce executable +FAIL: 23_containers/vector/allocator/noexcept.cc (test for excess errors) +FAIL: 23_containers/vector/bool/allocator/noexcept.cc (test for excess errors) +FAIL: 25_algorithms/max/constexpr.cc (test for excess errors) +FAIL: 25_algorithms/min/constexpr.cc (test for excess errors) +FAIL: 26_numerics/random/cauchy_distribution/cons/default.cc (test for excess errors) +UNRESOLVED: 26_numerics/random/cauchy_distribution/cons/default.cc compilation failed to produce executable +FAIL: 26_numerics/random/extreme_value_distribution/cons/default.cc (test for excess errors) +UNRESOLVED: 26_numerics/random/extreme_value_distribution/cons/default.cc compilation failed to produce executable +FAIL: 26_numerics/random/normal_distribution/cons/default.cc (test for excess errors) +UNRESOLVED: 26_numerics/random/normal_distribution/cons/default.cc compilation failed to produce executable +FAIL: 26_numerics/random/student_t_distribution/cons/default.cc (test for excess errors) +UNRESOLVED: 26_numerics/random/student_t_distribution/cons/default.cc compilation failed to produce executable +FAIL: 28_regex/match_results/ctors/wchar_t/default.cc (test for excess errors) +UNRESOLVED: 28_regex/match_results/ctors/wchar_t/default.cc compilation failed to produce executable FAIL: 29_atomics/atomic_float/1.cc execution test +FAIL: 30_threads/thread/adl.cc (test for excess errors) +FAIL: experimental/net/buffer/traits.cc (test for excess errors) +FAIL: experimental/net/execution_context/make_service.cc (test for excess errors) FAIL: experimental/net/internet/resolver/ops/lookup.cc execution test +FAIL: experimental/optional/relops/2.cc (test for excess errors) +UNRESOL
[Bug middle-end/96900] [9/10/11 Regression] bogus -Warray-bounds on strlen with valid pointer obtained from just-past-the-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96900 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Known to fail||10.2.0, 11.0, 9.3.0 Summary|bogus -Warray-bounds on |[9/10/11 Regression] bogus |strlen with valid pointer |-Warray-bounds on strlen |obtained from |with valid pointer obtained |just-past-the-end |from just-past-the-end --- Comment #1 from Martin Sebor --- The false positive was introduced in r274837: commit 14b7950f126f84fa585e3a057940ff10d4c5b3f8 Author: Martin Sebor Date: Thu Aug 22 23:09:26 2019 + PR middle-end/91490 - bogus argument missing terminating nul warning on strlen of a flexible array member gcc/c-family/ChangeLog: PR middle-end/91490 * c-common.c (braced_list_to_string): Add argument and overload. Handle flexible length arrays and unions. gcc/ChangeLog: PR middle-end/91490 * builtins.c (c_strlen): Rename argument and introduce new local. Set no-warning bit on original argument. * expr.c (string_constant): Pass argument type to fold_ctor_reference. Fold empty and zero constructors into empty strings. * gimple-fold.c (fold_nonarray_ctor_reference): Return a STRING_CST for missing initializers. * tree.c (build_string_literal): Handle optional argument. * tree.h (build_string_literal): Add defaulted argument. * gimple-ssa-warn-restrict.c (maybe_diag_access_bounds): Check no-warning bit on original expression.
[Bug c++/96901] [11 Regression] Many libstdc++ tests FAIL on i686-linux due to a PCH FE bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96901 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Target Milestone|--- |11.0 Priority|P3 |P1 Last reconfirmed||2020-09-02 Ever confirmed|0 |1
[Bug libstdc++/56109] Add light-weight ABI-compatible debug checks to standard containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56109 Jonathan Wakely changed: What|Removed |Added Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #3 from Jonathan Wakely --- The __google_stl_* checks were added by these commits ... Strict weak ordering checks in algos and RB trees: 8cc511b5e5c0814584644c90cb0d65d27182eddd Invariant checks and range checks in vector: ceeb7c3b17883b21f523ab0bef937f654b12eceb Range checks in deque: 0681de38f1f402ad5f1fd9cf9959f304c36f7c10 Non-empty checks in vector: 2b4e2a67ff643ebdc4dababd95010699918ad9e0 Dead stores in vector dtor: e1a3b2e088d16544b6b64e483e12ae77a813a274 Invariant checks in vector: 7a058129926f4838bc1344f3674c1a35052a03e4 Range checks in vector and vstring, scribbling in cleared vstring: 13480920300b3cf5f09d408fe249c873fbef1ee0 All the range checks and non-empty checks should be already enabled by _GLIBCXX_ASSERTIONS. The invariant checking and strict weak order checks may be too expensive to add to _GLIBCXX_ASSERTIONS. We could consider adding the dead stores in the destructors to wipe out the memory, so that subsequent accesses fail fast. Those stores should be optimised away so will have no cost in optimised builds, but might help in -O0 builds when debugging.
[Bug c++/96901] [11 Regression] Many libstdc++ tests FAIL on i686-linux due to a PCH FE bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96901 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Created attachment 49176 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49176&action=edit gcc11-pr96901.patch Untested fix.
[Bug libstdc++/86419] codecvt::in() and out() incorrectly return ok in some cases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86419 --- Comment #6 from Jonathan Wakely --- Thanks for the analysis.
[Bug libgomp/96902] New: internal compiler error in gimplify_scan_omp_clauses with "!$omp target enter data" directive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96902 Bug ID: 96902 Summary: internal compiler error in gimplify_scan_omp_clauses with "!$omp target enter data" directive Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: michalak at ucar dot edu CC: jakub at gcc dot gnu.org Target Milestone: --- Created attachment 49177 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49177&action=edit Source file that can reproduce the ICE when compiled with gfortran and OpenMP offload >the exact version of GCC; gcc version 10.1.0 (GCC) >the system type; Target: x86_64-pc-linux-gnu Centos7, Intel Xeon (Sandybridge) Thread model: posix Supported LTO compression algorithms: zlib OFFLOAD_TARGET_NAMES=nvptx-none >the options given when GCC was configured/built; Configured with: ../gcc-10.1.0/configure --enable-offload-targets=nvptx-none --with-cuda-driver-include=/opt/nvidia/hpc_sdk/Linux_x86_64/20.7/cuda/11.0/include --with-cuda-driver-lib=/opt/nvidia/hpc_sdk/Linux_x86_64/20.7/cuda/11.0/lib64 --disable-bootstrap --disable-multilib --enable-languages=c,c++,fortran,lto --prefix=/home/michalak/gcc-offload/install >the complete command line that triggers the bug; gfortran -fopenmp -save-temps -c bug1.F90 >the compiler output (error messages, warnings, etc.); % gfortran -fopenmp -save-temps -c bug1.F90 bug1.F90:13:0: 13 | !$omp target enter data map(to:this) | internal compiler error: in gimplify_scan_omp_clauses, at gimplify.c:9013 0xac3ad9 gimplify_scan_omp_clauses ../../gcc-10.1.0/gcc/gimplify.c:9013 0xac787e gimplify_omp_target_update ../../gcc-10.1.0/gcc/gimplify.c:12944 0xac787e gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc-10.1.0/gcc/gimplify.c:14147 0xacad26 gimplify_stmt(tree_node**, gimple**) ../../gcc-10.1.0/gcc/gimplify.c:6825 0xacb92f gimplify_bind_expr ../../gcc-10.1.0/gcc/gimplify.c:1424 0xac8a86 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc-10.1.0/gcc/gimplify.c:13809 0xacad26 gimplify_stmt(tree_node**, gimple**) ../../gcc-10.1.0/gcc/gimplify.c:6825 0xacc320 gimplify_body(tree_node*, bool) ../../gcc-10.1.0/gcc/gimplify.c:14857 0xacc825 gimplify_function_tree(tree_node*) ../../gcc-10.1.0/gcc/gimplify.c:15030 0x95d2cf cgraph_node::analyze() ../../gcc-10.1.0/gcc/cgraphunit.c:670 0x960117 analyze_functions ../../gcc-10.1.0/gcc/cgraphunit.c:1227 0x960632 symbol_table::finalize_compilation_unit() ../../gcc-10.1.0/gcc/cgraphunit.c:2974 >the preprocessed file (*.i*) that triggers the bug The compiler does not get far enough to generate a *.i file. I am pasting the file "bug1.F90" below and attaching. Thank you, -John --- Contents of bug1.F90 (also attached): module diffus type diffu_t integer nlap contains procedure :: init end type diffu_t contains module subroutine init ( this ) class(diffu_t), intent(inout) :: this !$omp target enter data map(to:this) end subroutine init end module diffus
[Bug fortran/96902] internal compiler error in gimplify_scan_omp_clauses with "!$omp target enter data" directive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96902 Jakub Jelinek changed: What|Removed |Added Component|libgomp |fortran CC||burnus at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords||openmp Version|9.1.0 |10.2.1 Last reconfirmed||2020-09-02 --- Comment #1 from Jakub Jelinek --- This got fixed with r11-2079-g102502e32ea4e8a75d6b252ba319d09d735d9aa7 on the trunk.
[Bug testsuite/96903] New: [11 regression] excess errors from gcc.dg/pr89350.c after r11-2973
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96903 Bug ID: 96903 Summary: [11 regression] excess errors from gcc.dg/pr89350.c after r11-2973 Product: gcc Version: 11.0 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:0c344a649d803a83ed35f629d292b98143935ffa, r11-2973 make -k check-gcc RUNTESTFLAGS="dg.exp=gcc.dg/pr89350.c" ... Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr89350.c -fdiagnostics-plain-output -O2 -Wall -S -o pr89350.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr89350.c -fdiagnostics-plain-output -O2 -Wall -S -o pr89350.s /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr89350.c: In function 'main': /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr89350.c:16:7: warning: '__builtin_memcpy' writing 1 or more bytes into a region of size 0 overflows the destination [-Wstringop-overflow=] /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr89350.c:6:6: note: destination object 'buf' FAIL: gcc.dg/pr89350.c (test for bogus messages, line 16) PASS: gcc.dg/pr89350.c (test for excess errors) testcase /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/dg.exp completed in 0 seconds === gcc Summary === # of expected passes1 # of unexpected failures1
[Bug testsuite/96904] New: [11 regression] excess errors from old-deja.exp=g++.old-deja/g++.abi/cxa_vec.C after r11-2979
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96904 Bug ID: 96904 Summary: [11 regression] excess errors from old-deja.exp=g++.old-deja/g++.abi/cxa_vec.C after r11-2979 Product: gcc Version: 11.0 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:6bdbf0f37bda2587a4e82cbb956de7a159a397ae, r11-2979 make -k check-gcc RUNTESTFLAGS=old-deja.exp=g++.old-deja/g++.abi/cxa_vec.C FAIL: g++.old-deja/g++.abi/cxa_vec.C -std=gnu++98 (test for excess errors) FAIL: g++.old-deja/g++.abi/cxa_vec.C -std=gnu++14 (test for excess errors) FAIL: g++.old-deja/g++.abi/cxa_vec.C -std=gnu++17 (test for excess errors) FAIL: g++.old-deja/g++.abi/cxa_vec.C -std=gnu++2a (test for excess errors) # of unexpected failures4 # of unresolved testcases 4 Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++63/../../xg++ -B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++63/../../ /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.old-deja/g++.abi/cxa_vec.C -fdiagnostics-plain-output -nostdinc++ -I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++ -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++98 -pedantic-errors -Wno-long-long -L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs -B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs -L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs -B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libitm/ -L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libitm/.libs -lm -o ./cxa_vec.exe(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++63/../../xg++ -B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++63/../../ /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.old-deja/g++.abi/cxa_vec.C -fdiagnostics-plain-output -nostdinc++ -I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++ -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++98 -pedantic-errors -Wno-long-long -L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs -B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs -L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs -B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libitm/ -L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libitm/.libs -lm -o ./cxa_vec.exe^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.old-deja/g++.abi/cxa_vec.C: In function 'void test0()':^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.old-deja/g++.abi/cxa_vec.C:90:12: error: 'set_terminate' is not a member of 'std'^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.old-deja/g++.abi/cxa_vec.C: In function 'void test1()':^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.old-deja/g++.abi/cxa_vec.C:123:12: error: 'set_terminate' is not a member of 'std'^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.old-deja/g++.abi/cxa_vec.C: In function 'void test2()':^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.old-deja/g++.abi/cxa_vec.C:157:12: error: 'set_terminate' is not a member of 'std'^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.old-deja/g++.abi/cxa_vec.C: In function 'void test3()':^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.old-deja/g++.abi/cxa_vec.C:191:12: error: 'set_terminate' is not a member of 'std'^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.old-deja/g++.abi/cxa_vec.C: In function 'void test4()':^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.old-deja/g++.abi/cxa_vec.C:229:12: error: 'set_terminate' is not a member of 'std'^M compiler exited with status 1 FAIL: g++.old-deja/g++.abi/cxa_vec.C -std=gnu++98 (test for excess errors) Excess errors: /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.old-deja/g++.abi/cxa_vec.C:90:12: error: 'set_terminate' is not a member of 'std' /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.old-deja/g++.abi/cxa_vec.C:123:12: error: 'set_terminate' is not a member of 'std' /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.old-d
[Bug middle-end/96900] [9/10/11 Regression] bogus -Warray-bounds on strlen with valid pointer obtained from just-past-the-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96900 --- Comment #2 from Martin Sebor --- The underlying cause is fold_nonarray_ctor_reference() returning a scalar zero for apparently out-of-bounds references when determining the initializer for s.a from &s.a[sizeof s.a]. Its caller, constant_byte_string(), then interprets that as an array of single element initialized to zero, but it incorrectly returns the offset from the beginning of s (i.e., 4 rather than 3 minus 3 for sizeof s.a). Its caller, c_strlen(), then uses the size of the one-element initializer (for "") and the offset (positive 1) as the basis for issuing the warning.
[Bug testsuite/96904] [11 regression] excess errors from old-deja.exp=g++.old-deja/g++.abi/cxa_vec.C after r11-2979
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96904 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Jonathan Wakely --- Should be fixed at r11-2984
[Bug analyzer/96894] Analyzer assumes pointer is NULL, even if pointer was tested to be non-null before
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96894 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-09-02 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from David Malcolm --- Thanks for filing this; confirmed.
[Bug c++/96905] New: ICE with consteval function: internal compiler error: in cp_gimplify_expr, at cp/cp-gimplify.c:827
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96905
Bug ID: 96905
Summary: ICE with consteval function: internal compiler error:
in cp_gimplify_expr, at cp/cp-gimplify.c:827
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
template
struct duration
{
static consteval int
gcd(int m, int n) noexcept
{
while (m != 0 && n != 0)
{
int rem = m % n;
m = n;
n = rem;
}
return m + n;
}
};
template class duration;
Compiled with -std=gnu++20 this ICEs:
ice.C: In static member function 'static consteval int duration::gcd(int,
int) [with Rep = int]':
ice.C:7:5: internal compiler error: in cp_gimplify_expr, at
cp/cp-gimplify.c:827
7 | while (m != 0 && n != 0)
| ^
0x603457 cp_gimplify_expr(tree_node**, gimple**, gimple**)
/home/jwakely/src/gcc/gcc/gcc/cp/cp-gimplify.c:827
0xd3f160 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:13571
0xd435c6 gimplify_stmt(tree_node**, gimple**)
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:6822
0xd40e43 gimplify_statement_list
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:1856
0xd40e43 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:14106
0xd435c6 gimplify_stmt(tree_node**, gimple**)
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:6822
0xd44291 gimplify_bind_expr
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:1411
0xd40209 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:13863
0xd4dcdc gimplify_stmt(tree_node**, gimple**)
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:6822
0xd4dcdc gimplify_and_add(tree_node*, gimple**)
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:486
0x8de1d3 gimplify_must_not_throw_expr
/home/jwakely/src/gcc/gcc/gcc/cp/cp-gimplify.c:577
0x8de1d3 cp_gimplify_expr(tree_node**, gimple**, gimple**)
/home/jwakely/src/gcc/gcc/gcc/cp/cp-gimplify.c:717
0xd3f160 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:13571
0xd58ac7 gimplify_stmt(tree_node**, gimple**)
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:6822
0xd58ac7 gimplify_body(tree_node*, bool)
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:14898
0xd58efd gimplify_function_tree(tree_node*)
/home/jwakely/src/gcc/gcc/gcc/gimplify.c:15052
0xb9f997 cgraph_node::analyze()
/home/jwakely/src/gcc/gcc/gcc/cgraphunit.c:671
0xba29b7 analyze_functions
/home/jwakely/src/gcc/gcc/gcc/cgraphunit.c:1235
0xba357d symbol_table::finalize_compilation_unit()
/home/jwakely/src/gcc/gcc/gcc/cgraphunit.c:2991
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/60304] Including disables -Wconversion-null in C++ 98 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304 --- Comment #29 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:f049cda373d29ea1bce4065b24cbb392cdc5b172 commit r11-2985-gf049cda373d29ea1bce4065b24cbb392cdc5b172 Author: Jonathan Wakely Date: Wed Sep 2 18:51:28 2020 +0100 c++: Stop defining true, false and bool as macros in Since r216679 these macros have only been defined in C++98 mode, rather than all modes. That is permitted as a GNU extension because that header doesn't exist in the C++ standard until C++11, so we can make it do whatever we want for C++98. But as discussed in the PR c++/60304 comments, these macros shouldn't ever be defined for C++. This patch removes the macro definitions for C++98 too. The new test already passed for C++98 (and the conversion is ill-formed in C++11 and later) so this new test is arguably unnecessary. gcc/ChangeLog: PR c++/60304 * ginclude/stdbool.h (bool, false, true): Never define for C++. gcc/testsuite/ChangeLog: PR c++/60304 * g++.dg/warn/Wconversion-null-5.C: New test.
[Bug c++/60304] Including disables -Wconversion-null in C++ 98 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #30 from Jonathan Wakely --- The testcase warns in C++98 mode (and is ill-formed in other modes) and the macros are gone now anyway. While I'm curious why the preprocessed code in comment 28 doesn't warn, I think we can call this fixed now.
[Bug testsuite/96904] [11 regression] excess errors from old-deja.exp=g++.old-deja/g++.abi/cxa_vec.C after r11-2979
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96904 --- Comment #2 from seurer at gcc dot gnu.org --- Yup, thanks
[Bug target/96906] New: Failure to optimize __builtin_ia32_psubusw128 compared to 0 to __builtin_ia32_pminuw128 compared to operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96906
Bug ID: 96906
Summary: Failure to optimize __builtin_ia32_psubusw128 compared
to 0 to __builtin_ia32_pminuw128 compared to operand
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
typedef int16_t v8i16 __attribute__((vector_size(16)));
v8i16 cmple_epu16(v8i16 x, v8i16 y)
{
return __builtin_ia32_psubusw128(x, y) == 0;
}
With -msse4.1, this can be optimized to `return __builtin_ia32_pminuw128(x, y)
== x;`. This transformation is done by LLVM, but not by GCC.
PS: I'm not 100% sure this is faster but it logically should be, since the
`pminuw` version doesn't have to handle zeroing an SSE register.
[Bug c/96907] New: [docs] document builtins for fputc and putc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96907 Bug ID: 96907 Summary: [docs] document builtins for fputc and putc Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: ndesaulniers at google dot com CC: rv at rasmusvillemoes dot dk, segher at kernel dot crashing.org Target Milestone: --- In https://reviews.llvm.org/D86508, I'm going through and working on improving Clang's compatibility with GCC in terms of supported compiler __builtin_ functions. I noticed that __has_builtin works with putc, __builtin_putc, fputc, and __builtin_fputc in GCC. I think putc and fputc could be added to this page. https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
[Bug c++/96905] ICE with consteval function: internal compiler error: in cp_gimplify_expr, at cp/cp-gimplify.c:827
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96905 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||jakub at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2020-09-02 --- Comment #1 from Marek Polacek --- Confirmed. Started with r277733 -- the introduction of consteval.
[Bug c++/96905] ICE with consteval function: internal compiler error: in cp_gimplify_expr, at cp/cp-gimplify.c:827
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96905 --- Comment #2 from Marek Polacek --- It looks like we've never cp_genericized the consteval function.
[Bug c++/81999] templated lambda in template context: cannot call operator() explicitly with template parameters (expected primary-expression before ...)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81999 bastien penavayre changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from bastien penavayre --- missing template keyword
[Bug c/96907] [docs] document builtins for fputc and putc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96907 --- Comment #1 from Andrew Pinski --- putc was added by g-b53b5aa509 fputc has been there since before 2003.
[Bug d/96869] __vectors unsupported in hardware should be rejected at compile-time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96869 --- Comment #3 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:f0a3bab43fda3084eaf1bdaac58936757f30ea35 commit r11-2988-gf0a3bab43fda3084eaf1bdaac58936757f30ea35 Author: Iain Buclaw Date: Mon Aug 31 22:42:10 2020 +0200 d: __vectors unsupported in hardware should be rejected at compile-time. gcc/d/ChangeLog: PR d/96869 * d-builtins.cc (build_frontend_type): Don't expose intrinsics that use unsupported vector types. * d-target.cc (Target::isVectorTypeSupported): Restrict to supporting only if TARGET_VECTOR_MODE_SUPPORTED_P is true. Don't allow complex or boolean vector types. gcc/testsuite/ChangeLog: PR d/96869 * gdc.dg/simd.d: Removed. * gdc.dg/cast1.d: New test. * gdc.dg/gdc213.d: Compile with target vect_sizes_16B_8B. * gdc.dg/gdc284.d: Likewise. * gdc.dg/gdc67.d: Likewise. * gdc.dg/pr96869.d: New test. * gdc.dg/simd1.d: New test. * gdc.dg/simd10447.d: New test. * gdc.dg/simd12776.d: New test. * gdc.dg/simd13841.d: New test. * gdc.dg/simd13927.d: New test. * gdc.dg/simd15123.d: New test. * gdc.dg/simd15144.d: New test. * gdc.dg/simd16087.d: New test. * gdc.dg/simd16697.d: New test. * gdc.dg/simd17237.d: New test. * gdc.dg/simd17695.d: New test. * gdc.dg/simd17720a.d: New test. * gdc.dg/simd17720b.d: New test. * gdc.dg/simd19224.d: New test. * gdc.dg/simd19627.d: New test. * gdc.dg/simd19628.d: New test. * gdc.dg/simd19629.d: New test. * gdc.dg/simd19630.d: New test. * gdc.dg/simd2a.d: New test. * gdc.dg/simd2b.d: New test. * gdc.dg/simd2c.d: New test. * gdc.dg/simd2d.d: New test. * gdc.dg/simd2e.d: New test. * gdc.dg/simd2f.d: New test. * gdc.dg/simd2g.d: New test. * gdc.dg/simd2h.d: New test. * gdc.dg/simd2i.d: New test. * gdc.dg/simd2j.d: New test. * gdc.dg/simd7951.d: New test. * gdc.dg/torture/array2.d: New test. * gdc.dg/torture/array3.d: New test. * gdc.dg/torture/simd16488a.d: New test. * gdc.dg/torture/simd16488b.d: New test. * gdc.dg/torture/simd16703.d: New test. * gdc.dg/torture/simd19223.d: New test. * gdc.dg/torture/simd19607.d: New test. * gdc.dg/torture/simd3.d: New test. * gdc.dg/torture/simd4.d: New test. * gdc.dg/torture/simd7411.d: New test. * gdc.dg/torture/simd7413a.d: New test. * gdc.dg/torture/simd7413b.d: New test. * gdc.dg/torture/simd7414.d: New test. * gdc.dg/torture/simd9200.d: New test. * gdc.dg/torture/simd9304.d: New test. * gdc.dg/torture/simd9449.d: New test. * gdc.dg/torture/simd9910.d: New test.
[Bug d/96869] __vectors unsupported in hardware should be rejected at compile-time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96869 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Iain Buclaw --- Done.
[Bug c++/96905] ICE with consteval function: internal compiler error: in cp_gimplify_expr, at cp/cp-gimplify.c:827
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96905 --- Comment #3 from Jakub Jelinek --- Yeah, we certainly never want to genericize them.
