Output DWARFv5+ DW_AT_alignment for non-default alignment of
variables, fields and types.
Regstrapped on x86_64-linux-gnu and i686-linux-gnu. Ok to install?
for include/ChangeLog
PR debug/63238
* dwarf2.def (DW_AT_alignment): New.
for gcc/ChangeLog
PR debug/63238
On Fri, Aug 26, 2016 at 3:09 AM, Jonathan Wakely wrote:
> OK for trunk, thanks.
Committed as r239794.
Thanks!
--
Regards,
Tim Shen
On Fri, Aug 26, 2016 at 03:29:50PM -0400, Michael Meissner wrote:
> These patches add more tests to the PowerPC vector initialization tests. Four
> of the tests added (#4, #5, #8, and #9) just try to do a bunch of vector
> initializations for the different vector type (char, short, float, and
> d
On Fri, Aug 26, 2016 at 10:28:25PM +0200, Mikael Morin wrote:
> Hello,
>
> Le 26/08/2016 à 20:27, Steve Kargl a écrit :
> > Here are two possible patches for PR fortran/77391. The first
> > patch treats the invalid code as a GNU Fortran extension as
> > gfortran current accepts the invalid code.
The AIX assembler implicitly inserts the length information at the
beginning of DWARF debugging sections. In 64 bit mode, it also
implicitly inserts the 64 bit DWARF extension escape sequence. GCC
must emit DWARF offsets with a size that matches the 64 bit extension.
This patch overrides DWARF_O
On Fri, Aug 26, 2016 at 10:28:25PM +0200, Mikael Morin wrote:
> Hello,
>
> Le 26/08/2016 à 20:27, Steve Kargl a écrit :
> > Here are two possible patches for PR fortran/77391. The first
> > patch treats the invalid code as a GNU Fortran extension as
> > gfortran current accepts the invalid code.
On Fri, 26 Aug 2016, Florian Weimer wrote:
> The crucial question is whether GCC will start assuming that pointers returned
> by malloc (or attribute-malloc functions) have such an alignment. That seems
> impossible.
GCC's assumptions about the alignment of pointers returned by malloc are
more
On 08/26/2016 02:45 PM, Florian Weimer wrote:
In the end, max_align_t is ignored by allocators, and applications
cannot rely on it as a result.
Hmm, well, in that case I suppose I should change Emacs to ignore
max_align_t as well. Thanks for the heads-up.
On 08/26/2016 01:54 PM, Joseph Myers wrote:
Such an increase is of course an ABI change, but a reasonably safe
one, in that max_align_t doesn't tend to appear in library interfaces
(rather, it's something to use when writing allocators and similar
code;
It should be fine, though I would like to
On 08/26/2016 10:54 PM, Joseph Myers wrote:
Such an increase is of course an ABI change, but a reasonably safe
one, in that max_align_t doesn't tend to appear in library interfaces
(rather, it's something to use when writing allocators and similar
code; most matches found on codesearch.debian.net
On Fri, 26 Aug 2016, Marc Glisse wrote:
> On Fri, 26 Aug 2016, Joseph Myers wrote:
>
> > And since __float128 is architecture-specific, there
> > isn't a preprocessor conditional that means "__float128 is available"
>
> That's what __SIZEOF_FLOAT128__ was supposed to be for. I didn't add it to
>
The first aspect of this patch is to add some checking of fix-it hints.
The idea is to put this checking within the rich_location machinery,
rather than requiring every diagnostic to implement it for itself.
The fixits within a rich_location are "atomic": all must be valid for
any to be applicable
On Fri, 26 Aug 2016, Joseph Myers wrote:
And since __float128 is architecture-specific, there
isn't a preprocessor conditional that means "__float128 is available"
That's what __SIZEOF_FLOAT128__ was supposed to be for. I didn't add it to
itanium because zombies, and it looks like powerpc did
The _FloatN, _FloatNx, _DecimalN and _DecimalNx types are specified in
such a way that they are basic types, meaning that max_align_t must be
at least as aligned as those types.
On 32-bit x86, max_align_t is currently 8-byte aligned, but
_Decimal128 and _Float128 are 16-byte aligned, so the alignm
On Fri, Aug 26, 2016 at 10:28:25PM +0200, Mikael Morin wrote:
> Hello,
>
> Le 26/08/2016 à 20:27, Steve Kargl a écrit :
> > Here are two possible patches for PR fortran/77391. The first
> > patch treats the invalid code as a GNU Fortran extension as
> > gfortran current accepts the invalid code.
I've committed this to gomp4 branch. The lto device compiler was ICEing when
reading in the offload inline statistics. The root cause was due to it not
having the function bodies of some functions, it therefore didn't try and read
callee statistics. Thus starting reading the next function's
Hello,
Le 26/08/2016 à 20:27, Steve Kargl a écrit :
Here are two possible patches for PR fortran/77391. The first
patch treats the invalid code as a GNU Fortran extension as
gfortran current accepts the invalid code. The second patch
enforces the standard. As I think gfortran should encourage
These patches add more tests to the PowerPC vector initialization tests. Four
of the tests added (#4, #5, #8, and #9) just try to do a bunch of vector
initializations for the different vector type (char, short, float, and double).
These other patches (#6, #7) test the code generated in paches #5
Joey,
Thanks for your understanding response and sorry for my late reply. I
have been badly caught up in work related stuff, lately.
As you might already be aware of, -mno-PDITR and -mSPB are primarily
targeted for MMU-less targets (or where you do have MMU but do not
want to/cannot use address t
Richard Earnshaw (lists) wrote:
>
> So isn't the real bug that we've permitted the user to create an object
> that is too large for the data model?
No that's a different issue I'm not trying to address here. The key is that as
long
as the start of the symbol is in range, we should be able to lin
Jiong Wang wrote:
> The -fomit-frame-pointer is really broken on aarch64_find_eh_return_addr
Yes, that's a good conclusion. However even with the frame pointer there are
cases that fail, for example it will access LR off SP even after alloca. In fact
we're lucky it works at all sometimes...
> I
Hi Steve,
I am strongly for the enforcement of the standard. Please apply patch #2.
Cheers
Paul
On 26 August 2016 at 20:27, Steve Kargl
wrote:
> Here are two possible patches for PR fortran/77391. The first
> patch treats the invalid code as a GNU Fortran extension as
> gfortran current acce
Here are two possible patches for PR fortran/77391. The first
patch treats the invalid code as a GNU Fortran extension as
gfortran current accepts the invalid code. The second patch
enforces the standard. As I think gfortran should encourage
standard conformance, I am inclined to commit the seco
Previous, fix-it hints were printed using the color of the severity
of the diagnostic (magenta for warnings, red for errors, cyan for
notes).
This patch updates fix-it hints so that replacement text is printed in
green, to better distinguish the suggested improvement from
the current code. For ex
On 8/26/16, Bernd Schmidt wrote:
> On 08/26/2016 06:05 PM, David Malcolm wrote:
>> selftest::fail and selftest::fail_formatted call abort. Marking
>> them as "noreturn" can help eliminate false warnings about unreachable
>> code in selftests.
>>
>> Successfully bootstrapped®rtested on x86_64-pc-l
Hi,
On Fri, Aug 26, 2016 at 7:43 AM, Andre Vieira (lists)
wrote:
> I am seeing failures on arm-none-eabi for Cortex-M0 for these two tests:
> .../gcc-final/arm-none-eabi/armv6-m/libstdc++-v3/include/variant: In
> member function 'std::__detail::__variant::_Variant_base<_Types>&
> std::__detail::_
On Fri, 2016-08-26 at 18:00 +0200, Bernd Schmidt wrote:
> On 08/26/2016 06:05 PM, David Malcolm wrote:
> > selftest::fail and selftest::fail_formatted call abort. Marking
> > them as "noreturn" can help eliminate false warnings about
> > unreachable
> > code in selftests.
> >
> > Successfully boo
On Fri, Aug 26, 2016 at 9:24 AM, augustine.sterl...@gmail.com
wrote:
> On Fri, Aug 26, 2016 at 12:02 AM, Max Filippov wrote:
>> This enables options -fstack-usage and -Wstack-usage.
>>
>> 2016-08-21 Max Filippov
>> gcc/
>> * config/xtensa/xtensa.c (xtensa_expand_prologue): Update
>>
On 26 August 2016 at 21:53, Rainer Orth wrote:
> Hi Prathamesh,
>
>> The attached version passes bootstrap+test on
>> x86_64-unknown-linux-gnu, ppc64le-linux-gnu,
>> and with c,c++,fortran on armv8l-linux-gnueabihf.
>> Cross-tested on arm*-*-* and aarch64*-*-*.
>> Verified the patch survives lto-b
The msp430 target supports an "interrupt" attribute, which can take an optional
argument specifying the interrupt number. If this argument is provided then the
compiler will output an __interrupt_vector_ section that the linker
script can use to create a vector table.
PR target/70713 (https://gcc.
On Fri, Aug 26, 2016 at 05:03:34PM +0200, Bernd Schmidt wrote:
> On 08/26/2016 04:50 PM, Segher Boessenkool wrote:
> >The head comment starts with
> >
> >+/* Separate shrink-wrapping
> >+
> >+ Instead of putting all of the prologue and epilogue in one spot, we
> >+ can put parts of it in places
On Fri, Aug 26, 2016 at 12:02 AM, Max Filippov wrote:
> This enables options -fstack-usage and -Wstack-usage.
>
> 2016-08-21 Max Filippov
> gcc/
> * config/xtensa/xtensa.c (xtensa_expand_prologue): Update
> current_function_static_stack_size variable with the static
> st
Hi Prathamesh,
> The attached version passes bootstrap+test on
> x86_64-unknown-linux-gnu, ppc64le-linux-gnu,
> and with c,c++,fortran on armv8l-linux-gnueabihf.
> Cross-tested on arm*-*-* and aarch64*-*-*.
> Verified the patch survives lto-bootstrap on x86_64-unknown-linux-gnu.
> Ok to commit ?
[
On Fri, Aug 19, 2016 at 2:46 PM, Alexandre Oliva wrote:
> Handling non-template friends is kind of easy, but it required a bit
> of infrastructure in dwarf2out to avoid (i) forcing debug info for
> unused types or functions: DW_TAG_friend DIEs are only emitted if
> their DW_AT_friend DIE is emitte
On 08/26/2016 06:05 PM, David Malcolm wrote:
selftest::fail and selftest::fail_formatted call abort. Marking
them as "noreturn" can help eliminate false warnings about unreachable
code in selftests.
Successfully bootstrapped®rtested on x86_64-pc-linux-gnu.
OK for trunk?
Don't we want to wrap
On 08/26/2016 06:03 PM, Trevor Saunders wrote:
yeah, it was just from being overly careful to not change behavior, but
that's silly we can always revert if it turns out to break something.
Not silly at all - it's a good mindset to have. But in cases where the
order doesn't matter I think it's
On Fri, Aug 26, 2016 at 7:39 AM, Prathamesh Kulkarni
wrote:
> However with C++FE it appears TYPE_RESTRICT is not set for the
> parameters (buf and fmt)
> and hence the warning doesn't get emitted for C++.
> C FE sets TYPE_RESTRICT for them. I am not sure how to workaround this
> issue, and would b
On Thu, Aug 25, 2016 at 10:46:14AM +0200, Bernd Schmidt wrote:
> On 08/25/2016 08:50 AM, tbsaunde+...@tbsaunde.org wrote:
> > @@ -2626,8 +2626,10 @@ unshare_all_rtl_1 (rtx_insn *insn)
> > This special care is necessary when the stack slot MEM does not
> > actually appear in the insn cha
selftest::fail and selftest::fail_formatted call abort. Marking
them as "noreturn" can help eliminate false warnings about unreachable
code in selftests.
Successfully bootstrapped®rtested on x86_64-pc-linux-gnu.
OK for trunk?
gcc/ChangeLog:
* selftest.h (selftest::fail): Add __attribute
This patch teaches the fortran FE how to verify that there is sufficient
parallelism when calling acc routines inside acc loop. E.g. the fortran
FE will now error if you call a gang routine from a vector loop, because
there's no way for vector partitioned code to spawn new gangs with the
OpenACC cu
On 26/08/16 10:40, Richard Biener wrote:
I suppose
you could get away with using sth entirely private to the backend,
like "sysv abi valist", also not ever user-creatable. Does this
side-step the FE issue?
It does.
Added comments and second test-case, as requested previously.
Bootstrapped an
The testcase in 57728 demonstrates that we have been treating
functions explicitly defaulted in the class body inconsistently with
explicit instantiation: an extern instantiation causes them not to be
generated, but a normal explicit instantiation doesn't cause them to
be emitted, leading to link e
Wilco Dijkstra writes:
> Ping
>
> I noticed it would still be a good idea to add an extra barrier in the epilog
> as the
> scheduler doesn't appear to handle aliases of frame accesses properly.
>
> This patch simplifies the handling of the EH return value. We force the use
> of the
> frame poi
On 08/26/2016 04:50 PM, Segher Boessenkool wrote:
The head comment starts with
+/* Separate shrink-wrapping
+
+ Instead of putting all of the prologue and epilogue in one spot, we
+ can put parts of it in places where those components are executed less
+ frequently.
and that is the long a
Hi Bernd,
On Fri, Aug 26, 2016 at 03:03:43PM +0200, Bernd Schmidt wrote:
> Not really, I'm afraid. There still seems to be no detailed explanation
> of the algorithm. Instead, there is a vague outline
Did you read the description of 8/9? If you think any of that needs to
be in the code, please
On 19/08/16 09:18, Jonathan Wakely wrote:
> On 18/08/16 13:32 -0700, Tim Shen wrote:
>> Tested on x86_64-linux-gnu and checked in as r239590.
>
> This updates the status at
> https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.201z
>
> Committed to trunk.
>
>
Hi,
I am seein
On 08/26/2016 03:48 PM, David Malcolm wrote:
I'm nervous about the build_random_cfg function: randomness in
selftests seems like a double-edged sword. On the one hand, we can use
it to fuzz-test an optimization to rapidly gain a lot of coverage. On
the other hand, does every host generate the s
On Fri, 2016-08-26 at 15:03 +0200, Bernd Schmidt wrote:
> On 08/01/2016 03:42 AM, Segher Boessenkool wrote:
> > This is the second version. Concern was renamed to component, and
> > all
> > other comments were addressed (I hope).
>
> Not really, I'm afraid. There still seems to be no detailed
> e
On Thu, Aug 25, 2016 at 11:35:53AM -0600, Martin Sebor wrote:
> > +foo (int a, int b)
> > +{
> > + int r = 0;
> > + r += !a == (a < b);
> > + r += !a == (a > b);
> > + r += !a == (a >= b);
> > + r += !a == (a <= b);
> > + r += !a == (a != b);
> > + r += !a == (a == b);
> > + r += !a == (a |
On Fri, Aug 26, 2016 at 11:18:46AM +0200, Richard Biener wrote:
> On Fri, Aug 26, 2016 at 10:57 AM, Marek Polacek wrote:
> > On Fri, Aug 26, 2016 at 10:53:01AM +0200, Richard Biener wrote:
> >> On Thu, Aug 25, 2016 at 3:39 PM, Marek Polacek wrote:
> >> > On Thu, Aug 25, 2016 at 11:17:37AM +0200,
PR libstdc++/51960
* doc/xml/manual/intro.xml: Document DR 2127 change.
* doc/html/*: Regenerate.
* include/bits/stl_raw_storage_iter.h (operator=(_Tp&&)): Add.
(operator++(), operator++(int)): Use injected class name.
* testsuite/20_util/raw_storage
On 08/01/2016 03:42 AM, Segher Boessenkool wrote:
This is the second version. Concern was renamed to component, and all
other comments were addressed (I hope).
Not really, I'm afraid. There still seems to be no detailed explanation
of the algorithm. Instead, there is a vague outline (which sh
In chasing down an LTO read/write bug I came across some 'interesting' code in
inline_write_summaries:
if (cnode && (node = cnode)->definition && !node->alias)
that in-test assignment isn't needed -- cnode is not modified until the next
loop iteration.
Fixed as obvious by removing the 'no
The following fixes PR69047, update-address-taken can use the same
trick as VN and re-write MEM[&d] into SSA when the size of the MEM
and the size of d do not match by using a BIT_FIELD_REF.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
The patch contains a workaround fo
On 25 August 2016 at 19:14, Jan Hubicka wrote:
>> Patch for performing interprocedural bitwise constant propagation.
>>
>> 2016-08-23 Prathamesh Kulkarni
>> Martin Jambhor
>>
>> * common.opt: New option -fipa-cp-bit.
>> * doc/invoke.texi: Document -fipa-cp-bit.
>>
On 26/08/16 12:42 +0100, Jonathan Wakely wrote:
This large patch replaces most of the remaining uses of -std in
dg-options with { target c++11 } or { target c++14 } effective
targets.
The advantage of this is that we will now test most things with the
default gnu++14 mode. Previously most tests
Arguments passed to diagnostic functions should not end with '\n'.
--
Joseph S. Myers
jos...@codesourcery.com
I've committed this patch to add release notes for the _FloatN, _FloatNx
support.
Index: gcc-7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.9
diff -u -r1.9 changes.html
--- gcc-7/chang
Hi,
The following patch adds option -Wrestrict that warns when an argument
is passed to a restrict qualified parameter and it aliases with
another argument.
eg:
int foo (const char *__restrict buf, const char *__restrict fmt, ...);
void f(void)
{
char buf[100] = "hello";
foo (buf, "%s-%s", bu
On Thu, Aug 25, 2016 at 6:13 PM, Steve Kargl
wrote:
> I plan to commit the following patch on Saturday if
> no one objects in the next 40 or so hours.
>
> 2016-08-25 Steven G. Kargl
>
> PR fortran/77372
> simplify.c (simplify_ieee_selected_real_kind): Check for NULL
> pointers.
This re-syncs java_mange_decl with lhd_set_decl_assembler_name.
Committed as obvious.
Otherwise testing with -flto fails in libjava testing with
^[[01m^[[K:^[[m^[[K ^[[01;31m^[[Kinternal compiler error:
^[[m^[[Kin java_mangle_decl, at java/mangle.c:84^M
0x63a513 java_mangle_decl(tree_node*)^M
This adds the new constructor required by the resolution of LWG 2583.
The new symbols matched the greedy patterns for strings in old symbol
versions, so I made them much more precise. It's possible some symbols
that are supposed to be exported will now not match, but I checked
that all symbols in
On 08/18/2016 04:41 PM, Jeff Law wrote:
It's pie in the sky right now, but it's something many of us want to see
happen. To that end we're trying to steer away from certain problematic
idioms (like using macros to conditionalize behavior) towards schemes
that would work in that world (hooks).
O
On 23/08/16 15:10, Wilco Dijkstra wrote:
> In aarch64_classify_symbol symbols are allowed full-range offsets on
> relocations.
> This means the offset can use all of the +/-4GB offset, leaving no offset
> available
> for the symbol itself. This results in relocation overflow and link-time
> er
I've committed this patch for /gcc-7/changes.html
Index: htdocs/gcc-7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.8
diff -u -r1.8 changes.html
--- htdocs/gcc-7/changes.html 25 Aug 20
On Fri, Aug 26, 2016 at 11:14 AM, Kyrill Tkachov
wrote:
> Hi all,
>
> The scheduling automata sizes are getting a bit out of control (as the PR
> complains about) and the Cortex-A8
> one is one of the largest offenders. An easy, low-hanging fruit in dealing
> with this are some of the FP/NEON oper
On 26/08/16 11:14, Kyrill Tkachov wrote:
> Hi all,
>
> The scheduling automata sizes are getting a bit out of control (as the
> PR complains about) and the Cortex-A8
> one is one of the largest offenders. An easy, low-hanging fruit in
> dealing with this are some of the FP/NEON operations
> that h
Hi all,
The scheduling automata sizes are getting a bit out of control (as the PR
complains about) and the Cortex-A8
one is one of the largest offenders. An easy, low-hanging fruit in dealing with
this are some of the FP/NEON operations
that have very large reservation durations specified for t
On 24/08/16 16:26, Kyrill Tkachov wrote:
> Hi all,
>
> If we want to add more macro fusion cases in the arm backend we need to
> rework the aarch_macro_fusion_pair_p a bit
> to not return early during the MOVW/MOVT fusion checks. This simple
> patch does that by adding a helper function
> that ca
The patch below is my current development state of Early LTO debug lumped
into one big patch (no changelog, sorry). It contains previously posted
https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01089.html
which extends dwarf2asm.h and adjusts a target hook which means the
patch carries the usua
On 24/08/16 12:48 -0700, Tim Shen wrote:
On Wed, Aug 24, 2016 at 1:41 AM, Jonathan Wakely wrote:
On 24/08/16 00:18 -0700, Tim Shen wrote:
I didn't realized that we can actually escape a dash inside bracket
expression: R"([\-])", in which case the dash should be treated
literally.
With this
On 26/08/16 09:52, Kyrill Tkachov wrote:
> Hi all,
>
> I'd like to backport this fix for an ILP32 ICE. This was a simple
> band-aid proposed by Andrew
> that is self-contained and doesn't touch non-ILP32 or non-aarch64 code
> so it should be pretty safe
> to backport. It has been in trunk and GCC
On Fri, Aug 26, 2016 at 10:57 AM, Marek Polacek wrote:
> On Fri, Aug 26, 2016 at 10:53:01AM +0200, Richard Biener wrote:
>> On Thu, Aug 25, 2016 at 3:39 PM, Marek Polacek wrote:
>> > On Thu, Aug 25, 2016 at 11:17:37AM +0200, Richard Biener wrote:
>> >> On Wed, Aug 24, 2016 at 7:43 PM, Marek Polac
On Fri, Aug 26, 2016 at 7:25 AM, Alexandre Oliva wrote:
> On Aug 22, 2016, Richard Biener wrote:
>
>> Just throwing in a wrench from the side ... you should do this in
>> dwarf2out_early_finish as late there will be no frontend around anymore.
>
> Thanks for the heads up, I've adjusted my local c
On Fri, Aug 26, 2016 at 5:08 AM, Prasad Ghangal
wrote:
> On 24 August 2016 at 15:32, Richard Biener wrote:
>> On Mon, Aug 22, 2016 at 8:40 PM, Prasad Ghangal
>> wrote:
>>> On 22 August 2016 at 16:55, Trevor Saunders wrote:
On Sun, Aug 21, 2016 at 10:35:17PM +0530, Prasad Ghangal wrote:
>>>
On Fri, Aug 26, 2016 at 10:53:01AM +0200, Richard Biener wrote:
> On Thu, Aug 25, 2016 at 3:39 PM, Marek Polacek wrote:
> > On Thu, Aug 25, 2016 at 11:17:37AM +0200, Richard Biener wrote:
> >> On Wed, Aug 24, 2016 at 7:43 PM, Marek Polacek wrote:
> >> > The -Wlogical-not-parentheses deliberately
Hi all,
I'd like to backport this fix for an ILP32 ICE. This was a simple band-aid
proposed by Andrew
that is self-contained and doesn't touch non-ILP32 or non-aarch64 code so it
should be pretty safe
to backport. It has been in trunk and GCC 6 for quite some time without issues
until Renlin's
On Thu, Aug 25, 2016 at 3:39 PM, Marek Polacek wrote:
> On Thu, Aug 25, 2016 at 11:17:37AM +0200, Richard Biener wrote:
>> On Wed, Aug 24, 2016 at 7:43 PM, Marek Polacek wrote:
>> > The -Wlogical-not-parentheses deliberately doesn't warn when the RHS has
>> > boolean type. But since in C the typ
On Thu, 25 Aug 2016, Tom de Vries wrote:
> On 25/08/16 13:48, Richard Biener wrote:
> > On Wed, 24 Aug 2016, Tom de Vries wrote:
> >
> > > Hi,
> > >
> > > in PR70955, ix86_canonical_va_list_type fails to recognize a
> > > __builtin_ms_va_list that was declared in a TU, because its type doesn't
>
This enables options -fstack-usage and -Wstack-usage.
2016-08-21 Max Filippov
gcc/
* config/xtensa/xtensa.c (xtensa_expand_prologue): Update
current_function_static_stack_size variable with the static
stack frame size of the current function when
flag_stack_usage
80 matches
Mail list logo
