[Bug c++/92053] Compilation fails or succeeds depending on the optimization flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92053 Kamlesh Kumar changed: What|Removed |Added CC||kamleshbhalui at gmail dot com --- Comment #4 from Kamlesh Kumar --- (In reply to Antony Polukhin from comment #2) > Reduced version. Note that Clang reduces to compile it with any -O, while > GCC is fine with it on -O0 https://godbolt.org/z/yTM0a4 : > Clang fails to compile it regardless of any optimization. see at https://godbolt.org/z/jP0Ct2
[Bug c++/87403] [Meta-bug] Issues that suggest a new warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 Bug 87403 depends on bug 49574, which changed state. Bug 49574 Summary: Give a warning for insane overloading https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49574 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID
[Bug c++/49574] Give a warning for insane overloading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49574
Eric Gallager changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|--- |INVALID
--- Comment #8 from Eric Gallager ---
(In reply to Jonathan Wakely from comment #7)
> OK here's the documentation patch:
>
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -3383,6 +3383,11 @@ object to the same type, to a base class of that
> type, or to void; such
> a conversion function will never be called.
> @end table
>
> +@item -Winsane-overloading @r{(C++ and Objective-C++ only)}
> +@opindex Winsane-overloading
> +@opindex Wno-insane-overloading
> +Warn about whatever was agreed to in Bugzilla.
> +
> @node Objective-C and Objective-C++ Dialect Options
> @section Options Controlling Objective-C and Objective-C++ Dialects
>
>
> The rest should be a simple matter of programming.
>
> More seriously, I'm not the one asking for the warning, so it's not up to me
> to describe what's wanted.
All right fine; I guess I'll close this then...
[Bug middle-end/92183] New: gcc tries to create a relocation in a mergeable section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92183
Bug ID: 92183
Summary: gcc tries to create a relocation in a mergeable
section
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rafael at espindo dot la
Target Milestone: ---
Given
struct foo {
const char *bar;
const char *zed;
};
void g(struct foo *r);
void f() {
struct foo t = {"bar", "zed"};
g();
}
gcc -O3 produces
.section.rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "bar"
.LC1:
.string "zed"
.section.rodata.cst8,"aM",@progbits,8
.align 8
.LC2:
.quad .LC1
While it is not illegal to have a relocation in a mergeable section, I don't
know of any linker that supports that, so gcc is being over aggressive.
[Bug c/92172] ARM Thumb2 frame pointers inconsistent with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92172 --- Comment #2 from Seth LaForge --- Good point on frame pointers vs a frame chain for unwinding. I'm looking for the unwindable frame chain. Wilco: > Why does this matter? Well as your examples show, if you want to emit a frame > chain using standard push/pop, it typically ends up pointing to the top of the > frame. That is the worst possible position for a frame pointer on Thumb - > while > Arm supports negative immediate offsets up to 4KB, Thumb-1 doesn't support > negative offsets at all, and Thumb-2 supports offsets up to -255 but only with > 32-bit instructions. So the result of conflating the frame chain and frame > pointer implies a terrible codesize hit for Thumb. Well, there's really no need for a frame pointer for efficiency, since the stack frame can be efficiently accessed with positive immediate accesses relative to the stack pointer. There are even special encodings for Thumb-2 16-bit LDR/STR which allow an immediate offset of 0 to 1020 when relative to SP - much larger than other registers. You're saying using a frame pointer implies a terrible codesize hit for Thumb, but I don't see how that can be - stack access will continue to go through SP, and the only code size hit should be pushing/popping R7 (~2 cycles), computing R7 as a frame pointer (~1 cycle), and potential register spills due to one less register available. That's a pretty small amount of overhead for a non-leaf function. > Your examples suggest LLVM suffers from both of these issues, and IIRC it > still > uses r11 on Arm but r7 on Thumb. That is way too inefficient/incorrect to > consider > a defacto standard. Using R11 in ARM and R7 on Thumb is mandated by the AAPCS I believe. I don't think the overhead is likely to be particularly different in Thumb vs ARM. Numbers talk, so I collected some benchmarks on some production firmware used in self-driving cars. This code is executing on a Cortex-R5F MCU, processing a large amount of data, with a wide variety of function sizes. Unfortunately precise benchmarking on this MCU is difficult - there seem to be swings of a few percent in performance due to changes in code alignment, but the rough results have been reliable. I'm collecting .text size and time spent in computation. Unfortunately we're using a pretty old version of gcc, but the frame pointer generation doesn't seem to have changed in newer releases. Baseline: With gcc 4.7, -fomit-frame-pointer, -mthumb: 384016 bytes, 110.943 s. With gcc 4.7, -fno-omit-frame-pointer, -mthumb: 396688 bytes, 113.539 s. This shows a +3.2% size overhead and +2.3% time overhead for enabling frame pointers in Thumb-2 code. With gcc 4.7, -fomit-frame-pointer, ARM mode: 487152 bytes, 113.874 s. That's +26.9% size and +2.6% time over -mthumb. With gcc 4.7, -fno-omit-frame-pointer, ARM mode: 498064 bytes, 116.936 s. This shows a +2.7% size overhead and +2.7% time overhead for enabling frame pointers in Thumb-2 code. Within margin of error, it appears the frame pointer overhead is comparable in Thumb-2 and ARM code. With clang 7, -fomit-frame-pointer, -mthumb: 371008 bytes, 107.072 s. That's -3.4% size and -3.5% time over gcc 4.7. With clang 7, -fomit-frame-pointer, -mthumb: 377296 bytes, 110.868 s. This shows a +1.7% size overhead and +3.5% time overhead for enabling frame pointers in Thumb-2 code for clang 7. Within margin of error, it appears clang's frame pointer overhead is slightly higher than gcc's for Thumb-2, but not much. With clang 7, -fomit-frame-pointer, ARM mode: 458592 bytes, 112.829 s. That's +21.5% size +1.8% time over clang -mthumb. With clang 7, -fno-omit-frame-pointer, ARM mode: 463440 bytes, 111.796 s. That's +1.1% size -0.9% time over clang ARM without frame pointers. I'm a bit mystified by this result - I looked at the generated code and it does what I'd expect, so I think this is just benchmarking variation due to caches/alignment. For my application, a ~2.5% performance hit is very worthwhile to gain the extra debugability of easy stack traces. I'll probably end up switching over to clang and frame pointers. It'd be nice if people using gcc for embedded ARM development had an easy option for generating stack traces.
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178
--- Comment #7 from Steve Kargl ---
On Tue, Oct 22, 2019 at 10:22:42PM +, sgk at troutmask dot
apl.washington.edu wrote:
> --- Comment #6 from Steve Kargl ---
> On Tue, Oct 22, 2019 at 09:30:14PM +, sgk at troutmask dot
> apl.washington.edu wrote:
> >
> > Cutting the -ftree-dump-original down to the 'call' statement
> > gives
> >
> > MAIN__ ()
> > {
> > {
> > integer(kind=4) D.3955;
> > integer(kind=4) D.3956;
> > integer(kind=4) M.7;
> >
> > D.3955 = (*(integer(kind=4)[0:] * restrict) a.data)[a.offset + 1];
> > D.3956 = D.3955 * D.3955;
> > M.7 = D.3956;
> > M.7 = MIN_EXPR ;
> > if ((integer(kind=4)[0:] * restrict) a.data != 0B)
> > {
> > __builtin_free ((void *) a.data);
> > (integer(kind=4)[0:] * restrict) a.data = 0B;
> > }
> > assign (M.7, );
> > }
> > }
> >
> > which shows the argument evaluation is done correctly. In short,
> > gfortran needs to scan the effective and dummy arguments for a
> > deallocation and just do the right thing.
> >
>
> The evaluation of arguments seems to be done in trans-expr.c
> gfc_conv_procedure_call(), where the argument list is simply
> walked and evaluated. That's not good as this pr shows. :(
>
There is a massive for-loop (lines: 5478-6638) that is used
for the evaluation of arguments. Within those lines, the
blocks 5924-5981, 6071-6111, and 6242-6273 are used to
delete allocated actual args for intent(out) dummy args.
I suspect that those blocks need to be removed, and second
following for-loop should scan the arg list to do the
deallocations.
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178
--- Comment #6 from Steve Kargl ---
On Tue, Oct 22, 2019 at 09:30:14PM +, sgk at troutmask dot
apl.washington.edu wrote:
>
> Cutting the -ftree-dump-original down to the 'call' statement
> gives
>
> MAIN__ ()
> {
> {
> integer(kind=4) D.3955;
> integer(kind=4) D.3956;
> integer(kind=4) M.7;
>
> D.3955 = (*(integer(kind=4)[0:] * restrict) a.data)[a.offset + 1];
> D.3956 = D.3955 * D.3955;
> M.7 = D.3956;
> M.7 = MIN_EXPR ;
> if ((integer(kind=4)[0:] * restrict) a.data != 0B)
> {
> __builtin_free ((void *) a.data);
> (integer(kind=4)[0:] * restrict) a.data = 0B;
> }
> assign (M.7, );
> }
> }
>
> which shows the argument evaluation is done correctly. In short,
> gfortran needs to scan the effective and dummy arguments for a
> deallocation and just do the right thing.
>
The evaluation of arguments seems to be done in trans-expr.c
gfc_conv_procedure_call(), where the argument list is simply
walked and evaluated. That's not good as this pr shows. :(
[Bug c++/91548] [10 Regression] Regression in constexpr evaluation of std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91548
--- Comment #7 from Marek Polacek ---
Thanks.
Reduced (no templates, no lambda):
constexpr int& impl(const int ()[10], int index) {
return const_cast(array[index]);
}
struct A {
constexpr int& operator[](int i) { return impl(elems, i); }
int elems[10];
};
constexpr bool
f()
{
A arr = {};
arr[2] = true;
return false;
}
constexpr bool b = f();
[Bug fortran/87851] [8/9/10 Regression] Wrong return type for len_trim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87851 --- Comment #10 from anlauf at gcc dot gnu.org --- Forget comment#8 and comment#9. The standard declares the default kind of LEN_TRIM to be that of default integer.
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178
--- Comment #5 from Steve Kargl ---
On Tue, Oct 22, 2019 at 09:03:42PM +, vladimir.fuka at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178
>
> --- Comment #4 from Vladimir Fuka ---
> It would be really strange if even expressions like below were not possible.
>
> implicit none
> integer, allocatable :: a(:)
> allocate(a, source=[1])
> call assign(a, (min(a(1)**2,0)))
> print *, allocated(a)
> contains
> subroutine assign(a, i)
> integer, allocatable, intent(out) :: a(:)
> integer, value :: i
> print *, i
> end subroutine
> end program
Yep. I agree. In fact, if you reverse the arguments, like,
implicit none
integer, allocatable :: a(:)
allocate(a, source=[1])
call assign((min(a(1)**2,0)), a)
print *, allocated(a)
contains
subroutine assign(i, a)
integer, allocatable, intent(out) :: a(:)
integer, value :: i
print *, i
end subroutine
end
gfortran gives
% gfcx -o z a.f90 && ./z
0
F
Cutting the -ftree-dump-original down to the 'call' statement
gives
MAIN__ ()
{
{
integer(kind=4) D.3955;
integer(kind=4) D.3956;
integer(kind=4) M.7;
D.3955 = (*(integer(kind=4)[0:] * restrict) a.data)[a.offset + 1];
D.3956 = D.3955 * D.3955;
M.7 = D.3956;
M.7 = MIN_EXPR ;
if ((integer(kind=4)[0:] * restrict) a.data != 0B)
{
__builtin_free ((void *) a.data);
(integer(kind=4)[0:] * restrict) a.data = 0B;
}
assign (M.7, );
}
}
which shows the argument evaluation is done correctly. In short,
gfortran needs to scan the effective and dummy arguments for a
deallocation and just do the right thing.
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 --- Comment #4 from Vladimir Fuka --- It would be really strange if even expressions like below were not possible. implicit none integer, allocatable :: a(:) allocate(a, source=[1]) call assign(a, (min(a(1)**2,0))) print *, allocated(a) contains subroutine assign(a, i) integer, allocatable, intent(out) :: a(:) integer, value :: i print *, i end subroutine end program
[Bug fortran/87851] [8/9/10 Regression] Wrong return type for len_trim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87851
--- Comment #9 from anlauf at gcc dot gnu.org ---
The following may be necessary in addition to the patch in comment#8:
Index: gcc/fortran/simplify.c
===
--- gcc/fortran/simplify.c (Revision 277298)
+++ gcc/fortran/simplify.c (Arbeitskopie)
@@ -4479,7 +4479,7 @@ gfc_simplify_len_trim (gfc_expr *e, gfc_expr *kind
{
gfc_expr *result;
size_t count, len, i;
- int k = get_kind (BT_INTEGER, kind, "LEN_TRIM", gfc_default_integer_kind);
+ int k = get_kind (BT_INTEGER, kind, "LEN_TRIM", gfc_charlen_int_kind);
if (k == -1)
return _bad_expr;
I think the scalarizer issue mentioned in comment#1 is a separate issue.
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 --- Comment #3 from Steve Kargl --- On Tue, Oct 22, 2019 at 07:32:59PM +, kargl at gcc dot gnu.org wrote: > > The effect of the intent(out) in assign is to deallocate the code on entry to > assign. This is done with the if-block. The side-effect of evaluating the > first dummy argument is that 'a' in the expression of the 2nd dummy argument > is > undefined. > > F2018 (well 18-007r1) page 308: > >If a dummy argument has INTENT (OUT) or INTENT (INOUT), the actual >argument shall be definable. If a dummy argument has INTENT (OUT) >and its associated actual argument is allocated, the actual argument >is deallocated on procedure invocation (9.7.3.2). > > then later > >15.5.2.13 Restrictions on entities associated with dummy arguments > >While an entity is associated with a dummy argument, the following >restrictions hold. > >(1) Action that affects the allocation status of the entity or a >subobject thereof shall be taken through the dummy argument. > >(2) If the allocation status of the entity or a subobject thereof >is affected through the dummy argument, then at any time during >the invocation and execution of the procedure, either before or >after the allocation or deallocation, it shall be referenced only >through the dummy argument. > > It seems that code is non-conforming. > Seems to be some wiggle room. 15.5.4 Subroutine reference A subroutine is invoked by execution of a CALL statement, ... When a subroutine is invoked, all actual argument expressions are evaluated, then the arguments are associated, and then the subroutine is executed. So, it comes down to when the deallocation occur? P. 308 says the deallocation occurs when the procedure is invoked. But, 15.5.4 defines the sequence of events that occur when it procedure is invoked. Is the reference to the subroutine name the initiation of invocation? No where does it say when the deallocation occurs.
[Bug fortran/87851] [8/9/10 Regression] Wrong return type for len_trim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87851
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #8 from anlauf at gcc dot gnu.org ---
The following obvious patch seems to fix the issue and regtests cleanly
after adjustment of one testcase:
Index: gcc/fortran/iresolve.c
===
--- gcc/fortran/iresolve.c (Revision 277298)
+++ gcc/fortran/iresolve.c (Arbeitskopie)
@@ -1536,7 +1536,7 @@
if (kind)
f->ts.kind = mpz_get_si (kind->value.integer);
else
-f->ts.kind = gfc_default_integer_kind;
+f->ts.kind = gfc_charlen_int_kind;
f->value.function.name = gfc_get_string ("__len_trim%d", string->ts.kind);
}
Index: gcc/testsuite/gfortran.dg/initialization_18.f90
===
--- gcc/testsuite/gfortran.dg/initialization_18.f90 (Revision 277298)
+++ gcc/testsuite/gfortran.dg/initialization_18.f90 (Arbeitskopie)
@@ -1,5 +1,5 @@
! { dg-do compile }
-! { dg-options "-std=f95 -Wall" }
+! { dg-options "-std=f95 -Wall -Wno-conversion" }
!
! PR fortran/34915
! Testcase contributed by Al Greynolds via comp.lang.fortran.
[Bug c++/91826] [8/9/10 Regression] Unexpected behavior when class defined with namespace alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91826 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org
[Bug c++/92182] No way to silence ''A::TKind' is too small to hold all values of 'enum Kind''
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92182 Marek Polacek changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-10-22 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed. I'll add something.
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-10-22
CC||kargl at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from kargl at gcc dot gnu.org ---
Compiling the code with -fdump-tree-original and stripping out the unessential
intermediate code gives
assign (struct array01_integer(kind=4) & restrict a, integer(kind=4) b)
{
}
foo ()
{
if ((integer(kind=4)[0:] * restrict) a.data != 0B)
{
__builtin_free ((void *) a.data);
(integer(kind=4)[0:] * restrict) a.data = 0B;
}
assign (, (*(integer(kind=4)[0:] * restrict) a.data)[a.offset + 1]);
}
The effect of the intent(out) in assign is to deallocate the code on entry to
assign. This is done with the if-block. The side-effect of evaluating the
first dummy argument is that 'a' in the expression of the 2nd dummy argument is
undefined.
F2018 (well 18-007r1) page 308:
If a dummy argument has INTENT (OUT) or INTENT (INOUT), the actual
argument shall be definable. If a dummy argument has INTENT (OUT)
and its associated actual argument is allocated, the actual argument
is deallocated on procedure invocation (9.7.3.2).
then later
15.5.2.13 Restrictions on entities associated with dummy arguments
While an entity is associated with a dummy argument, the following
restrictions hold.
(1) Action that affects the allocation status of the entity or a
subobject thereof shall be taken through the dummy argument.
(2) If the allocation status of the entity or a subobject thereof
is affected through the dummy argument, then at any time during
the invocation and execution of the procedure, either before or
after the allocation or deallocation, it shall be referenced only
through the dummy argument.
It seems that code is non-conforming.
[Bug c++/92182] New: No way to silence ''A::TKind' is too small to hold all values of 'enum Kind''
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92182
Bug ID: 92182
Summary: No way to silence ''A::TKind' is too small to hold all
values of 'enum Kind''
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
enum Kind : unsigned {
Y = 0x0,
N = 0x1,
Z = 0x2,
};
struct A {
Kind TKind : 2;
};
gcc file.c
warning: 'A::TKind' is too small to hold all values of 'enum Kind'
This warning has no flag so we cannot use -Wno-XXX. Only option to silence this
warning is '-w'.
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 --- Comment #11 from postmas...@trippelsdorf-de.bounceio.net --- Your email was bounced... - ... because something went wrong between you and your recipient. Ugh! What to do next? Well, your specific problem was a *5.1.2 * error. Which means you should: Check the "trippelsdorf.de" part of "mar...@trippelsdorf.de" for misspellings or missing letters. If you find an error, correct it in your contacts list or address book for next time. Or further: It is possible that the domain is temporarily inactive. If the spelling looks correct, contact your mail provider and if necessary, contact your recipient another way (e.g., phone or text message). Get more Bounce Intelligence ™ on 5.1.2 errors here![1] Thanks, have a lovely day. Yours truly, betterbounces.net[2] Rate this email: Helpful[3] :) or... Not Helpful[4] :( Advertisement | Prefer no ads?[5] YOU MIGHT LIKE [6] [7] [8] Learn more about RevenueStripe...[9] - © 2017 betterbounces.net, All rights reserved. Privacy[10] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] 1. https://www.betterbounces.net/email-error/5.1.2?utm_source=7o9_medium=direct_campaign=trippelsdorf.de_content=SeretV2 2. http://bit.ly/1AqkgOr 3. https://www.surveygizmo.com/s3/1609211/rtm01?tv=SeretV2=5.1.2=D8A64110-2417-4BAA-91BC-27BF610D41B5.1=7o9=Helpful 4. https://www.surveygizmo.com/s3/1609211/rtm01?tv=SeretV2=5.1.2=D8A64110-2417-4BAA-91BC-27BF610D41B5.1=7o9=Not%20helpful 5. https://betterbounces.net/b/Y1lM9w9S1KeLJcXVUarv1OJFNUggPr2joqvuXnfzPULQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsYz6BSAduUDUOX259ENsI7e3HBFe_L9qqkswLxxp.9W4Mz9nic1fEk3b_JEBlfwrWyjYIBRM6OLFt_OXq_MrKuT9FbPDZoBNzGNE4gztylPle8NHh464vf7titT91WI150sPs4r2y2APILF5Fb_KY7JnWSvrTPQ_RLqzm5WLiQf9amSPLQH7QgRJJZl0nTmCep0hcafWo1b1QZ.Tnel7dwKISR9T71aeKme2RnSzesMpbRiE42ke2Gr 6. http://stripe.rs-1117-a.com/stripe/redirect?cs_email=f34cde757c9729b925454a1cf67de4ac_sendid=1571769746877_esp=threatwave_offset=0_stripeid=2454 7. http://stripe.rs-1117-a.com/stripe/redirect?cs_email=f34cde757c9729b925454a1cf67de4ac_sendid=1571769746877_esp=threatwave_offset=1_stripeid=2454 8. http://stripe.rs-1117-a.com/stripe/redirect?cs_email=f34cde757c9729b925454a1cf67de4ac_sendid=1571769746877_esp=threatwave_offset=2_stripeid=2454 9. http://branding.rs-1117-a.com/?utm_source=contentstripe_medium=email_campaign=rs_2454_content=animatedlogo 10. https://www.betterbounces.net/privacy-policy
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 --- Comment #12 from postmas...@trippelsdorf-de.bounceio.net --- Created attachment 47087 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47087=edit attachment-60399-1.eml
[Bug fortran/92174] runtime error: index 15 out of bounds for type 'gfc_expr *[15]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92174 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Target Milestone|--- |9.3 --- Comment #9 from kargl at gcc dot gnu.org --- fixed on 9-branch and trunk.
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 Bug 63426 depends on bug 92174, which changed state. Bug 92174 Summary: runtime error: index 15 out of bounds for type 'gfc_expr *[15] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92174 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug fortran/92174] runtime error: index 15 out of bounds for type 'gfc_expr *[15]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92174 --- Comment #8 from kargl at gcc dot gnu.org --- Author: kargl Date: Tue Oct 22 18:38:30 2019 New Revision: 277298 URL: https://gcc.gnu.org/viewcvs?rev=277298=gcc=rev Log: 2019-10-22 Steven G. Kargl PR fortran/92174 * decl.c (attr_decl1): Move check for F2018:C822 from here ... * array.c (gfc_set_array_spec): ... to here. Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/array.c branches/gcc-9-branch/gcc/fortran/decl.c
[Bug c++/91548] [10 Regression] Regression in constexpr evaluation of std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91548 --- Comment #6 from Hannes Hauswedell --- To make the test only complain about the current issue, change line 20 in include/seqan3/std/span to ``` #if 0 ``` Regards, Hannes
[Bug fortran/92174] runtime error: index 15 out of bounds for type 'gfc_expr *[15]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92174 --- Comment #7 from kargl at gcc dot gnu.org --- Author: kargl Date: Tue Oct 22 18:18:59 2019 New Revision: 277297 URL: https://gcc.gnu.org/viewcvs?rev=277297=gcc=rev Log: 2019-10-22 Steven G. Kargl PR fortran/92174 * decl.c (attr_decl1): Move check for F2018:C822 from here ... * array.c (gfc_set_array_spec): ... to here. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/fortran/decl.c
[Bug c++/91548] [10 Regression] Regression in constexpr evaluation of std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91548 --- Comment #5 from Hannes Hauswedell --- (In reply to Marek Polacek from comment #4) > (In reply to Hannes Hauswedell from comment #2) > > Any news on this issue? We are using this pattern in some rather central > > files in our library and the bug literally breaks 90% of our unit tests so > > we can't keep track of other gcc10 issues or try the new concepts support... > > > > Thank you for your help! > > BTW, is the library publicly accessible? If it is, I could try to compile > it when I have a fix for this to make sure it's resolved. Sure, thanks for looking into this! The library is available here: https://github.com/seqan/seqan3/ Instructions for setting up unit tests are available here: https://docs.seqan.de/seqan/3-master-user/setup_tests.html The currently failing tests are visible here: http://cdash.seqan.de/index.php?project=SeqAn3 Under "Nightly: unit", "FreeBSD unit Debug g++10 -std=c++2a" Note that due to the recent arrival of C++20 concepts in gcc-trunk, other things are currently broken with so you need to explicitly provide "-std=c++17 -fconcepts" (and not trust the auto detection of our cmake config). Making e.g. "view_to_lower_test" should trigger the problem from this PR (although I just saw that it also has a seemingly unrelated problem with not finding std::span, just ignore that).
[Bug fortran/86248] [7/8/9/10 Regression] LEN_TRIM in specification expression causes link failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86248 --- Comment #6 from paul.richard.thomas at gmail dot com --- Hi Bill, If you look at pr44265, I took over the patch from Ian Sandoe and fixed one or two of the wrinkles associated with it. I do not seem to have given it as much thought as I should. Had I done so, I would have gone down the route suggested by Tobias Burnus and apparently used by g95 and NAG, namely to mark the length of the return value as unknown and initialize it on scope entry. I don't have time tonight but I'll put it on my list of TODOs. It looks like fairly low hanging fruit to me so I'll take a look see in the next few days. Messing with name mangling cannot be the right way to go that is for sure. Thanks for prodding me Paul On Mon, 21 Oct 2019 at 19:39, longb at cray dot com wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86248 > > --- Comment #5 from Bill Long --- > Any progress on this? > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug c++/92106] [8 Regression] ICE with structured bindings and -Wreturn-local-addr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92106 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Marek Polacek --- Fixed.
[Bug c++/92106] [8 Regression] ICE with structured bindings and -Wreturn-local-addr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92106 --- Comment #9 from Marek Polacek --- Author: mpolacek Date: Tue Oct 22 17:46:12 2019 New Revision: 277296 URL: https://gcc.gnu.org/viewcvs?rev=277296=gcc=rev Log: PR c++/92106 - ICE with structured bindings and -Wreturn-local-addr. * typeck.c (maybe_warn_about_returning_address_of_local): Avoid recursing on null initializer and return false instead. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp1z/decomp50.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/typeck.c
[Bug c++/91548] [10 Regression] Regression in constexpr evaluation of std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91548 --- Comment #4 from Marek Polacek --- (In reply to Hannes Hauswedell from comment #2) > Any news on this issue? We are using this pattern in some rather central > files in our library and the bug literally breaks 90% of our unit tests so > we can't keep track of other gcc10 issues or try the new concepts support... > > Thank you for your help! BTW, is the library publicly accessible? If it is, I could try to compile it when I have a fix for this to make sure it's resolved.
[Bug rtl-optimization/92180] Missed optimization on casting __builtin_ia32_rdtsc result to int32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92180 --- Comment #4 from Segher Boessenkool --- For x86 it may be because targetm.class_likely_spilled_p is true for ax, and then indeed cant_combine_insn_p is true. See r53531, the mail thread for that patch starts at https://gcc.gnu.org/ml/gcc-patches/2002-05/msg01216.html .
[Bug rtl-optimization/92180] Missed optimization on casting __builtin_ia32_rdtsc result to int32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92180
--- Comment #3 from Jakub Jelinek ---
It is cant_combine_insn_p that returns true on insn 14
(insn 5 2 6 2 (parallel [
(set (reg:DI 84)
(unspec_volatile:DI [
(const_int 0 [0])
] UNSPECV_RDTSC))
(set (reg:DI 85)
(unspec_volatile:DI [
(const_int 0 [0])
] UNSPECV_RDTSC))
]) "pr92180.c":4:10 1049 {rdtsc_rex64}
(nil))
(insn 6 5 7 2 (parallel [
(set (reg:DI 85)
(ashift:DI (reg:DI 85)
(const_int 32 [0x20])))
(clobber (reg:CC 17 flags))
]) "pr92180.c":4:10 564 {*ashldi3_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 7 6 14 2 (parallel [
(set (reg:DI 84)
(ior:DI (reg:DI 84)
(reg:DI 85)))
(clobber (reg:CC 17 flags))
]) "pr92180.c":4:10 454 {*iordi_1}
(expr_list:REG_DEAD (reg:DI 85)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 14 7 15 2 (set (reg/i:SI 0 ax)
(subreg:SI (reg:DI 84) 0)) "pr92180.c":5:1 67 {*movsi_internal}
(expr_list:REG_DEAD (reg:DI 84)
(nil)))
because ax is targetm.class_likely_spilled_p.
[Bug rtl-optimization/92180] Missed optimization on casting __builtin_ia32_rdtsc result to int32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92180 --- Comment #2 from Segher Boessenkool --- Combine *does* combine setters of hard registers. nonzero_bits is not reliable, it depends on the order things are tried in.
[Bug rtl-optimization/92180] Missed optimization on casting __builtin_ia32_rdtsc result to int32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92180
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||segher at gcc dot gnu.org,
||uros at gcc dot gnu.org
Component|tree-optimization |rtl-optimization
--- Comment #1 from Jakub Jelinek ---
I think that is because the combiner doesn't even try to combine into
instruction setting a hard register.
Consider:
unsigned int
foo (void)
{
return __builtin_ia32_rdtsc ();
}
void
bar (unsigned int *p)
{
*p = __builtin_ia32_rdtsc ();
}
Both have pretty much the same code before the combine, except
(insn 14 7 15 2 (set (reg/i:SI 0 ax)
(subreg:SI (reg:DI 84) 0)) "pr92180.c":5:1 67 {*movsi_internal}
(expr_list:REG_DEAD (reg:DI 84)
(nil)))
(insn 15 14 0 2 (use (reg/i:SI 0 ax)) "pr92180.c":5:1 -1
(nil))
in foo and
(insn 10 8 0 2 (set (mem:SI (reg/v/f:DI 84 [ p ]) [1 *p_5(D)+0 S4 A32])
(subreg:SI (reg:DI 85) 0)) "pr92180.c":10:6 67 {*movsi_internal}
(expr_list:REG_DEAD (reg:DI 85)
(expr_list:REG_DEAD (reg/v/f:DI 84 [ p ])
(nil
in bar.
For bar, combine uses the nonzero_bits to optimize the (unsigned int) ((x <<
32) | y) into (unsigned int) y, but in foo, probably because of the hard
register in there, it doesn't try anything. Of course propagating anything
into an insn setting a hard register is risky, but in this case we'd just
replace one pseudo in the SUBREG_REG of the SET_SRC with another one.
GIMPLE optimizations can't do anything here, because the (x << 32) | y isn't
exposed there, we'd need a builtin with two return values for that kind of
thing.
[Bug c++/92181] initializer_list & string_view result in "modification of '' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92181 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Changed in r261086.
[Bug c++/91979] Incorrect mangling for non-template-argument nullptr expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91979 --- Comment #4 from Kamlesh Kumar --- patch posted at https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01585.html
[Bug c++/92181] initializer_list & string_view result in "modification of '' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92181
Robrecht Dewaele changed:
What|Removed |Added
URL||https://godbolt.org/z/baRg-
||1
--- Comment #1 from Robrecht Dewaele ---
The following code was tested on most clang and GCC compilers available on
Godbolt, and my local machine running Arch Linux, gcc (GCC) 9.2.0.
Starting from GCC version 9, the following code results in a compile-time
error:
"modification of '' is not a constant expression"
on the line with the closing brace of the initializer_list initialization.
Code on Godbolt (has some extras compared to the minimal version below):
https://godbolt.org/z/baRg-1
// start of source code
#include
#include
struct S { const int i; };
constexpr std::initializer_list foo{
{ []() { return std::string_view("").compare(""); }() }
};
// end of source code
Another version I tested with used a constexpr function rather than a lambda,
with the same failing result.
I have also tried replacing the lambda body with a simple "return true;" which
fixes the error.
[Bug c++/92159] -Wenum-conversion for C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92159 Jonathan Wakely changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #5 from Jonathan Wakely --- Thanks, let's close this then.
[Bug c++/92181] New: initializer_list & string_view result in "modification of '' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92181 Bug ID: 92181 Summary: initializer_list & string_view result in "modification of '' is not a constant expression Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: robrecht.dewaele at pegus dot digital Target Milestone: ---
[Bug fortran/92174] runtime error: index 15 out of bounds for type 'gfc_expr *[15]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92174 --- Comment #6 from Steve Kargl --- On Tue, Oct 22, 2019 at 02:56:01PM +, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92174 > > --- Comment #5 from Martin Liška --- > > Problem is that the compiler invokes an undefined behaviour for the source > file. > > More precisely, it's an out of bounds array access. > Which is irrelevant as the gfortran diagnosis the issue, issues an error meesage, and exits.
[Bug tree-optimization/92180] New: Missed optimization on casting __builtin_ia32_rdtsc result to int32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92180
Bug ID: 92180
Summary: Missed optimization on casting __builtin_ia32_rdtsc
result to int32
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: mserdarsanli at gmail dot com
Target Milestone: ---
Link: https://godbolt.org/z/wcIN0a
#include
uint32_t foo1() {
return __builtin_ia32_rdtsc();
}
uint64_t foo2() {
return __builtin_ia32_rdtsc();
}
Generates assembly:
foo1():
rdtsc
sal rdx, 32
or rax, rdx
ret
foo2():
rdtsc
sal rdx, 32
or rax, rdx
ret
While clang generates better code for foo1
foo1(): # @foo1()
rdtsc
ret
[Bug c++/92159] -Wenum-conversion for C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92159
--- Comment #4 from Jonny Grant ---
My apologies, I tested with the correct test case and it already does not
compile in C++ as desired, so no -Wenum-conversion required.
#include
typedef enum {brandon, jon, mitch} name_t;
typedef enum {fred, dog, cat} name2_t;
name2_t name = brandon;
name_t hik = 3;
int hal_entry(void)
{
if (hik < name)
return(0);
return 1;
}
int main ()
{
printf ("%d\n", hal_entry());
return 0;
}
[Bug c++/92062] [9 Regression] ODR-use by static_assert ignored for static member of class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92062 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Marek Polacek --- Fixed.
[Bug c++/92062] [9 Regression] ODR-use by static_assert ignored for static member of class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92062 --- Comment #7 from Marek Polacek --- Author: mpolacek Date: Tue Oct 22 15:46:47 2019 New Revision: 277295 URL: https://gcc.gnu.org/viewcvs?rev=277295=gcc=rev Log: PR c++/92062 - ODR-use ignored for static member of class template. * pt.c (has_value_dependent_address): Strip location wrappers. * g++.dg/cpp0x/constexpr-odr1.C: New test. * g++.dg/cpp0x/constexpr-odr2.C: New test. Added: branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-odr1.C branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-odr2.C Modified: branches/gcc-9-branch/gcc/cp/ChangeLog branches/gcc-9-branch/gcc/cp/pt.c
[Bug c++/92158] Enum warning when -1 enum converted to unsigned int or int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92158
--- Comment #4 from Jonny Grant ---
Hello
Implicit conversion can introduce bugs. I would like to detect implicit enum
conversions to other types in C and C++. How about just adding the C++ warnings
first to match clang in example below?
The following example does produce warnings in C++ with Clang trunk, but not C.
Likewise with MSVC, C++ warning, but no C warning.
G++ only warns on line (19), clang has the additional line (15) and line (17)
warnings.
Could G++ also add the additions warnings?
-O2 -Wall -Wextra -Wconversion -Werror
#include
typedef enum
{
a = -1
} a_t;
a_t f()
{
return a;
}
int main()
{
unsigned int b = f();
a_t test = b;
printf("%u %u", test, b);
return b;
}
#1 with x86-64 clang (trunk)
:15:22: error: implicit conversion changes signedness: 'a_t' to
'unsigned int' [-Werror,-Wsign-conversion]
unsigned int b = f();
~ ^~~
:17:9: error: cannot initialize a variable of type 'a_t' with an lvalue
of type 'unsigned int'
a_t test = b;
^ ~
:19:12: error: implicit conversion changes signedness: 'unsigned int'
to 'int' [-Werror,-Wsign-conversion]
return b;
~~ ^
3 errors generated.
Compiler returned: 1
#1 with x64 msvc v19.22
example.cpp
(18): error C2440: 'initializing': cannot convert from 'unsigned int'
to 'a_t'
(18): note: Conversion to enumeration type requires an explicit cast
(static_cast, C-style cast or function-style cast)
Compiler returned: 2
x86-64 gcc (trunk) - 484ms
#1 with x86-64 gcc (trunk)
: In function 'int main()':
:17:16: error: invalid conversion from 'unsigned int' to 'a_t'
[-fpermissive]
17 | a_t test = b;
|^
||
|unsigned int
Compiler returned: 1
[Bug c++/91891] [7 Regression] std::function with lambda default initializer in aggregate construction causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91891
--- Comment #4 from Peter Bindels ---
For posterity,
#include
#include
#include
#include
#include
template
std::future make_ready_future(T t);
struct y
{
intv;
std::function v2 = [this]() { v; };
};
template
auto xx(Ts... ts)
{
return make_ready_future(y{ ts... });
}
int main() {
auto f = xx();
}
[Bug tree-optimization/92179] New: [10 regression] r277288 causes ICEs compiling several test cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92179 Bug ID: 92179 Summary: [10 regression] r277288 causes ICEs compiling several test cases Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- > FAIL: gcc.dg/vect/pr33953.c (internal compiler error) > FAIL: gcc.dg/vect/pr33953.c (test for excess errors) > FAIL: gcc.dg/vect/pr33953.c -flto -ffat-lto-objects scan-tree-dump-times > vect "vectorized 1 loops" 1 > FAIL: gcc.dg/vect/pr33953.c -flto -ffat-lto-objects scan-tree-dump-times > vect "vectorizing stmts using SLP" 1 > FAIL: gcc.dg/vect/pr33953.c -flto -ffat-lto-objects (internal compiler error) > FAIL: gcc.dg/vect/pr33953.c -flto -ffat-lto-objects (test for excess errors) > FAIL: gcc.dg/vect/pr33953.c scan-tree-dump-times vect "vectorized 1 loops" 1 > FAIL: gcc.dg/vect/pr33953.c scan-tree-dump-times vect "vectorizing stmts > using SLP" 1 > FAIL: gcc.dg/vect/slp-36.c (internal compiler error) > FAIL: gcc.dg/vect/slp-36.c (test for excess errors) > FAIL: gcc.dg/vect/slp-36.c -flto -ffat-lto-objects (internal compiler error) > FAIL: gcc.dg/vect/slp-36.c -flto -ffat-lto-objects (test for excess errors) > FAIL: gcc.target/powerpc/sse2-psrlq-2.c (internal compiler error) > FAIL: gcc.target/powerpc/sse2-psrlq-2.c (test for excess errors) They are all in this same spot: Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/sse2-psrlq-2.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -O3 -mpower8-vector -Wno-psabi -lm -o ./sse2-psrlq-2.exe(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/sse2-psrlq-2.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -O3 -mpower8-vector -Wno-psabi -lm -o ./sse2-psrlq-2.exe during GIMPLE pass: slp In file included from /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/sse2-psrlq-2.c:9: /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/sse2-check.h: In function 'do_test': /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/sse2-check.h:18:1: internal compiler error: in vectorizable_shift, at tree-vect-stmts.c:5836 0x10df15a3 vectorizable_shift /home/seurer/gcc/gcc-test2/gcc/tree-vect-stmts.c:5836 0x10e0aceb vect_transform_stmt(_stmt_vec_info*, gimple_stmt_iterator*, _slp_tree*, _slp_instance*) /home/seurer/gcc/gcc-test2/gcc/tree-vect-stmts.c:10835 0x10e3ba0f vect_schedule_slp_instance /home/seurer/gcc/gcc-test2/gcc/tree-vect-slp.c:3966 0x10e3b71b vect_schedule_slp_instance /home/seurer/gcc/gcc-test2/gcc/tree-vect-slp.c:3860 0x10e3b71b vect_schedule_slp_instance /home/seurer/gcc/gcc-test2/gcc/tree-vect-slp.c:3860 0x10e3e08b vect_schedule_slp(vec_info*) /home/seurer/gcc/gcc-test2/gcc/tree-vect-slp.c:4040 0x10e42607 vect_slp_bb_region /home/seurer/gcc/gcc-test2/gcc/tree-vect-slp.c:3092 0x10e42607 vect_slp_bb(basic_block_def*) /home/seurer/gcc/gcc-test2/gcc/tree-vect-slp.c:3186 0x10e45d7b execute /home/seurer/gcc/gcc-test2/gcc/tree-vectorizer.c:1309
[Bug c++/92106] [8/9 Regression] ICE with structured bindings and -Wreturn-local-addr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92106 --- Comment #8 from Marek Polacek --- Author: mpolacek Date: Tue Oct 22 15:21:34 2019 New Revision: 277294 URL: https://gcc.gnu.org/viewcvs?rev=277294=gcc=rev Log: PR c++/92106 - ICE with structured bindings and -Wreturn-local-addr. * typeck.c (maybe_warn_about_returning_address_of_local): Avoid recursing on null initializer and return false instead. Added: branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp1z/decomp50.C Modified: branches/gcc-9-branch/gcc/cp/ChangeLog branches/gcc-9-branch/gcc/cp/typeck.c
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 --- Comment #1 from Vladimir Fuka --- It also crashes with passing just a(1) instead of (a(1)) and when removing the value attribute.
[Bug fortran/92178] New: Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 Bug ID: 92178 Summary: Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: vladimir.fuka at gmail dot com Target Milestone: --- This code crashes at the allocated() call with GCC 7,8,9. I am not completely sure all aliasing rules, but I think it should be fine. implicit none integer, allocatable :: a(:) allocate(a, source=[1]) call assign(a, (a(1))) print *, allocated(a) contains subroutine assign(a, b) integer, allocatable, intent(out) :: a(:) integer, value :: b end subroutine end program based on https://stackoverflow.com/questions/58504284/assignment-of-allocatable-array-with-itself-values/58506248#58506248 > gfortran -fsanitize=address -g -fbacktrace assign.f90 > ./a.out ASAN:DEADLYSIGNAL = ==19756==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 0x00401354 bp 0x7ffd1a55b460 sp 0x7ffd1a55b0e0 T0) ==19756==The signal is caused by a READ memory access. ==19756==Hint: address points to the zero page. #0 0x401353 in MAIN__ /home/lada/f/testy/stackoverflow/assign.f90:9 #1 0x401631 in main /home/lada/f/testy/stackoverflow/assign.f90:9 #2 0x7fb2b52cef89 in __libc_start_main (/lib64/libc.so.6+0x20f89) #3 0x400c89 in _start (/home/lada/f/testy/stackoverflow/a.out+0x400c89) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /home/lada/f/testy/stackoverflow/assign.f90:9 in MAIN__ ==19756==ABORTING
[Bug c++/91930] [10 Regression] internal compiler error: in lazily_declare_fn, at cp/method.c:2423 with -fconcepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91930 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jason Merrill --- Fixed.
[Bug gcov-profile/91971] Profile directory concatenated with object file path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91971 --- Comment #4 from Martin Liška --- (In reply to qinzhao from comment #3) > (In reply to Martin Liška from comment #2) > > Confirmed. Can you please send the patch to mailing list? > > I have sent the patch to gcc-patches several weeks ago, and pinged twice > already: > > https://gcc.gnu.org/ml/gcc-patches//2019-10/msg01506.html Good, I'll make a review tomorrow. For the next time, please add me to CC of the email. > > are you the reviewer for this? I am, I was on vacation for almost 4 weeks, so that's why you haven't received a patch review ;)
[Bug gcov-profile/91971] Profile directory concatenated with object file path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91971 --- Comment #3 from qinzhao at gcc dot gnu.org --- (In reply to Martin Liška from comment #2) > Confirmed. Can you please send the patch to mailing list? I have sent the patch to gcc-patches several weeks ago, and pinged twice already: https://gcc.gnu.org/ml/gcc-patches//2019-10/msg01506.html are you the reviewer for this?
[Bug fortran/92174] runtime error: index 15 out of bounds for type 'gfc_expr *[15]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92174 --- Comment #5 from Martin Liška --- > Problem is that the compiler invokes an undefined behaviour for the source file. More precisely, it's an out of bounds array access.
[Bug fortran/92174] runtime error: index 15 out of bounds for type 'gfc_expr *[15]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92174
--- Comment #4 from Martin Liška ---
(In reply to Steve Kargl from comment #3)
> On Tue, Oct 22, 2019 at 02:14:55PM +, marxin at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92174
> >
> > --- Comment #2 from Martin Liška ---
> > (In reply to kargl from comment #1)
> > > (In reply to Martin Liška from comment #0)
> > > > Happens with UBSAN build in:
> > > >
> > > > $ ./xgcc -B.
> > > > /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/pr91802.f90
> > > > -fcoarray=single
> > > > ../../gcc/fortran/array.c:867:36: runtime error: index 15 out of bounds
> > > > for
> > > > type 'gfc_expr *[15]'
> > >
> > >
> > > What are you doing? pr91802.f90 is a compile time test.
> > > It cannot generate a runtime error.
> >
> > It's a runtime error of the GCC compiler that compiles the test-case ;)
> > The error message is a bit misleading.
> >
>
> So, what does your tool do? gfortran correctly diagnosis
> that rank+corank > 15, issues an error, and exits. What is
> the problem?
Problem is that the compiler invokes an undefined behaviour for the source
file.
You can see the same with the following patch:
diff --git a/gcc/fortran/array.c b/gcc/fortran/array.c
index 427110bee74..166caca8347 100644
--- a/gcc/fortran/array.c
+++ b/gcc/fortran/array.c
@@ -864,6 +864,7 @@ gfc_set_array_spec (gfc_symbol *sym, gfc_array_spec *as,
locus *error_loc)
sym->as->corank = as->corank;
for (i = 0; i < as->corank; i++)
{
+ gcc_assert (sym->as->rank + i < GFC_MAX_DIMENSIONS);
sym->as->lower[sym->as->rank + i] = as->lower[i];
sym->as->upper[sym->as->rank + i] = as->upper[i];
}
$ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/pr91802.f90
-fcoarray=single
f951: internal compiler error: in gfc_set_array_spec, at fortran/array.c:867
0x880e62 gfc_set_array_spec(gfc_symbol*, gfc_array_spec*, locus*)
/home/marxin/Programming/gcc/gcc/fortran/array.c:867
0x8b3f6d attr_decl1
/home/marxin/Programming/gcc/gcc/fortran/decl.c:8521
0x8b4114 attr_decl
/home/marxin/Programming/gcc/gcc/fortran/decl.c:8582
0x8b46f0 gfc_match_codimension()
/home/marxin/Programming/gcc/gcc/fortran/decl.c:8855
0x93dd54 match_word
/home/marxin/Programming/gcc/gcc/fortran/parse.c:65
0x93efcb decode_statement
/home/marxin/Programming/gcc/gcc/fortran/parse.c:464
0x944185 next_free
/home/marxin/Programming/gcc/gcc/fortran/parse.c:1272
0x944727 next_statement
/home/marxin/Programming/gcc/gcc/fortran/parse.c:1504
0x947bf0 parse_spec
/home/marxin/Programming/gcc/gcc/fortran/parse.c:3902
0x94b747 parse_module
/home/marxin/Programming/gcc/gcc/fortran/parse.c:6085
0x94c15b gfc_parse_file()
/home/marxin/Programming/gcc/gcc/fortran/parse.c:6390
0x9ad167 gfc_be_parse_file
/home/marxin/Programming/gcc/gcc/fortran/f95-lang.c:208
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/91363] Implement P0960R3: Parenthesized initialization of aggregates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91363 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #2 from Marek Polacek --- https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01578.html
[Bug tree-optimization/85887] [7/8/9/10 Regression] Missing DW_TAG_lexical_block PC range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85887 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Tue Oct 22 14:52:52 2019 New Revision: 277293 URL: https://gcc.gnu.org/viewcvs?rev=277293=gcc=rev Log: PR tree-optimization/85887 * decl.c (expand_static_init): Drop ECF_LEAF from __cxa_guard_acquire and __cxa_guard_release. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c
[Bug c++/90938] [9/10 Regression] Initializing array with {1} works, but not {0}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90938 --- Comment #10 from Jakub Jelinek --- There is no cutoff for 9.x (well, in about 2 years from now the branch will be closed), but the branch is used by people in the wild, so especially for regressions from recent releases the sooner it is fixed the better. Of course assuming the fix is safe.
[Bug c++/85746] Premature evaluation of __builtin_constant_p?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85746 Marc Glisse changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Marc Glisse --- Fixed in gcc-10.
[Bug preprocessor/90476] prepossessor should error if #line 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90476 --- Comment #9 from Jonny Grant --- Maybe it could say warning: line number out of range 1 - 2147483647
[Bug c++/85746] Premature evaluation of __builtin_constant_p?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85746 --- Comment #9 from Marc Glisse --- Author: glisse Date: Tue Oct 22 14:42:38 2019 New Revision: 277292 URL: https://gcc.gnu.org/viewcvs?rev=277292=gcc=rev Log: PR c++/85746: Don't fold __builtin_constant_p prematurely 2019-10-22 Marc Glisse gcc/cp/ * constexpr.c (cxx_eval_builtin_function_call): Only set force_folding_builtin_constant_p if manifestly_const_eval. gcc/testsuite/ * g++.dg/pr85746.C: New file. Added: trunk/gcc/testsuite/g++.dg/pr85746.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/testsuite/ChangeLog
[Bug preprocessor/90476] prepossessor should error if #line 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90476 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||msebor at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #8 from Martin Sebor --- C makes it a constraint that in the #line directive: The digit sequence shall not specify zero, nor a number greater than 2147483647. Both GCC and G++ issue a pedantic warning for the directive so I think they both do the right thing and already implement the requested behavior. There could be a warning option to control this warning separately from others but that seems like a separate issue that applies to a number of other warnings as well. gcc -O2 -S -Wall -Wextra -Wpedantic -xc++ /build/tmp/a.c pr90476.c:1:7: warning: line number out of range 1 | #line 0 | ^ pr90476.c: error: ‘mytypo’ does not name a type With that I think this can be resolved.
[Bug sanitizer/92154] new glibc breaks arm bootstrap due to libsanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92154 --- Comment #2 from Tamar Christina --- Author: tnfchris Date: Tue Oct 22 14:25:38 2019 New Revision: 277291 URL: https://gcc.gnu.org/viewcvs?rev=277291=gcc=rev Log: Arm: Fix arm libsanitizer bootstrap failure Glibc has recently introduced changed to the mode field in ipc_perm in commit 2f959dfe849e0646e27403f2e4091536496ac0f0. For Arm this means that the mode field no longer has the same size. This causes an assert failure against libsanitizer's internal copy of ipc_perm. Since this change can't be easily detected I am adding arm to the list of targets that are excluded from this check. libsanitizer doesn't use this field (and others, it in fact uses only 1 field) so this check can be ignored. Padding bits were used by glibc when the field was changed so sizeof and offsets of the remaining fields should be the same. libsanitizer/ChangeLog: PR sanitizer/92154 * sanitizer_common/sanitizer_platform_limits_posix.cpp (defined): Cherry-pick compiler-rt revision r375220. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp
[Bug fortran/92174] runtime error: index 15 out of bounds for type 'gfc_expr *[15]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92174 --- Comment #3 from Steve Kargl --- On Tue, Oct 22, 2019 at 02:14:55PM +, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92174 > > --- Comment #2 from Martin Liška --- > (In reply to kargl from comment #1) > > (In reply to Martin Liška from comment #0) > > > Happens with UBSAN build in: > > > > > > $ ./xgcc -B. > > > /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/pr91802.f90 > > > -fcoarray=single > > > ../../gcc/fortran/array.c:867:36: runtime error: index 15 out of bounds > > > for > > > type 'gfc_expr *[15]' > > > > > > What are you doing? pr91802.f90 is a compile time test. > > It cannot generate a runtime error. > > It's a runtime error of the GCC compiler that compiles the test-case ;) > The error message is a bit misleading. > So, what does your tool do? gfortran correctly diagnosis that rank+corank > 15, issues an error, and exits. What is the problem?
[Bug c++/90938] [9/10 Regression] Initializing array with {1} works, but not {0}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90938 --- Comment #9 from Martin Sebor --- I plan to submit a patch for GCC 10 and (hopefully) also GCC 9.x. What's the cutoff for 9?
[Bug fortran/92174] runtime error: index 15 out of bounds for type 'gfc_expr *[15]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92174 --- Comment #2 from Martin Liška --- (In reply to kargl from comment #1) > (In reply to Martin Liška from comment #0) > > Happens with UBSAN build in: > > > > $ ./xgcc -B. > > /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/pr91802.f90 > > -fcoarray=single > > ../../gcc/fortran/array.c:867:36: runtime error: index 15 out of bounds for > > type 'gfc_expr *[15]' > > > What are you doing? pr91802.f90 is a compile time test. > It cannot generate a runtime error. It's a runtime error of the GCC compiler that compiles the test-case ;) The error message is a bit misleading.
[Bug fortran/92174] runtime error: index 15 out of bounds for type 'gfc_expr *[15]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92174 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to Martin Liška from comment #0) > Happens with UBSAN build in: > > $ ./xgcc -B. > /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/pr91802.f90 > -fcoarray=single > ../../gcc/fortran/array.c:867:36: runtime error: index 15 out of bounds for > type 'gfc_expr *[15]' What are you doing? pr91802.f90 is a compile time test. It cannot generate a runtime error.
[Bug tree-optimization/92177] [10 regression] gcc.dg/vect/bb-slp-22.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92177
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2019-10-22
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Ah, thanks - that might be an undesided side-effect of r277241
We now vectorize
out[0] = a0 * x;
out[1] = a1 * y;
out[2] = a2 * x;
out[3] = a3 * y;
as
_5 = a0_40 * x_44(D);
_6 = a1_41 * y_45(D);
_7 = a2_42 * x_44(D);
_8 = a3_43 * y_45(D);
_66 = {_7, _8};
vect_cst__67 = _66;
_68 = {_5, _6};
vect_cst__69 = _68;
MEM [(unsigned int *)] = vect_cst__69;
_71 = [0] + 8;
MEM [(unsigned int *)_71] = vect_cst__67;
since we're no longer fencing the build-from-scalar code via
&& !SLP_TREE_CHILDREN (child).is_empty () (previously we had no
SLP children nodes for the SLP node representing the multiplication).
So the test is no longer testing vectorization of multiplications.
It also shows that BB vectorizing this function at strict basic-block
boundaries is suboptimal.
I'll see what to best do here, clearly a sort-term fix would be to
change the code to make vectorization of the multiplication more
obviously profitable.
[Bug ipa/92109] [10 Regression] ICE in modify_call_stmt, at ipa-param-manipulation.c:1586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92109 Martin Liška changed: What|Removed |Added CC||jamborm at gcc dot gnu.org Known to work||9.2.0 Known to fail||10.0 --- Comment #2 from Martin Liška --- Ok, now I have just isolated 4 pre-processed source files and I'm reducing these ..
[Bug tree-optimization/92166] [10 regression] ICE compiling gcc.dg/vshift-5.c starting with r277241
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92166 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Richard Biener --- Fixed.
[Bug tree-optimization/92173] [10 Regression] ICE in optab_for_tree_code, at optabs-tree.c:81
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92173 --- Comment #4 from Richard Biener --- Author: rguenth Date: Tue Oct 22 13:08:53 2019 New Revision: 277288 URL: https://gcc.gnu.org/viewcvs?rev=277288=gcc=rev Log: 2019-10-22 Richard Biener PR tree-optimization/92173 * tree-vect-loop.c (vectorizable_reduction): If vect_transform_reduction cannot handle code-generation try without the single-def-use-cycle optimization. Pass optab_vector to optab_for_tree_code to get vector shifts as that's what we'd generate. * gcc.dg/torture/pr92173.c: New testcase. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vshift-5.c trunk/gcc/tree-vect-slp.c trunk/gcc/tree-vect-stmts.c
[Bug c++/91826] [8/9/10 Regression] Unexpected behavior when class defined with namespace alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91826 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.4
[Bug lto/89075] [9/10 Regression] error: type variant has different TREE_TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89075 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.3
[Bug c++/91607] [9 regression] internal compiler error: in equal, at cp/constexpr.c:1088
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91607 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.3
[Bug libstdc++/90415] [9/10 Regression] std::is_copy_constructible> is incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90415 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.3
[Bug rtl-optimization/90706] [9 Regression] Useless code generated for stack / register operations on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.3
[Bug ipa/91969] Compiling testsuite/g++.dg/ipa/pr85421.C with -fdump-ipa-inline ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91969 Martin Liška changed: What|Removed |Added Keywords||patch --- Comment #3 from Martin Liška --- Patch candidate: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01563.html
[Bug target/87833] [9/10 Regression] -fPIC isn't used to create offload shared library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87833 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.3
[Bug ada/91100] [9,10 Regression] FAIL: gnat.dg/socket1.adb execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91100 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.3
[Bug tree-optimization/90264] [9/10 Regression] -Wnull-dereference QoI issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90264 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.3
[Bug c++/90291] [8/9/10 Regression] Inline namespace erroneously extends another namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90291 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.4
[Bug c++/67960] [8/9/10 Regression] Prefixing a function with [[deprecated]] produces multiple warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67960 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.4
[Bug bootstrap/87338] [8/9 Regression] gcc 8.2 fails to bootstrap on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87338 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.4
[Bug c/88660] [8/9/10 Regression] Invalid report of "set but used variable" with -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88660 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.4
[Bug c++/91891] [7 Regression] std::function with lambda default initializer in aggregate construction causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91891 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/92105] [7/8/9/10 Regression] decltype(decltype(decltype)) prints exponential number of repeated errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92105 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug debug/91887] [7/8/9 Regression] -fdebug-types-section ICE building chromium
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91887 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/92177] [10 regression] gcc.dg/vect/bb-slp-22.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92177 Rainer Orth changed: What|Removed |Added Target Milestone|--- |10.0
[Bug target/91816] [7/8/9/10 Regression] Arm generates out of range conditional branches in Thumb2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91816 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/92177] New: [10 regression] gcc.dg/vect/bb-slp-22.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92177 Bug ID: 92177 Summary: [10 regression] gcc.dg/vect/bb-slp-22.c FAILs Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: sparc-sun-solaris2.11 Created attachment 47085 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47085=edit 32-bit sparc-sun-solaris2.11 bb-slp-22.c.168t.slp2 Between 20191016 (r277071) and 20191021 (r277261), gcc.dg/vect/bb-slp-22.c began to FAIL on 32 and 64-bit SPARC: +FAIL: gcc.dg/vect/bb-slp-22.c -flto -ffat-lto-objects scan-tree-dump-times slp2 "basic block vectorized" 1 +FAIL: gcc.dg/vect/bb-slp-22.c scan-tree-dump-times slp2 "basic block vectorized" 1 The message now appears twice, so this is clearly progress, but the guards need to be adapted. Dump attached.
[Bug middle-end/91623] [7/8 Regression] -msse4.1 -O3 segfault in /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/smmintrin.h:270:10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91623 Richard Biener changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Priority|P3 |P2 Known to work||9.2.1 Known to fail||9.2.0
[Bug tree-optimization/91812] [7/8 Regression] GCC ignores volatile modifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91812 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug preprocessor/90476] prepossessor should error if #line 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90476 --- Comment #7 from Jonny Grant --- Could someone confirm this please.
[Bug tree-optimization/91384] [7/8/9/10 Regression] Compare with negation is not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91384 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2019-10-22 Ever confirmed|0 |1
[Bug lto/91273] [7/8/9/10 Regression] ICE in warn_types_mismatch at ipa-devirt.c:995
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91273 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/91241] [7/8/9/10 Regression] internal compiler error: symtab_node::verify failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91241 Richard Biener changed: What|Removed |Added Keywords||ice-checking Priority|P3 |P2 --- Comment #5 from Richard Biener --- Honza?
[Bug tree-optimization/91201] [7/8/9/10 Regression] SIMD not generated for horizontal sum of bytes in array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91201
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #25 from Richard Biener ---
We unroll the loop completely but our basic-block vectorization capabilities do
not include reductions. We see the following there:
[local count: 357878154]:
temp_33 = bytes[0];
_34 = temp_33 >> 32;
temp_35 = temp_33 + _34;
_36 = temp_35 >> 16;
temp_37 = temp_35 + _36;
_38 = temp_37 >> 8;
temp_44 = bytes[1];
_45 = temp_44 >> 32;
temp_46 = temp_44 + _45;
_47 = temp_46 >> 16;
temp_48 = temp_46 + _47;
_40 = temp_37 + temp_48;
_49 = temp_48 >> 8;
_51 = _38 + _40;
result_29 = _49 + _51;
_20 = (unsigned char) result_29;
b ={v} {CLOBBER};
return _20;
[Bug middle-end/90796] [8/9 Regression] GCC: O2 vs O3 output differs on simple test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796 Michael Matz changed: What|Removed |Added Summary|[8/9/10 Regression] GCC: O2 |[8/9 Regression] GCC: O2 vs |vs O3 output differs on |O3 output differs on simple |simple test |test Known to fail|10.0| --- Comment #13 from Michael Matz --- Fixed in trunk so far. Will be backporting in a few days.
[Bug middle-end/90796] [8/9/10 Regression] GCC: O2 vs O3 output differs on simple test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796 --- Comment #12 from Michael Matz --- Author: matz Date: Tue Oct 22 12:25:03 2019 New Revision: 277287 URL: https://gcc.gnu.org/viewcvs?rev=277287=gcc=rev Log: Fix PR middle-end/90796 PR middle-end/90796 * gimple-loop-jam.c (any_access_function_variant_p): New function. (adjust_unroll_factor): Use it to constrain safety, new parameter. (tree_loop_unroll_and_jam): Adjust call and profitable unroll factor. testsuite/ * gcc.dg/unroll-and-jam.c: Add three invalid and one valid case. Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-loop-jam.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/unroll-and-jam.c
[Bug c++/91133] [7/8/9/10 Regression] Wrong "partial specialization is not more specialized than" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91133 Richard Biener changed: What|Removed |Added Priority|P3 |P2
