Re: RFC: Gimple combine/folding interface
Andrew Pinski pins...@gmail.com wrote:
On Fri, Jul 19, 2013 at 5:09 PM, Andrew Pinski pins...@gmail.com
wrote:
I was creating a new gimple/folding interface and wanted some
opinions
on the interface.
typedef double_int (*nonzerobits_t)(tree var);
typedef tree (*valueizer_t)(tree var);
class gimple_combine
{
public:
gimple_combine(nonzerobits_t a, valueizer_t b) : nonzerobitsf(a),
valueizerv(b), allow_full_reassiocation(false) {}
gimple_combine() : nonzerobitsf(NULL), valueizerv(NULL),
allow_full_reassiocation(false) {}
gimple_combine(bool reas) : nonzerobitsf(NULL), valueizerv(NULL),
allow_full_reassiocation(reas) {}
tree build2 (location_t, enum tree_code, tree, tree, tree);
tree build1 (location_t, enum tree_code, tree, tree);
tree build3 (location_t, enum tree_code, tree, tree, tree, tree);
tree combine (gimple);
private:
nonzerobits_t nonzerobitsf;
valueizer_t valueizerv;
bool allow_full_reassiocation;
tree binary (location_t, enum tree_code, tree, tree, tree);
tree unary (location_t, enum tree_code, tree, tree);
tree ternary (location_t, enum tree_code, tree, tree, tree, tree);
};
Just a few comments before I return to work late in August. I like the way of
using a c++ object to store combiner flags as opposed to extra arguments. For
the optimizers I want to retain the ability to specify the desired result
(constant, single op, arbitrary) which also allows shortcutting some transforms.
I also want to retain the ability to return the combining result piecewise
without building trees, at least for results that fit a single gimple stmt.
bool replace_rhs_after_ssa_combine (gimple_stmt_iterator *, tree);
... Precisely to avoid this.
I'm not sure if you want to replace the fold-const.c workers with this
infrastructure?
Richard.
This is what I have so far and wonder if there is anything else I
should include.
This will be used to replace the folding code in fold-const.c and
gimple-fold.c.
I placed what I decided in a branch in git:
http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/gimple-ssa-combine.h;h=3d597291c1756cdf6e3318fd190ac70911ceb702;hb=d32468a31ab5e50fabab3a04303f6892ad890fd5
Note I won't have time to work on this again until the middle of August
or so.
The status of the current patch is that it is able to build libgcc but
there are some addition ICEs due to checking to make sure all of the
forwprop optimizations are pushed over to gimple_combine (since I
started this work on an older code base).
Thanks,
Andrew Pinski
Thanks,
Andrew Pinski
Write rights to commit to GCC
Hi, all! Earlier we (Samsung RD Institute Rus) proposed to implement OpenACC for GCC: http://gcc.gnu.org/ml/gcc/2013-05/msg00060.html We got our assignment form, now. I can attach signed and approved pdf, if needed. What should we do to get rights to create branch for OpenACC and submit a few patches to mainline? Like this one: http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00053.html -- Thanks, Evgeny.
Wrong code for i686 target with -O3 -flto
Hi All! Unfortunately now the compiler generates wrong code for i686 target when options -O3 and -flto are used. It started more than a month ago and reflected in PR57602. Such combination of options could be quite important at least from the performance point of view. Since there was almost no reaction on this PR I'd like to ask either to look at it in some observable future or revert the commit which is guilty for the issue. Thanks, Igor
Re: Write rights to commit to GCC
On 07/22/2013 10:07 AM, Evgeny Gavrin wrote: Hi, all! Earlier we (Samsung RD Institute Rus) proposed to implement OpenACC for GCC: http://gcc.gnu.org/ml/gcc/2013-05/msg00060.html We got our assignment form, now. I can attach signed and approved pdf, if needed. What should we do to get rights to create branch for OpenACC and submit a few patches to mainline? Like this one: http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00053.html I'm sorry, we're just being a little slow. You posted your patch a day before Americans were going away for their big holiday. Not a good excuse, I know, but probably true. Have a look in the MAINTAINERS file at the list of people who are responsible for the are you patched. Find the right person, and mail them directly. Remind them of your patch. Andrew.
dejagnu multilib options and dg-{add|additional-}options
Hello,
There are 42 test files (25 under gcc.dg) that specifies
{ dg-add-options bind_pic_locally }
in the regression testsuite. The procedure add_options_for_bind_pic_locally
from lib/target-supports.exp adds -fPIE or -fpie when -fPIC or -fpic is passed
respectively. But this is added before the dejagnu multilib options are added.
So when -fPIC is passed as a multilib option, -fPIE will be unset by -fPIC
(see gcc/common.opt). This should have been the behaviour since the patch
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01026.html that brings all -fPIC
-fPIE variants in a Negative loop, was applied.
I tried fixing this in dejagnu/target.exp by adding the multilib options before
the other options:
default_target_compile:
append add_flags [board_info $dest multilib_flags]
---
set add_flags [board_info $dest multilib_flags] $add_flags
and ran regressions for x86_64-unknown-linux-gnu before and after the change.
The only difference in the results after the change was 24 new PASSes which
are from the testcases which either use bind_pic_locally or that use -fno-pic.
(Interestingly, there are many test files that bind_pic_locally pass without
any issue before and after the change.)
I tend to think that the options added from the test files should always win.
Please correct me if I'm wrong. If I'm right, is dejagnu/target.exp is the
best place to fix this and the way it tried to fix? Any better suggestions?
Though this case is to do with -fPIC, I'm sure there are other options which
when they come as multilib options might have same issue with the some of the
options added by the test files or the default options.
Regards
VP
Re: RFC: Gimple combine/folding interface
On 07/20/2013 02:09 AM, Andrew Pinski wrote:
gimple_combine(bool reas) : nonzerobitsf(NULL), valueizerv(NULL),
allow_full_reassiocation(reas) {}
I think this constructor should be marked explicit.
--
Florian Weimer / Red Hat Product Security Team
Altera Nios II port submission
To the GCC Steering Committee, Mentor Graphics has submitted, and recently re-submitted an updated version, of a GCC backend port for the Altera Nios II architecture, currently on gcc-patches awaiting technical review [1]. We're proposing, upon port approval and commit to trunk, Sandra Loosemore and myself (Chung-Lin Tang), both of Mentor Graphics, as target maintainers. Thank you, Chung-Lin [1] http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00526.html http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00527.html http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00528.html
RE: Help with using multilib for Cilk Library
-Original Message- From: H.J. Lu [mailto:hjl.to...@gmail.com] Sent: Friday, July 19, 2013 6:56 PM To: Iyer, Balaji V Cc: Ian Lance Taylor; gcc@gcc.gnu.org Subject: Re: Help with using multilib for Cilk Library On Fri, Jul 19, 2013 at 3:53 PM, Iyer, Balaji V balaji.v.i...@intel.com wrote: -Original Message- From: Ian Lance Taylor [mailto:i...@google.com] Sent: Friday, July 19, 2013 6:26 PM To: Iyer, Balaji V Cc: gcc@gcc.gnu.org Subject: Re: Help with using multilib for Cilk Library On Fri, Jul 19, 2013 at 11:22 AM, Iyer, Balaji V balaji.v.i...@intel.com wrote: Hello Everyone, I am trying to use Multilib on Cilk Library. I looked at this website (http://www.airs.com/ian/configure/configure_8.html) and used libsanitizer and libgo as samples to model after. It is currently failing with the following error message: libtool: link: /export/users/my-files/b-gcc-multilib/./gcc/xg++ - B/export/users/my-files/b-gcc-multilib/./gcc/ -nostdinc++ -nostdinc++ - I/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/32/li bstdc++- v3/include/x86_64-unknown-linux-gnu -I/export/users/my-files/b-gcc- multilib/x86_64-unknown-linux-gnu/32/libstdc++-v3/include - I/export/users/my-files/gcc/libstdc++-v3/libsupc++ -I/export/users/my- files/gcc/libstdc++-v3/include/backward -I/export/users/my-files/gcc/libstdc++- v3/testsuite/util -L/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux- gnu/32/libstdc++-v3/src -L/export/users/my-files/b-gcc-multilib/x86_64- unknown-linux-gnu/32/libstdc++-v3/src/.libs -B/export/users/my-files/install- gcc-multilib/x86_64-unknown-linux-gnu/bin/ -B/export/users/my-files/install- gcc-multilib/x86_64-unknown-linux-gnu/lib/ -isystem /export/users/my- files/install-gcc-multilib/x86_64-unknown-linux-gnu/include -isystem /export/users/my-files/install-gcc-multilib/x86_64-unknown-linux-gnu/ sys- include -m32 -shared -nostdlib /usr/lib/../lib/crti.o /export/users/my-files/b- gcc-multilib/./gcc/32/crtbeginS.o .libs/bug.o .libs/cilk-abi.o .libs/cilk-abi-cilk- for.o .libs/cilk-abi-vla.o .libs/cilk-abi-vla-internal.o .libs/cilk_api.o .libs/cilk_fiber.o .libs/cilk_fiber-unix.o .libs/cilk_malloc.o .libs/c_reducers.o .libs/except-gcc.o .libs/frame_malloc.o .libs/full_frame.o .libs/global_state.o .libs/jmpbuf.o .libs/local_state.o .libs/metacall_impl.o .libs/os_mutex-unix.o .libs/os-unix.o .libs/pedigrees.o .libs/record-replay.o .libs/reducer_impl.o .libs/scheduler.o .libs/signal_node.o .libs/spin_mutex.o .libs/stats.o .libs/symbol_test.o .libs/sysdep-unix.o .libs/worker_mutex.o -Wl,-rpath - Wl,/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/lib stdc++- v3/src/.libs -Wl,-rpath -Wl,/export/users/my-files/install-gcc-multilib/lib/../lib64 -L/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/libs tdc++- v3/src/.libs -L/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux- gnu/libstdc++-v3/src -lpthread -ldl -L/export/users/my-files/b-gcc- multilib/x86_64-unknown-linux-gnu/32/libstdc++-v3/src -L/export/users/my- files/b-gcc-multilib/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.li bs - L/export/users/my-files/b-gcc-multilib/./gcc/32 -L/lib/../lib -L/usr/lib/../lib - L/export/users/my-files/b-gcc-multilib/./gcc /export/users/my-files/b-gcc- multilib/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so -lm -lc - lgcc_s /export/users/my-files/b-gcc-multilib/./gcc/32/crtendS.o /usr/lib/../lib/crtn.o -m32 -m32 -Wl,-soname -Wl,libcilkrts.so.5 -o .libs/libcilkrts.so.5.0.3511 /export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/libs tdc ++-v3/src/.libs/libstdc++.so: could not read symbols: File in wrong format collect2: error: ld returned 1 exit status make[4]: *** [libcilkrts.la] Error 1 make[4]: Leaving directory `/export/users/my-files/b-gcc-multilib/x86_64- unknown-linux-gnu/32/libcilkrts' make[3]: *** [multi-do] Error 1 make[3]: Leaving directory `/export/users/my-files/b-gcc From what it looks like, it is reading the 64 bit library for the 32 bit mode (or vice-versa). How do I fix this? I am also attaching my configure.ac and Makefile.am. Please note that it is not fully cleaned up (e.g. I have stuff commented out etc). Can someone please tell me what I am doing wrong? When building the 32bit libcillkrts you are linking against the 64-bit libstdc++. It's right there on your command line: /export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/libstd c++- v3/src/.libs/libstdc++.so. If that argument is needed at all, it needs to be /export/users/my-files/b-gcc- multilib/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/libstdc++ .so (note added /32 in there). I guess the question is where the argument is coming from. I must admit that I don't know. Is it in some environment variable?
Re: Write rights to commit to GCC
On 07/22/2013 03:07 AM, Evgeny Gavrin wrote: Hi, all! Earlier we (Samsung RD Institute Rus) proposed to implement OpenACC for GCC: http://gcc.gnu.org/ml/gcc/2013-05/msg00060.html We got our assignment form, now. I can attach signed and approved pdf, if needed. What should we do to get rights to create branch for OpenACC and submit a few patches to mainline? Like this one: http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00053.html See: Get an account on gcc.gnu.org/sourcware.org via this form, with my email as approving the request and gcc as the project. http://sourceware.org/cgi-bin/pdw/ps_form.cgi You'll want to review this page as well. http://gcc.gnu.org/svnwrite.html Note there were two good BOF sessions at the GNU Cauldron last week on accelerator support in GCC. I would strongly suggest you get in contact with folks from those sessions. Recordings of those sessions ought to show up relatively soon if they haven't already.
Re: GCC 4.8.1 MIPS
On Sun, 2013-07-21 at 10:24 -0700, Hendrik Greving wrote:
The enum opt_code in gcc/options.h looks like this;
enum opt_code
{
N_OPTS,
OPT_SPECIAL_unknown,
OPT_SPECIAL_ignore,
OPT_SPECIAL_program_name,
OPT_SPECIAL_input_file
};
I have a feeling I am missing something. Any idea what?
Thanks,
Regards,
Hendrik Greving
Which MIPS target are you building? I have not had any problems
building a MIPS cross compiler using the GCC 4.8.1 sources.
When I look at gcc/options.h in my build directory I see a very
(very) large opt_code enum:
enum opt_code
{
OPT = 0, /* -### */
/* OPT__CLASSPATH = 1, */ /* --CLASSPATH */
(lots of deleted lines)
OPT_fpic = 773,/* -fpic */
OPT_fpie = 774,/* -fpie */
(lots more deleted lines)
OPT_v = 1212, /* -v */
OPT_version = 1213,/* -version */
OPT_w = 1214, /* -w */
OPT_wrapper = 1215,/* -wrapper */
OPT_x = 1216, /* -x */
OPT_z = 1217, /* -z */
N_OPTS,
OPT_SPECIAL_unknown,
OPT_SPECIAL_ignore,
OPT_SPECIAL_program_name,
OPT_SPECIAL_input_file
};
You are not configuring/building directly in the source directory are
you? That doesn't work. options.h is built during the make process, it
looks like it didn't get made correctly for you. You might be missing
some tool (grep, awk, etc) that is needed when making option.h.
Steve Ellcey
sell...@mips.com
Re: Write rights to commit to GCC
On 07/22/2013 10:18 AM, Tobias Burnus wrote: Note there were two good BOF sessions at the GNU Cauldron last week on accelerator support in GCC. I would strongly suggest you get in contact with folks from those sessions. Recordings of those sessions ought to show up relatively soon if they haven't already. The only BoF I know about is Torvald's http://gcc.gnu.org/ml/gcc/2013-06/msg00226.html ; it's also the only one listed in the schedule/abstract at http://gcc.gnu.org/wiki/cauldron2013 Was the second one a follow up - or dit it focus on something else? BTW: The Cauldron 2013 recordings haven't shown up at YouTube, yet. The second was a follow-up, also led by Torvald. jeff
Re: Write rights to commit to GCC
Jeff Law wrote: On 07/22/2013 03:07 AM, Evgeny Gavrin wrote: Earlier we (Samsung RD Institute Rus) proposed to implement OpenACC for GCC: http://gcc.gnu.org/ml/gcc/2013-05/msg00060.html We got our assignment form, now. Great! I am looking forward to the implementation! I assume that you only target OpenACC support for C/C++ and not for Fortran, do you? Note there were two good BOF sessions at the GNU Cauldron last week on accelerator support in GCC. I would strongly suggest you get in contact with folks from those sessions. Recordings of those sessions ought to show up relatively soon if they haven't already. The only BoF I know about is Torvald's http://gcc.gnu.org/ml/gcc/2013-06/msg00226.html ; it's also the only one listed in the schedule/abstract at http://gcc.gnu.org/wiki/cauldron2013 Was the second one a follow up - or dit it focus on something else? BTW: The Cauldron 2013 recordings haven't shown up at YouTube, yet. Tobias
mach pass deleting instructions?
So I'm trying to get compare-and-branch working on my architecture. I
have the following patterns:
(define_expand cbranchsf4
[(set
(reg:CC CC_REGNO)
(compare:CC
(match_operand:SF 1 register_operand)
(match_operand:SF 2 register_operand)))
(set
(pc)
(if_then_else
(match_operator 0 comparison_operator
[(reg:CC CC_REGNO)
(const_int 0)]
)
(label_ref
(match_operand 3 ))
(pc))
)]
{}
)
(define_insn *test_sf
[(set
(reg:CC CC_REGNO)
(compare
(match_operand:SF 0 register_operand r)
(match_operand:SF 1 register_operand r)))]
fcmp %0, %1, %1
[(set_attr length 4)]
)
(define_insn *branch_condition:code
[(set
(pc)
(if_then_else
(condition
(reg:CC CC_REGNO)
(const_int 0))
(label_ref
(match_operand 0))
(pc)))]
bcondition:condition_code %0
[(set_attr length 4)]
)
The architecture is utterly traditional and the code above is stolen
pretty much intact from the moxie port (which I'm using as a reference
because it seems to be simple and easy to understand).
When I actually try to build stuff, however, the branch gets emitted but
then silently deleted during the mach pass. The debug tracing (as
produced by -da) doesn't say why; it just removes it. Naturally the
resulting program doesn't work. Example:
int cmp(float a, float b)
{ return ab; }
-
cmp:
push r6, lr
mov r6, #1 ; fast
fcmp r0, r1, r1
--- branch instruction to .L2 should be here
mov r6, #0 ; fast
.L2:
mov r0, r6 ; fast
pop r6, pc
Does anyone have any suggestions as to what I'm doing wrong, and where
to start looking? For example, what is the mach pass actually trying to
do, and is there any way to get it to give me more information about why
it's doing it?
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─
│ USER'S MANUAL VERSION 1.0: The information presented in this
│ publication has been carefully for reliability. --- anonymous
│ computer hardware manual
signature.asc
Description: OpenPGP digital signature
Re: Help forging a function_decl
Hi, On Wed, Jul 17, 2013 at 04:52:30PM -0300, Rodolfo Guilherme Wottrich wrote: Hello there, Please disregard this message in case it doesn't fit here. During compilation of a C file, I need to be able to create a global function definition, with whatever a body I may have forged. I mean, the function is not going to be present in the source file and I got to create the respective tree structure so it can be later gimplified and further compiled like any other function present in the source. I would only need to create that function in case some OpenMP directive is encountered, so my latest and unsuccessful try to do so was to create the tree structures for a FUNCTION_DECL and, say, a variable declared inside the scope of that function, after the parsing of a #pragma omp parallel in c_parser_omp_parallel() in file c-parser.c. I followed and tried to re-create the steps I found in the function create_omp_child_function(), in file omp-low.c, and http://gcc.gnu.org/onlinedocs/gccint/Function-Basics.html#Function-Basics. I think maybe the problem is that my new function doesn't go under rest_of_compilation, therefore it is not gimplified and obviously no code for it is generated. it's a bit difficult to say without knowing what you are doing and at what compilation stage you are doing it but perhaps you could try calling cgraph_add_new_function on the new decl? Also try reading the comment at the beginning of cgraphunit.c. Hope it helps, Martin Summarizing: I tried to forge a function in parsing time, but couldn't. What am I doing wrong, and how can one do such a thing? Maybe the problem is that I create no calls to that new function, what do you think? Anyway, I'm compiling with -O0, so I guess no optimization pass would remove my function just because it is not being used. Thanks in advance, --- Rodolfo Guilherme Wottrich Universidade Estadual de Campinas - Unicamp
Re: resurrecting automatic dependencies
Diego == Diego Novillo dnovi...@google.com writes: Diego Have you any plans for other build system work? Nope, no other plans. This was just an unfinished item from long ago that Cauldron inspired me to try to complete. Tom
Re: Help forging a function_decl
Hello, Thanks! I had solved the problem some days ago, and it was actually related to your answer. First, I hadn't used push_struct_function() to allocate storage for my new function. Second, I wasn't calling finish_function() after setting my tree, so it would not be further compiled (just like your suggestion, since cgraph_add_new_function is called inside it). As I was inside the scope of main(), I also needed to save the function context with push_function_context(), call finish_function() and then pop the context back. Third, the flag DECL_EXTERNAL for my function was being set, so even though my tree was going to be further compiled, the definition for my function_decl was to be found outside file scope. Now the problem is solved, but I still face an odd behavior: sometimes my function is output, sometimes not. Basically 50% of the times I compile my code, my function is simply not output. And when I try to debug gcc with gdb, it always fails. Any thoughts? Maybe I am missing something related to garbage collection or so... Not a clue. --- Rodolfo Guilherme Wottrich Universidade Estadual de Campinas - Unicamp 2013/7/22 Martin Jambor mjam...@suse.cz: Hi, On Wed, Jul 17, 2013 at 04:52:30PM -0300, Rodolfo Guilherme Wottrich wrote: Hello there, Please disregard this message in case it doesn't fit here. During compilation of a C file, I need to be able to create a global function definition, with whatever a body I may have forged. I mean, the function is not going to be present in the source file and I got to create the respective tree structure so it can be later gimplified and further compiled like any other function present in the source. I would only need to create that function in case some OpenMP directive is encountered, so my latest and unsuccessful try to do so was to create the tree structures for a FUNCTION_DECL and, say, a variable declared inside the scope of that function, after the parsing of a #pragma omp parallel in c_parser_omp_parallel() in file c-parser.c. I followed and tried to re-create the steps I found in the function create_omp_child_function(), in file omp-low.c, and http://gcc.gnu.org/onlinedocs/gccint/Function-Basics.html#Function-Basics. I think maybe the problem is that my new function doesn't go under rest_of_compilation, therefore it is not gimplified and obviously no code for it is generated. it's a bit difficult to say without knowing what you are doing and at what compilation stage you are doing it but perhaps you could try calling cgraph_add_new_function on the new decl? Also try reading the comment at the beginning of cgraphunit.c. Hope it helps, Martin Summarizing: I tried to forge a function in parsing time, but couldn't. What am I doing wrong, and how can one do such a thing? Maybe the problem is that I create no calls to that new function, what do you think? Anyway, I'm compiling with -O0, so I guess no optimization pass would remove my function just because it is not being used. Thanks in advance, --- Rodolfo Guilherme Wottrich Universidade Estadual de Campinas - Unicamp
TARGET_SECTION_TYPE_FLAGS
Is this hook still used? I don't see anything in the tool-chain referring to it. It is documented however. Regards, Thanks, Hendrik Greving
Re: RFC: Gimple combine/folding interface
On 07/21/2013 08:14 PM, Andrew Pinski wrote:
On Fri, Jul 19, 2013 at 5:09 PM, Andrew Pinski pins...@gmail.com wrote:
I was creating a new gimple/folding interface and wanted some opinions
on the interface.
typedef double_int (*nonzerobits_t)(tree var);
typedef tree (*valueizer_t)(tree var);
class gimple_combine
{
public:
gimple_combine(nonzerobits_t a, valueizer_t b) : nonzerobitsf(a),
IIRC, the zero/nonzero bits stuff in combine is mostly good at pruning
sign/zero extensions, eliminating bit masking in the low bits for alphas
and for cleaning up addressing of varargs arguments that were on the
stack. Yea, there are times when it can do other stuff, but that's my
recollection for what it was actually good at.
Before designing an interface which inherently includes that information
we should think hard about if it's valuable and if a tree combiner is
the right place.
I have high hopes that we can get the zero/sign extension elimination we
want by carrying VRP information and querying it.
As Richi has mentioned, we really want a folder we can call
independently of whatever pass we're in. Though I'd also like a folder
that can query for pass specific information if it's handy and useful.
One of the interesting things we're going to need to figure out is when
walking the use-def chains do we want to build the more complex
expression, then fold it, keeping the result if it's gimple. Or do we
want to work strictly with an exploded operator/operands represenation.
Jeff
Re: RFC: Gimple combine/folding interface
On Mon, Jul 22, 2013 at 01:36:17PM -0600, Jeff Law wrote:
Before designing an interface which inherently includes that
information we should think hard about if it's valuable and if a
tree combiner is the right place.
I have high hopes that we can get the zero/sign extension
elimination we want by carrying VRP information and querying it.
As Richi has mentioned, we really want a folder we can call
independently of whatever pass we're in. Though I'd also like a
folder that can query for pass specific information if it's handy
and useful.
For the preservation of VRP info we already have patch in process of review:
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00121.html
As for zero bits info, I've recently run into a case where having the zero
bits information preserved alongside of the VRP info could be helpful,
for optimizing away the vectorizer scalar loop for bound. If non-zero bits
computation proves or e.g. user asserts through if (val % 32)
__builtin_unreachable () or similar, even when the bounds of the loop aren't
constant, we could figure out that the number of iterations is a multiply of
vectorization factor and avoid computing that
So, perhaps let vrp{1,2} compute the vrp info and preserve (plus if not
specified just set nonzero bits to all ones), and this pass or other compute
the nonzero bits? Sign bit copies is just an int, perhaps also track that.
Jakub
GNU Tools Cauldron 2013 - Slides
I have uploaded all the slides I received to the wiki page. If you presented a talk and do not see your slides in http://gcc.gnu.org/wiki/cauldron2013, please fix the link yourself or let me know and I'll add them to the table (if you can fix the links yourself, you'll be doing me a big favour). I am in the process of uploading and processing videos, but I think it will take me at least another day or two to finish. I'll send an update after they are ready. Diego.
Git mirror changes
I'd like to make some changes to the GCC git-svn mirror. Specifically, I want to move all the SVN branches from remotes/ into heads/ and split the subdirectory branches (redhat, google, etc) into the individual branches. Should I leave the SVN branches as they are in remotes/ as well, for backward compatibility with existing users? Do we want to limit creation of non-personal branches via git? Any other thoughts? Jason
Re: Git mirror changes
On Mon, Jul 22, 2013 at 1:39 PM, Jason Merrill ja...@redhat.com wrote: I'd like to make some changes to the GCC git-svn mirror. Specifically, I want to move all the SVN branches from remotes/ into heads/ and split the subdirectory branches (redhat, google, etc) into the individual branches. Should I leave the SVN branches as they are in remotes/ as well, for backward compatibility with existing users? Do we want to limit creation of non-personal branches via git? What about distro/company branches that are in the git only or is that included in the personal branches? Thanks, Andrew Pinski Any other thoughts? Jason
Re: Git mirror changes
On 07/22/2013 02:39 PM, Jason Merrill wrote: I'd like to make some changes to the GCC git-svn mirror. Specifically, I want to move all the SVN branches from remotes/ into heads/ and split the subdirectory branches (redhat, google, etc) into the individual branches. Should I leave the SVN branches as they are in remotes/ as well, for backward compatibility with existing users? Do we want to limit creation of non-personal branches via git? No strong opinions. It might help if you gave a bit of rationale behind the proposed change though. Jeff
Re: Git mirror changes
On Mon, Jul 22, 2013 at 4:39 PM, Jason Merrill ja...@redhat.com wrote: I'd like to make some changes to the GCC git-svn mirror. Specifically, I want to move all the SVN branches from remotes/ into heads/ and split the subdirectory branches (redhat, google, etc) into the individual branches. Not sure if I completely understand, but would this change make it easier to deal with subdirectory branches? It's pretty horrid now. I don't fully understand what you are after with these changes, but they seem benign. Diego.
Re: TARGET_SECTION_TYPE_FLAGS
I was wrong. It is used in varasm.c:named_section. On Mon, Jul 22, 2013 at 11:22 AM, Hendrik Greving hendrik.greving.in...@gmail.com wrote: Is this hook still used? I don't see anything in the tool-chain referring to it. It is documented however. Regards, Thanks, Hendrik Greving
Re: Help with using multilib for Cilk Library
On Mon, Jul 22, 2013 at 9:27 AM, Iyer, Balaji V balaji.v.i...@intel.com wrote: -Original Message- From: H.J. Lu [mailto:hjl.to...@gmail.com] Sent: Friday, July 19, 2013 6:56 PM To: Iyer, Balaji V Cc: Ian Lance Taylor; gcc@gcc.gnu.org Subject: Re: Help with using multilib for Cilk Library On Fri, Jul 19, 2013 at 3:53 PM, Iyer, Balaji V balaji.v.i...@intel.com wrote: -Original Message- From: Ian Lance Taylor [mailto:i...@google.com] Sent: Friday, July 19, 2013 6:26 PM To: Iyer, Balaji V Cc: gcc@gcc.gnu.org Subject: Re: Help with using multilib for Cilk Library On Fri, Jul 19, 2013 at 11:22 AM, Iyer, Balaji V balaji.v.i...@intel.com wrote: Hello Everyone, I am trying to use Multilib on Cilk Library. I looked at this website (http://www.airs.com/ian/configure/configure_8.html) and used libsanitizer and libgo as samples to model after. It is currently failing with the following error message: libtool: link: /export/users/my-files/b-gcc-multilib/./gcc/xg++ - B/export/users/my-files/b-gcc-multilib/./gcc/ -nostdinc++ -nostdinc++ - I/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/32/li bstdc++- v3/include/x86_64-unknown-linux-gnu -I/export/users/my-files/b-gcc- multilib/x86_64-unknown-linux-gnu/32/libstdc++-v3/include - I/export/users/my-files/gcc/libstdc++-v3/libsupc++ -I/export/users/my- files/gcc/libstdc++-v3/include/backward -I/export/users/my-files/gcc/libstdc++- v3/testsuite/util -L/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux- gnu/32/libstdc++-v3/src -L/export/users/my-files/b-gcc-multilib/x86_64- unknown-linux-gnu/32/libstdc++-v3/src/.libs -B/export/users/my-files/install- gcc-multilib/x86_64-unknown-linux-gnu/bin/ -B/export/users/my-files/install- gcc-multilib/x86_64-unknown-linux-gnu/lib/ -isystem /export/users/my- files/install-gcc-multilib/x86_64-unknown-linux-gnu/include -isystem /export/users/my-files/install-gcc-multilib/x86_64-unknown-linux-gnu/ sys- include -m32 -shared -nostdlib /usr/lib/../lib/crti.o /export/users/my-files/b- gcc-multilib/./gcc/32/crtbeginS.o .libs/bug.o .libs/cilk-abi.o .libs/cilk-abi-cilk- for.o .libs/cilk-abi-vla.o .libs/cilk-abi-vla-internal.o .libs/cilk_api.o .libs/cilk_fiber.o .libs/cilk_fiber-unix.o .libs/cilk_malloc.o .libs/c_reducers.o .libs/except-gcc.o .libs/frame_malloc.o .libs/full_frame.o .libs/global_state.o .libs/jmpbuf.o .libs/local_state.o .libs/metacall_impl.o .libs/os_mutex-unix.o .libs/os-unix.o .libs/pedigrees.o .libs/record-replay.o .libs/reducer_impl.o .libs/scheduler.o .libs/signal_node.o .libs/spin_mutex.o .libs/stats.o .libs/symbol_test.o .libs/sysdep-unix.o .libs/worker_mutex.o -Wl,-rpath - Wl,/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/lib stdc++- v3/src/.libs -Wl,-rpath -Wl,/export/users/my-files/install-gcc-multilib/lib/../lib64 -L/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/libs tdc++- v3/src/.libs -L/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux- gnu/libstdc++-v3/src -lpthread -ldl -L/export/users/my-files/b-gcc- multilib/x86_64-unknown-linux-gnu/32/libstdc++-v3/src -L/export/users/my- files/b-gcc-multilib/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.li bs - L/export/users/my-files/b-gcc-multilib/./gcc/32 -L/lib/../lib -L/usr/lib/../lib - L/export/users/my-files/b-gcc-multilib/./gcc /export/users/my-files/b-gcc- multilib/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so -lm -lc - lgcc_s /export/users/my-files/b-gcc-multilib/./gcc/32/crtendS.o /usr/lib/../lib/crtn.o -m32 -m32 -Wl,-soname -Wl,libcilkrts.so.5 -o .libs/libcilkrts.so.5.0.3511 /export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/libs tdc ++-v3/src/.libs/libstdc++.so: could not read symbols: File in wrong format collect2: error: ld returned 1 exit status make[4]: *** [libcilkrts.la] Error 1 make[4]: Leaving directory `/export/users/my-files/b-gcc-multilib/x86_64- unknown-linux-gnu/32/libcilkrts' make[3]: *** [multi-do] Error 1 make[3]: Leaving directory `/export/users/my-files/b-gcc From what it looks like, it is reading the 64 bit library for the 32 bit mode (or vice-versa). How do I fix this? I am also attaching my configure.ac and Makefile.am. Please note that it is not fully cleaned up (e.g. I have stuff commented out etc). Can someone please tell me what I am doing wrong? When building the 32bit libcillkrts you are linking against the 64-bit libstdc++. It's right there on your command line: /export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/libstd c++- v3/src/.libs/libstdc++.so. If that argument is needed at all, it needs to be /export/users/my-files/b-gcc- multilib/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/libstdc++ .so (note added /32 in there). I guess the question is where the argument is coming
Re: Git mirror changes
On 07/22/2013 04:59 PM, Diego Novillo wrote: On Mon, Jul 22, 2013 at 4:39 PM, Jason Merrill ja...@redhat.com wrote: I'd like to make some changes to the GCC git-svn mirror. Specifically, I want to move all the SVN branches from remotes/ into heads/ and split the subdirectory branches (redhat, google, etc) into the individual branches. Not sure if I completely understand, but would this change make it easier to deal with subdirectory branches? It's pretty horrid now. That's the idea. Jason
Re: atomic support for LEON3 platform
Recently i am working on the atomic support for RTEMS. Our basic idea is to integrate the C11 atomic API into RTEMS. we have integrated the stdatomic.h into newlib which is used by RTEMS. And when we test the atomic ops on LEON3 platform (an important platform for RTEMS to test and verify SMP support) it posted that there is no defined functions like __atomic_fetch_add_xx. And this is because of SPARC V7-V8 lacks of compare and swap instruction., GCC also does not support those build in ops. But for LEON3 it is a special case, it has its own casa instruction to support compare_and_swap function. So i wonder whether gcc can consider support LEON3 build in atomic ops. Sure, patches to that effect are welcome. This will need to be coordinated with binutils because the assembler will very likely reject the instructions if it is passed -Av8 as is currently done for LEON/LEON3. As a matter of fact, I just installed a patch to add basic LEON3 support on the trunk so almost everything is already there as far as the compiler is concerned. -- Eric Botcazou
Re: Git mirror changes
On Mon, Jul 22, 2013 at 5:37 PM, Jason Merrill ja...@redhat.com wrote: On 07/22/2013 04:59 PM, Diego Novillo wrote: Not sure if I completely understand, but would this change make it easier to deal with subdirectory branches? It's pretty horrid now. That's the idea. Excellent! In that case, I'm all for it. Diego.
Re: Help forging a function_decl
I run gcc with -fdump-tree-all-raw and found out that all dumps until filename.c.013t.cfg are fine, but every time it fails, my function disappears from filename.c.016t.ompexp onwards. Remembering: I want it to happen every time there's a #pragma omp parallel in the source, so I put my implementation right after the end of c_parser_omp_parallel(), in file c-parser.c. Again, thank you for the help. --- Rodolfo Guilherme Wottrich Universidade Estadual de Campinas - Unicamp 2013/7/22 Rodolfo Guilherme Wottrich rgw...@gmail.com: Hello, Thanks! I had solved the problem some days ago, and it was actually related to your answer. First, I hadn't used push_struct_function() to allocate storage for my new function. Second, I wasn't calling finish_function() after setting my tree, so it would not be further compiled (just like your suggestion, since cgraph_add_new_function is called inside it). As I was inside the scope of main(), I also needed to save the function context with push_function_context(), call finish_function() and then pop the context back. Third, the flag DECL_EXTERNAL for my function was being set, so even though my tree was going to be further compiled, the definition for my function_decl was to be found outside file scope. Now the problem is solved, but I still face an odd behavior: sometimes my function is output, sometimes not. Basically 50% of the times I compile my code, my function is simply not output. And when I try to debug gcc with gdb, it always fails. Any thoughts? Maybe I am missing something related to garbage collection or so... Not a clue. --- Rodolfo Guilherme Wottrich Universidade Estadual de Campinas - Unicamp 2013/7/22 Martin Jambor mjam...@suse.cz: Hi, On Wed, Jul 17, 2013 at 04:52:30PM -0300, Rodolfo Guilherme Wottrich wrote: Hello there, Please disregard this message in case it doesn't fit here. During compilation of a C file, I need to be able to create a global function definition, with whatever a body I may have forged. I mean, the function is not going to be present in the source file and I got to create the respective tree structure so it can be later gimplified and further compiled like any other function present in the source. I would only need to create that function in case some OpenMP directive is encountered, so my latest and unsuccessful try to do so was to create the tree structures for a FUNCTION_DECL and, say, a variable declared inside the scope of that function, after the parsing of a #pragma omp parallel in c_parser_omp_parallel() in file c-parser.c. I followed and tried to re-create the steps I found in the function create_omp_child_function(), in file omp-low.c, and http://gcc.gnu.org/onlinedocs/gccint/Function-Basics.html#Function-Basics. I think maybe the problem is that my new function doesn't go under rest_of_compilation, therefore it is not gimplified and obviously no code for it is generated. it's a bit difficult to say without knowing what you are doing and at what compilation stage you are doing it but perhaps you could try calling cgraph_add_new_function on the new decl? Also try reading the comment at the beginning of cgraphunit.c. Hope it helps, Martin Summarizing: I tried to forge a function in parsing time, but couldn't. What am I doing wrong, and how can one do such a thing? Maybe the problem is that I create no calls to that new function, what do you think? Anyway, I'm compiling with -O0, so I guess no optimization pass would remove my function just because it is not being used. Thanks in advance, --- Rodolfo Guilherme Wottrich Universidade Estadual de Campinas - Unicamp
New GCC port/retarget
After porting/re-targeting a very old backend (own target) to GCC 4.8.1, I am getting this when compiling: Fixing headers into /path/to/objdir/gcc/include-fixed for moon-unknown-none target No forbidden identifiers defined by this target echo timestamp stmp-fixinc make[2]: *** No rule to make target `../../../../src/tools/fsf_4_8_1/gcc/ginclude/stdint.h', needed by `stmp-int-hdrs'. Stop. make[2]: Leaving directory `/path/to/objdir/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/path/to/objdir' make: *** [all] Error 2 Anybody knows what that is? Regards, Hendrik Greving
Re: New GCC port/retarget
On Mon, Jul 22, 2013 at 8:28 PM, Hendrik Greving hendrik.greving.in...@gmail.com wrote: After porting/re-targeting a very old backend (own target) to GCC 4.8.1, I am getting this when compiling: Fixing headers into /path/to/objdir/gcc/include-fixed for moon-unknown-none target No forbidden identifiers defined by this target echo timestamp stmp-fixinc make[2]: *** No rule to make target `../../../../src/tools/fsf_4_8_1/gcc/ginclude/stdint.h', needed by `stmp-int-hdrs'. Stop. make[2]: Leaving directory `/path/to/objdir/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/path/to/objdir' make: *** [all] Error 2 Anybody knows what that is? Set use_gcc_stdint in gcc/config.gcc. Make sure your tm.h file defines INT8_TYPE and friends one way or another. Look at config/glibc-stdint.h. Ian
[Bug fortran/57922] [OOP] Memory leak with allocatable polymorphics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57922 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from janus at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #2) (In reply to janus from comment #1) On x86_64-unknown-linux-gnu, I can confirm the problem with 4.7 and 4.8. However, the leak seems to be gone in the latest trunk version: Which is not very surprising as the finalization code should also take care of this. See PR37336. I believe r199643 was the enabling commit. Right. Although the test case does not actually deal with finalization, but rather involves polymorphic deallocation (i.e. PR 46321). Anyway, closing as fixed.
[Bug fortran/46321] [OOP] Polymorphic deallocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46321 --- Comment #7 from janus at gcc dot gnu.org --- Comment 0 has apparently been fixed by r199643. One should check whether the remaining items are also handled correctly already (in particular comments 1 - 3).
[Bug target/57952] New: AVX/AVX2 no ymm registries used in a trivial reduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57952
Bug ID: 57952
Summary: AVX/AVX2 no ymm registries used in a trivial reduction
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vincenzo.innocente at cern dot ch
in this quite trivial benchmark
gcc does not generate avx/avx2 instruction using ymm registries
c++ -Ofast -S polyAVX.cpp -march=core-avx2 ; grep -c ymm polyAVX.s
0
clang++ -Ofast -S polyAVX.cpp -march=core-avx2 ; grep -c ymm polyAVX.s
73
same for -march=corei7-avx
gcc version 4.9.0 20130718 (experimental) [trunk revision 201034] (GCC)
with obvious speed effect…
c++ -Ofast polyAVX.cpp -march=core-avx2 ; time ./a.out
0.508u 0.000s 0:00.50 100.0%0+0k 0+0io 1pf+0w
clang++ -Ofast polyAVX.cpp -march=core-avx2 ; time ./a.out
0.257u 0.000s 0:00.25 100.0%0+0k 0+0io 1pf+0w
cat polyAVX.cpp
//templatetypename T
typedef float T;
inline T polyHorner(T y) {
return T(0x2.p0) + y * (T(0x2.p0) + y * (T(0x1.p0) + y * (T(0x5.55523p-4) +
y * (T(0x1.5554dcp-4) + y * (T(0x4.48f41p-8) + y * T(0xb.6ad4p-12)) ;
}
int main() {
bool ret=true;
float s =0;
for (int k=0; k!=100; ++k) {
float c = 1.f/100.f;
for (int i=1; i1001; ++i) s+= polyHorner((float(i)+1.f)*c);
}
ret = s!=0;
return ret ? 0 : -1;
}
[Bug fortran/56937] Unnecessarily temporary with array-vector assignments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56937 --- Comment #12 from Mikael Morin mikael at gcc dot gnu.org --- (In reply to Thomas Koenig from comment #11) A big part is fixed now. Do people think that the case of comment#8 is worth fixing? At least it's worth having one PR open for it IMO.
[Bug c++/57880] cp/parser.c: 6 * missing break ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57880 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Ed?
[Bug c++/57888] using non-type template parameter in constexpr function for non static data member intializer segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57888 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- This is a Dup. *** This bug has been marked as a duplicate of bug 57827 ***
[Bug c++/57827] compiler segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57827 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||plasmahh at gmx dot net --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 57888 has been marked as a duplicate of this bug. ***
[Bug c++/57892] g++ internal compiler error: in expand_expr_real_1, at expr.c:9122 while attempting to brace-initialize a dynamically allocated array class member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57892 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.8.0, 4.8.1, 4.9.0 Resolution|--- |FIXED --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- In fact works with 4.8.0 too.
[Bug c++/57897] Target x86_64-w64-mingw32 failed with '-mno-fentry isn't compatible with SEH'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57897 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Kai, can you have a look?
[Bug c++/57901] [4.8/4.9 Regression] Cannot call-by-value such that class has non-trivial (constexpr) move constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57901 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-22 Known to work||4.7.3 Summary|[C++11][constexpr] Cannot |[4.8/4.9 Regression] Cannot |call-by-value such that |call-by-value such that |class has non-trivial |class has non-trivial |(constexpr) move|(constexpr) move |constructor |constructor Ever confirmed|0 |1 Known to fail||4.8.0, 4.8.1, 4.9.0 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- We may have a Dup of this.
[Bug c++/57926] Atomic functions broken with C++ but not C?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57926 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- CC-ing Andrew for the array-pointer issue. Or is this a more general C++ front-end issue?
[Bug c++/57938] Compiler breaks when a lambda expression is used as a default parameter in a constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57938 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Known to work||4.8.0, 4.8.1, 4.9.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC|francesco.nidito at gmail dot com | --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Works fine in 4.8.0 too.
[Bug c++/57930] missing destructor call after thrown exception in C++11 list initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57930 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jwakely.gcc at gmail dot com --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Maybe we have another one too, but isn't this PR57510?
[Bug lto/57602] [4.9 Regression] Runfails for several C/C++ benchmarks from spec2000 for i686 with -flto after r199422
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57602 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-22 Target Milestone|--- |4.9.0 Summary|Runfails for several C/C++ |[4.9 Regression] Runfails |benchmarks from spec2000|for several C/C++ |for i686 with -flto after |benchmarks from spec2000 |r199422 |for i686 with -flto after ||r199422 Ever confirmed|0 |1 --- Comment #7 from Uroš Bizjak ubizjak at gmail dot com --- Confirmed, a 4.9 regression.
[Bug c++/57948] internal compiler error: in initialize_reference, at cp/call.c:9285
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57948 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-22 Ever confirmed|0 |1
[Bug c++/57946] internal compiler error: Segmentation fault in int_fits_type_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57946 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-22 Ever confirmed|0 |1
[Bug c++/57947] internal compiler error: Segmentation fault using extended initializer lists without -std=c++11 or -std=gnu++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57947 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-07-22 Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- I can't reproduce this (with or without the std::) Looks like the error message doesn't match the code (line #8 ?!?)
[Bug c++/57930] missing destructor call after thrown exception in C++11 list initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57930 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- Yes, that's probably the one I'm thinking of. *** This bug has been marked as a duplicate of bug 57510 ***
[Bug c++/57510] initializer_list memory leak
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57510 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||mmehlich at semanticdesigns dot co ||m --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- *** Bug 57930 has been marked as a duplicate of this bug. ***
[Bug fortran/37336] Fortran 2003: Finish derived-type finalization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 Bug 37336 depends on bug 55207, which changed state. Bug 55207 Summary: Automatic deallocation of variables declared in the main program http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55207 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug fortran/55207] Automatic deallocation of variables declared in the main program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55207 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from janus at gcc dot gnu.org --- I think this PR has been fixed by r199643.
[Bug fortran/57762] [4.9 Regression] Memory leak in gfortran.dg/class_array_7.f03 after revision 200084
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57762 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #3 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #2) If it makes you happy, the following plugs the memory leak: --- a/gcc/testsuite/gfortran.dg/class_array_7.f03 +++ b/gcc/testsuite/gfortran.dg/class_array_7.f03 @@ -56,2 +56,3 @@ program main if (trim (print_type (a, a)) .ne. a is base_type) call abort + deallocate (a) end program main ... Well, it makes valgrind happy. And it certainly does not hurt to fix the test case in this regard. Is there any connection with PR55207 - Automatic deallocation of variables declared in the main program? Yes, sure. However, I don't directly see how the leak is related to r200084 ...
[Bug c++/57793] [4.7/4.8/4.9 Regression] ICE with bitfields in get_bit_range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57793 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED CC|jason at gcc dot gnu.org | Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- Thus this is fixed for 4.9.0.
[Bug libstdc++/57925] discrete_distribution can be improved to O(1) per sampling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57925 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-07-22 Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Handling this.
[Bug inline-asm/57950] wrong line numbers in error messages for inline assembler statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57950 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Andreas Schwab from comment #2) GCC uses the line number of the start of the asm statement, so line 8 is correct. Correct as expected but not as desired. This is what Clang prints by comparison: asm-line-number.c:3:12: error: invalid instruction mnemonic 'foo' __asm__ (foo\nfoo); ^ inline asm:1:2: note: instantiated into assembly here foo ^~~ asm-line-number.c:3:18: error: invalid instruction mnemonic 'foo' __asm__ (foo\nfoo); ^ inline asm:2:1: note: instantiated into assembly here foo ^~~ asm-line-number.c:10:7: error: invalid instruction mnemonic 'foo' foo ^ inline asm:1:2: note: instantiated into assembly here foo ^~~ 3 errors generated. It seems difficult to get there without an integrated assembler, but GCC could at least provide better locations to GAS (and GAS understand and print column numbers), so we could get: asm-line-number.c: Assembler messages: asm-line-number.c:3:12: Error: no such instruction: `foo' asm-line-number.c:3:18: Error: no such instruction: `foo' asm-line-number.c:10:7: Error: no such instruction: `foo' Any editor worth its salt would jump to the correct line and column in the sources.
[Bug inline-asm/57950] wrong line numbers in error messages for inline assembler statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57950 --- Comment #4 from Frank Heckenbach f.heckenb...@fh-soft.de --- (In reply to Manuel López-Ibáñez from comment #3) (In reply to Andreas Schwab from comment #2) GCC uses the line number of the start of the asm statement, so line 8 is correct. Correct as expected but not as desired. And it would only explain the latter messages, not the former ones reported as lines 3 and 4. This is what Clang prints by comparison: asm-line-number.c:3:12: error: invalid instruction mnemonic 'foo' __asm__ (foo\nfoo); ^ inline asm:1:2: note: instantiated into assembly here foo ^~~ asm-line-number.c:3:18: error: invalid instruction mnemonic 'foo' __asm__ (foo\nfoo); ^ inline asm:2:1: note: instantiated into assembly here foo ^~~ asm-line-number.c:10:7: error: invalid instruction mnemonic 'foo' foo ^ inline asm:1:2: note: instantiated into assembly here foo ^~~ 3 errors generated. It seems difficult to get there without an integrated assembler, but GCC could at least provide better locations to GAS (and GAS understand and print column numbers), so we could get: asm-line-number.c: Assembler messages: asm-line-number.c:3:12: Error: no such instruction: `foo' asm-line-number.c:3:18: Error: no such instruction: `foo' asm-line-number.c:10:7: Error: no such instruction: `foo' Any editor worth its salt would jump to the correct line and column in the sources. The clang output is indeed very nice, though to me, the wrong line numbers (at least in the presence of \n) are the more serious problem than the lack of column numbers.
[Bug testsuite/57591] gcc-4.8 libbacktrace btest failure on Linux ppc64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57591 --- Comment #4 from acrux acrux at linuxmail dot org --- same failure with gcc-4.8-20130718
[Bug libstdc++/57920] [c++11] Linux: std::random_device reads too much from /dev/urandom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57920 --- Comment #5 from Frank Heckenbach f.heckenb...@fh-soft.de --- (In reply to Paolo Carlini from comment #1) Note that in 4.8.x and mainline for modern x86 and x86_64 targets we don't use /dev/urandom at all, we use __x86_rdrand. In general, the idea is that more targets should use hardware support for random numbers and /dev/urandom become just a fall back. I'm not sure changing fread to read it's worth the trouble, and the change, since we are not talking about a regression, would not go in 4.7.x branch anyway. Are you on x86 / x86_64 or something else? I use an AMD (Thuban) in 32 bit mode. This processor core is ~3 years old and AFAICS it doesn't support rdrand. So even if newer AMDs do supports it (which I don't know), I guess it's fair to say that for some more years there will be processors around which don't, and in this case I assume gcc falls back to /dev/urandom.
[Bug libstdc++/57920] [c++11] Linux: std::random_device reads too much from /dev/urandom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57920 --- Comment #6 from Frank Heckenbach f.heckenb...@fh-soft.de --- (In reply to Paolo Carlini from comment #3) I'm going to attach a patchlet which does the trick (fread - read) for me. Note I'm on purpose disabling the use of __builtin_ia32_rdrand32_step on my x86_64 machine, the undef would not be in the committed patch of course. It would be great if you could test the change on your machines (in 4.7.x just change random.h, no need to rebuild) and confirm that everything is fine. I did the equivalent change to /usr/include/c++/4.7/bits/random.h and it works for me, thanks.
[Bug libstdc++/57920] [c++11] Linux: std::random_device reads too much from /dev/urandom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57920 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com --- Agreed, let's just commit the improvement. If/when you become aware of ways to extend the use of builtins to other CPUs / targets, please let me know, thanks.
[Bug inline-asm/57950] wrong line numbers in error messages for inline assembler statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57950 --- Comment #6 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Andreas Schwab from comment #5) The error messages are all generated by the assembler which knows nothing about the source file. It knows the locations passed by GCC. (And it could know the column also, if gas supported that). GCC seem to be passing wrong line numbers.
[Bug inline-asm/57950] wrong line numbers in error messages for inline assembler statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57950 --- Comment #5 from Andreas Schwab sch...@linux-m68k.org --- The error messages are all generated by the assembler which knows nothing about the source file.
[Bug inline-asm/57950] wrong line numbers in error messages for inline assembler statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57950 --- Comment #7 from Andreas Schwab sch...@linux-m68k.org --- There is no way to know how the newline was written.
[Bug libstdc++/57953] no C++11 compliant std::ios_base::failure found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57953 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to unixway.drive+gcc from comment #0) §27.5.3 states that ios_base defines ... a class failure derived from system_error. And http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2011 states this isn't implemented yet.
[Bug c++/57892] g++ internal compiler error: in expand_expr_real_1, at expr.c:9122 while attempting to brace-initialize a dynamically allocated array class member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57892 --- Comment #4 from morell at cs dot atu.edu --- Thank you! On 07/22/2013 04:55 AM, paolo.carlini at oracle dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57892 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.8.0, 4.8.1, 4.9.0 Resolution|--- |FIXED --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- In fact works with 4.8.0 too.
[Bug libstdc++/57953] New: no C++11 compliant std::ios_base::failure found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57953 Bug ID: 57953 Summary: no C++11 compliant std::ios_base::failure found Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: unixway.drive+gcc at gmail dot com §27.5.3 states that ios_base defines ... a class failure derived from system_error. The only std::ios_base::failure I see in a libstdc++ is a pre-C++11 ones. $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/gcc/src/gcc-4.8.1/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl --disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu --disable-install-libiberty --disable-multilib --disable-libssp --disable-werror --enable-checking=release Thread model: posix gcc version 4.8.1 (GCC) $ g++ -std=c++11 test.cpp test.cpp: In function ‘int main(int, char**)’: test.cpp:10:18: error: ‘class std::ios_base::failure’ has no member named ‘code’ std::cout e.code().value() std::endl;
[Bug c++/57880] cp/parser.c: 6 * missing break ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57880 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Maybe he is simply traveling or unable to read email, don't you think? Still, if you want to send a patch to the mailing list, of course it's fine. For a quicker review, I would recommend CC-ing Jason and adding [C++ Patch] to the subject line. Thanks.
[Bug c++/54853] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54853 --- Comment #4 from Leonid Volnitsky leonid at volnitsky dot com --- I can not reproduce this ICE with 4.8.1. It is ok to close this bug.
[Bug c++/57926] Atomic functions broken with C++ but not C?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57926
--- Comment #4 from Andrew Macleod amacleod at redhat dot com ---
Short answer.. I'm not a sure, but it appears to be a g++ thing.
I looks like g++ is using ARRAY_TYPE instead of POINTER_TYPE. the 4.8 branch
does the same thing, but it does seem odd to me. That means anywhere in the
compiler that uses POINTER_TYPE_P() is not going to trigger true for an array
in c++...
Going back to gcc 4.6 which only had __sync operations, the same issue exists:
x220:/home/compilers/gcc-4_6-branch/build/gcccat t.cpp
long int Mutex[1];
int AcquireLogMutex(void)
{
return(__sync_fetch_and_add(Mutex, 1));
}
int main() {}
x220:/home/compilers/gcc-4_6-branch/build/gcc./cc1plus t.cpp
int AcquireLogMutex()
t.cpp:5:38: error: incompatible type for argument 1 of ‘__sync_fetch_and_add’
Im stunned this has never been tripped over.
I can fix it in the atomic code, but I don't know what that means to other
languages since I've never paid attention to the detailed meaning of ARRAY_TYPE
vs POINTER_TYPE. Just allowing the ARRAY_TYPE objects to pass the existing
atomic tests of POINTER_TYPE_P or POINTER_TYPE appears to generate all the
correct code and errors for atomics, so I guess thats is the way to go...?
there are only a couple of places the check is made.
[Bug c++/57905] braced-init-list allowed in default template-argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57905 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-22 Ever confirmed|0 |1
[Bug middle-end/57811] Wasted work in find_reloads()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57811 --- Comment #4 from Po-Chun Chang pchang9 at cs dot wisc.edu --- Patch sent to gcc-patches@ http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00930.html
[Bug rtl-optimization/57812] Wasted work in computed_jump_p()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57812 --- Comment #3 from Po-Chun Chang pchang9 at cs dot wisc.edu --- Patch sent to gcc-patches@ http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00931.html
[Bug lto/57602] [4.9 Regression] Runfails for several C/C++ benchmarks from spec2000 for i686 with -flto after r199422
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57602 --- Comment #8 from Dmitry Gorbachev d.g.gorbachev at gmail dot com --- And a testcase from PR57879 fails with -O2 / -O1 and -flto, it happens when building GCC itself.
[Bug lto/57879] GCC with -flto generates invalid code for genmddeps program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57879 Dmitry Gorbachev d.g.gorbachev at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Dmitry Gorbachev d.g.gorbachev at gmail dot com --- . *** This bug has been marked as a duplicate of bug 57602 ***
[Bug middle-end/57806] Wasted work in propagate_nothrow()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57806 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #3 from Jeffrey A. Law law at redhat dot com --- Fixed on mainline.
[Bug middle-end/57790] Wasted work in can_move_insns_across()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57790 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #3 from Jeffrey A. Law law at redhat dot com --- Fixed on mainline.
[Bug middle-end/57809] Wasted work in omega_eliminate_red()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57809 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #8 from Jeffrey A. Law law at redhat dot com --- Fixed on mainline.
[Bug fortran/57803] Wasted work in gfc_build_dummy_array_decl()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57803 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #3 from Jeffrey A. Law law at redhat dot com --- Fixed on mainline.
[Bug libstdc++/57920] [c++11] Linux: std::random_device reads too much from /dev/urandom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57920 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug c++/57880] cp/parser.c: 6 * missing break ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57880 --- Comment #3 from David Binderman dcb314 at hotmail dot com --- (In reply to Paolo Carlini from comment #2) Ed? He's had eleven days to think about it and said nothing. I'd be happy to supply the obvious patch.
[Bug target/57949] [powerpc64] Structure parameter alignment issue with vector extensions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57949 --- Comment #1 from Bill Schmidt wschmidt at gcc dot gnu.org --- The front end identifies the structure as having the correct alignment. From the 001t.tu dump: @2846 record_type name: @2857size: @127 algn: 128 tag : struct flds: @2858 @2857 identifier_node strg: slngt: 1 @2858 field_decl name: @2870type: @16 scpe: @2846 srcp: vec-abi.c:3 chain: @2871 size: @22 algn: 64 bpos: @20 @2870 identifier_node strg: mlngt: 1 @2871 field_decl name: @2882type: @2817scpe: @2846 srcp: vec-abi.c:3 size: @19 algn: 128 bpos: @19 @2882 identifier_node strg: vlngt: 1
[Bug target/57954] New: AVX missing vxorps (zeroing) before vcvtsi2s %edx, slow down AVX code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57954
Bug ID: 57954
Summary: AVX missing vxorps (zeroing) before vcvtsi2s %edx,
slow down AVX code
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vincenzo.innocente at cern dot ch
in the following benchmark performances w/o vectorization are poor wrt to
expectations
I find out this is due to non zeroing a register before using it
c++ -O2 -S polyAVX.cpp -mavx
as -v --64 -o polyAVX.o polyAVX.s
GNU assembler version 2.23.1 (x86_64-redhat-linux-gnu) using BFD version (GNU
Binutils) 2.23.1
c++ -O2 polyAVX.o -march=corei7-avx ; time ./a.out
53896530759
15.418u 0.000s 0:15.43 99.8%0+0k 0+0io 1pf+0w
patch polyAVX.s
49a50
vxorps %xmm0,%xmm0,%xmm0
patching file polyAVX.s
as -v --64 -o polyAVX.o polyAVX.s
GNU assembler version 2.23.1 (x86_64-redhat-linux-gnu) using BFD version (GNU
Binutils) 2.23.1
c++ -O2 polyAVX.o -march=corei7-avx ; time ./a.out
10340756863
2.958u 0.000s 0:02.96 99.6%0+0k 0+0io 1pf+0w
I am sure there are many other cases like this.
gcc version 4.9.0 20130718 (experimental) [trunk revision 201034] (GCC)
cat polyAVX.cpp
//templatetypename T
typedef float T;
inline T polyHorner(T y) {
return T(0x2.p0) + y * (T(0x2.p0) + y * (T(0x1.p0) + y * (T(0x5.55523p-4) +
y * (T(0x1.5554dcp-4) + y * (T(0x4.48f41p-8) + y * T(0xb.6ad4p-12)) ;
}
#include x86intrin.h
#includeiostream
volatile unsigned long long rdtsc() {
unsigned int taux=0;
return __rdtscp(taux);
}
int main() {
long long t=0;
bool ret=true;
float s =0;
for (int k=0; k!=100; ++k) {
float c = 1.f/1000.f;
t -=rdtsc();
for (int i=1; i1001; ++i) s+= polyHorner((float(i)+float(k))*c);
t+=rdtsc();
}
ret = s!=0;
std::cout t std::endl;
return ret ? 0 : -1;
}
[Bug c++/52816] [C++11] Access to private members inside decltype in the signature of a member template causes access control error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52816 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Let's add the testcase and close the issue as fixed for 4.8.0.
[Bug c++/54853] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54853 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-07-22 Ever confirmed|0 |1 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Please provide a reduced testcase, normally ~20 lines are more than enough for C++ front-end issues: http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction
[Bug target/57949] [powerpc64] Structure parameter alignment issue with vector extensions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57949 --- Comment #2 from Bill Schmidt wschmidt at gcc dot gnu.org --- The wrong code is introduced during expand. vs.m is computed as mem(plus(virtual-incoming-args, 72)) with the pad at offset 80, v[0..1] at offset 88, and v[2..3] at offset 96. All are shown as having alignment 8. vs.m should have been placed at offset 80. After loading these into virtual regs with DI mode, they are stored at offsets 0, 8, 16, 24 from virtual-stack-vars, which is given an alignment of 128. Later the vector is loaded with V4SF mode.
[Bug lto/57602] [4.9 Regression] Runfails for several C/C++ benchmarks from spec2000 for i686 with -flto after r199422
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57602 Dmitry Gorbachev d.g.gorbachev at gmail dot com changed: What|Removed |Added CC||d.g.gorbachev at gmail dot com --- Comment #9 from Dmitry Gorbachev d.g.gorbachev at gmail dot com --- *** Bug 57879 has been marked as a duplicate of this bug. ***
[Bug fortran/57762] [4.9 Regression] Memory leak in gfortran.dg/class_array_7.f03 after revision 200084
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57762 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Mon Jul 22 17:02:26 2013 New Revision: 201137 URL: http://gcc.gnu.org/viewcvs?rev=201137root=gccview=rev Log: 2013-07-22 Tobias Burnus bur...@net-b.de PR fortran/57762 * gfortran.dg/class_array_7.f03: Fix memory leak. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/class_array_7.f03
[Bug fortran/57762] [4.9 Regression] Memory leak in gfortran.dg/class_array_7.f03 after revision 200084
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57762 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org --- The memory leak is now plugged - hence, close it as FIXED.
[Bug c++/52816] [C++11] Access to private members inside decltype in the signature of a member template causes access control error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52816 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug c++/54853] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54853 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Known to work||4.8.1 Resolution|--- |FIXED --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- Ok, thanks.
[Bug c++/57926] Atomic functions broken with C++ but not C?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57926 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- Thanks a lot Andrew. I think it makes sense to CC Jason.
[Bug fortran/57906] Coarray components: Assignment optimized away (gfortran.dg/coarray/lib_realloc_1.f90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57906 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- FIXED on the trunk (4.9)
[Bug fortran/52052] [Coarray] Properly handle coarray components of derived types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52052 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #0) Intrinsic assignment: Contrary to normal allocatable components, no reallocation is allowed. The programmer guarantees that the shape and type parameters are suitable. Patches: - http://gcc.gnu.org/ml/fortran/2013-06/msg00137.html (committed) - http://gcc.gnu.org/ml/fortran/2013-07/msg00041.html (committed)
[Bug fortran/52052] [Coarray] Properly handle coarray components of derived types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52052 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Mon Jul 22 17:28:56 2013 New Revision: 201140 URL: http://gcc.gnu.org/viewcvs?rev=201140root=gccview=rev Log: 2013-07-22 Tobias Burnus bur...@net-b.de PR fortran/57906 PR fortran/52052 * class.c (gfc_build_class_symbol): Set coarray_comp. * trans-array.c (structure_alloc_comps): For coarrays, directly use the data pointer address. 2013-07-22 Tobias Burnus bur...@net-b.de PR fortran/57906 PR fortran/52052 * coarray/lib_realloc_1.f90: Permit optimization. * gfortran.dg/coarray_31.f90: New. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/coarray/lib_realloc_1.f90
[Bug fortran/57906] Coarray components: Assignment optimized away (gfortran.dg/coarray/lib_realloc_1.f90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57906 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Mon Jul 22 17:28:56 2013 New Revision: 201140 URL: http://gcc.gnu.org/viewcvs?rev=201140root=gccview=rev Log: 2013-07-22 Tobias Burnus bur...@net-b.de PR fortran/57906 PR fortran/52052 * class.c (gfc_build_class_symbol): Set coarray_comp. * trans-array.c (structure_alloc_comps): For coarrays, directly use the data pointer address. 2013-07-22 Tobias Burnus bur...@net-b.de PR fortran/57906 PR fortran/52052 * coarray/lib_realloc_1.f90: Permit optimization. * gfortran.dg/coarray_31.f90: New. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/coarray/lib_realloc_1.f90
[Bug c++/57947] internal compiler error: Segmentation fault using extended initializer lists without -std=c++11 or -std=gnu++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57947
--- Comment #2 from Craig Schroeder cas43 at cs dot stanford.edu ---
Unfortunately that is because I tried cleaning up the test case some more after
reducing it down. How about this:
namespace std
{
template class _E class initializer_list {};
template int N struct D {D(std::initializer_listint) {}};
D0 d{1, 2, 3};
}
[Bug c++/57947] internal compiler error: Segmentation fault using extended initializer lists without -std=c++11 or -std=gnu++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57947 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Keywords||ice-on-invalid-code Status|WAITING |NEW --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Ok, thanks.
[Bug target/57787] Wasted work in ix86_valid_target_attribute_inner_p() and ix86_pad_returns()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57787 --- Comment #2 from Po-Chun Chang pchang9 at cs dot wisc.edu --- Patch sent to gcc-patches@ http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00941.html
