On January 12, 2015 9:04:50 PM CET, Jakub Jelinek wrote:
>Hi!
>
>This patch changes the libgcj*.pc installed filename to match the new
>GCC
>versioning scheme.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, tested make
>install.
>
>-rw-r--r--. 1 jakub jakub 192 Jan 12 21:02
>/tmp/blah/u
Hi, all,
Currently, the nds32 port on trunk only supports 512K or 4G addressing space
to access data by specifying -mgp-direct/-mno-gp-direct option. And the range
of text section is always assumed to be within 16M addressing space.
However, sometimes we may have large programs or sometimes we ma
Hi, all,
Committed as Rev. 219515: https://gcc.gnu.org/r219515
gcc/ChangeLog
* config/nds32/nds32.c (nds32_legitimate_address_p): Consider
TARGET_CMODEL_LARGE and TARGET_CMODEL_MEDIUM cases.
Best regards,
jasonwucj
0006-Consider-mcmodel-X-in-nds32_legitimate_address_p-imp.pa
Hi, all,
Committed as Rev. 219514: https://gcc.gnu.org/r219514
gcc/ChangeLog
* config/nds32/nds32.h (NDS32_SYMBOL_FLAG_RODATA): Define our own
target-specific symbol_ref flag.
(NDS32_SYMBOL_REF_RODATA_P): Define it to check if the symbol_ref
resides in rodata sec
Hi, all,
Committed as Rev. 219512: https://gcc.gnu.org/r219512
gcc/ChangeLog
* config/nds32/nds32.md (call): Use pseudo instruction bal which
clobbers TA_REGNUM if large code model is specified.
(call_register): Likewise.
(call_immediate): Likewise.
(call
Hi, all,
Committed as Rev. 219511: https://gcc.gnu.org/r219511
gcc/ChangeLog
* config/nds32/nds32.h (TARGET_CMODEL_SMALL): New macro.
(TARGET_CMODEL_MEDIUM): New macro.
(TARGET_CMODEL_LARGE): New macro.
* config/nds32/nds32.c (nds32_asm_file_start): Display corr
Hi, all,
Committed as Rev. 219510: https://gcc.gnu.org/r219510
gcc/ChangeLog
* common/config/nds32/nds32-common.c (TARGET_DEFAULT_TARGET_FLAGS):
Remove MASK_GP_DIRECT flag.
* config/nds32/nds32.h (MULTILIB_DEFAULTS): Have -mcmodel=medium as
one of the multilib de
2015-01-13 14:14 GMT+08:00 Chung-Ju Wu :
> Hi, all,
>
> Committed as Rev. 219509: https://gcc.gnu.org/r219509
>
>
> gcc/ChangeLog
>
> * config/nds32/nds32.opt (mcmodel): Add new option.
> * config/nds32/nds32-opts.h (nds32_cmodel_type): Add new enum type
> to describe code m
Hi, all,
Committed as Rev. 219509: https://gcc.gnu.org/r219509
gcc/ChangeLog
* config/nds32/nds32.opt (mcmodel): Add new option.
* config/nds32/nds32-opts.h (nds32_cmodel_type): Add new enum type
to describe code model.
Best regards,
jasonwucj
Stan Shebs has not been active in GCC development for a very long time.
I'm always sad to see folks go, but it happens.
The GCC steering committee felt it was not in the best interest of GCC
to have an inactive maintainer in the MAINTAINERS file. There are
likely others, Stan just happened
Hi,
The attached patch is to fix libffi build failure for
sh4-unknown-linux-gnu. Without it, configure fails with:
configure: error: "libffi has not been ported to sh4-unknown-linux-gnu."
on that target. OK for trunk?
Regards,
kaz
--
2015-01-13 Kaz Kojima
* configure.host:
Ping
On Wed, Nov 19, 2014 at 10:43 AM, Joey Ye wrote:
> Current thumb2 -Os generates suboptimal code for following tail call case:
>
> int f4(int b, int a, int c, int d);
> int g(int a, int b, int c, int d)
> { return f4(b, a, c, d); }
>
> arm-none-eabi-gcc -Os -mthumb -mcpu=cortex-m3 test.c
>
>
Hi,
With stores, we can get (const_int 0) as the src which has a mode of
VOIDmode but this can be a valid store for optimizing into a store
pair. This patch changes checking for the src mode to checking dest
mode instead which does not have this issue. I added a testcase which
shows the issue w
On Tue, Dec 9, 2014 at 6:18 PM, Andrew Pinski wrote:
> Hi,
> As mentioned in
> https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00609.html, the
> load/store pair peepholes currently accept volatile mem which can
> cause wrong code as the architecture does not define which part of the
> pair happens
On 1/13/15 01:32, Jeff Law wrote:
> On 01/12/15 10:01, Jeff Law wrote:
>> This indicates a violation of the type safety invariants we're adding to
>> GCC. Simply changing the code to use rtx rather than rtx_insn is
>> probably a step in the wrong direction.
>>
>> Part of the problem here is that R
On 01/12/2015 04:57 PM, H.J. Lu wrote:
> The problem is my x86_64-*-linux-gnux32 patch
>
> https://gcc.gnu.org/ml/gcc-patches/2012-08/msg01083.html
>
> was never accepted upstream. Can I apply it to config.guess
> in GCC?
Ah. Hmm. Perhaps the configure.host patch would be better after all.
On Mon, Jan 12, 2015 at 3:46 PM, H.J. Lu wrote:
> On Mon, Jan 12, 2015 at 2:42 PM, H.J. Lu wrote:
>> This libffi commit:
>>
>> 13e2d7b92557a9511a0414df82bf2df3edc55cba is the first bad commit
>> commit 13e2d7b92557a9511a0414df82bf2df3edc55cba
>> Author: Anthony Green
>> Date: Thu Jan 10 10:52:
On Mon, Jan 12, 2015 at 4:29 PM, Richard Henderson wrote:
> On 01/12/2015 03:46 PM, H.J. Lu wrote:
>> On Mon, Jan 12, 2015 at 2:42 PM, H.J. Lu wrote:
>>> This libffi commit:
>>>
>>> 13e2d7b92557a9511a0414df82bf2df3edc55cba is the first bad commit
>>> commit 13e2d7b92557a9511a0414df82bf2df3edc55cb
On 01/12/2015 11:08 AM, Uros Bizjak wrote:
> Hello!
>
>> Upstream libffi has added support for Go closures (using the static chain),
>> and support for complex numbers. Perhaps less relevant is new support for
>> arc, microblaze, moxie, nios, and or1k targets.
>>
>> Without additional changes for
On 01/12/2015 03:46 PM, H.J. Lu wrote:
> On Mon, Jan 12, 2015 at 2:42 PM, H.J. Lu wrote:
>> This libffi commit:
>>
>> 13e2d7b92557a9511a0414df82bf2df3edc55cba is the first bad commit
>> commit 13e2d7b92557a9511a0414df82bf2df3edc55cba
>> Author: Anthony Green
>> Date: Thu Jan 10 10:52:02 2013 -0
On Mon, Jan 12, 2015 at 3:50 PM, Joseph Myers wrote:
> On Mon, 12 Jan 2015, H.J. Lu wrote:
>
>> +if test x$enable_default_pie = xyes; then
>> + AC_MSG_CHECKING(if $target supports default PIE)
>> + enable_default_pie=no
>> + case $target in
>> +i?86*-*-linux* | x86_64*-*-linux*)
>> + s
Following backport tested on 4.8/4.9 with no new regressions. Ok to
commit to those branches?
-Pat
2015-01-12 Pat Haugen
Backport from mainline
2014-12-20 Segher Boessenkool
PR target/64358
* config/rs6000/rs6000.c (rs6000_split_logical_inner): Swap the
On Mon, 12 Jan 2015, H.J. Lu wrote:
> +if test x$enable_default_pie = xyes; then
> + AC_MSG_CHECKING(if $target supports default PIE)
> + enable_default_pie=no
> + case $target in
> +i?86*-*-linux* | x86_64*-*-linux*)
> + saved_LDFLAGS="$LDFLAGS"
> + saved_CFLAGS="$CFLAGS"
> +
Hi,
The patch below implements TARGET_ATOMIC_ASSIGN_EXPAND_FENV hook for
sh. It's cut&pasted from arm/arm-builtins.c's implementation by
using __builtin_sh_{get,set}_fpscr which Oleg added recently.
Tested on sh4-unknown-linux-gnu with no new failures. The failure
of gcc.dg/atomic/c11-atomic-exe
On Mon, Jan 12, 2015 at 2:42 PM, H.J. Lu wrote:
> This libffi commit:
>
> 13e2d7b92557a9511a0414df82bf2df3edc55cba is the first bad commit
> commit 13e2d7b92557a9511a0414df82bf2df3edc55cba
> Author: Anthony Green
> Date: Thu Jan 10 10:52:02 2013 -0500
>
> Handle both 32 and 64-bit x86 build
On Mon, Jan 12, 2015 at 12:19 PM, Jakub Jelinek wrote:
> Hi!
>
> The 991213-3.c testcase ICEs on aarch64-linux with -mabi=ilp32
> since wide-int merge. The problem is that
> x = convert_memory_address (Pmode, x)
> is used twice on a VOIDmode CONST_INT, which is wrong.
> For non-VOIDmode rtl the s
This libffi commit:
13e2d7b92557a9511a0414df82bf2df3edc55cba is the first bad commit
commit 13e2d7b92557a9511a0414df82bf2df3edc55cba
Author: Anthony Green
Date: Thu Jan 10 10:52:02 2013 -0500
Handle both 32 and 64-bit x86 builds regardless of target triple
breaks x32.
--
H.J.
On Mon, Jan 12, 2015 at 2:31 PM, H.J. Lu wrote:
> On Mon, Jan 12, 2015 at 11:08 AM, Uros Bizjak wrote:
>> Hello!
>>
>>> Upstream libffi has added support for Go closures (using the static chain),
>>> and support for complex numbers. Perhaps less relevant is new support for
>>> arc, microblaze, m
> ... Due to upstream breakage, and difficulty debugging on Darwin,
> {i686,x86_64}-darwin retains copies of the existing sources and thus remains
> 100% unchanged. ...
Nevertheless the commit breaks bootstrap on darwin:
...
libtool: link: /opt/gcc/build_w/./gcc/xgcc -B/opt/gcc/build_w/./gcc/
-B
James Greenhalgh writes:
> @@ -794,25 +805,25 @@ diagnosis when special predicates are used.
>
> These are the generic predicates available to all back ends. They are
> defined in @file{recog.c}. The first category of predicates allow
> -only constant, or @dfn{immediate}, operands.
> +only c
On Mon, Jan 12, 2015 at 11:08 AM, Uros Bizjak wrote:
> Hello!
>
>> Upstream libffi has added support for Go closures (using the static chain),
>> and support for complex numbers. Perhaps less relevant is new support for
>> arc, microblaze, moxie, nios, and or1k targets.
>>
>> Without additional c
In my PyPy libgccjit experiments I managed to get various crashes
deep inside the compile (when expanding gimple -> RTL).
Investigation showed that I was erroneously using params and locals from
one function in an entirely different function.
The API checks individual rvalues and the tree-like st
James Greenhalgh writes:
> @node Example
> @section Example of @code{define_insn}
> @cindex @code{define_insn} example
>
> -Here is an actual example of an instruction pattern, for the 68000/68020.
> +Here is an example of an instruction pattern, taken from the machine
> +description for the
James Greenhalgh writes:
> -For the generate pass, only the names of the insns matter, from either a
> -named @code{define_insn} or a @code{define_expand}. The compiler will
> +When expanding from gimple to RTL, only named @code{define_insn}
> +constructs and @code{define_expand} constructs are u
On 04/08/14 14:07, Mike Stump wrote:
Something broke in the compiler to cause combine to incorrectly optimize:
(insn 12 11 13 3 (set (reg:SI 604 [ D.6102 ])
(lshiftrt:SI (subreg/s/u:SI (reg/v:DI 601 [ x ]) 0)
(reg:SI 602 [ D.6103 ]))) t.c:47 4436 {lshrsi3}
(expr_list:
James Greenhalgh writes:
> If the output control string starts with a @samp{@@}, then it is actually
> a series of templates, each on a separate line. (Blank lines and
> leading spaces and tabs are ignored.) The templates correspond to the
> -pattern's constraint alternatives (@pxref{Multi-Al
On 01/12/15 14:51, Magnus Granberg wrote:
måndag 12 januari 2015 12.11.17 skrev H.J. Lu:
On Mon, Jan 12, 2015 at 12:03 PM, Jeff Law wrote:
On 01/12/15 12:59, H.J. Lu wrote:
I don't know if -pg will work PIE on any targets. For Linux/x86
the choices of crt1.o are
%{!shared: %{pg|p|profile:g
Thanks for tackling this.
[Sorry, just realised Jeff is going through this ATM too, so sorry for
any dups]
I think Sandra and probably others prefer to avoid an explicit future
tense, e.g. "X is substituted" rather than "X will be substituted".
James Greenhalgh writes:
> @@ -286,15 +284,15 @@ u
On 01/06/15 04:21, James Greenhalgh wrote:
Hi,
This patch updates the RTL Template section of md.texi.
I was aiming to:
* Remove outdated details of the compiler.
* Remove long or obscure words that, while accurate, only served to
obfuscate a simple idea.
* Refer to similar thing
The GNU coding standards say:
"Please do not write ‘()’ after a function name just to indicate it is a
function."
I've checked in this patch to fix some instances of that in the GCC manual.
-Sandra
2015-01-12 Sandra Loosemore
gcc/
* doc/invoke.texi ([-Wsuggest-attribute=]
måndag 12 januari 2015 12.11.17 skrev H.J. Lu:
> On Mon, Jan 12, 2015 at 12:03 PM, Jeff Law wrote:
> > On 01/12/15 12:59, H.J. Lu wrote:
> >> I don't know if -pg will work PIE on any targets. For Linux/x86
> >> the choices of crt1.o are
> >>
> >> %{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%
Two patches to make the new cxx11-shim_facets.cc file compile when
RTTI and wchar_t are disabled.
Tested x86_64-linux, commited to trunk.
commit d2cbfa8426fae046eea01630e24d4d15c9aa1e61
Author: Jonathan Wakely
Date: Mon Jan 12 11:46:57 2015 +
PR libstdc++/64553
* src/c++11
I was confused by the description of -Wbad-function-cast. It talks
about function calls, but the malloc example looked more like a
declaration, and IIRC it's not valid to redeclare functions from the
standard C library with the wrong return type (or at the very least we
shouldn't encourage doi
On 01/06/15 04:21, James Greenhalgh wrote:
Hi,
This patch updates the text in the "Output Template" and "Output
Statement" sections of md.texi.
I was aiming to:
* Remove outdated details of the compiler.
* Remove long or obscure words that, while accurate, only served to
obfuscate
On 01/12/15 12:59, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, giving up for all vector mode extensions
is unnecessary, but unlike scalar integer extensions, where the low part
of the extended value is the original value, for vectors this is not true,
thus the old value is lost. Which mean
On 01/11/15 12:26, Ilya Verbin wrote:
On 09 Jan 10:29, Thomas Schwinge wrote:
As this was the only use of ENABLE_LTO in the testsuite, I suggest to
also remove it from the gcc/Makefile.in:site.exp rule.
Done.
Here is an updated and retested patch. OK for trunk?
gcc/
* Makefile.in (s
Hi Andre,
+ if (INDIRECT_REF_P (parmse.string_length))
+/* In chains of functions/procedure calls the string_length already
+ is a pointer to the variable holding the length. Therefore
+ remove the deref on call. */
+parmse.string_length = TREE_OPERAND (p
This is a minimal backport of features added to GCC 5 to enable use
of binutils 2.25 with GCC 4.9 for MIPS soft-float builds. Further
details in the PR:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64569
The commits which are being backported are listed below (the last
one is posted but not commi
On Mon, Jan 12, 2015 at 09:53:16PM +0100, Bernd Edlinger wrote:
> I am asking if we plan to merge the TSAN runtime from the LLVM tree soon, or
> if it is better to cherry pick
No.
> specific changes from there.
Yes, I'll try to cherry-pick those tomorrow.
> I am especially interested in fixing
Hi Jakub,
I am asking if we plan to merge the TSAN runtime from the LLVM tree soon, or if
it is better to cherry pick
specific changes from there.
I am especially interested in fixing these two issues, but there may be other
important improvements too:
https://gcc.gnu.org/bugzilla/show_bug.cg
On 01/12/15 13:28, Jakub Jelinek wrote:
Hi!
This patch optimizes away TRUNC_MOD_EXPR by constant second argument
(if not 0 and not type's minimum) if the range of the first argument
is already known to be [-op1 + 1, op1 - 1] or its subset.
Bootstrapped/regtested on x86_64-linux and i686-linux,
On Mon, Jan 12, 2015 at 01:37:47PM -0700, Jeff Law wrote:
> On 01/12/15 13:01, Jakub Jelinek wrote:
> >On the following testcase we ICE with -Os -Wtype-limits, as
> >VR_UNDEFINED has NULL vr0->min and vr0->max. From what the code
> >does I believe the code only means to handle VR_RANGE and not any
On 01/12/15 13:01, Jakub Jelinek wrote:
Hi!
On the following testcase we ICE with -Os -Wtype-limits, as
VR_UNDEFINED has NULL vr0->min and vr0->max. From what the code
does I believe the code only means to handle VR_RANGE and not anything else.
Bootstrapped/regtested on x86_64-linux and i686-l
On 01/12/15 13:19, Jakub Jelinek wrote:
Hi!
The 991213-3.c testcase ICEs on aarch64-linux with -mabi=ilp32
since wide-int merge. The problem is that
x = convert_memory_address (Pmode, x)
is used twice on a VOIDmode CONST_INT, which is wrong.
For non-VOIDmode rtl the second convert_memory_addres
On 01/12/15 13:26, Jakub Jelinek wrote:
Hi!
For -mstack-arg-probe we push %rax and/or %r10 in the prologue, and
mark that insn as RTX_FRAME_RELATED_P. But that means that the dwarf2 pass
also considers that the %rax/%r10 registers, which are call used, to be
saved in the unwind info, but they a
Hi!
This patch optimizes away TRUNC_MOD_EXPR by constant second argument
(if not 0 and not type's minimum) if the range of the first argument
is already known to be [-op1 + 1, op1 - 1] or its subset.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2015-01-12 Jakub Jelinek
On 01/12/15 13:08, Jakub Jelinek wrote:
Hi!
Various gcc.dg/vect/ testcases now fail on the trunk with -fpic.
The problem is that they expect that the global vars bind locally and
vectorizer can increase their alignment, but with -fpic that does not
work, as one can interpose them.
Fixed by addi
On 01/12/15 13:10, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, HPUX doesn't have scalbln, but does have ldexp and
that function is already used in gcj-dump, so supposedly it is more portable
to use ldexp. Also in glibc it is defined in libc in addition to libm.
Bootstrapped/regtested on x
Hi!
For -mstack-arg-probe we push %rax and/or %r10 in the prologue, and
mark that insn as RTX_FRAME_RELATED_P. But that means that the dwarf2 pass
also considers that the %rax/%r10 registers, which are call used, to be
saved in the unwind info, but they are never restored, which makes the
dwarf2
As suggested by Andreas in the PR, the simplest fix for this problem is
to disable the various trunc* patterns for TARGET_COLDFIRE. That's
precisely what this patch does.
Built cross compilers with and without the m68k.md hunk. Verified the
test failed without the m68k.mk hunk and passed w
Hi!
The 991213-3.c testcase ICEs on aarch64-linux with -mabi=ilp32
since wide-int merge. The problem is that
x = convert_memory_address (Pmode, x)
is used twice on a VOIDmode CONST_INT, which is wrong.
For non-VOIDmode rtl the second convert_memory_address
is a NOP, but for VOIDmode the second ca
---
gcc/ChangeLog-2014| 10 ++
gcc/config/arm/arm-cores.def | 1 +
gcc/config/arm/arm-tables.opt | 3 +++
gcc/config/arm/arm-tune.md| 3 ++-
gcc/config/arm/arm.c | 22 ++
gcc/config/arm/arm.md | 11 +--
gcc/config/arm/bpabi.h
---
gcc/config/aarch64/aarch64.md | 1 +
gcc/config/arm/xgene1.md | 531 ++
2 files changed, 532 insertions(+)
create mode 100644 gcc/config/arm/xgene1.md
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 12e1054..1f6b
Marcus & Ramana,
Attached is the updated---and hopefully final---revision of the changes to
get XGene-1 properly wired up in the AArch64 and AArch64 backends.
On the AArch64 side, we've only removed the URL from the credits of the
xgene1.md file and the remaining content is unchanged (safe for
To keep this change separately buildable from the pipeline model,
this patch directs the APM XGene-1 to use the generic scheduling
model.
---
gcc/ChangeLog-2014 | 8 +++
gcc/config/aarch64/aarch64-cores.def | 1 +
gcc/config/aarch64/aarch64-tune.md | 2 +-
gcc/config/aarc
---
gcc/config/aarch64/aarch64.md | 2 +-
gcc/config/arm/types.md | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 1f6b1b6..98f4f30 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aar
On Mon, Jan 12, 2015 at 12:03 PM, Jeff Law wrote:
> On 01/12/15 12:59, H.J. Lu wrote:
>>
>> I don't know if -pg will work PIE on any targets. For Linux/x86
>> the choices of crt1.o are
>>
>> %{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}}
>>
>> -shared, -pg and -pie are mutually exc
Hi!
As mentioned in the PR, HPUX doesn't have scalbln, but does have ldexp and
that function is already used in gcj-dump, so supposedly it is more portable
to use ldexp. Also in glibc it is defined in libc in addition to libm.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Hi!
Various gcc.dg/vect/ testcases now fail on the trunk with -fpic.
The problem is that they expect that the global vars bind locally and
vectorizer can increase their alignment, but with -fpic that does not
work, as one can interpose them.
Fixed by adding dg-add-options bind_pic_locally. Boots
Hi!
This patch changes the libgcj*.pc installed filename to match the new GCC
versioning scheme.
Bootstrapped/regtested on x86_64-linux and i686-linux, tested make install.
-rw-r--r--. 1 jakub jakub 192 Jan 12 21:02
/tmp/blah/usr/local/lib64/pkgconfig/libgcj-5.pc
-rw-r--r--. 1 jakub jakub 192 J
> On 09 Jan 12:45, Jakub Jelinek wrote:
> > --- gcc/cgraphunit.c.jj 2015-01-09 12:01:33.0 +0100
> > +++ gcc/cgraphunit.c2015-01-09 12:22:27.742692667 +0100
> > @@ -2108,11 +2108,14 @@ ipa_passes (void)
> >if (g->have_offload)
> > {
> > section_name_prefix = OFF
Hi!
On the following testcase we ICE with -Os -Wtype-limits, as
VR_UNDEFINED has NULL vr0->min and vr0->max. From what the code
does I believe the code only means to handle VR_RANGE and not anything else.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2015-01-12 Jakub Jel
Hi!
As mentioned in the PR, giving up for all vector mode extensions
is unnecessary, but unlike scalar integer extensions, where the low part
of the extended value is the original value, for vectors this is not true,
thus the old value is lost. Which means we can perform REE, but only if
all uses
Reported by David Binderman within discussion of PR jit/63854.
Before/after jit.sum has 7272 passes.
Committed to trunk as r219487.
gcc/jit/ChangeLog:
* jit-playback.c (gcc::jit::playback::context::read_dump_file):
Add missing fclose on error-handling path.
---
gcc/jit/jit-playb
On 01/12/15 12:29, H.J. Lu wrote:
Is this an inherent restriction of -fPIE, or is it merely an implementation
detail? If the latter, is that implementation detail a target issue? ie,
could we have a target that supports profiling in conjunction with -fPIE?
If so, then this test seems too restr
On Mon, Jan 12, 2015 at 10:09 AM, Jeff Law wrote:
> On 01/11/15 16:58, H.J. Lu wrote:
>>
>> Hi,
>>
>> This patch adds check_effective_target_pie to check if the current
>> multilib generatse PIE by default. I will submit other patches to use
>> it. OK for trunk?
>>
>> Thanks.
>>
>> H.J.
>> ---
>
Hello!
> Upstream libffi has added support for Go closures (using the static chain),
> and support for complex numbers. Perhaps less relevant is new support for
> arc, microblaze, moxie, nios, and or1k targets.
>
> Without additional changes for Go, this merge has little effect. Within the
> gcc
On 01/11/15 04:40, Oleg Endo wrote:
Any particular reason why the SEQUENCE handling isn't done first, then
the REG_INC and CALL insn handling? I'd probably explicitly return
false if we had a sequence and none of its elements returned true.
There's no need to check anything on the toplevel SEQU
On 13 January 2015 at 00:01, Mike Stump wrote:
> On Jan 11, 2015, at 2:33 PM, Prathamesh Kulkarni
> wrote:
>> oops, sorry about this. We will build further flattening patches with
>> --enable-languages=all,go,jit,ada.
>> Shall that cover all the front-ends ?
>
> No objc++ is non-default:
Thanks!
On 01/10/15 09:35, Matthew Fortune wrote:
I guess so. I took the phrasing below for (high:m exp) to mean that high
only made sense when used with lo_sum.
True. But one can use a single high with different lo_sum expressions
when those lo_sum expressions are related.
So you might have a singl
On Jan 11, 2015, at 2:33 PM, Prathamesh Kulkarni
wrote:
> oops, sorry about this. We will build further flattening patches with
> --enable-languages=all,go,jit,ada.
> Shall that cover all the front-ends ?
No objc++ is non-default:
$ grep build_by_default */config-lang.in
go/config-lang.in:build
On 01/10/15 05:51, Richard Sandiford wrote:
I agree this is the kind of thing we'd need to consider if we were
deciding whether it's valid to connect a (lo_sum (high x+N) x+N) to an
existing (high x). But this code is handling cases where the connection
has already been made and we're trying to
On 01/11/15 17:25, H.J. Lu wrote:
target nonpic is always false for -fPIE since it defines both __PIC__ and
__PIE__. This patch changes gcc.dg/tree-ssa/ssa-store-ccp-3.c to make it
to pass with -fPIE by excluding PIE when nonpic is true. OK to for trunk?
Thanks.
H.J.
---
gcc/testsuite/gcc.d
On Thu, Jan 8, 2015 at 12:33 PM, Patrick Wollgast
wrote:
> A short recap again:
>
> Latest patch, changelog and a test program (further information about
> the program in the mail):
> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg03368.html
>
>
> Approved:
> * gcc/config/i386/*
> * libgcc/*
> * li
On 01/11/15 16:58, H.J. Lu wrote:
Hi,
This patch adds check_effective_target_pie to check if the current
multilib generatse PIE by default. I will submit other patches to use
it. OK for trunk?
Thanks.
H.J.
---
2015-01-11 H.J. Lu
* gcc.target/i386/pie.c: New test.
* lib/t
On 11/11/14 23:13, Martin Uecker wrote:
Hi,
this proposed patch adds an option "-Warray-bounds=" in addition to
"-Warray-bound". "-Warray-bounds=1" corresponds to "-Warray-bound".
For higher warning levels more warnings about optional accesses
outside of arrays are emitted. For example, warning
On 01/12/15 04:56, Evgeny Stupachenko wrote:
Agree, I've missed the usage of the function
"__register_frame_info_bases" (frame_dummy assembly had only indirect
call when I miss "-pie" in compilation).
There is no reference on glibc that way. Sorry for the confusion.
So that is potentially buggy r
On Mon, Jan 12, 2015 at 05:32:14PM +0100, Thomas Schwinge wrote:
> I have now committed the patch to gomp-4_0-branch in the following form.
> The issues raised above remain to be resolved.
>
> In spirit against the tree.h header flattening, I had to keep the
> #include "include/gomp-constants.h" i
On 01/12/15 08:54, Kyrill Tkachov wrote:
Hi all,
This recently added test adds -pg to its dg-options but not all targets
support
this and fail at link-time with "bin/ld: cannot find -lc_p".
Looking around I see that all tests that use -pg also do a
dg-require-profiling.
This patch adds that.
On 01/12/15 10:01, Jeff Law wrote:
This indicates a violation of the type safety invariants we're adding to
GCC. Simply changing the code to use rtx rather than rtx_insn is
probably a step in the wrong direction.
Part of the problem here is that RTX_FRAME_RELATED_P is valid on both
rtx_insn and
On Mon, Jan 12, 2015 at 7:52 AM, Kyrill Tkachov wrote:
> Hi all,
>
> As raised in https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01237.html and
> discussed in that thread, using __builtin_sqrt for vsqrt_f64 may end up in a
> call to the library sqrt at -O0. To avoid that this patch uses a target
>
This is an API change to one of the libgccjit.h entrypoints.
Although we don't yet guarantee API stability for libgccjit, I'm loathe
to break things without strong reasons.
I think that in this case the reasons *are* sufficient (see below),
and hence I feel that it's best to get this change in now
Hi,
gcc.target/i386/pr64291-1.c has 2 issues:
1. Stack variables, n and d, aren't initialized.
2. dnp[dn - 1] |= 1UL<<63; doesn't work with 32-bit long.
I am checking this patch from
https://gcc.gnu.org/bugzilla/attachment.cgi?id=34342
as an obvious fix.
H.J.
2015-01-12 Marc Glisse
Hello!
>> On Wed, Dec 31, 2014 at 01:28:47PM +0100, Allan Sandfeld Jensen wrote:
>> > I recently wanted to use multiversioning for BMI2 specific extensions
>> > PDEP/PEXT, and noticed it wasn't there. So I wrote this patch to add it,
>> > and also added AES, F16C and BMI1 for completeness.
>>
>> A
On 01/11/15 07:02, Chen Gang S wrote:
The related commit "1a1ed14 config/h8300: Use rtx_insn" gives an extra
check for rtx, which will cause building libgcc break, after regress it,
it can still generate the correct assemble code.
The related information is below:
[root@localhost libgcc]# ca
Hi!
On Mon, 22 Dec 2014 16:13:01 +0100, I wrote:
> I'm sending this again with some more people copied -- because I see
> you're working on tree.h/tree-core.h flattening, or know you're familiar
> with GCC plugins. ;-) Here is a question concerning both of that, where
> I'd appreciate your input.
Good, I fully agree. Fortunately the patch applies cleanly to the 4.9
branch and regtests without errors. Thus I have applied it as r219475.
Will do 4.8 soon.
Cheers,
Janus
2015-01-12 9:30 GMT+01:00 Paul Richard Thomas :
> Dear Janus,
>
> Since it is a regression, by all means update the branch
I found while checking ToT test status...
define_insn implicitly wraps the pattern in a parallel if there are
multiple instructions. Several MIPS patterns have an explicit parallel
which is mostly handled correctly but the code in 'gen_insn' does not
manage to locate the clobbers inside an explici
On Fri, Jan 09, 2015 at 01:58:45PM +0100, Richard Biener wrote:
> On Tue, Dec 30, 2014 at 10:23 PM, Magnus Granberg wrote:
> > fredag 14 november 2014 23.31.48 skrev Magnus Granberg:
> >> måndag 10 november 2014 21.26.39 skrev Magnus Granberg:
> >> > > Rainer
> >> >
> >> > Thanks Rainer for th
Hi all,
This recently added test adds -pg to its dg-options but not all targets
support
this and fail at link-time with "bin/ld: cannot find -lc_p".
Looking around I see that all tests that use -pg also do a
dg-require-profiling.
This patch adds that.
With this patch the test doesn't FAIL
1 - 100 of 158 matches
Mail list logo
