At Sun, 08 Mar 2015 23:14:10 +0900 (JST),
Kaz Kojima wrote:
>
> Oleg Endo wrote:
> >> diff --git a/gcc/config/sh/t-linux b/gcc/config/sh/t-linux
> >> index d33c638..22b8e3e 100644
> >> --- a/gcc/config/sh/t-linux
> >> +++ b/gcc/config/sh/t-linux
> >> @@ -1,2 +1,3 @@
> >> MULTILIB_DIRNAMES=
> >>
On Fri, 6 Mar 2015, Jeff Law wrote:
> On 03/06/15 06:16, Richard Biener wrote:
> >
> > This fixes PR63155 and reduces the memory usage at -O0 from reported
> > 10GB (couldn't verify/update on my small box) to 350MB (still worse
> > compared to 4.8 which needs only 50MB).
> >
> > It fixes this by
On Wed, Mar 4, 2015 at 12:09 PM, Alex Velenko wrote:
> For example, in arm testcase pr43920-2.c, CSE previously decided not to put
> an "obvious" note on insn 9, as set value was the same as note value.
> At the same time, other insns set up as -1 were set up through a register
> and did get a note
> From: Jiong Wang [mailto:jiong.w...@arm.com]
> Sent: Friday, March 06, 2015 8:10 PM
>
> On 05/03/15 09:53, Thomas Preud'homme wrote:
> > *** gcc/testsuite/ChangeLog ***
> >
> > 2015-02-16 Thomas Preud'homme
> >
> > * gcc.dg/loop-7.c: Run on all targets and check for loop2_invariant
>
I guess this patch doesn't break abi compatibility, so if everything
is Ok, I'm gonna patch it to 4.9 too.
I'm not sure if this is a "regression fix" though; if it's
inappropriate for trunk, then I can simply wait.
Bootstrapped in trunk and tested.
Thanks! :)
--
Regards,
Tim Shen
commit cf397
Updated patch after internal review:
* Moved the hotpatch specific NOP patterns to the normal NOP
patterns in the .md file.
* Make function_alignment unsigned and cast align_function
instead.
(ChangeLog is still the same.)
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
>From e0083
On Mon, Mar 09, 2015 at 12:22:21PM +0100, Dominik Vogt wrote:
> @@ -5308,34 +5309,14 @@ s390_asm_output_function_label (FILE *asm_out_file,
> const char *fname,
>stored directly before the label without crossing a cacheline
>boundary. All this is necessary to make sure the trampol
I noticed that we can use the do_ubsan_in_current_function wrapper more, which
allows us to simplify the code a bit further.
Ran ubsan testsuite on x86_64-linux, ok for trunk?
2015-03-09 Marek Polacek
* c-convert.c (convert): Make use of do_ubsan_in_current_function.
* c-decl.
On Thu, Mar 5, 2015 at 10:53 AM, Thomas Preud'homme wrote:
> diff --git a/gcc/dominance.c b/gcc/dominance.c
> index 33d4ae4..09c8c90 100644
> --- a/gcc/dominance.c
> +++ b/gcc/dominance.c
> @@ -982,7 +982,7 @@ nearest_common_dominator_for_set (enum cdi_direction dir,
> bitmap blocks)
>
> A_Dom
On Mon, Mar 09, 2015 at 12:35:54PM +0100, Marek Polacek wrote:
> I noticed that we can use the do_ubsan_in_current_function wrapper more, which
> allows us to simplify the code a bit further.
>
> Ran ubsan testsuite on x86_64-linux, ok for trunk?
>
> 2015-03-09 Marek Polacek
>
> * c-con
On Mon, Mar 09, 2015 at 12:48:56PM +0100, Jakub Jelinek wrote:
> > --- gcc/cp/cp-ubsan.c
> > +++ gcc/cp/cp-ubsan.c
> > @@ -63,9 +63,7 @@ cp_ubsan_instrument_vptr_p (tree type)
> >if (!flag_rtti || flag_sanitize_undefined_trap_on_error)
> > return false;
> >
> > - if (current_function_de
New patch with review results:
* 6-byte-NOP only for ZARCH
* Formatting.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
>From 176268849643c46427ea873c35390700ea7a4489 Mon Sep 17 00:00:00 2001
From: Dominik Vogt
Date: Mon, 23 Feb 2015 13:48:26 +0100
Subject: [PATCH 1/2] S390: Hotpatching
On 13/02/15 13:48 +, Matthew Wahab wrote:
On 11/02/15 15:43, Jonathan Wakely wrote:
On 11/02/15 11:14 +, Matthew Wahab wrote:
Attached the fixed patch.
Tested by running check-target-libstdc++-v3, with the modified tests,
for arm-none-eabi and aarch64-none-linux-gnu.
Ok to commit?
OK
On Mon, 9 Mar 2015, Richard Biener wrote:
> On Fri, 6 Mar 2015, Jeff Law wrote:
>
> > On 03/06/15 06:16, Richard Biener wrote:
> > >
> > > This fixes PR63155 and reduces the memory usage at -O0 from reported
> > > 10GB (couldn't verify/update on my small box) to 350MB (still worse
> > > compared
This fixes tail-merging and folding related wrong-code regressions
caused by ignoring alignment of memory references. It introduces
OEP_ADDRESS_OF (in addition to OEP_CONSTANT_ADDRESS_OF) to not
hurt the cases where we are only interested in addresses.
Bootstrapped and tested on x86_64-unknown-l
On Fri, Mar 6, 2015 at 12:48 PM, Bernd Edlinger
wrote:
> Hi Richard,
>
> here is my new proposal, it addresses your objections and generates
> "better" code for this test case:
>
> main:
> .LFB0:
> .cfi_startproc
> pushq%rbp
> .cfi_def_cfa_offset 16
> .cfi_offset 6, -16
> m
On Fri, Feb 27, 2015 at 05:29:47PM -0500, Jason Merrill wrote:
> On 02/19/2015 07:03 PM, Jakub Jelinek wrote:
> >+ /* Avoid warning for !!b == y where b is boolean. */
> >+ && (!DECL_P (current.lhs)
> >+ || TREE_TYPE (current.lhs) == NULL_TREE
> >+ || TREE_CODE (TREE_TY
On Fri, Mar 6, 2015 at 7:04 PM, Alexandre Oliva wrote:
> On Feb 26, 2015, Alexandre Oliva wrote:
>
>> So far, all the differences I looked at were caused by padding at the
>> end of BBs, and by jump stmts without line numbers at the end of BBs,
>> both right after the debug reset stmts the propos
On Fri, 6 Mar 2015 17:01:13 +0300
Ilya Verbin wrote:
> On Thu, Feb 26, 2015 at 20:25:11 +0300, Ilya Verbin wrote:
> > On Wed, Feb 25, 2015 at 10:36:08 +0100, Thomas Schwinge wrote:
> > > > Julian Brown wrote:
> > > > This is a version of the previously-posted patch to rework
> > > > initialisati
On Fri, Mar 06, 2015 at 06:41:38PM +0300, Yury Gribov wrote:
> On 03/06/2015 05:23 PM, Marat Zakirov wrote:
> >Hi all!
> >
> >Currently !ASAN_GLOBALS disables red-zones for global variables but
> >keeps their checks. This simple patch disables these checks too.
> >
> >--Marat
>
> Jakub,
>
> Given
On Fri, Mar 06, 2015 at 04:55:07PM +0300, Ilya Verbin wrote:
> Hi,
>
> I've found a bug in intelmic-mkoffload, it works only when the path to gcc is
> absolute or relative, but doesn't work when it's specified in the PATH env
> var.
> Here is the fix, I've got a piece of code from gcc/config/nvpt
On Mon, Mar 02, 2015 at 01:25:43PM +0300, Ilya Enkovich wrote:
> > --- a/gcc/toplev.c
> > +++ b/gcc/toplev.c
> > @@ -1376,6 +1376,11 @@ process_options (void)
> > {
> >if (targetm.chkp_bound_mode () == VOIDmode)
> > error ("-fcheck-pointer-bounds is not supported for this targe
This reduces the time spent in cgraph call-site hash by providing
inline version of htab_hash_pointer.
Bootstrap / regtest on x86_64-unknown-linux-gnu in progress.
Ok?
Thanks,
Richard.
2015-03-09 Richard Biener
PR middle-end/44563
* cgraph.h (struct cgraph_edge_hasher): Add
On 03/08/2015 02:52 PM, Jakub Jelinek wrote:
On Sun, Mar 08, 2015 at 02:33:03PM -0400, Ed Smith-Rowland wrote:
I just look to see if a lexed number in libcpp ends in a '.
If so, back up one character and let string processing handle it.
I get one warning and one error for each instance but I'd
On Mon, Mar 9, 2015 at 4:12 PM, Richard Biener wrote:
> ! /* This is a really poor hash function, but it is what the current code
> uses,
> ! so I am reusing it to avoid an additional axis in testing. */
This is a bit silly as a comment, because after your patch the
"current" code is the
On Fri, Mar 06, 2015 at 01:05:31PM +0100, Richard Biener wrote:
> On Thu, Mar 5, 2015 at 9:06 PM, Michael Meissner
> wrote:
> > This patch fixes PR 65240, which was a latent bug that was introduced when I
> > added the -mupper-regs support to the PowerPC compiler. In the PowerPC
> > compiler, if
Am 03/03/2015 um 02:21 PM schrieb Senthil Kumar Selvaraj:
On Mon, Mar 02, 2015 at 08:40:17PM +0100, Georg-Johann Lay wrote:
The new specs file generation introduces several problems. This patch
- Fix build warnings
- Clean up unused code and the old, now dead specs definitions.
- Removes unu
Hi,
As added in the PR, this issue is also present on 4.9 branch and
affects at least arm-linux-gnueabihf target (as reported in PR61207).
I've backported it in the 4.9 branch with the attached patch. The
difference with the trunk code is due the code introduced by PR63587
fix (I didn't checked
On 03/09/2015 10:34 AM, Jakub Jelinek wrote:
On Fri, Feb 27, 2015 at 05:29:47PM -0500, Jason Merrill wrote:
On 02/19/2015 07:03 PM, Jakub Jelinek wrote:
+ /* Avoid warning for !!b == y where b is boolean. */
+ && (!DECL_P (current.lhs)
+ || TREE_TYPE (current.lhs) =
Am 03/03/2015 um 02:21 PM schrieb Senthil Kumar Selvaraj:
On Mon, Mar 02, 2015 at 08:40:17PM +0100, Georg-Johann Lay wrote:
BTW, anyone knows what -march= is good for? It allows all kinds of silly
option combinations like "-march=avrtiny -mmcu=atmega8" without any
complaints.
IIRC, -march was
Forget this last patch.
The syntax of my dg lines was wrong and I'm seeing errors I'm not sure I
like.
I need to look at this further.
I'm sorry for the noise.
On Mon, Mar 09, 2015 at 04:38:57AM +0100, Jan Hubicka wrote:
> --- varasm.c (revision 221269)
> +++ varasm.c (working copy)
> @@ -1630,35 +1630,30 @@ default_ctor_section_asm_out_constructor
> void
> notice_global_symbol (tree decl)
> {
> - const char **type = &first_global_object_name;
> +
On 03/09/15 08:38, Richard Biener wrote:
On Fri, Mar 6, 2015 at 7:04 PM, Alexandre Oliva wrote:
On Feb 26, 2015, Alexandre Oliva wrote:
So far, all the differences I looked at were caused by padding at the
end of BBs, and by jump stmts without line numbers at the end of BBs,
both right after
> make_decl_rtl only calls this for:
> if (TREE_CODE (decl) == FUNCTION_DECL
> && cgraph_node::get (decl)
> && cgraph_node::get (decl)->instrumentation_clone)
> Is it intentional you are doing it unconditionally?
Yes, ultimate_transparent_alias_target is either called in make_decl_rt
On 03/09/15 03:53, Steven Bosscher wrote:
On Wed, Mar 4, 2015 at 12:09 PM, Alex Velenko wrote:
For example, in arm testcase pr43920-2.c, CSE previously decided not to put
an "obvious" note on insn 9, as set value was the same as note value.
At the same time, other insns set up as -1 were set up
On Thu, Mar 5, 2015 at 6:14 PM, Alan Modra wrote:
> This arranges to build a powerpc64le-linux compiler without -m32
> support by default. Bootstrapped and regression tested on Ubuntu
> powerpc64le-linux without --disable-multilib, and on powerpc64-linux
> and powerpc-linux. OK for mainline and
Hi!
I've reapplied David's fix to trunk after Matthias tested it on sparc* and
I've regtested it on x86_64-linux and i686-linux.
2015-03-09 Jakub Jelinek
PR sanitizer/63958
Reapply:
2014-10-14 David S. Miller
* sanitizer_common/sanitizer_platform_limits_lin
Hi!
BINFO_BASE_BINFO always gives a TREE_BINFO, so using DECL_CONTEXT on it
is wrong. The following patch fixes it to use BINFO_TYPE instead.
Bootstrapped/regtested on x86_64-linux and i686-linux, tested also on the
testcase in the PR. Ok for trunk?
We don't seem to have infrastructure for tes
On 03/06/2015 02:01 PM, Jason Merrill wrote:
On 03/06/2015 05:01 PM, Jason Merrill wrote:
On 03/06/2015 04:54 PM, Aldy Hernandez wrote:
But doesn't this still involve a MODIFY_EXPR, i.e. return retval =
D.2349?
If I understand you correct, no.
gimplify_return_expr creates a new temporary and
On Mar 8, 2015, at 10:38 AM, Iain Sandoe wrote:
> +Ian
> + ping
So, all the darwinness of the patch looks fine to me. One maintainer down,
just need libiberty approval.
If the work becomes too bothersome, the comment out the line and say, # does’t
work with libcc1 approach for the config frag
On 03/09/15 03:42, Richard Biener wrote:
On Fri, 6 Mar 2015, Jeff Law wrote:
On 03/06/15 06:16, Richard Biener wrote:
This fixes PR63155 and reduces the memory usage at -O0 from reported
10GB (couldn't verify/update on my small box) to 350MB (still worse
compared to 4.8 which needs only 50MB)
On 03/09/15 12:31, Jakub Jelinek wrote:
Hi!
BINFO_BASE_BINFO always gives a TREE_BINFO, so using DECL_CONTEXT on it
is wrong. The following patch fixes it to use BINFO_TYPE instead.
Bootstrapped/regtested on x86_64-linux and i686-linux, tested also on the
testcase in the PR. Ok for trunk?
We
On 03/08/15 03:14, Richard Biener wrote:
On March 7, 2015 5:20:08 PM CET, Jeff Law wrote:
On 03/07/15 01:34, Richard Biener wrote:
On March 6, 2015 9:22:05 PM CET, Martin Sebor
wrote:
On 03/06/2015 10:28 AM, Jeff Law wrote:
On 03/02/15 09:28, Martin Sebor wrote:
On 03/02/2015 06:58 AM, Ri
On 03/09/15 07:01, Richard Biener wrote:
Ok, like the following which adds a verify_ssa_coalescing () function
(which could in theory be called from IL verification like verify_ssa)
and calls it when ENABLE_CHECKING is defined.
Bootstrap & regtest running on x86_64-unknown-linux-gnu.
It didn't
On Mar 8, 2015, at 5:26 PM, Sandra Loosemore wrote:
> In general, the GCC manual documents the version of the compiler that it goes
> with. New features are being added all the time, and it's not terribly
> useful to users to document that such-and-such a feature isn't supported in
> ancient G
OK, thanks.
Jason
In this testcase we were crashing while trying to build up a copy
constructor call within the thunk for the function pointer conversion
operator, because we try to resolve 'this' and there is no 'this' in a
static member function. Fixed by avoiding that resolution when we're
calling a construc
2015-03-09 19:02 GMT+03:00 Georg-Johann Lay :
> Am 03/03/2015 um 02:21 PM schrieb Senthil Kumar Selvaraj:
>>
>> On Mon, Mar 02, 2015 at 08:40:17PM +0100, Georg-Johann Lay wrote:
>>>
>>> The new specs file generation introduces several problems. This patch
>>>
>>> - Fix build warnings
>>>
>>> - Cle
I backported the fix to the 4.9 branch already, so it would be nice to
get the test cases fixes there as well.
Martin -- that's your cue ;-)
Sure. It's on my list of things to do.
Martin
Hi!
As mentioned by richi, !x == 0 is actually equivalent to !(x == 0)
and x != 0 and !x != 0 is equivalent to !(x != 0) and x == 0, so this
patch adjusts the warning not to warn in that case, as adding parens
doesn't change anything.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for
Hi!
As mentioned in the PR, e.g. wide-int is very unhappy if the shift second
operand doesn't fit into the shift mode.
Generally, the backend shift patterns ensure that, but in debug insns
nothing enforces that.
This patch fixes that by making sure e.g. QImode shifts have always at
QImode shift a
Hi,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65366
GDB Python support upstream has always been compatible with Python3.
Fedora since F-22 builds GDB with Python3 by default (<=F-21 GDB used Python2).
gdbhooks.py in GCC trunk is compatible with Python2 but not Python3.
gdb-7.9-10.fc23.x86_64
Hello.
During compilation of Chromium project, I noticed (perf top) that
ix86_valid_target_attribute is utilized by about 0.8-1.9%.
Following patch introduces simple optimization that reduces the utilization to
~0.05%.
Tests have been running on x86_64-linux-pc.
Ready for trunk?
Martin
>From d
I committed this patch to gcc-5/changes.html to mention the new go and
gofmt programs.
Ian
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v
retrieving revision 1.86
diff -u -r1.86 changes.html
--- changes
Hello gentlemen.
The problem here is that we pick up the system's CFLAGS and pass it down
to the target libraries. This causes havoc when, for instance, CFLAGS
is -march=x86-64 and the target is powerpc-linux.
I don't see in what scenario the toplevel shell's CFLAGS would be of any
use in t
On Mon, 9 Mar 2015, Jakub Jelinek wrote:
> Hi!
>
> As mentioned by richi, !x == 0 is actually equivalent to !(x == 0)
> and x != 0 and !x != 0 is equivalent to !(x != 0) and x == 0, so this
> patch adjusts the warning not to warn in that case, as adding parens
> doesn't change anything.
>
> Boot
Yoshinori Sato wrote:
>> * config/sh/t-linux (MULTILIB_EXCEPTIONS): Define for m2a cases.
[snip]
> It works fine.
Thanks for checking. I've committed it on trunk as revision 221287.
Regards,
kaz
This bug was one I unfortunately introduced with the -mupper-regs support. If
the reload pass needed to reload a PLUS operation (for example, due to using
odd address with the LD/STD instructions), it would go through all of the
registers you could load DImode into, and see if it is a preferred re
Previously, if a Go program was crashing due to a signal due to heap
corruption, it could in some cases invoke the Go malloc function while
the Go malloc lock was held, leading to a recursive crash. This patch
fixes the problem by making __go_file_line simply assume that
libbacktrace keeps strings
This libgo patch fixes a crash when explicitly freeing a small map.
This is PR 65349. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r cf89d7a7f372 libgo/runtime/go-map-index.c
--- a/libgo/runtime/go-map-index.c Mon Mar 09 16:36:59 2015 -0700
This patch to libgo adds all the current gccgo GOARCH values to the
size maps used by the cgo program. Bootstrapped and ran Go testsuite
on x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 3a7299f45092 libgo/go/cmd/cgo/main.go
--- a/libgo/go/cmd/cgo/main.go Mon Mar 09 16:42:06 2015
On 03/09/15 15:26, Jakub Jelinek wrote:
Hi!
As mentioned by richi, !x == 0 is actually equivalent to !(x == 0)
and x != 0 and !x != 0 is equivalent to !(x != 0) and x == 0, so this
patch adjusts the warning not to warn in that case, as adding parens
doesn't change anything.
Bootstrapped/regtest
On 03/09/15 15:23, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, e.g. wide-int is very unhappy if the shift second
operand doesn't fit into the shift mode.
Generally, the backend shift patterns ensure that, but in debug insns
nothing enforces that.
This patch fixes that by making sure e.g. Q
> Hi!
>
> BINFO_BASE_BINFO always gives a TREE_BINFO, so using DECL_CONTEXT on it
> is wrong. The following patch fixes it to use BINFO_TYPE instead.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, tested also on the
> testcase in the PR. Ok for trunk?
>
> We don't seem to have infr
On 03/06/2015 06:03 PM, Ville Voutilainen wrote:
So.. just to clarify that we're on the same page.. making volatile-qualified
types non-trivially copyable is ok, but making wrappers of volatile-qualified
types non-trivially copyable is not ok? That's easily doable
implementation-wise,
but it mak
On 03/09/2015 02:33 PM, Aldy Hernandez wrote:
On 03/06/2015 02:01 PM, Jason Merrill wrote:
On 03/06/2015 05:01 PM, Jason Merrill wrote:
On 03/06/2015 04:54 PM, Aldy Hernandez wrote:
But doesn't this still involve a MODIFY_EXPR, i.e. return retval =
D.2349?
If I understand you correct, no.
g
Thanks for the quick response.
Patch built and regtested on x86_64-unknown-linux-gnu.
Currently the stub for sync memory in single.c invokes "asm volatile
("" : : : "memory")" but _gfortran_caf_sync_memory is not called when
the code is compiled with -fcoarray=single.
Please let me know if I hav
Hi,
this is part of my last week experiments on ICF performance work that seems
simple&effective enough even at this stage. This patch moves checks of DECL
itself from equals_private (that happens after reading function body) to
equals_wpa (that happens before) and organizes them in a sequence fro
>
> This reduces the time spent in cgraph call-site hash by providing
> inline version of htab_hash_pointer.
>
> Bootstrap / regtest on x86_64-unknown-linux-gnu in progress.
>
> Ok?
>
> Thanks,
> Richard.
>
> 2015-03-09 Richard Biener
>
> PR middle-end/44563
> * cgraph.h (struc
On 2015.03.09 at 14:00 -0400, David Edelsohn wrote:
> On Thu, Mar 5, 2015 at 6:14 PM, Alan Modra wrote:
> > This arranges to build a powerpc64le-linux compiler without -m32
> > support by default. Bootstrapped and regression tested on Ubuntu
> > powerpc64le-linux without --disable-multilib, and o
On 03/09/15 16:22, Aldy Hernandez wrote:
Hello gentlemen.
The problem here is that we pick up the system's CFLAGS and pass it down
to the target libraries. This causes havoc when, for instance, CFLAGS
is -march=x86-64 and the target is powerpc-linux.
I don't see in what scenario the toplevel s
71 matches
Mail list logo
