PING
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01763.html
2014-10-17 Shiva Chen shiva0...@gmail.com
Fix libatomic behavior for big endian toolchain
* cas_n.c: Fix shift amount for big endian toolchain
* config/arm/exch_n.c: Fix shift amount for big endian toolchain
* exch_n.c: Fix shift
On Mon, Jan 05, 2015 at 10:39:03PM +0100, Jakub Jelinek wrote:
http://gcc.gnu.org/ml/gcc-patches/2014-12/msg00297.html
- -fsanitize=vptr support
How is this different from vtable pointer verification that we already
support? Is there some reason we can't just use that instead?
I
On Tue, 6 Jan 2015, Mikhail Maltsev wrote:
Hi, all!
I'm pinging about this patch:
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01925.html (PR c/48956)
I know that maybe it's too early for sending a ping (less than 2
weeks), but I also have a question regarding my patch:
Is this patch
Ping!
On 12/24/2014 07:28 PM, Dimitris Papavasiliou wrote:
Hello,
The attached patch fixes an issue reported a couple of years ago in Bug
51891 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51891). The problem
is caused because classes without instance variables have no ivar list
at all, so
Hi!
I'd like to ping 3 patches:
http://gcc.gnu.org/ml/gcc-patches/2014-12/msg01519.html
- PR64344 - -fsanitize=float-cast-overflow fix - the C FE part
is approved, but not the sanitizer bits outside of the FE
http://gcc.gnu.org/ml/gcc-patches/2014-12/msg01271.html
- PR64265 - tsan
On Mon, Jan 05, 2015 at 02:27:41PM -0700, Jeff Law wrote:
On 01/05/15 06:53, Jakub Jelinek wrote:
Hi!
I'd like to ping 3 patches:
http://gcc.gnu.org/ml/gcc-patches/2014-12/msg01519.html
- PR64344 - -fsanitize=float-cast-overflow fix - the C FE part
is approved, but not the
On 01/05/15 06:53, Jakub Jelinek wrote:
Hi!
I'd like to ping 3 patches:
http://gcc.gnu.org/ml/gcc-patches/2014-12/msg01519.html
- PR64344 - -fsanitize=float-cast-overflow fix - the C FE part
is approved, but not the sanitizer bits outside of the FE
OK.
Hi, all!
I'm pinging about this patch:
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01925.html (PR c/48956)
I know that maybe it's too early for sending a ping (less than 2
weeks), but I also have a question regarding my patch:
Is this patch considered small enough to be accepted without
Any comments on this?
On 19 December 2014 at 09:21, Ville Voutilainen
ville.voutilai...@gmail.com wrote:
Tested on Linux-x64.
/cp
2014-12-19 Ville Voutilainen ville.voutilai...@gmail.com
Reject trailing return type for an operator auto().
* decl.c (grokdeclarator): Reject
Hi!
I'd like to ping 3 patches:
http://gcc.gnu.org/ml/gcc-patches/2014-12/msg00546.html
PR63831 - P1 - fix __has_attribute/__has_cpp_attribute handling
http://gcc.gnu.org/ml/gcc-patches/2014-12/msg00568.html
PR64023 - P3 - fix flags passed to non-bootstrapped host modules during
bootstrap
Hi!
I'd like to ping this patch to fix gcc/Makefile dependencies
for gengtype objects as well as gcc-{ar,nm,ranlib} objects.
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg03092.html
Jakub
On Wed, Dec 3, 2014 at 11:45 AM, Jakub Jelinek ja...@redhat.com wrote:
Hi!
I'd like to ping this patch to fix gcc/Makefile dependencies
for gengtype objects as well as gcc-{ar,nm,ranlib} objects.
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg03092.html
Ok.
Thanks,
Richard.
Jakub
check RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}
asan.exp tsan.exp ubsan.exp'
)?
I'd like to ping the
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02945.html
patch.
Ping.
Jakub
On Sat, Nov 15, 2014 at 11:57 AM, Mircea Namolaru
mircea.namol...@inria.fr wrote:
The close of stage 1 is getting close (very close). Even there is not so much
new code (basically
the new code computes the separation class option for AST build), I am not
sure that the patch
qualify for
New optimization flags and new params need documentation in
gcc/doc/invoke.texi.
Thanks. Added description in invoke.texi. The patch is in trunk.
The description of the --params suggest they provide fixed values - is
there no way to autodetect sensible values with a cost-model? I
hardly
The close of stage 1 is getting close (very close). Even there is not so much
new code (basically
the new code computes the separation class option for AST build), I am not sure
that the patch
qualify for stage 2.
There is very nice code generated by unroll-and-jam (stride mining) for small
Hi!
On Tue, Oct 28, 2014 at 01:44:50PM +0100, Jakub Jelinek wrote:
On Mon, Oct 27, 2014 at 05:16:05PM +0100, Jakub Jelinek wrote:
Here is an updated patch, ok if bootstrap/testing passes (so far just
checked with
make -j16 -k check RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} asan.exp
On Wed, Oct 8, 2014 at 5:35 AM, Bin Cheng bin.ch...@arm.com wrote:
Hi,
This patch is posted long before in a series of patches at
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01392.html . Since the
preceding patch is changed according to review comments, also because it's
long time not
On Oct 15, 2014, at 6:36 AM, Richard Biener richard.guent...@gmail.com wrote:
+ wide_int max_wi = wi::max_value (TYPE_PRECISION (type), UNSIGNED);
+ max_val = wi::to_widest (wide_int_to_tree (type, max_wi));
ick - there must be a better way to extend max_wi to infinite
precision.
Hi,
This patch is posted long before in a series of patches at
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01392.html . Since the
preceding patch is changed according to review comments, also because it's
long time not reviewed, I rebased and updated this patch as attached.
With this patch,
Ping.
On 15 Sep 18:43, Ilya Tocar wrote:
On 01 Sep 18:38, Ilya Tocar wrote:
Please mention the PR in the ChangeLog entry and add some testcases
(can be gcc.target/i386/, but we should have it tested).
Does this change anything on say register short sil __asm (sil); in
32-bit
mode
On Tue, Sep 30, 2014 at 02:44:21PM +0400, Ilya Tocar wrote:
2014-09-15 Ilya Tocar ilya.to...@intel.com
PR middle-end/62120
* varasm.c (decode_reg_name_and_count): Check availability for
registers from ADDITIONAL_REGISTER_NAMES.
Testsuite/
2014-09-15
Hi all, hi Jason,
On 08/24/2014 12:11 PM, Manuel López-Ibáñez wrote:
PING: https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01709.html
Today, I picked this unreviewed patch prepared by Manuel back in August
and trivially completed it by adjusting the testcases (all the tweaks
seem the expected
... forgot to attach the complete patch ;)
Paolo.
Index: cp/cp-tree.h
===
--- cp/cp-tree.h(revision 215710)
+++ cp/cp-tree.h(working copy)
@@ -5418,7 +5418,6 @@ extern const char
OK.
Jason
I don't want to cause you more work Paolo, but perhaps this should be
documented in https://gcc.gnu.org/gcc-5/changes.html. ?
Something like:
* Excessive template instantiation depth is now a fatal error. This
prevents excessive diagnostics that usually do not help to identify
the problem.
Hi,
On 09/30/2014 04:51 PM, Manuel López-Ibáñez wrote:
I don't want to cause you more work Paolo, but perhaps this should be
documented in https://gcc.gnu.org/gcc-5/changes.html. ?
Something like:
* Excessive template instantiation depth is now a fatal error. This
prevents excessive
On 18-09-14 19:46, Diego Novillo wrote:
On Thu, Sep 18, 2014 at 10:56 AM, Yury Gribov y.gri...@samsung.com wrote:
On 08/04/2014 12:14 PM, Tom de Vries wrote:
On 04-08-14 08:45, Yury Gribov wrote:
Thanks! My 2 (actually 4) cents below.
Hi Yuri,
thanks for the review.
+if ($#ARGV ==
On Fri, Sep 19, 2014 at 12:41:53PM +0200, Tom de Vries wrote:
I've followed up on the explanation by Segher about 2.15 File module
version and fixed the comment.
I've not added the 2.15 file module version check on copy Segher also
mentioned, since I'm not sure about that one. AFAIU the
On Fri, Sep 19, 2014 at 6:41 AM, Tom de Vries tom_devr...@mentor.com wrote:
So it's a question of predictability (always do the same or do nothing) vs.
robustness (do as much as you can given the circumstances). I'm not sure
which one is better in this case.
I think it's fine the way it is
On Mon, Sep 15, 2014 at 01:38:42PM +0400, Yury Gribov wrote:
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -176,7 +176,7 @@ along with GCC; see the file COPYING3. If not see
DEF_BUILTIN (ENUM, __builtin_ NAME, BUILT_IN_NORMAL, TYPE, TYPE,\
true, true, true, ATTRS,
Added Marek to comment on proposed UBSan option change.
On 09/18/2014 02:52 PM, Jakub Jelinek wrote:
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -1551,6 +1551,12 @@ common_handle_option (struct gcc_options *opts,
| SANITIZE_RETURNS_NONNULL_ATTRIBUTE))
On 08/04/2014 12:14 PM, Tom de Vries wrote:
On 04-08-14 08:45, Yury Gribov wrote:
Thanks! My 2 (actually 4) cents below.
Hi Yuri,
thanks for the review.
+if ($#ARGV == 1 ($ARGV[0] eq -i || $ARGV[0] eq
--inline)) {
+$diff = $ARGV[1];
Can we shift here and then just set $diff to
On Thu, Sep 18, 2014 at 10:56 AM, Yury Gribov y.gri...@samsung.com wrote:
On 08/04/2014 12:14 PM, Tom de Vries wrote:
On 04-08-14 08:45, Yury Gribov wrote:
Thanks! My 2 (actually 4) cents below.
Hi Yuri,
thanks for the review.
+if ($#ARGV == 1 ($ARGV[0] eq -i || $ARGV[0] eq
On Thu, 18 Sep 2014, Jakub Jelinek wrote:
Seems for -fdelete-null-pointer-checks we got it wrong too,
IMHO for -fsanitize={null,{,returns-}nonnull-attribute,undefined}
we want to disable it unconditionally, regardless of whether
that option appears on the command line or not.
And we handle
On 09/05/2014 10:54 AM, Yury Gribov wrote:
Hi all,
This patch enables -fsanitize-recover for KASan by default. This causes
KASan to continue execution after error in case of inline
instrumentation. This feature is needed because
- reports during early bootstrap won't even be printed
- needed to
---
From: Yury Gribov
Sent: Friday, August 22, 2014 12:47PM
To: GCC Patches
Cc: Jakub Jelinek, Marek Polacek, t...@alumni.duke.edu, sabrina...@gmail.com
Subject: [PATCH] Fix Asan ICEs on unexpected types (PR62140, PR61897)
On 08/22/2014 12:47 PM, Yury
On Mon, Sep 01, 2014 at 11:22:12AM +0400, Yury Gribov wrote:
BTW regarding ChangeLog: should I mention both bugs (they are
duplicates) or just one of them?
You can mention both if you want (on separate lines), or just the
one the other has been DUPed to.
commit
On 08/01/2014 07:53 PM, Jakub Jelinek wrote:
I think we should use David Malcolm's approach i.e. add some --report-bug
flag
to driver. This could be enabled by default at configure time via
--with-spec.
-freport-bug or whatever we call it should not be, at least if it attempts
to communicate
Thanks Jeff and Jakub, I've reposted ICE debugging patch into
gcc-patches mailing list
(https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00285.html).
-Maxim
On 08/01/2014 11:29 PM, Jeff Law wrote:
On 08/01/14 02:00, Jakub Jelinek wrote:
On Thu, Jul 24, 2014 at 04:39:28PM +0400, Maxim Ostapenko
On Thu, Jul 24, 2014 at 04:39:28PM +0400, Maxim Ostapenko wrote:
Ping.
Don't want to review a patch I wrote partially, so just a few comments:
1) IMHO it should be configure time selectable (not sure about the default,
but for non-release branches IMHO it should default to off, for release
On 08/01/2014 12:00 PM, Jakub Jelinek wrote:
Don't want to review a patch I wrote partially, so just a few comments:
1) IMHO it should be configure time selectable (not sure about the default,
but for non-release branches IMHO it should default to off, for release
branches I don't know). The
Jakub Jelinek ja...@redhat.com writes:
Don't want to review a patch I wrote partially, so just a few comments:
1) IMHO it should be configure time selectable (not sure about the default,
but for non-release branches IMHO it should default to off, for release
branches I don't know). The point
On Fri, Aug 01, 2014 at 08:43:27AM -0700, Andi Kleen wrote:
Jakub Jelinek ja...@redhat.com writes:
Don't want to review a patch I wrote partially, so just a few comments:
1) IMHO it should be configure time selectable (not sure about the default,
but for non-release branches IMHO it should
On Fri, Aug 01, 2014 at 12:13:18PM +0400, Yury Gribov wrote:
On 08/01/2014 12:00 PM, Jakub Jelinek wrote:
Don't want to review a patch I wrote partially, so just a few comments:
1) IMHO it should be configure time selectable (not sure about the default,
but for non-release branches IMHO it
On 08/01/14 02:00, Jakub Jelinek wrote:
On Thu, Jul 24, 2014 at 04:39:28PM +0400, Maxim Ostapenko wrote:
Ping.
Don't want to review a patch I wrote partially, so just a few comments:
1) IMHO it should be configure time selectable (not sure about the default,
but for non-release branches IMHO
On 07/31/2014 08:49 AM, Jeff Law wrote:
This is fine. Thanks,
Commited in r213367.
On 07/18/2014 05:38 PM, Jakub Jelinek wrote:
Do you error out on -fsanitize=thread -fsanitize=kernel-address ?
Perhaps -fsanitize=kernel-address -fsanitize=address should be invalid too?
Yes, all these combinations are invalid.
But you don't error out on that.
Ok, fixed.
Then in
On 07/30/14 08:34, Yury Gribov wrote:
On 07/18/2014 05:38 PM, Jakub Jelinek wrote:
Do you error out on -fsanitize=thread -fsanitize=kernel-address ?
Perhaps -fsanitize=kernel-address -fsanitize=address should be
invalid too?
Yes, all these combinations are invalid.
But you don't error out
Hello,
Ping for https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00237.html
Thanks in advance for your feedback,
With Kind Regards,
Olivier
On Jul 3, 2014, at 16:57 , Olivier Hainque hain...@adacore.com wrote:
From gcc/i386/config/mingw32.h, STARTFILE_SPEC and ENDFILE_SPEC include
crtbegin.o
Forwarded Message
Subject: [PATCH] Fix mklog to support running from arbitrary folder
Date: Mon, 21 Jul 2014 12:32:45 +0400
From: Yury Gribov y.gri...@samsung.com
To: GCC Patches gcc-patches@gcc.gnu.org
CC: Diego Novillo dnovi...@google.com, Trevor Saunders
Ping.
Original Message
Subject:[PATCH][Ping v4] Add patch for debugging compiler ICEs
Date: Fri, 11 Jul 2014 17:44:28 +0400
From: Maxim Ostapenko m.ostape...@partner.samsung.com
To: GCC Patches gcc-patches@gcc.gnu.org
CC: Yury Gribov y.gri...@samsung.com, Slava
Hi!
I'd like to ping the -fsanitize=alignment patch:
http://gcc.gnu.org/ml/gcc-patches/2014-07/msg00334.html
Thanks.
Jakub
Ping. Added small changes due to previous discussion in community.
Original Message
Subject:[PATCH][Ping v3] Add patch for debugging compiler ICEs
Date: Fri, 04 Jul 2014 18:32:44 +0400
From: Maxim Ostapenko m.ostape...@partner.samsung.com
To: GCC Patches gcc
Ping.
Original Message
Subject:[PATCH][Ping v2] Add patch for debugging compiler ICEs
Date: Thu, 26 Jun 2014 19:46:08 +0400
From: Maxim Ostapenko m.ostape...@partner.samsung.com
To: GCC Patches gcc-patches@gcc.gnu.org
CC: Yury Gribov y.gri...@samsung.com
Ping.
Original Message
Subject:[PATCH][Ping] Add patch for debugging compiler ICEs
Date: Wed, 11 Jun 2014 18:15:27 +0400
From: Maxim Ostapenko m.ostape...@partner.samsung.com
To: GCC Patches gcc-patches@gcc.gnu.org
CC: Yury Gribov y.gri...@samsung.com, Slava
Have already been done in r211699. Does it work for you? Adding a test
would still be useful.
-Y
-Original Message-
From: Marat Zakirov [mailto:m.zaki...@samsung.com]
Sent: Friday, June 06, 2014 3:43 PM
To: 'gcc-patches@gcc.gnu.org'
Cc: 'Konstantin Serebryany'; 'Jakub Jelinek'; 'Slava Garbuzov'; Gribov Yury;
'Marat Zakirov'
Subject: [PATCH] Fix for PR 61422
Hi all,
Here's a patch
Ping.
Original Message
Subject:[PATCH] Add patch for debugging compiler ICEs
Date: Mon, 02 Jun 2014 19:21:14 +0400
From: Maxim Ostapenko m.ostape...@partner.samsung.com
To: GCC Patches gcc-patches@gcc.gnu.org
CC: Yury Gribov y.gri...@samsung.com, Slava
On Sat, May 24, 2014 at 12:54 PM, Jonathan Wakely jwakely@gmail.com wrote:
On 24 May 2014 17:07, David Edelsohn wrote:
This patch broke the ability to run the libstdc++ testsuite on AIX.
I now see the following errors:
bad switch -O: must be -all, -about, -indices, -inline, -expanded,
This patch broke the ability to run the libstdc++ testsuite on AIX.
I now see the following errors:
bad switch -O: must be -all, -about, -indices, -inline, -expanded, -line, -lin
estop, -lineanchor, -nocase, -start, or --
while executing
regexp \-O $cxxflags
(procedure libstdc++_init
On 24 May 2014 17:07, David Edelsohn wrote:
This patch broke the ability to run the libstdc++ testsuite on AIX.
I now see the following errors:
bad switch -O: must be -all, -about, -indices, -inline, -expanded, -line,
-lin
estop, -lineanchor, -nocase, -start, or --
while executing
On 19/05/14 14:57 -0600, Sandra Loosemore wrote:
On 05/17/2014 04:07 AM, Jonathan Wakely wrote:
On 17 May 2014 10:50, Jonathan Wakely wrote:
On 17 May 2014 01:16, Sandra Loosemore wrote:
It appears that this patch from last fall never got reviewed.
On 16/05/14 14:56, Alexey Merzlyakov wrote:
On 07.05.2014 13:28, Ramana Radhakrishnan wrote:
On 05/07/14 09:19, Yury Gribov wrote:
Original Message
Subject: [PING] [PATCH] Fix for PR libstdc++/60758
Date: Thu, 17 Apr 2014 17:48:12 +0400
From: Alexey Merzlyakov
On 20.05.2014 16:25, Richard Earnshaw wrote:
On 16/05/14 14:56, Alexey Merzlyakov wrote:
On 07.05.2014 13:28, Ramana Radhakrishnan wrote:
On 05/07/14 09:19, Yury Gribov wrote:
Original Message
Subject: [PING] [PATCH] Fix for PR libstdc++/60758
Date: Thu, 17 Apr 2014
The following PR is opened for this problem:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61223
Thumb1 failure was also detected and reported in pr60758.
I've proposed a thumb1 bugfix there. Regtest for the fix currently is in
progress.
Patches must be proposed on gcc-patches and / or in
On 20/05/14 14:12, Ramana Radhakrishnan wrote:
The following PR is opened for this problem:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61223
Thumb1 failure was also detected and reported in pr60758.
I've proposed a thumb1 bugfix there. Regtest for the fix currently is in
progress.
On 20.05.2014 17:16, Richard Earnshaw wrote:
On 20/05/14 14:12, Ramana Radhakrishnan wrote:
The following PR is opened for this problem:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61223
Thumb1 failure was also detected and reported in pr60758.
I've proposed a thumb1 bugfix there. Regtest
On 05/20/2014 02:11 AM, Jonathan Wakely wrote:
On 19/05/14 14:57 -0600, Sandra Loosemore wrote:
On 05/17/2014 04:07 AM, Jonathan Wakely wrote:
On 17 May 2014 10:50, Jonathan Wakely wrote:
On 17 May 2014 01:16, Sandra Loosemore wrote:
It appears that this patch from last fall never got
Hi,
I'd like to once again ping this patch from 2014-04-22:
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01319.html
Thanks!
Bill
On 05/19/14 07:10, Bill Schmidt wrote:
Hi,
I'd like to once again ping this patch from 2014-04-22:
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01319.html
OK for the trunk. Thanks for your patience.
jeff
On 05/17/2014 04:07 AM, Jonathan Wakely wrote:
On 17 May 2014 10:50, Jonathan Wakely wrote:
On 17 May 2014 01:16, Sandra Loosemore wrote:
It appears that this patch from last fall never got reviewed.
https://gcc.gnu.org/ml/gcc-patches/2013-10/msg02340.html
Can someone take a look? I'll
On 17 May 2014 01:16, Sandra Loosemore wrote:
It appears that this patch from last fall never got reviewed.
https://gcc.gnu.org/ml/gcc-patches/2013-10/msg02340.html
Can someone take a look? I'll commit the patch on Cesar's behalf if it's
approved.
Libstdc++ patches need to go to the
On 17 May 2014 10:50, Jonathan Wakely wrote:
Then archives's inability...
Oof, not sure what my fingers were thinking there, I meant Then the
archive's inability... :)
On 17 May 2014 10:50, Jonathan Wakely wrote:
On 17 May 2014 01:16, Sandra Loosemore wrote:
It appears that this patch from last fall never got reviewed.
https://gcc.gnu.org/ml/gcc-patches/2013-10/msg02340.html
Can someone take a look? I'll commit the patch on Cesar's behalf if it's
On 07.05.2014 13:28, Ramana Radhakrishnan wrote:
On 05/07/14 09:19, Yury Gribov wrote:
Original Message
Subject: [PING] [PATCH] Fix for PR libstdc++/60758
Date: Thu, 17 Apr 2014 17:48:12 +0400
From: Alexey Merzlyakov alexey.merzlya...@samsung.com
To: Ramana Radhakrishnan
It appears that this patch from last fall never got reviewed.
https://gcc.gnu.org/ml/gcc-patches/2013-10/msg02340.html
Can someone take a look? I'll commit the patch on Cesar's behalf if
it's approved.
-Sandra
On May 16, 2014, at 5:16 PM, Sandra Loosemore san...@codesourcery.com wrote:
It appears that this patch from last fall never got reviewed.
Can someone take a look?
Tentative Ok. Let’s let the library people have a chance to weigh in… I’d
say, let’s give them til Tuesday… should be enough
On 05/05/14 05:58, Florian Weimer wrote:
On 02/03/2014 10:05 AM, Florian Weimer wrote:
On 01/17/2014 11:26 AM, Florian Weimer wrote:
On 01/08/2014 03:57 PM, Florian Weimer wrote:
What about the attached version? It still does not exactly match your
original suggestion because
Original Message
Subject: [PING] [PATCH] Fix for PR libstdc++/60758
Date: Thu, 17 Apr 2014 17:48:12 +0400
From: Alexey Merzlyakov alexey.merzlya...@samsung.com
To: Ramana Radhakrishnan ramra...@arm.com
CC: gcc-patches@gcc.gnu.org gcc-patches@gcc.gnu.org, Viacheslav
Garbuzov
Hi,
On 05/07/2014 10:19 AM, Yury Gribov wrote:
Original Message
Subject: [PING] [PATCH] Fix for PR libstdc++/60758
Date: Thu, 17 Apr 2014 17:48:12 +0400
From: Alexey Merzlyakov alexey.merzlya...@samsung.com
To: Ramana Radhakrishnan ramra...@arm.com
CC: gcc-patches@gcc.gnu.org
On 05/07/14 09:19, Yury Gribov wrote:
Original Message
Subject: [PING] [PATCH] Fix for PR libstdc++/60758
Date: Thu, 17 Apr 2014 17:48:12 +0400
From: Alexey Merzlyakov alexey.merzlya...@samsung.com
To: Ramana Radhakrishnan ramra...@arm.com
CC: gcc-patches@gcc.gnu.org
On 02/03/2014 10:05 AM, Florian Weimer wrote:
On 01/17/2014 11:26 AM, Florian Weimer wrote:
On 01/08/2014 03:57 PM, Florian Weimer wrote:
What about the attached version? It still does not exactly match your
original suggestion because gimple_call_lhs (stmt) can be NULL_TREE if
the result is
Hi,
I'd like to ping this patch:
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01319.html
Thanks!
Bill
--
Bill Schmidt, Ph.D.
IBM Advance Toolchain for PowerLinux
IBM Linux Technology Center
wschm...@linux.vnet.ibm.com
wschm...@us.ibm.com
On Wed, Apr 16, 2014 at 02:45:37PM -0400, DJ Delorie wrote:
I'll approve both patches, if you agree to think about a way to solve
this problem without module-specific configury changes for each such
command line option. I understand the usefulness of having
instrumentation, but the configure
On Wed, Apr 16, 2014 at 11:35 PM, Jeff Law l...@redhat.com wrote:
I'd like to ping 2 patches:
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00140.html
- Ensure GET_MODE_{SIZE,INNER,NUNITS} (const) is constant rather than
memory load after optimization (I'd like to keep the current
On 04/14/2014 01:02 PM, Jakub Jelinek wrote:
On Thu, Apr 10, 2014 at 12:01:31PM -0400, DJ Delorie wrote:
So, now that 4.9 has branched, are both patches ok for trunk, or just the
first one? The first one fixes --with-build-config=bootstrap-ubsan
fully and --with-build-config=bootstrap-asan
I'll approve both patches, if you agree to think about a way to solve
this problem without module-specific configury changes for each such
command line option. I understand the usefulness of having
instrumentation, but the configure hack is a hack.
Note that in a combined tree this isn't a
On 01/13/14 01:07, Jakub Jelinek wrote:
Hi!
I'd like to ping 2 patches:
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00140.html
- Ensure GET_MODE_{SIZE,INNER,NUNITS} (const) is constant rather than
memory load after optimization (I'd like to keep the current MODE_SIZE
patch for the
On Mon, Jan 13, 2014 at 08:22:47AM -0700, Jeff Law wrote:
On 01/13/14 08:20, Jakub Jelinek wrote:
On Mon, Jan 13, 2014 at 08:15:11AM -0700, Jeff Law wrote:
On 01/13/14 01:07, Jakub Jelinek wrote:
I'd like to ping 2 patches:
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00140.html
- Ensure
On Thu, Apr 10, 2014 at 12:01:31PM -0400, DJ Delorie wrote:
But ubsan is a new feature in 4.9, and it is a bootstrap failure
with that feature.
I will leave it up to the release manager to decide if they want this
non-regression patch applied before the branch, then.
This is for the
On Thu, 10 Apr 2014, Tobias Burnus wrote:
I would like to ping the patch:
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01673.html
It's a syntax issue: It simply makes no sense to have a @menu item
which points to @nodes which are at the same or higher level
than the section in which the
Gerald Pfeifer wrote:
Looks fine to me. And probably a good idea for the 4.9 branch as well.
Thanks for the review! However, Jakub has already approved and committed
it for me, just before he has branched 4.9 :-)
Tobias
On Wed, Apr 09, 2014 at 06:29:48PM -0400, DJ Delorie wrote:
- http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01370.html
PR sanitizer/56781
fix --with-build-config=bootstrap-ubsan bootstrap of lto-plugin
I have no particular problem with this patch, although the build has
gotten
I would like to ping the patch:
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01673.html
It's a syntax issue: It simply makes no sense to have a @menu item
which points to @nodes which are at the same or higher level
than the section in which the @menu is.
Newer makeinfo rightfully complain
But ubsan is a new feature in 4.9, and it is a bootstrap failure
with that feature.
I will leave it up to the release manager to decide if they want this
non-regression patch applied before the branch, then.
This is for the host libiberty only, and only when gcc is configured
a certain way.
DJ Delorie wrote:
This is for the host libiberty only, and only when gcc is configured
a certain way. The intent is to have libiberty that is going to be
linked into all the build and host tools instrumented, so that we
actually catch bugs in libiberty or bugs in host/build tools calling
Hi!
I'd like to ping:
- http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01370.html
PR sanitizer/56781
fix --with-build-config=bootstrap-ubsan bootstrap of lto-plugin
- http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01433.html
PR sanitizer/56781
fix --with-build-config=bootstrap-asan
- http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01370.html
PR sanitizer/56781
fix --with-build-config=bootstrap-ubsan bootstrap of lto-plugin
I have no particular problem with this patch, although the build has
gotten beyond my full understanding these days...
However, does this fix a
On 04/09/14 07:07, Jakub Jelinek wrote:
Hi!
I'd like to ping:
- http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01370.html
PR sanitizer/56781
fix --with-build-config=bootstrap-ubsan bootstrap of lto-plugin
- http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01433.html
PR sanitizer/56781
601 - 700 of 952 matches
Mail list logo
