[Bug tree-optimization/94043] [9/10 Regression] ICE in superloop_at_depth, at cfgloop.c:78
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94043 --- Comment #12 from Kewen Lin --- Created attachment 48122 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48122=edit ppc64le tested patch Thanks Richi! A patch draft attached to ensure on the right track, also bootstrapped/regresstested. I tried to reproduce the case that the stmts for lane extracting is empty (due to folding) with test cases associated in that old commit but failed. I think we don't need to deal with it? The new copy assignment instead of the phi could not be caught by the LC-PHI check in expand_simple_operations.
[Bug c/94337] New: Incorrect "dereferencing type-punned pointer will break strict-aliasing rules" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94337
Bug ID: 94337
Summary: Incorrect "dereferencing type-punned pointer will
break strict-aliasing rules" warning
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Consider the following example.
#include
struct s1
{
int a;
};
struct s2
{
int a, b;
};
int main (void)
{
union {
struct s1 m1[1];
struct s2 m2[1];
} u;
(u.m2)->b = 17;
printf ("%d\n", ((struct s2 *) (struct s1 *) u.m2)->b);
printf ("%d\n", ((struct s2 *) u.m1)->b);
return 0;
}
zira:~> gcc-10 tst.c -o tst -O2 -Wstrict-aliasing
tst.c: In function ‘main’:
tst.c:22:20: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
22 | printf ("%d\n", ((struct s2 *) u.m1)->b);
| ~^~~
But there is no type-punning here. All accesses are done via struct s2.
Everything else is pointer conversions, which are not related to the aliasing
rules.
[Bug c++/94336] New: template keyword accepted before destructor names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94336
Bug ID: 94336
Summary: template keyword accepted before destructor names
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: ---
We accept the following:
template void f(T *p) { p->template ~X(); }
template struct X {};
void g(X *p) { f(p); }
but arguably we shouldn't because [temp.names]/5: A name prefixed by the
keyword template shall be a template-id or the name shall refer to a class
template or an alias template.
[Bug c/60846] Add 128-bit integer types for general use on 32-bit/64-bit CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60846 mirh at protonmail dot ch changed: What|Removed |Added CC||mirh at protonmail dot ch --- Comment #6 from mirh at protonmail dot ch --- Any update? Of course performance is going to take a hit, but if you are working with 128bit data it's not like you have much other choices (other than painstakingly working this around yourself).
[Bug tree-optimization/94335] False positive -Wstringop-overflow warning with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94335 --- Comment #2 from Romain Geissler --- Thanks for the explanation. However few observations: - Is it really expected that the wording of the warning seems to imply gcc knows for sure that there is an invalid access ? What is the warning meant to find ? Potential issues, or real issues gcc can prove will happen 100% of the time ? Here I see that you pasted: if (_24 != -9223372036854775808) goto ; [94.29%] else goto ; [5.71%] so gcc itself is able to see that the most likely case is that we go in basic block 4 rather than 5 which emits this warning. So either the wording of the warning shall be updated to reflect that "maybe" the code wrong, either if possible we should try to make a different when gcc is sure and when it is not (like -Wuninitialized vs -Wmaybe-uninitialized). - Second observations, how do you suggest we teach gcc that this is indeed a false positive and we want the warning to be silenced. You mentioned "if (d == kEmptyPointer) __builtin_unreachable;", does this statement result in effectively having a new basic block branching where one side terminates the program and the other runs the actual expected behavior of "setVal". In other words, will the condition in the "if" really be emitted by the codegen and evaluated at runtime, or do I have the guarantee it will not emit new branches and only teach the optimizer that some cases are impossible ? In the case the answer is that it will emit a real codegen branch potentially impacting runtime, do you think it's worth adding a __builtin_assume in gcc like clang has (not in gcc 10 obviously, but in gcc 11 during stage 1) ? Cheers, Romain
[Bug tree-optimization/94335] False positive -Wstringop-overflow warning with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94335
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
CC||msebor at gcc dot gnu.org
--- Comment #1 from Martin Sebor ---
This type of warning is new GCC 10; it was added in the commit below. It works
as designed here. It sees the following IL (the memset calls don't do
anything). The MEM[] = 65; statement is what triggers it.
[local count: 1073741824]:
aDummyBuffer_4 = malloc (10);
it ={v} {CLOBBER};
if (aDummyBuffer_4 != 0B)
goto ; [70.00%]
else
goto ; [30.00%]
[local count: 751619281]:
_24 = aDummyBuffer_4 -
it.d = _24;
itCopy ={v} {CLOBBER};
if (_24 != -9223372036854775808)
goto ; [94.29%]
else
goto ; [5.71%]
[local count: 708669601]:
_23 = aDummyBuffer_4 -
itCopy.d = _23;
*aDummyBuffer_4 = 65;
aDummySource_97 = malloc (10);
D.40357 ={v} {CLOBBER};
_17 = aDummyBuffer_4 -
D.40357.d = _17;
goto ; [100.00%]
[local count: 365072224]:
itCopy.d = -424242;
MEM[(char *) + -424242B] = 65; <<< warning here
aDummySource_105 = malloc (10);
D.40357 ={v} {CLOBBER};
D.40357.d = -424242;
...
[local count: 322122544]:
it.d = -9223372036854775808;
itCopy ={v} {CLOBBER};
goto ; [100.00%]
It doesn't matter (much) whether the initial address is or can be null (the
warning persists even with operator new that doesn't return null or when the
ctor never does set d to kEmptyPointer). The branch of the code that sets d
to -424242 isn't eliminated because the pointer subtraction in either ctor
could, as far as GCC can tell, result in the same value as kEmptyPointer.
Asserting that the subtraction doesn't result in such a value, for instance
like so:
if (d == kEmptyPointer) __builtin_unreachable ();
and also guaranteeing that the initial address isn't null (e.g., by using
operator new) eliminates the warning.
Short of teaching GCC that the magnitude of the difference between any two
pointers must be less than PTRDIFF_MAX I don't think there's anything that can
be done do improve things (either codegen, or avoid the warning in this case).
I'll leave this report unresolved in case someone feels otherwise.
commit b631bdb3c16e85f35d38e39b3d315c35e4a5747c
Author: Martin Sebor
Date: Thu Jul 25 00:29:17 2019 +
PR tree-optimization/91183 - strlen of a strcpy result with a conditional
source not folded
PR tree-optimization/91183 - strlen of a strcpy result with a conditional
source not folded
PR tree-optimization/86688 - missing -Wstringop-overflow using a non-string
local array in strnlen with excessive bound
[Bug target/93819] PPC64 builtin vec_rlnm() argument order is wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93819 --- Comment #4 from CVS Commits --- The master branch has been updated by Carl Love : https://gcc.gnu.org/g:e97929e20b2f52e6cfc046c1302324d1b24d95e3 commit r10-7389-ge97929e20b2f52e6cfc046c1302324d1b24d95e3 Author: Carl Love Date: Wed Mar 25 18:33:37 2020 -0500 [PATCH] rs6000: vec_rlnm fix to make builtin work according to ABI gcc/ChangeLog 2020-03-25 Carl Love PR target/93819 * gcc/config/rs6000/altivec.h: Fixed swapped arguments for vec_rlnm define.
[Bug tree-optimization/94335] New: False positive -Wstringop-overflow warning with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94335
Bug ID: 94335
Summary: False positive -Wstringop-overflow warning with -O2
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
The following code emits a false positive -Wstringop-overflow warning with gcc
trunk with -O2 and -O3.
It's reduced manually from a much more complex scenario, where we try to define
an iterator that can be stored in shared memory, thus referencing object
through relative addresses rather than absolute addresses. In the warning of
this scenario, I don't see how we can access offset -424242 as the initial
pointed address is never nullptr.
Note: gcc 8/9 do not emit such warning.
#include
#include
#include
#include
#include
template
struct relative_address_iterator {
typedef T value;
typedef T *pointer;
typedef const T *const_pointer;
typedef T
typedef const T _reference;
typedef T value_type;
typedef ptrdiff_t difference_type;
typedef std::forward_iterator_tag iterator_category;
off_t d;
static constexpr off_t kEmptyPointer = std::numeric_limits::min();
/** Constructs the object from a pointer.
*/
relative_address_iterator(pointer t)
{
if (t)
{
d = (char *)t - (char *)this;
}
else
{
d = kEmptyPointer;
}
}
/** Copy constructor.
*/
relative_address_iterator(const relative_address_iterator )
{
if (r.d != kEmptyPointer)
{
d = (char *) - (char *)this + r.d;
}
else
{
// Normally this should not happen in this example, but gcc thinks
it does,
// as the error message references the special value -424242.
// d = kEmptyPointer;
d = -424242;
}
}
/** Initializes the pointee with the given value.
*/
void setVal(const_reference value) { *(pointer)((char *)this + d) = value;
}
/** Dereferences the object.
*/
operator pointer()
{
if (d == kEmptyPointer) return nullptr;
return ((pointer)((char *)this + d));
}
/** Preincrement operator.
*/
relative_address_iterator ++()
{
d += sizeof(value);
return (*this);
}
};
void f()
{
char* aDummyBuffer = static_cast(malloc(10));
memset(aDummyBuffer, 10, 0);
relative_address_iterator it(aDummyBuffer);
relative_address_iterator itCopy(it);
itCopy.setVal('A');
char* aDummySource = static_cast(malloc(10));
memset(aDummySource, 10, 0);
std::copy(relative_address_iterator(aDummySource),
relative_address_iterator(aDummySource + 5),
it);
}
int main()
{
f();
}
In member function 'void
relative_address_iterator::setVal(relative_address_iterator::const_reference)
[with T = char]',
inlined from 'void f()' at :82:18:
:56:71: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
56 | void setVal(const_reference value) { *(pointer)((char *)this + d) =
value; }
|
~^~~
: In function 'void f()':
:80:37: note: at offset -424242 to object 'itCopy' with size 8 declared
here
80 | relative_address_iterator itCopy(it);
| ^~
Compiler returned: 0
Cheers,
Romain
[Bug target/91614] [10 regression][arm] gcc.target/arm/unaligned-memcpy-2.c FAIL since r274986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91614 --- Comment #4 from Jeffrey A. Law --- I think the ARM maintainers need to make a decision here. Bernd, you might want to ping that last patch.
[Bug target/90763] PowerPC vec_xl_len should take const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90763 Will Schmidt changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #7 from Will Schmidt --- closing.
[Bug target/90763] PowerPC vec_xl_len should take const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90763 Will Schmidt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Will Schmidt --- Should be all fixed. closing. thanks -Will
[Bug c++/94257] ICE in inline nested namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94257
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2020-03-25
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
CC||mpolacek at gcc dot gnu.org,
||nathan at gcc dot gnu.org
--- Comment #1 from Marek Polacek ---
This compiled without errors until
r8-952-g945bf9e13f706bed44ec760ac60693e00c59b146:
94257.C:4:18: error: conflicting declaration of namespace ‘B’
inline namespace B {
^
and the ICE started with
r8-1488-g71bbbd133f65c26f65709037401154362210560e
[Bug target/91614] [10 regression][arm] gcc.target/arm/unaligned-memcpy-2.c FAIL since r274986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91614 Bernd Edlinger changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #3 from Bernd Edlinger --- My attempt at fixing this failure https://gcc.gnu.org/legacy-ml/gcc-patches/2019-09/msg00370.html I am not sure if it war rejected or just not reviewe
[Bug target/91518] [9/10 Regression] segfault when run CPU2006 465.tonto since r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91518 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P1 CC||law at redhat dot com
[Bug target/91498] [10 Regression] STV change in r274481 causes 300.twolf regression on Haswell
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91498 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Priority|P3 |P2
[Bug target/91614] [10 regression][arm] gcc.target/arm/unaligned-memcpy-2.c FAIL since r274986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91614 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 CC||law at redhat dot com
[Bug testsuite/94334] New: new tests gcc.dg/lto/pr94271 fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94334
Bug ID: 94334
Summary: new tests gcc.dg/lto/pr94271 fail
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at linux dot vnet.ibm.com
Target Milestone: ---
g:724ec02c2c6d1b79788be77f68ebb6ca7b5b6acd, r10-7372
This specific revision can't be built because of a compilation error but this
is where the test case was introduced. This was seen on powerpc64.
# of unexpected failures12
# of unresolved testcases 12
FAIL: gcc.dg/lto/pr94271 c_lto_pr94271_0.o assemble, -O0 -flto
-flto-partition=none -fuse-linker-plugin
FAIL: gcc.dg/lto/pr94271 c_lto_pr94271_1.o assemble, -O0 -flto
-flto-partition=none -fuse-linker-plugin
FAIL: gcc.dg/lto/pr94271 c_lto_pr94271_0.o assemble, -O2 -flto
-flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects
FAIL: gcc.dg/lto/pr94271 c_lto_pr94271_1.o assemble, -O2 -flto
-flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects
FAIL: gcc.dg/lto/pr94271 c_lto_pr94271_0.o assemble, -O0 -flto
-flto-partition=1to1 -fno-use-linker-plugin
FAIL: gcc.dg/lto/pr94271 c_lto_pr94271_1.o assemble, -O0 -flto
-flto-partition=1to1 -fno-use-linker-plugin
FAIL: gcc.dg/lto/pr94271 c_lto_pr94271_0.o assemble, -O2 -flto
-flto-partition=1to1 -fno-use-linker-plugin
FAIL: gcc.dg/lto/pr94271 c_lto_pr94271_1.o assemble, -O2 -flto
-flto-partition=1to1 -fno-use-linker-plugin
FAIL: gcc.dg/lto/pr94271 c_lto_pr94271_0.o assemble, -O0 -flto
-fuse-linker-plugin -fno-fat-lto-objects
FAIL: gcc.dg/lto/pr94271 c_lto_pr94271_1.o assemble, -O0 -flto
-fuse-linker-plugin -fno-fat-lto-objects
FAIL: gcc.dg/lto/pr94271 c_lto_pr94271_0.o assemble, -O2 -flto
-fuse-linker-plugin
FAIL: gcc.dg/lto/pr94271 c_lto_pr94271_1.o assemble, -O2 -flto
-fuse-linker-plugin
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/lto/pr94271_0.c:6:67: error:
__attribute__((__target__('avx512f'))) is invalid
[Bug rtl-optimization/90275] [8/9 Regression] ICE: in insert_regs, at cse.c:1128 with -O2 -fno-dce -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90275 --- Comment #17 from CVS Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:48817fbd7616f086ac7bb1dd38b862f78762c9b8 commit r10-7384-g48817fbd7616f086ac7bb1dd38b862f78762c9b8 Author: Jeff Law Date: Wed Mar 25 14:33:08 2020 -0600 Fix vector-compare-1 regressions on sh4/sh4eb caused by pattern clobbering T reg without expressing that in its RTL. PR rtl-optimization/90275 * config/sh/sh.md (mov_neg_si_t): Clobber the T register in the pattern.
[Bug d/94321] gdc.dg/pr92216.d FAILs on 32-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94321 John David Anglin changed: What|Removed |Added Target|i386-pc-solaris2.11,|i386-pc-solaris2.11, |sparc-sun-solaris2.11 |sparc-sun-solaris2.11, ||hppa-unknown-linux-gnu CC||danglin at gcc dot gnu.org --- Comment #1 from John David Anglin --- Same issue on hppa-linux.
[Bug rtl-optimization/90275] [8/9 Regression] ICE: in insert_regs, at cse.c:1128 with -O2 -fno-dce -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90275 --- Comment #16 from CVS Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:eeb0c7c07133634eb5e98ba0348392684a763c95 commit r10-7383-geeb0c7c07133634eb5e98ba0348392684a763c95 Author: Jeff Law Date: Wed Mar 25 14:12:32 2020 -0600 Fix vector-compare-1 regressions on sh4/sh4eb caused by pattern clobbering T reg without expressing that in its RTL. PR rtl-optimization/90275 * config/sh/sh.md (mov_neg_si_t): Clobber the T register in the pattern.
[Bug middle-end/94313] stores into string literals sometimes silently eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94313 --- Comment #4 from Martin Sebor --- An implementation is free to do whatever it wants when it finds invalid/undefined code. A quality implementation will also let the user know about it so it can be fixed. An even better one will let the user choose what to do in response (as we discussed in Manchester, it could either trap, substitute zero, or simply remove the code and proceed as if it was never there; other alternatives might be possible). This is all perfectly compatible with your preference. As long as the code is diagnosed it also meets my goal.
[Bug target/81594] Optimize PowerPC vector set and store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81594 --- Comment #7 from Segher Boessenkool --- Peepholes catch fewer cases, and it is very hard to write correct peepholes. The only reason to use peepholes is when the other passes leave some important optimisation on the table, and you cannot feasibly fix that problem. They are not a substitute for proper optimisation (for example, almost all "interesting" optimisation happen before it, so you cannot rely on combine or cse or *prop etc. to do anything -- so, if you want some simple optimisations with it you need to write that manually (an exponential amount of work). This even applies to "trivial" things like constant arguments. Peepholes are nice for mopping up those cases that for one reason or the other the other compiler passes cannot / do not get right. They can "tune" the compiler output to be just a teeny bit better. They cannot do anything more than that.
[Bug c++/94333] New: internal compiler error: Segmentation fault ( when trying use structure binding in requires(requires{}))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94333
Bug ID: 94333
Summary: internal compiler error: Segmentation fault ( when
trying use structure binding in requires(requires{}))
Product: gcc
Version: c++-concepts
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dmusiienko at gmail dot com
Target Milestone: ---
template
struct has2param
{
typedef char yes;
typedef struct{char n[2];} no;
template
static yes check(U u) requires(requires{[](auto u){auto [a, b] = u;}(u);});
static no check(...);
static constexpr bool y = sizeof(check(T())) == sizeof(yes);
};
struct point
{
int x;
int y;
};
int main()
{
point p{1, 2};
constexpr bool ans = has2param::y;
return 0;
}
---
x86-64 gcc(trunc) compiler output:
---
: In instantiation of 'static has2param::yes has2param::check(U)
requires requires{()(has2param::check::u);} [with U = point; T =
point; has2param::yes = char]':
:9:43: required from 'constexpr const bool has2param::y'
:21:50: required from here
:7:45: internal compiler error: Segmentation fault
7 | static yes check(U u) requires(requires{[](auto u){auto [a, b] =
u;}(u);});
|
^~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug target/94292] [10 Regression] ICE: SIGSEGV in forward_propagate_and_simplify (fwprop.c:1417) with -O -g -fno-tree-dce since r10-3985-g8b8ab8f473b42933b9c1e292c4b1ab02adf1863a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94292 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug target/94292] [10 Regression] ICE: SIGSEGV in forward_propagate_and_simplify (fwprop.c:1417) with -O -g -fno-tree-dce since r10-3985-g8b8ab8f473b42933b9c1e292c4b1ab02adf1863a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94292
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:6e4cd3cd259af2b5e04986a3f528a4f9f762
commit r10-7382-g6e4cd3cd259af2b5e04986a3f528a4f9f762
Author: Jakub Jelinek
Date: Wed Mar 25 19:06:45 2020 +0100
arm: Fix ICE caused by arm_gen_dicompare_reg [PR94292]
The following testcase ICEs, because arm_gen_dicompare_reg creates invalid
RTL which then propagates into DEBUG_INSNs and ICEs while handling them.
The problem is that this function emits
(insn 18 17 19 2 (set (reg:CC_DNE 100 cc)
(compare (ior:SI (ne:SI (subreg:SI (reg:DI 129) 0)
(subreg:SI (reg:DI 114 [ _2 ]) 0))
(ne:SI (subreg:SI (reg:DI 129) 4)
(subreg:SI (reg:DI 114 [ _2 ]) 4)))
(const_int 0 [0]))) "pr94292.c":7:11 325 {*cmp_ior}
(nil))
and the invalid thing is that the COMPARE has VOIDmode. Setting a
non-VOIDmode SET_DEST to VOIDmode SET_SRC is only valid if the SET_SRC is
CONST_INT/CONST_DOUBLE.
The following patch fixes it by giving the COMPARE the same mode as it
gives
to the SET_DEST cc register.
2020-03-25 Jakub Jelinek
PR target/94292
* config/arm/arm.c (arm_gen_dicompare_reg): Set mode of COMPARE to
mode rather than VOIDmode.
* gcc.dg/pr94292.c: New test.
[Bug c++/94306] Improve diagnostic when "requires" used instead of "requires requires" and add fix-it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94306 Patrick Palka changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Target Milestone|--- |10.0 Last reconfirmed||2020-03-25 --- Comment #1 from Patrick Palka --- Confirmed. Looking into it.
[Bug middle-end/94313] stores into string literals sometimes silently eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94313 --- Comment #3 from rguenther at suse dot de --- On Wed, 25 Mar 2020, msebor at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94313 > > --- Comment #2 from Martin Sebor --- > Removing invalid code not isn't wrong (as in non-conforming), but it's > decidedly unhelpful in avoiding the undefined behavior that doesn't > necessarily > go away just because the invalid statement is gone. It makes finding the > underlying bugs difficult. My solution for pr90404 detects most of these bugs > (and can also eliminate the buggy code) except those that are removed by DSE. > The intent of this report isn't so much to complain that GCC is doing > something > wrong but to document the rationale for doing something different (i.e., > diagnose these bugs consistently and leave it up to the user whether to > eliminate the code or replace it with a trap or something else). Usually the whole point of undefined behavior is that you do not need to detect it. When you detect undefined behavior you can try to do something sensible (try to second guess DWIM) like for example how we allow invalid type-punning when we see a trivial must-alias. In this case points-to analysis does not bother to invent something to represent not useful information because it's not useful and just wastes resources.
[Bug c++/94332] New: [concepts] requires-expression that contains a requires-expression incorrectly evaluates to false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94332
Bug ID: 94332
Summary: [concepts] requires-expression that contains a
requires-expression incorrectly evaluates to false
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
$ cat requires-requires.C
template
requires B
struct X { };
template
concept C = requires { X{}; };
static_assert(C); // should succeed
$ g++ -std=c++2a requires-requires.C
requires-requires.C:8:15: error: static assertion failed
8 | static_assert(C); // should succeed
| ^~
requires-requires.C:8:15: note: constraints not satisfied
requires-requires.C:6:11: required by the constraints of ‘template
concept C’
requires-requires.C:6:15: in requirements
requires-requires.C:6:26: note: the required expression ‘X{}’
is invalid
6 | concept C = requires { X{}; };
| ^~~
If we let the compiler elaborate further, we get:
requires-requires.C:6:26: note: the required expression ‘X{}’
is invalid, because
6 | concept C = requires { X{}; };
| ^~~
requires-requires.C:6:26: error: invalid use of incomplete type ‘struct
X’
requires-requires.C:3:10: note: declaration of ‘struct X’
3 | struct X { };
[Bug c++/94319] gcc/cp/coroutines.cc:2654: strange assignment ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94319 --- Comment #5 from David Binderman --- (In reply to Iain Sandoe from comment #4) > so fixed That's good news. I've no idea how the broken code would have been reached. Would it be worthwhile adding a test case to the test suite which reaches the now fixed code, to make sure it stays fixed in future ? Or maybe there is an existing test case which used to fail which now passes ?
[Bug middle-end/94004] [8/9 Regression] missing -Walloca on calls to alloca due to -Wno-system-headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94004 Martin Sebor changed: What|Removed |Added Known to work||10.0 Summary|[8/9/10 Regression] missing |[8/9 Regression] missing |-Walloca on calls to alloca |-Walloca on calls to alloca |due to -Wno-system-headers |due to -Wno-system-headers Known to fail|10.0| --- Comment #8 from Martin Sebor --- Fixed on trunk (GCC 10).
[Bug middle-end/94004] [8/9/10 Regression] missing -Walloca on calls to alloca due to -Wno-system-headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94004 --- Comment #7 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:b5228b1bc8cb81be494f5b5faa68b6b859ce0227 commit r10-7381-gb5228b1bc8cb81be494f5b5faa68b6b859ce0227 Author: Martin Sebor Date: Wed Mar 25 10:48:13 2020 -0600 PR middle-end/94004 - missing -Walloca on calls to alloca due to -Wno-system-headers gcc/testsuite/ChangeLog: PR middle-end/94004 * gcc.dg/Walloca-larger-than-3.c: New test. * gcc.dg/Walloca-larger-than-3.h: New test header. * gcc.dg/Wvla-larger-than-4.c: New test. gcc/ChangeLog: PR middle-end/94004 * gimple-ssa-warn-alloca.c (pass_walloca::execute): Issue warnings even for alloca calls resulting from system macro expansion. Include inlining context in all warnings.
[Bug target/94254] [10 regression] r10-7312 causes compiler hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #20 from Jeffrey A. Law --- Fixed by Richard's patch.
[Bug target/94254] [10 regression] r10-7312 causes compiler hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254 --- Comment #19 from CVS Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:713ecb3d417363a4b12c725b335fce10355da206 commit r10-7380-g713ecb3d417363a4b12c725b335fce10355da206 Author: Jeff Law Date: Wed Mar 25 10:37:31 2020 -0600 rs6000: Allow FPRs to change between SDmode and DDmode [PR94254] g:497498c878d48754318e486428e2aa30854020b9 caused lra to cycle on some SDmode reloads for power6. As explained in more detail in the PR comments, the problem was a conflict between two target hooks: rs6000_secondary_memory_needed_mode required SDmode FPR reloads to use DDmode memory (rightly, since using SDmode memory wouldn't make progress) but rs6000_can_change_mode_class didn't allow FPRs to change from SDmode to DDmode. Previously lra ignored that and changed the mode anyway. From what Segher says, it sounds like the "from_size < 8 || to_size < 8" check is mostly there for SF<->64-bit subregs, and that SDmode is stored in the way that target-independent code expects. This patch therefore allows SD<->DD changes. I wondered about checking for SD<->64-bit changes instead, but that seemed like an unnecessary generalisation for this stage. 2020-03-23 Richard Sandiford gcc/ PR target/94254 * config/rs6000/rs6000.c (rs6000_can_change_mode_class): Allow FPRs to change between SDmode and DDmode.
[Bug c++/94265] wrong warning "duplicated 'if' condition"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94265 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #4 from Patrick Palka --- Thanks for the bug report, this is now fixed for GCC 10.
[Bug target/94254] [10 regression] r10-7312 causes compiler hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #18 from Jeffrey A. Law --- I put the candidate patch into my tester which will run it on ppc64 and ppc64le native. Both ran fine and it fixed the regressions associated with Richard's LRA patch. They also both successfully built glibc and the kernel. Given Segher's c#12, I'm going to go ahead and commit the patch from c#11.
[Bug c++/94265] wrong warning "duplicated 'if' condition"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94265 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:c7a252ba2d0a08397d8fc6d6dc7db34f90f76acb commit r10-7379-gc7a252ba2d0a08397d8fc6d6dc7db34f90f76acb Author: Patrick Palka Date: Wed Mar 25 12:32:43 2020 -0400 c++: Fix invalid -Wduplicated-cond warning [PR94265] This fixes a false-positive warning from -Wduplicate-cond in the presence of an if-statement with a non-empty init-statement. Precisely determining whether a non-empty init-statement has side effects seems tricky and error-prone, so this patch takes the route of unconditionally invalidating the condition chain when it encounters such an if-statement. gcc/cp/ChangeLog: PR c++/94265 * parser.c (cp_parser_selection_statement) : Invalidate the current condition chain when the if-statement has a non-empty init-statement. gcc/testsuite/ChangeLog: PR c++/94265 * g++.dg/warn/Wduplicated-cond1.C: New test.
[Bug middle-end/94313] stores into string literals sometimes silently eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94313 --- Comment #2 from Martin Sebor --- Removing invalid code not isn't wrong (as in non-conforming), but it's decidedly unhelpful in avoiding the undefined behavior that doesn't necessarily go away just because the invalid statement is gone. It makes finding the underlying bugs difficult. My solution for pr90404 detects most of these bugs (and can also eliminate the buggy code) except those that are removed by DSE. The intent of this report isn't so much to complain that GCC is doing something wrong but to document the rationale for doing something different (i.e., diagnose these bugs consistently and leave it up to the user whether to eliminate the code or replace it with a trap or something else).
[Bug debug/94323] [10 Regression] g++: error: x.cpp: ‘-fcompare-debug’ failure since r10-7359-g6e771c087b10d5b730240ea35478eab8694c9c5d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94323 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Jakub Jelinek --- Created attachment 48121 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48121=edit gcc10-pr94323.patch Untested fix. Though, it is very ugly.
[Bug tree-optimization/94187] [10 Regression] valgrind error in count_nonzero_bytes since r10-2101
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94187 --- Comment #13 from David Binderman --- (In reply to David Binderman from comment #10) > There are about 5,800 Fortran source code files, about 16,100 C++ > and about 35,800 C source code files. That's a lot. > > I'll start with Fortran, then add in C++ then C and see how I get on. Fortran has be done, C++ is just about possible, but C consumes days of processor time. I've reported all the bugs I found for all three languages, but I think from now on I'll just do incremental testing i.e. only test new source code files. Something like $ find ~/gcc/trunk/gcc/testsuite -name \*.c -newer_than -print | sort > file.c.list $ for i in `cat file.c.list` do echo $i valgrind_C_compiler -c -O3 $i done Not ideal, but about as much as I can achieve until I get access to faster processors.
[Bug debug/94323] [10 Regression] g++: error: x.cpp: ‘-fcompare-debug’ failure since r10-7359-g6e771c087b10d5b730240ea35478eab8694c9c5d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94323 Jakub Jelinek changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- The cause is again DEBUG_BEGIN_STMTs. cp_parser_statement_expr's 4941 return cp_expr (expr, combined_loc); now calls protected_set_expr_location on expr, which for -g0 is a CLEANUP_POINT_EXPR, but with -g is STATEMENT_LIST which contains a DEBUG_BEGIN_STMT and that CLEANUP_POINT_EXPR. protected_set_expr_location will do: 5147 if (CAN_HAVE_LOCATION_P (t)) 5148SET_EXPR_LOCATION (t, loc); so overrides EXPR_LOCATION on the CLEANUP_POINT_EXPR, but in the -g case doesn't. Do we want protected_set_expr_location to handle STATEMENT_LISTs that only contain a single non-DEBUG_* stmt by recursing into that?
[Bug d/94315] [10 regression] new tests gdc.dg/pr93038.d and gdc.dg/pr93038b.d in r10-7320 fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94315 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Priority|P3 |P4
[Bug fortran/94331] New: Bind(C) corrupts array descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94331 Bug ID: 94331 Summary: Bind(C) corrupts array descriptors Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 48119 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48119=edit Fortran code demonstrating problems. Hi all! Call to bind(c) procedure corrupts array descriptor overwriting array bounds. in: GNU Fortran (GCC) 10.0.1 20200324 (experimental) Also in 9 but it's too buggy there to be relevant. Thank you very much. Best regards, José Rui
[Bug fortran/94331] Bind(C) corrupts array descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94331 --- Comment #1 from José Rui Faustino de Sousa --- Created attachment 48120 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48120=edit C code demonstrating problems.
[Bug tree-optimization/94131] [10 Regression] ICE: tree check: expected integer_cst, have plus_expr in get_len, at tree.h:5927 since r10-2814-g22fca489eaf98f26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94131 Jeffrey A. Law changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #7 from Jeffrey A. Law --- Fixed on the trunk.
[Bug tree-optimization/94131] [10 Regression] ICE: tree check: expected integer_cst, have plus_expr in get_len, at tree.h:5927 since r10-2814-g22fca489eaf98f26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94131 --- Comment #6 from CVS Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:05c13c439903eb78f109bcab62fd9a74f03a3c9b commit r10-7378-g05c13c439903eb78f109bcab62fd9a74f03a3c9b Author: Martin Sebor Date: Wed Mar 25 09:39:50 2020 -0600 PR tree-optimization/94131 - ICE on printf with a VLA string and -fno-tree-ccp gcc/testsuite/ChangeLog: PR tree-optimization/94131 * gcc.dg/pr94131.c: New test. gcc/ChangeLog: PR tree-optimization/94131 * gimple-fold.c (get_range_strlen_tree): Fail for variable-length types and decls. * tree-ssa-strlen.c (get_range_strlen_dynamic): Avoid assuming types have constant sizes.
[Bug target/81594] Optimize PowerPC vector set and store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81594 --- Comment #6 from Michael Meissner --- If you look at the original patch, it did try to do this optimization. When I looked at it some time later, the combiner no longer generated the sequence because it thought it was slower (due to length, etc.). You could spend a lot of time tuning the code so eventually the combiner will generate it again, but it was simpler to just put the peephole in to catch the cases that show up. If you want to take on the bug and do it earlier, go ahead. A peephole2 might not catch all uses, but it prevents whack-a-mole, where a change causes other code generation changes down the pike. Note, the original patch was written in the power8 time frame, and it would need to be adjust to power9 and future systems now (i.e. the patch only does the splitting if the value is a FPR or GPR, while in power9 it could be a traditional Altivec register). However, the splitter uses reload_completed that you always seem to object to. It could be done before register allocation, but then you would need to make sure that no other pass recombines the two separate items back into a vector once again.
[Bug other/94330] New: No warning if jobserver not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94330 Bug ID: 94330 Summary: No warning if jobserver not available Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: rdiezmail-gcc at yahoo dot de Target Milestone: --- If you pass -flto=jobserver , and the jobserver file descriptors are not actually available, you get no warning whatsoever from GCC. GNU Make does try to help in this scenario with the following warning: make[1]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. Without such a warning, it is really easy to miss the opportunity to parallelise the build. In fact, GCC seems to use 2 threads in this scenario, which misleads you into thinking that the option is working correctly, when in fact is not using all other CPU cores. More context on this issue is here: https://lists.gnu.org/archive/html/help-make/2020-02/msg0.html https://gcc.gnu.org/legacy-ml/gcc-help/2020-02/msg00069.html
[Bug debug/94326] g++: error: pack.ii: ‘-fcompare-debug’ failure (length)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94326 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-03-25
[Bug c/94322] Detected memory leaks while using clang AddressSanitizer to build GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94322 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-03-25 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug target/94317] gcc/config/arm/arm_mve.h:13907: strange assignment ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94317 --- Comment #8 from SRINATH PARVATHANENI --- Hi David, >>Can the author please indicate where the test cases for this code >>are in the gcc trunk testsuite. I'll give them some exercise. Christophe wrote: > There are lots of tests under gcc.target/arm/mve, but I think all them just > check that the generated code contains the instruction we expect to generate > from the intrinsic. (All of them have dg-do compile). Everything Christophe mentioned above is correct, expect for all them having "dg-do compile", Monday a patch was posted by Andre to changes tests to assemble. ``` commit 962406639c0ca9f0d948c843ad2a1ca5b17806da Author: Andre Vieira Date: Mon Mar 23 12:07:28 2020 + testsuite, arm: Change tests to assemble ``` >In the past I contributed Neon intrinsics executable tests (see >gcc.target/aarch64/advsimd-intrinsics) which caught several corner-case bugs. >It would probably be good to have similar things for MVE, but that's a huge >task. Thanks Christophe, I will check that. Regards, SRI.
[Bug target/94317] gcc/config/arm/arm_mve.h:13907: strange assignment ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94317 --- Comment #7 from David Binderman --- (In reply to Christophe Lyon from comment #6) > There are lots of tests under gcc.target/arm/mve, About 2,400 C source code files. > In the past I contributed Neon intrinsics executable tests (see > gcc.target/aarch64/advsimd-intrinsics) which caught several corner-case bugs. Sounds good. There are about 460 C source code files under that directory. > It would probably be good to have similar things for MVE, but that's a huge > task. Would it be enough to prioritise some of the more popular cases and write tests for those ? Is MVE bigger or smaller than Neon intrinsics ?
[Bug fortran/93484] [8/9/10 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1120 since r7-4028-g87c9fca50cbe7ca9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93484 --- Comment #6 from CVS Commits --- The releases/gcc-8 branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:2cc686897cc4d9935d4c8302af67565fa54c0aec commit r8-10142-g2cc686897cc4d9935d4c8302af67565fa54c0aec Author: Mark Eggleston Date: Wed Mar 25 15:10:03 2020 + fortran: ICE using undeclared symbol in array constructor PR93484 Using undeclared symbol k in an expression in the following array constructor results in an ICE: print *, [real(x(k))] If the call to the intrinsic is not in a constructor a no IMPLICIT type error is reported and the ICE does not occur. Matching on an expression instead of an initialisation express an and not converting a MATCH_ERROR return value into MATCH_NO results in the no IMPLICIT error and no ICE. Note: Steven G. Kargl is the author of the changes except for the test cases. gcc/fortran/ChangeLog: Backport from master 2020-03-25 Mark Eggleston PR fortran/93484 * match.c (gfc_match_type_spec): Replace gfc_match_init_expr with gfc_match_expr. Return m if m is MATCH_NO or MATCH_ERROR. gcc/testsuite Backport from master 2020-03-25 Mark Eggleston PR fortran/93484 * gfortran.dg/pr93484_1.f90: New test. * gfortran.dg/pr93484_2.f90: New test.
[Bug middle-end/92046] Command line options (that are per-functions) are affecting --params which are global.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92046 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Martin Liška --- I'm recommending to close it, let's continue in PR92860.
[Bug middle-end/92046] Command line options (that are per-functions) are affecting --params which are global.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92046 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #8 from Martin Liška --- @Richi: Can you please mention the new option -fallow-store-data-races at https://gcc.gnu.org/gcc-10/changes.html?
[Bug target/94317] gcc/config/arm/arm_mve.h:13907: strange assignment ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94317 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #6 from Christophe Lyon --- There are lots of tests under gcc.target/arm/mve, but I think all them just check that the generated code contains the instruction we expect to generate from the intrinsic. (All of them have dg-do compile) In the past I contributed Neon intrinsics executable tests (see gcc.target/aarch64/advsimd-intrinsics) which caught several corner-case bugs. It would probably be good to have similar things for MVE, but that's a huge task.
[Bug c/94253] FAIL: gfortran.dg/bind_c_coms.f90 -O0 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94253 --- Comment #3 from John David Anglin --- Okay, the problem is the test lacks a '-fcommon' option. The default was changed here: 2019-11-20 Wilco Dijkstra PR85678 * common.opt (fcommon): Change init to 1. * doc/invoke.texi (-fcommon): Update documentation. This means almost all the places in the testsuite where we add '-fno-common' are unnecessary...
[Bug debug/94281] [8/9/10 Regression] g++: error: hash.cpp: ‘-fcompare-debug’ failure (length) since r8-5241-g8697bf9f46f36168
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94281 Jakub Jelinek changed: What|Removed |Added Attachment #48117|0 |1 is obsolete|| --- Comment #4 from Jakub Jelinek --- Created attachment 48118 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48118=edit gcc10-pr94281.patch While trying to simulate all the cases that the patch is meant to handle in the debugger (i.e. also outer_stmt being a GIMPLE_BIND and some debug stmts before and/or after that), I've discovered a bug in gimple_seq_last_nondebug_stmt where it would return NULL on a gimple_seq containing the GIMPLE_BIND followed by a DEBUG_BEGIN_STMT, while obviously it should return that GIMPLE_BIND instead. THis updated patch should fix that too.
[Bug sanitizer/94328] Logging of defects to file does not work with Asan and Ubsan combined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94328 Martin Liška changed: What|Removed |Added Status|WAITING |NEW --- Comment #7 from Martin Liška --- I can confirm that. It's related to fact that clang links sanitizer library statically, while GCC dynamically. $ ldd a.out | grep san libasan.so.6 => /home/marxin/bin/gcc2/lib64/libasan.so.6 (0x77601000) libubsan.so.1 => /home/marxin/bin/gcc2/lib64/libubsan.so.1 (0x7693e000) And there's some clashing of common_flags()->log_path. @Jakub: I remember we had one similar problem..
[Bug target/94317] gcc/config/arm/arm_mve.h:13907: strange assignment ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94317 --- Comment #5 from David Binderman --- I am not sure how much testing this code got before it was put into git. Can the author please indicate where the test cases for this code are in the gcc trunk testsuite. I'll give them some exercise. In the somewhat worrying event that there are no test cases, then perhaps it might be wise to add some to aid future developers.
[Bug sanitizer/94328] Logging of defects to file does not work with Asan and Ubsan combined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94328 --- Comment #6 from Martin Liška --- Ok, let me take a look.
[Bug sanitizer/94328] Logging of defects to file does not work with Asan and Ubsan combined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94328 Gordon Mc changed: What|Removed |Added Known to fail||9.2.0 --- Comment #5 from Gordon Mc --- Also just tested with newer GCC 9.2.0 - behavior there is the same as 6.2 and 7.3, in that the ubsan logging goes to stderr instead of the log file, in the combined sanitizer build.
[Bug sanitizer/94328] Logging of defects to file does not work with Asan and Ubsan combined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94328 --- Comment #4 from Gordon Mc --- This seems to be specific to GCC - I just tested with clang 7.1.0, and it behaves as I would expect it to (both Asan and Ubsan content went to the UABSAN log file - none went to stderr)
[Bug sanitizer/94328] Logging of defects to file does not work with Asan and Ubsan combined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94328 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-03-25 Ever confirmed|0 |1 --- Comment #3 from Martin Liška --- Can you please test if clang suffers from the same problem? If so, please create a bug to upstream library: https://github.com/google/sanitizers/issues
[Bug sanitizer/94325] [8/9/10 Regression] UBSAN: "invalid vptr" false positive for virtual inheritance with -fno-sanitize-recover=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94325 Martin Liška changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||nathan at gcc dot gnu.org Keywords|needs-bisection | Summary|[UBSAN] "invalid vptr" |[8/9/10 Regression] UBSAN: |false positive for virtual |"invalid vptr" false |inheritance with|positive for virtual |-fno-sanitize-recover=all |inheritance with ||-fno-sanitize-recover=all Known to fail||8.4.0 --- Comment #2 from Martin Liška --- Started with my r8-4602-g896f6b3dfa6fb337109f97bed8d74c1e030c965e. Anyway, a help from C++ maintainer is more than welcomed.
[Bug debug/94329] gcc-9: error: use_only.f90: ‘-fcompare-debug’ failure (length)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94329 Martin Liška changed: What|Removed |Added Priority|P3 |P2 Last reconfirmed||2020-03-25 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug debug/94329] New: gcc-9: error: use_only.f90: ‘-fcompare-debug’ failure (length)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94329 Bug ID: 94329 Summary: gcc-9: error: use_only.f90: ‘-fcompare-debug’ failure (length) Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- Fails since GCC 4.9.0: $ cat use_only.f90 SUBROUTINE r_to_s1b ( s, hinv ) REAL hinv(:,:) DO I=1,3 DO J=1,3 S = hinv(i,j) END DO END DO END $ gcc -Werror -fcompare-debug -O1 -fno-tree-loop-optimize -fwrapv -c use_only.f90 gcc: error: use_only.f90: ‘-fcompare-debug’ failure (length)
[Bug debug/94281] [8/9/10 Regression] g++: error: hash.cpp: ‘-fcompare-debug’ failure (length) since r8-5241-g8697bf9f46f36168
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94281 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Jakub Jelinek --- Created attachment 48117 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48117=edit gcc10-pr94281.patch Untested fix.
[Bug sanitizer/94328] Logging of defects to file does not work with Asan and Ubsan combined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94328 --- Comment #2 from Gordon Mc --- Created attachment 48116 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48116=edit Script to run the testcase
[Bug sanitizer/94328] Logging of defects to file does not work with Asan and Ubsan combined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94328 --- Comment #1 from Gordon Mc --- Created attachment 48115 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48115=edit Makefile
[Bug sanitizer/94328] New: Logging of defects to file does not work with Asan and Ubsan combined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94328 Bug ID: 94328 Summary: Logging of defects to file does not work with Asan and Ubsan combined Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: gmc at synopsys dot com 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: --- Created attachment 48114 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48114=edit Source code for testcase Compile only with the Address Sanitizer, and the resulting exe can log its defects to file via the log_path setting in ASAN_OPTIONS Ditto for only the Undefined Sanitizer, and using the log_path in UBSAN_OPTIONS Combine the 2 though (the only 2 sanitizers that do seem to be allowed to coexist) and the logging does not seem to work correctly : ASAN_OPTIONS seems to be ignored altogether - and when I set UBSAN_OPTIONS the designated log_path is used ONLY for the Address Sanitizer (incl LeakSanitizer) defects - the Undefined Behavior defects go only to stderr, not to the log file. See attached files : "test.cx" is the source, "make all" builds 3 exes, "run" runs each, with log_path being set via the *_OPTIONS settings Thanks for any help in addressing this. Gordon
[Bug fortran/93484] [8/9/10 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1120 since r7-4028-g87c9fca50cbe7ca9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93484 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:dff885cdc00bbdccb5bb6277e4711093e3bbad1e commit r9-8416-gdff885cdc00bbdccb5bb6277e4711093e3bbad1e Author: Mark Eggleston Date: Wed Mar 25 13:43:23 2020 + fortran: ICE using undeclared symbol in array constructor PR93484 Using undeclared symbol k in an expression in the following array constructor results in an ICE: print *, [real(x(k))] If the call to the intrinsic is not in a constructor a no IMPLICIT type error is reported and the ICE does not occur. Matching on an expression instead of an initialisation express an and not converting a MATCH_ERROR return value into MATCH_NO results in the no IMPLICIT error and no ICE. Note: Steven G. Kargl is the author of the changes except for the test cases. gcc/fortran/ChangeLog: Backport from master 2020-03-25 Mark Eggleston PR fortran/93484 * match.c (gfc_match_type_spec): Replace gfc_match_init_expr with gfc_match_expr. Return m if m is MATCH_NO or MATCH_ERROR. gcc/testsuite Backport from master 2020-03-25 Mark Eggleston PR fortran/93484 * gfortran.dg/pr93484_1.f90: New test. * gfortran.dg/pr93484_2.f90: New test.
[Bug c++/94319] gcc/cp/coroutines.cc:2654: strange assignment ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94319 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Iain Sandoe --- so fixed
[Bug fortran/94327] Bind(c) argument attributes are incorrectly set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94327 --- Comment #1 from José Rui Faustino de Sousa --- Created attachment 48113 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48113=edit C code demonstrating problems.
[Bug c++/94319] gcc/cp/coroutines.cc:2654: strange assignment ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94319 --- Comment #3 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:83dfa06cb5cff143113cb7d632c90a40edefade8 commit r10-7376-g83dfa06cb5cff143113cb7d632c90a40edefade8 Author: Iain Sandoe Date: Wed Mar 25 12:04:58 2020 + coroutines: Fix missing dereference (PR94319). Fix a typo. gcc/cp/ChangeLog: 2020-03-25 Iain Sandoe PR c++/94319 * coroutines.cc (captures_temporary): Fix a missing dereference.
[Bug fortran/94327] New: Bind(c) argument attributes are incorrectly set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94327 Bug ID: 94327 Summary: Bind(c) argument attributes are incorrectly set Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 48112 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48112=edit Fortran code demonstrating problems. Hi all! Argument attributes should match the dummy argument attribute not the effective argument's. Found in both: GNU Fortran (GCC) 9.3.1 20200324 and GNU Fortran (GCC) 10.0.1 20200324 (experimental) Thank you very much. Best regards, José Rui
[Bug sanitizer/94325] [UBSAN] "invalid vptr" false positive for virtual inheritance with -fno-sanitize-recover=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94325 Martin Liška changed: What|Removed |Added Known to fail||10.0, 9.3.0 Known to work||7.4.0 Ever confirmed|0 |1 Keywords||needs-bisection Last reconfirmed||2020-03-25 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Confirmed, I'm bisecting that.
[Bug debug/94326] g++: error: pack.ii: ‘-fcompare-debug’ failure (length)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94326 Martin Liška changed: What|Removed |Added Priority|P3 |P2
[Bug debug/94326] New: g++: error: pack.ii: ‘-fcompare-debug’ failure (length)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94326
Bug ID: 94326
Summary: g++: error: pack.ii: ‘-fcompare-debug’ failure
(length)
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
This one is very old (at least GCC 4.8.0):
$ cat pack.ii
template class A {
const int _fn1() { return 0; }
public:
template void m_fn2(_Kt) { m_fn1(); }
};
class B {
A<> _M_t;
public:
template auto m_fn3(_Kt p1) -> decltype(_M_t.m_fn2(p1)) {
_M_t.m_fn2(p1);
}
};
struct C {};
void operator<(C, int) {
B a;
a.m_fn3(C{});
}
$ g++ pack.ii -c -fcompare-debug -std=c++11
pack.ii: In instantiation of ‘const int& A< >::m_fn1()
[with = int]’:
pack.ii:5:45: required from ‘void A< >::m_fn2(_Kt)
[with _Kt = C; = int]’
pack.ii:12:15: required from ‘decltype
(((B*)this)->B::_M_t.A<>::m_fn2<_Kt>(p1)) B::m_fn3(_Kt) [with _Kt = C; decltype
(((B*)this)->B::_M_t.A<>::m_fn2<_Kt>(p1)) = void]’
pack.ii:18:14: required from here
pack.ii:2:31: warning: returning reference to temporary [-Wreturn-local-addr]
2 | const int _fn1() { return 0; }
| ^
g++: error: pack.ii: ‘-fcompare-debug’ failure (length)
[Bug target/94317] gcc/config/arm/arm_mve.h:13907: strange assignment ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94317 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug target/94317] gcc/config/arm/arm_mve.h:13907: strange assignment ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94317 Martin Liška changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |srinath.parvathaneni at arm dot co ||m --- Comment #4 from Martin Liška --- Please create a bugzilla account with @gcc.gnu.org domain.
[Bug lto/94311] LTO produces line info entries with invalid line numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311 --- Comment #4 from Richard Biener --- (In reply to Mark Wielaard from comment #3) > (In reply to Richard Biener from comment #1) > > Err, but isn't this interpreting the dwarf from 'date'? So doesn't this > > mean that valgrind is "miscompiled" with --enable-lto rather than wrong > > debug? > > The error message isn't very clear, but valgrind also reads its own > code/binary (which is inserted into the process), which is build with LTO. > It is that library that has the wrong line numbers. Which can also be seen > in gdb: > > ./install/bin/valgrind -q date ==48528== warning: Can't handle line > info entry with line number 177277754 greater than 1048575 ==48528== (Nb: > this message is only shown once) ==48528== warning: Can't handle inlined > call info entry with line number 177277750 greater than 1048575 ==48528== > (Nb: this message is only shown once) > > Double check that valgrind debug info reader is correct: > gdb ./.in_place/memcheck-amd64-linux > Reading symbols from ./.in_place/memcheck-amd64-linux... > (gdb) info line guest_amd64_toIR.c:177277754 Line number 177277754 is > out of range for "priv/guest_amd64_toIR.c". > Line 177277754 of "priv/guest_amd64_toIR.c" starts at address > 0x58069001 and ends at 0x58069005 > . > (gdb) > You can also try: > (gdb) disass /s dis_ESC_0F__SSE4 > and you zillions of useless lines. > > If needed, you can ask valgrind to show more info about what it is > doing/reading by doing e.g. > ./install/bin/valgrind -v -v -v -v -d -d -d -d --debug-dump=line date > |& tee d.out So the error must be visible with readelf as well. Can you upload the valgrind binary somewhere (does the issue only reproduce with separate debug and/or dwz?)? It's also a quite odd error unless the whole .debug_line section looks garbled.
[Bug target/94317] gcc/config/arm/arm_mve.h:13907: strange assignment ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94317 --- Comment #3 from Srinath Parvathaneni --- Thanks David for reporting this issue, I'm working on it. Could someone assign this to me, I could not do it myself. Regards, SRI.
[Bug c++/94325] New: [UBSAN] "invalid vptr" false positive for virtual inheritance with -fno-sanitize-recover=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94325 Bug ID: 94325 Summary: [UBSAN] "invalid vptr" false positive for virtual inheritance with -fno-sanitize-recover=all Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jaroslaw.melzer.gcc at gmail dot com Target Milestone: --- Created attachment 48111 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48111=edit reproducer code See attached: ubsan-gcc.ii Program ubsan-gcc compiled with options: g++ -fsanitize=undefined -fno-sanitize-recover=all ubsan-gcc.ii exits with following false positive: ubsan-gcc.cpp:12:7: runtime error: member call on address 0x7ffcdd8c9800 which does not point to an object of type 'DE' 0x7ffcdd8c9800: note: object has invalid vptr 17 56 00 00 00 00 00 00 00 00 00 00 00 76 43 93 7b 4b c2 bf 30 71 eb 2f 17 56 00 00 e3 41 18 cc ^~~ invalid vptr May be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87095 This error doesn't manifest without -fno-sanitize-recover=all gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:hsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.2.1-9ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2)
[Bug fortran/94324] New: [10 regression] gfortran.dg/default_format_1.f90 etc. FAIL on 32-bit Solaris/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94324 Bug ID: 94324 Summary: [10 regression] gfortran.dg/default_format_1.f90 etc. FAIL on 32-bit Solaris/x86 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: i386-pc-solaris2.11 I just remembered that between 20191031 (r277679) and 20191101 (r277705) a couple of Fortran tests regressed on 32-bit Solaris/x86: +FAIL: gfortran.dg/default_format_1.f90 -O0 execution test +FAIL: gfortran.dg/default_format_1.f90 -O1 execution test +FAIL: gfortran.dg/default_format_1.f90 -O2 execution test +FAIL: gfortran.dg/default_format_1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test +FAIL: gfortran.dg/default_format_1.f90 -O3 -g execution test +FAIL: gfortran.dg/default_format_1.f90 -Os execution test Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG STOP 6 #2 0x08051851 in MAIN__ () at /vol/gcc/src/hg/master/local/gcc/testsuite/gfortran.dg/default_format_1.f90:20 20if (test (1.0_8, 0) /= 0) STOP 6 +FAIL: gfortran.dg/fmt_g0_1.f08 -O0 execution test +FAIL: gfortran.dg/fmt_g0_1.f08 -O1 execution test +FAIL: gfortran.dg/fmt_g0_1.f08 -O2 execution test +FAIL: gfortran.dg/fmt_g0_1.f08 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test +FAIL: gfortran.dg/fmt_g0_1.f08 -O3 -g execution test +FAIL: gfortran.dg/fmt_g0_1.f08 -Os execution test STOP 3 #2 0x0805143d in MAIN__ () at /vol/gcc/src/hg/master/local/gcc/testsuite/gfortran.dg/fmt_g0_1.f08:11 11 if (buffer.ne.":0.1:") STOP 3 (gdb) p buffer $1 = ':0.', '3' , '2:', ' ' +FAIL: gfortran.dg/round_4.f90 -O0 execution test +FAIL: gfortran.dg/round_4.f90 -O1 execution test +FAIL: gfortran.dg/round_4.f90 -O2 execution test +FAIL: gfortran.dg/round_4.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test +FAIL: gfortran.dg/round_4.f90 -O3 -g execution test +FAIL: gfortran.dg/round_4.f90 -Os execution test STOP 15 #2 0x08051f41 in MAIN__ () at /vol/gcc/src/hg/master/local/gcc/testsuite/gfortran.dg/round_4.f90:100 100 if (rnd10 .and. (r10p /= ref10u .or. r10m /= -ref10u)) STOP 15 (gdb) p rnd10 $1 = .TRUE. (gdb) p r10p $2 = 0.15551 (gdb) p ref10u $3 = 0.10001 (gdb) p r10m $4 = -0.15551 (gdb) p ref10u $5 = 0.10001 Since I found nothing in the above revision range that might have caused this and the failures only occur on Solaris 11.5 Beta, but not on Solaris 11.4, I suspect that the cause of the failure lies somewhere with the OS (libc or libm). However, given that I know nothing about fortran, it would be very helpful to have some guidance on where to look.
[Bug fortran/94324] [10 regression] gfortran.dg/default_format_1.f90 etc. FAIL on 32-bit Solaris/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94324 Rainer Orth changed: What|Removed |Added Target Milestone|--- |10.0
[Bug debug/94323] New: [10 Regression] g++: error: x.cpp: ‘-fcompare-debug’ failure since r10-7359-g6e771c087b10d5b730240ea35478eab8694c9c5d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94323
Bug ID: 94323
Summary: [10 Regression] g++: error: x.cpp: ‘-fcompare-debug’
failure since
r10-7359-g6e771c087b10d5b730240ea35478eab8694c9c5d
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, jason at gcc dot gnu.org
Target Milestone: ---
Since the revision I see:
$ cat x.cpp
volatile int a;
void fn1() {
({ a; });
}
$ g++ x.cpp -O2 -fcompare-debug -c
g++: error: x.cpp: ‘-fcompare-debug’ failure
[Bug debug/94323] [10 Regression] g++: error: x.cpp: ‘-fcompare-debug’ failure since r10-7359-g6e771c087b10d5b730240ea35478eab8694c9c5d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94323 Martin Liška changed: What|Removed |Added Known to fail||10.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Known to work||9.3.0 Target Milestone|--- |10.0 Last reconfirmed||2020-03-25
[Bug c/94322] Detected memory leaks while using clang AddressSanitizer to build GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94322 Martin Liška changed: What|Removed |Added Priority|P3 |P5 CC||marxin at gcc dot gnu.org Blocks||86656 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656 [Bug 86656] [meta-bug] Issues found with -fsanitize=address
[Bug lto/94259] --without-zstd seems to have no effect and links libzstd if available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94259 --- Comment #8 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:68c4570a4dea8ed6fefaea50943fb74ea8f78319 commit r10-7375-g68c4570a4dea8ed6fefaea50943fb74ea8f78319 Author: Martin Liska Date: Wed Mar 25 13:34:53 2020 +0100 Do not error about missing zstd unless --with-zstd. PR lto/94259 * configure.ac: Report error only when --with-zstd is used. * configure: Regenerate.
[Bug fortran/94289] Assumed-rank array bounds resuscitate on the second call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94289 --- Comment #1 from José Rui Faustino de Sousa --- Hi all! My first comment is not very clear so to elaborate a bit. For assumed-rank arrays no temporary array descriptor with the correct bounds is created like it is for assumed-shape arrays. So although the array bounds are correctly reported by the lbound, ubound and shape intrinsics the underlying array descriptor is still the original one. And since it is the original array descriptor, not a temporary with correct array bounds, that is passed down the call chain subsequent procedures will get a descriptor with the wrong bounds. This will probably imply adding assumed-rank arrays to the deferred initialization list, which is already done (I guess accidentally) for bind(c) procedures. I guess by removing the condition on the first if clause in gfc_build_dummy_array_decl and, hopefully, then in the "type_of_array" switch in gfc_trans_deferred_vars. This will imply also solving PR93957. Best regards, José Rui
[Bug c/94322] Detected memory leaks while using clang AddressSanitizer to build GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94322 --- Comment #1 from Richard Biener --- We're quite lazy in freeing all memory from generator tools (genhooks as you report) but there are also known leaks in the driver when it comes to command-line processing. That is, not all memory leaks are considered equal.
[Bug c/94322] New: Detected memory leaks while using clang AddressSanitizer to build GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94322 Bug ID: 94322 Summary: Detected memory leaks while using clang AddressSanitizer to build GCC Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: haoxintu at gmail dot com Target Milestone: --- Hi, I use clang with AddressSanitizer and detected memory leaks while building GCC. The SUMMARY are: = ==7174==ERROR: LeakSanitizer: detected memory leaks Direct leak of 112 byte(s) in 1 object(s) allocated from: #0 0x4debb0 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x4debb0) #1 0x521a45 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x521a45) #2 0x51e2a9 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x51e2a9) #3 0x51a8e5 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x51a8e5) #4 0x7f20623dc82f (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) Direct leak of 23 byte(s) in 1 object(s) allocated from: #0 0x4de998 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x4de998) #1 0x5219c1 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x5219c1) #2 0x521b7d (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x521b7d) #3 0x51bb89 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x51bb89) #4 0x7f20623dc82f (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) Indirect leak of 13368 byte(s) in 456 object(s) allocated from: #0 0x4de998 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x4de998) #1 0x5219c1 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x5219c1) #2 0x521b7d (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x521b7d) #3 0x51a9f0 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x51a9f0) #4 0x7f20623dc82f (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) Indirect leak of 8168 byte(s) in 1 object(s) allocated from: #0 0x4debb0 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x4debb0) #1 0x521a45 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x521a45) #2 0x520384 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x520384) #3 0x51f5af (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x51f5af) #4 0x51ab44 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x51ab44) #5 0x7f20623dc82f (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) Indirect leak of 7296 byte(s) in 456 object(s) allocated from: #0 0x4de998 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x4de998) #1 0x5219c1 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x5219c1) #2 0x51a9e5 (/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc/build/genhooks+0x51a9e5) #3 0x7f20623dc82f (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) SUMMARY: AddressSanitizer: 28967 byte(s) leaked in 915 allocation(s). Makefile:2504: recipe for target 's-tm-texi' failed make[3]: *** [s-tm-texi] Error 1 make[3]: *** Waiting for unfinished jobs 31 warnings generated. 19 warnings generated. rm fsf-funding.pod gcov.pod gpl.pod cpp.pod gcc.pod make[3]: Leaving directory '/home/haoxin/corpus-compilers/clang-build-gcc8/build/gcc' Makefile:4617: recipe for target 'all-stage1-gcc' failed make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory '/home/haoxin/corpus-compilers/clang-build-gcc8/build' Makefile:24352: recipe for target 'stage1-bubble' failed make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory '/home/haoxin/corpus-compilers/clang-build-gcc8/build' Makefile:944: recipe for target 'all' failed Here are my instructions: $export FUZZ_FLAGS="-O2 -fno-omit-frame-pointer -g -fsanitize=address -fsanitize-coverage=edge,trace-pc-guard,indirect-calls,trace-cmp,trace-div,trace-gep" $CC="clang $FUZZ_FLAGS" CXX="clang++ $FUZZ_FLAGS" ../configure $make -j4 Without FUZZ_FLAGS, clang can build GCC well. I used GCC-8.1.0, clang-6.0, and Ubuntu16.04.
[Bug lto/94311] LTO produces line info entries with invalid line numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311 --- Comment #3 from Mark Wielaard --- (In reply to Richard Biener from comment #1) > Err, but isn't this interpreting the dwarf from 'date'? So doesn't this > mean that valgrind is "miscompiled" with --enable-lto rather than wrong > debug? The error message isn't very clear, but valgrind also reads its own code/binary (which is inserted into the process), which is build with LTO. It is that library that has the wrong line numbers. Which can also be seen in gdb: ./install/bin/valgrind -q date ==48528== warning: Can't handle line info entry with line number 177277754 greater than 1048575 ==48528== (Nb: this message is only shown once) ==48528== warning: Can't handle inlined call info entry with line number 177277750 greater than 1048575 ==48528== (Nb: this message is only shown once) Double check that valgrind debug info reader is correct: gdb ./.in_place/memcheck-amd64-linux Reading symbols from ./.in_place/memcheck-amd64-linux... (gdb) info line guest_amd64_toIR.c:177277754 Line number 177277754 is out of range for "priv/guest_amd64_toIR.c". Line 177277754 of "priv/guest_amd64_toIR.c" starts at address 0x58069001 and ends at 0x58069005 . (gdb) You can also try: (gdb) disass /s dis_ESC_0F__SSE4 and you zillions of useless lines. If needed, you can ask valgrind to show more info about what it is doing/reading by doing e.g. ./install/bin/valgrind -v -v -v -v -d -d -d -d --debug-dump=line date |& tee d.out
[Bug d/94321] gdc.dg/pr92216.d FAILs on 32-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94321 Rainer Orth changed: What|Removed |Added Target Milestone|--- |10.0
[Bug d/94321] New: gdc.dg/pr92216.d FAILs on 32-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94321 Bug ID: 94321 Summary: gdc.dg/pr92216.d FAILs on 32-bit targets Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: i386-pc-solaris2.11, sparc-sun-solaris2.11 As originally reported in https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542177.html [which didn't get Cc'ed to you due to the abominable header rewriting]: The new gdc.dg/pr92216.d testcase FAILs on 32-bit Solaris/SPARC and x86 (and, I suppose, on every non-64-bit target): +FAIL: gdc.dg/pr92216.d -O0 scan-assembler _DT16_D7imports7pr922161B8__mixin24getSMFZPv[: \\t\\n] +FAIL: gdc.dg/pr92216.d -O0 -frelease scan-assembler _DT16_D7imports7pr922161B8__mixin24getSMFZPv[: \\t\\n] +FAIL: gdc.dg/pr92216.d -O0 -frelease -g scan-assembler _DT16_D7imports7pr922161B8__mixin24getSMFZPv[: \\t\\n] +FAIL: gdc.dg/pr92216.d -O0 -g scan-assembler _DT16_D7imports7pr922161B8__mixin24getSMFZPv[: \\t\\n] Same at -O[1-3s]. While the 64-bit version contains the expected _DT16_D7imports7pr922161B8__mixin24getSMFZPv the 32-bit one has _DT8_D7imports7pr922161B8__mixin24getSMFZPv I can't tell for certain if it's enough to allow for those two variants or if more is needed. Btw., I noticed that binutils 2.34 c++filt -s dlang cannot demangle those symbols. Is this expected?
[Bug lto/91027] [10 regression] SEGV in hash_table::find_slot_with_hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91027 Rainer Orth changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #14 from Rainer Orth --- Unfortunately, the bug is not fixed: while the original SEGV doesn't happen any longer, I now see the ICE originally reported in Comment #6 on both i386-pc-solaris2.11 and sparc-sun-solaris2.11: FAIL: gdc.dg/lto/ltotests d_lto_ltotests_0.o-d_lto_ltotests_1.o link, -O0 -flto -flto-partition=none (internal compiler error) during IPA pass: pure-const^M lto1: internal compiler error: in get_odr_type, at ipa-devirt.c:1936^M 0x7c4dfb get_odr_type(tree_node*, bool)^M /vol/gcc/src/hg/master/local/gcc/ipa-devirt.c:1936^M 0x7cba63 build_type_inheritance_graph()^M /vol/gcc/src/hg/master/local/gcc/ipa-devirt.c:2283^M 0x822f83 symbol_table::remove_unreachable_nodes(__FILE*)^M /vol/gcc/src/hg/master/local/gcc/ipa.c:320^M 0x476fd7 read_cgraph_and_symbols(unsigned int, char const**)^M /vol/gcc/src/hg/master/local/gcc/lto/lto-common.c:2915^M 0x459043 lto_main()^M /vol/gcc/src/hg/master/local/gcc/lto/lto.c:625^M
[Bug c++/94319] gcc/cp/coroutines.cc:2654: strange assignment ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94319 --- Comment #2 from Iain Sandoe --- (In reply to David Binderman from comment #1) > git blame says: > > 49789fd08378 (Iain Sandoe 2020-01-18 11:54:46 + 2654) do_subtree = 0; > > Adding author. indeed looks like a typo. thanks
[Bug lto/94320] [OpenMP][Offloading] lto1 ICE during IPA pass: inline – offline_size at gcc/ipa-inline-analysis.c:453
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94320 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Perhaps related to PR92357? I'm stuck there, tried 2020-02-07 Jakub Jelinek PR ipa/92357 * symtab.c (symtab_node::get_partitioning_class): Don't return SYMBOL_DUPLICATE for DECL_ONE_ONLY symbols if lto_stream_offload_p. --- gcc/symtab.c.jj 2020-01-15 11:05:19.589136168 +0100 +++ gcc/symtab.c2020-02-07 19:57:55.625108414 +0100 @@ -2003,6 +2003,7 @@ symtab_node::get_partitioning_class (voi if (DECL_ONE_ONLY (decl) && !force_output && !forced_by_abi + && !lto_stream_offload_p && !used_from_object_file_p ()) return SYMBOL_DUPLICATE; but it didn't work out. I'm afraid we need to actually implement properly the OpenMP 5.0 automatic omp declare target discovery and before IPA run perhaps another iteration of that and make sure that if we offload something, we either offload everything it refers to too (unless DECL_EXTERNAL), or diagnose it.
[Bug lto/94320] New: [OpenMP][Offloading] lto1 ICE during IPA pass: inline – offline_size at gcc/ipa-inline-analysis.c:453
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94320
Bug ID: 94320
Summary: [OpenMP][Offloading] lto1 ICE during IPA pass: inline
– offline_size at gcc/ipa-inline-analysis.c:453
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, openmp
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
May or may not be related to PR 92029
Still reducing the test case. When compiling with "-fopenmp -O0" it works, but
with "-fopenmp -O1" the offloading-compiler (AMDGCN or – has here – nvptx) ICEs
with:
during IPA pass: inline
lto1: internal compiler error: Segmentation fault
0xbdb6ff crash_signal
/net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/src/gcc-mainline/gcc/toplev.c:328
0x98074f offline_size
/net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/src/gcc-mainline/gcc/ipa-inline-analysis.c:453
0x980b58 growth_positive_p(cgraph_node*, cgraph_edge*, int)
/net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/src/gcc-mainline/gcc/ipa-inline-analysis.c:549
0x138610f want_inline_function_to_all_callers_p
/net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/src/gcc-mainline/gcc/ipa-inline.c:1088
0x138c37f ipa_inline
/net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/src/gcc-mainline/gcc/ipa-inline.c:2752
0x138d099 execute
/net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/src/gcc-mainline/gcc/ipa-inline.c:3091
It fails in ipa-inline-analysis.c's:
offline_size (struct cgraph_node *node, ipa_size_summary *info)
{
if (!DECL_EXTERNAL (node->decl))
{
if (node->will_be_removed_from_program_if_no_direct_calls_p ())
return info->size;
as info == NULL and decl is " get (node);
And ->get returns:
369 return exists (node) ? (*m_vector)[node->get_summary_id ()] : NULL;
[Bug c++/94314] [10 Regression] Optimizing mismatched new/delete pairs since r10-2106-g6343b6bf3bb83c87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94314 --- Comment #5 from Marc Glisse --- I don't think we need heavy machinery linking new and delete (and if we did I'd be tempted to store it in some global table rather than in the nodes). The most important case is the global replacable functions, for which we have a finite list, and for those a few checks like not matching array with non-array versions should do. For user overloads with attribute malloc (a gcc extension), I would go with heuristics like both/neither being class members, being members of the same class, etc. Although I am not quite sure how doable that is from the middle-end, how much of that information is still available (I think it is available in the mangled name, but demangling doesn't seem like a great idea).
