[Bug middle-end/88575] New: gcc got confused by different comparison operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88575
Bug ID: 88575
Summary: gcc got confused by different comparison operators
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
In test() gcc is not able to determine that for a==b it does not have to
evaluate 2nd comparison and can use value of a if 1st comparison is true. When
operators are swapped like in test2() or are the same, code is optimized.
[code]
double test(double a, double b)
{
if (a <= b)
return a < b ? a : b;
return 0.0;
}
double test2(double a, double b)
{
if (a < b)
return a <= b ? a : b;
return 0.0;
}
[/code]
[asm]
test(double, double):
vcomisd xmm1, xmm0
jnb .L10
vxorpd xmm0, xmm0, xmm0
ret
.L10:
vminsd xmm0, xmm0, xmm1
ret
test2(double, double):
vcmpnltsd xmm1, xmm0, xmm1
vxorpd xmm2, xmm2, xmm2
vblendvpd xmm0, xmm0, xmm2, xmm1
ret
[/asm]
[Bug c/88576] -fno-math-errno causes GCC to consider that malloc does not set errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88576 --- Comment #2 from Aurelien Jarno --- (In reply to Andrew Pinski from comment #1) > IIRC malloc setting errno also non standard. According to POSIX: The malloc() function shall fail if: [ENOMEM] [CX] [Option Start] Insufficient storage space is available. [Option End] In that case malloc returns a NULL pointer. However even after adding a check for the return value, GCC still optimizes-out saving and restoring errno.
[Bug fortran/88169] Rejects USE rename of namelist group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.5 --- Comment #16 from kargl at gcc dot gnu.org --- Fixed on trunk, branch-8, and branch-7. Thanks for the report. Closing.
[Bug c++/88577] New: misleading error message with template and auto return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88577
Bug ID: 88577
Summary: misleading error message with template and auto return
type
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
For the following code
template struct s{}
auto f() {}
g++ produces a rather misleading error message:
:3:1: error: multiple types in one declaration
3 | auto f() {}
| ^~~~
:3:5: error: expected ';' before 'f'
3 | auto f() {}
| ^~
| ;
If the template is removed, or the return type is changed the compiler suggest
the good place for the missing semi colon.
[Bug c++/88578] New: Static C++ objects with flexible array members overlap when initializes are non-const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88578
Bug ID: 88578
Summary: Static C++ objects with flexible array members overlap
when initializes are non-const
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
A modified version of flexary13.C fails an assertion when compiled with -O0
$ cat flexary13.C
// { dg-do compile }
// { dg-options -Wno-pedantic }
#define STR(s) #s
#define ASSERT(exp) \
((exp) ? (void)0 : (void)(__builtin_printf ("%s:%i: assertion %s failed\n", \
__FILE__, __LINE__, STR(exp)), \
__builtin_abort ()))
struct Ax { int n, a[]; };
struct AAx { int i; Ax ax; };
int i = 12345678;
int main ()
{
{
Ax s = { 0 };
ASSERT (s.n == 0);
}
{
static Ax s =
{ 0, { } }; // dg-warning "initialization of a flexible array member" }
ASSERT (s.n == 0);
}
{
static Ax s =
{ 1, { 2 } }; // dg-warning "initialization of a flexible array member"
}
ASSERT (s.n == 1 && s.a [0] == 2);
}
{
static Ax s =
{ 2, { 3, 4 } }; // dg-warning "initialization of a flexible array
member" }
ASSERT (s.n = 2 && s.a [0] == 3 && s.a [1] == 4);
}
{
static Ax s =
{ 123, i }; // dg-warning "initialization of a flexible array member" }
ASSERT (s.n == 123 && s.a [0] == i);
}
{
static Ax s =
{ 456, { i } }; // dg-warning "initialization of a flexible array member"
}
ASSERT (s.n == 456 && s.a [0] == i);
}
{
int j = i + 1, k = j + 1;
static Ax s =
{ 3, { i, j, k } }; // dg-warning "initialization of a flexible array
member" }
ASSERT (s.n == 3 && s.a [0] == i && s.a [1] == j && s.a [2] == k);
}
{
AAx s =
{ 1, { 2 } }; // dg-warning "initialization of a flexible array member"
}
ASSERT (s.i == 1 && s.ax.n == 2);
}
}
$ g++ -O0 flexary13.C
$ ./a.out
flexary13.C:44: assertion s.n == 456 && s.a [0] == i failed
Aborted (core dumped)
debugging shows that s.n == 12345678
reason is that in the case where flexible array members are initialized
with non-constant values (a C++ extension over C which rejects such code)
The static objects are allocated without the flexible part:
_ZZ4mainE1s_2:
.long 123
.local _ZGVZ4mainE1s_2
.comm _ZGVZ4mainE1s_2,8,8
.align 4
.type _ZZ4mainE1s_3, @object
.size _ZZ4mainE1s_3, 4
_ZZ4mainE1s_3:
.long 456
.local _ZGVZ4mainE1s_3
.comm _ZGVZ4mainE1s_3,8,8
.align 4
.type _ZZ4mainE1s_4, @object
.size _ZZ4mainE1s_4, 4
In higher optimization levels the objects still overlap,
but the assertion does not fire, which probably indicates
that it is ineffective (optimized away).
[Bug c/88576] -fno-math-errno causes GCC to consider that malloc does not set errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88576 --- Comment #4 from Andrew Pinski --- PR 42944
[Bug fortran/85798] ICE in get_array_index, at fortran/data.c:69
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85798 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Sat Dec 22 19:37:06 2018 New Revision: 267356 URL: https://gcc.gnu.org/viewcvs?rev=267356=gcc=rev Log: 2018-12-22 Steven G . Kargl PR fortran/85798 * decl.c (gfc_match_data): If a component of a derived type entity appears in data statement, check that does not have the allocatable attribute. 2018-12-22 Steven G . Kargl PR fortran/85798 * gfortran.dg/pr85798.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr85798.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog
[Bug c/88576] -fno-math-errno causes GCC to consider that malloc does not set errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88576 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #6 from Florian Weimer --- Has this got to do anything with errno? It seems to me that with -fno-math-errno, GCC assumes that malloc does not set *any* TLS variable. That doesn't look right to me.
[Bug fortran/88169] Rejects USE rename of namelist group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169 --- Comment #13 from kargl at gcc dot gnu.org --- Author: kargl Date: Sat Dec 22 17:26:12 2018 New Revision: 267351 URL: https://gcc.gnu.org/viewcvs?rev=267351=gcc=rev Log: 2018-12-21 Steven G. Kargl PR fortran/88169 * module.c (mio_namelist): Remove an error condition/message that is contrary to the Fortran standard. 2018-12-21 Steven G. Kargl PR fortran/88169 * gfortran.dg/pr88169_1.f90: new test. * gfortran.dg/pr88169_2.f90: Ditto. * gfortran.dg/pr88169_3.f90: Ditto. Added: trunk/gcc/testsuite/gfortran.dg/pr88169_1.f90 trunk/gcc/testsuite/gfortran.dg/pr88169_2.f90 trunk/gcc/testsuite/gfortran.dg/pr88169_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog
[Bug c/88576] New: -fno-math-errno causes GCC to consider that malloc does not set errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88576
Bug ID: 88576
Summary: -fno-math-errno causes GCC to consider that malloc
does not set errno
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: aurelien at aurel32 dot net
Target Milestone: ---
With the -fno-math-errno option, GCC optimizes-out saving and restoring errno
around a malloc call. Here is a testcase, derived from the GNU libc
string/strerror.c, to reproduce it:
typedef long unsigned int size_t;
extern char *__strerror_r (int __errnum, char *__buf, size_t __buflen);
extern void *malloc (size_t __size) __attribute__ ((__nothrow__)) __attribute__
((__malloc__));
extern __thread int __libc_errno __attribute__ ((tls_model ("initial-exec")));
static char *buf;
char *strerror (int errnum)
{
int saved_errno;
saved_errno = __libc_errno;
buf = malloc (1024);
(__libc_errno = (saved_errno));
return __strerror_r (errnum, buf, 1024);
}
Compile with: gcc -fmath-errno -Wall -O2 -fPIC -S -c strerror.i
Without -fno-math-errno, we can see in the output assembly code that errno is
saved around the malloc call:
strerror:
.LFB0:
.cfi_startproc
pushq %r12
.cfi_def_cfa_offset 16
.cfi_offset 12, -16
pushq %rbp
.cfi_def_cfa_offset 24
.cfi_offset 6, -24
movl%edi, %ebp
movl$1024, %edi
pushq %rbx
.cfi_def_cfa_offset 32
.cfi_offset 3, -32
movq__libc_errno@gottpoff(%rip), %rbx
movl%fs:(%rbx), %r12d
callmalloc@PLT
movl%ebp, %edi
movl$1024, %edx
movl%r12d, %fs:(%rbx)
movq%rax, %rsi
popq%rbx
.cfi_def_cfa_offset 24
popq%rbp
.cfi_def_cfa_offset 16
popq%r12
.cfi_def_cfa_offset 8
jmp __strerror_r@PLT
.cfi_endproc
With -fno-math-errno, saving and restoring errno is optimized out:
strerror:
.LFB0:
.cfi_startproc
pushq %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movl%edi, %ebx
movl$1024, %edi
callmalloc@PLT
movl%ebx, %edi
movl$1024, %edx
popq%rbx
.cfi_def_cfa_offset 8
movq%rax, %rsi
jmp __strerror_r@PLT
.cfi_endproc
This is reproducible with 6.5, 7.4, 8.2 and a snapshot of trunk from
2018-12-17.
[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64883 --- Comment #59 from Iain Sandoe --- Author: iains Date: Sat Dec 22 17:50:45 2018 New Revision: 267352 URL: https://gcc.gnu.org/viewcvs?rev=267352=gcc=rev Log: Backport fix for PR libstdc++/64883. Backport from mainline 2018-12-06 Jonathan Wakely Iain Sandoe PR libstdc++/64883 * testsuite/17_intro/headers/c++1998/all_attributes.cc: Don't test always_inline on Darwin. * testsuite/17_intro/headers/c++2011/all_attributes.cc: Likewise. * testsuite/17_intro/headers/c++2014/all_attributes.cc: Likewise. * testsuite/17_intro/headers/c++2017/all_attributes.cc: Likewise. * testsuite/17_intro/headers/c++2020/all_attributes.cc: Likewise. Modified: branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc branches/gcc-8-branch/libstdc++-v3/testsuite/17_intro/headers/c++2011/all_attributes.cc branches/gcc-8-branch/libstdc++-v3/testsuite/17_intro/headers/c++2014/all_attributes.cc
[Bug fortran/88169] Rejects USE rename of namelist group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169 --- Comment #14 from kargl at gcc dot gnu.org --- Author: kargl Date: Sat Dec 22 17:53:00 2018 New Revision: 267353 URL: https://gcc.gnu.org/viewcvs?rev=267353=gcc=rev Log: 2018-12-21 Steven G. Kargl PR fortran/88169 * module.c (mio_namelist): Remove an error condition/message that is contrary to the Fortran standard. 2018-12-21 Steven G. Kargl PR fortran/88169 * gfortran.dg/pr88169_1.f90: new test. * gfortran.dg/pr88169_2.f90: Ditto. * gfortran.dg/pr88169_3.f90: Ditto. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr88169_1.f90 branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr88169_2.f90 branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr88169_3.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/module.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c/88576] -fno-math-errno causes GCC to consider that malloc does not set errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88576 --- Comment #1 from Andrew Pinski --- IIRC malloc setting errno also non standard.
[Bug fortran/88169] Rejects USE rename of namelist group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169 --- Comment #15 from kargl at gcc dot gnu.org --- Author: kargl Date: Sat Dec 22 18:09:19 2018 New Revision: 267354 URL: https://gcc.gnu.org/viewcvs?rev=267354=gcc=rev Log: 2018-12-21 Steven G. Kargl PR fortran/88169 * module.c (mio_namelist): Remove an error condition/message that is contrary to the Fortran standard. 2018-12-21 Steven G. Kargl PR fortran/88169 * gfortran.dg/pr88169_1.f90: new test. * gfortran.dg/pr88169_2.f90: Ditto. * gfortran.dg/pr88169_3.f90: Ditto. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr88169_1.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr88169_2.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr88169_3.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/module.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug c/88576] -fno-math-errno causes GCC to consider that malloc does not set errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88576 --- Comment #3 from Andrew Pinski --- (In reply to Aurelien Jarno from comment #2) > (In reply to Andrew Pinski from comment #1) > > IIRC malloc setting errno also non standard. > > According to POSIX: > > The malloc() function shall fail if: > > [ENOMEM] > [CX] [Option Start] Insufficient storage space is available. [Option > End] > > In that case malloc returns a NULL pointer. However even after adding a > check for the return value, GCC still optimizes-out saving and restoring > errno. POSIX says one thing but C99 says another thing.
[Bug fortran/70149] [F08] Character pointer initialization causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70149 --- Comment #12 from Paul Thomas --- (In reply to Andreas Schwab from comment #9) > This generates wrong code on powerpc64, either the initializer or the size > of _F.myptr_mod_MOD_number_string is wrong. > > .globl _F.myptr_mod_MOD_number_string > .align 3 > .type _F.myptr_mod_MOD_number_string, @object > .size _F.myptr_mod_MOD_number_string, 8 > _F.myptr_mod_MOD_number_string: > .long 16 > .zero 4 > ... > addis 9,2,_F.myptr_mod_MOD_number_string@toc@ha > addi 9,9,_F.myptr_mod_MOD_number_string@toc@l > ld 9,0(9) > extsw 9,9 > cmpwi 7,9,16 Hi Andreas, Has this gone away? I seem to have applied what I believe to be the right patch as fallout from another PR. Cheers Paul
[Bug fortran/77703] [7/8/9 Regression] ICE on assignment to pointer function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77703 --- Comment #8 from Paul Thomas --- (In reply to Paul Thomas from comment #7) > Created attachment 44907 [details] > Patch for the PR > > This does the job. I am working on something else right now and will come > back to this in a week or so. > > Paul A week or two turned into a month or two. I am on to it. Paul
[Bug fortran/85544] [7/8/9 Regression] ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.c:3385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85544 --- Comment #10 from Harald Anlauf --- (In reply to Thomas Koenig from comment #8) > * trans-expr.c (gfc_conv_power_op): Handle cases of 1**integer, > (2|4|8|16) ** integer and (-1) ** integer. Handling positive powers of 2 should be straightforward: The condition is sth. like if (v > 1 && (v & (v-1) == 0)) and the exponent is derived by bit-counting the number of ones in (v-1)...
[Bug fortran/85544] [7/8/9 Regression] ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.c:3385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85544 --- Comment #11 from Thomas Koenig --- Author: tkoenig Date: Sat Dec 22 19:19:14 2018 New Revision: 267355 URL: https://gcc.gnu.org/viewcvs?rev=267355=gcc=rev Log: 2018-12-22 Thomas Koenig Backport from trunk PR fortran/85544 * frontend-passes.c (optimize_power): Remove. (optimize_op): Remove call to optimize_power. * trans-expr.c (gfc_conv_power_op): Handle cases of 1**integer, (2|4|8|16) ** integer and (-1) ** integer. 2018-12-22 Thomas Koenig Backport from trunk PR fortran/85544 * gfortran.dg/power_7.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/power_7.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/frontend-passes.c branches/gcc-8-branch/gcc/fortran/trans-expr.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c/88576] -fno-math-errno causes GCC to consider that malloc does not set errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88576 Zack Weinberg changed: What|Removed |Added CC||zackw at panix dot com --- Comment #5 from Zack Weinberg --- The C standard doesn't say malloc _will_ set errno on failure, but it also doesn't say it _won't_, and all library functions are allowed to clobber the value of errno unless it is specifically documented that they won't (N1570 7.5 [Errors], para 3, last sentence). In any case, an option named -fno-math-errno has no business affecting the treatment of functions that have nothing to do with mathematics.
[Bug c/88576] -fno-math-errno causes GCC to consider that malloc does not set errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88576 --- Comment #7 from Aurelien Jarno --- (In reply to Zack Weinberg from comment #5) > The C standard doesn't say malloc _will_ set errno on failure, but it also Well at least POSIX says: Otherwise, it shall return a null pointer and set errno to indicate the error. > doesn't say it _won't_, and all library functions are allowed to clobber the > value of errno unless it is specifically documented that they won't (N1570 > 7.5 [Errors], para 3, last sentence). I fully agree with that.
[Bug fortran/85798] ICE in get_array_index, at fortran/data.c:69
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85798 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Sat Dec 22 19:54:18 2018 New Revision: 267357 URL: https://gcc.gnu.org/viewcvs?rev=267357=gcc=rev Log: 2018-12-22 Steven G . Kargl PR fortran/85798 * decl.c (gfc_match_data): If a component of a derived type entity appears in data statement, check that does not have the allocatable attribute. 2018-12-22 Steven G . Kargl PR fortran/85798 * gfortran.dg/pr85798.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr85798.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/decl.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/85544] [7/8/9 Regression] ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.c:3385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85544 --- Comment #12 from Thomas Koenig --- (In reply to Harald Anlauf from comment #10) > Handling positive powers of 2 should be straightforward: > > The condition is sth. like > > if (v > 1 && (v & (v-1) == 0)) > > and the exponent is derived by bit-counting the number of ones in (v-1)... ... which is something I (currently) do not know to do in the front end. Let's leave that as some optimization potential (it should also be possible to optimize (-2)**n and so on) for a later date. Otherwise: Patches welcome (as always :-)
[Bug fortran/85544] [7/8/9 Regression] ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.c:3385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85544 --- Comment #8 from Thomas Koenig --- Author: tkoenig Date: Sat Dec 22 14:14:44 2018 New Revision: 267347 URL: https://gcc.gnu.org/viewcvs?rev=267347=gcc=rev Log: 2018-12-22 Thomas Koenig PR fortran/85544 * frontend-passes.c (optimize_power): Remove. (optimize_op): Remove call to optimize_power. * trans-expr.c (gfc_conv_power_op): Handle cases of 1**integer, (2|4|8|16) ** integer and (-1) ** integer. 2018-12-22 Thomas Koenig PR fortran/85544 * gfortran.dg/power_7.f90: New test. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/frontend-passes.c trunk/gcc/fortran/trans-expr.c
[Bug fortran/85544] [7/8/9 Regression] ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.c:3385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85544 --- Comment #9 from Thomas Koenig --- Author: tkoenig Date: Sat Dec 22 14:21:01 2018 New Revision: 267348 URL: https://gcc.gnu.org/viewcvs?rev=267348=gcc=rev Log: 2018-12-22 Thomas Koenig Backport from trunk PR fortran/85544 * gfortran.dg/power_7.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/power_7.f90
[Bug fortran/88328] ICE in resolve_tag_format, at fortran/io.c:1641
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88328 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Sun Dec 23 05:18:27 2018 New Revision: 267367 URL: https://gcc.gnu.org/viewcvs?rev=267367=gcc=rev Log: 2018-12-22 Steven G. Kargl PR fortran/88328 * io.c (resolve_tag_format): Add error for zero-sized array. (gfc_resolve_dt): Manipulate gfc_current_locus to get sensible error message locus. 2018-12-22 Steven G. Kargl PR fortran/88328 * gfortran.dg/pr88328.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr88328.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/88328] ICE in resolve_tag_format, at fortran/io.c:1641
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88328 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Target Milestone|--- |9.0 --- Comment #4 from kargl at gcc dot gnu.org --- Fixed on trunk. Closing.
[Bug c++/88580] New: Parameter pack expansion fails (variadic constructor template inside a variadic class template)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88580
Bug ID: 88580
Summary: Parameter pack expansion fails (variadic constructor
template inside a variadic class template)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: philodej at gmail dot com
Target Milestone: ---
The following simple code snippet compiles as expected on clang, msvc and icc,
but fails to compile on gcc (any version I have tried):
[https://godbolt.org/z/2uLKgn]
#include
struct Policy {
explicit Policy(std::string arg) {}
};
template
struct Scope : private Base... {
template
Scope(T&&... args)
: Base(std::forward(args)...)... {
}
};
int main() {
const auto scope = Scope{std::string{}};
}
... with following (seemingly meaningless) error:
error: no matching function for call to 'Policy::Policy(bool)'
If any of the parameter packs is replaced with a single template parameter then
the code compiles OK. So it seems that compiler is confused by combination of
two pack expansions.
Sorry if this kind of error has been reported already (I know that there are
already several bugs reported regarding variadic template parameter expansion
but none of them seemed to me identical to this one).
[Bug fortran/85544] [7/8/9 Regression] ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.c:3385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85544 --- Comment #13 from Harald Anlauf --- (In reply to Thomas Koenig from comment #12) > (In reply to Harald Anlauf from comment #10) > > > Handling positive powers of 2 should be straightforward: > > > > The condition is sth. like > > > > if (v > 1 && (v & (v-1) == 0)) > > > > and the exponent is derived by bit-counting the number of ones in (v-1)... > > ... which is something I (currently) do not know to do in the > front end. Since you already have HOST_WIDE_INT v; you could use wi::popcount (v-1). > Otherwise: Patches welcome (as always :-) I'm afraid removing some of your code would cross the magic 10 lines mark...
[Bug c/88576] -fno-math-errno causes GCC to consider that malloc does not set errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88576 Zack Weinberg changed: What|Removed |Added CC||rguenther at suse dot de --- Comment #8 from Zack Weinberg --- (In reply to Aurelien Jarno from comment #7) > (In reply to Zack Weinberg from comment #5) > > The C standard doesn't say malloc _will_ set errno on failure, but it also > > Well at least POSIX says: > Otherwise, it shall return a null pointer and set errno to indicate the > error. Yeah, I wasn't denying that, I was responding to Andrew taking the attitude that this was fine because ISO C proper _didn't_ say that. I dug into the code a little and it looks like this was an intentional re-use of -fno-math-errno to also mean "and neither will malloc", in the patch for PR 42944. I think that's wrong, but perhaps Richard Biener would like to argue otherwise...
[Bug fortran/85544] [7/8/9 Regression] ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.c:3385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85544 --- Comment #14 from Thomas Koenig --- Author: tkoenig Date: Sat Dec 22 20:16:22 2018 New Revision: 267360 URL: https://gcc.gnu.org/viewcvs?rev=267360=gcc=rev Log: 2018-12-22 Thomas Koenig Backport from trunk PR fortran/85544 * frontend-passes.c (optimize_power): Remove. (optimize_op): Remove call to optimize_power. * trans-expr.c (gfc_conv_power_op): Handle cases of 1**integer, (2|4|8|16) ** integer and (-1) ** integer. 2018-12-22 Thomas Koenig Backport from trunk PR fortran/85544 * gfortran.dg/power_7.f90: New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/power_7.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/frontend-passes.c branches/gcc-7-branch/gcc/fortran/trans-expr.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/85544] [7/8/9 Regression] ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.c:3385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85544 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Thomas Koenig --- The possible enhancement is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88579 The rejects-valid regression is now fixed on all branches.
[Bug fortran/88579] Calculating power of powers of two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88579 Thomas Koenig changed: What|Removed |Added CC||anlauf at gmx dot de Target Milestone|--- |10.0 Summary|Calculatiing power of |Calculating power of powers |powers of two |of two
[Bug c/88576] -fno-math-errno causes GCC to consider that malloc does not set errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88576 --- Comment #9 from Zack Weinberg --- ... whoops, hit send a little too early. AFAICT, the relevant code is call_may_clobber_ref_p_1 in tree-ssa-alias.c; I would say that the uses of flag_errno_math under the cases BUILT_IN_MALLOC, ALIGNED_ALLOC, CALLOC, STRDUP, STRNDUP, POSIX_MEMALIGN, REALLOC in that function are all wrong, and GCC should unconditionally assume errno may be clobbered by those builtins. If this behavior is felt to be valuable, it should get its own -f switch. (The uses of flag_errno_math under BUILT_IN_GAMMA*, LGAMMA*, and REMQUO* are appropriate, though, as those _are_ math functions.)
[Bug fortran/88579] New: Calculatiing power of powers of two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88579 Bug ID: 88579 Summary: Calculatiing power of powers of two Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- After PR 85544 has been fixed, there are some optimizations possible which are detailed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85544#c13 and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85544#c10 : Optimize other powers of two with a general rule involving bit counts, and also optimizing (-2)**n) and so on.
[Bug fortran/88579] Calculating power of powers of two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88579
--- Comment #1 from Harald Anlauf ---
OK, here's my proof-of-concept patch (not cleaned up):
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision 267353)
+++ gcc/fortran/trans-expr.c(working copy)
@@ -3068,7 +3068,8 @@
se->expr = build_int_cst (TREE_TYPE (lse.expr), 1);
return;
}
- else if (v == 2 || v == 4 || v == 8 || v == 16)
+ // else if (v == 2 || v == 4 || v == 8 || v == 16)
+ else if (v > 1 && ((v & (v-1)) == 0))
{
/* 2**n = 1<= 8)
+ {
+ int e = wi::popcount (v-1);
+ shift = fold_build2_loc (input_location, MULT_EXPR,
+ TREE_TYPE (rse.expr),
+ build_int_cst (TREE_TYPE (rse.expr), e),
+ rse.expr);
+ }
+#if 0
else if (v == 8)
shift = fold_build2_loc (input_location, MULT_EXPR,
TREE_TYPE (rse.expr),
@@ -3099,6 +3109,7 @@
TREE_TYPE (rse.expr),
build_int_cst (TREE_TYPE (rse.expr), 4),
rse.expr);
+#endif
else
gcc_unreachable ();
Running
make check-fortran RUNTESTFLAGS='dg.exp=power*.f90'
passes cleanly, but for some reason my setup always wants to run the
libgomp tests...
[Bug middle-end/88576] -fno-math-errno causes GCC to consider that malloc does not set errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88576 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-22 Component|c |middle-end Ever confirmed|0 |1 --- Comment #10 from Andrew Pinski --- Read the thread starting at: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00232.html
[Bug fortran/85798] ICE in get_array_index, at fortran/data.c:69
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85798 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Sat Dec 22 23:23:02 2018 New Revision: 267362 URL: https://gcc.gnu.org/viewcvs?rev=267362=gcc=rev Log: 2018-12-22 Steven G . Kargl PR fortran/85798 * decl.c (gfc_match_data): If a component of a derived type entity appears in data statement, check that does not have the allocatable attribute. 2018-12-22 Steven G . Kargl PR fortran/85798 * gfortran.dg/pr85798.f90: New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr85798.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/decl.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/85798] ICE in get_array_index, at fortran/data.c:69
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85798 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|NEW |RESOLVED CC||kargl at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |7.5 --- Comment #6 from kargl at gcc dot gnu.org --- Fixed on trunk, branch-8, and branch-7. Closing.
