[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 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&root=gcc&view=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 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/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.
[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&root=gcc&view=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 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/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 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 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 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 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&root=gcc&view=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 --- 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 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/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&root=gcc&view=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 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 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/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&root=gcc&view=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 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 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&root=gcc&view=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 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/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/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 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 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 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++/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 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 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&root=gcc&view=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 #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 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 #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&root=gcc&view=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 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&root=gcc&view=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 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 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&root=gcc&view=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 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&root=gcc&view=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/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&root=gcc&view=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 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]