They are currently just "integer", but the dot version is fast_compare.
This makes them all "add". Later we should introduce attributes to
distinguish e.g. addc and adde (which aren't currently handled as
separate instructions at all, only in groups).
2014-05-22 Segher Boessenkool
gcc/
They are currently just "integer", but the dot version is fast_compare.
This makes them all "logical".
2014-05-22 Segher Boessenkool
gcc/
* config/rs6000/rs6000.md (type): Add "logical". Delete
"fast_compare".
(dot): Adjust comment.
(andsi3_mc, *andsi3_interna
They are often labeled just "integer" currently. Fix that.
Also handle shift properly in those scheduling descriptions that
neglected it.
2014-05-22 Segher Boessenkool
gcc/
* config/rs6000/440.md (ppc440-integer): Include shift without
dot.
(ppc440-compare): Include
This uses the attribute "size" to specify the differences:
idiv -> div size=32
ldiv -> div size=64
It could use "dot" as well, but the current code doesn't handle that.
2014-05-22 Segher Boessenkool
gcc/
* config/rs6000/rs6000.md (type): Delete "idiv", "ldiv". Add
On Fri, May 23, 2014 at 09:30:12AM +0400, Yury Gribov wrote:
> > much better would be just dlsym a couple of
> > interesting symbols to verify that libasan.so.1 is ahead
> > of libc.so.6, libstdc++.so.6, libpthread.so.0 (whatever else
> > you want to override).
>
> One problem with dlsym() that I'
This uses the attributes "size" and "dot" to specify the differences:
imul3 -> mul size=8
imul2 -> mul size=16
imul -> mul size=32
lmul -> mul size=64
imul_compare -> mul size=32 dot=yes
lmul_compare -> mul size=64 dot=yes
2014-05-22 Segher Boesse
This uses the attribute "size" to specify the differences:
insert_word -> insert size=32
insert_dword -> insert size=64
It could use "dot" as well, but the current code doesn't handle that.
2014-05-22 Segher Boessenkool
gcc/
* config/rs6000/rs6000.md (type): Delete
This is for the legacy integer multiply-accumulate instructions.
Quite a mouthful, and "mulhw" is also a terrible name since we already
have a machine instruction called exactly that. Hence "halfmul".
Also fixes the titan automaton description for this.
2014-05-22 Segher Boessenkool
gcc/
Get rid of the one huge line. Group and order things a bit. Further
changes will follow so this doesn't try to make it perfect.
The rest of this patch series reduces the number of different integer
instruction types by folding many together using attributes "size"
(the data size), "dot" (does th
On 05/22/2014 11:54 PM, Jakub Jelinek wrote:
> Kostya, guess you should ignore the vDSO.
Right, we didn't encounter this problem when testing on our kernels.
I'll cook a patch for this.
> much better would be just dlsym a couple of
> interesting symbols to verify that libasan.so.1 is ahead
> o
Hi Richard,
Thanks for the review.
Let me get back to you on the results of -fsched-pressure --param
sched-pressure-algorithm=2 options.
Yes, we start the EBB with pressure 0.
Thanks,
Jaydeep
-Original Message-
From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
Sent: 22 May 20
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> On Wed, May 21, 2014 at 3:00 AM, Thomas Preud'homme
> wrote:
> >
> > Updated ChangeLogs:
> >
> > *** gcc/ChangeLog ***
> >
> > 2014-05-20 Thomas Preud'homme
> >
> > PR tree-optimization/54733
> > * tree-ssa-math-opts.
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> On Fri, Apr 4, 2014 at 7:48 AM, Thomas Preud'homme
> wrote:
> >
> > Please find attached an updated patch.
>
> This is ok.
Commited. It was already tested against trunk since it was on the same branch as
my patch for PR54733 which I re
On Fri, 23 May 2014, Janne Blomqvist wrote:
> On Thu, May 22, 2014 at 6:36 PM, Hans-Peter Nilsson wrote:
> > This patch broke build for newlib targets; you need AC_DEFINE
> > clauses for those in the "if-then"-leg where you patched the
> > "else"-leg.
>
> Do I?
The way that configure-clause is wr
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61215
The patch was bootstrapped on x86/x86-64 and arm and tested on
x86/x86-64.
Unfortunately I did not managed to decrease the test significantly to
include it into the testsuite.
Committed as rev. 210828 into
Ping?
thanks,
Cong
On Wed, Apr 30, 2014 at 1:28 PM, Cong Hou wrote:
> Thank you for reminding me the omp possibility. Yes, in this case my
> pattern is incorrect, because I assume all aliases will be resolved by
> alias checks, which may not be true with omp.
>
> LOOP_VINFO_NO_DATA_DEPENDENCIE
Also missing documentation in invoke.texi? Other than that, ok.
David
On Thu, May 22, 2014 at 5:00 PM, Paul Pluzhnikov wrote:
> On Thu, May 22, 2014 at 4:36 PM, Sriraman Tallam wrote:
>> This patch is pending review for trunk. Please see if this is ok to
>> commit to google/gcc-4_8 branch. Plea
On Thu, May 22, 2014 at 4:36 PM, Sriraman Tallam wrote:
> This patch is pending review for trunk. Please see if this is ok to
> commit to google/gcc-4_8 branch. Please see this for more details:
>
> https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01215.html
+mld-pie-copyrelocs
+Target Report Var(ix
This patch is pending review for trunk. Please see if this is ok to
commit to google/gcc-4_8 branch. Please see this for more details:
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01215.html
Patch attached.
Thanks
Sri
Index: config/i386/i386.c
===
On Thu, 22 May 2014, Richard Sandiford wrote:
> I can't hope to match Maciej's reply on the details, but like he says,
> my understanding was that this:
>
> > ADD.D $f20, $f10, $f10
> > MOV.D $f18, $f20
> > SWC1 $f20, 0($sp)
> > MTC1 $2, $f20
> > LWC1 $f20, 0($sp)
> > ADD.D $f16, $f18, $f20
> > (
On Thu, May 22, 2014 at 2:33 PM, Kai Tietz wrote:
> Hello,
>
> This patch avoids for sibling-tail-calls the use of pseudo-register. Instead
> it uses for load of memory-address the accumulator-register. By this we
> avoid that IRA/LRA need to choose a register. So we reduce register-pressure.
If a loop's header count is less than iteration count, the iteration
estimation is apparently incorrect for this loop. Thus disable
unrolling of such loops.
Testing on going. OK for trunk if test pass?
Thanks,
Dehao
gcc/ChangeLog:
2014-05-21 Dehao Chen
* cfgloop.h (expected_loop_iter
Hello,
This patch avoids for sibling-tail-calls the use of pseudo-register. Instead
it uses for load of memory-address the accumulator-register. By this we avoid
that IRA/LRA need to choose a register. So we reduce register-pressure.
The accumulator-register is always a valid register on tai
Matthew Fortune writes:
>> Let's step back a bit. Please explain which case you were trying to
>> handle with the specs patch. Rejecting -msingle-float -mfp64 seems
>> fine.
>> Fiddling with the specs to stop that combination reaching the assembler
>> is what seemed odd.
>
> So, perhaps this is
I think these asserts will be used by gcov-tool. So I prefer to change
them to gcov_nonruntime_assert(). I'll merge them in my new gcov-tool
patch before submitting (waiting for honaz's ok).
Thanks,
-Rong
On Thu, May 22, 2014 at 7:09 AM, Teresa Johnson wrote:
> On Thu, Jan 16, 2014 at 2:41 PM,
On Thu, May 22, 2014 at 6:36 PM, Hans-Peter Nilsson wrote:
> On Mon, 19 May 2014, Janne Blomqvist wrote:
>> Hello,
>>
>> some systems such as GNU Hurd, don't define PATH_MAX at all, and on
>> some other systems many syscalls apparently work for paths longer than
>> PATH_MAX. Thus GFortran shouldn'
The following patch fixes a GCC testsuite test failure on aarch64
after committing the 1st patch for PR60969.
The patch was bootstrapped and tested on x86/x86-64.
Committed as rev. 210825 for gcc-4.9 branch and rev. 210824 for trunk.
2014-05-22 Vladimir Makarov
PR rtl-optimizat
Hi,
This patch adds a small improvement about sibling tail-calls. We producing
without that patch an useless load of address into register.
See for this the testcases sibcall-1.c, and sibcall-3.c. The testcase
sibcall-3.c is just an demonstration about other missed opportunities for
sibcall t
From: tschwinge
gcc/c-family/
* c-common.h (c_omp_sharing_predetermined, c_omp_remap_decl):
Remove prototypes.
(record_types_used_by_current_var_decl): Move prototype to where
it belongs.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@210823
138bc75d-0d0
From: tschwinge
gcc/ada/
* gcc-interface/utils.c (DEF_FUNCTION_TYPE_0, DEF_FUNCTION_TYPE_6)
(DEF_FUNCTION_TYPE_7, DEF_FUNCTION_TYPE_8)
(DEF_FUNCTION_TYPE_VAR_5): Cosmetic fixes.
gcc/
* builtin-types.def: Simplify examples for DEF_FUNCTION_TYPE_*.
Yuri, this comes from yours
http://llvm.org/viewvc/llvm-project?view=revision&revision=205308
Could you please take a look?
On Thu, May 22, 2014 at 11:54 PM, Jakub Jelinek wrote:
> On Thu, May 22, 2014 at 09:43:01PM +0200, Paolo Carlini wrote:
>> Hi,
>>
>> On 05/22/2014 09:15 PM, Jakub Jelinek wr
On Thu, May 22, 2014 at 09:43:01PM +0200, Paolo Carlini wrote:
> Hi,
>
> On 05/22/2014 09:15 PM, Jakub Jelinek wrote:
> >Do you have LD_PRELOAD set in the environment?
> I don't.
> >If not, can you cut'n'paste the large-func-test-1.exe command line
> >and run it with the given LD_LIBRARY_PATH unde
Hi!
On Tue, 8 Oct 2013 21:52:40 +0200, Jakub Jelinek wrote:
> --- gcc/c/c-parser.c (.../trunk) (revision 203241)
> +++ gcc/c/c-parser.c (.../branches/gomp-4_0-branch) (revision 203287)
> +c_parser_omp_clause_thread_limit (c_parser *parser, tree list)
> [...]
> + location_t num_teams_loc
Hi,
On 05/22/2014 09:15 PM, Jakub Jelinek wrote:
Do you have LD_PRELOAD set in the environment?
I don't.
If not, can you cut'n'paste the large-func-test-1.exe command line and
run it with the given LD_LIBRARY_PATH under ldd? Jakub
Sure. This is what I get:
linux-vdso.so.1 (0x7ff
Thomas Schwinge wrote:
> On Thu, 22 May 2014 17:02:08 +0100, Gary Benson wrote:
> > Thomas Schwinge wrote:
> > > In GCC, I'm consistenly seeing the following new failure:
> > >
> > > ./test-demangle <
> > > ../../../source/libiberty/testsuite/demangle-expected
> > > FAIL at line 4350, op
On Thu, May 22, 2014 at 09:03:44PM +0200, Paolo Carlini wrote:
> Hi,
>
> On 05/22/2014 09:02 PM, Jakub Jelinek wrote:
> >On Thu, May 22, 2014 at 08:38:31PM +0200, Paolo Carlini wrote:
> >>Hi,
> >>
> >>On 05/22/2014 01:03 PM, Jakub Jelinek wrote:
> >>>On Thu, May 22, 2014 at 02:26:19PM +0400, Konst
On 05/22/2014 02:26 PM, Paolo Carlini wrote:
Good. I wanted to ask about that. Also, by copy instead of by value,
right? Because the Standard always talks about copy (likewise clang).
Yes.
Right, thanks. I'm probably going to add it, at some point. Me, I was looking
for something not using C
Hi,
On 05/22/2014 09:02 PM, Jakub Jelinek wrote:
On Thu, May 22, 2014 at 08:38:31PM +0200, Paolo Carlini wrote:
Hi,
On 05/22/2014 01:03 PM, Jakub Jelinek wrote:
On Thu, May 22, 2014 at 02:26:19PM +0400, Konstantin Serebryany wrote:
FAIL: c-c++-common/asan/asan-interface-1.c -O0 execution t
On Thu, May 22, 2014 at 08:38:31PM +0200, Paolo Carlini wrote:
> Hi,
>
> On 05/22/2014 01:03 PM, Jakub Jelinek wrote:
> >On Thu, May 22, 2014 at 02:26:19PM +0400, Konstantin Serebryany wrote:
> >>FAIL: c-c++-common/asan/asan-interface-1.c -O0 execution test
> >Is that before or after r21
Hi,
On 05/22/2014 01:03 PM, Jakub Jelinek wrote:
On Thu, May 22, 2014 at 02:26:19PM +0400, Konstantin Serebryany wrote:
FAIL: c-c++-common/asan/asan-interface-1.c -O0 execution test
Is that before or after r210743?
Can't reproduce the above (note, not bootstrapped compiler, just
--disable-b
Hi,
On 05/22/2014 08:13 PM, Jason Merrill wrote:
On 05/22/2014 04:27 AM, Paolo Carlini wrote:
lambda-ice7.C:8:9: error: cannot capture by value ‘a’ of incomplete type
‘A’
[=](){a;};
^
All the carets in your mail are in the first column; is this one in
the right place for you?
It would be def
On Thu, May 22, 2014 at 04:07:38PM +0200, Jakub Jelinek wrote:
> 2014-05-22 Jakub Jelinek
>
> * sanitizer.def (BUILT_IN_ASAN_REPORT_LOAD_N,
> BUILT_IN_ASAN_REPORT_STORE_N): New.
> * asan.c (struct asan_mem_ref): Change access_size type to
> HOST_WIDE_INT.
> (asan_m
On 05/22/2014 04:27 AM, Paolo Carlini wrote:
lambda-ice7.C:8:9: error: cannot capture by value ‘a’ of incomplete type
‘A’
[=](){a;};
^
All the carets in your mail are in the first column; is this one in the
right place for you?
Let's not print out the expression, we've been moving away from
> >It won't be so easy, because struct function is really built at
> >relatively convoluted
> >places within frontend before cgraph node is assigned to them (I tried
> >that few years
> >back).
>
> Well, just call cgraph create node from struct Funktion allocation.
That will make uninstantiated t
On Thu, May 22, 2014 at 2:01 AM, Kirill Yukhin wrote:
> Hello,
> On 20 May 08:24, H.J. Lu wrote:
>> ABI alignment should be sufficient for correctness. Bigger alignments
>> are supposed to give better performance. Can you try this patch on
>> HSW and SLM to see if it has any impact on performance
On Thu, 22 May 2014, Matthew Fortune wrote:
> I'm not confident that it would be the right thing to change this
> behaviour. While the test is slightly weird in that the compiler generates
> code that touches a -ffixed-reg this is just an ABI test.
>
> == Taken from MIPS ABI supplement ==
> Only
On Thu, 22 May 2014, Matthew Fortune wrote:
> GCC is saving too much of the callee-saved registers when single-precision
> values are live in them but this is historic behaviour. The code which
> controls this is very complex and I'd be worried about breaking it. The
> fix would be invasive as all
On Thu, 22 May 2014, Rainer Orth wrote:
> "Joseph S. Myers" writes:
>
> > On Thu, 22 May 2014, Rainer Orth wrote:
> >
> >>* common.opt (compressed_debug_sections): New enum.
> >>(gz, gz=): New options.
> >
> >>* opts.c (common_handle_option): Handle OPT_gz, OPT_gz_.
> >
> > Given tha
> For offloading which is being implemented on the gomp4 branch, we're about to
> introduce new mkoffload programs. These are going to require a lot of
> functionality that's already present in lto-wrapper and collect2, I've
> decided to make a new set of utility functions that can be linked in
"Joseph S. Myers" writes:
> On Thu, 22 May 2014, Rainer Orth wrote:
>
>> * common.opt (compressed_debug_sections): New enum.
>> (gz, gz=): New options.
>
>> * opts.c (common_handle_option): Handle OPT_gz, OPT_gz_.
>
> Given that the options are completely handled via specs, why can
Hi Gary!
On Thu, 22 May 2014 17:02:08 +0100, Gary Benson wrote:
> Thomas Schwinge wrote:
> > In GCC, I'm consistenly seeing the following new failure:
> >
> > ./test-demangle < ../../../source/libiberty/testsuite/demangle-expected
> > FAIL at line 4350, options --format=auto --no-params:
On Tue, 2014-05-20 at 16:36 -0400, David Edelsohn wrote:
> On Tue, May 20, 2014 at 3:28 PM, Peter Bergner wrote:
> > gcc/
> > * config/rs6000/htm.md (ttest): Use correct shift value to get CR0.
> >
> > gcc/testsuite/
> > * gcc.target/powerpc/htm-ttest.c: New test.
>
> Okay.
Ok, t
Hi Thomas,
Thomas Schwinge wrote:
> In GCC, I'm consistenly seeing the following new failure:
>
> ./test-demangle < ../../../source/libiberty/testsuite/demangle-expected
> FAIL at line 4350, options --format=auto --no-params:
> in: _QueueNotification_QueueController__$4PPPM_A_INo
On Thu, 22 May 2014, Bernd Schmidt wrote:
> The implementations of some functions like fork_execute are changed to those
> from collect2 and the calls in lto-wrapper adapted accordingly. There are some
> minor changes in these functions: for example I avoid calling fatal_error,
> instead using the
On Thu, 22 May 2014, Rainer Orth wrote:
> * common.opt (compressed_debug_sections): New enum.
> (gz, gz=): New options.
> * opts.c (common_handle_option): Handle OPT_gz, OPT_gz_.
Given that the options are completely handled via specs, why can't they
just be Driver options (wi
On May 22, 2014 5:24:33 PM CEST, Jan Hubicka wrote:
>>
>> Can we? If the body is not readily available we only have decl and
>> cgraph-node, not struct function.
>>
>> I suppose we could exchange the struct function pointer in
>> tree_function_decl for a cgraph_node pointer and put
>> the struc
On Mon, 19 May 2014, Janne Blomqvist wrote:
> Hello,
>
> some systems such as GNU Hurd, don't define PATH_MAX at all, and on
> some other systems many syscalls apparently work for paths longer than
> PATH_MAX. Thus GFortran shouldn't truncate paths to PATH_MAX
> characters, but rather use heap allo
>
> Can we? If the body is not readily available we only have decl and
> cgraph-node, not struct function.
>
> I suppose we could exchange the struct function pointer in
> tree_function_decl for a cgraph_node pointer and put
> the struct function pointer into the cgraph_node.
>
> Of course that
Hi Guys,
I am applying the patch below (to mainline and the 4.9 branch) to fix
a problem when building libgcc for the MSP430. The problem was that
the software multiply functions were being renamed to the hardware
multiply equivalents, and libgcc was using the hardware multiply
feature
On 05/22/14 07:16, Jakub Jelinek wrote:
On Thu, May 22, 2014 at 06:52:05AM -0600, Jeff Law wrote:
On 05/16/14 09:26, Tom Tromey wrote:
2014-05-16 Phil Muldoon
Jan Kratochvil
Tom Tromey
* gcc-c-fe.def: New file.
* gcc-c-interface.h: New file.
Hi Guys,
I am applying the patch below (to mainline and the 4.9 branch) to fix
a small bug in the definition of ASM_SPEC for the MSP430. The problem
was that there were no spaces between some of the options that could
be inserted into the assembler command line, which could produce
unin
>
>> > 3) there is still a failure for -m32:
>> > FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_UAF_long_double
>> > Ident(p)[12] = 0 output pattern test
>> > Output should match: WRITE of size 1[06]
>> > FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_UAF_long_double
>> > Ident(p)[0]
Richard Sandiford writes:
> Yeah, this sounds similar to what I was seeing for Cortex-A8
> with the default -fsched-pressure (which is tuned for and known
> to work well on x86). Did you try with:
>
> -fsched-pressure --param sched-pressure-heuristic=2
Gah, sched-pressure-algorithm rather than
Hi Jaydeep,
Thanks for the write-up and updated patches. I'll try to get to them
this weekend. In the meantime...
Jaydeep Patil writes:
> The -msched-weight option:
> We are using ~650 hot-spot functions from VP9/VP8/H264/MPEG4 codes
> available to us as a test suite. The default Haifa-schedu
On Thu, May 22, 2014 at 06:34:22PM +0400, Konstantin Serebryany wrote:
> > Notes:
> > 1) the cases where we e.g. for various stringops perform first and
> >last address check and use separate __asan_report_*1 for reporting
> >that should probably be converted to use this __asan_report_*_n t
On Thu, May 22, 2014 at 6:07 PM, Jakub Jelinek wrote:
> On Thu, May 22, 2014 at 04:06:21PM +0400, Konstantin Serebryany wrote:
>> Not really recently... (Feb 2013)
>> http://llvm.org/viewvc/llvm-project?rev=175507&view=rev
>
> Ah, wasn't aware of that.
>
> Here is (so far not bootstrapped/regteste
On 22 May 2014 14:03, Jiong Wang wrote:
> gcc/testsuite
> gcc.target/aarch64/tail-indirect-call_1.c: New test.
That should be tail_indirect_call_1.c as requested in the previous
review. Otherwise this is OK to commit.
/Marcus
simplify_shift_const_1 has code to convert:
(ashift (trunc (plus X C1)) C2)
into:
(plus (ashift (trunc X) C2) C1<
On 2 May 2014 13:27, Kugan wrote:
> +2014-05-02 Kugan Vivekanandarajah
> +
> + * config/aarch64/aarch64.c (TARGET_ATOMIC_ASSIGN_EXPAND_FENV): New
> + define.
> + * config/aarch64/aarch64-protos.h (aarch64_atomic_assign_expand_fenv):
> + New function declaration.
> +
Richard Biener wrote:
Can you try to clarify the wording (I'm not a native speaker).
Sure. I've filed a clarified version on PR 56955 and am attaching it
here for convenience.
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (rev
Hi Richard,
Please refer to the attached patch files.
gcc-p5600-noMSA.patch
The patch implements P5600 pipeline and scheduling for GP and FPU
instructions.
gcc-p5600-noMSA-msched-weight.patch
The patch implements -msched-weight option.
The -msched-weight option:
We are using ~650 hot-spot
On Thu, Jan 16, 2014 at 2:41 PM, Jan Hubicka wrote:
>> On Wed, Jan 15, 2014 at 8:39 PM, Jan Hubicka wrote:
>> >>
>> >> In that case should we call gcov_error when IN_LIBGCOV? One
>> >> possibility would be to simply make gcov_nonruntime_assert be defined
>> >> as if (!EXPR) gcov_error in the IN_L
On Thu, May 22, 2014 at 04:06:21PM +0400, Konstantin Serebryany wrote:
> Not really recently... (Feb 2013)
> http://llvm.org/viewvc/llvm-project?rev=175507&view=rev
Ah, wasn't aware of that.
Here is (so far not bootstrapped/regtested) patch for the GCC side.
Notes:
1) the cases where we e.g. for
> I'm a little worried that introducing PLUS_EXPR_CODE_P and friends
> invites too easy (not well thought) uses of it - they are distinct enough
> that we have very few "common" code-paths given the constraints on
> op2 of POINTER_PLUS_EXPR.
"grep -A1 -B1 POINTER_PLUS_EXPR *.c" convinced me of the
On Thu, May 22, 2014 at 2:49 PM, Martin Jambor wrote:
> Hi,
>
> On Wed, May 21, 2014 at 04:27:32PM +0200, Richard Biener wrote:
>> On Wed, May 21, 2014 at 3:16 PM, Martin Jambor wrote:
>> > Hi,
>> >
>> > this demonstrates how results of ipa-prop escape analysis from
>> > previous patches can be u
On 20.05.2014 20:24, Ramana Radhakrishnan wrote:
For now, please revert your original patch and one of Richard or me
will try to look at it in the morning. The thumb1 case is slightly
more complicated than this.
I don't like this approach as you are introducing the problem again in
ARM state
On Thu, May 22, 2014 at 1:57 PM, Bernd Schmidt wrote:
> This is a change from the gomp4 branch which I think could go on trunk now.
> It removes some duplicated definitions and puts them in a header file. More
> definitions will be added to that header once offloading is implemented as
> on the br
On Thu, May 22, 2014 at 06:52:05AM -0600, Jeff Law wrote:
> On 05/16/14 09:26, Tom Tromey wrote:
> >
> >2014-05-16 Phil Muldoon
> > Jan Kratochvil
> > Tom Tromey
> >
> > * gcc-c-fe.def: New file.
> > * gcc-c-interface.h: New file.
> > * gcc-interface.h: New file.
On 21/05/14 15:44, Marcus Shawcroft wrote:
Couple of comments:
+typedef void FP(int);
GNU style please, space before (.
+void f1(FP fp, int n) { (fp)(n); }
GNU style please, line breaks after void, '(' and ';'. Space between
')' an '('. Likewise in the following line.
We should really follow
On 05/16/14 09:26, Tom Tromey wrote:
2014-05-16 Phil Muldoon
Jan Kratochvil
Tom Tromey
* gcc-c-fe.def: New file.
* gcc-c-interface.h: New file.
* gcc-interface.h: New file.
---
+GCC_METHOD7 (gcc_decl, build_decl,
+const char *
Hi,
On Wed, May 21, 2014 at 04:27:32PM +0200, Richard Biener wrote:
> On Wed, May 21, 2014 at 3:16 PM, Martin Jambor wrote:
> > Hi,
> >
> > this demonstrates how results of ipa-prop escape analysis from
> > previous patches can be used at a later stage of compilation by
> > directly returning the
Oops, ignore that. Forgot -C gcc
On Thu, May 22, 2014 at 4:49 PM, Konstantin Serebryany
wrote:
> On Thu, May 22, 2014 at 3:03 PM, Jakub Jelinek wrote:
>> On Thu, May 22, 2014 at 02:26:19PM +0400, Konstantin Serebryany wrote:
>>> >> >> FAIL: c-c++-common/asan/asan-interface-1.c -O0 execution te
On Thu, May 22, 2014 at 3:03 PM, Jakub Jelinek wrote:
> On Thu, May 22, 2014 at 02:26:19PM +0400, Konstantin Serebryany wrote:
>> >> >> FAIL: c-c++-common/asan/asan-interface-1.c -O0 execution test
>> >> >Is that before or after r210743?
>
> Can't reproduce the above (note, not bootstrapped comp
On 22/05/14 00:44, Kugan wrote:
> Compiling some applications with -mgeneral-regs-only produces better
> code (runs faster) compared to not using it. The difference here is that
> when -mgeneral-regs-only is not used, floating point register are also
> used in register allocation. Then IRA/LRA has
On Thu, May 22, 2014 at 3:43 PM, Jakub Jelinek wrote:
> On Thu, May 22, 2014 at 01:03:48PM +0200, Jakub Jelinek wrote:
>> There are various other changes to asan_test.cc, so guess some work is
>> needed on that.
>
> Ok, tried to merge also g++.dg/asan from the same revision as you've merged
> lib
This is the second part of making a set of utility functions to be used
by collect2, lto-wrapper and mkoffload.
The implementations of some functions like fork_execute are changed to
those from collect2 and the calls in lto-wrapper adapted accordingly.
There are some minor changes in these fun
For offloading which is being implemented on the gomp4 branch, we're
about to introduce new mkoffload programs. These are going to require a
lot of functionality that's already present in lto-wrapper and collect2,
I've decided to make a new set of utility functions that can be linked
in with th
Hi!
On Wed, 14 May 2014 15:20:16 +0100, Gary Benson wrote:
> Andrew Burgess wrote:
> > On 14/05/2014 10:01 AM, Gary Benson wrote:
> > > Ian Lance Taylor wrote:
> > > > Andrew Burgess wrote:
> > > > > On 09/05/2014 9:53 PM, Ian Lance Taylor wrote:
> > > > > > Andrew Burgess wrote:
> > > > > > >
This is a change from the gomp4 branch which I think could go on trunk
now. It removes some duplicated definitions and puts them in a header
file. More definitions will be added to that header once offloading is
implemented as on the branch.
Bootstrapped and tested on x86_64-linux, ok?
Bernd
> Let's step back a bit. Please explain which case you were trying to
> handle with the specs patch. Rejecting -msingle-float -mfp64 seems
> fine.
> Fiddling with the specs to stop that combination reaching the assembler
> is what seemed odd.
So, perhaps this is a 'vendor' issue too like some ot
"Joseph S. Myers" writes:
[Sorry for dropping the ball on this for so long.]
> I still have no idea from your answer how a user is meant to know whether
> to use the option when compiling, linking or both, which is what needs to
> be clear from invoke.texi.
>
> What does it mean for the option
On Thu, May 22, 2014 at 01:03:48PM +0200, Jakub Jelinek wrote:
> There are various other changes to asan_test.cc, so guess some work is needed
> on that.
Ok, tried to merge also g++.dg/asan from the same revision as you've merged
libsanitizer.
On x86_64-linux, both -m32 and -m64 I see
FAIL: g++
"Joseph S. Myers" writes:
> On Tue, 20 May 2014, Eric Botcazou wrote:
>> > Make the code base easier to understand for newcomers. It's also a
>> > documentation improvement (you see what a HOST_WIDE_INT really is),
>> > alongside with [u]int64_t being less to type ...
>>
>> I personally find the
On Thu, May 22, 2014 at 02:26:19PM +0400, Konstantin Serebryany wrote:
> >> >> FAIL: c-c++-common/asan/asan-interface-1.c -O0 execution test
> >> >Is that before or after r210743?
Can't reproduce the above (note, not bootstrapped compiler, just
--disable-bootstrap), check-gcc RUNTESTFLAGS=asan.e
Hi!
Ping.
On Fri, 14 Mar 2014 12:22:29 +0100, I wrote:
> $ ../configure --enable-foo='--enable-a=1 --enable-b=2 --enable-c=3'
> [...]
> $ make configure-zlib
> config.status: creating Makefile
> config.status: executing default-1 commands
> ../../zlib/../config-ml.in: eva
Hi!
Now that GCC again is in development stage, and with fresh hope to have
someone review this patch submission, after having let the issue rest for
several months: I just re-tested the current versions. Still there are
no changes for a "regular" build (not using the new configure options).
On t
Hi
On 22 maggio 2014 12:26:19 CEST, Konstantin Serebryany
wrote:
>What is the exact command are you running?
Sorry, now I'm traveling. But nothing special, a very simple c and c++ build on
x86_64-linux. No special flags, all defaults. If nobody can reproduce I'll try
to fetch again the tree
What is the exact command are you running?
On Thu, May 22, 2014 at 1:47 PM, Jakub Jelinek wrote:
> On Thu, May 22, 2014 at 11:44:06AM +0200, Paolo Carlini wrote:
>> On 22 maggio 2014 11:05:31 CEST, Konstantin Serebryany
>> wrote:
>> >On Thu, May 22, 2014 at 12:54 PM, Paolo Carlini
>> > wrote:
>
On 1 May 2014 16:41, Richard Earnshaw wrote:
> I think really, you've got three independent changes here:
Version 2 of this patch series is now a 9 patch series which addresses
most of the following. Exceptions discussed below.
> 1) Optimize the prologue/epilogue sequences when ldrd is available
On Wed, May 21, 2014 at 3:00 AM, Thomas Preud'homme
wrote:
>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
>>
>> I'll send the new patch as soon as all the tests are done.
>
> Here you are. I also simplified the tests a bit having the reference as a
> function
> parameter instead of a
1 - 100 of 119 matches
Mail list logo
