Hi,
The following GCC patch (I don't have the libffi code git checked
out) implements libffi for AARCH64:ILP32. The majority of the AARCH64
code works correctly for ILP32.
For ILP32, we need to use long long types for ffi_arg and ffi_sarg.
And then we need to fix up the closure code to load cif
On 09/02/15 08:40, Andrew Pinski wrote:
> For ILP32, we need to use long long types for ffi_arg and ffi_sarg.
> And then we need to fix up the closure code to load cif, fn, and
> user_data by 32bit instead of 64bits as they are stored as pointers in
> C code.
Would it make more sense to use int64_
The testcase in PR54000 appears to be fixed with GCC 5 thus the following
adds a testcase for it, improving IVOPTs dumping to make it more likely
stable.
Tested on x86_64/i686, applied.
Richard.
2015-02-09 Richard Biener
PR tree-optimization/54000
* tree-ssa-looo-ivopts.c: I
On Thu, 5 Feb 2015, Tom de Vries wrote:
> On 26-01-15 15:47, Richard Biener wrote:
> > Index: gcc/testsuite/gcc.dg/uninit-19.c
> > ===
> > --- gcc/testsuite/gcc.dg/uninit-19.c(revision 0)
> > +++ gcc/testsuite/gcc.dg/uninit-19
Hi,
the attached patch fixes a critical problem in the va_start expansion
code in the S/390 backend. The problem exists since GCC 4.0.
Ok to commit to 4.9 branch and mainline?
Bye,
-Andreas-
2015-02-09 Andreas Krebbel
PR target/64979
* config/s390/s390.c (s390_va_start): M
Hi!
In r220529, I have committed a merge from trunk r219682 (2015-01-15) into
gomp-4_0-branch. This is the trunk »Merge current set of OpenACC changes
From gomp-4_0-branch« commit, which -- obviously -- mostly has been
present on gomp-4_0-branch already; here's the additional cleanup that I
merge
On Wed, Feb 4, 2015 at 10:45 AM, Tom de Vries wrote:
> Hi,
>
> I've observed a FAILURE for gcc.dg/graphite/scop-19.c with fpic:
> ...
> FAIL: gcc.dg/graphite/scop-19.c scan-tree-dump-times graphite "number of
> SCoPs: 0" 2
> ...
>
> In the nonpic case, d_growable_string_resize is inlined into
> d_
Hi,
As comments in the PR, root cause is GCC aggressively expand induction
variable's base. This patch avoids that by adding new parameter to
expand_simple_operations thus we can stop expansion whenever ssa var
referred by IV's step is encountered. As comments in patch, we could stop
expanding at
On Wed, Feb 4, 2015 at 11:55 AM, Jakub Jelinek wrote:
> On Sat, Nov 01, 2014 at 12:51:32PM +0100, Bernd Schmidt wrote:
>> LTO has a mechanism not to stream out common nodes that are expected to be
>> identical on each run. When using LTO to communicate between compilers for
>> different targets, t
On Wed, Feb 4, 2015 at 12:38 PM, Jakub Jelinek wrote:
> On Sat, Nov 01, 2014 at 12:57:45PM +0100, Bernd Schmidt wrote:
>> This is not against current trunk; it applies to gomp-4_0-branch where it is
>> one of the necessary parts to make offloading x86->nvptx work. The issue is
>> that the LTO file
On 09-02-15 09:59, Richard Biener wrote:
On Thu, 5 Feb 2015, Tom de Vries wrote:
On 26-01-15 15:47, Richard Biener wrote:
Index: gcc/testsuite/gcc.dg/uninit-19.c
===
--- gcc/testsuite/gcc.dg/uninit-19.c(revision 0)
+++ gcc/tes
The second time I missed patch in one day, I hate myself.
Here it is.
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Bin Cheng
> Sent: Monday, February 09, 2015 6:10 PM
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH PR6470
Hi,
when testing I noticed, that if compile with both -fsanitize=address and
-fstack-protector for 32-bit architectures and run with
ASAN_OPTIONS=detect_stack_use_after_return=1, libsanitizer fails with:
==7299==AddressSanitizer CHECK failed:
/home/max/workspace/downloads/gcc/libsanitizer/a
On 07/02/15 00:11, Jonathan Wakely wrote:
Any idea why HP still sees the tests fail? See comment 8 at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64467#c8
It looks like he's found the problem: that _NEWLIB_ is a recent addition
that isn't in the version he's using. I'll try replacing _NEWLIB_
On Mon, Feb 09, 2015 at 10:50:34AM +0100, Andreas Krebbel wrote:
> Hi,
>
> the attached patch fixes a critical problem in the va_start expansion
> code in the S/390 backend. The problem exists since GCC 4.0.
>
> Ok to commit to 4.9 branch and mainline?
No. This isn't a backend problem, but a bu
Bruce Korb writes:
> On 01/29/15 05:38, Rainer Orth wrote:
>> So I saw. If all else fails, we can still commit the (ugly/hard to
>> read) initial version, otherwise libgo won't build on Solaris before
>> some (quite recent) Solaris 11.2 patch, breaking bootstrap.
>
> Having it work at all seems
On 02/09/2015 12:29 PM, Jakub Jelinek wrote:
> On Mon, Feb 09, 2015 at 10:50:34AM +0100, Andreas Krebbel wrote:
>> Hi,
>>
>> the attached patch fixes a critical problem in the va_start expansion
>> code in the S/390 backend. The problem exists since GCC 4.0.
>>
>> Ok to commit to 4.9 branch and mai
Hello!
Attached patch xfails gcc.dg/c11-true_min-1.c execution for
alpha*-*-*. Without -mieee, it is not possible to compare a subnormal
number with zero on alpha targets, since any operation with subnormal
values will trigger a FPE.
2015-02-08 Uros Bizjak
PR target/58757
* gcc.dg/c11
On Mon, Feb 09, 2015 at 12:40:05PM +0100, Andreas Krebbel wrote:
> On 02/09/2015 12:29 PM, Jakub Jelinek wrote:
> > On Mon, Feb 09, 2015 at 10:50:34AM +0100, Andreas Krebbel wrote:
> >> Hi,
> >>
> >> the attached patch fixes a critical problem in the va_start expansion
> >> code in the S/390 backen
On Mon, Feb 09, 2015 at 01:05:23PM +0100, Jakub Jelinek wrote:
> As you can see, the updated testcase fails even on x86_64-linux.
Here is an updated patch that succeeds even on i686-linux.
2015-02-09 Jakub Jelinek
PR target/64979
* tree-stdarg.c (pass_stdarg::execute): Scan ph
Hello!
alpha defines MOVE_RATIO that doesn't fit these tests.
2015-02-09 Uros Bizjak
* gcc.dg/tree-ssa/ssa-dom-cse-2.c: Xfail scan-tree-dump for alpha*-*-*.
* gcc.dg/tree-ssa/pr42585.c: Xfail scan-tree-dump-times for alpha*-*-*.
Tested on alpha-linux-gnu and committed to mainline SVN
Hi!
On Wed, 28 Jan 2015 14:58:04 -0800, Caroline Tice wrote:
> Since all the pieces of this patch have been approved, I will commit
> it later today (since Patrick does not have commit privileges).
(This happened in r220232 and r220254.)
I'm seeing:
[...]
checking dynamic linker charac
Hello,
I'd like to ping with a respin of the 7 patches for
the attribute target (thumb,arm) [0-6] :
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02455.html
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02458.html
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02460.html
https://gcc.gnu.org/ml/gc
In order to fix the various conflicts that have happened since, please
find attached the re-based patches to trunk rev #220529 (respectively
from above p0.patch, p1.patch, p2,patch, p3.patch, p4,patch, p5,patch,
p6,patch).
oops, please don't review p0.patch here. This last one will be reviewe
Hello,
this is about a pointer bounds remapping regression introduced at
http://gcc.gnu.org/r190641
That revision introduced support for se.descriptor_only in
gfc_conv_expr_descriptor with this hunk:
> Index: trans-array.c
> ===
> --
This re-arranges things so that we have a chance to optimize
the bitpacking to a series of shifts and bit operations with
constant operands. We still fail to fully optimize this due
to various reasons but the "head" of streamer_write_tree_bitfields
and streamer_read_tree_bitfields now looks sane.
On Mon, 9 Feb 2015, Matthew Wahab wrote:
> On 07/02/15 00:11, Jonathan Wakely wrote:
> > Any idea why HP still sees the tests fail? See comment 8 at
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64467#c8
>
> It looks like he's found the problem: that _NEWLIB_ is a recent addition that
> isn't in
On Mon, Feb 9, 2015 at 7:20 AM, Bin Cheng wrote:
> And the missed patch.
>
> Thanks,
> bin
>
>> -Original Message-
>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
>> ow...@gcc.gnu.org] On Behalf Of Bin Cheng
>> Sent: Monday, February 09, 2015 2:07 PM
>> To: gcc-patches@gcc.gnu.
Hi all,
atm enable_if cannot be used to select between overload of UDLs. E.g.
https://gcc.gnu.org/bugzilla/attachment.cgi?id=34684 will not compile.
This can be easily fixed making sure that lookup_literal_operator
returns all the possible candidates and not just the first match. I
made some more
Dear Mikael,
I have the patch in my working tree since May 2014. It works as advertised
without
any visible side effect.
Thanks,
Dominique
On Mon, Feb 9, 2015 at 8:15 AM, Jeff Law wrote:
> On 02/03/15 04:39, Richard Biener wrote:
>>>
>>> I found that explicit types were ignored in some cases. It was
>>> frustrating to say the least.
>>
>>
>> Huh, that would be a bug. Do you have a pattern where that happens?
>
> I'll have to recrea
On Mon, Feb 9, 2015 at 1:17 PM, Jakub Jelinek wrote:
> On Mon, Feb 09, 2015 at 01:05:23PM +0100, Jakub Jelinek wrote:
>> As you can see, the updated testcase fails even on x86_64-linux.
>
> Here is an updated patch that succeeds even on i686-linux.
Ok if it fixes s390.
Thanks,
Richard.
> 2015-0
On 02/09/2015 01:05 PM, Jakub Jelinek wrote:
> On Mon, Feb 09, 2015 at 12:40:05PM +0100, Andreas Krebbel wrote:
>> On 02/09/2015 12:29 PM, Jakub Jelinek wrote:
>>> On Mon, Feb 09, 2015 at 10:50:34AM +0100, Andreas Krebbel wrote:
Hi,
the attached patch fixes a critical problem in the
On 02/09/2015 01:17 PM, Jakub Jelinek wrote:
> On Mon, Feb 09, 2015 at 01:05:23PM +0100, Jakub Jelinek wrote:
>> As you can see, the updated testcase fails even on x86_64-linux.
>
> Here is an updated patch that succeeds even on i686-linux.
Your patch fixes my testcase on s390x. Thanks!
-Andreas
On 28/01/15 18:50, Mike Stump wrote:
On Jan 28, 2015, at 9:51 AM, Marcus Shawcroft
wrote:
Going forward we can [ … ] xfail the test case pending a proper solution to
59448 ?
Mike do you prefer one of the other two approaches ?
I’d xfail the test case and mark with the fix consume PR. If
Hi,
This patch adds match.pd "compare-and-not" simplication patterns.
This is a generic transformation reducing variable accesses.
Done full regression run on arm-none-eabi, aarch64-none-elf,
aarch64_be-none-elf and bootstrapped on x86.
Is patch ok?
2015-02-09 Alex Velenko
gcc/
*
On Mon, Feb 9, 2015 at 3:30 AM, Rainer Orth
wrote:
> That worked fine indeed and is considerably more readable than my
> previous version.
Excellent! Thank you.
> It produced the identical fixincl.x, passed fixincludes make check and
> Solaris 10 and 11 bootstraps.
>
> Ok for mainline now, I g
On February 9, 2015 4:46:34 PM CET, Alex Velenko wrote:
>
>Hi,
>
>This patch adds match.pd "compare-and-not" simplication patterns.
>This is a generic transformation reducing variable accesses.
>
>Done full regression run on arm-none-eabi, aarch64-none-elf,
>aarch64_be-none-elf and bootstrapped on
Jan,
This patch caused Bug 64982 - [5 Regression] Many g++ failures on
x86_64-apple-darwin14 with -m32.
Jack
On Sun, Feb 8, 2015 at 3:20 PM, Jan Hubicka wrote:
> Hi,
> this patch makes i386.c ready for presence of aliases of local functions, but
> also fixes a wrong code i
On February 9, 2015 11:09:49 AM CET, Bin Cheng wrote:
>Hi,
>As comments in the PR, root cause is GCC aggressively expand induction
>variable's base. This patch avoids that by adding new parameter to
>expand_simple_operations thus we can stop expansion whenever ssa var
>referred by IV's step is en
This was giving an UNRESOLVED after my first attempt to apply the patch ran into
trouble with line wrapping, and in diagnosing the problem I'd introduced an
extra 'target' vs. the original
(https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00215.html). Sorry! Pushed as
r220542.
--Alan
gcc/testsu
Hi,
The attached patch fixes the lost mem aliasing info for atomic ops on SH
and allows the utilization of reg+disp address modes for atomic ops.
Actually it was supposed to be a pretty straight forward patch that just
replaces the open coded 'mem:QIHISI (match_operand:SI
"arith_reg_operand")' ope
On Feb 9, 2015, at 7:11 AM, Alex Velenko wrote:
> The following patch makes atomic-op-consume.c XFAIL
>
> Is this patch ok?
Ok.
I’d shorten the comment above the xfail to be exceedingly short:
/* PR59448 consume not implemented yet */
The reason is the brain can process this about 8x faster
On Feb 8, 2015, at 10:24 AM, Jack Howarth wrote:
> This last version of the patch bootstraps and passes the test suite
> without regressions on x86_64-apple-darwin14.
Ok for the darwin bits.
Tom,
After these changes I have the following regressions on
x86_64-apple-darwin1[04]*:
FAIL: gcc.dg/uninit-19.c (test for warnings, line 22)
FAIL: gcc.dg/uninit-19.c (test for excess errors)
FAIL: gcc.dg/graphite/scop-19.c scan-tree-dump-times graphite "number of SCoPs:
0" 1
I can prepare an
On 09/02/15 13:18, Hans-Peter Nilsson wrote:
On Mon, 9 Feb 2015, Matthew Wahab wrote:
On 07/02/15 00:11, Jonathan Wakely wrote:
Any idea why HP still sees the tests fail? See comment 8 at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64467#c8
It looks like he's found the problem: that _NEWLIB_
On 09-02-15 18:23, Dominique Dhumieres wrote:
Tom,
After these changes I have the following regressions on
x86_64-apple-darwin1[04]*:
FAIL: gcc.dg/uninit-19.c (test for warnings, line 22)
FAIL: gcc.dg/uninit-19.c (test for excess errors)
FAIL: gcc.dg/graphite/scop-19.c scan-tree-dump-times gr
On 02/09/15 06:42, Richard Biener wrote:
On Mon, Feb 9, 2015 at 8:15 AM, Jeff Law wrote:
On 02/03/15 04:39, Richard Biener wrote:
I found that explicit types were ignored in some cases. It was
frustrating to say the least.
Huh, that would be a bug. Do you have a pattern where that happen
Before I commit this, or do the corresponding tree level patch, I would
like this to be looked at by the FP people. I am guessing at some of
this, other parts i gleaned from various standards docs and an irc
conversation with Joseph. This should have been documented when it was
put into the
build_vec_init works to evaluate constant values for elements of a
vector initializer, but it wasn't working properly for a
default-initialized array with a constexpr default constructor. First I
needed to add that case to the try_const condition; then I needed to
change tho form of the initia
> Le 9 févr. 2015 à 20:01, Dominique d'Humières a écrit :
>
>
>> Le 9 févr. 2015 à 19:10, Tom de Vries a écrit :
>>
>> On 09-02-15 18:23, Dominique Dhumieres wrote:
>>> Tom,
>>>
>>> After these changes I have the following regressions on
>>> x86_64-apple-darwin1[04]*:
>>>
>>> FAIL: gcc.dg/
On 02 Feb 13:15, Jakub Jelinek wrote:
> On Mon, Jan 12, 2015 at 12:22:44AM +0300, Ilya Verbin wrote:
> > Currently if a target* pragma appears within a target region, GCC
> > successfully
> > compiles such code (with a warning). But the binary fails at run-time,
> > since it
> > tries to call GO
We reject the following testcase in C99 mode, because in C99 we always
wrap COMPOUND_LITERAL_EXPR in a SAVE_EXPR when initializing a range of
elements, even though the expression is required to be constant. As a
consequence, we error out with "initializer element is not constant".
It's been like t
Hello, gentle maintainer.
This is a message from the Translation Project robot. (If you have
any questions, send them to .)
A new POT file for textual domain 'cpplib' has been made available
to the language teams for translation. It is archived as:
http://translationproject.org/POT-files/c
Hi,
this patch fixes ICE seen when compiling firefox with large unit growths.
The problem is that the speculative part of analysis trips over VOID pointer
and gets lost.
Bootstrapped/regtsted x86_64-linux, commited.
* ipa-polymorphic-call.c (ipa_polymorphic_call_context): Avoid ICE
Hi,
this patch fixes one false positive seen while building Firefox with FDO.
There are case when we try to compare bases of a type that was not analyzed
yet. I rewrot ethe comparsion loop to walk BINFO_BASE_BINFO array instead
of comparing with the ODR_type representation. This is more precise be
Hi,
this patch finally disables the wroarkound in ipa-icf for local functions.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
2015-02-08 Jan Hubicka
PR ipa/63566
* ipa-icf.c (set_local): New function.
(sem_function::merge): Use it.
Index: ipa-icf.c
===
This appears to be the first instance where 'target' and 'nonpic' have
been used in a dg-warning.
On Mon, Feb 9, 2015 at 2:40 PM, Dominique d'Humières wrote:
>
>> Le 9 févr. 2015 à 20:01, Dominique d'Humières a écrit :
>>
>>
>>> Le 9 févr. 2015 à 19:10, Tom de Vries a écrit :
>>>
>>> On 09-02-1
On 02/09/2015 11:51 AM, Marek Polacek wrote:
> We reject the following testcase in C99 mode, because in C99 we always
> wrap COMPOUND_LITERAL_EXPR in a SAVE_EXPR when initializing a range of
> elements, even though the expression is required to be constant. As a
> consequence, we error out with "i
> Jan,
> This patch caused Bug 64982 - [5 Regression] Many g++ failures on
> x86_64-apple-darwin14 with -m32.
>Jack
Hi,
I think best way would be to move the warning to middle-end when the thunk is
being
expanded (other alternative is just to force analysis before doing t
Hi,
this patch fixes issue with emutls outputting duplicate ddeifnitions of the vars
it creates becuase it sometimes inserts variable twice (once as alias target and
once as real var).
Bootstrapped/regtested x86_64-linux and HP regtested at at cris-elf.
PR ipa/61548
* tree-emutls.c
Also, aren't we pretty much the only target to default to PIC? So if
the 'target' and 'nonpic' testing is failing when used in the context
of dg-warning, wouldn't that appear functional on the nonpic targets?
That is, since the nonpic test is to check for __PIC__, if that fails
in dg-warning, woul
Hello, gentle maintainer.
This is a message from the Translation Project robot. (If you have
any questions, send them to .)
A new POT file for textual domain 'gcc' has been made available
to the language teams for translation. It is archived as:
http://translationproject.org/POT-files/gcc-
Hi!
asan_intercepted_p only looks at fcode and obviously means only
BUILT_IN_NORMAL builtins, so we should ignore it for BUILT_IN_MD builtins.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk as
obvious.
2015-02-09 Jakub Jelinek
PR sanitizer/64981
* b
On 02/09/2015 04:01 PM, Jan Hubicka wrote:
I had to dro # in the error message, I am not quite sure what it means.
It just means more verbose.
Jason, what do you think?
Looks fine to me.
Jason
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Finnish team of translators. The file is available at:
http://translationproject.org/latest/cpplib/fi.po
(This file, 'cpplib-5.1-b20150208
cpplib-5.1-b20150208.fi.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
On 02/06/15 05:12, Alexander Monakov wrote:
Ping?
On Fri, 30 Jan 2015, Alexander Monakov wrote:
Hello,
Recently on gcc-help@ one of the users asked whether they need to set
-fvar-tracking-assignments on the command line by hand. The documentation may
be clearer in that this flag has a useful
On 02/01/15 09:42, Iain Sandoe wrote:
This is a GCC5 bootstrap regression on 32bit Darwin hosts ( I can raise a PR if
that is considered necessary).
Has this been addressed or is it still pending?
In fact it is not libcc1, but libiberty that is the cause -
On 26 Jan 2015, at 14:13, Rainer
On 02/03/15 16:57, Kaz Kojima wrote:
Kaz Kojima wrote:
2015-01-27 Joern Rennecke
Kaz Kojima
PR target/64761
* config/sh/sh-protos.h (sh_can_redirect_branch): Don't declare.
* config/sh/sh.c (TARGET_CAN_FOLLOW_JUMP): Redefine.
(sh_can_redirect_br
Hi,
I'd like to ping these patches
http://gcc.gnu.org/ml/gcc-patches/2015-01/msg02716.html
pr 61889 - p1 don't require ftw.h in gcov-tool.c
http://gcc.gnu.org/ml/gcc-patches/2015-01/msg01869.html
pr 64076 - p2 - don't ICE on invalid code that has ironly and not ironly
thunks
thanks!
Trev
> Hi,
>
> I'd like to ping these patches
>
> http://gcc.gnu.org/ml/gcc-patches/2015-01/msg02716.html
> pr 61889 - p1 don't require ftw.h in gcov-tool.c
Looks good enough. Hopefully eventually someone will write mingw implementation.
OK
>
> http://gcc.gnu.org/ml/gcc-patches/2015-01/msg01869.html
On 02/06/15 05:24, James Greenhalgh wrote:
---
2015-02-06 James Greenhalgh
* haifa-sched.c (recompute_todo_spec): After applying a
replacement and cancelling a dependency, also clear the
SCHED_GROUP_P flag.
My worry here would be that we might be clearing a SCHED_GROU
Converting GDB to be a C++ program, I stumbled on 'basename' issues,
like:
src/gdb/../include/ansidecl.h:169:64: error: new declaration ‘char*
basename(const char*)’
/usr/include/string.h:597:26: error: ambiguates old declaration ‘const char*
basename(const char*)’
which I believe led to this
Just like libiberty.h. So that C++ programs, such as GDB when built
as a C++ program, can use it.
include/ChangeLog:
2015-02-09 Pedro Alves
* floatformat.h [__cplusplus]: Wrap in extern "C".
---
include/floatformat.h | 8
1 file changed, 8 insertions(+)
diff --git a/include
On Wed, 2015-02-04 at 23:19 +0100, Jakub Jelinek wrote:
> On Wed, Feb 04, 2015@01:58:32PM -0800, Cary Coutant wrote:
> > > DW_LANG_Fortran03 and DW_LANG_Fortran08 DW_AT_language values were
> > > recently
> > > accepted into DWARF5. This patch changes GCC to handle those similarly to
> > > how e.
On Mon, 9 Feb 2015, Kenneth Zadeck wrote:
> @findex ge
> @cindex greater than
> @@ -2603,6 +2618,10 @@ Like @code{gt} and @code{gtu} but test f
> @item (ge:@var{m} @var{x} @var{y})
> @itemx (geu:@var{m} @var{x} @var{y})
> Like @code{gt} and @code{gtu} but test for ``greater than or equal''.
>
On 02/09/2015 11:10 AM, Kenneth Zadeck wrote:
> +@table @code
> +@findex ltgt
> +@cindex less than or greater than
> +@item (ltgt:@var{m} @var{x} @var{y})
> +@code{STORE_FLAG_VALUE} if the values represented by @var{x} and
> +@var{y} are less, or greater, otherwise 0. This is a quiet operation
> +
On 02/03/15 20:03, Bin.Cheng wrote:
I looked into the test and can confirm the previous compilation is correct.
The cover letter of this patch said IRA mis-handled REQ_EQUIV before,
but in this case it is REG_EQUAL that is lost. The full dump (without
this patch) after IRA is like:
Right, but a
Bah, looks like I dropped gdb-patches@ by accident, adding it back
(patch here: https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00580.html).
For the gcc folks, this is part of this series:
https://sourceware.org/ml/gdb-patches/2015-02/msg00202.html
Thanks,
Pedro Alves
On 02/09/2015 11:20 PM, Pedr
On Mon, Feb 9, 2015 at 3:20 PM, Pedro Alves wrote:
> Just like libiberty.h. So that C++ programs, such as GDB when built
> as a C++ program, can use it.
Why is not needed for GCC building with C++ compiler?
Thanks,
Andrew
>
> include/ChangeLog:
> 2015-02-09 Pedro Alves
>
> * floatfo
On 02/09/2015 11:35 PM, Andrew Pinski wrote:
> On Mon, Feb 9, 2015 at 3:20 PM, Pedro Alves wrote:
>> Just like libiberty.h. So that C++ programs, such as GDB when built
>> as a C++ program, can use it.
>
> Why is not needed for GCC building with C++ compiler?
Because it doesn't include it.
The
Jeff Law wrote:
>> Ping?
>>
>> https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02345.html
> Presumably you're pinging due to the reorg/doc changes? Those are
> fine :-)
Thanks! I've committed it as revision 220552.
Regards,
kaz
> This patch adds a new jump insn for the jump crossing between hot/cold
> pertitions and reenables -freorder-blocks-and-partition on SH in
> some cases.
>
> --
> PR target/64761
> * config/sh/sh.c (sh_option_override): Don't change
> -freorder-blocks-and-partition to -freorder-b
On 02/09/2015 06:26 PM, Richard Henderson wrote:
On 02/09/2015 11:10 AM, Kenneth Zadeck wrote:
+@table @code
+@findex ltgt
+@cindex less than or greater than
+@item (ltgt:@var{m} @var{x} @var{y})
+@code{STORE_FLAG_VALUE} if the values represented by @var{x} and
+@var{y} are less, or greater, oth
On 02/09/2015 06:24 PM, Joseph Myers wrote:
On Mon, 9 Feb 2015, Kenneth Zadeck wrote:
@findex ge
@cindex greater than
@@ -2603,6 +2618,10 @@ Like @code{gt} and @code{gtu} but test f
@item (ge:@var{m} @var{x} @var{y})
@itemx (geu:@var{m} @var{x} @var{y})
Like @code{gt} and @code{gtu} b
On 02/09/15 00:57, Zhouyi Zhou wrote:
+2015-02-09 Zhouyi Zhou
+ * ira-color.c (setup_left_conflict_sizes_p): save a init statement.
THanks. I improve the ChangeLog a bit fixed the indention, bootstrapped
and regression tested your change.
Installed on the trunk.
Thanks,
Jeff
On 02/06/15 02:34, Georg Koppen wrote:
Hi,
inline is a patch to avoid using /dev/random on Windows in ssp.c. If it
is getting used there might be a local malicious process supplying fake
random values (e.g. via C:\dev\random) rendering SSP useless.
Comments/review are much appreciated. The patc
Hi Eric,
I'm taking over Zhenqiang's work on this. Comments and updated patch
below.
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Eric Botcazou
> > + rtx reg_equal = insn ? find_reg_equal_equiv_note (insn) : NULL_RTX;
> > + unsigned HOST_WIDE_INT
On Mon, Feb 9, 2015 at 5:51 PM, Thomas Preud'homme
wrote:
> Hi Eric,
>
> I'm taking over Zhenqiang's work on this. Comments and updated patch
> below.
>
>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
>> ow...@gcc.gnu.org] On Behalf Of Eric Botcazou
>> > + rtx reg_equal = insn ? find_
And this is part 2.
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Eric Botcazou
>
> Once this is done, the same thing needs to be applied to XEXP
> (reg_equal, 0)
> before it is sent to nonzero_bits.
>
>
> > - /* Don't call nonzero_bits if it c
> From: Andrew Pinski [mailto:pins...@gmail.com]
> Sent: Tuesday, February 10, 2015 9:57 AM
> > +#ifdef SHORT_IMMEDIATES_SIGN_EXTEND
> > +/* If MODE has a precision lower than PREC and SRC is a non-negative
> constant
> > + that would appear negative in MODE, sign-extend SRC for use in
> nonzero
cpplib-5.1-b20150208.uk.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Ukrainian team of translators. The file is available at:
http://translationproject.org/latest/cpplib/uk.po
(This file, 'cpplib-5.1-b201502
94 matches
Mail list logo
