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
cpplib-5.1-b20150208.uk.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
> 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
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
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_
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 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
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/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/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
> 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
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
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
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
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 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
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 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 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.
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
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
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
> 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
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
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
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/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
cpplib-5.1-b20150208.fi.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 Finnish team of translators. The file is available at:
http://translationproject.org/latest/cpplib/fi.po
(This file, 'cpplib-5.1-b20150208
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
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
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-
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
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
> 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
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
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
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
===
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 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
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
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
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
> 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/
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
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
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
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 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_
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 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.
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
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
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
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
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 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
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
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 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
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 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 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 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
Dear Mikael,
I have the patch in my working tree since May 2014. It works as advertised
without
any visible side effect.
Thanks,
Dominique
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
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.
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
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.
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
> ===
> --
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,
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
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!
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
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
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
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 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
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 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
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_
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
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
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
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 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
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 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!
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
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
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
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 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_
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
94 matches
Mail list logo