[Bug target/65836] [6 Regression] gnat fails to build on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65836 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from ktkachov at gcc dot gnu.org --- So bootstrap now succeeds. Presumably fixed by Tom?
[Bug lto/65378] Tweak to wording of -Wodr message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65378 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-27 CC||hubicka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org --- David, sorry, I did not notice this PR before. Indeed warning: type 'struct failure' violates the One Definition Rule [-Wodr] seems better than current wording. Would you go ahead and update that in ipa-devirt? (the patch is preapproved). I would welcome other refinements in the warnings too.
[Bug c/65892] gcc fails to implement N685 aliasing of union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||alias CC||rguenth at gcc dot gnu.org --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- As Andrew says GCCs behavior is intentional and N685 is just completely broken.
[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919 John Buddery jvb at cyberscience dot com changed: What|Removed |Added CC||jvb at cyberscience dot com --- Comment #6 from John Buddery jvb at cyberscience dot com --- I had this issue as well, and here is the solution I used in case anyone is still interested. I believe it is caused by an HP-UX linker bug, the same one described by this comment and workaround in config/ia64/hpux.h: /* The HP-UX linker has a bug that causes calls from functions in .text.unlikely to functions in .text to cause a segfault. Until it is fixed, prevent code from being put into .text.unlikely or .text.hot. */ #define TARGET_ASM_FUNCTION_SECTION ia64_hpux_function_section While this workaround is sufficient for C code, unfortunately g++ can use multiple text sections for various different reasons when compiling c++ code (lookup Vague Linkage for details). This means g++ is broken on HP ia64, and gcc 4.8.0 build using g++, which is why the bootstrap now fails. The workaround I applied was to add the line: #undef MAKE_DECL_ONE_ONLY to gcc/config/ia64/hpux.h, below the lines I referenced above. This seems to prevent gcc from using .linkonce.t sections, and keeps the HP-UX linker happy. I've no idea if this is the correct solution, but it does produce a working g++. Unfortunately just applying this edit you your 4.9.2 sources and building isn't good enough, because it's your existing broken g++ which does the stage1 build. As far as I can tell all g++ versions available for download are broken, so you have to first download and build 4.7.4 or earlier, applying the same gcc/config/ia64/hpux.h as above. This version builds with gcc, not g++, so the bootstrap isn't a problem. Once you have a fixed 4.7.4 g++, you can then use that to bootstrap 4.9.2 - after again apply the hpux.h edit to the 4.9.2 sources. In my case when building 4.9.2 I also had to disable libgomp, but I think that's a different issue. Of course a much better solution to all this would be to get a fixed HP linker; but I can't even tell if any of the HP patches help as they don't seem to make these fixes generally available.
[Bug c/65864] Consider emitting -Wswitch-bool less aggressively?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65864 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from ktkachov at gcc dot gnu.org --- Turns out the kernel guys were not against rewriting the switch statement to an if-else. https://lkml.org/lkml/2015/4/23/367 Closing this out then
[Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65875 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #3) Created attachment 35395 [details] gcc5-pr65875.patch Untested fix. IMHO vrp_visit_phi_node was missing the vr_result VR_VARING handling if the value range turned into varying only during update_value_range, and also update_value_range wasn't telling the caller if it changed it into varying late. That said, the testcase has conditionally undefined variable, and checking whether all the VRP decisions (first and second pass) are sane, would be nice, Richard, could you please have a look? E.g. I find it strange that h has VR [0, LONG_MAX] before VRP2, when it really has just values 0 or 1, so should be ideally [0, 1]. Or that i has value range [1, LONG_MAX] - it is conditionally undefined (that is ignored), and conditionally negation of an int variable (only if that int variable is negative). The negated int variable is [1, +INF(OVF)] because INT_MIN might overflow, perhaps if we really need to preserve the OVF flag, we have to use [1, +INF(OVF)] again rather than just [1, 0x7fff] :(. For h we get into the loop PHI handling code which drops to INF-1 if it iterates too much. The rest probably ripples down from that. I can't see where that [1, 0x7ff] issue happens.
[Bug tree-optimization/65893] ifcombine not done anymore on expansion of va_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65893 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- IMHO it makes sense to move stdarg a bit earlier, after pass_dce.
[Bug fortran/65894] [6 Regression] severe regression in gfortran 6.0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894 --- Comment #7 from Jürgen Reuter juergen.reuter at desy dot de --- Created attachment 35404 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35404action=edit Code that triggers the segmentation fault.
[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org --- First of all, why is this filed as a GCC bug? And what is PIE specific on the issue? I mean, if -Bsymbolic doesn't cope well with like copy relocations, then the testcase doesn't work on most targets when the binary is normal executable rather than PIE.
[Bug tree-optimization/65217] __builtin_unreachable in if statement causes bad assembly generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65217 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization, xfail Status|RESOLVED|REOPENED Last reconfirmed||2015-04-27 CC||law at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Component|c |tree-optimization Resolution|FIXED |--- Ever confirmed|0 |1 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- It was only fixed by luck due to us folding all stmts in forwprop which turns if (_3 != n_1(D)) into the canonical if (n_1(D) != _3) and then DOM recording the proper equality via record_equality by _always_ swapping operands due to else if (is_gimple_min_invariant (x) /* ??? When threading over backedges the following is important for correctness. See PR61757. */ || (loop_depth_of_name (x) = loop_depth_of_name (y))) and its '==' part. For non-canonical order (in GCC 4.9 and earlier) that swapping turned it into the unfortunate direction. That equality decides whether we propagate _3 into the return value on the else branch (where n_1(D) == _3) or leave it as n_1(D) (good for this case). I am about to commit a patch that does not perform this kind of random swapping (and will XFAIL the testcase).
[Bug debug/65549] [4.9/5/6 Regression] crash in htab_hash_string with -flto -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #31 from Eric Botcazou ebotcazou at gcc dot gnu.org --- That's the prominent issue with LTO in Ada because there are a lot of nested functions in Ada. We use a local patch that fixes up the limbo list again: @@ -24063,6 +24080,11 @@ dwarf2out_finish (const char *filename) } #endif resolve_addr (comp_unit_die ()); + /* resolve_addr calls force_decl_die, which can put new DIEs on the limbo + list in LTO mode when nested functions are put in a different partition + than that of their parent function. */ + if (in_lto_p) +fixup_limbo_list (); move_marked_base_types (); for (node = deferred_asm_name; node; node = node-next)
[Bug middle-end/65874] [5 Regression] bootstrap comparison failure (gcc/ira.o) on ia64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65874 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.2
[Bug ipa/65873] [5/6 Regression] Failure to inline always_inline memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65873 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- I think simply honoring always_inline (the attribute! not just DECL_DISREGARD_INLINE_LIMITS) regardless of any options would be ok as well (and maybe simply reject optimize/target attributes on inline bodies?)
[Bug fortran/65894] [6 Regression] severe regression in gfortran 6.0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894 vehre at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #4 from vehre at gcc dot gnu.org --- Looks like this is my patch's fault. I will investigate and report back. Because this is on trunk and seems to not make gfortran completely unusable, I would like not to withdraw the commit, but to fix the issue in a later patch.
[Bug fortran/65894] [6 Regression] severe regression in gfortran 6.0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |6.0 Summary|severe regression in|[6 Regression] severe |gfortran 6.0.0 |regression in gfortran ||6.0.0
[Bug fortran/65894] [6 Regression] severe regression in gfortran 6.0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894 --- Comment #5 from Jürgen Reuter juergen.reuter at desy dot de --- Here is a reduced test case (where iso_varying_string.f90 is the standard module with 1 or 2 modifications by us). As this is at the core of our program, we do rely on a timely fix in order to further use and test gfortran 6.0. module model_data use iso_varying_string, string_t = varying_string implicit none private public :: field_data_t public :: model_data_t type :: field_data_t private integer :: pdg = 0 type(string_t), dimension(:), allocatable :: name contains procedure :: init = field_data_init procedure :: get_pdg = field_data_get_pdg end type field_data_t type :: model_data_t private type(string_t) :: name type(field_data_t), dimension(:), allocatable :: field contains generic :: init = model_data_init procedure, private :: model_data_init generic :: get_pdg = model_data_get_field_pdg_index procedure, private :: model_data_get_field_pdg_index generic :: get_field_ptr = model_data_get_field_ptr_pdg procedure, private :: model_data_get_field_ptr_pdg procedure :: get_field_ptr_by_index = model_data_get_field_ptr_index procedure :: init_sm_test = model_data_init_sm_test end type model_data_t contains subroutine field_data_init (prt, pdg) class(field_data_t), intent(out) :: prt integer, intent(in) :: pdg prt%pdg = pdg end subroutine field_data_init elemental function field_data_get_pdg (prt) result (pdg) integer :: pdg class(field_data_t), intent(in) :: prt pdg = prt%pdg end function field_data_get_pdg subroutine model_data_init (model, name, n_field) class(model_data_t), intent(out) :: model type(string_t), intent(in) :: name integer, intent(in) :: n_field model%name = name allocate (model%field (n_field)) end subroutine model_data_init function model_data_get_field_pdg_index (model, i) result (pdg) class(model_data_t), intent(in) :: model integer, intent(in) :: i integer :: pdg pdg = model%field(i)%get_pdg () end function model_data_get_field_pdg_index function model_data_get_field_ptr_pdg (model, pdg, check) result (ptr) class(model_data_t), intent(in), target :: model integer, intent(in) :: pdg logical, intent(in), optional :: check type(field_data_t), pointer :: ptr integer :: i, pdg_abs if (pdg == 0) then ptr = null () return end if pdg_abs = abs (pdg) do i = 1, size (model%field) if (model%field(i)%get_pdg () == pdg_abs) then ptr = model%field(i) return end if end do ptr = null () end function model_data_get_field_ptr_pdg function model_data_get_field_ptr_index (model, i) result (ptr) class(model_data_t), intent(in), target :: model integer, intent(in) :: i type(field_data_t), pointer :: ptr ptr = model%field(i) end function model_data_get_field_ptr_index subroutine model_data_init_sm_test (model) class(model_data_t), intent(out) :: model type(field_data_t), pointer :: field integer, parameter :: n_field = 19 call model%init (var_str (SM_test), n_field) field = model%get_field_ptr_by_index (1) call field%init (1) end subroutine model_data_init_sm_test end module model_data module flavors use model_data implicit none private public :: flavor_t type :: flavor_t private integer :: f = 0 type(field_data_t), pointer :: field_data = null () contains generic :: init = flavor_init0_model procedure, private :: flavor_init0_model end type flavor_t contains impure elemental subroutine flavor_init0_model (flv, f, model) class(flavor_t), intent(inout) :: flv integer, intent(in) :: f class(model_data_t), intent(in), target :: model flv%f = f flv%field_data = model%get_field_ptr (f, check=.true.) end subroutine flavor_init0_model end module flavors module beams use model_data use flavors implicit none private public :: beam_1 contains subroutine beam_1 (u) integer, intent(in) :: u type(flavor_t), dimension(2) :: flv real, dimension(2) :: pol_f type(model_data_t), target :: model call model%init_sm_test () call flv%init ([1,-1], model) pol_f(1) = 0.5 end subroutine beam_1 end module beams program main use beams call beam_1 (6) end program main
[Bug fortran/65894] [6 Regression] severe regression in gfortran 6.0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894 --- Comment #6 from Jürgen Reuter juergen.reuter at desy dot de --- Created attachment 35403 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35403action=edit Auxiliary module
[Bug c++/53184] Unnecessary anonymous namespace warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53184 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-04-27 CC|orgads at gmail dot com| Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Ever confirmed|0 |1
[Bug web/64968] Upgrade GCC Bugzilla to 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968 Frédéric Buclin LpSolit at netscape dot net changed: What|Removed |Added Attachment #35353|0 |1 is obsolete|| --- Comment #16 from Frédéric Buclin LpSolit at netscape dot net --- Created attachment 35409 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35409action=edit GCC patch for 5.0, v3 To make Mikael happy, I'm going to apply this patch which will sniff the content type of the submitted attachment and will convert it to text/plain if it's of type text/x-*.
[Bug libstdc++/62258] [4.8/4.9/5/6 Regression] uncaught_exception() equals to `true' after rethrow_exception()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62258 --- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org --- doko, I'm still curious if you can verify if you see a regression here or not.
[Bug libstdc++/62258] [4.8/4.9/5/6 Regression] uncaught_exception() equals to `true' after rethrow_exception()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62258 --- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed on trunk so far
[Bug libstdc++/62258] [4.8/4.9/5/6 Regression] uncaught_exception() equals to `true' after rethrow_exception()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62258 --- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Mon Apr 27 19:44:30 2015 New Revision: 222480 URL: https://gcc.gnu.org/viewcvs?rev=222480root=gccview=rev Log: 2015-04-27 Dmitry Prokoptsev dprokopt...@gmail.com Michael Hanselmann pub...@hansmi.ch PR libstdc++/62258 * libsupc++/eh_ptr.cc (rethrow_exception): Increment count of uncaught exceptions. * testsuite/18_support/exception_ptr/62258.cc: New. Added: trunk/libstdc++-v3/testsuite/18_support/exception_ptr/62258.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/libsupc++/eh_ptr.cc
[Bug web/64968] Upgrade GCC Bugzilla to 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968 --- Comment #17 from Frédéric Buclin LpSolit at netscape dot net --- Patch applied. Mikael, the next time you upload a f90 script, Bugzilla will correctly detect it as text/plain. Note that it won't convert the MIME type of already uploaded attachments (which you can manually fix to text/plain yourself).
[Bug fortran/64230] [4.9/5 Regression] Invalid memory reference in a compiler-generated finalizer for allocatable component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64230 Mat Cross mathewc at nag dot co.uk changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Mat Cross mathewc at nag dot co.uk --- I've restored the closure status and I'll keep an eye on how PR64921 goes.
[Bug c++/65896] [5/6 Regression] Erroneous uninitialized variable access error in constexpr function with temporary variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65896 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-27 Known to work||4.8.3, 4.9.2 Summary|Erroneous uninitialized |[5/6 Regression] Erroneous |variable access error in|uninitialized variable |constexpr function with |access error in constexpr |temporary variables |function with temporary ||variables Ever confirmed|0 |1 Known to fail||5.1.0, 6.0
[Bug c++/65882] [5/6 Regression] Internal compiler error: Error reporting routines re-entered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65882 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.2
[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |5.2
[Bug tree-optimization/65887] remove va_arg ap copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65887 --- Comment #1 from vries at gcc dot gnu.org --- Created attachment 35402 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35402action=edit patch to remove copyback
[Bug ipa/65873] [5/6 Regression] Failure to inline always_inline memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65873 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #1) I think certain combinations of flag will trigger ICE, such as one enabling/disabling vector builtins. But I suppose we may want to bypass majority of the checks for case we have always_inline w/o explicit optimization attribute indeed, but only at early inlining time, probably not at LTO? At LTO time we already did transformation that turn previously correct code with target's optimization flags to be incorrect (i.e. -fstrict-aliasing blocks some transformations we may do during early opts) Yeah, special casing always_inline with no explicit optimize/target attributes only, and only during early inlining IMHO should be sufficient.
[Bug tree-optimization/65887] remove va_arg ap copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65887
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to vries from comment #2)
I.
After removing the copyback using attached patch, and marking the va_arg
first argument as addressable as suggested here (
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01314.html ) using this patch
(nr 1):
...
@@ -9408,6 +9458,23 @@ gimplify_va_arg_expr (tree *expr_p, gimple_seq *pre_p,
}
/* Transform a VA_ARG_EXPR into an VA_ARG internal function. */
+ mark_addressable (valist);
ap = build_fold_addr_expr_loc (loc, valist);
tag = build_int_cst (build_pointer_type (type), 0);
*expr_p = build_call_expr_internal_loc (loc, IFN_VA_ARG, type, 2, ap,
tag);
...
we get the desired:
...
e = VA_ARG (argp, 0B);
e = VA_ARG (argp, 0B);
...
II.
However, we subsequently run into a verify_gimple_call failure in
gcc.c-torture/execute/va-arg-10.c, for the second argument of this va_copy:
...
__builtin_va_copy (apc, ap);
...
D.2056 = VA_ARG (ap, 0B);
...
Presumably because ap is not marked as addressable when gimplifying the
va_copy, but ap is later marked as addressable when gimplifying VA_ARG_EXPR.
With this patch (nr 2), we mark the second va_copy argument as addressable
when gimplifying va_copy:
...
@@ -2339,6 +2340,55 @@ gimplify_call_expr (tree *expr_p, gimple_seq *pre_p,
bool want_value)
DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL)
switch (DECL_FUNCTION_CODE (fndecl))
{
+ case BUILT_IN_VA_COPY:
+ mark_addressable (CALL_EXPR_ARG (*expr_p, 1));
+ break;
case BUILT_IN_VA_START:
{
builtin_va_start_p = TRUE;
...
That indeed prevents the verify_gimple_call error. But the code now contains
a copy:
...
ap.0 = ap;
__builtin_va_copy (apc, ap.0);
...
D.2057 = VA_ARG (ap, 0B);
...
The copy in itself does not look incorrect, but we'd rather not have it.
III.
Furthermore, patch nr 1 triggers a verify_gimple_call error on
gcc.c-torture/execute/va-arg-14.c for the first argument of a va_copy:
...
__builtin_va_copy (param, local);
...
D.1845 = VA_ARG (param, 0B);
...
Using this patch (nr 3), we also mark the first argument of the copy as
addressable:
...
@@ -2341,6 +2341,7 @@ gimplify_call_expr (tree *expr_p, gimple_seq *pre_p,
bool want_value)
{
case BUILT_IN_VA_COPY:
mark_addressable (CALL_EXPR_ARG (*expr_p, 1));
+ mark_addressable (CALL_EXPR_ARG (*expr_p, 0));
break;
case BUILT_IN_VA_START:
{
...
That indeed prevents the verify_gimple_call failure. But it results in this
code:
...
param.0 = param;
__builtin_va_copy (param.0, local);
...
D.1846 = VA_ARG (param, 0B);
...
which doesn't look correct: param is unmodified by the va_copy.
Well, you only get the copy if param is of register type (thus a pointer).
So the code is correct I belive.
Rather than marking the va_list arg addressable in all the cases above
you should probably simply ensure the frontend marks it so from the
point it creates a variable with va_list type. This is because even
va_list a1, a2;
a1 = a2;
__builtin_va_arg (a1, ...);
might go wrong when gimplifying a1 = a2.
OTOH, the obvious tests (execute.exp=va-arg*.c, execute.exp=stdarg*.c,
callabi.exp) are passing, probably because va_list is a pointer type, and
va_copy modifies what param points to.
[Bug tree-optimization/65887] remove va_arg ap copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65887
--- Comment #2 from vries at gcc dot gnu.org ---
I.
After removing the copyback using attached patch, and marking the va_arg first
argument as addressable as suggested here (
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01314.html ) using this patch (nr
1):
...
@@ -9408,6 +9458,23 @@ gimplify_va_arg_expr (tree *expr_p, gimple_seq *pre_p,
}
/* Transform a VA_ARG_EXPR into an VA_ARG internal function. */
+ mark_addressable (valist);
ap = build_fold_addr_expr_loc (loc, valist);
tag = build_int_cst (build_pointer_type (type), 0);
*expr_p = build_call_expr_internal_loc (loc, IFN_VA_ARG, type, 2, ap, tag);
...
we get the desired:
...
e = VA_ARG (argp, 0B);
e = VA_ARG (argp, 0B);
...
II.
However, we subsequently run into a verify_gimple_call failure in
gcc.c-torture/execute/va-arg-10.c, for the second argument of this va_copy:
...
__builtin_va_copy (apc, ap);
...
D.2056 = VA_ARG (ap, 0B);
...
Presumably because ap is not marked as addressable when gimplifying the
va_copy, but ap is later marked as addressable when gimplifying VA_ARG_EXPR.
With this patch (nr 2), we mark the second va_copy argument as addressable when
gimplifying va_copy:
...
@@ -2339,6 +2340,55 @@ gimplify_call_expr (tree *expr_p, gimple_seq *pre_p,
bool want_value)
DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL)
switch (DECL_FUNCTION_CODE (fndecl))
{
+ case BUILT_IN_VA_COPY:
+ mark_addressable (CALL_EXPR_ARG (*expr_p, 1));
+ break;
case BUILT_IN_VA_START:
{
builtin_va_start_p = TRUE;
...
That indeed prevents the verify_gimple_call error. But the code now contains a
copy:
...
ap.0 = ap;
__builtin_va_copy (apc, ap.0);
...
D.2057 = VA_ARG (ap, 0B);
...
The copy in itself does not look incorrect, but we'd rather not have it.
III.
Furthermore, patch nr 1 triggers a verify_gimple_call error on
gcc.c-torture/execute/va-arg-14.c for the first argument of a va_copy:
...
__builtin_va_copy (param, local);
...
D.1845 = VA_ARG (param, 0B);
...
Using this patch (nr 3), we also mark the first argument of the copy as
addressable:
...
@@ -2341,6 +2341,7 @@ gimplify_call_expr (tree *expr_p, gimple_seq *pre_p, bool
want_value)
{
case BUILT_IN_VA_COPY:
mark_addressable (CALL_EXPR_ARG (*expr_p, 1));
+ mark_addressable (CALL_EXPR_ARG (*expr_p, 0));
break;
case BUILT_IN_VA_START:
{
...
That indeed prevents the verify_gimple_call failure. But it results in this
code:
...
param.0 = param;
__builtin_va_copy (param.0, local);
...
D.1846 = VA_ARG (param, 0B);
...
which doesn't look correct: param is unmodified by the va_copy.
OTOH, the obvious tests (execute.exp=va-arg*.c, execute.exp=stdarg*.c,
callabi.exp) are passing, probably because va_list is a pointer type, and
va_copy modifies what param points to.
[Bug ipa/65873] [5/6 Regression] Failure to inline always_inline memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65873 --- Comment #1 from Jan Hubicka hubicka at gcc dot gnu.org --- The diff in flags is the following: not inlinable: bar/1 - memcpy/0, optimization level attribute mismatch align_functions (0/0x10) align_jumps (0/0x10) align_loops (0/0x10) flag_vect_cost_model (0x2/0x1) optimize (0x3/0x2) flag_associative_math (0x1/0) flag_cx_limited_range (0x1/0) flag_finite_math_only (0x1/0) flag_gcse_after_reload (0x1/0) flag_inline_functions (0x1/0) flag_ipa_cp_clone (0x1/0) flag_errno_math (0/0x1) flag_predictive_commoning (0x1/0) flag_reciprocal_math (0x1/0) flag_signed_zeros (0/0x1) flag_trapping_math (0/0x1) flag_tree_loop_distribute_patterns (0x1/0) flag_tree_loop_vectorize (0x1/0) flag_tree_partial_pre (0x1/0) flag_tree_slp_vectorize (0x1/0) flag_unsafe_math_optimizations (0x1/0) flag_unswitch_loops (0x1/0) so we fail because of errno-math difference. The logic accepting/rejecitng inlines in can_inline_edge_p and I guess it is the fact that we are affraid to inline safe math to unsafe. I think certain combinations of flag will trigger ICE, such as one enabling/disabling vector builtins. But I suppose we may want to bypass majority of the checks for case we have always_inline w/o explicit optimization attribute indeed, but only at early inlining time, probably not at LTO? At LTO time we already did transformation that turn previously correct code with target's optimization flags to be incorrect (i.e. -fstrict-aliasing blocks some transformations we may do during early opts)
[Bug libstdc++/65899] New: std::basic_stringbuf member __xfer_bufptrs should be explicitly declared private
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65899
Bug ID: 65899
Summary: std::basic_stringbuf member __xfer_bufptrs should be
explicitly declared private
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: bastian.beisc...@rwth-aachen.de
Target Milestone: ---
I'm trying to compile code with GCC 5.1.0 which makes use of the good ole:
#define private public
hack (for some reason). I know, I know, but it's not my code and I'd like it to
compile out of the box...
Now the issue is this: In GCC 5.1.0's version of the sstream header one finds
the following:
templatetypename _CharT, typename _Traits, typename _Alloc
class basic_stringbuf : public basic_streambuf_CharT, _Traits
{
struct __xfer_bufptrs;
public:
// Types:
typedef _CharTchar_type;
typedef _Traits traits_type;
[...]
private:
[...]
struct __xfer_bufptrs
{
[...]
The problem is that the member __xfer_bufptrs is implicitly private when it's
declared but then later it's expliclity marked private.
Then, due to the #define private public, the second one turns public but the
first one does not and there's a conflict leading to this error:
/usr/include/c++/5.1.0/sstream:335:7: error: ‘struct
std::basic_stringbuf_CharT, _Traits, _Alloc::__xfer_bufptrs’ redeclared with
different access
struct __xfer_bufptrs
^
Any chance to mark the first instance private explicitly?
[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886 --- Comment #13 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Jakub Jelinek from comment #12) First of all, why is this filed as a GCC bug? And what is PIE specific on the issue? I mean, if -Bsymbolic doesn't cope well with like copy relocations, then the testcase doesn't work on most targets when the binary is normal executable rather than PIE. It is true that the testcase doesn't work with normal executable. I don't believe GCC is wrong to generate copy relocation in PIE. It is only a GCC bug that PIE worked before, it doesn't work now and there is no command option to make PIE to work.
[Bug target/65895] Segfault building cross GCC 5.1.0 for Target AVR on Mac OSX 10.10.3 (using Apple LLVM version 6.1.0 (clang-602.0.49))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65895 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |RESOLVED Keywords||build CC||gjl at gcc dot gnu.org Blocks||65296 Assignee|unassigned at gcc dot gnu.org |gjl at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |5.2 Known to fail||5.1.0 Severity|minor |normal --- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org --- Fixed in 5.2. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65296 [Bug 65296] [avr] fix various issues with specs file generation
[Bug target/65296] [avr] fix various issues with specs file generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65296 Bug 65296 depends on bug 65895, which changed state. Bug 65895 Summary: Segfault building cross GCC 5.1.0 for Target AVR on Mac OSX 10.10.3 (using Apple LLVM version 6.1.0 (clang-602.0.49)) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65895 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886 --- Comment #17 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Jakub Jelinek from comment #16) (In reply to H.J. Lu from comment #15) Unless we state -Bsymbolic should never be used with GCC, we should provide a way to make PIE to compatible with -Bsymbolic. Well, there is a way, build with -fPIC rather than -fPIE. Since -Bsymbolic is allowed with PIE, we should take advantage of it. -fsymbolic -fPIE is the same as -fPIC and -fsymbolic -fPIC generates much better codes for shared library.
[Bug libstdc++/65899] std::basic_stringbuf member __xfer_bufptrs should be explicitly declared private
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65899 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- No. Use -fno-access-control which does it properly.
[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to H.J. Lu from comment #13) It is true that the testcase doesn't work with normal executable. I don't believe GCC is wrong to generate copy relocation in PIE. It is only a GCC bug that PIE worked before, it doesn't work now and there is no command option to make PIE to work. As it doesn't work with normal executables, I'm not convinced we need such an option or that it is right to assume it should work.
[Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65875 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Mon Apr 27 12:21:17 2015 New Revision: 222461 URL: https://gcc.gnu.org/viewcvs?rev=222461root=gccview=rev Log: PR tree-optimization/65875 * tree-vrp.c (update_value_range): If in is_new case setting old_vr to VR_VARYING, also set new_vr to it. Remove old_vr-type == VR_VARYING test. (vrp_visit_phi_node): Return SSA_PROP_VARYING instead of SSA_PROP_INTERESTING if update_value_range returned true, but new range is VR_VARYING. * gcc.c-torture/compile/pr65875.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/gcc.c-torture/compile/pr65875.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/tree-vrp.c
[Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65875 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug testsuite/65900] New: FAIL: gcc.dg/pr65345-2.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65900 Bug ID: 65900 Summary: FAIL: gcc.dg/pr65345-2.c (test for excess errors) Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /te st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr65345-2.c -fno-diagnostics-show-caret -fd iagnostics-color=never -lm-o ./pr65345-2.exe(timeout = 300) spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /test/gnu/gcc/gc c/gcc/testsuite/gcc.dg/pr65345-2.c -fno-diagnostics-show-caret -fdiagnostics-col or=never -lm -o ./pr65345-2.exe ld: Unsatisfied symbol __atomic_compare_exchange_4 in file /var/tmp//ccWEnQpO. o 1 errors. collect2: error: ld returned 1 exit status compiler exited with status 1 output is: ld: Unsatisfied symbol __atomic_compare_exchange_4 in file /var/tmp//ccWEnQpO. o 1 errors. collect2: error: ld returned 1 exit status FAIL: gcc.dg/pr65345-2.c (test for excess errors)
[Bug target/65296] [avr] fix various issues with specs file generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65296 --- Comment #12 from Georg-Johann Lay gjl at gcc dot gnu.org --- Author: gjl Date: Mon Apr 27 11:43:20 2015 New Revision: 222459 URL: https://gcc.gnu.org/viewcvs?rev=222459root=gccview=rev Log: PR target/65296 PR target/65895 * config/avr/gen-avr-mmcu-specs.c (print_mcu): Close file. Add hint how to use own spec file. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/gen-avr-mmcu-specs.c
[Bug target/65895] Segfault building cross GCC 5.1.0 for Target AVR on Mac OSX 10.10.3 (using Apple LLVM version 6.1.0 (clang-602.0.49))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65895 --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org --- Author: gjl Date: Mon Apr 27 11:43:20 2015 New Revision: 222459 URL: https://gcc.gnu.org/viewcvs?rev=222459root=gccview=rev Log: PR target/65296 PR target/65895 * config/avr/gen-avr-mmcu-specs.c (print_mcu): Close file. Add hint how to use own spec file. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/gen-avr-mmcu-specs.c
[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886 --- Comment #15 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Jakub Jelinek from comment #14) As it doesn't work with normal executables, I'm not convinced we need such an option or that it is right to assume it should work. People are using -Bsymbolic for very good reasons and they know the risk. In KDE, there are #if !defined(QT_BOOTSTRAPPED) defined(QT_REDUCE_RELOCATIONS) defined(__ELF__) !defined(__PIC__) !defined(__PIE__) # error You must build your code with position independent code if Qt was built with -reduce-relocations. \ Compile your code with -fPIC or -fPIE. #endif Unless we state -Bsymbolic should never be used with GCC, we should provide a way to make PIE to compatible with -Bsymbolic.
[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886 --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to H.J. Lu from comment #15) Unless we state -Bsymbolic should never be used with GCC, we should provide a way to make PIE to compatible with -Bsymbolic. Well, there is a way, build with -fPIC rather than -fPIE.
[Bug c/65901] New: no warning or error for va_arg (ap, void)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65901
Bug ID: 65901
Summary: no warning or error for va_arg (ap, void)
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
We have va_arg (ap, void) somewhere in the testsuite
(gcc.c-torture/compile/pr48767.c).
AFAIU, using void in va_arg is undefined behaviour in c.
Currently, we just compile it without warning or error:
...
$ cat ~/va-arg-void.c
#include stdarg.h
int
f (int d, ...)
{
int res;
va_list ap;
va_start (ap, d);
va_arg (ap, void);
res = va_arg (ap, int);
va_end (ap);
return res;
}
int
main (void)
{
return f (1, 2, 3);
}
$ gcc -O2 ~/va-arg-void.c
$ ./a.out ; echo $?
3
...
Btw, note that va_arg (ap, void) has an effect on ap.
[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886 --- Comment #18 from H.J. Lu hjl.tools at gmail dot com --- (In reply to H.J. Lu from comment #17) Since -Bsymbolic is allowed with PIE, we should take advantage of it. -fsymbolic -fPIE is the same as -fPIC and -fsymbolic -fPIC generates much better codes for shared library. -fsymbolic -fPIE isn't the same as -fPIC. It is between -fPIC and -fPIE.
[Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65875 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Mon Apr 27 11:26:12 2015 New Revision: 222458 URL: https://gcc.gnu.org/viewcvs?rev=222458root=gccview=rev Log: PR tree-optimization/65875 * tree-vrp.c (update_value_range): If in is_new case setting old_vr to VR_VARYING, also set new_vr to it. Remove old_vr-type == VR_VARYING test. (vrp_visit_phi_node): Return SSA_PROP_VARYING instead of SSA_PROP_INTERESTING if update_value_range returned true, but new range is VR_VARYING. * gcc.c-torture/compile/pr65875.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr65875.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug target/65895] Segfault building cross GCC 5.1.0 for Target AVR on Mac OSX 10.10.3 (using Apple LLVM version 6.1.0 (clang-602.0.49))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65895 --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org --- Author: gjl Date: Mon Apr 27 11:49:42 2015 New Revision: 222460 URL: https://gcc.gnu.org/viewcvs?rev=222460root=gccview=rev Log: Backport from 2015-04-27 trunk r222459. PR target/65296 PR target/65895 * config/avr/gen-avr-mmcu-specs.c (print_mcu): Close file. Add hint how to use own spec file. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/avr/gen-avr-mmcu-specs.c
[Bug target/65296] [avr] fix various issues with specs file generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65296 --- Comment #13 from Georg-Johann Lay gjl at gcc dot gnu.org --- Author: gjl Date: Mon Apr 27 11:49:42 2015 New Revision: 222460 URL: https://gcc.gnu.org/viewcvs?rev=222460root=gccview=rev Log: Backport from 2015-04-27 trunk r222459. PR target/65296 PR target/65895 * config/avr/gen-avr-mmcu-specs.c (print_mcu): Close file. Add hint how to use own spec file. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/avr/gen-avr-mmcu-specs.c
[Bug middle-end/65855] missing optimization: triangular numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65855 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- shorten_compare in the C frontend family performs the (long unsigned int) n_3(D) != 18446744073709551615 simplification. Nothing in fold-const.c or match.pd does.
[Bug libstdc++/65899] std::basic_stringbuf member __xfer_bufptrs should be explicitly declared private
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65899 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Ugh, -fno-access-control doesn't prevent the error. Then I suggest using -include sstream, so that stringstream is included before some idiot comes along and redefines a keyword. But I'm not interested in supporting -Dprivate=public, it's just wrong.
[Bug fortran/64921] [4.9/5/6 Regression] FAIL: gfortran.dg/class_allocate_18.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921 --- Comment #14 from Mat Cross mathewc at nag dot co.uk --- For the record, perhaps it is of interest for me to note that we are running into this (cf. PR64230 comment 9) on code like Program test Implicit None Type :: t1 Integer, Allocatable :: i End Type Type :: t2 Integer, Allocatable :: i End Type Type, Extends (t1) :: t3 Type (t2) :: j End Type Type, Extends (t3) :: t4 Integer, Allocatable :: k End Type Call s Print *, 'ok' Contains Subroutine s Class (t1), Allocatable :: x Allocate (t4 :: x) End Subroutine End Program Since the crash is in bad compiler-generated finalization code (since 4.9), and given that (if I recall correctly) gfortran is using the Fortran 2008 semantics for entities declared in a main program being implicitly saved, this is why removing the Deallocate (in the comment 12 example) works - the finalizer is never called then. In the interim, does anyone have any bright ideas for a reasonable (few-line) workaround? Thanks.
[Bug tree-optimization/65907] New: [6 Regression] ICE: in set_lattice_value, at tree-ssa-ccp.c:535
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65907
Bug ID: 65907
Summary: [6 Regression] ICE: in set_lattice_value, at
tree-ssa-ccp.c:535
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
Target Milestone: ---
Building LLVM fails with gcc-6:
trippels@gcc2-power8 Support % /home/trippels/gcc_test/usr/local/bin/g++ -fPIC
-std=c++11 -O2 -fno-exceptions -fno-rtti -c YAMLParser.ii
/home/trippels/llvm/lib/Support/YAMLParser.cpp: In function
‘std::__cxx11::string llvm::yaml::escape(llvm::StringRef)’:
/home/trippels/llvm/lib/Support/YAMLParser.cpp:642:13: internal compiler error:
in set_lattice_value, at tree-ssa-ccp.c:535
std::string yaml::escape(StringRef Input) {
^
0x10b6f98b set_lattice_value
../../gcc/gcc/tree-ssa-ccp.c:535
0x10b70bbf ccp_visit_phi_node
../../gcc/gcc/tree-ssa-ccp.c:1147
0x10c14337 simulate_stmt
../../gcc/gcc/tree-ssa-propagate.c:344
0x10c16507 simulate_block
../../gcc/gcc/tree-ssa-propagate.c:485
0x10c16507 ssa_propagate(ssa_prop_result (*)(gimple_statement_base*,
edge_def**, tree_node**), ssa_prop_result (*)(gphi*))
../../gcc/gcc/tree-ssa-propagate.c:928
0x10b6db3f do_ssa_ccp
../../gcc/gcc/tree-ssa-ccp.c:2411
0x10b6db3f execute
../../gcc/gcc/tree-ssa-ccp.c:2444
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
Reducing...
[Bug target/64579] __TM_end __builtin_tend failed to return transactional state
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64579 --- Comment #2 from Peter Bergner bergner at gcc dot gnu.org --- Author: bergner Date: Mon Apr 27 14:52:50 2015 New Revision: 222467 URL: https://gcc.gnu.org/viewcvs?rev=222467root=gccview=rev Log: gcc/ PR target/64579 * config/rs6000/htm.md: Remove all define_expands. (UNSPECV_HTM_TABORTDC, UNSPECV_HTM_TABORTDCI, UNSPECV_HTM_TABORTWC, UNSPECV_HTM_TABORTWCI): Remove. (UNSPECV_HTM_TABORTXC, UNSPECV_HTM_TABORTXCI, UNSPECV_HTM_TTEST): New. (tabort_internal, tbegin_internal, tcheck_internal, tend_internal, trechkpt_internal, treclaim_internal, tsr_internal): Rename from this... (tabort, tbegin, tcheck, tend, trechkpt, treclaim, tsr): ...to this. (tabortdc_internal, tabortdci_internal, tabortwc_internal, tabortwci_internal): Remove define_insns. (tabortwdc, tabortwdci): New define_insns. (tabort): Use gpc_reg_operand. (tcheck): Remove operand. (htm_mfspr_mode, htm_mtspr_mode): Use GPR mode macro. * config/rs6000/htmxlintrin.h (__TM_end): Use _HTM_TRANSACTIONAL as expected value. * config/rs6000/rs6000-builtin.def (BU_HTM_SPR0): Remove. (BU_HTM_SPR1): Rename to BU_HTM_V1. Remove use of RS6000_BTC_SPR. (tabort, tabortdc, tabortdci, tabortwc, tabortwci, tbegin, tcheck, tend, tendall, trechkpt, treclaim, tresume, tsuspend, tsr, ttest): Pass in the RS6000_BTC_CR attribute. (get_tfhar, set_tfhar, get_tfiar, set_tfiar, get_texasr, set_texasr, get_texasru, set_texasru): Pass in the RS6000_BTC_SPR attribute. (tcheck): Remove builtin argument. * config/rs6000/rs6000.c (rs6000_htm_spr_icode): Use TARGET_POWERPC64 not TARGET_64BIT. (htm_expand_builtin): Fix usage of expandedp. Disallow usage of the tabortdc and tabortdci builtins when not in 64-bit mode. Modify code to handle the loss of the HTM define_expands. Emit code to copy the CR register to TARGET. (htm_init_builtins): Modify code to handle the loss of the HTM define_expands. * config/rs6000/rs6000.h (RS6000_BTC_32BIT): Delete. (RS6000_BTC_64BIT): Likewise. (RS6000_BTC_CR): New macro. * doc/extend.texi: Update documentation for htm builtins. gcc/testsuite/ PR target/64579 * gcc.target/powerpc/htm-1.c: New test. * gcc.target/powerpc/htm-builtin-1.c (__builtin_tabortdc): Only test on 64-bit compiles. (__builtin_tabortdci): Likewise. (__builtin_tcheck): Remove operand. * lib/target-supports.exp (check_htm_hw_available): New function. Added: trunk/gcc/testsuite/gcc.target/powerpc/htm-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/htm.md trunk/gcc/config/rs6000/htmxlintrin.h trunk/gcc/config/rs6000/rs6000-builtin.def trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/rs6000.h trunk/gcc/doc/extend.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/htm-builtin-1.c trunk/gcc/testsuite/lib/target-supports.exp
[Bug c/65892] gcc fails to implement N685 aliasing of union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 --- Comment #8 from Martin Sebor msebor at gcc dot gnu.org --- If one of you can explain the problem with it I'm willing to write up a paper and submit it to WG14 and request to have the standard changed.
[Bug libgomp/65904] New: Memory corruption with acc_shutdown, nvptx offloading, libgomp.oacc-c-c++-common/asyncwait-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65904 Bug ID: 65904 Summary: Memory corruption with acc_shutdown, nvptx offloading, libgomp.oacc-c-c++-common/asyncwait-1.c Product: gcc Version: unknown Status: UNCONFIRMED Keywords: openacc Severity: normal Priority: P3 Component: libgomp Assignee: jules at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- Seems to have appeared with the recent libgomp changes (r221878, r221922). *** glibc detected *** ./asyncwait-1.exe: double free or corruption (!prev): 0x01cfdcf0 *** === Backtrace: = /lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x2ac3b574bb96] [...]/build-gcc/x86_64-unknown-linux-gnu/./libgomp/.libs/libgomp.so.1(+0x153dd)[0x2ac3b52a33dd] [...]/build-gcc/x86_64-unknown-linux-gnu/./libgomp/.libs/libgomp.so.1(acc_shutdown+0x115)[0x2ac3b52a57a5] ./asyncwait-1.exe[0x40333d] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x2ac3b56ee76d] ./asyncwait-1.exe[0x400fb9] === Memory map: [...] Valgrind reports: [...] ==24645== Invalid read of size 8 ==24645==at 0x60A53C8: gomp_free_memmap (target.c:914) ==24645==by 0x60A77A4: acc_shutdown (oacc-init.c:229) ==24645==by 0x402254: main (in [...]/asyncwait-1.exe) ==24645== Address 0xda94f78 is 88 bytes inside a block of size 1,512 free'd ==24645==at 0x4C2A739: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==24645==by 0x60A53DC: gomp_free_memmap (target.c:917) ==24645==by 0x60A77A4: acc_shutdown (oacc-init.c:229) ==24645==by 0x402254: main (in [...]/asyncwait-1.exe) [...]
[Bug c++/65905] New: Building eCos fails with clist.hxx:304:1: error: template with C linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65905 Bug ID: 65905 Summary: Building eCos fails with clist.hxx:304:1: error: template with C linkage Product: gcc Version: 5.1.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: --- Created attachment 35406 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35406action=edit precompiled source code using gcc-5.1 it is no longer possible to build the eCos library: arm-eabi-gcc -c -I/home/ed/Downloads/ecos-test_install/include -I/home/ed/Downloads/ecos-cvs-120723/packages/infra/current -I/home/ed/Downloads/ecos-cvs-120723/packages/infra/current/src -I/home/ed/Downloads/ecos-cvs-120723/packages/infra/current/tests -I. -I/home/ed/Downloads/ecos-cvs-120723/packages/infra/current/src/ -finline-limit=7000 -Wall -Wpointer-arith -Wundef -Woverloaded-virtual -Wno-write-strings -mno-thumb-interwork -mcpu=arm7tdmi -g -O2 -ffunction-sections -fdata-sections -fno-rtti -fno-exceptions -Wp,-MD,src/startup.tmp -o src/infra_startup.o /home/ed/Downloads/ecos-cvs-120723/packages/infra/current/src/startup.cxx In file included from /home/ed/Downloads/ecos-test_install/include/cyg/kernel/mlqueue.hxx:63:0, from /home/ed/Downloads/ecos-test_install/include/cyg/kernel/sched.hxx:131, from /home/ed/Downloads/ecos-cvs-120723/packages/infra/current/src/startup.cxx:69: /home/ed/Downloads/ecos-test_install/include/cyg/infra/clist.hxx:304:1: error: template with C linkage template class T class Cyg_CList_T ^ /home/ed/Downloads/ecos-test_install/include/cyg/infra/clist.hxx:347:1: error: template with C linkage template class T class Cyg_DNode_T ^ make[1]: *** [src/startup.o.d] Error 1
[Bug libgcc/65902] New: GCC-5.1 fails to bootstrap for eCos/arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65902 Bug ID: 65902 Summary: GCC-5.1 fails to bootstrap for eCos/arm-eabi Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: bernd.edlinger at hotmail dot de Target Milestone: --- build for eCos fails in libgcc because sys-include/cyg/infra/cyg_type.h typedef's bool and libgcc/unwind-arm-common.inc defines it too. ../gcc-5.1.0/configure --prefix=/home/ed/gnu/arm-eabi --target=arm-eabi --with-newlib --enable-languages=c,c++ --disable-hosted-libstdcxx --disable-__cxa-atexit --disable-libquadmath --disable-decimal-float make [...] /home/ed/gnu/gcc-build-arm/./gcc/xgcc -B/home/ed/gnu/gcc-build-arm/./gcc/ -B/home/ed/gnu/arm-eabi/arm-eabi/bin/ -B/home/ed/gnu/arm-eabi/arm-eabi/lib/ -isystem /home/ed/gnu/arm-eabi/arm-eabi/include -isystem /home/ed/gnu/arm-eabi/arm-eabi/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fno-inline -I. -I. -I../.././gcc -I../../../gcc-5.1.0/libgcc -I../../../gcc-5.1.0/libgcc/. -I../../../gcc-5.1.0/libgcc/../gcc -I../../../gcc-5.1.0/libgcc/../include -DHAVE_CC_TLS -o _fractunsUDIHQ.o -MT _fractunsUDIHQ.o -MD -MP -MF _fractunsUDIHQ.dep -DL_fractuns -DFROM_UDI -DTO_HQ -c ../../../gcc-5.1.0/libgcc/fixed-bit.c -fvisibility=hidden -DHIDE_EXPORTS /home/ed/gnu/gcc-build-arm/./gcc/xgcc -B/home/ed/gnu/gcc-build-arm/./gcc/ -B/home/ed/gnu/arm-eabi/arm-eabi/bin/ -B/home/ed/gnu/arm-eabi/arm-eabi/lib/ -isystem /home/ed/gnu/arm-eabi/arm-eabi/include -isystem /home/ed/gnu/arm-eabi/arm-eabi/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fno-inline -I. -I. -I../.././gcc -I../../../gcc-5.1.0/libgcc -I../../../gcc-5.1.0/libgcc/. -I../../../gcc-5.1.0/libgcc/../gcc -I../../../gcc-5.1.0/libgcc/../include -DHAVE_CC_TLS -o _fractunsUDISQ.o -MT _fractunsUDISQ.o -MD -MP -MF _fractunsUDISQ.dep -DL_fractuns -DFROM_UDI -DTO_SQ -c ../../../gcc-5.1.0/libgcc/fixed-bit.c -fvisibility=hidden -DHIDE_EXPORTS In file included from ../../../../gcc-5.1.0/libgcc/config/arm/unwind-arm.c:143:0: ../../../../gcc-5.1.0/libgcc/unwind-arm-common.inc:39:23: error: conflicting types for ‘bool’ typedef unsigned char bool; ^ In file included from /home/ed/gnu/arm-eabi/arm-eabi/sys-include/cyg/libc/stdio/stdio.h:61:0, from /home/ed/gnu/arm-eabi/arm-eabi/sys-include/stdio.h:80, from ../../../../gcc-5.1.0/libgcc/../gcc/tsystem.h:87, from ../../../../gcc-5.1.0/libgcc/unwind-arm-common.inc:25, from ../../../../gcc-5.1.0/libgcc/config/arm/unwind-arm.c:143: /home/ed/gnu/arm-eabi/arm-eabi/sys-include/cyg/infra/cyg_type.h:171:21: note: previous declaration of ‘bool’ was here typedef cyg_halbool bool; ^ In file included from ../../../../gcc-5.1.0/libgcc/config/arm/unwind-arm.c:143:0: ../../../../gcc-5.1.0/libgcc/unwind-arm-common.inc: In function ‘get_eit_entry’: ../../../../gcc-5.1.0/libgcc/unwind-arm-common.inc:245:29: warning: cast discards ‘const’ qualifier from pointer target type [-Wcast-qual] ucbp-pr_cache.ehtp = (_Unwind_EHT_Header *)eitp-content; ^ make[4]: *** [unwind-arm.o] Fehler 1 make[4]: Verlasse Verzeichnis '/home/ed/gnu/gcc-build-arm/arm-eabi/thumb/libgcc' make[3]: *** [multi-do] Fehler 1 make[3]: Verlasse Verzeichnis '/home/ed/gnu/gcc-build-arm/arm-eabi/libgcc' make[2]: *** [all-multi] Fehler 2 make[2]: *** Warte auf noch nicht beendete Prozesse... make[2]: Verlasse Verzeichnis '/home/ed/gnu/gcc-build-arm/arm-eabi/libgcc' make[1]: *** [all-target-libgcc] Fehler 2 make[1]: Verlasse Verzeichnis '/home/ed/gnu/gcc-build-arm' make: *** [all] Fehler 2
[Bug libstdc++/51617] [C++0x] async(f) isn't.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51617 torvald at gcc dot gnu.org changed: What|Removed |Added CC||torvald at gcc dot gnu.org --- Comment #11 from torvald at gcc dot gnu.org --- ISO C++ SG1 was close to deprecating std::async for other reasons, but there was too much objection to this from other parts of the committee; the main concern was that there is no replacement for the functionality. Even though the executors proposal is still being discussed and not part of any published TS yet, the parallelism TS V1 is being published. Thus, I'm not sure whether spending too much time is justified, given the potentially short-lived importance of current async().
[Bug libgcc/65902] GCC-5.1 fails to bootstrap for eCos/arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65902 --- Comment #1 from Bernd Edlinger bernd.edlinger at hotmail dot de --- this would fix the regression: --- libgcc/unwind-arm-common.inc.jj 2015-01-05 13:33:28.0 +0100 +++ libgcc/unwind-arm-common.inc2015-04-27 15:54:04.378469179 +0200 @@ -36,7 +36,7 @@ /* Definitions for C++ runtime support routines. We make these weak declarations to avoid pulling in libsupc++ unnecessarily. */ -typedef unsigned char bool; +#define bool unsigned char typedef struct _ZSt9type_info type_info; /* This names C++ type_info type */ enum __cxa_type_match_result
[Bug fortran/65903] New: Line continuation followed by comment character in string fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65903 Bug ID: 65903 Summary: Line continuation followed by comment character in string fails to compile Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: laurent.chardon at gmail dot com Target Milestone: --- Created attachment 35405 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35405action=edit Test case that fails when zero or more blank characters separate an and a ! in a string The fix implemented for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64506 has introduced a new bug. Now when a string contains the characters ! next to each other, the scanner erroneously deletes the rest of the line. The attached test case shows the problem.
[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886 --- Comment #19 from Jakub Jelinek jakub at gcc dot gnu.org --- I know it isn't the same. But, IMHO this isn't worth adding another knob which will be a maintainance nightmare.
[Bug c++/65906] New: using-declaration allowed for non-direct base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65906
Bug ID: 65906
Summary: using-declaration allowed for non-direct base class
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: danregister at poczta dot fm
Target Milestone: ---
GCC compiles without complaining the following code, which contains
using-declaration which brings constructor of non-direct base class:
#include iostream
void log(std::string msg) { std::cout msg std::endl; }
struct Base
{
Base() { log(__func__); }
Base(int, int) { log(__func__); }
};
struct D1 : Base
{
D1() { log(__func__); }
};
struct D2 : D1
{
D2() { log(__func__); }
using Base::Base;
};
int main()
{
D2 d(1, 2);
}
The output:
Base
D1
The same code compiled with clang produces: error: 'Base' is not a direct base
of 'D2', cannot inherit constructors
Possible duplicate: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32039
[Bug c++/65906] using-declaration allowed for non-direct base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65906 --- Comment #1 from Daniel Adamski danregister at poczta dot fm --- Just to clarify, it is Base() that's being called, not Base(int, int) (I should have used something else than __func__).
[Bug libstdc++/65909] check_v3_target_namedlocale blows up on targets that don't support command-line arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65909 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |UNCONFIRMED Last reconfirmed|2015-04-27 00:00:00 | Ever confirmed|1 |0 --- Comment #2 from sandra at gcc dot gnu.org --- Whoops, make that 2.4GB, not TB; I just realized I was confusing 1k blocks with bytes.
[Bug c++/39813] improve __PRETTY_FUNCTION__ for templated methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39813 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-04-27 CC|paolo.carlini at oracle dot com| Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Ever confirmed|0 |1 --- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com --- Mine.
[Bug tree-optimization/65447] AArch64: iv-opt causes bad addressing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65447 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-04-27 CC||ramana at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Confirmed.
[Bug libgomp/65362] OpenACC compilation on Tegra K1 (ARM)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65362 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-27 CC||ramana at gcc dot gnu.org Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- The feature just isn't there - patches welcome :)
[Bug libstdc++/65909] check_v3_target_namedlocale blows up on targets that don't support command-line arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65909 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-27 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Ouch! The quick fix patch is OK to commit if you want to do so, it's certainly an improvement over what we have now.
[Bug libstdc++/65909] New: check_v3_target_namedlocale blows up on targets that don't support command-line arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65909 Bug ID: 65909 Summary: check_v3_target_namedlocale blows up on targets that don't support command-line arguments Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: sandra at gcc dot gnu.org Target Milestone: --- Created attachment 35410 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35410action=edit proposed patch The test program written by check_v3_target_namedlocale in lib/libstdc++.exp accesses the string at *(argv + 1) without first checking that argc = 2. Some embedded targets don't support command-line arguments, so even though the testsuite may always invoke the test program with the required number of arguments, the program may not receive them. I'm working with a new simulator provided by a customer that prints an error message for accesses to unmapped memory and then continues execution instead of terminating with an exception. I ended up with a 2.4TB log file from running the libstdc++ testsuite because of this problem. :-( I hacked up the attached patch as a quick fix; it has the effect of making it think the requested locale is unsupported if the target has this problem. A better solution might be to write and compile a fresh program every time with a hard-coded locale name to test for. I guess it depends on whether you think embedded targets that don't support programs with command-line arguments will still be able to support named locales. I ran into this in a local GCC 4.9.2 build but the code is the same on mainline head.
[Bug libstdc++/65839] xmethods need updating once gdb decides how to fix 18285
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65839 --- Comment #3 from Doug Evans dje at google dot com --- [fyi] Here's the tentative patch for gdb. https://sourceware.org/ml/gdb-patches/2015-04/msg00947.html
[Bug ipa/65908] [5/6 Regression] ICE: in expand_thunk, at cgraphunit.c:1700
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65908 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- The problem is that IPA ICF compares the return type and argument types by looking at TREE_TYPE of DECL_RESULT (or PARM_DECLs from DECL_ARGUMENTS), but that is modified by cp_genericize. So, either in addition to comparing the types it should also compare DECL_BY_REFERENCE values of RESULT_DECL and PARM_DECLs, or it should also (or only?) look at TREE_TYPE of the FUNCTION_TYPE/METHOD_TYPE and/or TYPE_ARG_TYPES of that).
[Bug bootstrap/65910] New: r222473 breaks x86_64 darwin bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65910 Bug ID: 65910 Summary: r222473 breaks x86_64 darwin bootstrap Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: howarth.at.gcc at gmail dot com Target Milestone: --- The commit... r222473 | ctice | 2015-04-27 12:44:35 -0400 (Mon, 27 Apr 2015) | 17 lines Give proper type and size to named cold partitions. 2015-04-27 Caroline Tice cmt...@google.com * final.c (final_scan_insn): Output cold_function_nmae as function type. * varasm.c (cold_function_name): Make gloval. (assemble_start_function): Re-set cold_function_name. (assemble_end_function): Output cold partition size. * varasm.h (cold_fun ction_name): Declare global. 2015-04-27 Caroline Tice cmt...@google.com * gcc.dg/tree-prof/cold_partition_label.c (main): Check for cold partition size. breaks the bootstrap of gcc trunk on x86_64-apple-darwin using the clang compilers from Xcode 6.3. The previous commit r222472 bootstraps fine. The bootstrap failure appears as... g++ -c -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc-6-20150427/gcc -I../../gcc-6-20150427/gcc/. -I../../gcc-6-20150427/gcc/../include -I../../gcc-6-20150427/gcc/../libcpp/include -I/sw/include -I/sw/include -I../../gcc-6-20150427/gcc/../libdecnumber -I../../gcc-6-20150427/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc-6-20150427/gcc/../libbacktrace -I/sw/include -I/sw/include -o varasm.o -MT varasm.o -MMD -MP -MF ./.deps/varasm.TPo ../../gcc-6-20150427/gcc/varasm.c ... ../../gcc-6-20150427/gcc/varasm.c:1868:2: error: use of undeclared identifier 'ASM_DECLARE_FUNCTION_SIZE' ASM_DECLARE_FUNCTION_SIZE (asm_out_file, ^
[Bug libstdc++/65909] check_v3_target_namedlocale blows up on targets that don't support command-line arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65909 --- Comment #3 from sandra at gcc dot gnu.org --- Author: sandra Date: Tue Apr 28 02:40:56 2015 New Revision: 222497 URL: https://gcc.gnu.org/viewcvs?rev=222497root=gccview=rev Log: 2015-04-27 Sandra Loosemore san...@codesourcery.com PR libstdc++/65909 libstdc++-v3/ * testsuite/lib/libstdc++.exp (check_v3_target_namedlocale): Make the generated test program fail gracefully if the target doesn't support passing command-line arguments. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/lib/libstdc++.exp
[Bug target/65810] powerpc64 alignment of r2 insufficient for loading long-double constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65810 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #8 from Alan Modra amodra at gmail dot com --- Fixed
[Bug tree-optimization/65217] __builtin_unreachable in if statement causes bad assembly generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65217 --- Comment #4 from Jeffrey A. Law law at gcc dot gnu.org --- Author: law Date: Tue Apr 28 04:01:28 2015 New Revision: 222499 URL: https://gcc.gnu.org/viewcvs?rev=222499root=gccview=rev Log: PR tree-optimization/65217 * tree-ssa-dom.c (record_equality): Given two SSA_NAMEs, if just one of them has a single use, make sure it is the LHS of the implied copy. PR tree-optimization/65217 * gcc.target/i386/pr65217.c: Remove XFAIL. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pr65217.c trunk/gcc/tree-ssa-dom.c
[Bug bootstrap/65910] r222473 breaks x86_64 darwin bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65910 --- Comment #1 from Jack Howarth howarth.at.gcc at gmail dot com --- This is from a bootstrap on darwin14 with the command... % ../gcc-6-20150427/configure --prefix=/Users/howarth/dist -enable-languages=c,c++ --with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11/include --x-libraries=/usr/X11/lib --with-build-config=bootstrap-debug
[Bug target/65810] powerpc64 alignment of r2 insufficient for loading long-double constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65810 --- Comment #7 from Alan Modra amodra at gcc dot gnu.org --- Author: amodra Date: Tue Apr 28 03:47:19 2015 New Revision: 222498 URL: https://gcc.gnu.org/viewcvs?rev=222498root=gccview=rev Log: PR target/65810 * config/rs6000/rs6000.c (POWERPC64_TOC_POINTER_ALIGNMENT): Define. (offsettable_ok_by_alignment): Use minimum of decl and toc pointer alignment. Replace dead code with assertion. (use_toc_relative_ref): Add mode arg. Return false in -mcmodel=medium case if size exceeds toc pointer alignment. (rs6000_legitimize_reload_address): Update use_toc_relative_ref call. (rs6000_emit_move): Likewise. * configure.ac: Add linker toc pointer alignment check. * configure: Regenerate. * config.in: Regenerate. Modified: trunk/gcc/ChangeLog trunk/gcc/config.in trunk/gcc/config/rs6000/rs6000.c trunk/gcc/configure trunk/gcc/configure.ac
[Bug tree-optimization/65907] [6 Regression] ICE: in set_lattice_value, at tree-ssa-ccp.c:535
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65907 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- Is this a dup of PR 65851?
[Bug ipa/65858] ICE in varpool_node::get_constructor during chromium build on arm-linux-gnueabihf with LTO during LINK chrome
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65858
--- Comment #2 from prathamesh3492 at gcc dot gnu.org ---
Hi,
Sorry for late response, I applied your patch and got the following ICE:
-std=gnu++11 -flto --param lto-partitions=1
Full command line options: http://pastebin.com/6JSWH9YM
../../third_party/cld_2/src/internal/cld_generated_cjk_uni_prop_80.cc:7132:1:
internal compiler error: in output_constructor, at lto-streamer-out.c:2152
} // End namespace CLD2
^
0xb25609 output_constructor
/home/prathamesh.kulkarni/gnu-toolchain/src/gcc.git/gcc/lto-streamer-out.c:2152
0xb25609 lto_output()
/home/prathamesh.kulkarni/gnu-toolchain/src/gcc.git/gcc/lto-streamer-out.c:2354
0xb7e6c1 write_lto
/home/prathamesh.kulkarni/gnu-toolchain/src/gcc.git/gcc/passes.c:2395
0xb81c0e ipa_write_summaries_1
/home/prathamesh.kulkarni/gnu-toolchain/src/gcc.git/gcc/passes.c:2459
0xb81c0e ipa_write_summaries()
/home/prathamesh.kulkarni/gnu-toolchain/src/gcc.git/gcc/passes.c:2519
0x877dda ipa_passes
/home/prathamesh.kulkarni/gnu-toolchain/src/gcc.git/gcc/cgraphunit.c:2216
0x877dda symbol_table::compile()
/home/prathamesh.kulkarni/gnu-toolchain/src/gcc.git/gcc/cgraphunit.c:2312
0x879d3c symbol_table::finalize_compilation_unit()
/home/prathamesh.kulkarni/gnu-toolchain/src/gcc.git/gcc/cgraphunit.c:2461
0x645c40 cp_write_global_declarations()
/home/prathamesh.kulkarni/gnu-toolchain/src/gcc.git/gcc/cp/decl2.c:4757
Reduced test-case:
It appears that r49, which fixed PR65801 introduced this issue.
The following test-case also ICE's for x86.
int x { 0.5 };
int main() { return 0; }
prathamesh.kulkarni@ex40-01:~$ fsf-toolchain/bin/g++ -flto braced-init.cpp -c
-Wno-narrowing -std=gnu++11
prathamesh.kulkarni@ex40-01:~$ fsf-toolchain/bin/g++ -flto braced-init.o
lto1: internal compiler error: in get_constructor, at varpool.c:331
0xd22c43 varpool_node::get_constructor()
../../src/gcc/varpool.c:331
0xd23af8 varpool_node::assemble_decl()
../../src/gcc/varpool.c:602
0x6b8633 output_in_order
../../src/gcc/cgraphunit.c:2137
0x6b8b23 symbol_table::compile()
../../src/gcc/cgraphunit.c:2378
0x62b025 lto_main()
../../src/gcc/lto/lto.c:3496
I think it happens because, check_narrowing() returns false and it's caller
cp/semantics.c:finish_compound_literal
returns error_mark_node, which then gets streamed into object file.
Conside this part of check_narrowing():
if (!ok)
{
if (cxx_dialect == cxx98)
warning_at (EXPR_LOC_OR_LOC (init, input_location), OPT_Wnarrowing,
narrowing conversion of %qE from %qT to %qT inside { }
is ill-formed in C++11, init, ftype, type);
else if (!TREE_CONSTANT (init))
{
if (complain tf_warning_or_error)
{
pedwarn (EXPR_LOC_OR_LOC (init, input_location), OPT_Wnarrowing,
narrowing conversion of %qE from %qT to %qT inside { },
init, ftype, type);
ok = true;
}
}
else if (complain tf_error)
{
global_dc-pedantic_errors = 1;
pedwarn (EXPR_LOC_OR_LOC (init, input_location), OPT_Wnarrowing,
narrowing conversion of %qE from %qT to %qT inside { },
init, ftype, type);
global_dc-pedantic_errors = flag_pedantic_errors;
}
}
return cxx_dialect == cxx98 || ok;
For the above test-case ok is false and we enter the nested
else if (complain tf_error) block.
pedwarn() doesn't print anything here and returns 0.
That's because the following condition becomes true in
diagnostic.c:diagnostic_report_diagnostic():
/* This tests if the user provided the appropriate -Wfoo or
-Wno-foo option. */
if (! context-option_enabled (diagnostic-option_index,
context-option_state))
return false;
So diagnostic_report_diagnostic() returns false to pedwarn()
which then returns 0 to check_narrowing() and warning is not printed.
return cxx_dialect == cxx98 || ok;
Since we are compiling with gnu++11 mode, cxx_dialect
is not cxx98 and ok is false, hence check_narrowing() returns false.
cp/semantics.c:finish_compound_literal() calls check_narrowing():
if (SCALAR_TYPE_P (type)
!BRACE_ENCLOSED_INITIALIZER_P (compound_literal)
!check_narrowing (type, compound_literal, complain))
return error_mark_node;
I suppose that check_narrowing() returns false here and the above if condition
becomes true and finish_compound_literal() returns
error_mark_node which is then streamed. Is that correct ?
I tried with the following untested patch, which prevents the ICE,
but not sure if it's the right approach:
diff --git a/gcc/cp/typeck2.c b/gcc/cp/typeck2.c
index 884957b..2a25c20 100644
--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -872,8 +872,7 @@ check_narrowing (tree type, tree init, tsubst_flags_t
complain)
bool ok =
[Bug c/65901] no warning or error for va_arg (ap, void)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65901
--- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org ---
Untested patch:
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -12648,6 +12648,11 @@ c_build_va_arg (location_t loc, tree expr, tree type)
if (warn_cxx_compat TREE_CODE (type) == ENUMERAL_TYPE)
warning_at (loc, OPT_Wc___compat,
C++ requires promoted type, not enum type, in %va_arg%);
+ if (type == error_mark_node || !COMPLETE_TYPE_P (type))
+{
+ c_incomplete_type_error (NULL_TREE, type);
+ return error_mark_node;
+}
return build_va_arg (loc, expr, type);
}
[Bug tree-optimization/65887] remove va_arg ap copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65887
--- Comment #4 from vries at gcc dot gnu.org ---
(In reply to Richard Biener from comment #3)
(In reply to vries from comment #2)
Rather than marking the va_list arg addressable in all the cases above
you should probably simply ensure the frontend marks it so from the
point it creates a variable with va_list type. This is because even
va_list a1, a2;
a1 = a2;
__builtin_va_arg (a1, ...);
might go wrong when gimplifying a1 = a2.
This seems to do the trick, I'll put it through some more testing:
...
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 9797e17..d6a93d9 10044
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -5910,6 +5910,7 @@ set_compound_literal_name (tree decl)
tree
build_va_arg (location_t loc, tree expr, tree type)
{
+ mark_addressable (expr);
expr = build1 (VA_ARG_EXPR, type, expr);
SET_EXPR_LOCATION (expr, loc);
return expr;
...
[Bug tree-optimization/65907] [6 Regression] ICE: in set_lattice_value, at tree-ssa-ccp.c:535
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65907
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-04-27
Ever confirmed|0 |1
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
trippels@gcc2-power8 Support % YAMLParser.ii
template typename class A;
template class struct B;
template typename _CharT, typename = A_CharT class C;
template struct Bchar { static int m_fn1(char *); };
template typename, typename class C {
struct _Alloc_hider {
_Alloc_hider(int);
} _M_dataplus;
public:
C(char *p1) : _M_dataplus(0) { p1 ? Bchar::m_fn1(p1) : 0; }
};
int a, c;
char b[0];
inline char *fn1(char *p1, int) {
--p1;
if (a == 0)
*--p1 = '0';
if (a)
*--p1 = 0;
return p1;
}
inline Cchar fn2() { return fn1(b, 0); }
void fn3() {
for (int i;; ++i)
if (i)
if (c)
fn2();
}
trippels@gcc2-power8 Support % /home/trippels/gcc_test/usr/local/bin/g++ -fPIC
-std=c++11 -O2 -c YAMLParser.ii
YAMLParser.ii: In function ‘void fn3()’:
YAMLParser.ii:24:6: internal compiler error: in set_lattice_value, at
tree-ssa-ccp.c:535
void fn3() {
^
0x10b6f98b set_lattice_value
../../gcc/gcc/tree-ssa-ccp.c:535
0x10b70bbf ccp_visit_phi_node
../../gcc/gcc/tree-ssa-ccp.c:1147
0x10c14337 simulate_stmt
../../gcc/gcc/tree-ssa-propagate.c:344
0x10c16507 simulate_block
../../gcc/gcc/tree-ssa-propagate.c:485
0x10c16507 ssa_propagate(ssa_prop_result (*)(gimple_statement_base*,
edge_def**, tree_node**), ssa_prop_result (*)(gphi*))
../../gcc/gcc/tree-ssa-propagate.c:928
0x10b6db3f do_ssa_ccp
../../gcc/gcc/tree-ssa-ccp.c:2411
0x10b6db3f execute
../../gcc/gcc/tree-ssa-ccp.c:2444
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug web/64968] Upgrade GCC Bugzilla to 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #12 from Mikael Morin mikael at gcc dot gnu.org --- Hello, not sure this is due to the upgrade, but the attachment appears empty in the page: https://gcc.gnu.org/bugzilla/attachment.cgi?id=35405action=edit
[Bug c++/65851] ice in set_lattice_value at tree-ssa-cc p.c:535
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65851 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #6 from Markus Trippelsdorf trippels at gcc dot gnu.org --- *** Bug 65907 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/65907] [6 Regression] ICE: in set_lattice_value, at tree-ssa-ccp.c:535
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65907 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to H.J. Lu from comment #2) Is this a dup of PR 65851? Yes, very likely. *** This bug has been marked as a duplicate of bug 65851 ***
[Bug c++/63540] Erroneous 'Derived' declares a move constructor or move assignment operator in error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63540
Daniel Adamski danregister at poczta dot fm changed:
What|Removed |Added
CC||danregister at poczta dot fm
--- Comment #2 from Daniel Adamski danregister at poczta dot fm ---
I have another variant of that issue:
struct Base
{
Base() {}
Base(const Base ) {}
Base operator=(Base ) { return *this; }
};
struct D1 : Base
{
using Base::operator=;
D1 operator=(const D1) { return *this; }
};
int main()
{
D1 x;
D1 y = x;
(void) y;
}
The error:
test.cpp: In function ‘int main()’:
test.cpp:19:12: error: use of deleted function ‘D1::D1(const D1)’
D1 y = x;
^
test.cpp:10:8: note: ‘D1::D1(const D1)’ is implicitly declared as deleted
because ‘D1’ declares a move constructor or move assignment operator
struct D1 : Base
It's enough to remove one of the lines (any one) from D1 for the error to go
away.
Yet another variant:
struct Base
{
Base() {}
Base(const Base ) {}
Base operator=(Base ) { return *this; }
};
struct D1 : Base
{
using Base::operator=;
};
struct D2 : D1
{
D2 operator=(const D2 ) { return *this; }
};
int main()
{
D1 x;
D1 y = x;
(void) y;
}
The error is the same. The operator=() in D2 doesn't have to be D2's
assignment operator. It may some other operator(), e.g., operator(int) or
it may be using D1::operator=; or using Base::operator=;
[Bug c/65901] no warning or error for va_arg (ap, void)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65901 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-27 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- We should probably reject such a program. G++/clang reject that as well.
[Bug c/65891] -Wlogical-op now warns about logical ‘and’ of equal expressions even when different types/sizeofs are involved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65891 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|mpolacek at gcc dot gnu.org|unassigned at gcc dot gnu.org --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- In the ML I wrote: I'm afraid there isn't an easy solution to this; the problem is that we fold sizeof early, so the warning sees t sizeof 4 t 4 Thus unassigning for now.
[Bug fortran/65894] [6 Regression] severe regression in gfortran 6.0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894 --- Comment #8 from vehre at gcc dot gnu.org --- Created attachment 35407 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35407action=edit A first patch. With the attached patch your small test case and the testsuite runs w/o segfault now. Furthermore does gcc6 bootstrap and regtest ok with the patch.
[Bug c/64610] No -Wbool-compare warning on (0 != a) = 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64610 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |6.0
[Bug rtl-optimization/65862] [MIPS] IRA/LRA issue: integers spilled to floating-point registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65862
Vladimir Makarov vmakarov at gcc dot gnu.org changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comment #3 from Vladimir Makarov vmakarov at gcc dot gnu.org ---
The result of the old patch which makes ALL_REGS available changes
the order of coloring and, as a consequence, the result of allocation for r218
and r220 after IRA. That is unfortunate result of heuristics approaches.
Before the patch:
...
Popping a4(r218,l0) -- assign reg 30
Popping a0(r220,l0) -- spill
...
Disposition:
... 4:r218 l0306:r219 l0160:r220 l0 mem
After patch:
Popping a0(r220,l0) -- assign reg 30
Popping a4(r218,l0) -- (memory is more profitable 184 vs 191) spill!
...
Disposition:
... 4:r218 l0 mem6:r219 l0160:r220 l030
The costs of MEM and FP_REGS are the same as for example r218 occurs in 2
insns:
59: r218:SI=r194:SI=0x1
16: pc={(r218:SI!=0)?L18:pc}
The costs are equal if cost of moving general regs to/from fp regs or
memory are equal. So it looks ok to me.
r218 spilled in IRA is reassigned to a fp reg in *LRA*. It could be
changed if we used only preferred class in LRA for this. In this
case, r218 stays spilled and we remove one insn (saving the allocated
fp reg):
sdc1$f20,64($sp)
I am not sure, that the result code is better as we access memory 3
times instead of access to $f20.
But I could try to use preferred class in LRA (after checking how it
affects x86/x86-64 performance), if such solution is ok for you.
But I can not just revert the patch making ALL_REGS available to make
coloring heuristic more fotunate for your particular case, as it
reopens the old PR for which the patch was created and i have no other
solutions for the old PR.
Robert, please let me know what do you think.
[Bug web/64968] Upgrade GCC Bugzilla to 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968 --- Comment #13 from Frank Ch. Eigler fche at redhat dot com --- (In reply to Mikael Morin from comment #12) Hello, not sure this is due to the upgrade, but the attachment appears empty in the page: https://gcc.gnu.org/bugzilla/attachment.cgi?id=35405action=edit This appears to be due to CSS/JS goo marking that attachment textarea as display: none !important for some reason.
[Bug fortran/60322] [OOP] Incorrect bounds on polymorphic dummy array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60322 --- Comment #9 from vehre at gcc dot gnu.org --- Author: vehre Date: Mon Apr 27 17:41:01 2015 New Revision: 222478 URL: https://gcc.gnu.org/viewcvs?rev=222478root=gccview=rev Log: 2015-04-27 Andre Vehreschild ve...@gmx.de PR fortran/60322 Add tests forgotten to svn-add. * gfortran.dg/class_allocate_19.f03: New test. * gfortran.dg/class_array_20.f03: New test. * gfortran.dg/class_array_21.f03: New test. * gfortran.dg/finalize_29.f08: New test. Added: trunk/gcc/testsuite/gfortran.dg/class_allocate_19.f03 trunk/gcc/testsuite/gfortran.dg/class_array_20.f03 trunk/gcc/testsuite/gfortran.dg/class_array_21.f03 trunk/gcc/testsuite/gfortran.dg/finalize_29.f08 Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/57335] internal compiler error: in cxx_eval_bit_field_ref, at cp/semantics.c:6977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57335 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ktietz at gcc dot gnu.org --- Comment #11 from Kai Tietz ktietz at gcc dot gnu.org --- Mine.
[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ktietz at gcc dot gnu.org --- Comment #11 from Kai Tietz ktietz at gcc dot gnu.org --- Fixed with delayed-folding for C++. Therefore mine.
[Bug c++/65906] using-declaration allowed for non-direct base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65906 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-27 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Daniel Adamski from comment #0) Possible duplicate: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32039 Maybe, but there is a specific rule regarding inheriting constructors that applies here and not for 32039, in [namespace.udecl]/3: If such a using-declaration names a constructor, the nested-name-specifier shall name a direct base class of the class being defined;
[Bug fortran/65841] Seg fault on intrinsic assignment to allocatable derived type with allocatable component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65841 --- Comment #5 from vehre at gcc dot gnu.org --- Author: vehre Date: Mon Apr 27 17:34:11 2015 New Revision: 222477 URL: https://gcc.gnu.org/viewcvs?rev=222477root=gccview=rev Log: gcc/fortran 2015-04-27 Andre Vehreschild ve...@gmx.de PR fortran/59678 PR fortran/65841 * trans-array.c (duplicate_allocatable): Fixed deep copy of allocatable components, which are liable for copy only, when they are allocated. (gfc_duplicate_allocatable): Add deep-copy code into if component allocated block. Needed interface change for that. (gfc_copy_allocatable_data): Supplying NULL_TREE for code to add into if-block for checking whether a component was allocated. (gfc_duplicate_allocatable_nocopy): Likewise. (structure_alloc_comps): Likewise. * trans-array.h: Likewise. * trans-expr.c (gfc_trans_alloc_subarray_assign): Likewise. * trans-openmp.c (gfc_walk_alloc_comps): Likewise. gcc/testsuite 2015-04-27 Andre Vehreschild ve...@gmx.de PR fortran/59678 PR fortran/65841 * gfortran.dg/alloc_comp_deep_copy_1.f03: New test. * gfortran.dg/alloc_comp_deep_copy_2.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_deep_copy_1.f03 trunk/gcc/testsuite/gfortran.dg/alloc_comp_deep_copy_2.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-array.h trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-openmp.c trunk/gcc/testsuite/ChangeLog
