[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893 --- Comment #2 from 康 珊 --- Created attachment 46062 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46062=edit octane benchmark part2
[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893 --- Comment #1 from 康 珊 --- Created attachment 46061 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46061=edit octane benchmark part1
[Bug libfortran/79540] [7/8 Regression] FAIL: gfortran.dg/fmt_fw_d.f90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79540 --- Comment #26 from Jerry DeLisle --- (In reply to Dominique d'Humieres from comment #25) > Fixed on trunk so far. Yes, OK to backport.
[Bug tree-optimization/70392] [openacc] inconsistent line numbers in uninitialised warnings for if clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70392 Eric Gallager changed: What|Removed |Added CC|manu at gcc dot gnu.org|jason at gcc dot gnu.org, ||nathan at acm dot org --- Comment #4 from Eric Gallager --- (In reply to Manuel López-Ibáñez from comment #3) > Look at the dumps. Probably the C++ FE or the optimisers do not create an > expression with a valid location for bool. It is not an issue with > Wuninitialized. > ok, never mind; removing you and replacing you with the C++ FE maintainers instead, then...
[Bug inline-asm/87984] [7/8/9 Regression] wrong code for local reg var input to asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #32 from Segher Boessenkool ---
Historically, a local register asm variable *does* live in that variable
for its entire scope. This stopped working correctly, even with the many
caveats there were for it, and many years ago the manual added language
saying that only using such a var in an extended asm in or out is supported,
and there was language warning you to keep the life time short, etc.
This did *not* change the implementation. Any other use still is explicitly
unsupported, and all such testcases are invalid code.
It would be nice if GCC was changed such that such vars were expanded to a
pseudo like any other var, and copies to/from a hard reg just around the asm.
Gimple doesn't need to do *anything* for that, just keep track that the var
is declared as local register var, and the gimple it had now at expand is
just fine:
===
f ()
{
register int a __asm__ (*eax);
int o;
;; basic block 2, loop depth 0
;;pred: ENTRY
a = 1;
__asm__("add %1, %0" : "=g" o_14 : "r" a, "0" 0);
clear_eax ();
__asm__("add %1, %0" : "=g" o_21 : "r" a, "0" o_14);
clear_eax ();
__asm__("add %1, %0" : "=g" o_28 : "r" a, "0" o_21);
clear_eax ();
return o_28;
;;succ: EXIT
}
===
But currently "a" is expanded as a hard reg, not a pseudo, and the code does
not
do what you want at all. As the manual tells you.
===
;; Generating RTL for gimple basic block 2
;; a = 1;
(insn 5 4 0 (set (reg/v:SI 0 ax [ a ])
(const_int 1 [0x1])) "cax.c":6:18 -1
(nil))
===
(and it gets worse after that).
[Bug c++/89894] poor error message when redefining a function overloaded on a non-type specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89894
--- Comment #2 from Martin Sebor ---
Actually, it's not specific to non-type specializations or even templates. The
same problem happens with ordinary types. Non-type template specializations
just exacerbate it.
$ cat z.C && gcc -c -Wall z.C
struct A { };
typedef A B;
typedef A T;
typedef B U;
void h (T) { }
void h (U) { }
z.C:8:6: error: redefinition of ‘void h(U)’
8 | void h (U) { }
| ^
z.C:7:6: note: ‘void h(T)’ previously defined here
7 | void h (T) { }
| ^
[Bug c++/89894] poor error message when redefining a function overloaded on a non-type specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89894 Martin Sebor changed: What|Removed |Added Keywords||diagnostic CC||dmalcolm at gcc dot gnu.org --- Comment #1 from Martin Sebor --- David, you might be interested in this.
[Bug c++/89894] New: poor error message when redefining a function overloaded on a non-type specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89894
Bug ID: 89894
Summary: poor error message when redefining a function
overloaded on a non-type specialization
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The error message below make it difficult to understand what exactly the root
cause problem is: the names of the types of the arguments are different and no
other detail is provided. If the definitions of T and U and far apart (e.g.,
in different headers perhaps even supplied by different libraries) and
complicated (e.g., the result of some non-trivial algorithm) determining what
makes the types the same could be a non-trivial exercise.
Including a note in the error message pointing to the types underlying the
aliases would help.
Providing more detail about the underlying types, such as the values of the
constants the underlying templates are instantiated on analogously to what's
done for ordinary templates, would help even more.
$ cat z.C && gcc -c -Wall -std=c++2a z.C
struct A { int i; };
template struct B { };
constexpr A f () { return A{1<<27}; }
constexpr A g () { return A{134217728}; }
typedef B T;
typedef B U;
void h (T) { }
void h (U) { }
z.C:10:6: error: redefinition of ‘void h(U)’
10 | void h (U) { }
| ^
z.C:9:6: note: ‘void h(T)’ previously defined here
9 | void h (T) { }
| ^
[Bug libfortran/79540] [7/8 Regression] FAIL: gfortran.dg/fmt_fw_d.f90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79540 Dominique d'Humieres changed: What|Removed |Added Summary|[7/8/9 Regression] FAIL:|[7/8 Regression] FAIL: |gfortran.dg/fmt_fw_d.f90|gfortran.dg/fmt_fw_d.f90 |-O0 execution test |-O0 execution test --- Comment #25 from Dominique d'Humieres --- Fixed on trunk so far.
[Bug fortran/54852] Bogus(?) warnings when compiling gfortran.dg/bind_c_vars.f90 gfortran.dg/bind_c_vars_driver.c with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54852 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Dominique d'Humieres --- The warnings are gone since GCC6, closing.
[Bug fortran/80174] [meta-bug] Fortran lto issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80174 Bug 80174 depends on bug 54852, which changed state. Bug 54852 Summary: Bogus(?) warnings when compiling gfortran.dg/bind_c_vars.f90 gfortran.dg/bind_c_vars_driver.c with -flto https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54852 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/89841] improper descriptor information passed to C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89841 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Paul Thomas --- Fixed on trunk. Thanks for the report. Paul
[Bug fortran/89842] CFI_allocate fails to allocate object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89842 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED CC||pault at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Paul Thomas --- Fixed on trunk. Thanks for the report. Paul
[Bug fortran/89841] improper descriptor information passed to C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89841 --- Comment #4 from Paul Thomas --- Author: pault Date: Sat Mar 30 15:39:00 2019 New Revision: 270037 URL: https://gcc.gnu.org/viewcvs?rev=270037=gcc=rev Log: 2019-03-30 Paul Thomas PR fortran/89841 * trans-expr.c (gfc_conv_gfc_desc_to_cfi_desc): Use the formal argument attributes rather than those of the actual argument. PR fortran/89842 * trans-expr.c (gfc_conv_gfc_desc_to_cfi_desc): Call 'set_dtype_for_unallocated' for any type of arrayspec. 2019-03-30 Paul Thomas PR fortran/89841 * gfortran.dg/ISO_Fortran_binding_1.f90: Change the interfaces for c_deallocate, c_allocate and c_assumed_size so that the attributes of the array arguments are correct and are typed. * gfortran.dg/ISO_Fortran_binding_7.f90: New test. * gfortran.dg/ISO_Fortran_binding_7.c: Additional source. PR fortran/89842 * gfortran.dg/ISO_Fortran_binding_8.f90: New test. * gfortran.dg/ISO_Fortran_binding_8.c: Additional source. Added: trunk/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_7.c trunk/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_7.f90 trunk/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_8.c trunk/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_8.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_1.f90
[Bug fortran/89842] CFI_allocate fails to allocate object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89842 --- Comment #2 from Paul Thomas --- Author: pault Date: Sat Mar 30 15:39:00 2019 New Revision: 270037 URL: https://gcc.gnu.org/viewcvs?rev=270037=gcc=rev Log: 2019-03-30 Paul Thomas PR fortran/89841 * trans-expr.c (gfc_conv_gfc_desc_to_cfi_desc): Use the formal argument attributes rather than those of the actual argument. PR fortran/89842 * trans-expr.c (gfc_conv_gfc_desc_to_cfi_desc): Call 'set_dtype_for_unallocated' for any type of arrayspec. 2019-03-30 Paul Thomas PR fortran/89841 * gfortran.dg/ISO_Fortran_binding_1.f90: Change the interfaces for c_deallocate, c_allocate and c_assumed_size so that the attributes of the array arguments are correct and are typed. * gfortran.dg/ISO_Fortran_binding_7.f90: New test. * gfortran.dg/ISO_Fortran_binding_7.c: Additional source. PR fortran/89842 * gfortran.dg/ISO_Fortran_binding_8.f90: New test. * gfortran.dg/ISO_Fortran_binding_8.c: Additional source. Added: trunk/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_7.c trunk/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_7.f90 trunk/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_8.c trunk/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_8.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_1.f90
[Bug c++/60241] [4.8 Regression] internal compiler error: in finish_member_declaration, at cp/semantics.c:2617
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60241 --- Comment #9 from Jason Merrill --- Author: jason Date: Sat Mar 30 15:23:37 2019 New Revision: 270036 URL: https://gcc.gnu.org/viewcvs?rev=270036=gcc=rev Log: PR c++/89744 - ICE with specialization of member class template. My fix five years ago for PR 60241 was incomplete: when we reassign implicit instances of a partial instantiation of a member template to the explicit specialization of that partial instantiation, we also need to adjust the CLASSTYPE_TI_ARGS to match what we'd get when looking up that instance after the explicit specialization. We also need to do this when we later look up the instance in a way that only finds the explicit specialization halfway through lookup_template_class_1. * pt.c (lookup_template_class_1): If the partial instantiation is explicitly specialized, adjust. (maybe_process_partial_specialization): Also adjust CLASSTYPE_TI_ARGS. Added: trunk/gcc/testsuite/g++.dg/template/mem-spec1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c
[Bug c++/89744] [8 Regression] ICE with specialization of nested template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89744 --- Comment #4 from Jason Merrill --- Author: jason Date: Sat Mar 30 15:23:37 2019 New Revision: 270036 URL: https://gcc.gnu.org/viewcvs?rev=270036=gcc=rev Log: PR c++/89744 - ICE with specialization of member class template. My fix five years ago for PR 60241 was incomplete: when we reassign implicit instances of a partial instantiation of a member template to the explicit specialization of that partial instantiation, we also need to adjust the CLASSTYPE_TI_ARGS to match what we'd get when looking up that instance after the explicit specialization. We also need to do this when we later look up the instance in a way that only finds the explicit specialization halfway through lookup_template_class_1. * pt.c (lookup_template_class_1): If the partial instantiation is explicitly specialized, adjust. (maybe_process_partial_specialization): Also adjust CLASSTYPE_TI_ARGS. Added: trunk/gcc/testsuite/g++.dg/template/mem-spec1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c
[Bug fortran/87946] [7/8/9 Regression] ICE in gfc_walk_array_ref, at fortran/trans-array.c:10506
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87946 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #2 from Thomas Koenig --- In gfc_walk_array_ref, ar->as is zero when looking at the size of z in the function g.
[Bug fortran/64118] Strange warning about unused function/subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64118 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dominique d'Humieres --- This PR has been fixed since GCC6, closing.
[Bug fortran/89891] New: [meta-bug] Accessing memory in rejected statements or expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89891 Bug ID: 89891 Summary: [meta-bug] Accessing memory in rejected statements or expressions Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- There are quite a few places where we access memory in rejected statements. This should be a place to gather them.
[Bug fortran/59344] warning for needless pointer attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59344 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Dominique d'Humieres --- > Please provide the man power otherwise you'll never get it. No manpower provided, closing as WONTFIX.
[Bug fortran/68815] Error/warning diagnostic: '%s' should be converted to %qs-like or %<%s%>-like string strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68815 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Dominique d'Humieres --- > Tobias: Can the bug be marked as resolved? No feedback, closing. Please open a new PR for remaining issue(s).
[Bug fortran/89646] [7/8/9 Regression] Spurious actual argument might interfere warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89646 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org Target Milestone|--- |7.5 Summary|Spurious actual argument|[7/8/9 Regression] Spurious |might interfere warning |actual argument might ||interfere warning
[Bug fortran/89866] [8 Regression] [F08] wrong-code problem with POINTER, INTENT(IN) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89866 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Thomas Koenig --- So, fixed. Thanks for the bug report!
[Bug fortran/39627] [meta-bug] Fortran 2008 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39627 Bug 39627 depends on bug 89866, which changed state. Bug 89866 Summary: [8 Regression] [F08] wrong-code problem with POINTER, INTENT(IN) argument https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89866 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/88242] static_assertion only fires when class is templated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88242
--- Comment #1 from fiesh at zefix dot tv ---
Ran through creduce:
template struct b { static constexpr int c = a; };
template struct d {};
template struct j;
template struct j> : b {};
template constexpr long h = j::c;
template struct n : n { static constexpr int c = i; };
template <> struct n<0> {};
using k = n<6>;
#ifndef FIX
template
#endif
struct l {
d m;
static auto f(n>) -> d;
static auto f(n + 1> q) -> d {
static_assert(q.c == 2, "BUG88242_1");
}
static auto o() { f(k{}); }
};
#ifndef FIX
using p = l<>;
#else
using p = l;
#endif
static_assert(p::o);
[Bug fortran/89866] [8 Regression] [F08] wrong-code problem with POINTER, INTENT(IN) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89866 --- Comment #6 from Thomas Koenig --- Author: tkoenig Date: Sat Mar 30 13:45:47 2019 New Revision: 270035 URL: https://gcc.gnu.org/viewcvs?rev=270035=gcc=rev Log: 2019-03-30 Thomas Koenig PR fortran/89866 * gfortran.dg/pointer_intent_8.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pointer_intent_8.f90 Modified: branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/89866] [8 Regression] [F08] wrong-code problem with POINTER, INTENT(IN) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89866 --- Comment #5 from Thomas Koenig --- Author: tkoenig Date: Sat Mar 30 13:41:10 2019 New Revision: 270034 URL: https://gcc.gnu.org/viewcvs?rev=270034=gcc=rev Log: 2019-03-30 Thomas Koenig PR fortran/89866 * gfortran.dg/pointer_intent_8.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pointer_intent_8.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/89866] [8 Regression] [F08] wrong-code problem with POINTER, INTENT(IN) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89866 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #4 from Thomas Koenig --- I see correct execution with 8.3.1 20190310, so I assume this has been fixed in the meantime. I will commit a test case so this does not regress.
[Bug fortran/89830] intrinsic repeat() is completely broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89830 Thomas Koenig changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #10 from Thomas Koenig --- I'm closing the original bug report as invalid. For the second one... well, you can submit an enhancement requiest if you want to.
[Bug fortran/89841] improper descriptor information passed to C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89841 --- Comment #3 from paul.richard.thomas at gmail dot com --- It's on its way to being committed this afternoon :-) Cheers Paul On Sat, 30 Mar 2019 at 12:41, dominiq at lps dot ens.fr wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89841 > > --- Comment #2 from Dominique d'Humieres --- > A patch has been posted at > https://gcc.gnu.org/ml/fortran/2019-03/msg00142.html > and approved at > https://gcc.gnu.org/ml/fortran/2019-03/msg00143.html > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug fortran/78865] [7/8 Regression] ICE in create_tmp_var, at gimple-expr.c:473
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78865 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Thomas Koenig --- Fixed on gcc-8. Applying the patch to gcc-7 leads to FAIL: gfortran.dg/allocatable_dummy_1.f90 -O1 (internal compiler error) and it makes no sense to chase this down. Closing as fixed.
[Bug fortran/78865] [7/8 Regression] ICE in create_tmp_var, at gimple-expr.c:473
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78865 --- Comment #8 from Thomas Koenig --- Author: tkoenig Date: Sat Mar 30 13:23:38 2019 New Revision: 270032 URL: https://gcc.gnu.org/viewcvs?rev=270032=gcc=rev Log: 2019-03-30 Thomas Koenig PR fortran/78865 Backport from trunk * interface.c (compare_actual_formal): Change errors about missing or extra to gfc_error_now to make sure they are issued. Change "spec" to "specifier" in message. * resolve.c (resolve_global_procedure): Also check for mismatching interface with global symbols if the namespace has already been resolved. 2019-03-30 Thomas Koenig PR fortran/78865 Backport from trunk * gfortran.dg/altreturn_10.f90: New test. * gfortran.dg/whole_file_3.f90: Change dg-warning to dg-error. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/altreturn_10.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/interface.c branches/gcc-8-branch/gcc/fortran/resolve.c branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/gfortran.dg/whole_file_3.f90
[Bug fortran/80563] [cleanup] handle allocatable DT intent(out) arguments in init_intent_out_dt instead of gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80563 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-03-30 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=78377 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- See pr78377 comment 3.
[Bug fortran/89821] Get a SIGFPE on a simple test of a kind=real128 variable with -ffpe-trap=invalid switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89821 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-03-30 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres --- There are two issues: (1) The fpe-trap triggered for the reduced test in comment 2 between revisions r253982 (2017-10-22, no trap) and r254227 (2017-10-30, trap). The change has not been back ported to the GCC8 branch. (2) The fpe-trap triggered for the original test after revision r245268, but not before r245187: found a nan_real32. Handle it. found a nan_real64. Handle it. Floating exception Now the question is: done want to restore the previous behavior?
[Bug tree-optimization/70392] [openacc] inconsistent line numbers in uninitialised warnings for if clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70392 --- Comment #3 from Manuel López-Ibáñez --- Look at the dumps. Probably the C++ FE or the optimisers do not create an expression with a valid location for bool. It is not an issue with Wuninitialized. On Sat, 30 Mar 2019, 02:50 egallager at gcc dot gnu.org, < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70392 > > Eric Gallager changed: > >What|Removed |Added > > > CC||dmalcolm at gcc dot > gnu.org, >||dodji at gcc dot gnu.org, >||manu at gcc dot gnu.org > > --- Comment #2 from Eric Gallager --- > cc-ing diagnostics maintainers, and Manu since it's an issue with > -Wuninitialized > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug fortran/89841] improper descriptor information passed to C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89841 --- Comment #2 from Dominique d'Humieres --- A patch has been posted at https://gcc.gnu.org/ml/fortran/2019-03/msg00142.html and approved at https://gcc.gnu.org/ml/fortran/2019-03/msg00143.html
[Bug fortran/89866] [8 Regression] [F08] wrong-code problem with POINTER, INTENT(IN) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89866 --- Comment #3 from Dominique d'Humieres --- This has been fixed between revisions r264810 (2018-10-03, wrong code) and r264951 (2018-10-09, OK) and the fix has not been back ported to the GCC8 branch). I did not find any obvious commit in this range. On the GCC8 branch I see the expected output up to r251946, but a segfault at runtime for r251980 (2017-09-11), likely r251949. AFAICT the wrong code issue appeared at revision r257065.
[Bug fortran/89840] [Coarray] CO_BROADCAST: Missing finalization/deallocation of allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89840 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-03-30 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- I do not see any PR opened for co_broadcast not supporting derived-type arguments. When and why do you expect the subroutine 'done' to be called in your test? In its present state I think this PR is INVALID.
[Bug fortran/85686] [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=85686 --- Comment #5 from Thomas Koenig --- (In reply to Jürgen Reuter from comment #4) > Any update on this one, that should possibly be not so hard to fix I'd guess. A combination of character, associate, and arrays? How many hoenest's nests do you want to disturb in one go? ;-)
[Bug fortran/86481] [OOP] Memory leak with sourced allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86481 Dominique d'Humieres changed: What|Removed |Added CC||andrew at fluidgravity dot co.uk --- Comment #8 from Dominique d'Humieres --- *** Bug 89890 has been marked as a duplicate of this bug. ***
[Bug fortran/89890] Memory leak from a function returning a subtype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89890 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Dominique d'Humieres --- This has been fixed by revision r263916 (2018-08-28) and looks like a duplicate of pr86481. *** This bug has been marked as a duplicate of bug 86481 ***
[Bug d/89255] libphobos.unittests multilib handling broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89255 --- Comment #2 from Iain Buclaw --- Created attachment 46060 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46060=edit patch for pr89255 I posted this to gcc-patches in three parts, it would be good if you can test it on solaris before I commit.
[Bug fortran/87127] External function not recognised from within an associate block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87127 --- Comment #6 from paul.richard.thomas at gmail dot com --- Hi Juergen, Noted - as it happens, I have an hour or so right now :-) Cheers Paul On Fri, 29 Mar 2019 at 23:08, juergen.reuter at desy dot de wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87127 > > --- Comment #5 from Jürgen Reuter --- > Paul, would be cool to get back to this one! ;) > > -- > You are receiving this mail because: > You reported the bug.
