Re: proposal to make SIZE_TYPE more flexible
On Thu, 19 Dec 2013, DJ Delorie wrote: Where is the right place to set the array of this __intN mode is enabled flags? I initially set it in tree.c where __int128 is set up, but that happens *after* c_parse_init() needs the flag to set up the RID_* keywords for them. Maybe immediately after the call to init_adjust_machine_modes from do_compile? (It can't actually be inside backend_init, since it needs to happen even if just preprocessing - whether __SIZEOF_INT128__ gets defined depends on __int128 availability, and presumably you'll have such __SIZEOF_INTN__ macros for whichever such types are available - in which case no_backend is true.) -- Joseph S. Myers jos...@codesourcery.com
GCC 4.9.0 Status Report (2013-12-20)
Status == The trunk remains in Stage 3 until the end of January at which point we enter regression-and-doc-fixes-only mode. Quality is improving slowly as we are still getting a lot of new regressions, both due to increased testing and still merging a lot of code (please slow down and consider pushing back features for GCC 4.10). Quality Data Priority # Change from last report --- --- P1 56- 7 P2 127- 9 P3 21+ 10 --- --- Total 204- 6 Previous Report === http://gcc.gnu.org/ml/gcc/2013-11/msg00435.html The next report will be sent when we leave Stage 3.
Re: Remove spam in GCC mailing list
Stop banning this sender. Since we want to clean up spam in GCC mailing list. If you want to restore your Mozilla Bugzilla account (seotaewong40), you want to contact Mozilla Bugzilla. You want to add posting permissions to wine-devel mailing list for seotaewong40 gmail com mail address.
controlling the default C++ dialect
Hey all, this thread started on the libstdc++ list where I asked a couple of questions about patching std::string for C++11 compliance. I have figured how to do that and it yields a library that only works in the C++11 mode. This is not an issue here as we deploy a versioned runtime into a specific path. However, the whole thing is a bit inconvenient to C++ devs as they have to pass -std=c++11 to get anything done. So, my question is - how do I patch the notion of the default C++ dialect that gcc has? I have patched cxx_dialect in gcc/c-family/c-common.c, yet that is not enough. Is there some other thing that overwrites the default? Thanks in advance, Oleg.
GNU Tools Cauldron 2014 - Call for Abstracts and Participation
== GNU Tools Cauldron 2014 http://gcc.gnu.org/wiki/cauldron2014 Call for Abstracts and Participation 18-20 July 2014 Cambridge, England == We are pleased to announce another gathering of GNU tools developers. The basic format of this meeting will be similar to the previous meetings. The purpose of this workshop is to gather all GNU tools developers, discuss current/future work, coordinate efforts, exchange reports on ongoing efforts, discuss development plans for the next 12 months, developer tutorials and any other related discussions. This time we will meet in Cambridge, England from 18/Jul/2014 to 20/Jul/2014. Exact details on location and venue will be available shortly. We are inviting every developer working in the GNU toolchain: GCC, GDB, binutils, runtimes, etc. In addition to discussion topics selected at the conference, we are looking for advance submissions. If you have a topic that you would like to present, please submit an abstract describing what you plan to present. We are accepting three types of submissions: - Prepared presentations: demos, project reports, etc. - BoFs: coordination meetings with other developers. - Tutorials for developers. No user tutorials, please. Note that we will not be doing in-depth reviews of the presentations. Mainly we are looking for applicability and to decide scheduling. There will be time at the conference to add other topics of discussion, similarly to what we did at the previous meetings. To register your abstract, send e-mail to tools-cauldron-ad...@googlegroups.com. Your submission should contain the following information: Title: Authors: Abstract: If you intend to participate, but not necessarily present, please let us know as well. Send a message to tools-cauldron-ad...@googlegroups.com stating your intent to participate.
Re: proposal to make SIZE_TYPE more flexible
This seems mostly plausible, though I don't see anything to ensure that
__intN does not exist at all if the size matches one of the standard C
types, or if the mode fails targetm.scalar_mode_supported_p.
What do we check against for this? Is there some table of standard
types we can read the bitsize of in toplev.c, or should we use the
macros as below? What about float/vector/complex types? I assume we
don't check those since the __intN types are integer types.
Also, should we special-case the int128 case so we always get __int128
if the backend supports TImode?
static bool
standard_type_bitsize (int bitsize)
{
if (bitsize == 128)
return false;
if (bitsize == CHAR_TYPE_SIZE
|| bitsize == SHORT_TYPE_SIZE
|| bitsize == INT_TYPE_SIZE
|| bitsize == LONG_TYPE_SIZE
|| bitsize == LONG_LONG_TYPE_SIZE)
return true;
return false;
}
Re: proposal to make SIZE_TYPE more flexible
On Fri, 20 Dec 2013, DJ Delorie wrote: This seems mostly plausible, though I don't see anything to ensure that __intN does not exist at all if the size matches one of the standard C types, or if the mode fails targetm.scalar_mode_supported_p. What do we check against for this? Is there some table of standard types we can read the bitsize of in toplev.c, or should we use the macros as below? What about float/vector/complex types? I assume we don't check those since the __intN types are integer types. I think using the macros for type sizes is fine, and float / vector / complex types are completely irrelevant to this (so standard_type_bitsize should maybe be standard_integer_type_bitsize). Also, should we special-case the int128 case so we always get __int128 if the backend supports TImode? No, the (TImode, __int128) pair should be handled the same way as all the other __intN types rather than special-cased (of course you should ensure the patch does not end up changing the set of configurations for which __int128 is available). -- Joseph S. Myers jos...@codesourcery.com
Re: proposal to make SIZE_TYPE more flexible
I think using the macros for type sizes is fine, and float / vector / complex types are completely irrelevant to this (so standard_type_bitsize should maybe be standard_integer_type_bitsize). Whew. Am I missing any in the previous code snippet (char, short, int, long, long long) ? Those were the ones documented in tm.texi. No, the (TImode, __int128) pair should be handled the same way as all the other __intN types rather than special-cased (of course you should ensure the patch does not end up changing the set of configurations for which __int128 is available). So if a target happened to set long long to TImode, it wouldn't have __int128 any more? I'm wondering if any ILP64 target would be affected (x86-64 isn't, I don't think any others are).
Re: proposal to make SIZE_TYPE more flexible
On Fri, 20 Dec 2013, DJ Delorie wrote: I think using the macros for type sizes is fine, and float / vector / complex types are completely irrelevant to this (so standard_type_bitsize should maybe be standard_integer_type_bitsize). Whew. Am I missing any in the previous code snippet (char, short, int, long, long long) ? Those were the ones documented in tm.texi. That's the correct list. No, the (TImode, __int128) pair should be handled the same way as all the other __intN types rather than special-cased (of course you should ensure the patch does not end up changing the set of configurations for which __int128 is available). So if a target happened to set long long to TImode, it wouldn't have __int128 any more? I'm wondering if any ILP64 target would be affected (x86-64 isn't, I don't think any others are). No existing target defines LONG_LONG_TYPE_SIZE to more than 64. -- Joseph S. Myers jos...@codesourcery.com
Re: proposal to make SIZE_TYPE more flexible
Ok, so I've got it checking for existing types and checking the target for supported modes. Any other features, or is it time for a second patch? Should I cut out the __int128 parts yet, or do you just want to see the new code still? To-Do: C++ parser, C++ mangling. Still no idea what to do about mangling.
Re: proposal to make SIZE_TYPE more flexible
On Fri, 20 Dec 2013, DJ Delorie wrote: Ok, so I've got it checking for existing types and checking the target for supported modes. Any other features, or is it time for a second patch? Should I cut out the __int128 parts yet, or do you just want to see the new code still? I think a patch is more useful once believe feature-complete, which means replacing the __int128 support with the new mechanism. -- Joseph S. Myers jos...@codesourcery.com
[Bug middle-end/57904] [4.9 Regression] Bogus(?) invokes undefined behavior warning with Fortran's finalization wrapper (gfortran.dg/class_48.f90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #11) With the patch in comment 9, gfortran.dg/class_48.f90 no longer fails and I don't see any regression. The warning for the test in pr58746 comment 2 is also fixed. But you can always create testcases (in C/C++ etc.) that will hit this warning, so while the FE change is possible, we need to do something either about the optimization passes in between IPA and cunrolli (copyprop change Jeff talks about, perhaps only done for that single pass instance and not others, or all?, guess depending on how expensive it is) or scheduling there another instance of some other cleanup pass, or deferring the warning reporting until some cleanup. For the FE change, I guess most important are benchmark results, doesn't it slow down important benchmarks?
[Bug other/59545] Signed integer overflow issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59545 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #5) Thanks Jakub, it looks much better now. What is left are mostly left shifts of negative values: gcc/combine.c:11865:14: runtime error: left shift of negative value -4096 Left shifts of negative value we apparently only warn for C++11 and C++14, not for C++98 (is that because the C++98 wording is fuzzy, don't remember), and for C99 and C11 the even stronger check where for signed left shifts not only all negative values shifted up by any amount are invalid, but also positive values shifted up such that the result is negative or any bits are shifted away. Perhaps we should fix that in preparation for C++11 anyway, just trying to understand why GCC hasn't reported it. gcc/cp/error.c:448:7: runtime error: call to function pp_cxx_type_specifier_seq(cxx_pretty_printer*, tree_node*) through pointer to incorrect function type 'void (*)(c_pretty _printer *, tree_node *)' Haven't seen this error, perhaps we don't instrument it (yet)? Marek? gcc/cselib.c:1121:43: runtime error: signed integer overflow: 4224 + 9223372036854775806 cannot be represented in type 'long' gcc/cselib.c:1121:43: runtime error: signed integer overflow: 4224 + 9223372036854775807 cannot be represented in type 'long' gcc/expr.c:3986:17: runtime error: signed integer overflow: 0 - -9223372036854775808 cannot be represented in type 'long' I wonder why I haven't seen these with GCC (for clang I used some random svn snapshot and the compiler was so terribly slow and occassionally hanging that I gave up on it). What exact configuration you've used?
[Bug other/56811] [4.8/4.9 Regression] libbacktrace causes undefined symbol _Unwind_GetIPInfo on ia64-hpux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56811 --- Comment #9 from __vic d.v.a at ngs dot ru --- Is there any progress and/or solid plan? The last available version of G++ for HP-UX is 4.7.1 (here http://h21007.www2.hp.com/portal/site/dspp/menuitem.863c3e4cbcdc3f3515b49c108973a801?ciid=2a08725cc2f02110725cc2f02110275d6e10RCRD) Without normal C++11 support and important bug fixes!
[Bug bootstrap/59541] [4.9 Regression] Revision 206070 breaks bootstrap on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59541 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr --- Note that on x86_64-apple-darwin10 the test gcc.dg/tree-prof/cold_partition_label.c has started to fail (compilation, -fprofile-use -D_PROFILE_USE) between r204856 (OK) and r205324 (fail). This is fixed at 206120 with the faulty part of 206070 reverted.
[Bug other/59545] Signed integer overflow issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59545 --- Comment #7 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #6) (In reply to Markus Trippelsdorf from comment #5) gcc/cselib.c:1121:43: runtime error: signed integer overflow: 4224 + 9223372036854775806 cannot be represented in type 'long' gcc/cselib.c:1121:43: runtime error: signed integer overflow: 4224 + 9223372036854775807 cannot be represented in type 'long' gcc/expr.c:3986:17: runtime error: signed integer overflow: 0 - -9223372036854775808 cannot be represented in type 'long' I wonder why I haven't seen these with GCC (for clang I used some random svn snapshot and the compiler was so terribly slow and occassionally hanging that I gave up on it). What exact configuration you've used? You're right that clang is terribly slow (e.g. compiling insn-extract takes over 5 minutes on my machine). I'm using the LLVM 3.4 branch (they are close to release). Config: % CC=clang -fsanitize=undefined -fno-sanitize=bounds -w CXX=clang++ -fsanitize=undefined -fno-sanitize=bounds -w ../gcc/configure --disable-bootstrap --disable-werror --disable-multilib --enable-languages=c,c++,fortran
[Bug debug/59510] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212 with -O2 -g --param=large-stack-frame-growth=1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59510 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Very likely duplicate of PR debug/59350.
[Bug c/59520] a possible inconsistency in error diagnostics with -pedantic -std=c99
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59520
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org ---
Let me raise another question that is unrelated, but perhaps you folks, in
particular Joseph, could help add some clarify as I have been baffled by a
couple of examples.
In particular, are the following well-defined according the standard or they
have undefined behavior?
AFAIK neither is well-defined according to base standards, in C (and C++?) the
only valid accesses to union are to the last stored field, but it is accepted
as GNU extension.
Ex 2
int printf (const char *, ...);
struct S0
{
char f0;
int f1;
};
union
{
int f0;
struct S0 f1;
} d;
int
main ()
{
struct S0 g = {0,0};
d.f1 = g;
printf (%d\n, d.f0);
This is of course undefined behavior even with the GNU extensions, padding bits
in g are undefined and you are then accessing them. It is the same thing
as if you did struct S0 g = {0,0}; memcpy (d.f0, g, sizeof (int)); printf
(%d\n, d.f0);
[Bug middle-end/57904] [4.9 Regression] Bogus(?) invokes undefined behavior warning with Fortran's finalization wrapper (gfortran.dg/class_48.f90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904
--- Comment #13 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Jakub Jelinek from comment #12)
But you can always create testcases (in C/C++ etc.) that will hit this
warning, so while the FE change is possible, we need to do something either
about the optimization passes in between IPA and cunrolli (copyprop change
Jeff talks about, perhaps only done for that single pass instance and not
others, or all?, guess depending on how expensive it is) or scheduling there
another instance of some other cleanup pass, or deferring the warning
reporting until some cleanup.
Could someone please provide a C test case that generates this warning?
maybe something like:
int dovar = from;
if (dovar = to)
for (;;)
{
...
if (dovar == to)
break;
dovar += step;
}
For the FE change, I guess most important are benchmark results, doesn't it
slow down important benchmarks?
I think the change in the simple DO-loops really makes sense,
independent of this warning.
It generates the IL code just a bit more like it is done in C:
for (dovar=from; dovar = to; dovar+=step) { ... }
=
dovar = from;
if (dovar = to)
{
loop:
...
dovar+=step;
if (dovar = to)
goto loop;
}
Therefore the IL is easier to analyze and
chances are good that the optimizer performs better.
I can't do these benchmarks however. Who could do that for us?
[Bug preprocessor/59566] [4.8/4.9 regression] g++ preprocessor output includes comments meant for GNU C Library files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59566 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-12-20 Target Milestone|--- |4.8.3 Summary|[4.8 regression] g++|[4.8/4.9 regression] g++ |preprocessor output |preprocessor output |includes comments meant for |includes comments meant for |GNU C Library files |GNU C Library files Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- You are using -C, so what do you expect? Note that since 4.8.x GCC automatically includes stdc-predef.h (which you can see when you remove the -P option). The comment nicely explains in the last sentence: /* This header is separate from features.h so that the compiler can include it implicitly at the start of every compilation. It must not itself include features.h or any other header that includes features.h because the implicit include comes before any feature test macros that may be defined in a source file before it first explicitly includes a system header. GCC knows the name of this header in order to preinclude it. */ Thus, it works as designed. No?
[Bug c++/59565] ICE on valid code in DWARF generation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59565 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-20 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
--- Comment #5 from bin.cheng amker.cheng at gmail dot com ---
For the offending loop:
bb 5:
bb 6:
# b.4_30 = PHI b.4_12(5), 1(12)
# prephitmp_28 = PHI c.1_9(5), c.1_21(12)
# b_lsm.11_13 = PHI b.4_12(5), 1(12)
# ivtmp_46 = PHI ivtmp_45(5), 13(12)
c.1_9 = prephitmp_28 | 1;
b.4_12 = b.4_30 + 1;
ivtmp_45 = ivtmp_46 - 1;
if (ivtmp_45 != 0)
goto bb 5;
else
goto bb 7;
Now SCEV recognizes b_lsm.11_13 as {1,1}_2, and vectorizer considers it can be
vectorized.
The problem comes in function slpeel_update_phi_nodes_for_guard1 for phi node
:# b_lsm.11_13 = PHI b.4_12(5), 1(12). It's special because its loop_arg:
b.4_12 has already been handled in previous node and has non-null current
definition, resulting in assertion failure at line:
gcc_assert (get_current_def (current_new_name) == NULL_TREE);
It seems loop manipulating utility for vectorization can't cope with this kind
PEELED phi node.
We can get more loops vectorized if we can handle this issue in vectorization.
For example, the more complicated example reported can be vectorized
successfully.
But, I think it's a little bit difficult to handle the case because it's
possible to have the PEELED phi node come before the phi node from which it's
peeled from (b.4_30, in this case), just like:
bb 5:
bb 6:
# b_lsm.11_13 = PHI b.4_12(5), 1(12) appear before b.4_30
# b.4_30 = PHI b.4_12(5), 1(12)
# prephitmp_28 = PHI c.1_9(5), c.1_21(12)
# ivtmp_46 = PHI ivtmp_45(5), 13(12)
c.1_9 = prephitmp_28 | 1;
b.4_12 = b.4_30 + 1;
ivtmp_45 = ivtmp_46 - 1;
if (ivtmp_45 != 0)
goto bb 5;
else
goto bb 7;
So here I come up three options:
0) handle peeled phi in slpeel_update_phi_nodes_for_guard*. Maybe two passes
scanning for phi nodes is necessary.
1) reject loops containing peeled phi node in vectorization.
2) add code to rewrite such peeled phi node into normal one.
I am new to vectorization, so any words?
Thanks,
bin
[Bug tree-optimization/59564] False positive array -Warray-bounds check with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59564
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-12-20
Component|c |tree-optimization
Version|unknown |4.9.0
Ever confirmed|0 |1
Known to fail||4.8.2, 4.9.0
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
DOM optimizes this to
if (n = 0)
{
n = 0;
arr[0] = 0;
}
else
arr[n] = 0;
after which value-range propagation warns for the arr[n] on the else
branch because there n = 1 and thus the access is out-of-bounds.
Fixing the obfuscation by doing
if (n 0) n = 0;
instead of
if (n = 0) n = 0;
fixes the warning.
The warning is basically that n is not constrained to be 1 which is
of course kind-of-useless. We don't warn for a plain arr[n] either.
But as you give VRP a half-useful range you make it emit the warning.
Common to these kind of bogus warnings is that we have duplicated the
memory access and warn about the bad half of it. But we have no way
of tracking whether there are now two pieces instead of just one ...
(apart from maybe using source location info and making sure that VRP
computes the same warning for equal source location accesses).
[Bug other/59545] Signed integer overflow issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59545 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-20 Ever confirmed|0 |1 --- Comment #8 from Marek Polacek mpolacek at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #6) gcc/cp/error.c:448:7: runtime error: call to function pp_cxx_type_specifier_seq(cxx_pretty_printer*, tree_node*) through pointer to incorrect function type 'void (*)(c_pretty _printer *, tree_node *)' Haven't seen this error, perhaps we don't instrument it (yet)? Marek? Yeah, we don't instrument this at all.
[Bug bootstrap/59541] [4.9 Regression] Revision 206070 breaks bootstrap on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59541 --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr --- could someone please point me at the original post for this patch? I have the same question. I have finally found the answer: final patch at http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01368.html OKed by Jan Hubicka at http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01379.html
[Bug tree-optimization/59413] [4.9 Regression] wrong code at -Os on x86_64-linux-gnu in both 32-bit and 64-bit modes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59413 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Weird, I still get exactly the same code (except for gcc version string) between pre-r205884 and post-r205884. So, what exact differences are you seeing on the testcase, and with -fdump-tree-all -da starting with what pass? Tried both a non-bootstrap gcc in my bisecting tree and 12 freshly built gcc x86_64 bootstraps from around Dec 5 till now. Because when I'm not able to reproduce it, I'm hesistant to adding the testcase...
[Bug preprocessor/59566] [4.8/4.9 regression] g++ preprocessor output includes comments meant for GNU C Library files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59566 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Yeah, that is not a bug. With -ffreestanding, -nostdinc or -fpreprocessed stdc-predef.h isn't automatically included, but you then have to deal with the other effects of those options.
[Bug c++/59567] New: Incorrect error 'was not declared in this scope'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59567 Bug ID: 59567 Summary: Incorrect error 'was not declared in this scope' Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jascha at jawset dot com Parent member variables not visible in derived type's c'tor if derived is in template. See the example for the exact scenario.
[Bug c++/59567] Incorrect error 'was not declared in this scope'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59567 Jascha Wetzel jascha at jawset dot com changed: What|Removed |Added Attachment #31486|0 |1 is obsolete|| --- Comment #1 from Jascha Wetzel jascha at jawset dot com --- Created attachment 31488 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31488action=edit reproducing code
[Bug c++/59567] Incorrect error 'was not declared in this scope'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59567 Jascha Wetzel jascha at jawset dot com changed: What|Removed |Added Attachment #31488|compile simply with g++|reproducer description|filename | --- Comment #2 from Jascha Wetzel jascha at jawset dot com --- Comment on attachment 31488 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31488 reproducer compile simply with g++ filename
[Bug tree-optimization/59413] [4.9 Regression] wrong code at -Os on x86_64-linux-gnu in both 32-bit and 64-bit modes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59413
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #7 from H.J. Lu hjl.tools at gmail dot com ---
[hjl@gnu-mic-2 gcc-regression]$ cat pr59413.c
typedef unsigned int uint32_t;
uint32_t a;
int b;
int
main ()
{
uint32_t c;
for (a = 7; a = 1; a++)
{
char d = a;
c = d;
b = a == c;
}
if (a != 7)
__builtin_abort ();
return 0;
}
[hjl@gnu-mic-2 gcc-regression]$
/export/project/git/gcc-regression/master/205883/usr/bin/gcc -S pr59413.c -Os
-o bad.s
[hjl@gnu-mic-2 gcc-regression]$
/export/project/git/gcc-regression/master/205887/usr/bin/gcc -S pr59413.c -Os
-o good.s
[hjl@gnu-mic-2 gcc-regression]$ diff -up bad.s good.s
--- bad.s2013-12-20 04:38:57.810620352 -0800
+++ good.s2013-12-20 04:39:12.476337299 -0800
@@ -8,20 +8,9 @@
main:
.LFB0:
.cfi_startproc
-movlb(%rip), %edx
-movl$7, %eax
-.L2:
-incl%eax
-cmpl$3, %eax
-je.L6
-movl$1, %edx
-jmp.L2
-.L6:
-pushq%rax
-.cfi_def_cfa_offset 16
-movl%edx, b(%rip)
-movl$2, a(%rip)
-callabort
+movl$7, a(%rip)
+xorl%eax, %eax
+ret
.cfi_endproc
.LFE0:
.sizemain, .-main
@@ -31,5 +20,5 @@ main:
.LHOTE0:
.commb,4,4
.comma,4,4
-.identGCC: (GNU) 4.9.0 20131211 (experimental) [trunk revision
205883]
+.identGCC: (GNU) 4.9.0 20131211 (experimental) [trunk revision
205887]
.section.note.GNU-stack,,@progbits
[hjl@gnu-mic-2 gcc-regression]$
[Bug tree-optimization/59413] [4.9 Regression] wrong code at -Os on x86_64-linux-gnu in both 32-bit and 64-bit modes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59413 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Ah, my fault then, terribly sorry, I've simplified the testcase a little bit (removed the typedef and used unsigned int instead). Apparently for the reproduction it is important that the c variable uses some typedef to unsigned int rather than that type directly.
[Bug c/59520] a possible inconsistency in error diagnostics with -pedantic -std=c99
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59520 --- Comment #6 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Fri, 20 Dec 2013, su at cs dot ucdavis.edu wrote: In particular, are the following well-defined according the standard or they have undefined behavior? In both cases, you are accessing uninitialized padding bits. ISO C allows for the possibility of type punning through unions (in a footnote added in C99 TC3, not in normative text), but this is still uninitialized data. Whether accesses to uninitialized data are completely undefined behavior, or only produce unspecified values in some cases, is less clear. See N1747 and the discussion under DR 451 in the draft Chicago minutes N1764. (Your examples concern padding bits in objects with static storage duration, rather than uninitialized objects with automatic storage duration, but the issues are much the same.) The general desire is to allow optimizations that may mean an uninitialized object does not act as if it has any consistent value, without making it undefined behavior to call memcpy (for example) on objects that may be only partly initialized.
[Bug tree-optimization/59413] [4.9 Regression] wrong code at -Os on x86_64-linux-gnu in both 32-bit and 64-bit modes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59413 --- Comment #9 from H.J. Lu hjl.tools at gmail dot com --- (In reply to H.J. Lu from comment #5) It is fixed by r205884. We can add the testcase and close it. FWIW, it is also introduced by r204516.
[Bug tree-optimization/59413] [4.9 Regression] wrong code at -Os on x86_64-linux-gnu in both 32-bit and 64-bit modes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59413 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Fri Dec 20 13:07:10 2013 New Revision: 206147 URL: http://gcc.gnu.org/viewcvs?rev=206147root=gccview=rev Log: PR tree-optimization/59413 * gcc.c-torture/execute/pr59413.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr59413.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/59413] [4.9 Regression] wrong code at -Os on x86_64-linux-gnu in both 32-bit and 64-bit modes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59413 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org --- Thanks, testcase committed, so we are all set now.
[Bug testsuite/59494] [4.9 Regression] FAIL: gfortran.dg/vect/fast-math-mgrid-resid.f scan-tree-dump-times optimized vect_[^\\n]*\\+ 13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59494 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- True, I guess adding -mtune=generic doesn't hurt though, it will be still broken with --target_board=unix/-mtune=core2 or similar testing, but at least it will FAIL less often. For core* tuning the difference is e.g. in reassoc (different reassoc widths, fairly recent change), and starting with probably r160636 different IVopts decisions based on different costs. I believe that is the only reason for the different number of vector additions.
[Bug tree-optimization/59544] Vectorizing store with negative step
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59544 --- Comment #1 from meibf at gcc dot gnu.org --- Author: meibf Date: Fri Dec 20 13:46:01 2013 New Revision: 206148 URL: http://gcc.gnu.org/viewcvs?rev=206148root=gccview=rev Log: 2013-12-20 Bingfeng Mei b...@broadcom.com PR tree-optimization/59544 * tree-vect-stmts.c (perm_mask_for_reverse): Move before vectorizable_store. (vectorizable_store): Handle negative step. * gcc.target/i386/pr59544.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr59544.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-stmts.c
[Bug c++/59315] [4.9 regression] g++.dg/warn/Wunused-3.C FAILs with -fno-use-cxa-atexit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59315 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target|*-*-solaris2.* | Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-20 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Host|*-*-solaris2.* | Summary|[4.9 regression]|[4.9 regression] |g++.dg/warn/Wunused-3.C |g++.dg/warn/Wunused-3.C |FAILs on Solaris|FAILs with ||-fno-use-cxa-atexit Ever confirmed|0 |1 Build|*-*-solaris2.* | --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- This regressed everywhere with -O -Wunused -fno-use-cxa-atexit starting with r204265, on Solaris that is just the default, while on various other targets it is not. mark_used is no longer called on the TREE_STATIC global VAR_DECL, eventhough it has a non-trivial destructor. Jason, can you please have a look?
[Bug middle-end/59471] [4.9 Regression] ICE using vector extensions (non-top-level BIT_FIELD_REF, IMAGPART_EXPR or REALPART_EXPR)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59471
--- Comment #10 from Richard Biener rguenth at gcc dot gnu.org ---
Testing
Index: gimplify.c
===
--- gimplify.c (revision 205891)
+++ gimplify.c (working copy)
@@ -7358,12 +7358,22 @@ gimplify_expr (tree *expr_p, gimple_seq
TREE_TYPE (*expr_p));
break;
+ case VIEW_CONVERT_EXPR:
+ if (is_gimple_reg_type (TREE_TYPE (*expr_p))
+ is_gimple_reg_type (TREE_TYPE (TREE_OPERAND (*expr_p, 0
+ {
+ ret = gimplify_expr (TREE_OPERAND (*expr_p, 0), pre_p,
+ post_p, is_gimple_val, fb_rvalue);
+ recalculate_side_effects (*expr_p);
+ break;
+ }
+ /* Fallthru. */
+
case ARRAY_REF:
case ARRAY_RANGE_REF:
case REALPART_EXPR:
case IMAGPART_EXPR:
case COMPONENT_REF:
- case VIEW_CONVERT_EXPR:
ret = gimplify_compound_lval (expr_p, pre_p, post_p,
fallback ? fallback : fb_rvalue);
break;
@@ -7709,10 +7719,17 @@ gimplify_expr (tree *expr_p, gimple_seq
break;
case BIT_FIELD_REF:
- ret = gimplify_expr (TREE_OPERAND (*expr_p, 0), pre_p,
- post_p, is_gimple_lvalue, fb_either);
- recalculate_side_effects (*expr_p);
- break;
+ {
+ if (is_gimple_reg_type (TREE_TYPE (*expr_p))
+is_gimple_reg_type (TREE_TYPE (TREE_OPERAND (*expr_p, 0
+ ret = gimplify_expr (TREE_OPERAND (*expr_p, 0), pre_p,
+ post_p, is_gimple_val, fb_rvalue);
+ else
+ ret = gimplify_expr (TREE_OPERAND (*expr_p, 0), pre_p,
+ post_p, is_gimple_lvalue, fb_either);
+ recalculate_side_effects (*expr_p);
+ break;
+ }
case TARGET_MEM_REF:
{
code-generation for the testcase is awkward though:
foo:
.LFB0:
.cfi_startproc
movaps %xmm0, -24(%rsp)
movq-24(%rsp), %rax
movq%rax, -24(%rsp)
movq-24(%rsp), %xmm0
ret
not sure why RTL cannot recover here, we expand from
foo (uint16x8_t x)
{
vector(2) long unsigned int _2;
long unsigned int _3;
uint8x8_t _4;
bb 2:
_2 = VIEW_CONVERT_EXPRvector(2) long unsigned int(x_5(D));
_3 = BIT_FIELD_REF _2, 64, 0;
_4 = VIEW_CONVERT_EXPRuint8x8_t(_3);
return _4;
with forwprop we could re-write this into
_4 = BIT_FIELD_REF x_5(D), 64, 0;
as BIT_FIELD_REF is allowed to select uint8x8_t from uint16x8_t directly.
[Bug c/59520] a possible inconsistency in error diagnostics with -pedantic -std=c99
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59520 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-20 Ever confirmed|0 |1 Severity|normal |minor --- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Zhendong Su from comment #4) It would be nice to see that this gets fixed eventually [...] it would be great to see this aspect of compilers also gets better to become more friendly to beginners (and professionals too). I think everybody working on GCC would agree with you. But the number of people working on GCC is very limited and they have a finite amount of time to dedicate to it. So either you convince new people to start working on GCC or yourself start contributing. Fixing this bug for example may be easy or may require some effort, but given that it surely affects very few people using non-standard code and there are also easy work-arounds, people already working on GCC will likely spent their time on something else. If you consider this issue important, just set-up a build environment, launch gdb and start hacking. You can grep for the error message, set a breakpoint at the error line and analyze why it is emitted and how you can modify the code to follow the warning route. If you get it fixed before the end of January, it will be in GCC 4.9. Be the change you wish to see!
[Bug testsuite/59494] [4.9 Regression] FAIL: gfortran.dg/vect/fast-math-mgrid-resid.f scan-tree-dump-times optimized vect_[^\\n]*\\+ 13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59494 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- I believe that is the only reason for the different number of vector additions. I don't think the number of packed double operations is changed, only the number of occurrences of the scanned regular expression: [Book15] f90/bug% gfc -S -mtune=generic -O3 -ffast-math -msse2 -fpredictive-commoning -ftree-vectorize -fdump-tree-optimized /opt/gcc/work/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f [Book15] f90/bug% egrep vect_[^\n]*\+ fast-math-mgrid-resid.f.169t.optimized | wc -l 13 [Book15] f90/bug% grep addpd fast-math-mgrid-resid.s | wc -l 23 [Book15] f90/bug% grep subpd fast-math-mgrid-resid.s | wc -l 4 [Book15] f90/bug% grep mulpd fast-math-mgrid-resid.s | wc -l 4 [Book15] f90/bug% gfc -S -O3 -ffast-math -msse2 -fpredictive-commoning -ftree-vectorize -fdump-tree-optimized /opt/gcc/work/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f [Book15] f90/bug% egrep vect_[^\n]*\+ fast-math-mgrid-resid.f.169t.optimized | wc -l 10 [Book15] f90/bug% grep addpd fast-math-mgrid-resid.s | wc -l 23 [Book15] f90/bug% grep subpd fast-math-mgrid-resid.s | wc -l 4 [Book15] f90/bug% grep mulpd fast-math-mgrid-resid.s | wc -l 4 Well, I don't think configuring with arbitrary --with-cpu/tune is a supported configuration for zero testsuite FAILs ...? The tested configurations x86_64-apple-darwin* (IIRC defaulting to --with-arch=core2 --with-cpu=core2) and x86_64-*-* configured with --with-arch=corei7 --with-cpu=corei7. I also hope forbidden configurations are rejected (as done for at least some compiling options).
[Bug preprocessor/59566] [4.8/4.9 regression] g++ preprocessor output includes comments meant for GNU C Library files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59566 --- Comment #3 from gdlxn at us dot ibm.com --- Richard and Jakub - Thanks for the quick response and explanation. I was able to use the -nostdinc option to suppress the automatic inclusion of stdc-predef.h, which eliminates the unwanted comments.
[Bug c++/59567] Incorrect error 'was not declared in this scope'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59567 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- Gcc's behavior is correct as a is not dependent so it is not looked up via a dependent base class.
[Bug c++/59255] [4.8/4.9 Regression] Segmentation fault with std::function and -fprofile-use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59255 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Fri Dec 20 16:32:21 2013 New Revision: 206152 URL: http://gcc.gnu.org/viewcvs?rev=206152root=gccview=rev Log: PR c++/59255 * g++.dg/tree-prof/pr59255.C: New test. Added: trunk/gcc/testsuite/g++.dg/tree-prof/pr59255.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/59255] [4.8/4.9 Regression] Segmentation fault with std::function and -fprofile-use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59255 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Fri Dec 20 16:34:21 2013 New Revision: 206153 URL: http://gcc.gnu.org/viewcvs?rev=206153root=gccview=rev Log: PR c++/59255 Backported from mainline 2013-08-19 Dehao Chen de...@google.com * value-prof.c (gimple_ic): Fix the bug of adding EH edge. * g++.dg/tree-prof/pr59255.C: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/tree-prof/pr59255.C Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/value-prof.c
[Bug c++/59255] [4.8/4.9 Regression] Segmentation fault with std::function and -fprofile-use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59255 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug debug/54114] VTA compile-time performance could be improved
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54114 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||law at redhat dot com Summary|[4.8/4.9 Regression]|VTA compile-time |variable-tracking |performance could be |performance regression from |improved |4.8-20120610 to | |4.8-20120701| --- Comment #10 from Jeffrey A. Law law at redhat dot com --- Removing regression marker based on c#7 and c#8. Sounds like there's still work that can be done here, but that the regression aspect is significantly improved.
[Bug fortran/59561] [4.9 Regression] warning: iteration 4 invokes undefined behavior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59561 --- Comment #2 from janus at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #1) Isn't that effectively a duplicate of the P1 regression PR57904? Might well be, I'm not sure. However, the patch posted in PR 57904 comment 9 does not seem to fix the problem here ...
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 --- Comment #40 from dave.anglin at bell dot net --- On 12/19/2013 5:53 PM, John David Anglin wrote: Rechecking status on the arm box. Problem is still there: ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:58:30: fatal error: linux/perf_event.h: No such file or directory #include linux/perf_event.h
[Bug middle-end/57904] [4.9 Regression] Bogus(?) invokes undefined behavior warning with Fortran's finalization wrapper (gfortran.dg/class_48.f90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904 --- Comment #14 from Jeffrey A. Law law at redhat dot com --- So a quick prototype which reuses the infrastructure from the phi-only-propagator cleans things up quite nicely. Given this block after substitute_and_fold does its thing: bb 2: ubound.0_3 = 0; size.1_4 = ubound.0_3 + 1; size.1_5 = MAX_EXPR size.1_4, 0; _6 = size.1_5 * 4; _7 = (character(kind=4)) _6; _8 = MAX_EXPR _7, 1; sizes_9 = __builtin_malloc (_8); size.3_10 = MAX_EXPR ubound.0_3, 0; _11 = size.3_10 * 4; _12 = (character(kind=4)) _11; _13 = MAX_EXPR _12, 1; strides_14 = __builtin_malloc (_13); MEM[(integer(kind=4)[0:D.1917] *)sizes_9][0] = 1; if (ubound.0_3 0) goto bb 3; else goto bb 6; I (manually) seed the phi-only propagator's 2nd step with _3 as being a newly exposed destination of a copy/constant initialization and let that trivial propagator do its thing... Resulting in: bb 2: sizes_9 = __builtin_malloc (4); strides_14 = __builtin_malloc (1); MEM[(integer(kind=4)[0:D.1917] *)sizes_9][0] = 1; goto bb 6; Which is exactly what we want. Also note that we collapse the conditional at the end of the block. That in turn makes the problematic loop unreachable and it goes away as one would expect. The problem I see is I'd prefer not to expose this in substitute_and_fold directly. That routine is used by multiple propagators. I'm thinking that instead we can have a callback to the pass utilizing substitute_and_fold that gets called when something has folded.
[Bug rtl-optimization/56069] [4.7/4.8/4.9 Regression] RA pessimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56069
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #5 from Jeffrey A. Law law at redhat dot com ---
Maybe I'm missing something here. We have this immediately prior to IRA:
(insn 2 4 3 2 (set (reg/v:DI 86 [ mem ])
(reg:DI 5 di [ mem ])) j.c:2 89 {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 5 di [ mem ])
(nil)))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(insn 6 3 7 2 (parallel [
(set (reg:DI 88 [ D.1760 ])
(lshiftrt:DI (reg/v:DI 86 [ mem ])
(const_int 3 [0x3])))
(clobber (reg:CC 17 flags))
]) j.c:3 562 {*lshrdi3_1}
(expr_list:REG_DEAD (reg/v:DI 86 [ mem ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 7 6 8 2 (set (reg:DI 89)
(const_int 17592186044416 [0x1000])) j.c:3 89 {*movdi_internal}
(nil))
(insn 8 7 13 2 (parallel [
(set (reg:DI 87 [ D.1760 ])
(ior:DI (reg:DI 88 [ D.1760 ])
(reg:DI 89)))
(clobber (reg:CC 17 flags))
]) j.c:3 421 {*iordi_1}
(expr_list:REG_DEAD (reg:DI 89)
(expr_list:REG_DEAD (reg:DI 88 [ D.1760 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (ior:DI (reg:DI 88 [ D.1760 ])
(const_int 17592186044416 [0x1000]))
(nil))
(insn 13 8 16 2 (set (reg/i:DI 0 ax)
(reg:DI 87 [ D.1760 ])) j.c:4 89 {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 87 [ D.1760 ])
(nil)))
(insn 16 13 0 2 (use (reg/i:DI 0 ax)) j.c:4 -1
(nil))
ISTM that we want (reg 86) to prefer di and (reg 87) to prefer ax by way of the
hard register copies. (reg 88) should then prefer di by way of insn 6.
(reg 89) really doesn't need a preference and can go anywhere that doesn't
conflict.
So if we look at the IRA dump we have:
Pass 1 for finding pseudo/allocno costs
r89: preferred GENERAL_REGS, alternative NO_REGS, allocno GENERAL_REGS
r88: preferred GENERAL_REGS, alternative NO_REGS, allocno GENERAL_REGS
r87: preferred AREG, alternative GENERAL_REGS, allocno GENERAL_REGS
r86: preferred DIREG, alternative GENERAL_REGS, allocno GENERAL_REGS
Which I guess is OK. A bit surprised to not see r88 preferring DIreg at this
point, but I guess copies implied by the 2 operand nature are handled later.
ISTM that the copy implied by insn 6 should result in 88 somehow preferring
DIreg. Then, ideally we'd see that while 89 can go anywhere it's best to match
it with 87.
Vlad, what am I missing here?
[Bug middle-end/57904] [4.9 Regression] Bogus(?) invokes undefined behavior warning with Fortran's finalization wrapper (gfortran.dg/class_48.f90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904 --- Comment #15 from Dominique d'Humieres dominiq at lps dot ens.fr --- *** Bug 58746 has been marked as a duplicate of this bug. ***
[Bug middle-end/58746] [4.9 Regression] Incorrect warning with -Waggressive-loop-optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58746 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- Fixed by the patch in pr57904 comment 9. Marked as duplicate. *** This bug has been marked as a duplicate of bug 57904 ***
[Bug c++/59568] New: complex type operator does not set eofbit for input streams.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59568
Bug ID: 59568
Summary: complex type operator does not set eofbit for input
streams.
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Physeterm at yahoo dot com
Created attachment 31489
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31489action=edit
g++ -v
(Actually, it is set, it's just cleared before the return to caller)
The problem as I understand it is that the call to __is.putback(__ch)
resets the eofbit to 0, (in C++11) after a valid eof has been detected.
The next extraction operation fails on attempting to get a char type
but the eofbit is not set to 1.
This precludes the ability to do error checking on input files.
A simple solution I think would be to test for the eofbit before
attempting the putback. ie:
else
{
if (! __is.eof()) {
__is.putback(__ch);
__is __re_x;
__x = __re_x;
}
}
return __is;
}
in file /usr/include/c++/4.8.1/complex (This only fixes int types)
[Bug middle-end/57904] [4.9 Regression] Bogus(?) invokes undefined behavior warning with Fortran's finalization wrapper (gfortran.dg/class_48.f90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904 --- Comment #16 from Dominique d'Humieres dominiq at lps dot ens.fr --- For the FE change, I guess most important are benchmark results, doesn't it slow down important benchmarks? AFAICT the answer is not at least for the gfortran test suite and the polyhedron ones (pb05, pb11, and my own variants). May be Joost can do more testing for CP2K.
[Bug c++/59568] complex type operator does not set eofbit for input streams.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59568 --- Comment #1 from Physeterm at yahoo dot com --- Created attachment 31490 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31490action=edit test program
[Bug c++/59568] complex type operator does not set eofbit for input streams.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59568 --- Comment #2 from Physeterm at yahoo dot com --- Created attachment 31491 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31491action=edit input test file
[Bug c++/59568] complex type operator does not set eofbit for input streams.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59568 --- Comment #3 from Physeterm at yahoo dot com --- Created attachment 31492 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31492action=edit output
[Bug c++/59568] complex type operator does not set eofbit for input streams.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59568 --- Comment #4 from Physeterm at yahoo dot com --- Created attachment 31493 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31493action=edit make command
[Bug fortran/59561] [4.9 Regression] warning: iteration 4 invokes undefined behavior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59561 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-20 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- (In reply to Tobias Burnus from comment #1) Isn't that effectively a duplicate of the P1 regression PR57904? Might well be, I'm not sure. However, the patch posted in PR 57904 comment 9 does not seem to fix the problem here ... I don't think it is a duplicate and I think the warning is correct (on x86_64-apple-darwin13 I get it with/without SAVE and with/without the patch in PR 57904 comment 9). Too bad that the warning is emitted twice and the iteration count starts at 0 and not at one as in first (IMHO #iterations=end-start+1, i.e., 5).
[Bug middle-end/59561] [4.9 Regression] warning: iteration 4 invokes undefined behavior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59561 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||law at redhat dot com Component|fortran |middle-end --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- I think it is a middle-end issue.
[Bug middle-end/57904] [4.9 Regression] Bogus(?) invokes undefined behavior warning with Fortran's finalization wrapper (gfortran.dg/class_48.f90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904 --- Comment #17 from Jeffrey A. Law law at redhat dot com --- Dominique, thanks for verifying that 58746 is a duplicate. I was wondering about that. Richi, we've known for a long time (since the early 90s) that running CSE soon after loop unrolling is profitable. S, why not run conditionally run DOM after unrolling? That wouldn't create a compile-time hit for a typical -O2 compilation.
[Bug middle-end/57904] [4.9 Regression] Bogus(?) invokes undefined behavior warning with Fortran's finalization wrapper (gfortran.dg/class_48.f90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904 --- Comment #18 from Jeffrey A. Law law at redhat dot com --- Whoops, message for Richi was meant for a different BZ.
[Bug bootstrap/59541] [4.9 Regression] Revision 206070 breaks bootstrap on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59541 --- Comment #9 from Martin Liška marxin.liska at gmail dot com --- Hello, thank you for the hotfix that repaired switch/case missing return value. Actually I was told by Jan to reproduce the functionality from varasm.c that I was able to bootstrap and test. The idea of reordering pass is to order all functions that are seen during instrumentation run and are executed during start-up of an application. So that, we do not build separate sections for .text, .text.hot and .text.startup. On the other hand: any execute function should not live in .text.unlikely and .text.startup. If so, it means that we miss profile info and these functions can be identified during debugging process. I am not familiar with darwin format, Jan do you know what could cause problem?
[Bug rtl-optimization/56069] [4.7/4.8/4.9 Regression] RA pessimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56069 --- Comment #6 from Vladimir Makarov vmakarov at gcc dot gnu.org --- (In reply to Jeffrey A. Law from comment #5) Maybe I'm missing something here. We have this immediately prior to IRA: ISTM that we want (reg 86) to prefer di and (reg 87) to prefer ax by way of the hard register copies. (reg 88) should then prefer di by way of insn 6. (reg 89) really doesn't need a preference and can go anywhere that doesn't conflict. So if we look at the IRA dump we have: Pass 1 for finding pseudo/allocno costs r89: preferred GENERAL_REGS, alternative NO_REGS, allocno GENERAL_REGS r88: preferred GENERAL_REGS, alternative NO_REGS, allocno GENERAL_REGS r87: preferred AREG, alternative GENERAL_REGS, allocno GENERAL_REGS r86: preferred DIREG, alternative GENERAL_REGS, allocno GENERAL_REGS Which I guess is OK. A bit surprised to not see r88 preferring DIreg at this point, but I guess copies implied by the 2 operand nature are handled later. ISTM that the copy implied by insn 6 should result in 88 somehow preferring DIreg. Then, ideally we'd see that while 89 can go anywhere it's best to match it with 87. Vlad, what am I missing here? Preferred/alternative class is misleading here. It is not used anywhere in IRA/LRA for allocation decision (but may be it is used by reload -- i don't remember). It is only used as a temporary result for allocno class calculation. Hard reg preferences and copies are further in the dump. They looks as following cp0:a2(r88)-a3(r86)@1000:constraint cp1:a0(r87)-a1(r89)@1000:constraint cp2:a0(r87)-a2(r88)@1000:constraint pref0:a0(r87)-hr0@1500 pref1:a3(r86)-hr5@1500 This problem is well known me. Jakub filled analogous PR. I am working on it. The reason of the problem are copies created for commutative ops insns. Two copies give different signals for hard reg preferences through the propagation mechanism. It is easy to make a test for this problem because the test should be small and involve arguments and result on small number of insns. Therefore we have a few such PRs. In bigger function, the probability of the problem occurrence is quite small.
[Bug fortran/37336] [F03] Finish derived-type finalization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 --- Comment #27 from janus at gcc dot gnu.org --- From http://gcc.gnu.org/ml/fortran/2013-12/msg00104.html ... Currently missing are: a) Finalization of the LHS during intrinsic assignment: b) Finalization of functions results after their use c) Finalization of structure/array constructors after their use.
[Bug fortran/45424] [F08] Add IS_CONTIGUOUS intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45424 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-20 Summary|[F2008] Add IS_CONTIGUOUS |[F08] Add IS_CONTIGUOUS |intrinsic |intrinsic Ever confirmed|0 |1
[Bug bootstrap/59541] [4.9 Regression] Revision 206070 breaks bootstrap on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59541 --- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr --- Hello, thank you for the hotfix that repaired switch/case missing return value. Nothing has been committed yet to fix darwin bootstrap!-(
[Bug middle-end/59569] New: [4.9 Regression] r206148 causes internal compiler error: in vect_create_destination_var, at tree-vect-data-refs.c:4294
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59569 Bug ID: 59569 Summary: [4.9 Regression] r206148 causes internal compiler error: in vect_create_destination_var, at tree-vect-data-refs.c:4294 Product: gcc Version: 4.9.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: bmei at broadcom dot com When compiling 253.perlbmk from SPEC CPU 2K on Linux/x86-64, I got [hjl@gnu-mic-2 0001]$ /export/project/git/gcc-regression/master/206150/usr/bin/gcc -c -o pp.o -DSPEC_CPU2000_LP64 -DSPEC_CPU2000_LINUX_I386 -DSPEC_CPU2000_NEED_BOOL -DSPEC_CPU2000_GLIBC22-O3 -funroll-loops -ffast-math pp.c In file included from perl.h:1090:0, from pp.c:16: handy.h:71:0: warning: bool redefined [enabled by default] # define bool char ^ In file included from config.h:1:0, from perl.h:137, from pp.c:16: spec_config.h:160:0: note: this is the location of the previous definition #define bool int ^ In file included from perl.h:2121:0, from pp.c:16: pp.c: In function \u2018Perl_pp_splice\u2019: embed.h:759:20: internal compiler error: in vect_create_destination_var, at tree-vect-data-refs.c:4294 #define pp_splice Perl_pp_splice ^ pp.h:20:20: note: in definition of macro \u2018PP\u2019 #define PP(s) OP * s(ARGSproto) ^ pp.c:2687:4: note: in expansion of macro \u2018pp_splice\u2019 PP(pp_splice) ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. [hjl@gnu-mic-2 0001]$
[Bug middle-end/59569] [4.9 Regression] r206148 causes internal compiler error: in vect_create_destination_var, at tree-vect-data-refs.c:4294
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59569 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com --- Created attachment 31494 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31494action=edit A testcase [hjl@gnu-mic-2 0001]$ /export/project/git/gcc-regression/master/206150/usr/bin/gcc -S -O3 -funroll-loops -ffast-math pr59569.c pr59569.c: In function ‘Perl_pp_splice’: pr59569.c:7304:6: internal compiler error: in vect_create_destination_var, at tree-vect-data-refs.c:4294 OP * Perl_pp_splice(void) ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. [hjl@gnu-mic-2 0001]$
[Bug middle-end/59569] [4.9 Regression] r206148 causes internal compiler error: in vect_create_destination_var, at tree-vect-data-refs.c:4294
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59569 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-21 Target Milestone|--- |4.9.0 Ever confirmed|0 |1
[Bug c++/59570] New: Warning for semicolon trailing closing curly brackets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59570 Bug ID: 59570 Summary: Warning for semicolon trailing closing curly brackets Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eugene.zelenko at gmail dot com Hi! I think will be great to have warning when useless semicolon trails closing curly bracket (closing function definition or code block). Same should be done for C. Eugene.
[Bug middle-end/59569] [4.9 Regression] r206148 causes internal compiler error: in vect_create_destination_var, at tree-vect-data-refs.c:4294
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59569 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- 254.gap in SPEC CPU 2K is also failed.
[Bug c++/59571] New: [C++11] ICE when casting inside static member constexpr brace initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59571
Bug ID: 59571
Summary: [C++11] ICE when casting inside static member
constexpr brace initializer
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bruck.michael at googlemail dot com
$ cat ice.cpp
template class
struct foo
{
static constexpr int bar{(int)-1};
};
$ g++ -std=c++11 -c ice.cpp
ice.cpp:4:37: internal compiler error: unexpected expression ‘(int)((-1))’ of
kind cast_expr
static constexpr int bar{(int)-1};
^
ice.cpp:4:37: internal compiler error: Aborted
g++: internal compiler error: Aborted (program cc1plus)
...
$ g++ --version
g++ (GCC) 4.8.2
...
Re: [RFA][PATCH][middle-end/53623] Improve extension elimination
Hello!
index 000..5375b61
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr53623.c
@@ -0,0 +1,25 @@
+/* { dg-do compile { target { x86_64-*-* } } } */
+/* { dg-options -O2 -fdump-rtl-ree } */
Please use:
/* { dg-do compile { target { ! ia32 } } } */
Uros.
Re: [RFA][PATCH][middle-end/53623] Improve extension elimination
On Thu, Dec 19, 2013 at 09:57:36PM -0700, Jeff Law wrote:
* ree.c (combine_set_extension): Handle case where source
and destination registers in an extension insn are different.
(combine_reaching_defs): Allow source and destination
registers in extension to be different under limited
circumstances.
(add_removable_extension): Remove restriction that the
source and destination registers in the extension are the
same.
(find_and_remove_re): Emit a copy from the extension's
destination to its source after the defining insn if
the source and destination registers are different.
testsuite/
* gcc.target/i386/pr53623.c: New test.
Thanks for working on this, the only thing I'd worry about are
HARD_REGNO_NREGS 1 registers if the two hard regs might overlap.
Perhaps it is fine as is and dunno how many targets actually allow partial
overlap in between the multi-register REGs. If you aren't sure this
would be handled properly, perhaps the check could go to
add_removable_extension below the REG_P check add
!reg_overlap_mentioned_p (dest, XEXP (src, 0))
diff --git a/gcc/ree.c b/gcc/ree.c
index 9938e98..63ad86c 100644
--- a/gcc/ree.c
+++ b/gcc/ree.c
@@ -282,9 +282,21 @@ static bool
combine_set_extension (ext_cand *cand, rtx curr_insn, rtx *orig_set)
{
rtx orig_src = SET_SRC (*orig_set);
- rtx new_reg = gen_rtx_REG (cand-mode, REGNO (SET_DEST (*orig_set)));
rtx new_set;
+ /* If the extension's source/destination registers are not the same
+ then we need to change the original load to reference the destination
+ of the extension. Then we need to emit a copy from that destination
+ to the original destination of the load. */
+ rtx new_reg;
+ bool copy_needed
+= REGNO (SET_DEST (PATTERN (cand-insn)))
+ != REGNO (XEXP (SET_SRC (PATTERN (cand-insn)), 0));
Perhaps the right formatting here would be
bool copy_needed
= (REGNO (SET_DEST (PATTERN (cand-insn)))
!= REGNO (XEXP (SET_SRC (PATTERN (cand-insn)), 0)));
? ()s for emacs, and aligning != under REGNO.
+ if (copy_needed)
+new_reg = gen_rtx_REG (cand-mode, REGNO (SET_DEST (PATTERN
(cand-insn;
Too long line.
Looks good to me otherwise.
Jakub
Re: [PATCH] Ubsan load of bool/enum sanitization
On Thu, Dec 19, 2013 at 10:22:38PM -0700, Jeff Law wrote: + *gsi = create_cond_insert_point (gsi, /*before_p=*/true, + /*then_more_likely_p=*/false, + /*create_then_fallthru_edge=*/true, + then_bb, fallthru_bb); Ick (comments embedded in argumust list). Is there some compelling reason for those comments? That is a style used heavily e.g. in the C++ frontend, just an attempt to make the code slightly more readable what exactly you are passing. But it isn't that important, so I'll remove it. OK with that trivial fix. Thanks. Jakub
[PING] RE: [PATCH] Vectorization for store with negative step
OK to commit?
Thanks,
Bingfeng
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On
Behalf Of Bingfeng Mei
Sent: 18 December 2013 16:25
To: Jakub Jelinek
Cc: Richard Biener; gcc-patches@gcc.gnu.org
Subject: RE: [PATCH] Vectorization for store with negative step
Hi, Jakub,
Sorry for all the formatting issues. Haven't submit a patch for a while :-).
Please find the updated patch.
Thanks,
Bingfeng
-Original Message-
From: Jakub Jelinek [mailto:ja...@redhat.com]
Sent: 18 December 2013 13:38
To: Bingfeng Mei
Cc: Richard Biener; gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Vectorization for store with negative step
On Wed, Dec 18, 2013 at 01:31:05PM +, Bingfeng Mei wrote:
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 206016)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2013-12-18 Bingfeng Mei b...@broadcom.com
+
+ PR tree-optimization/59544
+* tree-vect-stmts.c (perm_mask_for_reverse): Move before
This should be a tab instead of 8 spaces.
+ vectorizable_store. (vectorizable_store): Handle negative step.
Newline and tab after store., rather than space.
Property changes on: gcc/testsuite/gcc.target/i386/pr59544.c
___
Added: svn:executable
+ *
Please don't add such bogus property. Testcases aren't executable.
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (revision 206016)
+++ gcc/testsuite/ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2013-12-18 Bingfeng Mei b...@broadcom.com
+
+ PR tree-optimization/59544
+ * gcc.target/i386/pr59544.c: New test
Missing dot at the end of line.
+
2013-12-16 Jakub Jelinek ja...@redhat.com
PR middle-end/58956
Index: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c (revision 206016)
+++ gcc/tree-vect-stmts.c (working copy)
@@ -4859,6 +4859,25 @@ ensure_base_align (stmt_vec_info stmt_in
}
+/* Given a vector type VECTYPE returns the VECTOR_CST mask that implements
+ reversal of the vector elements. If that is impossible to do,
+ returns NULL. */
+
+static tree
+perm_mask_for_reverse (tree vectype)
+{
+ int i, nunits;
+ unsigned char *sel;
+
+ nunits = TYPE_VECTOR_SUBPARTS (vectype);
+ sel = XALLOCAVEC (unsigned char, nunits);
+
+ for (i = 0; i nunits; ++i)
+sel[i] = nunits - 1 - i;
+
+ return vect_gen_perm_mask (vectype, sel);
+}
+
/* Function vectorizable_store.
Check if STMT defines a non scalar data-ref (array/pointer/structure) that
@@ -4902,6 +4921,8 @@ vectorizable_store (gimple stmt, gimple_
vectree oprnds = vNULL;
vectree result_chain = vNULL;
bool inv_p;
+ bool negative = false;
+ tree offset = NULL_TREE;
vectree vec_oprnds = vNULL;
bool slp = (slp_node != NULL);
unsigned int vec_num;
@@ -4976,16 +4997,38 @@ vectorizable_store (gimple stmt, gimple_
if (!STMT_VINFO_DATA_REF (stmt_info))
return false;
- if (tree_int_cst_compare (loop nested_in_vect_loop_p (loop, stmt)
- ? STMT_VINFO_DR_STEP (stmt_info) : DR_STEP (dr),
- size_zero_node) 0)
+ negative = tree_int_cst_compare (loop nested_in_vect_loop_p (loop, stmt)
+? STMT_VINFO_DR_STEP (stmt_info) : DR_STEP (dr),
+size_zero_node) 0;
The formatting looks wrong, do:
negative
= tree_int_cst_compare (loop nested_in_vect_loop_p (loop, stmt)
? STMT_VINFO_DR_STEP (stmt_info) : DR_STEP (dr),
size_zero_node) 0;
instead.
+ if (negative ncopies 1)
{
if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
- negative step for store.\n);
+ multiple types with negative step.);
return false;
}
+ if (negative)
+{
+ gcc_assert (!grouped_store);
+ alignment_support_scheme = vect_supportable_dr_alignment (dr, false);
+ if (alignment_support_scheme != dr_aligned
+ alignment_support_scheme != dr_unaligned_supported)
Lots of places where you use 8 spaces instead of tab, please fix.
+offset = size_int (-TYPE_VECTOR_SUBPARTS (vectype) + 1);
+
if (store_lanes_p)
aggr_type = build_array_type_nelts (elem_type, vec_num * nunits);
else
@@ -5200,7 +5246,7 @@ vectorizable_store (gimple stmt, gimple_
dataref_ptr
= vect_create_data_ref_ptr (first_stmt, aggr_type,
simd_lane_access_p ? loop : NULL,
- NULL_TREE, dummy, gsi, ptr_incr,
+ offset, dummy, gsi, ptr_incr,
Re: [PATCH][1/3] Re-submission of Altera Nios II port, gcc parts
On 11/26/2013 07:45 AM, Chung-Lin Tang wrote: +(define_insn movhi_internal + [(set (match_operand:HI 0 nonimmediate_operand =m, r,r, r,r) +(match_operand:HI 1 general_operand rM,m,rM,I,J))] Didn't you say you'd removed the J alternative? +error (only register based stack limit is supported); This one also ought to be a sorry. Other than these two, I think this can go in. Bernd
Re: [PATCH] Time profiler - phase 2
Hello, there's updated version of the patch. Tested on x86_64 with enable bootstrap. Martin This caused pr59541. TIA Dominique
Re: [RFC/CFT] auto-wipe dump files [was: Re: [committed] Fix up bb-slp-31.c testcase]
On Thu, Oct 31, 2013 at 09:39:11AM +0100, Jakub Jelinek wrote:
On Thu, Oct 31, 2013 at 09:34:41AM +0100, Bernhard Reutner-Fischer wrote:
The cleanup routine would currently run 7 regexes on the incoming
compiler-flags which is supposedly pretty fast.
But yes, we could as well key off scan-dump. If we do that, i'd
suggest to simply wipe all potential dumps, regardless of the family
etc, like:
$ltrans\[0-9\]\[0-9\]\[0-9\][itr].*
What do you think?
Many tests (e.g. in gcc.dg/vect/) pass -fdump-* flags and require cleanups,
even if they don't have any scan directives.
Right.
Mike, attaching a new, slightly simplified patch.
I do not have time nor interest to persue this any further.
Ok for trunk at this stage?
Otherwise i would suggest to either drop this idea altogether or that
you take over if you think this is a nice thing to have for the next
stage1.
Ontop of this patch you would have to
git grep -l -E (cleanup-.*-dump|cleanup-saved-temps) | egrep -v
(ChangeLog|/lib/) | sed -e s|[^/]*$|| | sort | uniq | \
while read d;
do
find $d -type f -exec sed -i -e
/cleanup-[^-]*[-]*dump/d;/cleanup-saved-temps/d {} +
done
diffstat -s:
4874 files changed, 111 insertions(+), 5099 deletions(-)
Tested the same way as the initial incarnation against r205304 with no
regressions.
The ChangeLogs remain the same, i.e.:
gcc/testsuite/ChangeLog
2013-10-12 Bernhard Reutner-Fischer al...@gcc.gnu.org
* lib/gcc-dg.exp (cleanup-ipa-dump, cleanup-rtl-dump,
cleanup-tree-dump, cleanup-dump): Remove. Adjust all callers.
(schedule-cleanups): New proc.
(gcc-dg-test-1): Call it.
* lib/profopt.exp (profopt-execute): Likewise.
* g++.dg/cdce3.C: Adjust expected line numbers.
* gcc.dg/cdce1.c: Likewise.
* gcc.dg/cdce2.c: Likewise.
* gcc.dg/strlenopt-22.c: Fix comment delimiter.
* gcc.dg/strlenopt-24.c: Likewise.
* gcc.dg/tree-ssa/vrp26.c: Likewise.
* gcc.dg/tree-ssa/vrp28.c: Likewise.
* obj-c++.dg/encode-2.mm: Likewise.
* lib/dg-pch.exp(pch-init): Remove pch-check objects.
libgomp/ChangeLog
2013-10-12 Bernhard Reutner-Fischer al...@gcc.gnu.org
* testsuite/libgomp.graphite/bounds.c: Adjust for
cleanup-tree-dump removal.
* testsuite/libgomp.graphite/force-parallel-1.c: Likewise.
* testsuite/libgomp.graphite/force-parallel-2.c: Likewise.
* testsuite/libgomp.graphite/force-parallel-3.c: Likewise.
* testsuite/libgomp.graphite/force-parallel-4.c: Likewise.
* testsuite/libgomp.graphite/force-parallel-5.c: Likewise.
* testsuite/libgomp.graphite/force-parallel-6.c: Likewise.
* testsuite/libgomp.graphite/force-parallel-7.c: Likewise.
* testsuite/libgomp.graphite/force-parallel-8.c: Likewise.
* testsuite/libgomp.graphite/force-parallel-9.c: Likewise.
* testsuite/libgomp.graphite/pr41118.c: Likewise.
gcc/ChangeLog
2013-10-12 Bernhard Reutner-Fischer al...@gcc.gnu.org
* config/arm/neon-testgen.ml (emit_epilogue): Remove manual call
to cleanup-saved-temps.
gcc/doc/ChangeLog
2013-10-12 Bernhard Reutner-Fischer al...@gcc.gnu.org
* doc/sourcebuild.texi (Clean up generated test files): Expand
introduction.
(cleanup-ipa-dump, cleanup-rtl-dump, cleanup-tree-dump,
cleanup-saved-temps): Remove.
PS: As you can see, i had to touch a couple of files that had broken
comments like the vrp and strlenopt files. Should the testsuite
add -Wcomment per default?
cheers,
From ac5690774eb2134b063464be56bfc56826305d01 Mon Sep 17 00:00:00 2001
From: Bernhard Reutner-Fischer rep.dot@gmail.com
Date: Fri, 18 Oct 2013 21:08:49 +0200
Subject: [PATCH] auto-wipe dump files
Signed-off-by: Bernhard Reutner-Fischer rep.dot@gmail.com
---
gcc/config/arm/neon-testgen.ml| 1 -
gcc/doc/sourcebuild.texi | 19 ++---
gcc/testsuite/g++.dg/cdce3.C | 5 +-
gcc/testsuite/gcc.dg/cdce1.c | 3 +-
gcc/testsuite/gcc.dg/cdce2.c | 3 +-
gcc/testsuite/gcc.dg/strlenopt-22.c | 3 +-
gcc/testsuite/gcc.dg/strlenopt-24.c | 3 +-
gcc/testsuite/gcc.dg/tree-ssa/vrp26.c | 3 +-
gcc/testsuite/gcc.dg/tree-ssa/vrp28.c | 3 +-
gcc/testsuite/lib/dg-pch.exp | 2 +
gcc/testsuite/lib/gcc-dg.exp | 134 +++---
gcc/testsuite/lib/profopt.exp | 3 +
gcc/testsuite/obj-c++.dg/encode-2.mm | 3 +-
13 files changed, 111 insertions(+), 74 deletions(-)
diff --git a/gcc/config/arm/neon-testgen.ml b/gcc/config/arm/neon-testgen.ml
index 543318b..4734ac0 100644
--- a/gcc/config/arm/neon-testgen.ml
+++ b/gcc/config/arm/neon-testgen.ml
@@ -139,7 +139,6 @@ let emit_epilogue chan features regexps =
else
()
);
-Printf.fprintf chan /* { dg-final { cleanup-saved-temps } } */\n
(* Check a list of C types to determine which ones are pointers and which
ones are const. *)
diff
RE: Two build != host fixes
Date: Fri, 20 Dec 2013 07:57:02 +1030
From: amo...@gmail.com
To: bernd.edlin...@hotmail.de
CC: gcc-patches@gcc.gnu.org; ja...@redhat.com; d...@redhat.com;
ebotca...@adacore.com
Subject: Re: Two build != host fixes
On Thu, Dec 19, 2013 at 11:50:02AM +0100, Bernd Edlinger wrote:
Isn't the actual invocation of the build-g++ also including
/sysroot_for_host/include
in that case? Why doesn't this cause problems then?
Yes, and that causes failures too. BUILD_CPPFLAGS is the culprit.
See http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01149.html
--
Alan Modra
Australia Development Lab, IBM
Ok, now I understand:
The change with GMPINC= is just incomplete, without the other patch.
When I apply the other patch too, I get this (obviously cleaner) build-g++
invocations:
g++ -c -DIN_GCC -DGENERATOR_FILE -I. -Ibuild -I../../gcc-4.9-20131215/gcc
-I../../gcc-4.9-20131215/gcc/build -I../../gcc-4.9-20131215/gcc/../include
-I../../gcc-4.9-20131215/gcc/../libcpp/include \
-o build/gengtype.o ../../gcc-4.9-20131215/gcc/gengtype.c
flex -ogengtype-lex.c ../../gcc-4.9-20131215/gcc/gengtype-lex.l { \
echo '#include bconfig.h' gengtype-lex.c.tmp; \
cat gengtype-lex.c gengtype-lex.c.tmp; \
mv gengtype-lex.c.tmp gengtype-lex.c; \
}
g++ -c -DIN_GCC -DGENERATOR_FILE -I. -Ibuild -I../../gcc-4.9-20131215/gcc
-I../../gcc-4.9-20131215/gcc/build -I../../gcc-4.9-20131215/gcc/../include
-I../../gcc-4.9-20131215/gcc/../libcpp/include \
-o build/gengtype-lex.o gengtype-lex.c
g++ -c -DIN_GCC -DGENERATOR_FILE -I. -Ibuild -I../../gcc-4.9-20131215/gcc
-I../../gcc-4.9-20131215/gcc/build -I../../gcc-4.9-20131215/gcc/../include
-I../../gcc-4.9-20131215/gcc/../libcpp/include \
-o build/gengtype-parse.o
../../gcc-4.9-20131215/gcc/gengtype-parse.c
g++ -c -DIN_GCC -DGENERATOR_FILE -I. -Ibuild -I../../gcc-4.9-20131215/gcc
-I../../gcc-4.9-20131215/gcc/build -I../../gcc-4.9-20131215/gcc/../include
-I../../gcc-4.9-20131215/gcc/../libcpp/include \
-o build/gengtype-state.o
../../gcc-4.9-20131215/gcc/gengtype-state.c
Regards
Bernd.
Re: Improving mklog [was: Re: RFC Asan instrumentation control]
Ultimately, mklog ought to write the ChangeLog itself.
We get rid of that headache, at least.
How about this then? Updated mklog now adds 'New file'/'New
test'/'Remove' when necessary.
I did some tests with unified/context-diffed SVN and git and it worked
as expected. I can do more testing if necessary.
-Y
diff --git a/contrib/mklog b/contrib/mklog
index d3f044e..fb0514f 100755
--- a/contrib/mklog
+++ b/contrib/mklog
@@ -43,7 +43,7 @@ chdir $gcc_root;
# Program starts here. You should not need to edit anything below this
# line.
#-
-if ( $#ARGV != 0 ) {
+if ($#ARGV != 0) {
$prog = `basename $0`; chop ($prog);
print usage: $prog file.diff\n\n;
print Adds a ChangeLog template to the start of file.diff\n;
@@ -56,40 +56,76 @@ $dir = `dirname $diff`; chop ($dir);
$basename = `basename $diff`; chop ($basename);
$hdrline = $date $name $addr;
-my %cl_entries;
+sub get_clname ($) {
+ return ('ChangeLog', $_[0]) if ($_[0] !~ /[\/\\]/);
-sub get_clname($) {
my $dirname = $_[0];
while ($dirname) {
my $clname = $dirname/ChangeLog;
if (-f $clname) {
- my $filename_rel = substr ($_[0], length ($dirname) + 1);
- return ($filename_rel, $clname);
+ my $relname = substr ($_[0], length ($dirname) + 1);
+ return ($clname, $relname);
} else {
$dirname =~ s/[\/\\]?[^\/\\]*$//;
}
}
- return ($_[0], 'Unknown Changelog');
+
+ return ('Unknown ChangeLog', $_[0]);
+}
+
+sub remove_suffixes ($) {
+ my $filename = $_[0];
+ $filename =~ s/^[ab]\///;
+ $filename =~ s/\.jj$//;
+ return $filename;
}
# For every file in the .diff print all the function names in ChangeLog
# format.
-$bof = 0;
+%cl_entries = ();
+$change_msg = undef;
+$look_for_funs = 0;
$clname = get_clname('');
open (DFILE, $diff) or die Could not open file $diff for reading;
while (DFILE) {
-# Check if we found a new file.
-if (/^\+\+\+ (b\/)?(\S+)/) {
+# Stop processing functions if we found a new file
+ # Remember both left and right names because one may be /dev/null.
+if (/^[+*][+*][+*] +(\S+)/) {
+ $left = remove_suffixes ($1);
+ $look_for_funs = 0;
+ }
+if (/^--- +(\S+)?/) {
+ $right = remove_suffixes ($1);
+ $look_for_funs = 0;
+ }
+
+ # Check if the body of diff started.
+ # We should now have both left and right name,
+ # so we can decide filename.
+
+if ($left (/^\*{15}$/ || /^@@ /)) {
# If we have not seen any function names in the previous file (ie,
- # $bof == 1), we just write out a ':' before starting the next
+ # $change_msg is empty), we just write out a ':' before starting the next
# file.
- if ($bof == 1) {
- $cl_entries{$clname} .= :\n;
+ if ($clname) {
+ $cl_entries{$clname} .= $change_msg ? $change_msg : :\n;
+ }
+
+ if ($left eq $right) {
+ $filename = $left;
+ } elsif($left eq '/dev/null') {
+ $filename = $right;
+ } elsif($right eq '/dev/null') {
+ $filename = $left;
+ } else {
+ print STDERR Error: failed to parse diff for $left and $right\n;
+ exit 1;
}
- $filename = $2;
- ($filename_rel, $clname) = get_clname ($filename);
- $cl_entries{$clname} .= \t* $filename_rel;
- $bof = 1;
+ $left = $right = undef;
+ ($clname, $relname) = get_clname ($filename);
+ $cl_entries{$clname} .= \t* $relname;
+ $change_msg = '';
+ $look_for_funs = $filename =~ '\.(c|cpp|C|cc|h|inc|def)$';
}
# Remember the last line in a unified diff block that might start
@@ -98,6 +134,22 @@ while (DFILE) {
$save_fn = $1;
}
+# Check if file is newly added.
+# Two patterns: for context and unified diff.
+if (/^\*\*\* 0 \*\*\*\*/
+|| /^@@ -0,0 \+1.* @@/) {
+$change_msg = $filename =~ /testsuite.*(?!\.exp)$/ ? : New test.\n : : New file.\n;
+$look_for_funs = 0;
+}
+
+# Check if file was removed.
+# Two patterns: for context and unified diff.
+if (/^--- 0 /
+|| /^@@ -1.* \+0,0 @@/) {
+$change_msg = : Remove.\n;
+$look_for_funs = 0;
+}
+
# If we find a new function, print it in brackets. Special case if
# this is the first function in a file.
#
@@ -110,10 +162,11 @@ while (DFILE) {
# The fourth pattern looks for the starts of functions or classes
# within a unified diff block.
-if (/^\*\*\*\*\*\** ([a-zA-Z0-9_].*)/
+if ($look_for_funs
+ (/^\*\*\*\*\*\** ([a-zA-Z0-9_].*)/
|| /^[\-\+\!] ([a-zA-Z0-9_]+)[ \t]*\(.*/
|| /^@@ .* @@ ([a-zA-Z0-9_].*)/
- || /^[-+ ](\{)/)
+ || /^[-+ ](\{)/))
{
$_ = $1;
my $fn;
@@ -138,25 +191,24 @@ while (DFILE) {
# If this is the first function in the file, we display it next
# to the filename, so we need an extra space before the opening
# brace.
- if ($bof) {
- $cl_entries{$clname} .= ;
- $bof = 0;
+ if (!$change_msg) {
+ $change_msg .= ;
} else {
- $cl_entries{$clname} .= \t;
+ $change_msg .= \t;
}
- $cl_entries{$clname} .= ($fn):\n;
+
Re: [PATCH] fixincludes: use $(FI) instead of fixincl@EXEEXT@
On 8 November 2013 17:28, Bruce Korb bk...@gnu.org wrote: Sure. Looks good to me. Thanks pushed as r206146 thanks, On Fri, Nov 8, 2013 at 2:57 AM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On 4 April 2013 22:20, Bruce Korb bk...@gnu.org wrote: Except as noted below, fine by me. On 04/04/13 12:56, Bernhard Reutner-Fischer wrote: Bootstrapped and regtested on x86_64-unknown-linux-gnu and x86_64-mine-linux-uclibc without regressions, ok for trunk? fixincludes/ChangeLog: 2013-04-04 Bernhard Reutner-Fischer al...@gcc.gnu.org Makefile.in: Use $(FI) instead of fixincl@EXEEXT@. Cleanup whitespace while at it. Signed-off-by: Bernhard Reutner-Fischer rep.dot@gmail.com --- fixincludes/Makefile.in | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/fixincludes/Makefile.in b/fixincludes/Makefile.in index ce850ff..3dc869d 100644 --- a/fixincludes/Makefile.in +++ b/fixincludes/Makefile.in @@ -131,7 +131,7 @@ fixinc.sh : fixinc.in mkfixinc.sh Makefile $(srcdir)/fixincl.x: @MAINT@ fixincl.tpl inclhack.def cd $(srcdir) ; $(SHELL) ./genfixes -mostlyclean : +mostlyclean: I see no reason for changing things. dropped this hunk. But if you are going to clean up the colons, then they should be in columns (mostly 12 or 16). This one is already in 12. rm -f *.o *-stamp $(AF) $(FI) *~ fixinc.sh clean: mostlyclean @@ -179,18 +179,18 @@ check : all install : all -rm -rf $(DESTDIR)$(itoolsdir) - $(mkinstalldirs) $(DESTDIR)$(itoolsdir) + $(mkinstalldirs) $(DESTDIR)$(itoolsdir) $(mkinstalldirs) $(DESTDIR)$(itoolsdatadir)/include $(INSTALL_DATA) $(srcdir)/README-fixinc \ $(DESTDIR)$(itoolsdatadir)/include/README $(INSTALL_SCRIPT) fixinc.sh $(DESTDIR)$(itoolsdir)/fixinc.sh - $(INSTALL_PROGRAM) fixincl@EXEEXT@ \ - $(DESTDIR)$(itoolsdir)/fixincl@EXEEXT@ + $(INSTALL_PROGRAM) $(FI) \ + $(DESTDIR)$(itoolsdir)/$(FI) This should now fit on a single line. ok $(INSTALL_SCRIPT) mkheaders $(DESTDIR)$(itoolsdir)/mkheaders install-strip: install test -z '$(STRIP)' \ - || $(STRIP) $(DESTDIR)$(itoolsdir)/fixincl@EXEEXT@ + || $(STRIP) $(DESTDIR)$(itoolsdir)/$(FI) changed this too to be on a single line now. .PHONY: all check install install-strip .PHONY: dvi pdf info html install-pdf install-info install-html Changelog remains the same. II was using the attached updated patch since April, ok for trunk?
Re: [PATCH 2/3] libstdc++-v3: ::tmpnam depends on uClibc SUSV4_LEGACY
On 13 November 2013 18:56, Jonathan Wakely jwakely@gmail.com wrote: On 13 November 2013 09:22, Bernhard Reutner-Fischer wrote: On 11 November 2013 12:30, Jonathan Wakely jwakely@gmail.com wrote: How does __UCLIBC_SUSV4_LEGACY__ get defined? We'd have a problem if users defined that at configure time but not later when using the library. That would be defined by uClibc's configury, but the latest commit-6f2faa2 i attached does not mention this anymore, but does the check in a libc-agnostic manner? Yes, but I was concerned about whether the value of that macro can change between configuring libstdc++ and users compiling code using libstdc++. If it could change (e.g. by users compiling with -D_POSIX_C_SOURCE=200112L or some other feature test macro) then the value of _GLIBCXX_USE_TMPNAM (which doesn't change) would be unreliable and we could end up with a using ::tmpnam in the library that causes errors when users compile. If it's set when configuring uClibc then it is a constant for a given libstdc++ installation, so the value of _GLIBCXX_USE_TMPNAM is reliable. In that case your change is OK to commit (with or without the XYZ change) - thanks. It is a constant, yes. I will push this after another round of regtests against current trunk as time permits. thanks,
Re: [PATCH] Time profiler - phase 2
Hi Martin,
Thanks for working on this!
--- However you have introduced some problems including a bootstrap fail on
darwin.
On 16 Dec 2013, at 10:13, Jan Hubicka wrote:
Hello,
there's updated version of the patch.
Tested on x86_64 with enable bootstrap.
Martin
On 16 December 2013 00:21, Jan Hubicka hubi...@ucw.cz wrote:
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 93e857df..d5a0ac8 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,14 @@
+2013-12-15 Martin Liska marxin.li...@gmail.com
+ Jan Hubicka j...@suse.cz
+
+ * cgraphunit.c (node_cmp): New function.
+ (expand_all_functions): Function ordering added.
+ * common.opt: New profile based function reordering flag introduced.
+ * lto-partition.c: Support for time profile added.
+ * lto.c: Likewise.
+ * predict.c (handle_missing_profiles): Time profile handled in
+ missing profiles.
+
There is no mention of config/darwin.c here ^
diff --git a/gcc/config/darwin.c b/gcc/config/darwin.c
index ea056a9..4267c89 100644
--- a/gcc/config/darwin.c
+++ b/gcc/config/darwin.c
@@ -3621,9 +3621,16 @@ darwin_function_section (tree decl, enum node_frequency
freq,
unlikely executed (this happens especially with function splitting
where we can split away unnecessary parts of static constructors). */
if (startup freq != NODE_FREQUENCY_UNLIKELY_EXECUTED)
-return (weak)
- ? darwin_sections[text_startup_coal_section]
- : darwin_sections[text_startup_section];
+ {
+/* If we do have a profile or(and) LTO phase is executed, we do not need
+ these ELF section. */
+if (!in_lto_p || !flag_profile_values)
+ return (weak)
+ ? darwin_sections[text_startup_coal_section]
+ : darwin_sections[text_startup_section];
+else
+ return text_section;
+ }
/* Similarly for exit. */
if (exit freq != NODE_FREQUENCY_UNLIKELY_EXECUTED)
@@ -3640,10 +3647,15 @@ darwin_function_section (tree decl, enum node_frequency
freq,
: darwin_sections[text_cold_section];
break;
case NODE_FREQUENCY_HOT:
- return (weak)
- ? darwin_sections[text_hot_coal_section]
- : darwin_sections[text_hot_section];
- break;
+ {
+/* If we do have a profile or(and) LTO phase is executed, we do not
need
+ these ELF section. */
+if (!in_lto_p || !flag_profile_values)
+ return (weak)
+ ? darwin_sections[text_hot_coal_section]
+ : darwin_sections[text_hot_section];
+break;
+ }
default:
return (weak)
? darwin_sections[text_coal_section]
-=
This is NOT OK for darwin, it breaks bootstrap with pr59541.
If one fixes that trivial issue - then there is a lot of test-suite fallout of
profiled code.
Please explain what the logic is intended to implement - and ensure that all
the code-paths have equivalent treatment - it all looks inconsitent to me at
present.
I am sure that one of the darwin folks will be happy to review (or at least
test) changes.
cheers
Iain
[PATCH, libiberty] Remove malloc/realloc from demangler (was: Add a couple of missing casts)
Ian Lance Taylor wrote:
On Wed, Nov 13, 2013 at 7:30 AM, Gary Benson gben...@redhat.com wrote:
Richard Biener wrote:
On Tue, Nov 12, 2013 at 8:55 PM, Ian Lance Taylor i...@google.com wrote:
On Tue, Nov 12, 2013 at 11:24 AM, Uros Bizjak ubiz...@gmail.com wrote:
This was uncovered by x86 lto-profiledbootstrap. The patch allows
lto-profiledbootstrap to proceed further.
2013-11-12 Uros Bizjak ubiz...@gmail.com
* cp-demangle.c (d_copy_templates): Cast result of malloc
to (struct d_print_template *).
(d_print_comp): Cast result of realloc to (struct d_saved scope
*).
Tested on x86_64-pc-linux-gnu.
OK for mainline?
The patch is OK, but this code is troubling. I obviously
should have looked at it earlier. The C++ demangler is
sometimes used in panic situations, when malloc is not
available. The interface was designed to be usable without
requiring malloc, by passing in a sufficiently large buffer.
I'm concerned that we apparently now require malloc to work.
That indeed looks like an important regression - Gary, can you
please work to fix this?
I'm on it.
Thanks. See also the cplus_demangle_print_callback function.
The below patch should remedy this.
After the end of today I'll likely not check this email until
January 5. If this patch gets approved before then and you
want it in please either ping me on gary@ the domain in my sig
or just somebody else commit it for me.
Thanks,
Gary
--
http://gbenson.net/
diff --git a/libiberty/ChangeLog b/libiberty/ChangeLog
index 825ddd2..78c1433 100644
--- a/libiberty/ChangeLog
+++ b/libiberty/ChangeLog
@@ -1,3 +1,20 @@
+2013-12-20 Gary Benson gben...@redhat.com
+
+ * cp-demangle.c (struct d_print_info): New fields
+ next_saved_scope, copy_templates, next_copy_template and
+ num_copy_templates.
+ (d_count_templates): New function.
+ (d_print_init): New parameter dc.
+ Estimate numbers of templates and scopes required.
+ (d_print_free): Removed function.
+ (cplus_demangle_print_callback): Allocate stack for
+ templates and scopes. Removed call to d_print_free.
+ (d_copy_templates): Removed function.
+ (d_save_scope): New function.
+ (d_get_saved_scope): Likewise.
+ (d_print_comp): Replace state saving/restoring code with
+ calls to d_save_scope and d_get_saved_scope.
+
2013-11-22 Cary Coutant ccout...@google.com
PR other/59195
diff --git a/libiberty/cp-demangle.c b/libiberty/cp-demangle.c
index 029151e..de08d94 100644
--- a/libiberty/cp-demangle.c
+++ b/libiberty/cp-demangle.c
@@ -329,8 +329,16 @@ struct d_print_info
unsigned long int flush_count;
/* Array of saved scopes for evaluating substitutions. */
struct d_saved_scope *saved_scopes;
+ /* Index of the next unused saved scope in the above array. */
+ int next_saved_scope;
/* Number of saved scopes in the above array. */
int num_saved_scopes;
+ /* Array of templates for saving into scopes. */
+ struct d_print_template *copy_templates;
+ /* Index of the next unused copy template in the above array. */
+ int next_copy_template;
+ /* Number of copy templates in the above array. */
+ int num_copy_templates;
/* The nearest enclosing template, if any. */
const struct demangle_component *current_template;
};
@@ -475,7 +483,8 @@ static void
d_growable_string_callback_adapter (const char *, size_t, void *);
static void
-d_print_init (struct d_print_info *, demangle_callbackref, void *);
+d_print_init (struct d_print_info *, demangle_callbackref, void *,
+ const struct demangle_component *);
static inline void d_print_error (struct d_print_info *);
@@ -3770,11 +3779,141 @@ d_growable_string_callback_adapter (const char *s,
size_t l, void *opaque)
d_growable_string_append_buffer (dgs, s, l);
}
+/* Walk the tree, counting the number of templates encountered, and
+ the number of times a scope might be saved. These counts will be
+ used to allocate data structures for d_print_comp, so the logic
+ here must mirror the logic d_print_comp will use. It is not
+ important that the resulting numbers are exact, so long as they
+ are larger than the actual numbers encountered. */
+
+static void
+d_count_templates_scopes (int *num_templates, int *num_scopes,
+ const struct demangle_component *dc)
+{
+ if (dc == NULL)
+return;
+
+ switch (dc-type)
+{
+case DEMANGLE_COMPONENT_NAME:
+case DEMANGLE_COMPONENT_TEMPLATE_PARAM:
+case DEMANGLE_COMPONENT_FUNCTION_PARAM:
+case DEMANGLE_COMPONENT_SUB_STD:
+case DEMANGLE_COMPONENT_BUILTIN_TYPE:
+case DEMANGLE_COMPONENT_OPERATOR:
+case DEMANGLE_COMPONENT_CHARACTER:
+case DEMANGLE_COMPONENT_NUMBER:
+case DEMANGLE_COMPONENT_UNNAMED_TYPE:
+ break;
+
+case DEMANGLE_COMPONENT_TEMPLATE:
+ (*num_templates)++;
[committed] Add testcase for PR59413
Hi!
The bug in this PR has been introduced by my r204516 change and fixed
by r205884 (PR59417) fix.
I've committed the testcase as obvious so that we can close the PR.
2013-12-20 Jakub Jelinek ja...@redhat.com
PR tree-optimization/59413
* gcc.c-torture/execute/pr59413.c: New test.
--- gcc/testsuite/gcc.c-torture/execute/pr59413.c.jj2013-12-20
13:59:46.518654547 +0100
+++ gcc/testsuite/gcc.c-torture/execute/pr59413.c 2013-12-20
13:59:29.0 +0100
@@ -0,0 +1,21 @@
+/* PR tree-optimization/59413 */
+
+typedef unsigned int uint32_t;
+
+uint32_t a;
+int b;
+
+int
+main ()
+{
+ uint32_t c;
+ for (a = 7; a = 1; a++)
+{
+ char d = a;
+ c = d;
+ b = a == c;
+}
+ if (a != 7)
+__builtin_abort ();
+ return 0;
+}
Jakub
Re: [PATCH] merge auto_vec and stack_vec
On Fri, Dec 20, 2013 at 12:18 AM, Trevor Saunders
trev.saund...@gmail.com wrote:
As discussed in http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02808.html
bootstrap + same regression tests as previous rev, ok?
Ok.
Thanks,
Richard.
2013-12-19 Trevor saunders tsaund...@mozilla.com
gcc/
* vec.h (stack_vec): Convert to a templaate specialization of
auto_vec.
* config/i386/i386.c, df-scan.c, function.c, genautomata.c,
gimplify.c, graphite-clast-to-gimple.c, graphite-dependences.c,
graphite-scop-detection.c, graphite-sese-to-poly.c, hw-doloop.c,
trans-mem.c, tree-call-cdce.c, tree-data-ref.c, tree-dfa.c,
tree-if-conv.c, tree-inline.c, tree-loop-distribution.c,
tree-parloops.c, tree-predcom.c, tree-ssa-alias.c,
tree-ssa-loop-ivcanon.c, tree-ssa-phiopt.c, tree-ssa-threadedge.c,
tree-ssa-uncprop.c, tree-vect-loop.c, tree-vect-patterns.c,
tree-vect-slp.c, tree-vect-stmts.c, var-tracking.c: Adjust.
cp/
* semantics.c (build_anon_member_initialization): Replace
stack_vecT, N with auto_vecT, N.
ada/
* gcc-interface/decl.c (components_to_record): Replace stack_vec with
auto_vec.
Trev
diff --git a/gcc/ada/gcc-interface/decl.c b/gcc/ada/gcc-interface/decl.c
index a80d1a9..ad129c6 100644
--- a/gcc/ada/gcc-interface/decl.c
+++ b/gcc/ada/gcc-interface/decl.c
@@ -7010,7 +7010,7 @@ components_to_record (tree gnu_record_type, Node_Id
gnat_component_list,
tree gnu_union_type, gnu_union_name;
tree this_first_free_pos, gnu_variant_list = NULL_TREE;
bool union_field_needs_strict_alignment = false;
- stack_vec vinfo_t, 16 variant_types;
+ auto_vec vinfo_t, 16 variant_types;
vinfo_t *gnu_variant;
unsigned int variants_align = 0;
unsigned int i;
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 5dde632..e3f8b4d 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -30809,7 +30809,7 @@ ix86_generate_version_dispatcher_body (void *node_p)
push_cfun (DECL_STRUCT_FUNCTION (resolver_decl));
- stack_vectree, 2 fn_ver_vec;
+ auto_vectree, 2 fn_ver_vec;
for (versn_info = node_version_info-next; versn_info;
versn_info = versn_info-next)
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 7c1b18e..30426d8 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -7439,7 +7439,7 @@ build_anon_member_initialization (tree member, tree
init,
to build up the initializer from the outside in so that we can reuse
previously built CONSTRUCTORs if this is, say, the second field in an
anonymous struct. So we use a vec as a stack. */
- stack_vectree, 2 fields;
+ auto_vectree, 2 fields;
do
{
fields.safe_push (TREE_OPERAND (member, 1));
diff --git a/gcc/df-scan.c b/gcc/df-scan.c
index eb7e4d4..dcb4566 100644
--- a/gcc/df-scan.c
+++ b/gcc/df-scan.c
@@ -86,10 +86,10 @@ static HARD_REG_SET elim_reg_set;
struct df_collection_rec
{
- stack_vecdf_ref, 128 def_vec;
- stack_vecdf_ref, 32 use_vec;
- stack_vecdf_ref, 32 eq_use_vec;
- stack_vecdf_mw_hardreg_ptr, 32 mw_vec;
+ auto_vecdf_ref, 128 def_vec;
+ auto_vecdf_ref, 32 use_vec;
+ auto_vecdf_ref, 32 eq_use_vec;
+ auto_vecdf_mw_hardreg_ptr, 32 mw_vec;
};
static df_ref df_null_ref_rec[1];
diff --git a/gcc/function.c b/gcc/function.c
index 2c8d781..95f7ed8 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -4114,7 +4114,7 @@ reorder_blocks (void)
if (block == NULL_TREE)
return;
- stack_vectree, 10 block_stack;
+ auto_vectree, 10 block_stack;
/* Reset the TREE_ASM_WRITTEN bit for all blocks. */
clear_block_marks (block);
diff --git a/gcc/genautomata.c b/gcc/genautomata.c
index 5580c69..aa05541 100644
--- a/gcc/genautomata.c
+++ b/gcc/genautomata.c
@@ -3349,7 +3349,7 @@ uniq_sort_alt_states (alt_state_t alt_states_list)
if (alt_states_list-next_alt_state == 0)
return alt_states_list;
- stack_vecalt_state_t, 150 alt_states;
+ auto_vecalt_state_t, 150 alt_states;
for (curr_alt_state = alt_states_list;
curr_alt_state != NULL;
curr_alt_state = curr_alt_state-next_alt_state)
@@ -5484,7 +5484,7 @@ form_ainsn_with_same_reservs (automaton_t automaton)
{
ainsn_t curr_ainsn;
size_t i;
- stack_vecainsn_t, 150 last_insns;
+ auto_vecainsn_t, 150 last_insns;
for (curr_ainsn = automaton-ainsn_list;
curr_ainsn != NULL;
@@ -,7 +,7 @@ make_automaton (automaton_t automaton)
state_t state;
state_t start_state;
state_t state2;
- stack_vecstate_t, 150 state_stack;
+ auto_vecstate_t, 150 state_stack;
int states_n;
reserv_sets_t reservs_matter = form_reservs_matter (automaton);
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 2e8c657..d51d1b8 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -1846,7 +1846,7 @@ gimplify_compound_lval
[PATCH, nds32] Committed: Fix inaccurate alignment checking when passing BLKmode argument.
Hi, all,
There is a problem in nds32.h to determine available register number
for passing BLKmode argument. The original checking only refers to
NDS32_NEED_N_REGS_FOR_ARG macro but that is not sufficient to make
decision of using odd or even register number. It is supposed to
further check the type alignment.
We define a new macro NDS32_MODE_TYPE_ALIGN and rewrite
NDS32_AVAILABLE_REGNUM_FOR_ARG definition.
The patch for nds32.c and nds32.h is as follow:
Index: gcc/config/nds32/nds32.h
===
--- gcc/config/nds32/nds32.h(revision 206139)
+++ gcc/config/nds32/nds32.h(working copy)
@@ -126,6 +126,11 @@
#define NDS32_SINGLE_WORD_ALIGN_P(value) (((value) 0x03) == 0)
#define NDS32_DOUBLE_WORD_ALIGN_P(value) (((value) 0x07) == 0)
+/* Get alignment according to mode or type information.
+ When 'type' is nonnull, there is no need to look at 'mode'. */
+#define NDS32_MODE_TYPE_ALIGN(mode, type) \
+ (type ? TYPE_ALIGN (type) : GET_MODE_ALIGNMENT (mode))
+
/* Round X up to the nearest double word. */
#define NDS32_ROUND_UP_DOUBLE_WORD(value) (((value) + 7) ~7)
@@ -142,12 +147,18 @@
/* This macro is used to return the register number for passing argument.
We need to obey the following rules:
1. If it is required MORE THAN one register,
-make sure the register number is a even value.
+we need to further check if it really needs to be
+aligned on double words.
+ a) If double word alignment is necessary,
+ the register number must be even value.
+ b) Otherwise, the register number can be odd or even value.
2. If it is required ONLY one register,
the register number can be odd or even value. */
-#define NDS32_AVAILABLE_REGNUM_FOR_ARG(reg_offset, mode, type) \
- ((NDS32_NEED_N_REGS_FOR_ARG (mode, type) 1)\
- ? (((reg_offset) + NDS32_GPR_ARG_FIRST_REGNUM + 1) ~1)\
+#define NDS32_AVAILABLE_REGNUM_FOR_ARG(reg_offset, mode, type) \
+ ((NDS32_NEED_N_REGS_FOR_ARG (mode, type) 1) \
+ ? ((NDS32_MODE_TYPE_ALIGN (mode, type) PARM_BOUNDARY) \
+ ? (((reg_offset) + NDS32_GPR_ARG_FIRST_REGNUM + 1) ~1) \
+ : ((reg_offset) + NDS32_GPR_ARG_FIRST_REGNUM))\
: ((reg_offset) + NDS32_GPR_ARG_FIRST_REGNUM))
/* This macro is to check if there are still available registers
Index: gcc/config/nds32/nds32.c
===
--- gcc/config/nds32/nds32.c(revision 206139)
+++ gcc/config/nds32/nds32.c(working copy)
@@ -1438,8 +1438,8 @@
{
unsigned int align;
- /* When 'type' is nonnull, there is no need to look at 'mode'. */
- align = (type ? TYPE_ALIGN (type) : GET_MODE_ALIGNMENT (mode));
+ /* Pick up the alignment according to the mode or type. */
+ align = NDS32_MODE_TYPE_ALIGN (mode, type);
return (align PARM_BOUNDARY);
}
@@ -1853,10 +1853,10 @@
if (NDS32_ARG_PASS_IN_REG_P (cum-reg_offset, mode, type))
{
/* Pick up the next available register number. */
- return gen_rtx_REG (mode,
- NDS32_AVAILABLE_REGNUM_FOR_ARG (cum-reg_offset,
- mode,
- type));
+ unsigned int regno;
+
+ regno = NDS32_AVAILABLE_REGNUM_FOR_ARG (cum-reg_offset, mode, type);
+ return gen_rtx_REG (mode, regno);
}
else
{
And the gcc/ChangeLog is as below:
+2013-12-20 Chung-Ju Wu jasonw...@gmail.com
+
+ * config/nds32/nds32.h (NDS32_MODE_TYPE_ALIGN): New macro.
+ (NDS32_AVAILABLE_REGNUM_FOR_ARG): Use more accurate alignment checking
+ to determine available register number.
+ * config/nds32/nds32.c (nds32_needs_double_word_align): Use new
+ macro NDS32_MODE_TYPE_ALIGN.
+ (nds32_function_arg): Refine code layout.
+
2013-12-19 Jeff Law l...@redhat.com
* doc/invoke.texi: (dump-rtl-ree): Fix typo and clarify ree
Bootstrapped and tested on nds32le-elf/nds32be-elf target.
Committed as Rev.206142:
http://gcc.gnu.org/r206142
Best regards,
jasonwucj
Re: [PING] RE: [PATCH] Vectorization for store with negative step
On Fri, Dec 20, 2013 at 11:09 AM, Bingfeng Mei b...@broadcom.com wrote:
OK to commit?
Ok.
Thanks,
Richard.
Thanks,
Bingfeng
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On
Behalf Of Bingfeng Mei
Sent: 18 December 2013 16:25
To: Jakub Jelinek
Cc: Richard Biener; gcc-patches@gcc.gnu.org
Subject: RE: [PATCH] Vectorization for store with negative step
Hi, Jakub,
Sorry for all the formatting issues. Haven't submit a patch for a while :-).
Please find the updated patch.
Thanks,
Bingfeng
-Original Message-
From: Jakub Jelinek [mailto:ja...@redhat.com]
Sent: 18 December 2013 13:38
To: Bingfeng Mei
Cc: Richard Biener; gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Vectorization for store with negative step
On Wed, Dec 18, 2013 at 01:31:05PM +, Bingfeng Mei wrote:
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 206016)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2013-12-18 Bingfeng Mei b...@broadcom.com
+
+ PR tree-optimization/59544
+* tree-vect-stmts.c (perm_mask_for_reverse): Move before
This should be a tab instead of 8 spaces.
+ vectorizable_store. (vectorizable_store): Handle negative step.
Newline and tab after store., rather than space.
Property changes on: gcc/testsuite/gcc.target/i386/pr59544.c
___
Added: svn:executable
+ *
Please don't add such bogus property. Testcases aren't executable.
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (revision 206016)
+++ gcc/testsuite/ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2013-12-18 Bingfeng Mei b...@broadcom.com
+
+ PR tree-optimization/59544
+ * gcc.target/i386/pr59544.c: New test
Missing dot at the end of line.
+
2013-12-16 Jakub Jelinek ja...@redhat.com
PR middle-end/58956
Index: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c (revision 206016)
+++ gcc/tree-vect-stmts.c (working copy)
@@ -4859,6 +4859,25 @@ ensure_base_align (stmt_vec_info stmt_in
}
+/* Given a vector type VECTYPE returns the VECTOR_CST mask that implements
+ reversal of the vector elements. If that is impossible to do,
+ returns NULL. */
+
+static tree
+perm_mask_for_reverse (tree vectype)
+{
+ int i, nunits;
+ unsigned char *sel;
+
+ nunits = TYPE_VECTOR_SUBPARTS (vectype);
+ sel = XALLOCAVEC (unsigned char, nunits);
+
+ for (i = 0; i nunits; ++i)
+sel[i] = nunits - 1 - i;
+
+ return vect_gen_perm_mask (vectype, sel);
+}
+
/* Function vectorizable_store.
Check if STMT defines a non scalar data-ref (array/pointer/structure) that
@@ -4902,6 +4921,8 @@ vectorizable_store (gimple stmt, gimple_
vectree oprnds = vNULL;
vectree result_chain = vNULL;
bool inv_p;
+ bool negative = false;
+ tree offset = NULL_TREE;
vectree vec_oprnds = vNULL;
bool slp = (slp_node != NULL);
unsigned int vec_num;
@@ -4976,16 +4997,38 @@ vectorizable_store (gimple stmt, gimple_
if (!STMT_VINFO_DATA_REF (stmt_info))
return false;
- if (tree_int_cst_compare (loop nested_in_vect_loop_p (loop, stmt)
- ? STMT_VINFO_DR_STEP (stmt_info) : DR_STEP (dr),
- size_zero_node) 0)
+ negative = tree_int_cst_compare (loop nested_in_vect_loop_p (loop, stmt)
+? STMT_VINFO_DR_STEP (stmt_info) : DR_STEP (dr),
+size_zero_node) 0;
The formatting looks wrong, do:
negative
= tree_int_cst_compare (loop nested_in_vect_loop_p (loop, stmt)
? STMT_VINFO_DR_STEP (stmt_info) : DR_STEP (dr),
size_zero_node) 0;
instead.
+ if (negative ncopies 1)
{
if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
- negative step for store.\n);
+ multiple types with negative step.);
return false;
}
+ if (negative)
+{
+ gcc_assert (!grouped_store);
+ alignment_support_scheme = vect_supportable_dr_alignment (dr, false);
+ if (alignment_support_scheme != dr_aligned
+ alignment_support_scheme != dr_unaligned_supported)
Lots of places where you use 8 spaces instead of tab, please fix.
+offset = size_int (-TYPE_VECTOR_SUBPARTS (vectype) + 1);
+
if (store_lanes_p)
aggr_type = build_array_type_nelts (elem_type, vec_num * nunits);
else
@@ -5200,7 +5246,7 @@ vectorizable_store (gimple stmt, gimple_
dataref_ptr
= vect_create_data_ref_ptr (first_stmt, aggr_type,
Re: [PATCH, ARM, v2] Fix PR target/59142: internal compiler error while compiling OpenCV 2.4.7
On 19/12/13 17:40, Charles Baylis wrote: On 19 December 2013 16:13, Richard Earnshaw rearn...@arm.com wrote: OK with that change. Thanks. The bugzilla entry is targeted at 4.8, but it is a latent problem which affects 4.7 too. Is it ok for 4.8, and should it be considered for 4.7? Yes, provided it passes testing on those releases. R.
Re: [PATCH][ARM] Implement CRC32 intrinsics for AArch32 in ARMv8-A
On 19/12/13 17:58, Kyrill Tkachov wrote:
On 18/12/13 15:32, Ramana Radhakrishnan wrote:
On Tue, Dec 3, 2013 at 1:46 PM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
Ping?
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02351.html
Thanks,
Kyrill
Ok if no objections in 24 hours.
Thanks Ramana, I've committed it as r206128 together with this obvious change
that sets the conds attribute on the md pattern.
I just noticed that I committed the first version of the patch posted at:
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02250.html
instead of the second version posted at:
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02351.html
that was approved. The difference is only that the second one has underscores
under the variable names in arm_acle.h.
I've committed the attached patch to add them as obvious with r206149. Tested
arm-none-eabi on a model.
Sorry for the noise,
Kyrill
2013-12-20 Kyrylo Tkachov kyrylo.tkac...@arm.com
* config/arm/arm_acle.h: Add underscores before variables.
Kyrill
Ramana
On 26/11/13 09:44, Kyrill Tkachov wrote:
Ping?
Thanks,
Kyrill
On 19/11/13 17:04, Kyrill Tkachov wrote:
On 19/11/13 16:26, Joseph S. Myers wrote:
In any target header installed for user use, such as arm_acle.h, you
need
to be namespace-clean. In this case, that means you need to use
implementation-namespace identifiers such as __a, __b and __d in case
the
user has defined macros with names such as a, b and d (unless the ACLE
says that identifiers a, b and d are in the implementation's namespace
when this header is included, which would be a very odd thing for it to
do).
Hi Joseph,
Thanks for the catch. ACLE doesn't expect a,b,d to be in the
implementation
namespace. I've added underscores before them.
Made sure tests pass.
Revised patch attached.
How's this?
Kyrill
gcc/
2013-11-19 Kyrylo Tkachov kyrylo.tkac...@arm.com
* Makefile.in (TEXI_GCC_FILES): Add arm-acle-intrinsics.texi.
* config.gcc (extra_headers): Add arm_acle.h.
* config/arm/arm.c (FL_CRC32): Define.
(arm_have_crc): Likewise.
(arm_option_override): Set arm_have_crc.
(arm_builtins): Add CRC32 builtins.
(bdesc_2arg): Likewise.
(arm_init_crc32_builtins): New function.
(arm_init_builtins): Initialise CRC32 builtins.
(arm_file_start): Handle architecture extensions.
* config/arm/arm.h (TARGET_CPU_CPP_BUILTINS): Define
__ARM_FEATURE_CRC32.
Define __ARM_32BIT_STATE.
(TARGET_CRC32): Define.
* config/arm/arm-arches.def: Add armv8-a+crc.
* config/arm/arm-tables.opt: Regenerate.
* config/arm/arm.md (type): Add crc.
(crc_variant): New insn.
* config/arm/arm_acle.h: New file.
* config/arm/iterators.md (CRC): New int iterator.
(crc_variant, crc_mode): New int attributes.
* confg/arm/unspecs.md (UNSPEC_CRC32B, UNSPEC_CRC32H,
UNSPEC_CRC32W,
UNSPEC_CRC32CB, UNSPEC_CRC32CH, UNSPEC_CRC32CW): New unspecs.
* doc/invoke.texi: Document -march=armv8-a+crc option.
* doc/extend.texi: Document ACLE intrinsics.
* doc/arm-acle-intrinsics.texi: New.
gcc/testsuite
2013-11-19 Kyrylo Tkachov kyrylo.tkac...@arm.com
* lib/target-supports.exp (add_options_for_arm_crc): New
procedure.
(check_effective_target_arm_crc_ok_nocache): Likewise.
(check_effective_target_arm_crc_ok): Likewise.
* gcc.target/arm/acle/: New directory.
* gcc.target/arm/acle/acle.exp: New.
* gcc.target/arm/acle/crc32b.c: New test.
* gcc.target/arm/acle/crc32h.c: Likewise.
* gcc.target/arm/acle/crc32w.c: Likewise.
* gcc.target/arm/acle/crc32d.c: Likewise.
* gcc.target/arm/acle/crc32cb.c: Likewise.
* gcc.target/arm/acle/crc32ch.c: Likewise.
* gcc.target/arm/acle/crc32cw.c: Likewise.
* gcc.target/arm/acle/crc32cd.c: Likewise.
Index: gcc/config/arm/arm_acle.h
===
--- gcc/config/arm/arm_acle.h (revision 206132)
+++ gcc/config/arm/arm_acle.h (working copy)
@@ -34,60 +34,60 @@
#ifdef __ARM_FEATURE_CRC32
__extension__ static __inline uint32_t __attribute__ ((__always_inline__))
-__crc32b (uint32_t a, uint8_t b)
+__crc32b (uint32_t __a, uint8_t __b)
{
- return __builtin_arm_crc32b (a, b);
+ return __builtin_arm_crc32b (__a, __b);
}
__extension__ static __inline uint32_t __attribute__ ((__always_inline__))
-__crc32h (uint32_t a, uint16_t b)
+__crc32h (uint32_t __a, uint16_t __b)
{
- return __builtin_arm_crc32h (a, b);
+ return __builtin_arm_crc32h (__a, __b);
}
__extension__ static __inline uint32_t __attribute__ ((__always_inline__))
-__crc32w (uint32_t a, uint32_t b)
+__crc32w (uint32_t __a, uint32_t __b)
{
- return __builtin_arm_crc32w (a, b);
+ return __builtin_arm_crc32w (__a, __b);
}
#ifdef __ARM_32BIT_STATE
__extension__ static __inline uint32_t
[Patch] libgcov.c re-factoring
On Tue, Dec 17, 2013 at 7:48 AM, Teresa Johnson tejohn...@google.com wrote:
On Mon, Dec 16, 2013 at 2:48 PM, Xinliang David Li davi...@google.com wrote:
Ok -- gcov_write_counter and gcov_write_tag_length are qualified as
low level primitives for basic gcov format and probably should be kept
in gcov-io.c.
gcov_rewrite is petty much libgcov runtime implementation details so I
think it should be moved out. gcov_write_summary is not related to
gcov low level format either, neither is gcov_seek. Ok for them to be
moved?
After looking at these some more, with the idea that gcov-io.c should
encapsulate the lower level IO routines, then I think all of these
(including gcov_rewrite) should remain in gcov-io.c. I think
gcov_write_summary belongs there since all of the other gcov_write_*
are there. And gcov_seek and gcov_rewrite are both adjusting gcov_var
fields to affect the file IO operations. And there are currently no
references to gcov_var within libgcc/libgcov* files.
So I think we should leave the patch as-is. Honza, is the current
patch ok for trunk?
Ping. Patch inlined below.
Thanks,
Teresa
2013-12-11 Rong Xu x...@google.com
* gcc/gcov-io.c (gcov_var): Move from gcov-io.h.
(gcov_position): Ditto.
(gcov_is_error): Ditto.
(gcov_rewrite): Ditto.
* gcc/gcov-io.h: Refactor. Move gcov_var to gcov-io.h, and libgcov
only part to libgcc/libgcov.h.
* libgcc/libgcov-driver.c: Use libgcov.h.
(buffer_fn_data): Use xmalloc instead of malloc.
(gcov_exit_merge_gcda): Ditto.
* libgcc/libgcov-driver-system.c (allocate_filename_struct): Ditto.
* libgcc/libgcov.h: New common header files for libgcov-*.h.
* libgcc/libgcov-interface.c: Use libgcov.h
* libgcc/libgcov-merge.c: Ditto.
* libgcc/libgcov-profiler.c: Ditto.
* libgcc/Makefile.in: Add dependence to libgcov.h
Index: gcc/gcov-io.c
===
--- gcc/gcov-io.c (revision 205895)
+++ gcc/gcov-io.c (working copy)
@@ -36,6 +36,36 @@ static const gcov_unsigned_t *gcov_read_words (uns
static void gcov_allocate (unsigned);
#endif
+GCOV_LINKAGE struct gcov_var gcov_var;
+
+/* Save the current position in the gcov file. */
+static inline gcov_position_t
+gcov_position (void)
+{
+ gcc_assert (gcov_var.mode 0);
+ return gcov_var.start + gcov_var.offset;
+}
+
+/* Return nonzero if the error flag is set. */
+static inline int
+gcov_is_error (void)
+{
+ return gcov_var.file ? gcov_var.error : 1;
+}
+
+#if IN_LIBGCOV
+/* Move to beginning of file and initialize for writing. */
+GCOV_LINKAGE inline void
+gcov_rewrite (void)
+{
+ gcc_assert (gcov_var.mode 0);
+ gcov_var.mode = -1;
+ gcov_var.start = 0;
+ gcov_var.offset = 0;
+ fseek (gcov_var.file, 0L, SEEK_SET);
+}
+#endif
+
static inline gcov_unsigned_t from_file (gcov_unsigned_t value)
{
#if !IN_LIBGCOV
Index: gcc/gcov-io.h
===
--- gcc/gcov-io.h (revision 205895)
+++ gcc/gcov-io.h (working copy)
@@ -164,51 +164,7 @@ see the files COPYING3 and COPYING.RUNTIME respect
#ifndef GCC_GCOV_IO_H
#define GCC_GCOV_IO_H
-#if IN_LIBGCOV
-/* About the target */
-
-#if BITS_PER_UNIT == 8
-typedef unsigned gcov_unsigned_t __attribute__ ((mode (SI)));
-typedef unsigned gcov_position_t __attribute__ ((mode (SI)));
-#if LONG_LONG_TYPE_SIZE 32
-typedef signed gcov_type __attribute__ ((mode (DI)));
-typedef unsigned gcov_type_unsigned __attribute__ ((mode (DI)));
-#else
-typedef signed gcov_type __attribute__ ((mode (SI)));
-typedef unsigned gcov_type_unsigned __attribute__ ((mode (SI)));
-#endif
-#else
-#if BITS_PER_UNIT == 16
-typedef unsigned gcov_unsigned_t __attribute__ ((mode (HI)));
-typedef unsigned gcov_position_t __attribute__ ((mode (HI)));
-#if LONG_LONG_TYPE_SIZE 32
-typedef signed gcov_type __attribute__ ((mode (SI)));
-typedef unsigned gcov_type_unsigned __attribute__ ((mode (SI)));
-#else
-typedef signed gcov_type __attribute__ ((mode (HI)));
-typedef unsigned gcov_type_unsigned __attribute__ ((mode (HI)));
-#endif
-#else
-typedef unsigned gcov_unsigned_t __attribute__ ((mode (QI)));
-typedef unsigned gcov_position_t __attribute__ ((mode (QI)));
-#if LONG_LONG_TYPE_SIZE 32
-typedef signed gcov_type __attribute__ ((mode (HI)));
-typedef unsigned gcov_type_unsigned __attribute__ ((mode (HI)));
-#else
-typedef signed gcov_type __attribute__ ((mode (QI)));
-typedef unsigned gcov_type_unsigned __attribute__ ((mode (QI)));
-#endif
-#endif
-#endif
-
-
-#if defined (TARGET_POSIX_IO)
-#define GCOV_LOCKED 1
-#else
-#define GCOV_LOCKED 0
-#endif
-
-#else /* !IN_LIBGCOV */
+#ifndef IN_LIBGCOV
/* About the host */
typedef unsigned gcov_unsigned_t;
@@ -231,48 +187,10 @@ typedef unsigned HOST_WIDEST_INT gcov_type_unsigne
#define GCOV_LOCKED 0
#endif
-#endif /* !IN_LIBGCOV */
-
-/* In gcov we want function linkage to be static. In the
[C++ PATCH] Don't ICE on TYPE_BINFO (PR c++/59111)
We ICEd on invalid testcases with auto, because lookup_conversions
got template_type_parm as a parameter and the TYPE_BINFO didn't like
it. Fixed by checking for RECORD_OR_UNION_TYPE_P first.
Regtested/bootstrapped on x86_64-linux, ok for trunk?
2013-12-20 Marek Polacek pola...@redhat.com
PR c++/59111
cp/
* search.c (lookup_conversions): Return NULL_TREE if
!RECORD_OR_UNION_TYPE_P.
testsuite/
* g++.dg/cpp0x/pr59111.C: New test.
* g++.dg/cpp1y/pr59110.C: New test.
--- gcc/cp/search.c.mp 2013-12-20 15:04:51.296753249 +0100
+++ gcc/cp/search.c 2013-12-20 15:04:55.552768259 +0100
@@ -2506,7 +2506,7 @@ lookup_conversions (tree type)
tree list = NULL_TREE;
complete_type (type);
- if (!TYPE_BINFO (type))
+ if (!RECORD_OR_UNION_TYPE_P (type) || !TYPE_BINFO (type))
return NULL_TREE;
lookup_conversions_r (TYPE_BINFO (type), 0, 0,
--- gcc/testsuite/g++.dg/cpp0x/pr59111.C.mp 2013-12-20 14:44:16.871202015
+0100
+++ gcc/testsuite/g++.dg/cpp0x/pr59111.C2013-12-20 14:49:48.888403724
+0100
@@ -0,0 +1,5 @@
+// PR c++/59111
+// { dg-do compile { target c++11 } }
+
+auto foo(); // { dg-error type specifier without trailing return type }
+int i = foo(); // { dg-error cannot convert }
--- gcc/testsuite/g++.dg/cpp1y/pr59110.C.mp 2013-12-20 14:51:17.402737711
+0100
+++ gcc/testsuite/g++.dg/cpp1y/pr59110.C2013-12-20 14:58:08.988234451
+0100
@@ -0,0 +1,4 @@
+// PR c++/59110
+// { dg-options -std=c++1y }
+
+int i = *(auto*)0; // { dg-error cannot convert }
Marek
Re: [PATCH, libiberty] Remove malloc/realloc from demangler (was: Add a couple of missing casts)
On Fri, Dec 20, 2013 at 5:00 AM, Gary Benson gben...@redhat.com wrote: --- a/libiberty/ChangeLog +++ b/libiberty/ChangeLog @@ -1,3 +1,20 @@ +2013-12-20 Gary Benson gben...@redhat.com + + * cp-demangle.c (struct d_print_info): New fields + next_saved_scope, copy_templates, next_copy_template and + num_copy_templates. + (d_count_templates): New function. + (d_print_init): New parameter dc. + Estimate numbers of templates and scopes required. + (d_print_free): Removed function. + (cplus_demangle_print_callback): Allocate stack for + templates and scopes. Removed call to d_print_free. + (d_copy_templates): Removed function. + (d_save_scope): New function. + (d_get_saved_scope): Likewise. + (d_print_comp): Replace state saving/restoring code with + calls to d_save_scope and d_get_saved_scope. This is OK. Thanks for following up on this. Ian
Re: [RFC][gomp4] Offloading patches (3/3): Add invocation of target compiler
On 12/17/2013 12:42 PM, Michael V. Zolotukhin wrote: Hi everybody, Here is a patch 3/3: Add invocation of target compiler. + /* Run objcopy on TARGET_IMAGE_FILE_NAME. */ + buf1 = (char*) xmalloc (strlen (.data=.) + + strlen (OFFLOAD_IMAGE_SECTION_NAME) + 1); + if (!buf1) +return NULL; + sprintf (buf1, .data=%s, OFFLOAD_IMAGE_SECTION_NAME); + obstack_init (argv_obstack); + obstack_ptr_grow (argv_obstack, objcopy); + obstack_ptr_grow (argv_obstack, -B); + obstack_ptr_grow (argv_obstack, i386); + obstack_ptr_grow (argv_obstack, -I); + obstack_ptr_grow (argv_obstack, binary); + obstack_ptr_grow (argv_obstack, -O); + /* TODO: Properly handle 32-bit mode. */ + obstack_ptr_grow (argv_obstack, elf64-x86-64); + obstack_ptr_grow (argv_obstack, target_image_file_name); + obstack_ptr_grow (argv_obstack, --rename-section); + obstack_ptr_grow (argv_obstack, buf1); + obstack_ptr_grow (argv_obstack, NULL); + + argv = XOBFINISH (argv_obstack, const char **); This patch seems to make rather too many assumptions about host and target compilers. Certainly code like this can't go into target-independent code like lto-wrapper. Also, I'm not sure you can assume you'll get ELF files out of the OpenACC target compiler; I'd very prefer a solution that doesn't rely on objcopy. Bernd
Re: Improving mklog [was: Re: RFC Asan instrumentation control]
On 20/12/2013, 07:08 , Yury Gribov wrote: Ultimately, mklog ought to write the ChangeLog itself. We get rid of that headache, at least. How about this then? Updated mklog now adds 'New file'/'New test'/'Remove' when necessary. I did some tests with unified/context-diffed SVN and git and it worked as expected. I can do more testing if necessary. This is OK. Thanks. Diego.
[PATCH] Improve i?86/x86_64 prologue_and_epilogue for leaf functions (PR target/59501)
Hi!
Honza recently changed the i?86 backend, so that it often doesn't
do -maccumulate-outgoing-args by default on x86_64.
Unfortunately, on some of the here included testcases this regressed
quite a bit the generated code. As AVX vectors are used, the dynamic
realignment code needs to assume e.g. that some of them will need to be
spilled, and for -mno-accumulate-outgoing-args the code needs to set
need_drap early as well. But in when emitting the prologue/epilogue,
if need_drap is set, we don't perform the optimization for leaf functions
which have zero size stack frame, thus we end up with uselessly doing
dynamic stack realignment, setting up DRAP that nothing uses and later on
restore everything back.
This patch improves it, if the DRAP register isn't live at the start of
entry bb successor and we aren't going to realign the stack, we don't
need DRAP at all, and even if we need DRAP register, that can't be the sole
reason for doing stack realignment, the prologue code is able to set up DRAP
even without dynamic stack realignment.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2013-12-20 Jakub Jelinek ja...@redhat.com
PR target/59501
* config/i386/i386.c (ix86_save_reg): Don't return true for drap_reg
if !crtl-stack_realign_needed.
(ix86_finalize_stack_realign_flags): If drap_reg isn't live on entry
and stack_realign_needed will be false, clear drap_reg and need_drap.
Optimize leaf functions that don't need stack frame even if
crtl-need_drap.
* gcc.target/i386/pr59501-1.c: New test.
* gcc.target/i386/pr59501-1a.c: New test.
* gcc.target/i386/pr59501-2.c: New test.
* gcc.target/i386/pr59501-2a.c: New test.
* gcc.target/i386/pr59501-3.c: New test.
* gcc.target/i386/pr59501-3a.c: New test.
* gcc.target/i386/pr59501-4.c: New test.
* gcc.target/i386/pr59501-4a.c: New test.
* gcc.target/i386/pr59501-5.c: New test.
* gcc.target/i386/pr59501-6.c: New test.
--- gcc/config/i386/i386.c.jj 2013-12-19 13:35:23.0 +0100
+++ gcc/config/i386/i386.c 2013-12-20 11:44:14.389310804 +0100
@@ -9235,7 +9235,9 @@ ix86_save_reg (unsigned int regno, bool
}
}
- if (crtl-drap_reg regno == REGNO (crtl-drap_reg))
+ if (crtl-drap_reg
+ regno == REGNO (crtl-drap_reg)
+ crtl-stack_realign_needed)
return true;
return (df_regs_ever_live_p (regno)
@@ -10473,12 +10475,23 @@ ix86_finalize_stack_realign_flags (void)
return;
}
+ /* If drap has been set, but it actually isn't live at the start
+ of the function and !stack_realign, there is no reason to set it up. */
+ if (crtl-drap_reg !stack_realign)
+{
+ basic_block bb = ENTRY_BLOCK_PTR_FOR_FN (cfun)-next_bb;
+ if (! REGNO_REG_SET_P (DF_LR_IN (bb), REGNO (crtl-drap_reg)))
+ {
+ crtl-drap_reg = NULL_RTX;
+ crtl-need_drap = false;
+ }
+}
+
/* If the only reason for frame_pointer_needed is that we conservatively
assumed stack realignment might be needed, but in the end nothing that
needed the stack alignment had been spilled, clear frame_pointer_needed
and say we don't need stack realignment. */
if (stack_realign
- !crtl-need_drap
frame_pointer_needed
crtl-is_leaf
flag_omit_frame_pointer
@@ -10516,6 +10529,18 @@ ix86_finalize_stack_realign_flags (void)
}
}
+ /* If drap has been set, but it actually isn't live at the start
+of the function, there is no reason to set it up. */
+ if (crtl-drap_reg)
+ {
+ basic_block bb = ENTRY_BLOCK_PTR_FOR_FN (cfun)-next_bb;
+ if (! REGNO_REG_SET_P (DF_LR_IN (bb), REGNO (crtl-drap_reg)))
+ {
+ crtl-drap_reg = NULL_RTX;
+ crtl-need_drap = false;
+ }
+ }
+
frame_pointer_needed = false;
stack_realign = false;
crtl-max_used_stack_slot_alignment = incoming_stack_boundary;
--- gcc/testsuite/gcc.target/i386/pr59501-2.c.jj2013-12-20
12:02:08.754662741 +0100
+++ gcc/testsuite/gcc.target/i386/pr59501-2.c 2013-12-20 12:02:04.665668734
+0100
@@ -0,0 +1,5 @@
+/* PR target/59501 */
+/* { dg-do run } */
+/* { dg-options -O2 -mavx -maccumulate-outgoing-args } */
+
+#include pr59501-1.c
--- gcc/testsuite/gcc.target/i386/pr59501-1.c.jj2013-12-20
12:01:44.253781613 +0100
+++ gcc/testsuite/gcc.target/i386/pr59501-1.c 2013-12-20 12:12:26.715391613
+0100
@@ -0,0 +1,30 @@
+/* PR target/59501 */
+/* { dg-do run } */
+/* { dg-options -O2 -mavx -mno-accumulate-outgoing-args } */
+
+#define CHECK_H avx-check.h
+#define TEST avx_test
+
+#include CHECK_H
+
+typedef double V __attribute__ ((vector_size (32)));
+
+__attribute__((noinline, noclone)) V
+foo (double *x, unsigned *y)
+{
+ V r = { x[y[0]], x[y[1]], x[y[2]], x[y[3]] };
+ return r;
+}
+
+static void
+TEST (void)
+{
+ double a[16];
+
