Hi Jeff,
Our AIX team is parallely working on the issue that why EH is not
working with static linking on AIX. For time being this patch
will be work around for the issue.
On Thu, Mar 30, 2017 at 1:07 AM, Jeff Law wrote:
> On 03/26/2017 06:05 PM, Joel Brobecker wrote:
>>
>> Hello,
>>
>>> I got
On 3 April 2017 13:32:30 CEST, Sebastian Huber
wrote:
>Allow targets to define the default for the short enums option.
Does this work nowadays?
About 10 years ago I did this for some arm and had to force TREE_CODE at al to
16 bit manually, IIRC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3420
On 04/04/17 09:43, Bernhard Reutner-Fischer wrote:
On 3 April 2017 13:32:30 CEST, Sebastian Huber
wrote:
Allow targets to define the default for the short enums option.
Does this work nowadays?
About 10 years ago I did this for some arm and had to force TREE_CODE at al to
16 bit manually, II
On Mon, Apr 3, 2017 at 9:03 PM, Nathan Sidwell wrote:
> Bill,
> can you give this patch a spin please? I've smoke tested it on a ppc64le
> x-compiler, but don't have one to run executables. regression testing on an
> x86_64-linux system is ok.
>
> The DEPENDENT_TYPE_VALID_P thing is a red herring
On Tue, Apr 4, 2017 at 8:43 AM, Bernhard Reutner-Fischer
wrote:
> On 3 April 2017 13:32:30 CEST, Sebastian Huber
> wrote:
>>Allow targets to define the default for the short enums option.
>
> Does this work nowadays?
> About 10 years ago I did this for some arm and had to force TREE_CODE at al
On Mon, Apr 3, 2017 at 12:32 PM, Sebastian Huber
wrote:
> Allow targets to define the default for the short enums option.
>
> gcc/
>
> * config/arm/arm.c: (ARM_DEFAULT_SHORT_ENUMS): Provide default
> definition.
> * config/arm/rtems.h (ARM_DEFAULT_SHORT_ENUMS) Define.
> ---
On 04/04/17 11:00, Ramana Radhakrishnan wrote:
> static bool
> arm_default_short_enums (void)
> {
>- return TARGET_AAPCS_BASED && arm_abi != ARM_ABI_AAPCS_LINUX;
>+ return ARM_DEFAULT_SHORT_ENUMS;
> }
>
>
>diff --git a/gcc/config/arm/rtems.h b/gcc/config/arm/rtems.h
>index 53cd987..b34bbe8
> We have local modifications in the Ada front-end so I cannot reproduce it
> with the pristine tree either. :-(
I apparently screwed up yesterday, this can be reproduced as such in the
directory of a boostrapped compiler:
eric@polaris:~/build/gcc/native/gcc> rm ada/sem_util.o
eric@polaris:~/bu
On Mon, Apr 3, 2017 at 10:47 PM, Volker Reichelt
wrote:
> The following patch fixes a broken diagnostic:
> #'unary_plus_expr' not supported by expression#
>
> The code to handle UNARY_PLUS_EXPR is already in place in
> cxx_pretty_printer::unary_expression. However, UNARY_PLUS_EXPR
> is not checked
> Le 3 avr. 2017 à 19:00, Jakub Jelinek a écrit :
>
> On Mon, Apr 03, 2017 at 10:56:13AM -0600, Jeff Law wrote:
>> On 04/01/2017 06:24 AM, Jakub Jelinek wrote:
>>> Apparently Darwin has insane default stack size for pthread_create
>>> unless overridden through pthread_attr_setstacksize - 512kB,
> eric@polaris:~/build/gcc/native/gcc> rm ada/sem_util.o
> eric@polaris:~/build/gcc/native/gcc> make ADAFLAGS="-gnatpgn"
> /home/eric/build/gcc/native/./prev-gcc/xgcc -
> B/home/eric/build/gcc/native/./prev-gcc/
> -B/home/eric/install/gcc/x86_64-suse- linux/bin/
> -B/home/eric/install/gcc/x86_64-su
As the testcase shows, elt can become a NULL tree during
FOR_EACH_CONSTRUCTOR_VALUE. So guard against this possibility before
calling reduced_constant_expression_p() recursively.
Tested on ppc64le.
OK for trunk?
PR c++/80294
* constexpr.c (reduced_constant_expression_p): Guard aga
Hi Andrew,
Please find a number of small patches which are adding support to for CRT long
calls, and fixes some errors when generating dwarf information and addresses.
Please let me know if more info is required,
Claudiu
Claudiu Zissulescu (3):
[ARC] Update mode_dependent_address_p hook.
[A
Update arc_mode_dependent_address_p to avoid emitting subreg(mem (reg
..)) when expanding.
gcc/
2016-10-11 Claudiu Zissulescu
* config/arc/arc.c (arc_mode_dependent_address_p): Relax
conditions to take advantage of various optimizations.
---
gcc/config/arc/arc.c | 8 ++--
The use of CFA_FRAME_BASE_OFFSET and ARG_POINTER_CFA_OFFSET macros
leads to wrong offset calculation for DW_OP_fbreg constructions.
Remove them.
gcc/
2016-10-17 Claudiu Zissulescu
* config/arc/arc-protos.h (arc_decl_pretend_args): Remove.
* config/arc/arc.c (arc_decl_pretend_ar
There are situations when the range offered by the bl instruction is
not sufficient to reach CRT routines. Thus, use a long jump
construction.
gcc/
2016-04-21 Claudiu Zissulescu
* config/arc/arc.h (CRT_CALL_STATIC_FUNCTION): Use long calls.
---
gcc/config/arc/arc.h | 9 +
1 fi
Small multiply variants of ARM Cortex-M0, Cortex-M0+ and Cortex-M1 were
relying on the old cost model to work when optimizing for speed. These
stopped being used in r241965 which led to these cores starting to use
mul instructions instead of synthetizing the multiplications. This was
not caught by
Allow targets to define the default for the short enums option.
v2: Move ARM_DEFAULT_SHORT_ENUMS to arm.h.
gcc/
* config/arm/arm.h: (ARM_DEFAULT_SHORT_ENUMS): Provide default
definition.
* config/arm/arm.c: (arm_default_short_enums): Use
ARM_DEFAULT_SHORT_ENUMS.
[dropping devel at rtems dot org as I don't want more bounces]
On Tue, Apr 4, 2017 at 10:07 AM, Sebastian Huber
wrote:
> On 04/04/17 11:00, Ramana Radhakrishnan wrote:
>>>
>>> > static bool
>>> > arm_default_short_enums (void)
>>> > {
>>> >- return TARGET_AAPCS_BASED && arm_abi != ARM_ABI_AAP
On 04/04/17 12:41, Ramana Radhakrishnan wrote:
[dropping devel at rtems dot org as I don't want more bounces]
On Tue, Apr 4, 2017 at 10:07 AM, Sebastian Huber
wrote:
>On 04/04/17 11:00, Ramana Radhakrishnan wrote:
>>>
>>> > static bool
>>> > arm_default_short_enums (void)
>>> > {
>>> >-
On 04/04/17 12:50, Sebastian Huber wrote:
On 04/04/17 12:41, Ramana Radhakrishnan wrote:
[dropping devel at rtems dot org as I don't want more bounces]
On Tue, Apr 4, 2017 at 10:07 AM, Sebastian Huber
wrote:
>On 04/04/17 11:00, Ramana Radhakrishnan wrote:
>>>
>>> > static bool
>>> > arm
On 03/04/17 23:31 +0100, Jonathan Wakely wrote:
On 03/04/17 20:06 +0100, Jonathan Wakely wrote:
On 03/04/17 11:48 -0700, Mike Stump wrote:
[ dup, I sent the wrong from the wrong email address, you might not see it
because of that ]
On Apr 3, 2017, at 11:47 AM, Mike Stump wrote:
On Apr 3, 2
On 04/04/2017 04:27 AM, Richard Biener wrote:
On Mon, Apr 3, 2017 at 9:03 PM, Nathan Sidwell wrote:
However, as you can see there's already a get-out for COMPLEX_TYPE, and I
think the same is needed for VECTOR_TYPE.
Hmm, but that is essentially a hack given that build_complex_type does thin
On 04/03/2017 06:18 PM, Eric Botcazou wrote:
>> On S/390 UNITS_PER_WORD is:
>> 8 with -m64
>> 4 with -m31
>> 8 with -m31 -mzarch
>>
>> This has been chosen to support use of 64 bit registers also in 32 bit
>> code. Code compiled with -m31 -mzarch is supposed to adhere to the 32
>> bit ABI. In ord
On Tue, Apr 04, 2017 at 08:39:59AM +0200, Uros Bizjak wrote:
> > Any thoughts on what to do to generate reasonable code when the shift count
> > comes from memory (e.g. as int variable) or is in the low bits of some XMM
> > regioster?
>
> The problem with int variable from memory is, that shifts a
Hello All,
I just discovered that backtrace_create_state should be called once,
that it is returning some heap-allocated data (which cannot be free-d,
because there is no
backtrace_destroy_state routine).
I suggest the attached patch (against GCC trunk r246678) which just
improves the commen
Revised patch.
* doc/extend.texi (Extended Asm ): Rename to
"Clobbers and Scratch Registers". Add OpenBLAS example.
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 0f44ece..0b0a021 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -7869,7 +7869,7 @@ A com
On Tue, Apr 4, 2017 at 2:00 PM, Jakub Jelinek wrote:
> On Tue, Apr 04, 2017 at 08:39:59AM +0200, Uros Bizjak wrote:
>> > Any thoughts on what to do to generate reasonable code when the shift count
>> > comes from memory (e.g. as int variable) or is in the low bits of some XMM
>> > regioster?
>>
>>
Hi,
I noticed that the already created reference and pointer types
are left in an inconsistent state if the may_alias attribute
is added to a class, in some cases.
The attached patch fixes this by adding another loop over
all type variants of each pointer and reference type.
The new test case 20
On 04/04/17 12:39 +, Bernd Edlinger wrote:
Hi,
I noticed that the already created reference and pointer types
are left in an inconsistent state if the may_alias attribute
is added to a class, in some cases.
The attached patch fixes this by adding another loop over
all type variants of each
On Tue, Apr 4, 2017 at 1:31 PM, Nathan Sidwell wrote:
> On 04/04/2017 04:27 AM, Richard Biener wrote:
>>
>> On Mon, Apr 3, 2017 at 9:03 PM, Nathan Sidwell wrote:
>
>
>>> However, as you can see there's already a get-out for COMPLEX_TYPE, and I
>>> think the same is needed for VECTOR_TYPE.
>>
>>
>
On Tue, Apr 4, 2017 at 5:05 AM, wrote:
>
> I just discovered that backtrace_create_state should be called once, that it
> is returning some heap-allocated data (which cannot be free-d, because there
> is no
> backtrace_destroy_state routine).
>
> I suggest the attached patch (against GCC trunk r2
On 04/04/2017 09:00 AM, Richard Biener wrote:
tree
add_builtin_type (const char *name, tree type)
{
tree id = get_identifier (name);
tree decl = build_decl (BUILTINS_LOCATION, TYPE_DECL, id, type);
return lang_hooks.decls.pushdecl (decl);
}
this seems to miss setting TYPE_NAME (type) =
On 2017-04-04 15:38, Ian Lance Taylor wrote:
On Tue, Apr 4, 2017 at 5:05 AM, wrote:
I just discovered that backtrace_create_state should be called once,
that it
is returning some heap-allocated data (which cannot be free-d, because
there
is no
backtrace_destroy_state routine).
I suggest t
I'll try the POC patch in a bit (kind of ugly as we have to replicate this for
a whole bunch of types, I guess).
Just FYI, I noticed this similar bug report came in today, not sure about the
types: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80309
-- Bill
Bill Schmidt, Ph.D.
GCC for Linux on
On 04/04/2017 09:57 AM, Bill Schmidt wrote:
I'll try the POC patch in a bit (kind of ugly as we have to replicate this for
a whole bunch of types, I guess).
thanks. Yup, all rs6000's builtins. Wrapping it all in a
tree my_builtin_vector (char const *name, tree elt, unsigned num);
helper woul
On Tue, Apr 4, 2017 at 6:50 AM, wrote:
> On 2017-04-04 15:38, Ian Lance Taylor wrote:
>
>> How about we just add backtrace_destroy_state?
>
> I don't know how to code that. In my
> https://github.com/bstarynk/melt-monitor I observed that calling free on
> such
> a struct backtrace_state pointer i
On 2017-04-04 16:04, Ian Lance Taylor wrote:
On Tue, Apr 4, 2017 at 6:50 AM, wrote:
On 2017-04-04 15:38, Ian Lance Taylor wrote:
How about we just add backtrace_destroy_state?
I don't know how to code that. In my
https://github.com/bstarynk/melt-monitor I observed that calling free
on
su
Hi,
When creating static bounds for foo below we end up with:
*((unsigned long *) &__chkp_bounds_of_foo + 8) =
~(__builtin_ia32_sizeof (foo) + ((long unsigned int) &foo +
18446744073709551615));
This fails in gimplify_function_tree with gcc_assert (!VOID_TYPE_P
(TREE_TYPE (*expr_p)));
Is it OK?
On Tue, Apr 04, 2017 at 02:33:24PM +0200, Uros Bizjak wrote:
> > I assume split those before reload. Because we want to give reload a chance
> > to do the zero extension on GPRs if it is more beneficial, and it might
> > choose to store it into memory and load into XMM from memory and that is
> >
> On Apr 1, 2017, at 12:15 PM, Gerald Pfeifer wrote:
>
> On Fri, 31 Mar 2017, Bill Schmidt wrote:
>> OK, I've committed this as r246617. Gerald, please let me know
>> if you'd like any changes to the text.
>
> This looks fine to me.
>
> Just "These are described briefly below." I'd written a
On Apr 4, 2017, at 2:20 AM, Dominique d'Humières wrote:
>> Dominique has already tested it on Darwin 16 and said he'll test on Darwin
>> 10; I'm waiting for those results.
>>
>> Jakub
>
> No problem with darwin10.
I'm fine with the patch.
On Apr 4, 2017, at 4:19 AM, Jonathan Wakely wrote:
> Here's one more that somebody reported to the unofficial github
> mirror: https://github.com/gcc-mirror/gcc/pull/6/files
>
> Committed to trunk.
Thanks.
On 03/18/2017 12:20 PM, Jan-Benedict Glaw wrote:
Hi Richard, Catherine, Matthew
On Thu, 2017-03-02 14:40:46 +0100, Richard Biener wrote:
[...]
On IRC we decided to wait&see for the TREE_NO_WARNING issue. So the
following is what I committed.
Bootstrapped / tested on x86_64-unknown-linux-gnu.
All the MIPS compilers will fail to build using the trunk due to a
couple minor uninitialized memory issues.
First in mips_multi_add we add an uninitialized mips_multi_member object
to the mips_multi_members vec. It's easy enough to just memset the new
member.
Second in mips_expand_vec_pe
On 04/04/2017 09:07 AM, Alexander Ivchenko wrote:
Hi,
When creating static bounds for foo below we end up with:
*((unsigned long *) &__chkp_bounds_of_foo + 8) =
~(__builtin_ia32_sizeof (foo) + ((long unsigned int) &foo +
18446744073709551615));
This fails in gimplify_function_tree with gcc_ass
On 04/04/17 11:30, Thomas Preudhomme wrote:
> Small multiply variants of ARM Cortex-M0, Cortex-M0+ and Cortex-M1 were
> relying on the old cost model to work when optimizing for speed. These
> stopped being used in r241965 which led to these cores starting to use
> mul instructions instead of synth
Gerald, (or who does this)
Since shared memory parallel programming with Fortran is now a Standard feature
of the language, we would like to support full parallelism through the use of
mpich and OpenCorrays.
We choose mpich as a default only because it is very stable. We choose
OpenCoarrays becau
Hi,
gcc.target/arm/atomic_loaddi_11.c testcase contributed in r246365 does
not test the changed code since ARMv7-R does not have division
instructions in ARM state. This patch changes it to target Cortex-R5
processor instead which does have division instructions in ARM state.
ChangeLog entry is
Ping?
Best regards,
Thomas
On 30/03/17 11:46, Thomas Preudhomme wrote:
Ping?
Best regards,
Thomas
On 27/03/17 12:15, Thomas Preudhomme wrote:
Hi,
Currently GCC is happy to use LDRD to perform a 64bit load on ARMv7-R,
as shown by the testcase on this patch. However, LDRD is only atomic
whe
On 04/01/2017 06:20 AM, Jakub Jelinek wrote:
Hi!
As discussed in the PR, in the following testcase we don't if-convert
with the generic (and many other) tuning, because we default to
--param max-rtl-if-conversion-insns=1 in most of the tunings.
The problem we have is with multiple cmov instructi
At first blush, the POC patch breaks every test that uses -flto. I'll see if I
can dig deeper after a bit,
in case this doesn't make the problem obvious.
Thanks,
Bill
> On Apr 4, 2017, at 9:02 AM, Nathan Sidwell wrote:
>
> On 04/04/2017 09:57 AM, Bill Schmidt wrote:
>> I'll try the POC patch
> This worked as well. I've committed the following patch:
>
> gcc/ada/ChangeLog:
>
> 2017-04-04 Andreas Krebbel
>
> * system-linux-s390.ads: Use Long_Integer'Size to define
> Memory_Size.
Thanks!
--
Eric Botcazou
> We choose mpich as a default only because it is very stable.
Why are why tying ourselves to one MPI implementation?
FX
Hi FX,
we don't really do. You can use other MPI implementation as well, albeit not all
features are implemented in all the others. For failed images support we needed
the fault tolerance support for MPI, which I see only in mpich from 3.2 on. The
other MPI implementations publicy available do not
On 04/04/2017 01:40 PM, Bill Schmidt wrote:
At first blush, the POC patch breaks every test that uses -flto. I'll see if I
can dig deeper after a bit,
in case this doesn't make the problem obvious.
Try this.
nathan
--
Nathan Sidwell
Index: c-family/c-common.c
===
Resending as plain text (although now I realize my reply is at least partially
redundant since reading Andre’s email):
On April 4, 2017 at 10:44:09 AM, FX
(fxcoud...@gmail.com(mailto:fxcoud...@gmail.com)) wrote:
> > We choose mpich as a default only because it is very stable.
>
> Why are wh
On April 4, 2017 at 9:48:23 AM, Jerry DeLisle
(jvdeli...@charter.net(mailto:jvdeli...@charter.net)) wrote:
> Gerald, (or who does this)
>
> Since shared memory parallel programming with Fortran is now a Standard
> feature
> of the language, we would like to support full parallelism th
On 04/04/2017 10:44 AM, FX wrote:
>> We choose mpich as a default only because it is very stable.
>
> Why are why tying ourselves to one MPI implementation?
>
> FX
>
Not tying ourselves at all. This just gives users who install gcc manually with
the ./configure process a default to use and only
Jeff Law writes:
> All the MIPS compilers will fail to build using the trunk due to a
> couple minor uninitialized memory issues.
>
> First in mips_multi_add we add an uninitialized mips_multi_member object
> to the mips_multi_members vec. It's easy enough to just memset the new
> member.
>
> S
Hi!
While generic tree sharing is usually harmless, because we unshare
everything before gimplification, on the following testcase a match.pd
pattern that uses @1 twice introduces tree sharing during the C
gimplification langhook, so after everything has been unshared.
The following patch fixes i
Hi!
aggregate_value_p is called often very early during compilation, e.g.
from allocate_function or during gimplification of a call with lhs.
The problem with that is e.g. that on x86_64 -m64 -mno-sse we can't
include , because the always_inline inline functions
in mmx and 3dnow intrinsic headers
Hi!
When I've implemented vector -fsanitize=signed-integer-overflow,
we've started to emit weirdo warnings on e.g. the following testcase.
There is really no call with return value that changes ABI
based on ISA options, there is just an internal fn call that is expanded
completely inline (UBSAN_C
This patch to libgo backports a change from Go tip to make the time
test ParseInLocation more robust. This lets the test pass on systems
that have updated their timezone database to 2017a or later. This
fixes GCC PR 80302. Bootstrapped and ran Go time test on
x86_64-pc-linux-gnu. Committed to m
We got a bug report from a customer pointing out that calling
promise::set_value on a moved-from promise crashes instead of throwing
an exception with error code future_errc::no_state.
This fixes it, by moving the _S_check calls to *before* we deference
the pointer that the calls check!
This pas
On April 4, 2017 9:29:19 PM GMT+02:00, Jakub Jelinek wrote:
>Hi!
>
>When I've implemented vector -fsanitize=signed-integer-overflow,
>we've started to emit weirdo warnings on e.g. the following testcase.
>
>There is really no call with return value that changes ABI
>based on ISA options, there is
On 04/04/2017 01:15 PM, Matthew Fortune wrote:
Jeff Law writes:
All the MIPS compilers will fail to build using the trunk due to a
couple minor uninitialized memory issues.
First in mips_multi_add we add an uninitialized mips_multi_member object
to the mips_multi_members vec. It's easy enough
> On Apr 4, 2017, at 1:02 PM, Nathan Sidwell wrote:
>
> On 04/04/2017 01:40 PM, Bill Schmidt wrote:
>> At first blush, the POC patch breaks every test that uses -flto. I'll see
>> if I can dig deeper after a bit,
>> in case this doesn't make the problem obvious.
>
> Try this.
Thanks, Nathan,
On 04/04/17 14:58, Jonathan Wakely wrote:
> On 04/04/17 12:39 +, Bernd Edlinger wrote:
>> Hi,
>>
>> I noticed that the already created reference and pointer types
>> are left in an inconsistent state if the may_alias attribute
>> is added to a class, in some cases.
>>
>> The attached patch fixe
The attached patch fixes PR 79890. Bootstrapped and regression
tested on s390x biarch and s390.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
gcc/ChangeLog-pr79890
PR target/79890
* config/s390/s390.c (s390_register_info_gprtofpr): Return if
call_eh_return is true
On 5 April 2017 at 00:29, Bernd Edlinger wrote:
>> The new test doesn't really belong in the libstdc++, does it?
>>
>> If this is a bug in the front-end then a reduced version of the test
>> belongs in the g++ testsuite.
>>
>
> Yes, I moved the test case to the g++.dg/lto branch, where it
> fortun
All,
The attached patch modifies the contrib/download_prerequisites script to work
on macOS.
The revised script detects the operating system and adjusts the shasum and md5
commands
to their expected name and arguments on macOS. The revised script also uses
curl if
wget is not present. macO
On 04/05/17 00:33, Ville Voutilainen wrote:
> On 5 April 2017 at 00:29, Bernd Edlinger wrote:
>>> The new test doesn't really belong in the libstdc++, does it?
>>>
>>> If this is a bug in the front-end then a reduced version of the test
>>> belongs in the g++ testsuite.
>>>
>>
>> Yes, I moved the
73 matches
Mail list logo
