[Bug fortran/95366] [10/11 Regression] TYPE IS(character(*)) no longer matches since r10-3605-gf61e54e59cda5a2e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95366 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #2 from Thomas Koenig --- Mark, can you take this on?
[Bug libfortran/95313] Possible overflow in itoa_buf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95313 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org Last reconfirmed||2020-06-13 --- Comment #1 from Thomas Koenig --- I'll take a look.
[Bug middle-end/95276] [10/11 Regression] Amusing stringpop-overflow message building libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95276 --- Comment #11 from Thomas Koenig --- (In reply to Thomas Koenig from comment #10) > The libgfortran bug is now PR 95313 . Actually, the warning is a false positive, for our code. We never call write_z with an excessive length. So, what's left is to tell -Wstringop-overflow to shut up in a way that does not incur a run-time penalty.
[Bug libfortran/95313] Possible overflow in itoa_buf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95313 --- Comment #2 from CVS Commits --- The master branch has been updated by Thomas Kथà¤nig : https://gcc.gnu.org/g:0cfc34ad1293a5e19f1dc67c461c58d99222ac9d commit r11-1290-g0cfc34ad1293a5e19f1dc67c461c58d99222ac9d Author: Thomas Koenig Date: Sat Jun 13 10:04:33 2020 +0200 Disable -Wstringop-overflow warning after checking code path of caller. The warning that is disabled, only on this single line, has been inspected and found to be not applicable; it is known that the size of the buffer is safe. libgfortran/ChangeLog: 2020-06-13 Thomas Koenig PR libfortran/95313 * io/write.c (ztoa_big): Disable -Wstringop-overflow for one line.
[Bug libfortran/95313] Possible overflow in itoa_buf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95313 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Thomas Koenig --- The warning is not gone, closing.
[Bug fortran/95647] operator(.eq.) and operator(==) treated differently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647 --- Comment #3 from Thomas Koenig --- If we treat .eq. and == differently, that is an indication of a bug in the compiler itself.
[Bug target/95661] Code built with -m32 uses SSE2 instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95661 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #1 from Mikael Pettersson --- (In reply to Matt Emmerton from comment #0) > --with-bugurl=http://bugzilla.redhat.com/bugzilla That's a Red Hat compiler, with Red Hat modifications and configuration, and as --with-bugurl indicates, they're the ones you should report the bug to. > --with-arch_32=x86-64 This is what's causing SSE2 in 32-bit code. I think this needs to be --with-arch-32=i386, or the multilibs need to explicitly include i386, and then you could compile with -m32 -mcpu=i386.
[Bug target/95661] Code built with -m32 uses SSE2 instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95661 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Not a bug as GCC is configured to default to include sse2 for 32bits.
[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640 --- Comment #17 from Andrew Pinski --- (In reply to Steve Kargl from comment #13) > With a bit of work, someone could do > > Index: gcc/fortran/trans-types.c > === > --- gcc/fortran/trans-types.c (revision 280157) > +++ gcc/fortran/trans-types.c (working copy) > @@ -451,7 +451,7 @@ gfc_init_kinds (void) > continue; >if (mode != TYPE_MODE (float_type_node) > && (mode != TYPE_MODE (double_type_node)) > - && (mode != TYPE_MODE (long_double_type_node)) > + && (!flag_disable_real10 || mode != TYPE_MODE > (long_double_type_node)) > #if defined(HAVE_TFmode) && defined(ENABLE_LIBQUADMATH_SUPPORT) > && (mode != TFmode) > #endif It needs to be more complex than that as long double on most targets is NOT the 80bit (96bit or 128bit storage) IEEE FP type.
[Bug target/95661] Code built with -m32 uses SSE2 instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95661 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- And it is an intentional disto decision, because 32-bit kernels aren't supported (not even shipped) in RHEL and thus SSE2 is required. You can always use -march=i386 or -mno-sse etc. to override the defaults. E.g. in Fedora 32-bit CPUs are still supported and the configured compiler defaults to -march=i686 for 32-bit compilation.
[Bug c++/95663] New: static_cast checks for null even when the pointer is dereferenced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663
Bug ID: 95663
Summary: static_cast checks for null even when the pointer is
dereferenced
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jzwinck at gmail dot com
Target Milestone: ---
Consider this C++ code:
struct Base1
{
int x;
};
struct Base2
{
int y;
};
struct Derived : Base1, Base2
{
int get_y() const { return y; }
};
int field(Base2* base)
{
return static_cast(base)->y;
}
int getter(Base2* base)
{
return static_cast(base)->get_y();
}
Both field() and getter() produce this with -O2 or -O3:
testrdi, rdi
je .L2
mov eax, DWORD PTR [rdi]
ret
.L2:
mov eax, DWORD PTR ds:4
ud2
That's fair, it traps if we dereference a null pointer. But I need the best
performance and don't want the null check, so I add
-fno-isolate-erroneous-paths-dereference and see:
lea rax, [rdi-4]
testrdi, rdi
cmovne rdi, rax
mov eax, DWORD PTR [rdi+4]
ret
If I read that correctly, it checks if the pointer is null so it can
dereference 0x4 instead of 0x0. That's hardly an improvement over the naive
and optimal code:
mov eax, DWORD PTR [rdi]
ret
Which is what Clang generates for field() in all versions through 10, and for
getter() up to 3.6 (3.7 through 10 generate a cmovne like GCC with no-isolate).
I tried adding __attribute__((nonnull)) to the function declarations, but it
didn't help.
Live demo: https://godbolt.org/z/XnhZoz
[Bug c++/87515] "no return statement in function returning non-void" miscompiles with optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87515
ipelupes changed:
What|Removed |Added
CC||ipelupes at hotmail dot com
--- Comment #4 from ipelupes ---
I think the warning is not enough, because the resulting behaviour is quite
hard to debug, affecting the program flow, eg the following:
include
int f()
{
}
int main()
{
printf("calling returnless nonvoid\n");
f();
return 0;
}
compiled with g++ -O2 test.C
prints out "calling returnless nonvoid" for a few thousand times before seg
faulting on my machine (gcc 9.3.1). I would not be helped by the warning in
tracking this down in a large project (often lots of warnings are present).
also: adding __builtin_unreachable(); hides the warning making it even harder
to find
[Bug c++/87515] "no return statement in function returning non-void" miscompiles with optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87515 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- You can always use -Werror=return-type, or -fsanitize=undefined which will diagnose it at runtime.
[Bug target/95661] Code built with -m32 uses SSE2 instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95661 --- Comment #4 from Matt Emmerton --- Thank you everyone. This fully explains why we were still getting SSE in 32-bit mode.
[Bug ada/95664] New: generic instantiation fails to detect abstract equality, builds with gcc-9 and fails to link with gcc-10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95664 Bug ID: 95664 Summary: generic instantiation fails to detect abstract equality, builds with gcc-9 and fails to link with gcc-10 Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: nicolas at debian dot org Target Milestone: --- Hello. A minimal reproducer follows. With gcc-9.3.0 (Debian build 13), all goes well, but gcc-10.1.0 (Debian build 3) fails to link: # /usr/bin/ld: ./pkg.o: in function `pkg__instantiation': # pkg.ads:(.text+0x9): undefined reference to `pkg__Oeq' If the source is valid Ada code (I am not quite sure), then gcc-9 is right and gcc-10 introduces a regression, else both versions should report an error instead of their current behaviour. cat > gen_proc.ads < main.adb <
[Bug c++/95665] New: memory access error on passing additional parameters to Int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95665 Bug ID: 95665 Summary: memory access error on passing additional parameters to Int128 Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: estellnb at elstel dot org Target Milestone: --- Created attachment 48725 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48725&action=edit types.tar.bz2 I have programmed a library for calculating with WIdeInts witgh gcc 8.3.0-6, Debian Stable. When I started to use the library an opertor (>>) suddenly returned a wrong result (>> was ignored; result as would be without shifting). For that program replacing (wi>>2)*3 by wi>>=2 and wi*=3 has helped. However I then tried to isolate the problem into a test case and it showed that the additional parameters passed to the procedure calling (wi>>2)*3 caused the memory access problem. The test program does not return a wrong result but it crashes with a memory access error. Replacing by wi>>=2, wi*=3 did not help here. It always crashes as soon as the full parameter list is used. I had tried to debug the problem and inserting some printf-statements made the values inside the >> oeprator to be retrieved correctly though the result was still lost. Another time it returned zero as if that would have been passed as parameter instead of 32. I currently do not dare to use that WideInt implementation as it seems to trigger some gcc compiler error. sample program: test_int128.cpp (only a very few lines) library: types.h
[Bug c++/95665] memory access error on passing additional parameters in addition to Int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95665 --- Comment #1 from Elmar Stellnberger --- compile and start with ./runit test_int128.cpp
[Bug c++/93467] [concepts] getting "type constraint differs in template redeclaration" error after friend declaration in template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93467 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:652ec7e8c046b239c42dedd295acf1815ed2b93a commit r10-8288-g652ec7e8c046b239c42dedd295acf1815ed2b93a Author: Patrick Palka Date: Thu Jun 11 16:33:41 2020 -0400 c++: constrained class template friend [PR93467] This fixes two issues in our handling of constrained class template friend declarations. The first issue is that we fail to set the constraints on the injected class template declaration during tsubst_friend_class. The second issue is that the template parameter levels within the parsed constraints of a class template friend declaration are shifted if the enclosing class is a template, and this shift leads to spurious constraint mismatch errors in associate_classtype_constraints if the friend declaration refers to an already declared class template. gcc/cp/ChangeLog: PR c++/93467 * constraint.cc (associate_classtype_constraints): If there is a discrepancy between the current template depth and the template depth of the original declaration, then adjust the template parameter depth within the current constraints appropriately. * pt.c (tsubst_friend_class): Substitute into and set the constraints on the injected declaration. gcc/testsuite/ChangeLog: PR c++/93467 * g++.dg/cpp2a/concepts-friend6.C: New test. * g++.dg/cpp2a/concepts-friend7.C: New test. (cherry picked from commit 11c7261128ad3ee136508703b20e45cbe04f8dd0)
[Bug c++/93467] [concepts] getting "type constraint differs in template redeclaration" error after friend declaration in template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93467 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |10.2 --- Comment #4 from Patrick Palka --- Fixed for GCC 10.2+.
[Bug ada/95664] generic instantiation fails to detect abstract equality, builds with gcc-9 and fails to link with gcc-10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95664 Ludovic Brenta changed: What|Removed |Added CC||ludo...@ludovic-brenta.org --- Comment #1 from Ludovic Brenta --- ARM 3.9.3(3/2): A subprogram declared by an abstract_subprogram_declaration or a formal_abstract_subprogram_declaration is an abstract subprogram. If it is a primitive subprogram of a tagged type, then the tagged type shall be abstract. so this does not explicitly forbid abstract subprograms that are primitive to an untagged type; however: 7 A call on an abstract subprogram shall be a dispatching call; nondispatching calls to an abstract subprogram are not allowed. this implicitly requires the formal type of the controlling operand to be tagged and the actual to be class-wide. Therefore I think gcc-9.3 and gcc-10.1 should both report an error; it should be illegal to declare "=" as an abstract primitive subprogram of the untagged type Element.
[Bug fortran/95647] operator(.eq.) and operator(==) treated differently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647 --- Comment #4 from Steve Kargl --- On Sat, Jun 13, 2020 at 08:11:22AM +, tkoenig at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647 > > --- Comment #3 from Thomas Koenig --- > If we treat .eq. and == differently, that is an indication > of a bug in the compiler itself. If a user provides an overloading of .eq. or == with an INTERFACE OPERATOR() statement, then things appear to work. The IEEE modules are not provided by a user and for parts of the modules gfortran builts the needed the pieces at compile time. gfortran also marks symbols as coming from an IEEE module for special handling. For whatever reason, with the IEEE_ARITHMETICi module if the interface is given in terms of ==, it is not overloaded to .eq.; while for the converse .eq. is overloaded to ==. The purposed patch fixes this issue.
[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640 --- Comment #18 from Steve Kargl --- On Sat, Jun 13, 2020 at 10:14:43AM +, pinskia at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640 > > --- Comment #17 from Andrew Pinski --- > (In reply to Steve Kargl from comment #13) > > With a bit of work, someone could do > > > > Index: gcc/fortran/trans-types.c > > === > > --- gcc/fortran/trans-types.c (revision 280157) > > +++ gcc/fortran/trans-types.c (working copy) > > @@ -451,7 +451,7 @@ gfc_init_kinds (void) > > continue; > >if (mode != TYPE_MODE (float_type_node) > > && (mode != TYPE_MODE (double_type_node)) > > - && (mode != TYPE_MODE (long_double_type_node)) > > + && (!flag_disable_real10 || mode != TYPE_MODE > > (long_double_type_node)) > > #if defined(HAVE_TFmode) && defined(ENABLE_LIBQUADMATH_SUPPORT) > > && (mode != TFmode) > > #endif > > > It needs to be more complex than that as long double on most > targets is NOT the 80bit (96bit or 128bit storage) IEEE FP type. Of course, this was just a test to see if it would work. It does not. As gfortran's behavior conforms with the Fortran standard, I'm inclined to close the bug report with INVALID. But, I'm leaving it open as someone else might find value in disabling REAL(10). Now, if someone else closes the bug, I won't object.
[Bug fortran/27318] gfortran should warn if a interface does not match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27318 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #4 from Thomas Koenig --- This is also not caught: module test implicit none interface subroutine hello(n) integer :: n end subroutine hello end interface contains subroutine bar() call hello(3) end subroutine bar end module test subroutine hello(r) real :: r integer :: i do i = 1, int(r); print *, 'hello'; end do end subroutine hello
[Bug tree-optimization/95353] [10 Regression] spurious -Wstringop-overflow writing to a trailing array plus offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95353 --- Comment #14 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:678178cbf3642f272459b2be675cc518b3121d09 commit r11-1292-g678178cbf3642f272459b2be675cc518b3121d09 Author: Martin Sebor Date: Sat Jun 13 11:29:01 2020 -0600 Correct test to avoid failures in ILP32. Amends: PR middle-end/95353 - spurious -Wstringop-overflow writing to a trailing array plus offset. gcc/testsuite/ChangeLog: * gcc.dg/builtin-stringop-chk-5.c: Make assertions independent of data model.
[Bug c++/95440] [coroutines] ICE with static members in promise_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95440 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:b88498204521731f46b439b33f936009fedfdf35 commit r10-8289-gb88498204521731f46b439b33f936009fedfdf35 Author: Iain Sandoe Date: Sat Jun 13 10:36:29 2020 +0100 coroutines: Make call argument handling more robust [PR95440] build_new_method_call is supposed to be able to handle a null arguments list pointer (when the method has no parms). There were a couple of places where uses of the argument list pointer were not defended against NULL. gcc/cp/ChangeLog: PR c++/95440 * call.c (add_candidates): Use vec_safe_length() for testing the arguments list. (build_new_method_call_1): Use vec_safe_is_empty() when checking for an empty args list. gcc/testsuite/ChangeLog: PR c++/95440 * g++.dg/coroutines/pr95440.C: New test. (cherry picked from commit a9eec9625ea7165292958be04899b057804192fb)
[Bug c/95666] New: gcc 9.3.0 generates incorrect code with -O3 on HP-UX IA64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95666 Bug ID: 95666 Summary: gcc 9.3.0 generates incorrect code with -O3 on HP-UX IA64 Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: aerofeev at commvault dot com Target Milestone: --- Created attachment 48726 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48726&action=edit Source code, assembly and compiled test program Hi, While upgrading our compilers from gcc-4.9.3 to gcc-9.3.0 we have found that openssl started crashing with the following stack: #0 0x402bbf00:1 in x509_name_ex_d2i+0x641 () #1 0x4026bd40:0 in ASN1_item_ex_d2i+0x8c0 () #2 0x4026eea0:0 in asn1_template_noexp_d2i+0xd00 () #3 0x4026e110:0 in asn1_template_ex_d2i+0x590 () #4 0x4026d340:0 in ASN1_item_ex_d2i+0x1ec0 () #5 0x4026eea0:0 in asn1_template_noexp_d2i+0xd00 () #6 0x4026e110:0 in asn1_template_ex_d2i+0x590 () #7 0x4026d340:0 in ASN1_item_ex_d2i+0x1ec0 () #8 0x4026b330:0 in ASN1_item_d2i+0x110 () #9 0x402c14c0:0 in d2i_X509+0x80 () #10 0x403946b0:0 in PEM_ASN1_read_bio+0xf0 () #11 0x401f9610:0 in PEM_read_bio_X509+0x50 () The stack by itself is not very relevant to this report, I'm mentioning it here only in case if someone else runs into the same issue and tries googling the stack. The real issue lies in another file, stack.c where a function called sk_insert() corrupts OpenSSL's struct STACK by inserting a new element into STACK::data[] array at incorrect location. The corruption is caused by gcc producing incorrect assembly for the body of sk_insert() with -O3. The purpose of sk_insert(struct STACK *st, void *data, int loc) is to insert a new element "data" into st->data[] array at the specified location "loc". If necessary, sk_insert() can reallocate st->data[] and can shift elements in the array to free up the space for the new element, but all of that code is not what triggers the bug. It's the simplest insertion of a new element into empty preallocated array at location 0 where things break, and the element ends up being inserted at location 1 instead. Regretfully, I couldn't trim the reallocation piece and the piece that moves existing elements from the function, because without them the assembly changes, and the bug disappears. I have extracted sk_insert() into a separate file stack.c (attached to this report), removed some of the fat and constructed a test case demonstrating how the code puts first element at location st->data[1] instead of location st->data[0]. If compiled with -O2, the test program will produce a single "OK" word. If compiled with -O3, the post-insertion checks yield these messages: Bad st.data[0]= (87fff228 expected) Bad st.data[1]=87fff228 (0 expected) I have reviewed the assembly code and found that at line 101 r41 is incorrectly incremented after having been set to st->num at line 88. Later at line 133 the value of r41 is assigned to r15. r15 is then multiplied by 8 (size of a single element in st->data[]) and is added to st->data. Finally the new element is assigned to the location pointed to by r15 at line 152. Net result is that instead of storing new element at location st->data[0], the code stores it at location st->data[0+1]. Like I've said, the issue disappears if the code is compiled with -O2. I am not confident however that it's related to the optimization level at all. Any change to sk_insert(), sometimes as subtle as a simple printf() or removal of loc<0 alters assembly enough to make the bug go away. Please advise on whether this is something known and what other information I can provide to help troubleshoot the problem.
[Bug target/95400] -march=native and -march=icelake-client produce different results on icelake client
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95400 H.J. Lu changed: What|Removed |Added Target Milestone|--- |8.5 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from H.J. Lu --- Fixed GCC 11, GCC 10.2 (r10-8246), GCC 9.4 (r9-8652) and GCC 8.5 (r8-10298).
[Bug middle-end/95667] New: warning for memset writing across multiple members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95667
Bug ID: 95667
Summary: warning for memset writing across multiple members
Product: gcc
Version: 10.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: ---
Although strictly correct, GCC usually avoids warning for calls to memcpy that
write into multiple members at the same time, up to the size of the complete
object. This is done because the Linux kernel does these things in a few
places. As dangerous as the practice is, the change committed to resolve
pr95353 (r11-1183) tried to preserve this behavior for now (in the future I'd
like to add a new warning option to control it), but the test case below shows
it didn't preserve the GCC 10 and prior behavior in this case (same with
memcpy).
$ cat z.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout z.c
struct S { char a[3], b[5]; };
void* f (void)
{
struct S *p = __builtin_malloc (sizeof *p);
char s[] = "1234567";
__builtin_strcpy (p->a, s); // warning (good)
return p;
}
void* g (void)
{
struct S *p = __builtin_malloc (sizeof *p);
__builtin_memset (p->a, 0, 8); // warning not expected (yet)
return p;
}
z.c: In function ‘f’:
z.c:7:3: warning: ‘__builtin_strcpy’ writing 8 bytes into a region of size 3
[-Wstringop-overflow=]
7 | __builtin_strcpy (p->a, s); // warning (good)
| ^~
z.c:1:17: note: at offset 0 to object ‘a’ with size 3 declared here
1 | struct S { char a[3], b[5]; };
| ^
;; Function f (f, funcdef_no=0, decl_uid=1934, cgraph_uid=1, symbol_order=0)
f ()
{
char s[8];
struct S * p;
long unsigned int _8;
[local count: 1073741824]:
p_4 = __builtin_malloc (8);
s = "1234567";
_8 = MEM [(char * {ref-all})&s];
MEM [(char * {ref-all})p_4] = _8;
s ={v} {CLOBBER};
return p_4;
}
;; Function g (g, funcdef_no=1, decl_uid=1939, cgraph_uid=2, symbol_order=1)
g ()
{
struct S * p;
char[3] * _1;
[local count: 1073741824]:
p_4 = __builtin_malloc (8);
_1 = &p_4->a;
__builtin_memset (_1, 0, 8);
return p_4;
}
z.c: In function ‘g’:
z.c:14:3: warning: ‘__builtin_memset’ writing 8 bytes into a region of size 3
overflows the destination [-Wstringop-overflow=]
14 | __builtin_memset (p->a, 0, 8); // warning not expected (yet)
| ^
z.c:1:17: note: destination object ‘a’
1 | struct S { char a[3], b[5]; };
| ^
[Bug middle-end/95667] [11 Regression] unintended warning for memset writing across multiple members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95667 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-06-13 Blocks||88443 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Keywords||diagnostic Ever confirmed|0 |1 Summary|warning for memset writing |[11 Regression] unintended |across multiple members |warning for memset writing ||across multiple members --- Comment #1 from Martin Sebor --- See https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548040.html for the original report. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 [Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
[Bug c++/95638] [10/11 Regression] Legit-looking code doesn't work with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95638 --- Comment #6 from bin cheng --- We call graphds_scc twice to break alias dependence, with alias dependence edges skipped in the second call. The code (both before and after r10-7184-ge4e9a59105a81cdd6c1328b0a5ed9fe4cc82840e) tries to rectify post order information after the second call, however it never gets it right. Actually I don't think it can be easily rectified (if possible). Will test another patch which records/restores post order information for the second call.
[Bug ada/95664] generic instantiation fails to detect abstract equality, builds with gcc-9 and fails to link with gcc-10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95664
Jean-Pierre Rosen changed:
What|Removed |Added
CC||rosen at adalog dot fr
--- Comment #2 from Jean-Pierre Rosen ---
This is fixed in the development version of AdaControl.
Patch:
- package Declarations_Store is new Scope_Manager.Scoped_Store
(Asis.Declaration);
+ package Declarations_Store is new Scope_Manager.Scoped_Store
(Asis.Declaration,
+
Equivalent_Keys => Asis.Elements.Is_Equal);
There is a hole in the language about this case. I reported to AdaCore, and
here is Tucker Taft's response:
After looking through the RM, it seems that the use of an abstract "=" in
this context is not directly covered, but the closest thing is the rule about
what happens when you wrap a type with an abstract "=" into a record or array
type. The abstract "=" raises Program_Error if it is ever invoked. See RM
4.5.2 (24.1/3):
24.1/3
{AI05-0123-1} If the primitive equals operator for an untagged record type is
abstract, then Program_Error is raised at the point of any (implicit) call to
that abstract subprogram.
24.f/3
Reason: An explicit call to an abstract subprogram is illegal. This rule is
needed in order to define the effect of an implicit call such as a call that is
part of the predefined equality operation for an enclosing composite type that
has a component of an untagged record type that has an abstract primitive
equals operator. For tagged types, an abstract primitive equals operator is
only allowed for an abstract type, and abstract types cannot be components, so
this case does not occur.
So my sense is that this should *not* be a compile-time error, but rather raise
Program_Error if the "=" operator of the formal type is invoked. We also
should write up an AI to at least clarify this particular case.
We could try to make this illegal in the generic spec, but clearly we cannot
make it illegal in the generic body, because of contract issues. But I think
the same argument applies here, namely that there is no need to disallow this
instantiation, unless "=" is actually used, which argues for raising
Program_Error rather than making it illegal.
