On 9/9/16 5:51 PM, Jeff Law wrote:
On 08/30/2016 10:23 PM, Peter Bergner wrote:
gcc/
PR rtl-optimization/77289
* lra-constraints.c (get_final_hard_regno): Add support for non hard
register numbers. Remove support for subregs.
(get_hard_regno): Use SUBREG_P. Don't call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77289
--- Comment #7 from Peter Bergner ---
Author: bergner
Date: Sat Sep 10 01:36:33 2016
New Revision: 240065
URL: https://gcc.gnu.org/viewcvs?rev=240065=gcc=rev
Log:
gcc/
PR rtl-optimization/77289
* lra-constraints.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77420
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
I've committed the following patch. It restores gfortran's
behavior prior to my commit r224159 if the current namespace
has an empty equivalent list.
2016-09-09 Steven G. Kargl
PR fortran/77420
* module.c (load_equiv): If the current namespace has a list of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77420
--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Sep 10 00:52:45 2016
New Revision: 240063
URL: https://gcc.gnu.org/viewcvs?rev=240063=gcc=rev
Log:
2016-09-09 Steven G. Kargl
PR
valgrind contains a copy of the libiberty demangler which gets compiled
with -Wshadow. That shows the following warning:
cp-demangle.c: In function ‘d_substitution’:
cp-demangle.c:3772:35: warning: declaration of ‘c’ shadows a previous local
struct demangle_component *c;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77546
Bug ID: 77546
Summary: [5 to 6 regression] C++ software renderer performance
drop
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77520
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77521
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
On 09/09/2016 07:59 AM, Joseph Myers wrote:
On Thu, 8 Sep 2016, Martin Sebor wrote:
PS I used hexadecimal based on what c-format.c does but now that
I checked more carefully how %qE formats string literals I see it
uses octal. I think hexadecimal is preferable because it avoids
ambiguity but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77521
--- Comment #2 from Martin Sebor ---
Author: msebor
Date: Fri Sep 9 23:12:10 2016
New Revision: 240059
URL: https://gcc.gnu.org/viewcvs?rev=240059=gcc=rev
Log:
PR c/77520 - wrong value for extended ASCII characters in -Wformat message
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77520
--- Comment #2 from Martin Sebor ---
Author: msebor
Date: Fri Sep 9 23:12:10 2016
New Revision: 240059
URL: https://gcc.gnu.org/viewcvs?rev=240059=gcc=rev
Log:
PR c/77520 - wrong value for extended ASCII characters in -Wformat message
PR
On 09/09/2016 07:28 AM, Bernd Edlinger wrote:
Hi David,
I attempted to create a reproducer for PR 71779; however I'm not yet
able to replicate the bogus cse reported there via the test case.
Thanks, this is just awesome. I immediately had to try your patch.
I'd pointed David at 71779
On 09/09/2016 02:41 PM, Segher Boessenkool wrote:
On Fri, Sep 09, 2016 at 12:31:31PM -0600, Jeff Law wrote:
On 06/08/2016 03:18 AM, Bernd Schmidt wrote:
On 06/08/2016 03:47 AM, Segher Boessenkool wrote:
+ /* regrename creates wrong code for exception handling, if used
together
+
On 08/24/2016 07:13 PM, David Malcolm wrote:
Here's a much less ambitious version of the patch kit, which
eliminates any attempt to write to the user's source
code (getting rid of edit_context::apply_changes and
-fdiagnostics-apply-fixits).
It implements -fdiagnostics-generate-patch. In so
On 08/30/2016 10:23 PM, Peter Bergner wrote:
PR77289 exposes a latent problem with LRA constraint matching. In the buggy
test cases, LRA performs a speculative register elimination before checking
operands for matching constraints. With the elimination, the operands
appear to match. However,
On 08/29/2016 02:41 PM, Segher Boessenkool wrote:
On Mon, Aug 29, 2016 at 10:19:25PM +0200, Steven Bosscher wrote:
On Mon, Aug 29, 2016 at 6:50 PM, Segher Boessenkool wrote:
This patch changes that so that that def is only added after
epilogue_completed.
...
Does this work on all other
On 08/29/2016 10:50 AM, Segher Boessenkool wrote:
For separate shrink-wrapping we need to find out which basic blocks
need what components set up by a prologue, so that we can move those
prologue pieces deeper into the function, so that those pieces are
executed less frequently, improving
By design, the libgomp OpenACC runtime prohibits data clauses with
aliased addresses from being used in the same construct. E.g., the user
is not allowed to specify
#pragma acc parallel copy(var[0:10]) copy(pvar[0:10])
where pvar is a pointer to var or if those subarrays overlap. To a
certain
On 08/29/2016 02:19 PM, Steven Bosscher wrote:
On Mon, Aug 29, 2016 at 6:50 PM, Segher Boessenkool wrote:
This patch changes that so that that def is only added after
epilogue_completed.
...
Does this work on all other targets?
Guessing: not for targets where INCOMING_RETURN_ADDR_RTX is the
On 09/09/2016 03:40 PM, Bernd Edlinger wrote:
Hi,
I think it is time to remove support for INITIAL_FRAME_POINTER_OFFSET, which is
no longer
used by any target today. This removes a bunch of conditional code, and fixes
a few bits
in the documentation. I'd say that part of the documentation
On 08/29/2016 10:12 AM, Tom de Vries wrote:
On 29/08/16 17:51, Joseph Myers wrote:
On Wed, 24 Aug 2016, Tom de Vries wrote:
This patch fixes PR71602 by making canonical_va_list_type more strict.
Bootstrapped and reg-tested on x86_64.
OK for trunk, 6-branch?
ENOPATCH
Patch attached this
Hi,
I would like to ping the following patch:
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01015.html
While implementing divmod transform:
https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01757.html
I ran into an issue with optab_libfunc().
It appears optab_libfunc (sdivmod_optab, mode) returns
On Thu, Sep 08, 2016 at 12:34:07PM -0600, Jeff Law wrote:
> On 07/31/2016 07:42 PM, Segher Boessenkool wrote:
> >
> >Deciding what blocks should run with a certain component active so that
> >the total cost of executing the prologues (and epilogues) is optimal, is
> >not a computationally feasible
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160909 (experimental
On 08/12/2016 01:27 PM, David Malcolm wrote:
In r239260 I attempted to add fix-it hints for -Wformat type
warnings.
Unfortunately, my implementation was too simplistic, and only
worked correctly for the most simple format strings: the fix-it
hint would suggest replacement of an entire
Hi,
I think it is time to remove support for INITIAL_FRAME_POINTER_OFFSET, which is
no longer
used by any target today. This removes a bunch of conditional code, and fixes
a few bits
in the documentation. I'd say that part of the documentation is quite out of
sync, but I just
have to stop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77267
--- Comment #4 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Fri Sep 9 21:38:06 2016
New Revision: 240057
URL: https://gcc.gnu.org/viewcvs?rev=240057=gcc=rev
Log:
Fix PR target/77267
2016-09-10 Alexander Ivchenko
On Thu, Sep 8, 2016 at 7:06 AM, Jonathan Wakely wrote:
> On 08/09/16 09:10 +0200, Marc Glisse wrote:
>>
>> Do we want a generic fallback implementation (similar to
>> gcc/config/i386/gmm_malloc.h)? A windows version with _aligned_malloc /
>> _aligned_free would also be
On Thu, Sep 08, 2016 at 11:55:04AM -0600, Jeff Law wrote:
> On 07/31/2016 07:42 PM, Segher Boessenkool wrote:
> >Doing cprop on frame-related instructions blows up spectacularly.
> >So don't.
> >
> >2016-06-07 Segher Boessenkool
> >
> > * regcprop.c
TS 18661-1 defines a macro CR_DECIMAL_DIG in , for the number
of decimal digits for which conversions between decimal character
strings and (IEEE) binary formats, in both directions, are correctly
rounded. This patch implements support for this macro in GCC's
.
The definition __UINTMAX_MAX__ is
On Thu, Sep 08, 2016 at 11:54:33AM -0600, Jeff Law wrote:
> On 07/31/2016 07:42 PM, Segher Boessenkool wrote:
> >If selective scheduling copies register restores it confuses dwarf2cfi.
> >
> >2016-06-07 Segher Boessenkool
> >
> > * sel-sched-ir.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77543
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
On 09.09.2016 21:15, Manuel López-Ibáñez wrote:
> On 09/09/16 13:28, Florian Weimer wrote:
>> For compile-time fortify checks (such as the wrappers for type-safe
>> open/openat), we need to add tests in glibc which examine the compiler output
>> for warnings and errors.
>>
>> I do not want to add
On 08/20/2016 09:57 AM, tbsaunde+...@tbsaunde.org wrote:
From: Trevor Saunders
Hi,
basically just $subject, always define HAVE_AS_LEB128, and then use if / else
instead of #ifdef. Note the diff has a bit of whitespace noise, so there's a
-w diff below the full
On Thu, Sep 08, 2016 at 11:51:53AM -0600, Jeff Law wrote:
> On 07/31/2016 07:42 PM, Segher Boessenkool wrote:
> >A restore is supposed to restore some certain register. Restoring it
> >into some other register will not work. Don't.
> >
> >2016-06-07 Segher Boessenkool
On Fri, Sep 09, 2016 at 12:57:32PM -0600, Jeff Law wrote:
> I think the lack of test coverage is something we'll want to address.
Building and running the compiler, the various target libraries, and the
testsuite is more than enough coverage for correctness in my opinion --
I cannot make up
On Fri, Sep 09, 2016 at 12:31:31PM -0600, Jeff Law wrote:
> On 06/08/2016 03:18 AM, Bernd Schmidt wrote:
> >On 06/08/2016 03:47 AM, Segher Boessenkool wrote:
> >>+ /* regrename creates wrong code for exception handling, if used
> >>together
> >>+ with separate shrink-wrapping.
On Fri, Sep 09, 2016 at 12:28:12PM -0600, Jeff Law wrote:
> >The generic code only does
> >
> >+ /* We don't handle "strange" functions. */
> >+ if (cfun->calls_alloca
> >+ || cfun->calls_setjmp
> >+ || cfun->can_throw_non_call_exceptions
> >+ || crtl->calls_eh_return
> >+
Patch #1. All the fixes to static buffer sizes that were inspired by
your warning. These are all approved and can go in immediately.
Attached is this patch.
Hi, this patch changed the file gcc/go/gofrontend/expressions.cc. As
described in gcc/go/gofrontend/README, the files in the
On Fri, Sep 09, 2016 at 12:19:03PM -0600, Jeff Law wrote:
> >>Does this impact the compile time computation complexity issue that was
> >>raised elsewhere?
> >
> >I'm not sure what you mean here either, sorry. It is all O(NM) with N
> >the number of BBs and M the number of components (and
This patch to the Go frontend increases the size of a local buffer to
avoid a -Wformat-length warning. This undoes a patch that was earlier
committed to the GCC repository in favor of a patch to the gofrontend
repository mirrored to GCC. Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu.
The following patch fixes an ICE due to a gcc_assert() firing.
As everyone here knows, gfortran runs a series a matchers during
parsing. If a matcher fails, it often queuesi/reports an error
message and returns, which allows other matchers to run. If a
match is successful, a queued error
On 08/26/2016 07:03 AM, 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 explanation
of the
On Fri, Aug 19, 2016 at 8:29 AM, Martin Sebor wrote:
>> My biggest concern with this iteration is the tight integration between
>> the optimization and warning. We generally avoid that kind of tight
>> integration such that enabling the warning does not affect the
>>
On 06/08/2016 03:18 AM, Bernd Schmidt wrote:
On 06/08/2016 03:47 AM, Segher Boessenkool wrote:
+ /* regrename creates wrong code for exception handling, if used
together
+ with separate shrink-wrapping. Disable for now, until we have
+ figured out what exactly is going on. */
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77544
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
This patch by Than McIntosh adds an abstraction layer for the SHA1
checksum code in the Go frontend. This breaks a dependency of the
gofrontend on libiberty, and thus adds another separation between the
gofrontend code and GCC proper. Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu.
On 09/09/2016 09:04 AM, Segher Boessenkool wrote:
On Fri, Sep 09, 2016 at 12:58:11PM +0200, Bernd Schmidt wrote:
Hmm? The problem is that you can't generally emit a save/restore
independent of placement, because you may not know which offset to use
from whichever base register. But these
On Wed, Aug 31, 2016 at 05:14:43PM -0700, Steve Kargl wrote:
>
> 2016-09-03 Steven G. Kargl
>
> PR fortran/77406
> * interface.c (gfc_compare_interfaces): Fix detection of ambiguous
> interface involving alternate return.
> (check_interface1):
On 09/09/2016 09:40 AM, Segher Boessenkool wrote:
So I think sticking with this as a design decision makes sense -- does
it impact the issue around running a particular component's prologue
more than once?
I don't follow, sorry; could you rephrase?
Nevermind -- my question has been resolved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77544
Bug ID: 77544
Summary: [Regression 6/7] segfault at -O0 - infinite loop in
simplification
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77506
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77506
--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Sep 9 18:04:23 2016
New Revision: 240052
URL: https://gcc.gnu.org/viewcvs?rev=240052=gcc=rev
Log:
2016-09-09 Steven G. Kargl
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77507
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77507
--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Sep 9 17:57:11 2016
New Revision: 240050
URL: https://gcc.gnu.org/viewcvs?rev=240050=gcc=rev
Log:
2016-09-09 Steven G. Kargl
PR
On Fri, 9 Sep 2016, Bernd Edlinger wrote:
> Hi,
>
> just a nit:
>
> +Defined to the widths of the corresponding types. They exist to make
> +the implementations of @file{limits.h} and @file{stdint.h} make
> +correctly.
>
> Defined to the bit widths ...
>
> They exist to make the
Hi,
just a nit:
+Defined to the widths of the corresponding types. They exist to make
+the implementations of @file{limits.h} and @file{stdint.h} make
+correctly.
Defined to the bit widths ...
They exist to make the implementations of ... behave correctly.
Bernd.
This patch by Than McIntosh removes the dependence of the Go frontend
on the hex_value array from libiberty. This is a step toward breaking
the links between the gofrontend code proper on GCC. Bootstrapped and
ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index:
On 09/09/2016 10:57 AM, Segher Boessenkool wrote:
On Fri, Sep 09, 2016 at 10:48:30AM -0600, Jeff Law wrote:
and even allows them to be executed more than once, if that is
cheaper.
This is the part that I'm still struggling with.
The usual example:
1
|\
| \
| 2
| /
|/
3
|\
| \
| 4
| /
|/
On 09/08/16 11:35, Florian Weimer wrote:
> On 09/07/2016 08:32 PM, Bernd Edlinger wrote:
>> interesting. I just tried the test case from PR 77330 with _Decimal128.
>> result: _Decimal128 did *not* trap with gcc4.8.4, but it does trap with
>> gcc-7.0.0.
>
> Recent GCC versions rely on struct
On 09/09/2016 06:28 AM, Florian Weimer wrote:
For compile-time fortify checks (such as the wrappers for type-safe
open/openat), we need to add tests in glibc which examine the compiler
output for warnings and errors.
I do not want to add Dejagnu as a dependency to the glibc test suite,
but I
On 09/09/2016 10:49 AM, Segher Boessenkool wrote:
On Fri, Sep 09, 2016 at 09:59:03AM -0600, Jeff Law wrote:
On 09/09/2016 09:17 AM, Segher Boessenkool wrote:
On Thu, Sep 08, 2016 at 10:41:37AM -0600, Jeff Law wrote:
So can you expand on the malloc example a bit -- I'm pretty sure I
understand
TS 18661-1 defines and macros for widths of
standard integer types and the typedefs defined in, or whose limits
are defined in, . (The connection to the main
floating-point subject matter of TS 18661-1 is that these are intended
to be used with the fromfp functions to convert from floating
On Fri, Sep 09, 2016 at 10:48:30AM -0600, Jeff Law wrote:
> and even allows them to be executed more than once, if that is
> >cheaper.
> This is the part that I'm still struggling with.
The usual example:
1
|\
| \
| 2
| /
|/
3
|\
| \
| 4
| /
|/
5
where 2 and 4 need a certain prologue
On 09/09/2016 09:33 AM, Segher Boessenkool wrote:
On Thu, Sep 08, 2016 at 11:20:41AM -0600, Jeff Law wrote:
On 08/29/2016 03:31 AM, Bernd Schmidt wrote:
On 08/01/2016 03:42 AM, Segher Boessenkool wrote:
+@deftypefn {Target Hook} void
TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS (sbitmap)
+Emit
On Fri, Sep 09, 2016 at 09:59:03AM -0600, Jeff Law wrote:
> On 09/09/2016 09:17 AM, Segher Boessenkool wrote:
> >On Thu, Sep 08, 2016 at 10:41:37AM -0600, Jeff Law wrote:
> >>So can you expand on the malloc example a bit -- I'm pretty sure I
> >>understand what you're trying to do, but a concrete
On 09/09/2016 09:28 AM, Segher Boessenkool wrote:
Segher's code essentially allows individual components of the prologue
to sink to different points within the function rather than forcing the
prologue to be sunk as an atomic unit.
It also allows prologue an epilogue components to be placed in
Hi!
On Thu, Sep 01, 2016 at 03:40:49PM +0200, Marek Polacek wrote:
> @@ -1749,6 +1758,16 @@ c_parser_declaration_or_fndef (c_parser *parser, bool
> fndef_ok,
> {
>if (auto_type_p)
> error_at (here, "%<__auto_type%> in empty declaration");
> + else if (specs->typespec_kind
On Fri, Sep 9, 2016 at 6:52 AM, Andreas Schwab wrote:
>
> You should use alignof(ucontext_t) instead of hardcoding 16.
Fair enough. Done like so. Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu, committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
On Fri, Sep 09, 2016 at 08:13:01AM -0700, Steven G. Kargl wrote:
> On Fri, Sep 09, 2016 at 01:47:40PM +0200, Paul Richard Thomas wrote:
> >
> > This is OK for trunk. Are you backporting any of these fixes? If so,
> > you're OK to go back to 5-branch.
> >
>
> I have a pile of *.diff files that I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77512
Eric Botcazou changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
On 09/09/2016 09:51 AM, Segher Boessenkool wrote:
On Thu, Sep 08, 2016 at 11:50:56AM -0600, Jeff Law wrote:
On 07/31/2016 07:42 PM, Segher Boessenkool wrote:
Deleting restores (before a noreturn) that are dead confuses dwarf2cfi.
2016-06-07 Segher Boessenkool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77543
Bug ID: 77543
Summary: ARM: G++ generates redundant instructions at -O0
Product: gcc
Version: 5.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
On 09/09/2016 09:17 AM, Segher Boessenkool wrote:
On Thu, Sep 08, 2016 at 10:41:37AM -0600, Jeff Law wrote:
So can you expand on the malloc example a bit -- I'm pretty sure I
understand what you're trying to do, but a concrete example may help
Bernd and be useful for archival purposes.
Sure,
On Thu, Sep 08, 2016 at 11:50:56AM -0600, Jeff Law wrote:
> On 07/31/2016 07:42 PM, Segher Boessenkool wrote:
> >Deleting restores (before a noreturn) that are dead confuses dwarf2cfi.
> >
> >2016-06-07 Segher Boessenkool
> >
> > * dce.c (delete_unmarked_insns):
On 09/09/2016 04:58 AM, Bernd Schmidt wrote:
On 09/08/2016 07:20 PM, Jeff Law wrote:
On 08/29/2016 03:31 AM, Bernd Schmidt wrote:
How do these actually know where to save/restore registers? The frame
pointer may have been eliminated, and SP isn't necessarily constant
during the function. Seems
On Thu, Sep 08, 2016 at 11:37:17AM -0600, Jeff Law wrote:
> I don't have major concerns with this patch -- I'd like to see
> clarification done on the ownership of the sbitmaps (ie, who allocates
> and releases those objects). I'd like to see if we can get a better
> introduction as well.
On Fri, Sep 09, 2016 at 09:26:39AM -0600, Jeff Law wrote:
> >>I think one of the questions (and I haven't looked through the whole
> >>thread yet to see if it's answered) is why the basic shrink-wrapping
> >>algorithm can't be applied to each of the prologue components -- though
> >>you may have
On Thu, Sep 08, 2016 at 11:20:41AM -0600, Jeff Law wrote:
> On 08/29/2016 03:31 AM, Bernd Schmidt wrote:
> >On 08/01/2016 03:42 AM, Segher Boessenkool wrote:
> >>+@deftypefn {Target Hook} void
> >>TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS (sbitmap)
> >>+Emit prologue insns for the components
On Thu, Sep 08, 2016 at 10:58:13AM -0600, Jeff Law wrote:
> >And that comment puzzles me. Surely prologue and epilogue are executed
> >only once currently, so how does frequency come into it? Again - please
> >provide an example.
> Right, they're executed once currently. But the prologue could be
On 09/09/2016 12:19 AM, Segher Boessenkool wrote:
Thanks for looking at the patches Jeff.
On Thu, Sep 08, 2016 at 10:28:59AM -0600, Jeff Law wrote:
Right. Essentially Segher's patch introduces the concept of prologue
components that are independent of each other and which can be
On Thu, Sep 08, 2016 at 10:41:37AM -0600, Jeff Law wrote:
> So can you expand on the malloc example a bit -- I'm pretty sure I
> understand what you're trying to do, but a concrete example may help
> Bernd and be useful for archival purposes.
Sure, but it's big (which is the problem :-) )
> I
On Fri, Sep 09, 2016 at 01:47:40PM +0200, Paul Richard Thomas wrote:
>
> This is OK for trunk. Are you backporting any of these fixes? If so,
> you're OK to go back to 5-branch.
>
I have a pile of *.diff files that I will someday
apply to at least 6. I know I have lost a few diffs,
so those
On Fri, Sep 09, 2016 at 12:58:11PM +0200, Bernd Schmidt wrote:
> Hmm? The problem is that you can't generally emit a save/restore
> independent of placement, because you may not know which offset to use
> from whichever base register. But these offsets aren't necessarily
> constant throughout
On 27/05/16 15:51, Ulrich Weigand wrote:
> Andre Vieira (lists) wrote:
>> On 07/04/16 10:30, Andre Vieira (lists) wrote:
>>> On 17/03/16 16:33, Andre Vieira (lists) wrote:
On 23/10/15 12:31, Bernd Schmidt wrote:
> On 10/12/2015 11:58 AM, Ulrich Weigand wrote:
>>
>> Index:
On Fri, 9 Sep 2016, David Malcolm wrote:
> (FWIW, I'd much prefer it if DejaGnu were implemented in Python rather
> than Tcl; writing and debugging .exp files below gcc/testsuite is one
QMTest was a test harness written in Python and avoiding various issues
with DejaGnu's design, though by now
On 2016/9/1 03:13 PM, Richard Biener wrote:
> On Wed, 31 Aug 2016, Chung-Lin Tang wrote:
>
>> Hi Richard, Martin,
>> this issue is actually sort of like PR 70856, basically the same ICE
>> after IPA-ICF, due to DECL_PT_UIDs not consistent after reaching for the
>> ultimate_alias_target().
>>
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77535
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
---
On Fri, 2016-09-09 at 14:28 +0200, Florian Weimer wrote:
> For compile-time fortify checks (such as the wrappers for type-safe
> open/openat), we need to add tests in glibc which examine the
> compiler
> output for warnings and errors.
>
> I do not want to add Dejagnu as a dependency to the
The definition and most uses of MAKECONTEXT_STACK_TOP in libgo were
removed in https://golang.org/cl/88660043, which removed support for
Solaris 8/9. One use of MAKECONTEXT_STACK_TOP was accidentally left
in the source code. Remove it now. Bootstrapped and ran Go testsuite
on
On Thu, 8 Sep 2016, Martin Sebor wrote:
> PS I used hexadecimal based on what c-format.c does but now that
> I checked more carefully how %qE formats string literals I see it
> uses octal. I think hexadecimal is preferable because it avoids
> ambiguity but I'm open to changing it to octal if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77542
Bug ID: 77542
Summary: __attribute__((warn_unused_result)) ignored on
function template
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
On Sep 09 2016, Ian Lance Taylor wrote:
> Index: libgo/runtime/proc.c
> ===
> --- libgo/runtime/proc.c (revision 239872)
> +++ libgo/runtime/proc.c (working copy)
> @@ -156,6 +156,20 @@
On Fri, Sep 2, 2016 at 9:27 AM, Andreas Schwab wrote:
> On Sep 02 2016, Ian Lance Taylor wrote:
>
>> On Fri, Sep 2, 2016 at 9:14 AM, Andreas Schwab wrote:
>>>
>>> That breaks libgo on ia64. The problem is that _ucontext_t isn't
>>>
Hi David,
> I attempted to create a reproducer for PR 71779; however I'm not yet
> able to replicate the bogus cse reported there via the test case.
Thanks, this is just awesome. I immediately had to try your patch.
The main reason for PR 71779 was that this
(insn 1047 1046 1048 (set (reg:DI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77541
Uroš Bizjak changed:
What|Removed |Added
Keywords||ra
Status|UNCONFIRMED
Hi,
Although libjava is currently on death row, here is a patch to
(correctly) fix mips64el in the java interpreter. This restores
sparc64 BE java support based on the report[1] that reverting my
original patch fixes the bug (I have not rerun this on spark64
BE as we are back to the original code
For compile-time fortify checks (such as the wrappers for type-safe
open/openat), we need to add tests in glibc which examine the compiler
output for warnings and errors.
I do not want to add Dejagnu as a dependency to the glibc test suite,
but I wonder if you could share any lessons learned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71917
--- Comment #12 from Matthew Fortune ---
Created attachment 39593
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39593=edit
Proposed fix
Attached fix should resolve the issue on sparc64 BE.
The original attempt at the fix for mips64el is
1 - 100 of 128 matches
Mail list logo