clang vs free software
Helmut Eller eller.hel...@gmail.com: If nobody bothers with even considering the question, it would appear that it is not all that important... Maybe nobody bothers because using clang is easier than to fight with FSF policies. Which is pretty close if not identical to my original point. The clang people aren't just a technical challenge to GCC, they're a philosophical/political one to the FSF as well. They are explicitly reacting, and positioning themselves publicly against, what they consider FSF over-control. It is never a good idea to exclude political and social ramifications from the software design and use decisions... It so happens that over the long hall, the free software ends up being technologically superiormost often. But this is besides the point. The clearest possible statement of this is in Chandler Carruth's talk Clang: Defending C++ from Murphy's Million Monkeys (all over YouTube) in which he explains why we set out to build another C++ compiler by beginning with this question posted to the gcc list: is there are reason for not making the [GCC] front ends dynamic libraries which could be linked by any program that wants to parse source code? Carruth then quotes RMS: One of our main goals for GCC is to prevent any parts of it from being used together with non-free software. Thus, we have deliberately avoided many things that might possibly have the effect of facilitating such usage... Carruth then says, exasperation very obvious in his voice, This is *not* a *useful answer*! (about 3:42 in the video). Clearly this is a complete break off now of the BSD community but there is another half of this story, because the platform that most of us have gotten compfortable with over the last decade is now being flanked on several levels for which the compiler keychain is maybe just the last straw. I think it might be necessary in the near future to just break with the current Linux platform altogether, and maybe rebuild a BSD based system with the FSF tool kit and start there as a new base. Thus, the clang project. They want to build IDEs and other tools that share the compiler's code. GCC policy won't let them do that. Ergo, GCC must be kicked aside. The clang developers are demonstrating that they have the capacity to make good on this threat. clang is not a toy or a laboratory demonstration; it is a real, production-quality compiler with some significant advantages over GCC. Much more useful error messages is one; a newer generation of optimization leading to smaller, tighter code is another; and much faster compilation is yet another. It is just another compiler in order to make non-free software. It is the free software platform as a whole that is being seriously strained. The Clang vs Other Open Source Compilers page admits that GCC supports more targets than LLVM and GCC supports languages that clang does not aim to, but these are not stable advantages given the technical strength of LLVM and the large amount of developer commitment clang now has. I'm not pointing out these facts to argue with the FSF's past decisions, but to ask What are you going to do now? More of the same will not serve. GCC is in near-term danger of losing its dominance in open-source C development; I would say the danger is imminent if not that people are innately conservative about major changes Uh huh. You know what, it won't matter with UEFI and if systemd continues to absorb the entire GNU toolkit. It is not just BSD that will no longer have GNU/Roots The GNU/Linux is almost dead in its own right. to their toolchains. The other shoe will drop when a major Linux distribution ships with clang as its default compiler; I could easily see this happening before the end of 2015, followed by a cascade of me-too defections. To keep its #1 spot, GCC needs to out-improve and out-compete clang. And not just on the technical level, either. Using clang is easier than to fight with FSF policies indeed. Unless that changes, GCC's future is as a legacy tool, a backwater that developers are exiting as fast as is practical. [QUOTE]I'm an engineer. I choose the best tool for the job, politics be damned. You must be a stupid engineer then, because politcs and technology have been attacted at the hip since the 1st dynasty in Ancient Egypt. I guess you missed that one. [/QUOTE] Right now, it is hard to find a distribution that functions, and they have less GNU tools on them every day. As I've said before, I don't personally care who wins; either tool will serve my needs. I would prefer to see both flourish and compete with each other. But that's not where things are heading unless GCC ups its game. That won't even scratch the surface. Consider this... UEFI puts a operating system between you and your hardware. Without a secure boot, it is a security flaw...outright. WITH a secure boot, it is no better than the Apple Appstore because you can't change the
Merging the ./config directory between GCC and Binutils
Hi! Yesterday, an outstanding fix was committed to the GCC repo for a not correctly regenerated file. Now that that's fixed, I'll merge the two ./config directories (unfortunately, both the Binutils and the GCC tree gained commits that weren't synced) and come up with a patch. I hope that there won't be too many commits in the mean time, to produce a lot of fuzz :) Once that's in sync again, I'll keep a script running to check that and report missing commits in any of the trees. MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: Wenn ich wach bin, träume ich. the second : signature.asc Description: Digital signature
Re: gcc-4_9 inlines less funcs than gcc-4_8 because of used_as_abstract_origin flag.
Hi,
this is patch I commited to mainline
2014-11-22 Jan Hubicka hubi...@ucw.cz
* ipa.c (symbol_table::remove_unreachable_nodes): Mark all inline clones
as having abstract origin used.
* ipa-inline-transform.c (can_remove_node_now_p_1): Drop abstract
origin check.
(clone_inlined_nodes): Copy abstract originflag.
* ipa-cgraph.c (working): Use get_create to get abstract origin node.
Index: ipa.c
===
--- ipa.c (revision 217890)
+++ ipa.c (working copy)
@@ -360,9 +360,18 @@ symbol_table::remove_unreachable_nodes (
DECL_ABSTRACT_ORIGIN (node-decl))
{
struct cgraph_node *origin_node
- = cgraph_node::get_create (DECL_ABSTRACT_ORIGIN (node-decl));
- origin_node-used_as_abstract_origin = true;
- enqueue_node (origin_node, first, reachable);
+ = cgraph_node::get (DECL_ABSTRACT_ORIGIN (node-decl));
+ if (origin_node !origin_node-used_as_abstract_origin)
+ {
+ origin_node-used_as_abstract_origin = true;
+ gcc_assert (!origin_node-prev_sibling_clone);
+ gcc_assert (!origin_node-next_sibling_clone);
+ for (cgraph_node *n = origin_node-clones; n;
+ n = n-next_sibling_clone)
+ if (n-decl == DECL_ABSTRACT_ORIGIN (node-decl))
+ n-used_as_abstract_origin = true;
+ enqueue_node (origin_node, first, reachable);
+ }
}
/* If any symbol in a comdat group is reachable, force
all externally visible symbols in the same comdat
Index: ipa-inline-transform.c
===
--- ipa-inline-transform.c (revision 217890)
+++ ipa-inline-transform.c (working copy)
@@ -100,7 +100,6 @@ can_remove_node_now_p_1 (struct cgraph_n
the callgraph so references can point to it. */
return (!node-address_taken
!node-has_aliases_p ()
- !node-used_as_abstract_origin
node-can_remove_if_no_direct_calls_p ()
/* Inlining might enable more devirtualizing, so we want to remove
those only after all devirtualizable virtual calls are processed.
@@ -218,6 +217,7 @@ clone_inlined_nodes (struct cgraph_edge
update_original, vNULL, true,
inlining_into,
NULL);
+ n-used_as_abstract_origin = e-callee-used_as_abstract_origin;
e-redirect_callee (n);
}
}
Index: lto-cgraph.c
===
--- lto-cgraph.c(revision 217890)
+++ lto-cgraph.c(working copy)
@@ -877,7 +877,8 @@ compute_ltrans_boundary (lto_symtab_enco
if (DECL_ABSTRACT_ORIGIN (node-decl))
{
struct cgraph_node *origin_node
- = cgraph_node::get (DECL_ABSTRACT_ORIGIN (node-decl));
+ = cgraph_node::get_create (DECL_ABSTRACT_ORIGIN (node-decl));
+ origin_node-used_as_abstract_origin = true;
add_node_to (encoder, origin_node, true);
}
}
Re: gcc-4_9 inlines less funcs than gcc-4_8 because of used_as_abstract_origin flag.
Thanks for the fix. Is it ok to backport it to gcc-4_9? Yes, it is OK assuming that there are no problems with the patch for a week. (it ought to be safe) Honza
[Bug target/64008] [SH] sh4-linux configured compiler rejects -m4-nofpu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64008 --- Comment #3 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to Oleg Endo from comment #2) and a patch from somewhere else that seems related: http://cgit.openembedded.org/openembedded/plain/recipes/gcc/gcc-4.5/sh4- multilib.patch Perhaps I don't get the original problem. The kernel folks used to specify --with-multilib-list=m4,m4-nofpu during configuring sh4-linux gcc. Doesn't it work now?
[Bug ipa/61602] [5 Regression] ICE in lto1 on x86_64-linux-gnu in ipa_single_use, at ipa.c:1257
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61602
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 ---
An overnight csmith run came up with the same issue:
~ % cat crash1.i
int a;
int *b = a, **c = b;
int
main ()
{
int **d = b;
*d = 0;
}
~ % gcc -O2 -flto crash2.i
lto1: internal compiler error: in ipa_single_use, at ipa.c:1299
[Bug go/64021] New: Empty struct vs libffi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64021 Bug ID: 64021 Summary: Empty struct vs libffi Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: rth at gcc dot gnu.org CC: cmang at google dot com In go_struct_to_ffi, an empty struct is maped to ffi_type_void. On i386, some ABIs return a struct pop 4 bytes of stack. If one calls a function returning a structure without preparing for this, the stack will be corrupted. On sparc32, functions returning a structure return to a different address. If one calls a function returning a structure without preparing for this, the instruction after the call will be skipped. In both cases, this causes reflect/all_test.go returnEmpty to fail. I wonder what's better: follow C++ and map empty structures to a single byte (i.e. no more zero-sized structures), or enhance libffi to be able to deal with empty structures so that we don't have to lie to libffi about the type being manipulated?
[Bug go/64021] Empty struct vs libffi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64021 --- Comment #1 from Richard Henderson rth at gcc dot gnu.org --- Oh, that should read fail after the merge of the new libffi. Current libffi happens to have nothing interesting in the stack slot that's incorrectly popped, and to happens not to fail. Not so with the ffi_call_go rewrite.
[Bug fortran/64022] New: [F2003][IEEE] ieee_support_flag does not handle kind=10 and kind=16 REAL variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64022 Bug ID: 64022 Summary: [F2003][IEEE] ieee_support_flag does not handle kind=10 and kind=16 REAL variables Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: fxcoudert at gcc dot gnu.org Reported by Ian D Chivers and Jane Sleightholme. The following program is rejected at compile time with: if ( ieee_support_flag(ieee_all(i),z) ) then 1 Error: There is no specific function for the generic 'ieee_support_flag' at (1) In the program below, z is a REAL(kind=16) variable but kind=10 has the same issue. module precision_module implicit none integer, parameter :: sp = selected_real_kind( 6, 37) integer, parameter :: dp = selected_real_kind(15, 307) integer, parameter :: qp = selected_real_kind(30, 291) end module precision_module program ch3402 use precision_module use ieee_arithmetic implicit none real (sp) :: x = 1.0 real (dp) :: y = 1.0_dp real (qp) :: z = 1.0_qp integer :: i character*20 , dimension(5) :: flags = (/ 'IEEE_DIVIDE_BY_ZERO ' , 'IEEE_INEXACT' , 'IEEE_INVALID' , 'IEEE_OVERFLOW ' , 'IEEE_UNDERFLOW ' /) do i=1,5 if ( ieee_support_flag(ieee_all(i),x) ) then write(unit=*,fmt=10) flags(i) 10 format(a20,' 32 bit support') endif if ( ieee_support_flag(ieee_all(i),y) ) then write(unit=*,fmt=20) flags(i) 20 format(a20,' 64 bit support') endif if ( ieee_support_flag(ieee_all(i),z) ) then write(unit=*,fmt=30)flags(i) 30 format(a20,'128 bit support') endif end do end program ch3402
[Bug target/63783] [4.9/5 Regression] [SH] Miscompilation of boolean negation on SH4 using -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63783 --- Comment #18 from Michael Karcher gcc-bugzilla at mkarcher dot dialup.fu-berlin.de --- As I said, I did not try your patch, but just read the source. The assembly you quoted convinces me that there is no problem in the code actually produced by your patch, which is great. This is caused by the pattern or-then-SImode-compare, as you explained. The or-then-SImode-compare optimization has an adverse effect on the test coverage, it seems. In both cases, GET_MODE(src_reg) and GET_MODE(dst_reg) are SImode, so the DImode output branch is not tested by any of your two example source files. Furthermore, it looks like make_not_reg_insn will actually produce bad code if it were ever called with GET_MODE(src_reg) == DImode. So I would strongly suggest to narrow it to only accept SImode input operands, so it fails to apply instead of generate bad code if something manages to call it with DImode input.
[Bug bootstrap/64023] New: [5 Regression] r216964 breaks bootstrap on darwin when using gcc as the bootstrap compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64023 Bug ID: 64023 Summary: [5 Regression] r216964 breaks bootstrap on darwin when using gcc as the bootstrap compiler. Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: fxcoudert at gcc dot gnu.org, howarth at bromo dot med.uc.edu, iains at gcc dot gnu.org, jakub at redhat dot com Host: x86_64-apple-darwin* Target: x86_64-apple-darwin* Build: x86_64-apple-darwin* When using gcc as the bootstrap compiler, bootstrapping fails at stage 3 on darwin after r216964: libtool: link: /opt/gcc/p_build/./gcc/xg++ -B/opt/gcc/p_build/./gcc/ -nostdinc++ -nostdinc++ -I/opt/gcc/p_build/x86_64-apple-darwin14.0.0/libstdc++-v3/include/x86_64-apple-darwin14.0.0 -I/opt/gcc/p_build/x86_64-apple-darwin14.0.0/libstdc++-v3/include -I/opt/gcc/p_work/libstdc++-v3/libsupc++ -I/opt/gcc/p_work/libstdc++-v3/include/backward -I/opt/gcc/p_work/libstdc++-v3/testsuite/util -L/opt/gcc/p_build/x86_64-apple-darwin14.0.0/libstdc++-v3/src -L/opt/gcc/p_build/x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs -L/opt/gcc/p_build/x86_64-apple-darwin14.0.0/libstdc++-v3/libsupc++/.libs -B/opt/gcc/gcc4.10p-217961/x86_64-apple-darwin14.0.0/bin/ -B/opt/gcc/gcc4.10p-217961/x86_64-apple-darwin14.0.0/lib/ -isystem /opt/gcc/gcc4.10p-217961/x86_64-apple-darwin14.0.0/include -isystem /opt/gcc/gcc4.10p-217961/x86_64-apple-darwin14.0.0/sys-include -Wl,-undefined -Wl,dynamic_lookup -o .libs/libcc1.0.so -bundle .libs/findcomp.o .libs/libcc1.o .libs/names.o .libs/callbacks.o .libs/connection.o .libs/marshall.o -L/opt/gcc/p_build/x86_64-apple-darwin14.0.0/libstdc++-v3/src -L/opt/gcc/p_build/x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs -L/opt/gcc/p_build/x86_64-apple-darwin14.0.0/libstdc++-v3/libsupc++/.libs -static-libstdc++ -static-libgcc -Wl,-no_pie ../libiberty/pic/libiberty.a -Wl,-exported_symbols_list,.libs/libcc1-symbols.expsym ld: file not found: libstdc++.a see https://gcc.gnu.org/ml/gcc-patches/2014-11/msg1.html and analysis at https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00731.html. Note that bootstrap succeeds when using clang as the bootstrap compiler (no support for Ada). The following patch from Iain Sandoe restores bootstrap: --- ../_clean/libcc1/Makefile.in2014-11-07 17:38:40.0 +0100 +++ libcc1/Makefile.in2014-11-08 19:39:34.0 +0100 @@ -98,6 +98,10 @@ LTCXXCOMPILE = $(LIBTOOL) --tag=CXX $(AM --mode=compile $(CXX) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \ $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS) CXXLD = $(CXX) + +CXX_LFLAGS = \ + -Xcompiler -B../$(target_noncanonical)/libstdc++-v3/src/.libs \ + -Xcompiler -B../$(target_noncanonical)/libstdc++-v3/libsupc++/.libs CXXLINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \ --mode=link $(CXXLD) $(AM_CXXFLAGS) $(CXXFLAGS) $(AM_LDFLAGS) \ $(LDFLAGS) -o $@ @@ -276,7 +280,7 @@ libcc1plugin_la_LIBADD = $(libiberty) libcc1plugin_la_DEPENDENCIES = $(libiberty_dep) libcc1plugin_la_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) \ $(LIBTOOLFLAGS) --mode=link $(CXXLD) $(AM_CXXFLAGS) \ -$(CXXFLAGS) $(libcc1plugin_la_LDFLAGS) $(LTLDFLAGS) -o $@ +$(CXXFLAGS) $(libcc1plugin_la_LDFLAGS) $(CXX_LFLAGS) $(LTLDFLAGS) -o $@ LTLDFLAGS = $(shell $(SHELL) $(top_srcdir)/../libtool-ldflags $(LDFLAGS)) libcc1_la_LDFLAGS = -module -export-symbols $(srcdir)/libcc1.sym @@ -285,7 +289,7 @@ libcc1_la_LIBADD = $(libiberty) libcc1_la_DEPENDENCIES = $(libiberty_dep) libcc1_la_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) \ $(LIBTOOLFLAGS) --mode=link $(CXXLD) $(AM_CXXFLAGS) \ -$(CXXFLAGS) $(libcc1_la_LDFLAGS) $(LTLDFLAGS) -o $@ +$(CXXFLAGS) $(libcc1_la_LDFLAGS) $(CXX_LFLAGS) $(LTLDFLAGS) -o $@ all: $(BUILT_SOURCES) cc1plugin-config.h $(MAKE) $(AM_MAKEFLAGS) all-am
[Bug bootstrap/64023] [5 Regression] r216964 breaks bootstrap on darwin when using gcc as the bootstrap compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64023 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-22 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed.
[Bug target/63949] Aarch64 instruction combiner does not optimize subsi_sxth function as expected (gcc.target/aarch64/extend.c fails)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63949 --- Comment #3 from Richard Earnshaw rearnsha at gcc dot gnu.org --- make_extraction is unable to generate bit-field extractions in more than one mode. This causes the extractions that it does generate to be wrapped in subregs when SImode results are wanted. Ideally, we should teach make_extraction to be more sensible, but I'm not sure what the impact of that would be on other ports that really can only support one mode for bit-field extracts.
[Bug target/63783] [4.9/5 Regression] [SH] Miscompilation of boolean negation on SH4 using -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63783 --- Comment #19 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Michael Karcher from comment #18) As I said, I did not try your patch, but just read the source. The assembly you quoted convinces me that there is no problem in the code actually produced by your patch, which is great. This is caused by the pattern or-then-SImode-compare, as you explained. The or-then-SImode-compare optimization has an adverse effect on the test coverage, it seems. In both cases, GET_MODE(src_reg) and GET_MODE(dst_reg) are SImode, so the DImode output branch is not tested by any of your two example source files. That is true as it stands now. However, we already anticipate that there might be something going on with DImode stuff, so just adding the test might help debugging in the future. Even if it doesn't add any value now, it doesn't hurt anyone either. Furthermore, it looks like make_not_reg_insn will actually produce bad code if it were ever called with GET_MODE(src_reg) == DImode. Please do explain. So I would strongly suggest to narrow it to only accept SImode input operands, so it fails to apply instead of generate bad code if something manages to call it with DImode input. If that should ever happen, we already have a test case that will pop up in the test results.
[Bug bootstrap/64023] [5 Regression] r216964 breaks bootstrap on darwin when using gcc as the bootstrap compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64023 --- Comment #2 from Iain Sandoe iains at gcc dot gnu.org --- as commented in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 c#14..17 this is caused by $(HOST_EXPORTS) being used at stage#N1 instead of $(POSTSTAGE1_HOST_EXPORTS) Thus the config test for the bootstrap compiler is affecting the later build. In this case, GCC fails to build because it supports -static-libstdc++ (and thus the option is passed to the build) but it then needs the -B options to allow for spec substitution to work for libstdc++. These are not present in HOST_EXPORTS because, obviously, the host compiler is installed and doesn't need them. NOTE: (clang succeeds because it does not support -staticlibstdc++, so that option is not passed to the stage#3 libs build. However in that case the fault is potentially more subtle, because the library is then being linked with a dependency on the *system* libstdc++.dylib and not the current build.
[Bug c++/61649] fixincludes update for solaris___restrict in sys/feature_tests.h on Illumos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61649 --- Comment #1 from Richard PALO richard at netbsd dot org --- given https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52168, it seems necessary to update the test_text line with a newline appended as follows so that check.sh doesn't balk: +test_text = #if (defined(__STDC__) defined(_STDC_C99))\n + #define_RESTRICT_KYWD restrict;
[Bug ipa/63852] [5 regression] acats failures on x86_64-apple-darwin14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63852 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Target|x86_64-apple-darwin14 |x86_64-apple-darwin1* Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-22 Host|x86_64-apple-darwin14 |x86_64-apple-darwin1* Summary|[5.0 regression] acats |[5 regression] acats |failures on |failures on |x86_64-apple-darwin14 |x86_64-apple-darwin14 Ever confirmed|0 |1 Build|x86_64-apple-darwin14 |x86_64-apple-darwin1* --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still present at r217951 and also seen on x86_64-apple-darwin10.
[Bug target/63783] [4.9/5 Regression] [SH] Miscompilation of boolean negation on SH4 using -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63783 --- Comment #20 from Michael Karcher gcc-bugzilla at mkarcher dot dialup.fu-berlin.de --- (In reply to Oleg Endo from comment #19) The or-then-SImode-compare optimization has an adverse effect on the test coverage, it seems. In both cases, GET_MODE(src_reg) and GET_MODE(dst_reg) are SImode, so the DImode output branch is not tested by any of your two example source files. That is true as it stands now. However, we already anticipate that there might be something going on with DImode stuff, so just adding the test might help debugging in the future. Even if it doesn't add any value now, it doesn't hurt anyone either. The test case is not a problem - but it would be helpful to have a testcase that actually tests the DImode output case. I understand that it likely is not possible with today's gcc to reach that branch, so it seems this has to stay the way it is now. I am fine with it. Furthermore, it looks like make_not_reg_insn will actually produce bad code if it were ever called with GET_MODE(src_reg) == DImode. Please do explain. Of course. The instructions involving src_reg in make_not_reg_insn dealing with src_reg are completely quoted here: + // On SH we can do only SImode and DImode comparisons. + if (! (GET_MODE (src_reg) == SImode || GET_MODE (src_reg) == DImode)) +return NULL; In this fragment, you accept DImode source operands. So that code may be used to replace a DImode compare. + emit_insn (gen_rtx_SET (VOIDmode, m_ccreg, + gen_rtx_fmt_ee (EQ, SImode, src_reg, const0_rtx))); In this fragment, you are generating the replacement instruction, which is always an SImode compare. Maybe I miss the point, but I fail to undestand how an SImode compare might be acceptable on an DImode operand. Possibly, this even ICEs, I don't know enough about gcc internals to know what happens if src_reg is DImode which is passed to EQ in SImode.
[Bug preprocessor/63831] [5 Regression] r217292 causes segfaults with -MM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63831
Iain Sandoe iains at gcc dot gnu.org changed:
What|Removed |Added
Blocks||63773
--- Comment #12 from Iain Sandoe iains at gcc dot gnu.org ---
on any darwin post 11, there are headers including __has_attribute.
At present, this PR is only affecting darwin12 - and with c#10 proceeds almost
completely, but still blocks bootstrap building libada.
{hopefully, some analysis of the remaining fail will follow later today}
[Bug target/47500] -G0 option not recognized by gnat1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47500 --- Comment #10 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Sat Nov 22 11:28:56 2014 New Revision: 217962 URL: https://gcc.gnu.org/viewcvs?rev=217962root=gccview=rev Log: Backport from mainline 2014-11-20 Vincent Celier cel...@adacore.com PR ada/47500 * back_end.adb (Scan_Back_End_Switches): Skip switch -G and its argument. Modified: branches/gcc-4_9-branch/gcc/ada/ChangeLog branches/gcc-4_9-branch/gcc/ada/back_end.adb
[Bug target/47500] -G0 option not recognized by gnat1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47500 --- Comment #11 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Sat Nov 22 11:29:27 2014 New Revision: 217963 URL: https://gcc.gnu.org/viewcvs?rev=217963root=gccview=rev Log: Backport from mainline 2014-11-20 Vincent Celier cel...@adacore.com PR ada/47500 * back_end.adb (Scan_Back_End_Switches): Skip switch -G and its argument. Modified: branches/gcc-4_8-branch/gcc/ada/ChangeLog branches/gcc-4_8-branch/gcc/ada/back_end.adb
[Bug target/47500] -G0 option not recognized by gnat1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47500 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Target Milestone|5.0 |4.8.4 --- Comment #12 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Fixed on all active branches.
[Bug middle-end/63991] redundant read when write to volatile member of packed structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63991 --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org --- It looks like -fpack-struct cannot be used when -fstrict-volatile-bitfields is in effect, i.e. on ARM EABI. As for unaligned volatile fields on strict-alignment targets, they clearly ask for trouble. Simply do not use -fpack-struct.
[Bug tree-optimization/64024] New: gcc.dg/vect/vect-simd-clone-6.c ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64024 Bug ID: 64024 Summary: gcc.dg/vect/vect-simd-clone-6.c ICEs Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ubizjak at gmail dot com Created attachment 34074 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34074action=edit Preprocessed source ./cc1 -quiet -ftree-vectorize -fno-vect-cost-model -O2 -fopenmp-simd -mavx -m32 vect-simd-clone-6.i /home/uros/gcc-svn/trunk/gcc/testsuite/gcc.dg/vect/vect-simd-clone-6.c: In function ‘bar’: /home/uros/gcc-svn/trunk/gcc/testsuite/gcc.dg/vect/vect-simd-clone-6.c:24:1: internal compiler error: Segmentation fault bar (int x) ^ 0xd18076 crash_signal /home/uros/gcc-svn/trunk/gcc/toplev.c:359 0x9ca6cf is_gimple_variable /home/uros/gcc-svn/trunk/gcc/gimple-expr.h:83 0x9cd0e5 is_gimple_val(tree_node*) /home/uros/gcc-svn/trunk/gcc/gimple-expr.c:820 0xa8c59e force_gimple_operand_1(tree_node*, gimple_statement_base**, bool (*)(tree_node*), tree_node*) /home/uros/gcc-svn/trunk/gcc/gimplify-me.c:70 0xa8c79b force_gimple_operand(tree_node*, gimple_statement_base**, bool, tree_node*) /home/uros/gcc-svn/trunk/gcc/gimplify-me.c:113 0xf9b87e vectorizable_simd_clone_call /home/uros/gcc-svn/trunk/gcc/tree-vect-stmts.c:2987 0xfa9017 vect_transform_stmt(gimple_statement_base*, gimple_stmt_iterator*, bool*, _slp_tree*, _slp_instance*) /home/uros/gcc-svn/trunk/gcc/tree-vect-stmts.c:7260 0xfbd7fc vect_transform_loop(_loop_vec_info*) /home/uros/gcc-svn/trunk/gcc/tree-vect-loop.c:6131 0xfd2c01 vectorize_loops() /home/uros/gcc-svn/trunk/gcc/tree-vectorizer.c:491 0xecd257 execute /home/uros/gcc-svn/trunk/gcc/tree-ssa-loop.c:289 Please submit a full bug report,
[Bug tree-optimization/64024] gcc.dg/vect/vect-simd-clone-6.c ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64024
--- Comment #1 from Uroš Bizjak ubizjak at gmail dot com ---
gdb says:
Program received signal SIGSEGV, Segmentation fault.
0x009ca6cf in is_gimple_variable (t=0x0) at
/home/uros/gcc-svn/trunk/gcc/gimple-expr.h:83
83return (TREE_CODE (t) == VAR_DECL
(gdb) list
78 /* Return true if T is a variable. */
79
80 static inline bool
81 is_gimple_variable (tree t)
82 {
83return (TREE_CODE (t) == VAR_DECL
84|| TREE_CODE (t) == PARM_DECL
85|| TREE_CODE (t) == RESULT_DECL
86|| TREE_CODE (t) == SSA_NAME);
87 }
(gdb) bt
#0 0x009ca6cf in is_gimple_variable (t=0x0) at
/home/uros/gcc-svn/trunk/gcc/gimple-expr.h:83
#1 0x009cd0e6 in is_gimple_val (t=0x0) at
/home/uros/gcc-svn/trunk/gcc/gimple-expr.c:820
#2 0x00a8c59f in force_gimple_operand_1 (expr=0x0,
stmts=0x7fffd348, gimple_test_f=0x9cd0ce is_gimple_val(tree_node*),
var=0x0)
at /home/uros/gcc-svn/trunk/gcc/gimplify-me.c:70
#3 0x00a8c79c in force_gimple_operand (expr=0x0, stmts=0x7fffd348,
simple=true, var=0x0) at /home/uros/gcc-svn/trunk/gcc/gimplify-me.c:113
#4 0x00f9b87f in vectorizable_simd_clone_call (stmt=0x71a3a8e8,
gsi=0x7fffd700, vec_stmt=0x7fffd660, slp_node=0x0)
at /home/uros/gcc-svn/trunk/gcc/tree-vect-stmts.c:2987
#5 0x00fa9018 in vect_transform_stmt (stmt=0x71a3a8e8,
gsi=0x7fffd700, grouped_store=0x7fffd763, slp_node=0x0,
slp_node_instance=0x0)
at /home/uros/gcc-svn/trunk/gcc/tree-vect-stmts.c:7260
#6 0x00fbd7fd in vect_transform_loop (loop_vinfo=0x21bd660) at
/home/uros/gcc-svn/trunk/gcc/tree-vect-loop.c:6131
#7 0x00fd2c02 in vectorize_loops () at
/home/uros/gcc-svn/trunk/gcc/tree-vectorizer.c:491
#8 0x00ecd258 in (anonymous namespace)::pass_vectorize::execute
(this=0x212f9b0, fun=0x71a42a80) at
/home/uros/gcc-svn/trunk/gcc/tree-ssa-loop.c:289
#9 0x00c1914d in execute_one_pass (pass=0x212f9b0) at
/home/uros/gcc-svn/trunk/gcc/passes.c:2311
#10 0x00c19387 in execute_pass_list_1 (pass=0x212f9b0) at
/home/uros/gcc-svn/trunk/gcc/passes.c:2363
#11 0x00c193b8 in execute_pass_list_1 (pass=0x212f230) at
/home/uros/gcc-svn/trunk/gcc/passes.c:2364
#12 0x00c193b8 in execute_pass_list_1 (pass=0x212e0f0) at
/home/uros/gcc-svn/trunk/gcc/passes.c:2364
#13 0x00c193f5 in execute_pass_list (fn=0x71a42a80, pass=0x212e030)
at /home/uros/gcc-svn/trunk/gcc/passes.c:2374
#14 0x0083a838 in cgraph_node::expand (this=0x71a45188) at
/home/uros/gcc-svn/trunk/gcc/cgraphunit.c:1773
#15 0x0083ae69 in expand_all_functions () at
/home/uros/gcc-svn/trunk/gcc/cgraphunit.c:1909
#16 0x0083b973 in symbol_table::compile (this=0x718a8000) at
/home/uros/gcc-svn/trunk/gcc/cgraphunit.c:2263
#17 0x0083bb1e in symbol_table::finalize_compilation_unit
(this=0x718a8000) at /home/uros/gcc-svn/trunk/gcc/cgraphunit.c:2340
#18 0x0068ad19 in c_write_global_declarations () at
/home/uros/gcc-svn/trunk/gcc/c/c-decl.c:10777
#19 0x00d1893a in compile_file () at
/home/uros/gcc-svn/trunk/gcc/toplev.c:584
#20 0x00d1ad4e in do_compile () at
/home/uros/gcc-svn/trunk/gcc/toplev.c:2041
#21 0x00d1af58 in toplev::main (this=0x7fffdd4f, argc=9,
argv=0x7fffde48) at /home/uros/gcc-svn/trunk/gcc/toplev.c:2138
#22 0x016608f2 in main (argc=9, argv=0x7fffde48) at
/home/uros/gcc-svn/trunk/gcc/main.c:38
[Bug rtl-optimization/63917] [5 Regression] r217646 caused many failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63917 Bernd Edlinger bernd.edlinger at hotmail dot de changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #7 from Bernd Edlinger bernd.edlinger at hotmail dot de --- also gmp-4.3.2/mpz/n_pow_ui.c is miscompiled because of this.
[Bug lto/64025] New: Several testsuite execution failures with -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64025 Bug ID: 64025 Summary: Several testsuite execution failures with -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: ubizjak at gmail dot com This problem was unearthed on i686-linux-gnu with -fpic (see [1]): FAIL: gcc.c-torture/execute/builtins/memmove-chk.c execution, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects FAIL: gcc.c-torture/execute/builtins/mempcpy-2.c execution, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects FAIL: gcc.c-torture/execute/builtins/strcpy.c execution, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects FAIL: gcc.c-torture/execute/pr17252.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test FAIL: gcc.dg/torture/pr47365.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test [1] https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg02442.html
[Bug go/64021] Empty struct vs libffi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64021 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- FWIW, gcc and g++ pass empty struct differently on x86.
[Bug c/59708] clang-compatible checked arithmetic builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59708 --- Comment #20 from dave.anglin at bell dot net --- On 22-Nov-14, at 2:31 AM, jakub at gcc dot gnu.org wrote: Is that with r217946 or later? No. My latest build is r217898. -- John David Anglindave.ang...@bell.net
[Bug tree-optimization/64026] New: Many FAIL: ... scan-tree-dump-times vect Vectorizing an unaligned access 0 with -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64026 Bug ID: 64026 Summary: Many FAIL: ... scan-tree-dump-times vect Vectorizing an unaligned access 0 with -fpic Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ubizjak at gmail dot com This is a recent regression. Comparing versions 5.0.0 20141120 (experimental) [trunk revision 217836] [1] with 5.0.0 20141122 (experimental) [trunk revision 217961] [2], there are many vectorizer scan failures (using -fpic) scan-tree-dump-times vect Alignment of access forced using peeling and scan-tree-dump-times vect Vectorizing an unaligned access [1] https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg02192.html [1] https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg02442.html
[Bug tree-optimization/64026] Many FAIL: ... scan-tree-dump-times vect Vectorizing an unaligned access 0 with -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64026 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target||i686-linux-gnu CC||hjl.tools at gmail dot com --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- HJ, is it possible to run a regression hunt between these two revisions?
[Bug target/64027] New: inefficient handling of msp430 byte operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64027 Bug ID: 64027 Summary: inefficient handling of msp430 byte operands Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pab at pabigot dot com
[Bug target/64027] inefficient handling of msp430 byte operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64027
--- Comment #1 from Peter A. Bigot pab at pabigot dot com ---
The following program:
int request();
int release();
unsigned char execute (unsigned char arg);
unsigned char safe_execute (unsigned char arg)
{
int rc;
unsigned char rs = 0;
rc = request();
if (0 == rc) {
do {
rs = execute(arg);
} while(0);
(void)release();
}
return rs;
}
when compiled with msp430-elf-gcc -Os produces:
safe_execute:
0: 0a 15 pushm #1, r10 ;16-bit words
2: 4a 4c mov.b r12,r10 ;
4: 3a f0 ff 00 and #255, r10 ;#0x00ff
8: b0 12 00 00 call#0 ;
a: R_MSP430X_ABS16 request
c: 0c 93 cmp #0, r12 ;r3 As==00
e: 00 20 jnz $+2 ;abs 0x10
e: R_MSP430X_10_PCREL .L3
10: 4c 4a mov.b r10,r12 ;
12: b0 12 00 00 call#0 ;
14: R_MSP430X_ABS16 execute
16: 4a 4c mov.b r12,r10 ;
18: 3a f0 ff 00 and #255, r10 ;#0x00ff
1c: b0 12 00 00 call#0 ;
1e: R_MSP430X_ABS16 release
20: 30 40 00 00 br #0x ;
22: R_MSP430X_ABS16 .L2
0024 .L3:
24: 0a 43 clr r10 ;
0026 .L2:
26: 4c 4a mov.b r10,r12 ;
28: 0a 17 popm#1, r10 ;16-bit words
2a: 30 41 ret
Under mspgcc this produces:
safe_execute:
0: 0b 12 pushr11
2: 4b 4f mov.b r15,r11
4: b0 12 00 00 call#0x
8: 0f 93 tst r15
a: 07 20 jnz $+16;abs 0x1a
c: 4f 4b mov.b r11,r15
e: b0 12 00 00 call#0x
12: 4b 4f mov.b r15,r11
14: b0 12 00 00 call#0x
18: 01 3c jmp $+4 ;abs 0x1c
1a: 4b 43 clr.b r11
1c: 4f 4b mov.b r11,r15
1e: 3b 41 pop r11
20: 30 41 ret
There are two things to be fixed here.
First, in this code:
2: 4a 4c mov.b r12,r10 ;
4: 3a f0 ff 00 and #255, r10 ;#0x00ff
the second instruction is unnecessary, because the mov.b guarantees the
upper half of r10 will be zero. In general the msp430 target does not
appear to take full advantage of the semantics of byte operands in
MSP430. 8 bytes would be saved by eliminating this instruction in two
places.
Second, this sequence generated by msp430-elf:
CALL#release
BR #.L2
.L3:
MOV.W #0, R10
.L2:
should use a jmp instruction instead of a br, saving two bytes.
[Bug tree-optimization/64026] Many FAIL: ... scan-tree-dump-times vect Vectorizing an unaligned access 0 with -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64026 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Uroš Bizjak from comment #1) HJ, is it possible to run a regression hunt between these two revisions? Is this FAIL: gcc.dg/vect/vect-simd-clone-6.c (internal compiler error) FAIL: gcc.dg/vect/vect-simd-clone-6.c (test for excess errors) FAIL: gcc.dg/vect/vect-simd-clone-6.c -flto -ffat-lto-objects (internal compiler error) FAIL: gcc.dg/vect/vect-simd-clone-6.c -flto -ffat-lto-objects (test for excess e rrors) new?
[Bug tree-optimization/60770] disappearing clobbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60770 --- Comment #11 from Marc Glisse glisse at gcc dot gnu.org --- Author: glisse Date: Sat Nov 22 14:28:19 2014 New Revision: 217967 URL: https://gcc.gnu.org/viewcvs?rev=217967root=gccview=rev Log: 2014-11-22 Marc Glisse marc.gli...@inria.fr PR tree-optimization/60770 * tree-sra.c (clobber_subtree): New function. (sra_modify_constructor_assign): Call it. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-sra.c
[Bug tree-optimization/64026] Many FAIL: ... scan-tree-dump-times vect Vectorizing an unaligned access 0 with -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64026 --- Comment #3 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to H.J. Lu from comment #2) Is this FAIL: gcc.dg/vect/vect-simd-clone-6.c (internal compiler error) FAIL: gcc.dg/vect/vect-simd-clone-6.c (test for excess errors) FAIL: gcc.dg/vect/vect-simd-clone-6.c -flto -ffat-lto-objects (internal compiler error) FAIL: gcc.dg/vect/vect-simd-clone-6.c -flto -ffat-lto-objects (test for excess e rrors) new? I don't know, but I have reported this in a separate PR64024.
[Bug tree-optimization/60770] disappearing clobbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60770 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #12 from Marc Glisse glisse at gcc dot gnu.org --- Clobbers are now properly preserved in this case. We don't warn yet, but that's PR 60517.
[Bug c++/60517] warning/error for taking address of member of a temporary object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #18 from Marc Glisse glisse at gcc dot gnu.org ---
The .uninit dump for the original testcase now looks like:
double foo(A) (struct A a)
{
double SR.1;
bb 2:
return SR.1_2(D);
}
which the uninit pass would warn about, except that SR.1 is marked
TREE_NO_WARNING (possibly since the temporary created by the front-end). If
someone wants to look into that...
[Bug target/64008] [SH] sh4-linux configured compiler rejects -m4-nofpu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64008 --- Comment #4 from Segher Boessenkool segher at gcc dot gnu.org --- I configured for sh4-linux, foolishly thinking that sh4-nofpu would work with that as well. Why not build all regular multilibs for every regular config? Maybe keep sh5, sh2a separate, I dunno (I note that sh2a-nofpu is built for sh1 and sh2 configs, but not e.g. sh3 or sh4, or sh2a itself! Truly strange stuff. I suspect it makes sense in that it builds a minimal amount of multilibs and then supports everything it can with that, but that does not make terribly much sense from the viewpoint of a user).
[Bug target/51244] [SH] Inefficient conditional branch and code around T bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #77 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Sat Nov 22 15:06:34 2014 New Revision: 217968 URL: https://gcc.gnu.org/viewcvs?rev=217968root=gccview=rev Log: gcc/ PR target/63986 PR target/51244 * config/sh/sh.c (sh_is_logical_t_store_expr, sh_try_omit_signzero_extend): Use rtx_insn* for insn argument. (sh_split_movrt_negc_to_movt_xor): New function. (sh_find_set_of_reg): Move to ... * config/sh/sh-protos.h (sh_find_set_of_reg): ... here and convert to template function. (set_of_reg): Use rtx_insn* for insn member. (sh_is_logical_t_store_expr, sh_try_omit_signzero_extend): Use rtx_insn* for insn argument. * config/sh/sh.md (movrt_negc, *movrt_negc): Split into movt-xor sequence using new sh_split_movrt_negc_to_movt_xor function. (movrt_xor): Allow also for SH2A. (*movt_movrt): Delete insns and splits. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh-protos.h trunk/gcc/config/sh/sh.c trunk/gcc/config/sh/sh.md
[Bug target/63986] [5 Regression][SH] gcc.target/sh/pr51244-15.c failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63986 --- Comment #10 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Sat Nov 22 15:06:34 2014 New Revision: 217968 URL: https://gcc.gnu.org/viewcvs?rev=217968root=gccview=rev Log: gcc/ PR target/63986 PR target/51244 * config/sh/sh.c (sh_is_logical_t_store_expr, sh_try_omit_signzero_extend): Use rtx_insn* for insn argument. (sh_split_movrt_negc_to_movt_xor): New function. (sh_find_set_of_reg): Move to ... * config/sh/sh-protos.h (sh_find_set_of_reg): ... here and convert to template function. (set_of_reg): Use rtx_insn* for insn member. (sh_is_logical_t_store_expr, sh_try_omit_signzero_extend): Use rtx_insn* for insn argument. * config/sh/sh.md (movrt_negc, *movrt_negc): Split into movt-xor sequence using new sh_split_movrt_negc_to_movt_xor function. (movrt_xor): Allow also for SH2A. (*movt_movrt): Delete insns and splits. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh-protos.h trunk/gcc/config/sh/sh.c trunk/gcc/config/sh/sh.md
[Bug target/63783] [4.9/5 Regression] [SH] Miscompilation of boolean negation on SH4 using -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63783 --- Comment #21 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Michael Karcher from comment #20) Of course. The instructions involving src_reg in make_not_reg_insn dealing with src_reg are completely quoted here: + // On SH we can do only SImode and DImode comparisons. + if (! (GET_MODE (src_reg) == SImode || GET_MODE (src_reg) == DImode)) +return NULL; In this fragment, you accept DImode source operands. So that code may be used to replace a DImode compare. + emit_insn (gen_rtx_SET (VOIDmode, m_ccreg, + gen_rtx_fmt_ee (EQ, SImode, src_reg, const0_rtx))); In this fragment, you are generating the replacement instruction, which is always an SImode compare. Maybe I miss the point, but I fail to undestand how an SImode compare might be acceptable on an DImode operand. Possibly, this even ICEs, I don't know enough about gcc internals to know what happens if src_reg is DImode which is passed to EQ in SImode. The SImode refers to the result of the EQ, not the operands. In sh.md the pattern cmpeqdi_t will be picked up for this.
[Bug preprocessor/63831] [5 Regression] r217292 causes segfaults with -MM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63831
--- Comment #13 from Iain Sandoe iains at gcc dot gnu.org ---
So at stage #3 building libada, we see that s-oscons.{adb,h} are empty.
Looking at the error log :
ln: rts/system.ads: File exists
In file included from /usr/include/sys/time.h:78:0,
from /GCC/gcc-trunk/gcc/ada/gsocket.h:183,
from /GCC/gcc-trunk/gcc/ada/s-oscons-tmplt.c:103:
/usr/include/sys/_structs.h: In function ‘__has_attribute__’:
/usr/include/sys/_structs.h:186:3: error: storage class specified for parameter
‘fd_set’
} fd_set;
^
/usr/include/sys/_structs.h:192:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘{’ token
{
^
In file included from /GCC/gcc-trunk/gcc/ada/gsocket.h:183:0,
from /GCC/gcc-trunk/gcc/ada/s-oscons-tmplt.c:103:
/usr/include/sys/time.h:82:25: error: storage class specified for parameter
‘time_t’
typedef __darwin_time_t time_t;
=== note in the stuff below:
Availability.h includes AvailabilityInternal.h which uses:
#ifdef __has_attribute
#if __has_attribute(availability)
/* use better attributes if possible */
what's not obvious is why that's causing a failure in this context (but passing
elsewhere in the compile.
[of course, could be buggy system headers, but then clang works on this
platform, so I suppose it should have been exercised.]
I don't think I can share darwin headers here - but it's likely that we can
find the key ones on the apple OpenSource server, if you don't have access to
them.
In the meantime I'll see if I can narrow things down.
/GCC/gcc-trunk/gcc/ada/s-oscons-tmplt.c
102
103 #include gsocket.h
104
/GCC/gcc-trunk/gcc/ada/gsocket.h
180 #if defined (__vxworks) ! defined (__RTP__)
181 #include sys/times.h
182 #else
183 #include sys/time.h
184 #endif
/usr/include/sys/time.h
64 #ifndef _SYS_TIME_H_
65 #define _SYS_TIME_H_
66
67 #include sys/cdefs.h
68 #include sys/_types.h
69 #include Availability.h
70
71 /*
72 * [XSI] The fd_set type shall be defined as described in
sys/select.h.
73 * The timespec structure shall be defined as described in time.h
74 */
75 #define __need_fd_set
76 #define __need_struct_timespec
77 #define __need_struct_timeval
78 #include sys/_structs.h
/usr/include/sys/_structs.h
183 __BEGIN_DECLS
184 typedef struct fd_set {
185 __int32_t fds_bits[__DARWIN_howmany(__DARWIN_FD_SETSIZE,
__DARWIN_NFDBITS)];
186 } fd_set;
187 __END_DECLS
[Bug fortran/64022] [F2003][IEEE] ieee_support_flag does not handle kind=10 and kind=16 REAL variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64022 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-22 Assignee|unassigned at gcc dot gnu.org |fxcoudert at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- I was under the impression that if IEEE_SUPPORT_DATATYPE is false for a given kind, then other functions need to be available. Reading the standard again, I was probably wrong.
[Bug target/63783] [4.9/5 Regression] [SH] Miscompilation of boolean negation on SH4 using -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63783 --- Comment #22 from Michael Karcher gcc-bugzilla at mkarcher dot dialup.fu-berlin.de --- OK, in that case I retract my objections and I think the patch is fine. I am sorry for that mistake.
[Bug c++/61528] std::min std::max and RValue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61528 --- Comment #8 from Marc Glisse glisse at gcc dot gnu.org --- If I mark f as static or inline (so the optimizer changes f to take its argument by value), I get with g++-5: w2.c: In function 'int main()': w2.c:11:7: warning: 'anonymous' is used uninitialized in this function [-Wuninitialized] f(i); ^ w2.c:13:7: warning: 'anonymous' is used uninitialized in this function [-Wuninitialized] f(a); ^ (not the best error message, but a good first step) It is quite fragile though, if instead f is inlined (rename main to help convince the optimizer), we end up with: _49 = std::basic_ostreamchar::_M_insertlong unsigned int (cout, _9(D)); and don't warn about it (I didn't check, but I assume _9 is marked TREE_NO_WARNING).
[Bug target/63783] [4.9/5 Regression] [SH] Miscompilation of boolean negation on SH4 using -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63783 --- Comment #23 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Sat Nov 22 15:50:10 2014 New Revision: 217969 URL: https://gcc.gnu.org/viewcvs?rev=217969root=gccview=rev Log: gcc/ PR target/63783 PR target/51244 * config/sh/sh_treg_combine.cc (sh_treg_combine::make_not_reg_insn): Do not emit bitwise not insn. Emit logical not insn sequence instead. Adjust related comments throughout the file. gcc/testsuite/ PR target/63783 PR target/51244 * gcc.target/sh/torture/pr63783-1.c: New. * gcc.target/sh/torture/pr63783-2.c: New. * gcc.target/sh/pr51244-20.c: Adjust. * gcc.target/sh/pr51244-20-sh2a.c: Adjust. Added: trunk/gcc/testsuite/gcc.target/sh/torture/pr63783-1.c trunk/gcc/testsuite/gcc.target/sh/torture/pr63783-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh_treg_combine.cc trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/sh/pr51244-20-sh2a.c trunk/gcc/testsuite/gcc.target/sh/pr51244-20.c
[Bug target/51244] [SH] Inefficient conditional branch and code around T bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #78 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Sat Nov 22 15:50:10 2014 New Revision: 217969 URL: https://gcc.gnu.org/viewcvs?rev=217969root=gccview=rev Log: gcc/ PR target/63783 PR target/51244 * config/sh/sh_treg_combine.cc (sh_treg_combine::make_not_reg_insn): Do not emit bitwise not insn. Emit logical not insn sequence instead. Adjust related comments throughout the file. gcc/testsuite/ PR target/63783 PR target/51244 * gcc.target/sh/torture/pr63783-1.c: New. * gcc.target/sh/torture/pr63783-2.c: New. * gcc.target/sh/pr51244-20.c: Adjust. * gcc.target/sh/pr51244-20-sh2a.c: Adjust. Added: trunk/gcc/testsuite/gcc.target/sh/torture/pr63783-1.c trunk/gcc/testsuite/gcc.target/sh/torture/pr63783-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh_treg_combine.cc trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/sh/pr51244-20-sh2a.c trunk/gcc/testsuite/gcc.target/sh/pr51244-20.c
[Bug preprocessor/63831] [5 Regression] r217292 causes segfaults with -MM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63831 --- Comment #14 from Iain Sandoe iains at gcc dot gnu.org --- this might be a hint: broken c.f. OK - __has_attribute cppdefine commented out $ diff -W200 -y --suppress-common-lines s-oscons-tmplt.i /GCC/ml/gcc-trunk-apple/gcc/ada/rts/s-oscons-tmplt.i # 102 /GCC/ml/gcc-trunk-bust/./gcc/include-fixed/limits.h 3 4 |# 102 /GCC/ml/gcc-trunk-apple/./gcc/include-fixed/limits.h 3 4 /* make sure a default max version is set */__has_attribute__ (availability) |/* make sure a default max version is set */ # 1 /GCC/ml/gcc-trunk-bust/./gcc/include/stdint.h 1 3 4 |# 1 /GCC/ml/gcc-trunk-apple/./gcc/include/stdint.h 1 3 4
[Bug target/51244] [SH] Inefficient conditional branch and code around T bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #79 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Sat Nov 22 16:07:25 2014 New Revision: 217970 URL: https://gcc.gnu.org/viewcvs?rev=217970root=gccview=rev Log: gcc/ Backport from mainline 2014-11-22 Oleg Endo olege...@gcc.gnu.org PR target/63783 PR target/51244 * config/sh/sh_treg_combine.cc (sh_treg_combine::make_not_reg_insn): Do not emit bitwise not insn. Emit logical not insn sequence instead. Adjust related comments throughout the file. gcc/testsuite/ Backport from mainline 2014-11-22 Oleg Endo olege...@gcc.gnu.org PR target/63783 PR target/51244 * gcc.target/sh/torture/pr63783-1.c: New. * gcc.target/sh/torture/pr63783-2.c: New. * gcc.target/sh/pr51244-20.c: Adjust. * gcc.target/sh/pr51244-20-sh2a.c: Adjust. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/sh/torture/pr63783-1.c branches/gcc-4_9-branch/gcc/testsuite/gcc.target/sh/torture/pr63783-2.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/sh/sh_treg_combine.cc branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/gcc.target/sh/pr51244-20-sh2a.c branches/gcc-4_9-branch/gcc/testsuite/gcc.target/sh/pr51244-20.c
[Bug target/63783] [4.9/5 Regression] [SH] Miscompilation of boolean negation on SH4 using -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63783 --- Comment #24 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Sat Nov 22 16:07:25 2014 New Revision: 217970 URL: https://gcc.gnu.org/viewcvs?rev=217970root=gccview=rev Log: gcc/ Backport from mainline 2014-11-22 Oleg Endo olege...@gcc.gnu.org PR target/63783 PR target/51244 * config/sh/sh_treg_combine.cc (sh_treg_combine::make_not_reg_insn): Do not emit bitwise not insn. Emit logical not insn sequence instead. Adjust related comments throughout the file. gcc/testsuite/ Backport from mainline 2014-11-22 Oleg Endo olege...@gcc.gnu.org PR target/63783 PR target/51244 * gcc.target/sh/torture/pr63783-1.c: New. * gcc.target/sh/torture/pr63783-2.c: New. * gcc.target/sh/pr51244-20.c: Adjust. * gcc.target/sh/pr51244-20-sh2a.c: Adjust. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/sh/torture/pr63783-1.c branches/gcc-4_9-branch/gcc/testsuite/gcc.target/sh/torture/pr63783-2.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/sh/sh_treg_combine.cc branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/gcc.target/sh/pr51244-20-sh2a.c branches/gcc-4_9-branch/gcc/testsuite/gcc.target/sh/pr51244-20.c
[Bug target/55023] hppa: wrong code generated with tail call optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55023 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|NEW |UNCONFIRMED CC||rsandifo at gcc dot gnu.org Ever confirmed|1 |0 --- Comment #11 from John David Anglin danglin at gcc dot gnu.org --- The sibcall arguments are relative to the frame/argument pointer. They are the same on the 32-bit target and often are eliminated in favour of the stack pointer. On the 64-bit target, sibcalls are disabled because there is no relation between the argument pointer and stack pointer.
[Bug target/55023] hppa: wrong code generated with tail call optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55023 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|2014-11-07 00:00:00 |2014-11-22 Ever confirmed|0 |1
[Bug preprocessor/63831] [5 Regression] r217292 causes segfaults with -MM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63831 --- Comment #15 from Iain Sandoe iains at gcc dot gnu.org --- Reproducer: $ cat t.h #ifdef __has_attribute #if __has_attribute(availability) /* use better attributes if possible */ #endif #endif gcc-trunk-bust$ ./gcc/xgcc -Bgcc t.h -E t.i gcc-trunk-bust$ more t.i # 1 t.h # 1 built-in # 1 command-line # 1 t.h __has_attribute__ (availability)
[Bug bootstrap/63703] [4.9.2 Regression] cc1: internal compiler error: in init_reg_sets, at reginfo.c:178
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63703 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Target|powerpc-unknown-darwin |powerpc-apple-darwin9 Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-22 CC||fxcoudert at gcc dot gnu.org Host|powerpc-unknown-darwin |powerpc-apple-darwin9 Summary|[4.9 Regression] cc1: |[4.9.2 Regression] cc1: |internal compiler error: in |internal compiler error: in |init_reg_sets, at |init_reg_sets, at |reginfo.c:178 |reginfo.c:178 Ever confirmed|0 |1 Build|powerpc-unknown-darwin |powerpc-apple-darwin9 --- Comment #6 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- (In reply to Lawrence Velázquez from comment #5) Some MacPorts users are now reporting this. Can you provide a backtrace of the error? In the build directory, run the executable gcc/cc1 on a test source file (like the empty main program that libgcc configure tries to compile), under the debugger: lldb -- ./gcc/cc1 test.c The debugger starts, then you type r (without quotes) and enter. It will stop at the point of failure, then you type bt and enter again. Paste here the result of that last command. This will help understand where things are going wrong.
[Bug middle-end/64028] New: [5 Regression] r211599 caused many vectorizer test failures with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64028 Bug ID: 64028 Summary: [5 Regression] r211599 caused many vectorizer test failures with -fPIC Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: hubicka at ucw dot cz On Linux/ia32, r211599 caused many vectorizer test failures with -fPIC, like: FAIL: gcc.dg/vect/vect-7.c scan-tree-dump-times vect Vectorizing an unaligned a ccess 0 FAIL: gcc.dg/vect/vect-7.c -flto -ffat-lto-objects scan-tree-dump-times vect V ectorizing an unaligned access 0
[Bug tree-optimization/64026] Many FAIL: ... scan-tree-dump-times vect Vectorizing an unaligned access 0 with -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64026 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com --- I opened PR 64028.
[Bug tree-optimization/64024] [5 Regression] gcc.dg/vect/vect-simd-clone-6.c ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64024 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-22 CC||hubicka at ucw dot cz Target Milestone|--- |5.0 Summary|gcc.dg/vect/vect-simd-clone |[5 Regression] |-6.c ICEs |gcc.dg/vect/vect-simd-clone ||-6.c ICEs Ever confirmed|0 |1 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- It was caused by r211599.
[Bug tree-optimization/64026] [5 Rehression] Many FAIL: ... scan-tree-dump-times vect Vectorizing an unaligned access 0 with -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64026 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-22 Target Milestone|--- |5.0 Summary|Many FAIL: ... |[5 Rehression] Many FAIL: |scan-tree-dump-times vect |... scan-tree-dump-times |Vectorizing an unaligned |vect Vectorizing an |access 0 with -fpic|unaligned access 0 with ||-fpic Ever confirmed|0 |1
[Bug other/63694] [5.0 Regression] Build error compiling asan.c: strtoull undeclared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63694 --- Comment #11 from John David Anglin danglin at gcc dot gnu.org --- Author: danglin Date: Sat Nov 22 20:53:36 2014 New Revision: 217972 URL: https://gcc.gnu.org/viewcvs?rev=217972root=gccview=rev Log: PR other/63694 * libiberty/configure.ac: Check for strtol, strtoul, strtoll and strtoull declarations. * libiberty/configure: Regenerated. * gcc/configure.ac: Check for strtol, strtoul, strtoll and strtoull declarations. * gcc/configure: Regenerated. * gcc/config.in: Regenerated. Modified: trunk/gcc/config.in trunk/gcc/configure trunk/gcc/configure.ac trunk/libiberty/configure trunk/libiberty/configure.ac
[Bug other/63694] [5.0 Regression] Build error compiling asan.c: strtoull undeclared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63694 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #12 from John David Anglin danglin at gcc dot gnu.org --- Fixed.
[Bug ipa/63598] [5.0 Regression] ICE: in ipa_merge_profiles at ipa-utils.c:396
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63598 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Priority|P1 |P3 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from John David Anglin danglin at gcc dot gnu.org --- Fixed.
[Bug target/63981] [5 Regression] some C++ tests fail with -mabi=ilp32 on aarch64 (with -O2 and above)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63981 Bug 63981 depends on bug 63982, which changed state. Bug 63982 Summary: [5 Regression] Almost all of the devirt testcases fail with -mabi=ilp32 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63982 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/63982] [5 Regression] Almost all of the devirt testcases fail with -mabi=ilp32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63982 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org --- Fixed.
[Bug middle-end/24437] OBJ_TYPE_REF handling in fold_stmt should be moved to fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24437 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #11 from Andrew Pinski pinskia at gcc dot gnu.org --- The folding for OBJ_TYPE_REF is now more complex so closing as won't fix.
[Bug middle-end/26022] [4.2 Regression] ICE with references and virtual functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26022 Bug 26022 depends on bug 24437, which changed state. Bug 24437 Summary: OBJ_TYPE_REF handling in fold_stmt should be moved to fold https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24437 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX
[Bug go/64021] Empty struct vs libffi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64021 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-22 Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- Confirmed.
[Bug middle-end/56552] conditional move can generate unnecessary conversion code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56552 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/55177] missed optimizations with __builtin_bswap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177 --- Comment #14 from Andrew Pinski pinskia at gcc dot gnu.org --- The original testcase in comment #0 is still not optimized at the gimple level due to extra casts. If I use unsigned instead of int, the testcase is optimized at the gimple level.
[Bug c++/64029] New: const int (in)[]{1,2,3,4,5}; results in internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64029
Bug ID: 64029
Summary: const int (in)[]{1,2,3,4,5}; results in internal
compiler error: Segmentation fault
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: narayan_behera at hotmail dot com
Here is a single line program that recreates the bug:
int main() { const int (in)[]{1,2,3,4,5}; return 0; }
-- g++ diagnostics follows
g++ -std=c++11 -Wall -Wextra -c usearr1.cpp
usearr1.cpp: In function ‘int main()’:
usearr1.cpp:4:15: warning: unused variable ‘in’ [-Wunused-variable]
const int (in)[]{1,2,3,4,5};
^
usearr1.cpp:4:30: internal compiler error: Segmentation fault
const int (in)[]{1,2,3,4,5};
^
0x855784a crash_signal
.././gcc-4.9.1/gcc/toplev.c:337
0x83e6aca gimplify_decl_expr
.././gcc-4.9.1/gcc/gimplify.c:1359
0x83e6aca gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
.././gcc-4.9.1/gcc/gimplify.c:7820
0x83e9c17 gimplify_stmt(tree_node**, gimple_statement_base**)
.././gcc-4.9.1/gcc/gimplify.c:5373
0x83e7904 gimplify_cleanup_point_expr
.././gcc-4.9.1/gcc/gimplify.c:5149
0x83e7904 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
.././gcc-4.9.1/gcc/gimplify.c:7990
0x83e9c17 gimplify_stmt(tree_node**, gimple_statement_base**)
.././gcc-4.9.1/gcc/gimplify.c:5373
0x83e81fc gimplify_statement_list
.././gcc-4.9.1/gcc/gimplify.c:1432
0x83e81fc gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
.././gcc-4.9.1/gcc/gimplify.c:8042
0x83e9c17 gimplify_stmt(tree_node**, gimple_statement_base**)
.././gcc-4.9.1/gcc/gimplify.c:5373
0x83ea4a8 gimplify_bind_expr
.././gcc-4.9.1/gcc/gimplify.c:1099
0x83e784e gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
.././gcc-4.9.1/gcc/gimplify.c:7824
0x83e9c17 gimplify_stmt(tree_node**, gimple_statement_base**)
.././gcc-4.9.1/gcc/gimplify.c:5373
0x83e81fc gimplify_statement_list
.././gcc-4.9.1/gcc/gimplify.c:1432
0x83e81fc gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
.././gcc-4.9.1/gcc/gimplify.c:8042
0x83e9c17 gimplify_stmt(tree_node**, gimple_statement_base**)
.././gcc-4.9.1/gcc/gimplify.c:5373
0x83eaaba gimplify_body(tree_node*, bool)
.././gcc-4.9.1/gcc/gimplify.c:8734
0x83eada0 gimplify_function_tree(tree_node*)
.././gcc-4.9.1/gcc/gimplify.c:8887
0x82e3cf8 analyze_function
.././gcc-4.9.1/gcc/cgraphunit.c:649
0x82e4c86 analyze_functions
.././gcc-4.9.1/gcc/cgraphunit.c:1017
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 testsuite/63971] Some of gcc.target/aarch64/test_frame_*.c tests fail now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63971 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- Author: pinskia Date: Sat Nov 22 23:41:26 2014 New Revision: 217975 URL: https://gcc.gnu.org/viewcvs?rev=217975root=gccview=rev Log: 2014-11-22 Andrew Pinski apin...@cavium.com PR target/63971 * gcc.target/aarch64/test_frame_1.c: Expect only two loads of x30 (in the epilogue). * gcc.target/aarch64/test_frame_6.c: Likewise. * gcc.target/aarch64/test_frame_2.c: Expect only one pair load of x30 and x19 (in the epilogue). * gcc.target/aarch64/test_frame_4.c: Likewise. * gcc.target/aarch64/test_frame_7.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/aarch64/test_frame_1.c trunk/gcc/testsuite/gcc.target/aarch64/test_frame_2.c trunk/gcc/testsuite/gcc.target/aarch64/test_frame_4.c trunk/gcc/testsuite/gcc.target/aarch64/test_frame_6.c trunk/gcc/testsuite/gcc.target/aarch64/test_frame_7.c
[Bug testsuite/63971] Some of gcc.target/aarch64/test_frame_*.c tests fail now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63971 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- Fixed.
[Bug c++/64029] [4.9/5 Regression] const int (in)[]{1,2,3,4,5}; results in internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64029
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-11-23
Known to work||4.8.2
Summary|const int |[4.9/5 Regression] const
|(in)[]{1,2,3,4,5}; results |int (in)[]{1,2,3,4,5};
|in internal compiler error: |results in internal
|Segmentation fault |compiler error:
||Segmentation fault
Ever confirmed|0 |1
Known to fail||4.9.2, 5.0
[Bug target/64008] [SH] sh4-linux configured compiler rejects -m4-nofpu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64008 --- Comment #5 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to Segher Boessenkool from comment #4) At least for sh4, it would have a historical reason. In the old time, -m4-nofpu confused many users (including me). From its name, those users expected that it'll give the same ABI for integer only programs with -m4 and fallen into the pit. Then no one complained when the default configuration was -m4 only for sh4-linux gcc and the kernel folks satisfied with --with-multilib-list=m4,m4-nofpu.
[Bug middle-end/63972] shrink_wrap_symbol_ref_1.c fail with -mabi=ilp32 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63972 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization, patch URL||https://gcc.gnu.org/ml/gcc- ||patches/2014-11/msg02920.ht ||ml --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- Patch was submitted: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02920.html
[Bug target/63848] [5 Regression] FAIL: c-c++-common/torture/builtin-arith-overflow-17.c -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63848 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org --- *** Bug 63975 has been marked as a duplicate of this bug. ***
[Bug target/63975] some of the builtin-arith-overflow* fail on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63975 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- Actually it was the same as bug 63848. Closing as dup and confirmed fixed. *** This bug has been marked as a duplicate of bug 63848 ***
[Bug middle-end/49721] convert_memory_address_addr_space may generate invalid new insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49721 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #37 from Andrew Pinski pinskia at gcc dot gnu.org --- Fixed for GCC 5.
[Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55142 Bug 55142 depends on bug 49721, which changed state. Bug 49721 Summary: convert_memory_address_addr_space may generate invalid new insns https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49721 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug bootstrap/63539] libgo does not use the newly built objcopy when doing a combined build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63539 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||build, patch URL||https://gcc.gnu.org/ml/gcc- ||patches/2014-11/msg02921.ht ||ml Component|go |bootstrap --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org --- Patch submitted: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02921.html .
[Bug testsuite/63899] WARNING: Could not compile g++.dg/compat/struct-layout-1 generator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63899 --- Comment #2 from Richard PALO richard at netbsd dot org --- I can't seem to recreate this now, although I'm not that sure it had to do with an issue involving the compiler on illumos where the native libm 'complex.h' was being erroneously fixed up causing precompiler problems with missing closing brace. https://www.illumos.org/issues/5367 updated as well was fixincludes for 4.9.2 with: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52168 and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61649 if I come across this issue again I'll post back.
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #84 from Kazumoto Kojima kkojima at gcc dot gnu.org --- FYI, merge from trunk revision 217978 as sh-lra revision 217980 to apply the lra remat changes on trunk.
[Bug sanitizer/63855] [5 Regression] ICE: SIGSEGV in ipa_comdats with -fsanitize=null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63855 tbsaunde at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||tbsaunde at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #4 from tbsaunde at gcc dot gnu.org --- dup of 61324 *** This bug has been marked as a duplicate of bug 61324 ***
[Bug ipa/61324] [5 Regression] ICE: SIGSEGV at ipa-comdats.c:321 with -fno-use-cxa-atexit -fkeep-inline-functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61324 --- Comment #2 from tbsaunde at gcc dot gnu.org --- *** Bug 63855 has been marked as a duplicate of this bug. ***
[Bug fortran/44672] [F08] ALLOCATE with SOURCE and no array-spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44672 kalle vinzent.boerner at gmx dot de changed: What|Removed |Added CC||vinzent.boerner at gmx dot de --- Comment #6 from kalle vinzent.boerner at gmx dot de --- This bug is still virulent in gfortran 4.9 with source code: Program tmp Implicit None Integer, Dimension(6) :: A Integer, Allocatable, Dimension(:) :: B A=1 Allocate(B,source=A) write(*,*) B End Program tmp compiled with: gfortran-4.9 -o tmp tmp.f90 will result in: Allocate(B,source=A) 1 Error: Array specification required in ALLOCATE statement at (1)
[PATCH] IPA ICF: memory leak fix
Hello.
Following patch removes memory leak that was introduced by very first IPA ICF
patch.
I would like to thank David for hunting the leak.
Patch an bootstrap on x86_86-linux-pc and no regression is introduced.
Thanks,
Martin
From f959905e984a84d0353fb1e32ba83db2b6dfe4d2 Mon Sep 17 00:00:00 2001
From: mliska mli...@suse.cz
Date: Fri, 21 Nov 2014 16:04:06 +0100
Subject: [PATCH] IPA ICF: memory leak fix
gcc/ChangeLog:
2014-11-21 David Malcolm dmalc...@redhat.com
Martin Liska mli...@suse.cz
* ipa-icf.c (sem_function::equals_private): auto_vecint replaces
int* allocated with XNEWVEC.
(sem_function::bb_dict_test): Likewise.
* ipa-icf.h: Likewise.
---
gcc/ipa-icf.c | 15 ++-
gcc/ipa-icf.h | 2 +-
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/gcc/ipa-icf.c b/gcc/ipa-icf.c
index e0633e7..4a0fcfb 100644
--- a/gcc/ipa-icf.c
+++ b/gcc/ipa-icf.c
@@ -410,7 +410,6 @@ sem_function::equals_private (sem_item *item,
basic_block bb1, bb2;
edge e1, e2;
edge_iterator ei1, ei2;
- int *bb_dict = NULL;
bool result = true;
tree arg1, arg2;
@@ -489,8 +488,8 @@ sem_function::equals_private (sem_item *item,
/* Basic block edges check. */
for (unsigned i = 0; i bb_sorted.length (); ++i)
{
- bb_dict = XNEWVEC (int, bb_sorted.length () + 2);
- memset (bb_dict, -1, (bb_sorted.length () + 2) * sizeof (int));
+ auto_vecint bb_dict;
+ bb_dict.safe_grow_cleared (bb_sorted.length () + 2);
bb1 = bb_sorted[i]-bb;
bb2 = m_compared_func-bb_sorted[i]-bb;
@@ -957,9 +956,15 @@ sem_function::icf_handled_component_p (tree t)
corresponds to TARGET. */
bool
-sem_function::bb_dict_test (int* bb_dict, int source, int target)
+sem_function::bb_dict_test (auto_vecint bb_dict, int source, int target)
{
- if (bb_dict[source] == -1)
+ /* bb_dict is cleared with zeros, so that source and target are
+ incremented. bb_dist is used to verify that edges in source and
+ target function correspond. */
+
+ source++;
+ target++;
+ if (bb_dict[source] == 0)
{
bb_dict[source] = target;
return true;
diff --git a/gcc/ipa-icf.h b/gcc/ipa-icf.h
index 046e858..75db93a 100644
--- a/gcc/ipa-icf.h
+++ b/gcc/ipa-icf.h
@@ -275,7 +275,7 @@ private:
/* Basic blocks dictionary BB_DICT returns true if SOURCE index BB
corresponds to TARGET. */
- bool bb_dict_test (int* bb_dict, int source, int target);
+ bool bb_dict_test (auto_vecint bb_dict, int source, int target);
/* Iterates all tree types in T1 and T2 and returns true if all types
are compatible. If COMPARE_POLYMORPHIC is set to true,
--
2.1.2
[PATCH, i386 testsuite]: Add some missing requirements to avx512vl tests
Hello!
2014-11-22 Uros Bizjak ubiz...@gmail.com
* gcc.target/i386/avx512vl-vpermb-2.c: Require avx512vbmi.
* gcc.target/i386/avx512vl-vpermi2b-2.c: Ditto.
* gcc.target/i386/avx512vl-vpermt2b-2.c: Ditto.
* gcc.target/i386/avx512vl-vpmaddhuq-2.c: Require avx512ifma.
* gcc.target/i386/avx512vl-vpmaddluq-2.c: Ditto.
* gcc.target/i386/avx512vl-vpmultishiftqb-2.c: Ditto.
Tested on x86_64-linux-gnu and committed to mainline SVN.
Uros.
Index: gcc.target/i386/avx512vl-vpermb-2.c
===
--- gcc.target/i386/avx512vl-vpermb-2.c (revision 217951)
+++ gcc.target/i386/avx512vl-vpermb-2.c (working copy)
@@ -1,6 +1,7 @@
/* { dg-do run } */
/* { dg-options -O2 -mavx512vbmi -mavx512vl -DAVX512VL } */
/* { dg-require-effective-target avx512vl } */
+/* { dg-require-effective-target avx512vbmi } */
#define AVX512F_LEN 256
#define AVX512F_LEN_HALF 128
Index: gcc.target/i386/avx512vl-vpermi2b-2.c
===
--- gcc.target/i386/avx512vl-vpermi2b-2.c (revision 217951)
+++ gcc.target/i386/avx512vl-vpermi2b-2.c (working copy)
@@ -1,6 +1,7 @@
/* { dg-do run } */
/* { dg-options -O2 -mavx512vbmi -mavx512vl -DAVX512VL } */
/* { dg-require-effective-target avx512vl } */
+/* { dg-require-effective-target avx512vbmi } */
#define AVX512F_LEN 256
#define AVX512F_LEN_HALF 128
Index: gcc.target/i386/avx512vl-vpermt2b-2.c
===
--- gcc.target/i386/avx512vl-vpermt2b-2.c (revision 217951)
+++ gcc.target/i386/avx512vl-vpermt2b-2.c (working copy)
@@ -1,6 +1,7 @@
/* { dg-do run } */
/* { dg-options -O2 -mavx512vbmi -mavx512vl -DAVX512VL } */
/* { dg-require-effective-target avx512vl } */
+/* { dg-require-effective-target avx512vbmi } */
#define AVX512F_LEN 256
#define AVX512F_LEN_HALF 128
Index: gcc.target/i386/avx512vl-vpmaddhuq-2.c
===
--- gcc.target/i386/avx512vl-vpmaddhuq-2.c (revision 217951)
+++ gcc.target/i386/avx512vl-vpmaddhuq-2.c (working copy)
@@ -1,6 +1,7 @@
/* { dg-do run } */
/* { dg-options -O2 -mavx512ifma -mavx512vl -DAVX512VL } */
/* { dg-require-effective-target avx512vl } */
+/* { dg-require-effective-target avx512ifma } */
#define AVX512F_LEN 256
#define AVX512F_LEN_HALF 128
Index: gcc.target/i386/avx512vl-vpmaddluq-2.c
===
--- gcc.target/i386/avx512vl-vpmaddluq-2.c (revision 217951)
+++ gcc.target/i386/avx512vl-vpmaddluq-2.c (working copy)
@@ -1,6 +1,7 @@
/* { dg-do run } */
/* { dg-options -O2 -mavx512ifma -mavx512vl -DAVX512VL } */
/* { dg-require-effective-target avx512vl } */
+/* { dg-require-effective-target avx512ifma } */
#define AVX512F_LEN 256
#define AVX512F_LEN_HALF 128
Index: gcc.target/i386/avx512vl-vpmultishiftqb-2.c
===
--- gcc.target/i386/avx512vl-vpmultishiftqb-2.c (revision 217951)
+++ gcc.target/i386/avx512vl-vpmultishiftqb-2.c (working copy)
@@ -1,6 +1,7 @@
/* { dg-do run } */
/* { dg-options -O2 -mavx512vbmi -mavx512vl -DAVX512VL } */
/* { dg-require-effective-target avx512vl } */
+/* { dg-require-effective-target avx512vbmi } */
#define AVX512F_LEN 256
#define AVX512F_LEN_HALF 128
Re: [PATCH] IPA ICF: memory leak fix
On 2014.11.22 at 09:05 +0100, Martin Liška wrote: Hello. Following patch removes memory leak that was introduced by very first IPA ICF patch. I would like to thank David for hunting the leak. Patch an bootstrap on x86_86-linux-pc and no regression is introduced. I gave the patch a quick spin on gcc112: *** Error in `/home/trippels/gcc_build_dir/./prev-gcc/lto1': free(): invalid next size (fast): 0x01000a5fc160 *** === Backtrace: = /lib64/libc.so.6(+0xa3d9c)[0x3fff7b6b3d9c] /lib64/libc.so.6(+0xaf0b4)[0x3fff7b6bf0b4] /home/trippels/gcc_build_dir/./prev-gcc/lto1(_ZN3vecIi7va_heap6vl_ptrE7releaseEv-0x1d4bc00)[0x1025dd88] /home/trippels/gcc_build_dir/./prev-gcc/lto1(_ZN7ipa_icf12sem_function14equals_privateEPNS_8sem_itemER8hash_mapIP11symtab_nodeS2_22default_hashmap_traitsE-0x9c083c)[0x116586bc] /home/trippels/gcc_build_dir/./prev-gcc/lto1(_ZN7ipa_icf12sem_function6equalsEPNS_8sem_itemER8hash_mapIP11symtab_nodeS2_22default_hashmap_traitsE-0x9c0578)[0x11658998] /home/trippels/gcc_build_dir/./prev-gcc/lto1(_ZN7ipa_icf18sem_item_optimizer7executeEv-0x9b8774)[0x11660a84] /home/trippels/gcc_build_dir/./prev-gcc/lto1(_ZN7ipa_icf12pass_ipa_icf7executeEP8function-0x9b0314)[0x11668efc] /home/trippels/gcc_build_dir/./prev-gcc/lto1(_Z16execute_one_passP8opt_pass-0x1647588)[0x1098a0a8] /home/trippels/gcc_build_dir/./prev-gcc/lto1(_Z21execute_ipa_pass_listP8opt_pass-0x1644c2c)[0x1098ca7c] /home/trippels/gcc_build_dir/./prev-gcc/lto1(_Z8lto_mainv-0x1df20e4)[0x101b494c] /home/trippels/gcc_build_dir/./prev-gcc/lto1[0x10b599b8] /home/trippels/gcc_build_dir/./prev-gcc/lto1(_ZN6toplev4mainEiPPc-0x1e8be70)[0x101507b8] /home/trippels/gcc_build_dir/./prev-gcc/lto1(main-0x1ec8d8c)[0x1015493c] /lib64/libc.so.6(+0x447ac)[0x3fff7b6547ac] /lib64/libc.so.6(__libc_start_main-0x19cbf4)[0x3fff7b6549d4] === Memory map: ... -- Markus
RE: [PATCHv4][MIPS] Implement O32 ABI extensions (GCC)
Andrew Pinski pins...@gmail.com writes: On Wed, Nov 12, 2014 at 2:56 PM, Matthew Fortune matthew.fort...@imgtec.com wrote: Moore, Catherine catherine_mo...@mentor.com writes: The patch looks good. Please fix up these couple of nits prior to committing. OK, thanks for the second read through. One further amendment below, I'll aim to commit later today. Yes, that's better. Committed as r217446 Fingers crossed there will be no fallout from it but if there is I'll deal with it promptly. Most of the testcases fail if you are compiling for soft-float: FAIL: gcc.target/mips/call-clobbered-1.c -O1 scan-assembler-times sdc1 2 FAIL: gcc.target/mips/call-clobbered-1.c -O1 scan-assembler-times ldc1 4 ... FAIL: gcc.target/mips/call-clobbered-2.c -O1 scan-assembler-times lwc1 4 FAIL: gcc.target/mips/call-clobbered-2.c -O1 scan-assembler-times swc1 2 ... FAIL: gcc.target/mips/call-clobbered-3.c -O1 scan-assembler-times lwc1 5 FAIL: gcc.target/mips/call-clobbered-3.c -O1 scan-assembler-times swc1 3 ... FAIL: gcc.target/mips/call-clobbered-4.c -Os scan-assembler-times lwc1 4 FAIL: gcc.target/mips/call-clobbered-4.c -Os scan-assembler-times swc1 2 ... FAIL: gcc.target/mips/call-saved-4.c -O0 scan-assembler \$f20 FAIL: gcc.target/mips/call-saved-4.c -O0 scan-assembler \$f22 FAIL: gcc.target/mips/call-saved-4.c -O0 scan-assembler \$f24 FAIL: gcc.target/mips/call-saved-4.c -O0 scan-assembler \$f26 FAIL: gcc.target/mips/call-saved-4.c -O0 scan-assembler \$f28 FAIL: gcc.target/mips/call-saved-4.c -O0 scan-assembler \$f30 FAIL: gcc.target/mips/call-saved-5.c -O0 scan-assembler \$f20 FAIL: gcc.target/mips/call-saved-5.c -O0 scan-assembler \$f22 FAIL: gcc.target/mips/call-saved-5.c -O0 scan-assembler \$f24 FAIL: gcc.target/mips/call-saved-5.c -O0 scan-assembler \$f26 FAIL: gcc.target/mips/call-saved-5.c -O0 scan-assembler \$f28 FAIL: gcc.target/mips/call-saved-5.c -O0 scan-assembler \$f30 ... FAIL: gcc.target/mips/movdf-1.c -O1 scan-assembler-times ldc1 1 ... FAIL: gcc.target/mips/movdf-2.c -O1 scan-assembler mthc1 FAIL: gcc.target/mips/movdf-2.c -O1 scan-assembler mtc1 ... FAIL: gcc.target/mips/movdf-3.c -O1 scan-assembler-times mtc1 2 ... Thanks Andrew. I'll take a look, getting these tests to be usable in all the hardfloat configs took such a long time that I have clearly not run the single or soft float configs. My intention was to make mips.exp intelligent enough to know that -mfp* imply -mdouble-float and -mhard-float which should resolve this. I would also add -msingle-float support but single-float has been ignored for a number of tests so I'll look at that separately. It will take a couple of days to go through the configs to make sure I don’t break the tests for hard-float configs with the change. Matthew
Re: [PATCH x86] Increase PARAM_MAX_COMPLETELY_PEELED_INSNS when branch is costly
OK. Looks like a good performance vs. codesize tradeoff. Yes, but IMO this should be done in the generic code, unrolling small loops is profitable on most architectures. -- Eric Botcazou
Re: C++ PATCH for c++/63657 (missed unused reference warning)
On 11/22/2014 03:18 AM, Jason Merrill wrote: The earlier fix for 38958 was too broad; we don't want to suppress the unused warning for all references to type with non-trivial destructor, just references bound to a temporary. Thanks! Paolo.
Re: [PATCH x86] Increase PARAM_MAX_COMPLETELY_PEELED_INSNS when branch is costly
On Sat, Nov 22, 2014 at 10:49 AM, Eric Botcazou ebotca...@adacore.com wrote: OK. Looks like a good performance vs. codesize tradeoff. Yes, but IMO this should be done in the generic code, unrolling small loops is profitable on most architectures. Yeah, but after a couple of pings for a generic change, we went the target way. Uros.
Re: [PATCH, combine] Try REG_EQUAL for nonzero_bits
The patch tries to use REG_EQUAL to get more precise info for nonzero_bits,
which helps to remove unnecessary zero_extend.
Here is an example when compiling Coremark, we have rtx like,
(insn 1244 386 388 47 (set (reg:SI 263 [ D.5767 ])
(reg:SI 384 [ D.5767 ])) 786 {*thumb2_movsi_insn}
(expr_list:REG_EQUAL (zero_extend:SI (mem:QI (reg/v/f:SI 271 [ memblock
]) [0 *memblock_13(D)+0 S1 A8]))
(nil)))
from reg:SI 384, we can only know it is a 32-bit value. But from
REG_EQUAL, we can know it is an 8-bit value. Then for the following rtx seq,
(insn 409 407 410 50 (set (reg:SI 308)
(plus:SI (reg:SI 263 [ D.5767 ])
(const_int -48 [0xffd0]))) core_state.c:170 4
{*arm_addsi3}
(nil))
(insn 410 409 411 50 (set (reg:SI 309)
(zero_extend:SI (subreg:QI (reg:SI 308) 0))) core_state.c:170 812
{thumb2_zero_extendqisi2_v6}
(expr_list:REG_DEAD (reg:SI 308)
(nil)))
the zero_extend for r309 can be optimized by combine pass.
This sounds like a good idea.
2014-11-21 Zhenqiang Chen zhenqiang.c...@arm.com
* combine.c (set_nonzero_bits_and_sign_copies): Try REG_EQUAL note.
diff --git a/gcc/combine.c b/gcc/combine.c
index 6a7d16b..68a883b 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -1713,7 +1713,15 @@ set_nonzero_bits_and_sign_copies (rtx x, const_rtx
set, void *data)
/* Don't call nonzero_bits if it cannot change anything. */
if (rsp-nonzero_bits != ~(unsigned HOST_WIDE_INT) 0)
- rsp-nonzero_bits |= nonzero_bits (src, nonzero_bits_mode);
+ {
+ rtx reg_equal = insn ? find_reg_note (insn, REG_EQUAL,
NULL_RTX)
+ : NULL_RTX;
+ if (reg_equal)
+ rsp-nonzero_bits |= nonzero_bits (XEXP (reg_equal, 0),
+nonzero_bits_mode);
+ else
+ rsp-nonzero_bits |= nonzero_bits (src, nonzero_bits_mode);
+ }
num = num_sign_bit_copies (SET_SRC (set), GET_MODE (x));
if (rsp-sign_bit_copies == 0
|| rsp-sign_bit_copies num)
Use find_reg_equal_equiv_note instead. Are you sure that this won't yield
inferior results in very peculiar cases? IOW, why not use both sources?
Note that 'src' is massaged just above if SHORT_IMMEDIATES_SIGN_EXTEND is
defined so we should probably do it for the note datum too, for example by
factoring the code into a function and invoking it.
Why not do the same for num_sign_bit_copies?
--
Eric Botcazou
Re: [PATCH, PR 63551] Use proper type in evaluate_conditions_for_known_args
Hi,
On Fri, Nov 21, 2014 at 09:18:03PM +0100, Richard Biener wrote:
On November 21, 2014 9:07:50 PM CET, Martin Jambor mjam...@suse.cz wrote:
the testcase of PR 63551 passes a union between a signed and an
unsigned integer between two functions as a parameter. The caller
initializes to an unsigned integer with the highest order bit set, the
callee loads the data through the signed field and compares with zero.
evaluate_conditions_for_known_args then wrongly evaluated the
condition in these circumstances, which later on lead to insertion of
builtin_unreachable and miscompilation.
Fixed by fold_converting the known value first. I use the type of the
value in the condition which should do exactly the right thing because
the value is taken from the corresponding gimple_cond statement in
which types must match.
Bootstrapped and tested on x86_64-linux. OK for trunk?
I think you want to use fold_unary (VIEW_CONVERT,...) Here if you consider
the case with
Int and float. And fail if that returns NULL or not a constant.
You are of course right. The following does exactly that.
Bootstrapped and tested on x86_64-linux on trunk and the 4.9 branch.
OK for both?
Thanks,
Martin
2014-11-21 Martin Jambor mjam...@suse.cz
PR ipa/63551
* ipa-inline-analysis.c (evaluate_conditions_for_known_args): Convert
value of the argument to the type of the value in the condition.
testsuite/
* gcc.dg/ipa/pr63551.c: New test.
Index: src/gcc/ipa-inline-analysis.c
===
--- src.orig/gcc/ipa-inline-analysis.c
+++ src/gcc/ipa-inline-analysis.c
@@ -880,7 +880,10 @@ evaluate_conditions_for_known_args (stru
}
if (c-code == IS_NOT_CONSTANT || c-code == CHANGED)
continue;
- res = fold_binary_to_constant (c-code, boolean_type_node, val, c-val);
+ val = fold_unary (VIEW_CONVERT_EXPR, TREE_TYPE (c-val), val);
+ res = val
+ ? fold_binary_to_constant (c-code, boolean_type_node, val, c-val)
+ : NULL;
if (res integer_zerop (res))
continue;
clause |= 1 (i + predicate_first_dynamic_condition);
Index: src/gcc/testsuite/gcc.dg/ipa/pr63551.c
===
--- /dev/null
+++ src/gcc/testsuite/gcc.dg/ipa/pr63551.c
@@ -0,0 +1,33 @@
+/* { dg-do run } */
+/* { dg-options -Os } */
+
+union U
+{
+ unsigned int f0;
+ int f1;
+};
+
+int a, d;
+
+void
+fn1 (union U p)
+{
+ if (p.f1 = 0)
+if (a)
+ d = 0;
+}
+
+void
+fn2 ()
+{
+ d = 0;
+ union U b = { 4294967286 };
+ fn1 (b);
+}
+
+int
+main ()
+{
+ fn2 ();
+ return 0;
+}
Re: [PATCH x86] Increase PARAM_MAX_COMPLETELY_PEELED_INSNS when branch is costly
Yeah, but after a couple of pings for a generic change, we went the target way. That's a bit of a shame, the 400 - 100 change was very likely tested only on x86-64 and nevetheless applied to the generic code, so the fix repairing the damages should also be applied to the generic code. -- Eric Botcazou
Re: [PATCH, PR 63551] Use proper type in evaluate_conditions_for_known_args
On Sat, Nov 22, 2014 at 12:09:46PM +0100, Martin Jambor wrote: 2014-11-21 Martin Jambor mjam...@suse.cz PR ipa/63551 * ipa-inline-analysis.c (evaluate_conditions_for_known_args): Convert value of the argument to the type of the value in the condition. testsuite/ * gcc.dg/ipa/pr63551.c: New test. Index: src/gcc/ipa-inline-analysis.c === --- src.orig/gcc/ipa-inline-analysis.c +++ src/gcc/ipa-inline-analysis.c @@ -880,7 +880,10 @@ evaluate_conditions_for_known_args (stru } if (c-code == IS_NOT_CONSTANT || c-code == CHANGED) continue; - res = fold_binary_to_constant (c-code, boolean_type_node, val, c-val); + val = fold_unary (VIEW_CONVERT_EXPR, TREE_TYPE (c-val), val); VCE should only be used if the sizes of the types are the same. Is that always the case here? Jakub
[Ada] Fix ICE on Ordered_Map and No_Streams restriction
This is an ICE on the use of the pre-defined unit Ordered_Map in conjunction
with the No_Streams restriction. In this case, gigi builds a NULL_EXPR
wrapping a call to the raise Program_Error routine, but it fails to gimplify
it properly in gnat_gimplify_expr.
Tested on x86_64-suse-linux, applied on the mainline.
2014-11-22 Eric Botcazou ebotca...@adacore.com
* gcc-interface/trans.c (gnat_gimplify_expr): Add 'type' variable.
case NULL_EXPR: Deal with unconstrained array types and use 'type'.
case ADDR_EXPR: Use 'type'.
case DECL_EXPR: Likewise.
2014-11-22 Eric Botcazou ebotca...@adacore.com
* gnat.dg/specs/no_streams.ads: New test.
--
Eric BotcazouIndex: gcc-interface/trans.c
===
--- gcc-interface/trans.c (revision 217961)
+++ gcc-interface/trans.c (working copy)
@@ -7657,6 +7657,7 @@ gnat_gimplify_expr (tree *expr_p, gimple
gimple_seq *post_p ATTRIBUTE_UNUSED)
{
tree expr = *expr_p;
+ tree type = TREE_TYPE (expr);
tree op;
if (IS_ADA_STMT (expr))
@@ -7665,16 +7666,17 @@ gnat_gimplify_expr (tree *expr_p, gimple
switch (TREE_CODE (expr))
{
case NULL_EXPR:
- /* If this is for a scalar, just make a VAR_DECL for it. If for
- an aggregate, get a null pointer of the appropriate type and
- dereference it. */
- if (AGGREGATE_TYPE_P (TREE_TYPE (expr)))
- *expr_p = build1 (INDIRECT_REF, TREE_TYPE (expr),
- convert (build_pointer_type (TREE_TYPE (expr)),
- integer_zero_node));
+ /* If this is an aggregate type, build a null pointer of the appropriate
+ type and dereference it. */
+ if (AGGREGATE_TYPE_P (type)
+ || TREE_CODE (type) == UNCONSTRAINED_ARRAY_TYPE)
+ *expr_p = build_unary_op (INDIRECT_REF, NULL_TREE,
+ convert (build_pointer_type (type),
+ integer_zero_node));
+ /* Otherwise, just make a VAR_DECL. */
else
{
- *expr_p = create_tmp_var (TREE_TYPE (expr), NULL);
+ *expr_p = create_tmp_var (type, NULL);
TREE_NO_WARNING (*expr_p) = 1;
}
@@ -7697,7 +7699,7 @@ gnat_gimplify_expr (tree *expr_p, gimple
if (TREE_CODE (op) == CONSTRUCTOR TREE_CONSTANT (op))
{
tree addr = build_fold_addr_expr (tree_output_constant_def (op));
- *expr_p = fold_convert (TREE_TYPE (expr), addr);
+ *expr_p = fold_convert (type, addr);
return GS_ALL_DONE;
}
@@ -7711,7 +7713,7 @@ gnat_gimplify_expr (tree *expr_p, gimple
required if the type is passed by reference. */
if ((TREE_CODE (op) == CONSTRUCTOR || TREE_CODE (op) == CALL_EXPR)
AGGREGATE_TYPE_P (TREE_TYPE (op))
- !AGGREGATE_TYPE_P (TREE_TYPE (expr)))
+ !AGGREGATE_TYPE_P (type))
{
tree mod, new_var = create_tmp_var_raw (TREE_TYPE (op), C);
gimple_add_tmp_var (new_var);
-- { dg-do compile }
pragma Restrictions (No_Streams);
with Ada.Containers.Ordered_Maps;
package No_Streams is
type Arr is new String (1..8);
package My_Ordered_Map is new Ada.Containers.Ordered_Maps
(Key_Type = Natural, Element_Type = Arr);
end No_Streams;
[Ada] Fix ICE on bounded string subtype in packed record type
The compiler aborts on an extension of a tagged record type which contains a
field whose type is a packed record type which in turn contains a field of a
bounded string subtype. Fixed by the attached tweak.
Tested on x86_64-suse-linux, applied on the mainline.
2014-11-22 Eric Botcazou ebotca...@adacore.com
* gcc-interface/trans.c (Call_to_gnu): Strip unchecked conversions on
actuals of In parameters if the destination type is an unconstrained
composite type.
2014-11-22 Eric Botcazou ebotca...@adacore.com
* gnat.dg/specs/pack11.ads: New test.
--
Eric Botcazou-- { dg-do compile }
with Ada.Strings.Bounded;
package Pack11 is
package My_Strings is new Ada.Strings.Bounded.Generic_Bounded_Length (4);
subtype My_Bounded_String is My_Strings.Bounded_String;
type Rec1 is tagged null record;
type Rec2 is record
S : My_Bounded_String;
end record;
pragma Pack (Rec2);
type Rec3 is new Rec1 with record
R : Rec2;
end record;
end Pack11;Index: gcc-interface/trans.c
===
--- gcc-interface/trans.c (revision 217964)
+++ gcc-interface/trans.c (working copy)
@@ -4016,9 +4016,10 @@ Call_to_gnu (Node_Id gnat_node, tree *gn
gnat_formal = Next_Formal_With_Extras (gnat_formal),
gnat_actual = Next_Actual (gnat_actual))
{
+ Entity_Id gnat_formal_type = Etype (gnat_formal);
tree gnu_formal = present_gnu_tree (gnat_formal)
? get_gnu_tree (gnat_formal) : NULL_TREE;
- tree gnu_formal_type = gnat_to_gnu_type (Etype (gnat_formal));
+ tree gnu_formal_type = gnat_to_gnu_type (gnat_formal_type);
const bool is_true_formal_parm
= gnu_formal TREE_CODE (gnu_formal) == PARM_DECL;
const bool is_by_ref_formal_parm
@@ -4031,13 +4032,16 @@ Call_to_gnu (Node_Id gnat_node, tree *gn
address if it's passed by reference or as target of the back copy
done after the call if it uses the copy-in/copy-out mechanism.
We do it in the In case too, except for an unchecked conversion
- because it alone can cause the actual to be misaligned and the
- addressability test is applied to the real object. */
+ to an elementary type or a constrained composite type because it
+ alone can cause the actual to be misaligned and the addressability
+ test is applied to the real object. */
const bool suppress_type_conversion
= ((Nkind (gnat_actual) == N_Unchecked_Type_Conversion
- Ekind (gnat_formal) != E_In_Parameter)
+ (Ekind (gnat_formal) != E_In_Parameter
+ || (Is_Composite_Type (Underlying_Type (gnat_formal_type))
+ !Is_Constrained (Underlying_Type (gnat_formal_type)
|| (Nkind (gnat_actual) == N_Type_Conversion
- Is_Composite_Type (Underlying_Type (Etype (gnat_formal);
+ Is_Composite_Type (Underlying_Type (gnat_formal_type;
Node_Id gnat_name = suppress_type_conversion
? Expression (gnat_actual) : gnat_actual;
tree gnu_name = gnat_to_gnu (gnat_name), gnu_name_type;
@@ -4200,7 +4204,7 @@ Call_to_gnu (Node_Id gnat_node, tree *gn
if (Ekind (gnat_formal) != E_Out_Parameter
Do_Range_Check (gnat_actual))
gnu_actual
- = emit_range_check (gnu_actual, Etype (gnat_formal), gnat_actual);
+ = emit_range_check (gnu_actual, gnat_formal_type, gnat_actual);
/* Unless this is an In parameter, we must remove any justified modular
building from GNU_NAME to get an lvalue. */
[Patch, option handling] optc-gen.awk - support || in EnabledBy()
In fortran/*.opt, I'd like to use:
Fortran Var(warn_tabs) Warning EnabledBy(Wall || Wpedantic)
However, || is not supported by EnabledBy. This patch adds it. I
checked that option.c remains the same after the patch.
I attached the patch twice: Once with -w -U16 to show the modification
(minus re-indenting) and once with re-indenting.
OK for the trunk?
Tobias
gcc/
2014-11-22 Tobias Burnus net-b.de
* optc-gen.awk: Support || in EnabledBy.
diff --git a/gcc/optc-gen.awk b/gcc/optc-gen.awk
index ecb225c..0707db2 100644
--- a/gcc/optc-gen.awk
+++ b/gcc/optc-gen.awk
@@ -25,63 +25,84 @@
# opt-read.awk.
#
# Usage: awk -f opt-functions.awk -f opt-read.awk -f optc-gen.awk \
#[-v header_name=header.h] inputfile options.c
# Dump that array of options into a C file.
END {
# Record first EnabledBy and LangEnabledBy uses.
n_enabledby = 0;
for (i = 0; i n_langs; i++) {
n_enabledby_lang[i] = 0;
}
for (i = 0; i n_opts; i++) {
enabledby_arg = opt_args(EnabledBy, flags[i]);
if (enabledby_arg != ) {
+ if (index(enabledby_arg, ) == 0) {
+ # Enabledby(arg) or Enabledby(arg1 || arg2 || arg3)
+ n_enabledby_names = split(enabledby_arg, enabledby_names, \\|\\| );
+ for (j = 1; j = n_enabledby_names; j++) {
+enabledby_name = enabledby_names[j];
+enabledby_index = opt_numbers[enabledby_name];
+if (enabledby_index == ) {
+print #error Enabledby: enabledby_name
+} else {
+condition = ;
+if (enables[enabledby_name] == ) {
+enabledby[n_enabledby] = enabledby_name;
+n_enabledby++;
+}
+enables[enabledby_name] = enables[enabledby_name] opts[i] ;;
+enablesif[enabledby_name] = enablesif[enabledby_name] condition ;;
+}
+ }
+ } else {
+# Enabledby(arg1 arg2)
n_enabledby_names = split(enabledby_arg, enabledby_names, );
if (n_enabledby_names 2) {
print #error EnabledBy (Wfoo Wbar Wbaz) not currently supported
}
for (j = 1; j = n_enabledby_names; j++) {
enabledby_name = enabledby_names[j];
enabledby_index = opt_numbers[enabledby_name];
if (enabledby_index == ) {
print #error Enabledby: enabledby_name
} else {
condition = ;
if (n_enabledby_names == 2) {
opt_var_name_1 = search_var_name(enabledby_names[1], opt_numbers, opts, flags, n_opts);
opt_var_name_2 = search_var_name(enabledby_names[2], opt_numbers, opts, flags, n_opts);
if (opt_var_name_1 == ) {
print #error enabledby_names[1] does not have a Var() flag
}
if (opt_var_name_2 == ) {
print #error enabledby_names[2] does not have a Var() flag
}
condition = opts-x_ opt_var_name_1 opts-x_ opt_var_name_2;
}
if (enables[enabledby_name] == ) {
enabledby[n_enabledby] = enabledby_name;
n_enabledby++;
}
enables[enabledby_name] = enables[enabledby_name] opts[i] ;;
enablesif[enabledby_name] = enablesif[enabledby_name] condition ;;
}
}
}
+}
enabledby_arg = opt_args(LangEnabledBy, flags[i]);
if (enabledby_arg != ) {
enabledby_langs = nth_arg(0, enabledby_arg);
enabledby_name = nth_arg(1, enabledby_arg);
enabledby_posarg = nth_arg(2, enabledby_arg);
enabledby_negarg = nth_arg(3, enabledby_arg);
lang_enabled_by(enabledby_langs, enabledby_name, enabledby_posarg, enabledby_negarg);
}
}
print /* This file is auto-generated by optc-gen.awk. */
print
n_headers = split(header_name, headers, )
for (i = 1; i = n_headers; i++)
diff --git a/gcc/optc-gen.awk b/gcc/optc-gen.awk
index ecb225c..0707db2 100644
--- a/gcc/optc-gen.awk
+++ b/gcc/optc-gen.awk
@@ -38,36 +38,57 @@ for (i = 0; i n_langs; i++) {
for (i = 0; i n_opts; i++) {
enabledby_arg = opt_args(EnabledBy, flags[i]);
if (enabledby_arg != ) {
-n_enabledby_names = split(enabledby_arg, enabledby_names, );
-if (n_enabledby_names 2) {
-print #error EnabledBy (Wfoo Wbar Wbaz) not currently supported
-}
-for (j = 1; j = n_enabledby_names; j++) {
-enabledby_name = enabledby_names[j];
-enabledby_index = opt_numbers[enabledby_name];
-if (enabledby_index == ) {
-print #error Enabledby:
[PATCH] Work around in-tree gmp configure problems
Hi, since r217627 we use an updated AutoMake missing script. However that revealed a hidden bug in gmp-4.3.2's (up to gmp-6.0.0a) configure script. That is: an in-tree gmp/configure fails now if flex is missing. The gmp configure uses our missing flex script, and previously that emitted an error message and created a dummy lex.yy.c, The new version of that script does no longer create any lex.yy.c. But also if flex is installed, the configure script sets M4=m4-not-needed, before calling flex, which aborts, and leaves an empty lex.yy.c. However chances are that the flex tool fails in a way that there is no lex.yy.c at all, for instance under windows, or with a different version of flex. Now the problem is, if the invocation of flex does not create at least an empty lex.yy.c the whole gmp configuration fails, even though, flex is only needed for one demo example. This patch adds LEX=touch lex.yy.c to the in-tree gmp configure script, which does in fact the same thing as the flex tool when called under these conditions. I have tested gmp-4.3.2 and gmp-6.0.0a in-tree and boot-strapped under x86_64-linux-gnu successfully. OK for trunk? Thanks Bernd. 2014-11-22 Bernd Edlinger bernd.edlin...@hotmail.de * Makefile.def (module=gmp): Work around in-tree gmp configure bug with missing flex. * Makefile.in: Regenerated. patch-gmp.diff Description: Binary data
