On 29/01/14 17:42, Kyrill Tkachov wrote:
On 23/01/14 08:58, Kyrill Tkachov wrote:
On 16/01/14 18:10, Kyrill Tkachov wrote:
Hi all,
The Cortex-A53 and Cortex-A57 cores support the CRC32 and Crypto extensions to
the ARMv8-A architecture. This patch adds that information to their definitions
in
Hi!
I'd like to ping a few outstanding patches:
- PR59575 P1 ARM dwarf2cfi ICEs fix
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01997.html
- PR59992 P1 var-tracking improvement
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01962.html
- PR60030 P1 ubsan expansion fix
On Tue, Feb 4, 2014 at 4:39 AM, Yury Gribov y.gri...@samsung.com wrote:
Original Message
Subject: [PATCH][PING] Fix for PR59600 (prohibit inlining if
no_sanitize_address)
Date: Tue, 28 Jan 2014 09:13:10 +0400
From: Yury Gribov y.gri...@samsung.com
To: GCC Patches gcc
Richard wrote:
I think you can't rely on pointer equivalence of the lookup_attribute
result so you want instead of
Thanks, makes sense.
Please also name CIF_OPTION_MISMATCH as CIF_ATTRIBUTE_MISMATCH
and say function attribute mismatch in the description.
Done.
What about updated patch?
On Tue, Feb 4, 2014 at 3:32 PM, Yury Gribov y.gri...@samsung.com wrote:
Richard wrote:
I think you can't rely on pointer equivalence of the lookup_attribute
result so you want instead of
Thanks, makes sense.
Please also name CIF_OPTION_MISMATCH as CIF_ATTRIBUTE_MISMATCH
and say function
Richard wrote:
What about updated patch?
Ok if it passes bootstrap and regtesting.
It does, commited in r207497.
-Y
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 ignored and this case needs instrumentation,
Original Message
Subject: [PATCH][PING] Fix for PR59600 (prohibit inlining if
no_sanitize_address)
Date: Tue, 28 Jan 2014 09:13:10 +0400
From: Yury Gribov y.gri...@samsung.com
To: GCC Patches gcc-patches@gcc.gnu.org
Original Message
Subject: [PATCH] Fix
On 23/01/14 08:58, Kyrill Tkachov wrote:
On 16/01/14 18:10, Kyrill Tkachov wrote:
Hi all,
The Cortex-A53 and Cortex-A57 cores support the CRC32 and Crypto extensions to
the ARMv8-A architecture. This patch adds that information to their definitions
in aarch64-cores.def.
Tested
Original Message
Subject: [PATCH] Fix handling of context diff patches in mklog
Date: Wed, 22 Jan 2014 18:36:23 +0400
From: Yury Gribov y.gri...@samsung.com
To: GCC Patches gcc-patches@gcc.gnu.org, Diego Novillo
dnovi...@google.com
CC: Viacheslav Garbuzov
Original Message
Subject: [PATCH] Fix for PR59600
Date: Tue, 21 Jan 2014 14:42:31 +0400
From: Yury Gribov y.gri...@samsung.com
To: GCC Patches gcc-patches@gcc.gnu.org
Hi,
This patch fixes the problem reported in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59600 : functions
On Fri, Jan 10, 2014 at 09:35:22PM +0100, Jakub Jelinek wrote:
2014-01-10 Jakub Jelinek ja...@redhat.com
PR c++/59659
* init.c (build_vec_init): If there are 10+ elements with the
same value in the CONSTRUCTOR, construct them using a runtime loop
rather than one by
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 reasons mentioned there, but also add this patch)
On Mon, Jan 13, 2014 at 9:07 AM, Jakub Jelinek ja...@redhat.com wrote:
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00131.html
- PR target/59617
handle gather loads for AVX512 (at least non-masked ones, masked ones
will need to wait for 5.0 and we need to find how to represent it in
On Mon, Jan 13, 2014 at 09:15:14AM +0100, Uros Bizjak wrote:
On Mon, Jan 13, 2014 at 9:07 AM, Jakub Jelinek ja...@redhat.com wrote:
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00131.html
- PR target/59617
handle gather loads for AVX512 (at least non-masked ones, masked ones
will
On Mon, 13 Jan 2014, Jakub Jelinek wrote:
On Mon, Jan 13, 2014 at 09:15:14AM +0100, Uros Bizjak wrote:
On Mon, Jan 13, 2014 at 9:07 AM, Jakub Jelinek ja...@redhat.com wrote:
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00131.html
- PR target/59617
handle gather loads for AVX512
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 GET_MODE_{SIZE,INNER,NUNITS} (const) is constant rather than
memory load after optimization (I'd
Hello,
On 13 Jan 09:35, Jakub Jelinek wrote:
On Mon, Jan 13, 2014 at 09:15:14AM +0100, Uros Bizjak wrote:
On Mon, Jan 13, 2014 at 9:07 AM, Jakub Jelinek ja...@redhat.com wrote:
Kirill, is it possible for you to test the patch in the simulator? Do
we have a testcase in gcc's testsuite that
On Mon, Jan 13, 2014 at 7:26 PM, Kirill Yukhin kirill.yuk...@gmail.com wrote:
Kirill, is it possible for you to test the patch in the simulator? Do
we have a testcase in gcc's testsuite that can be used to check this
patch?
E.g. gcc.target/i386/avx2-gather* and avx512f-gather*.
This
On Mon, Jan 13, 2014 at 07:40:16PM +0100, Uros Bizjak wrote:
An unrelated observation: gcc should figure out that %k1 mask register
can be used in all gather insns and avoid unnecessary copies at the
beginning of the loop.
I thought about that too, even started modifying sse.md, but then I
Hi!
I'd like to ping a few unreviewed patches:
- use libbacktrace in libsanitizer symbolization - PR sanitizer/59136
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00558.html
- allow building libsanitizer against older kernel headers
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00963.html
-
Hi,
assuming I didn't miss anything (I'm still catching up with my emails),
I'd like to ping the below. Thanks!
Paolo.
///
On 12/10/2013 01:54 PM, Paolo Carlini wrote:
Hi,
as far as I can see, this bug asks for the implementation of
Core/1442, thus don't do a special
On 11/28/13 00:17, Jakub Jelinek wrote:
On Wed, Nov 27, 2013 at 01:11:59PM -0700, Jeff Law wrote:
On 11/27/13 00:36, Jakub Jelinek wrote:
Use libbacktrace for libsanitizer's symbolization (will need tweaking,
depending on next libsanitizer merge, whether the corresponding
sanitizer_common
On Wed, Nov 27, 2013 at 01:06:06PM -0700, Jeff Law wrote:
+ HOST_WIDE_INT offset, sz;
+ sz = ASAN_RED_ZONE_SIZE;
+ sz = data.asan_vec[0] - prev_offset;
Seems to me like the first assignment to sz is dead. Clearly
something isn't right here.
Thanks for catching that out,
Hi Jeff,
On my side, there's
[c++, driver] Add -lrt on Solaris
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01488.html
resubmitted as
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00412.html
It's unclear if the more intrusive solution outlined in the second
message (introduce
On 2013.11.20 at 15:43 +0100, Markus Trippelsdorf wrote:
On 2013.11.20 at 14:41 +0100, Paolo Bonzini wrote:
Note that you need to regenerate all users of libtool.m4. Please post a
patch _with_ the regeneration so that whoever applies it won't screw up.
Ping.
Can you please have look, Paolo?
Here is the patch series that had been posted in Sep that is aimed to
isolate the Android support from targets that actually don't have that
support (We discussed the need of it with Jakub here
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00185.html):
Jakub Jelinek ja...@redhat.com writes:
On Fri, Nov 22, 2013 at 09:36:18AM -0700, Jeff Law wrote:
In fact, I would suggest that anyone with a pending patch from prior
to stage1 close that hasn't gotten feedback by midnight Tuesday ping
their patch. I'd like to have a sense of everything that
In fact, I would suggest that anyone with a pending patch from prior to
stage1 close that hasn't gotten feedback by midnight Tuesday ping their
patch. I'd like to have a sense of everything that is outstanding
sooner rather than later and wrap up any loose ends as quickly as possible.
On 11/27/13 05:30, Eric Botcazou wrote:
In fact, I would suggest that anyone with a pending patch from prior to
stage1 close that hasn't gotten feedback by midnight Tuesday ping their
patch. I'd like to have a sense of everything that is outstanding
sooner rather than later and wrap up any
On 11/27/13 04:48, Rainer Orth wrote:
Jakub Jelinek ja...@redhat.com writes:
On Fri, Nov 22, 2013 at 09:36:18AM -0700, Jeff Law wrote:
In fact, I would suggest that anyone with a pending patch from prior
to stage1 close that hasn't gotten feedback by midnight Tuesday ping
their patch. I'd
On 11/27/13 01:28, Alexander Ivchenko wrote:
Here is the patch series that had been posted in Sep that is aimed to
isolate the Android support from targets that actually don't have that
support (We discussed the need of it with Jakub here
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00185.html):
On 11/27/13 01:02, Markus Trippelsdorf wrote:
On 2013.11.20 at 15:43 +0100, Markus Trippelsdorf wrote:
On 2013.11.20 at 14:41 +0100, Paolo Bonzini wrote:
Note that you need to regenerate all users of libtool.m4. Please post a
patch _with_ the regeneration so that whoever applies it won't
On 11/27/13 00:36, Jakub Jelinek wrote:
AddressSanitizer use-after-return instrumentation:
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02070.html
+ HOST_WIDE_INT offset, sz;
+ sz = ASAN_RED_ZONE_SIZE;
+ sz = data.asan_vec[0] - prev_offset;
Seems to me like the first
On 11/27/13 00:36, Jakub Jelinek wrote:
Use libbacktrace for libsanitizer's symbolization (will need tweaking,
depending on next libsanitizer merge, whether the corresponding
sanitizer_common changes are upstreamed or not, and perhaps to compile
libbacktrace sources again with renamed function
On 11/27/13 00:36, Jakub Jelinek wrote:
Elemental function support (updated version of the earlier patch):
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03197.html
Richi OK's this earlier today. So it's good to go, right? I thought I
saw some follow-up items that Richi agreed could be done
On Wed, Nov 27, 2013 at 01:26:54PM -0700, Jeff Law wrote:
On 11/27/13 00:36, Jakub Jelinek wrote:
Elemental function support (updated version of the earlier patch):
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03197.html
Richi OK's this earlier today. So it's good to go, right? I
thought
On Wed, Nov 27, 2013 at 01:11:59PM -0700, Jeff Law wrote:
On 11/27/13 00:36, Jakub Jelinek wrote:
Use libbacktrace for libsanitizer's symbolization (will need tweaking,
depending on next libsanitizer merge, whether the corresponding
sanitizer_common changes are upstreamed or not, and perhaps
On Fri, Nov 22, 2013 at 09:36:18AM -0700, Jeff Law wrote:
In fact, I would suggest that anyone with a pending patch from prior
to stage1 close that hasn't gotten feedback by midnight Tuesday ping
their patch. I'd like to have a sense of everything that is
outstanding sooner rather than later
Hello all,
I'm pinging the patch
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00056.html
##
Index: gcc/toplev.c
===
--- gcc/toplev.c(revision 204671)
+++ gcc/toplev.c(working copy)
@@ -1968,11 +1968,13
On Mon, Nov 11, 2013 at 8:36 AM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
2013-11-11 Basile Starynkevitch bas...@starynkevitch.net
* toplev.c (toplev_main): Move PLUGIN_FINISH invocation before
diagnostic_finish.
OK.
Diego.
Can someone please review this patch?
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg02637.html
I would like to commit the already-approved -fstrict-volatile-bitfields
patch once we also have an approved fix for the infinite recursion
problem I discovered while testing a backport of the patch
Hi,
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01166.html
Thanks!
Paolo.
Hi,
pinging this patch of mine, sent beginning of September:
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01435.html
Just checked that it still applies cleanly and passes testing.
Thanks!
Paolo.
Ping.
OK,
thanks!
Honza
Thanks,
Martin
On Wed, Sep 11, 2013 at 03:02:02PM +0200, Martin Jambor wrote:
Hi,
edge_within_scc should really be a part of API accompanying
ipa_reduced_postorder just like ipa_get_nodes_in_cycle and so this
patch moves it to ipa-utils.c and gives it
Ping.
Thanks,
Martin
On Wed, Sep 11, 2013 at 03:02:02PM +0200, Martin Jambor wrote:
Hi,
edge_within_scc should really be a part of API accompanying
ipa_reduced_postorder just like ipa_get_nodes_in_cycle and so this
patch moves it to ipa-utils.c and gives it the ipa_ prefix.
On Fri, Jul 26, 2013 at 10:08 AM, Stefan Kristiansson
stefan.kristians...@saunalahti.fi wrote:
On Fri, Jul 26, 2013 at 08:51:41AM +0200, Uros Bizjak wrote:
Stefan, can you resubmit an updated patch (with proposed update from [1])?
I would really like to see this patch in the mainline.
** PING **
On July 01, Tobias Burnus wrote:
The following patches are pending to be reviewed:
* http://gcc.gnu.org/ml/fortran/2013-06/msg00142.html
* http://gcc.gnu.org/ml/fortran/2013-06/msg00132.html
* http://gcc.gnu.org/ml/fortran/2013-06/msg00137.html
It would help me tremendously if my
Hi Tobias,
** PING **
On July 01, Tobias Burnus wrote:
The following patches are pending to be reviewed:
* http://gcc.gnu.org/ml/fortran/2013-06/msg00142.html
OK if nobody else objects within 24 h.
* http://gcc.gnu.org/ml/fortran/2013-06/msg00132.html
This one is OK.
*
The following patches are pending to be reviewed:
* http://gcc.gnu.org/ml/fortran/2013-06/msg00142.html
* http://gcc.gnu.org/ml/fortran/2013-06/msg00141.html
* http://gcc.gnu.org/ml/fortran/2013-06/msg00132.html
* http://gcc.gnu.org/ml/fortran/2013-06/msg00137.html
*
Ping... These libgfortran changes are done the same way as libstdc++
so I hope they are OK.
Steve Ellcey
sell...@mips.com
From sell...@mips.com Tue Jun 4 12:49:55 2013
This patch allows me to build libgfortran for a cross-compiling toolchain
using newlib. Currently the checks done by
Steve Ellcey wrote:
Ping... These libgfortran changes are done the same way as libstdc++
so I hope they are OK.
OK - Thanks for the patch. (I was hoping that some configure maintainer
would do the deed.)
Tobias
From sell...@mips.com Tue Jun 4 12:49:55 2013
This patch allows me to build
On Fri, 26 Apr 2013, Han Shen(沈涵) wrote:
Hi, I'd like to ping the patch '-fstack-protector-strong':
- http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00945.html
Add a new option '-fstack-protector-strong' to protect only
stack-smashing-vulnerable functions.
I see this is now in?
Can you
Hi!
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00282.html
Reject -fsanitize=address -fsanitize=thread linking that won't ever work at
runtime.
Jakub
On 05/17/2013 12:49 AM, Jakub Jelinek wrote:
Hi!
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00282.html
Reject -fsanitize=address -fsanitize=thread linking that won't ever work at
runtime.
I thought Dodji already OK's this.If there's any concern about the
scope going outside Dodji's area,
On Wed, May 1, 2013 at 2:00 PM, Jeff Law l...@redhat.com wrote:
On 04/26/2013 10:45 AM, Han Shen(沈涵) wrote:
Hi, I'd like to ping the patch '-fstack-protector-strong':
- http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00945.html
Add a new option '-fstack-protector-strong' to protect only
On 05/07/2013 11:20 AM, Han Shen(沈涵) wrote:
How do you plan on handling Florian's retslot issue? Are you going to scan
the gimple looking for suitable calls? How do you avoid instrumentation in
the callee for that case?
I find myself wondering if you'd be better off scanning the gimple
Hi, I'd like to ping the patch '-fstack-protector-strong':
- http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00945.html
Add a new option '-fstack-protector-strong' to protect only
stack-smashing-vulnerable functions.
Thanks,
H.
Hi!
I'd like to ping 2 color diagnostics patches:
- http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00787.html
colorize filename using locus color even when printed
without :line:column
- http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00923.html
make -fdiagnostics-color=auto the default if
On Thu, Apr 25, 2013 at 5:22 PM, Jakub Jelinek ja...@redhat.com wrote:
Hi!
I'd like to ping 2 color diagnostics patches:
- http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00787.html
colorize filename using locus color even when printed
without :line:column
you should declare the variables
On Sun, Apr 21, 2013 at 10:54 PM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
Richard,
i pulled these two frags out of your comments because i wanted to get some
input from you on it while i addressed the other issues you raised.
+ enum SignOp {
+/* Many of the math functions
On 04/19/2013 09:31 AM, Richard Biener wrote:
+ number of elements of the vector that are in use. When LEN *
+ HOST_BITS_PER_WIDE_INT the precision, the value has been
+ compressed. The values of the elements of the vector greater than
+ LEN - 1. are all equal to the highest order bit
Richard Biener richard.guent...@gmail.com writes:
At the rtl level your idea does not work. rtl constants do not have a mode
or type.
Which is not true and does not matter. I tell you why. Quote:
It _is_ true, as long as you read rtl constants as rtl integer constants :-)
+#if
Richard Sandiford rdsandif...@googlemail.com wrote:
Richard Biener richard.guent...@gmail.com writes:
At the rtl level your idea does not work. rtl constants do not
have a mode
or type.
Which is not true and does not matter. I tell you why. Quote:
It _is_ true, as long as you read rtl
Richard Biener richard.guent...@gmail.com writes:
Richard Sandiford rdsandif...@googlemail.com wrote:
Richard Biener richard.guent...@gmail.com writes:
At the rtl level your idea does not work. rtl constants do not
have a mode
or type.
Which is not true and does not matter. I tell you why.
On 04/22/2013 08:20 AM, Richard Biener wrote:
That said, a lot of my pushback is because I feel a little lonesome in this
wide-int review and don't want to lone-some decide about that (generic)
interface part as well.
yeh, now sandiford is back from vacation so there are two of us to beat
on
Richard,
i pulled these two frags out of your comments because i wanted to get
some input from you on it while i addressed the other issues you raised.
+ enum SignOp {
+/* Many of the math functions produce different results depending
+ on if they are SIGNED or UNSIGNED. In
On Tue, Apr 16, 2013 at 10:07 PM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
Richard,
I made major changes to wide-int along the lines you suggested. Each of the
binary operations is now a template.
There are 5 possible implementations of those operations, one for each of
HWI, unsigned
Hi,
On 4/5/13 12:07 AM, Paolo Carlini wrote:
Hi,
in the audit trail of c++/56815 Manuel noticed that, inconsistently
with the documentation, a LangEnabledBy was missing for
-Wpointer-arith vs -Wpedantic.
Then I noticed that a clean up was possible in the actual pedwarn
calls, which, in
On Fri, Apr 5, 2013 at 2:34 PM, Kenneth Zadeck zad...@naturalbridge.com wrote:
Richard,
There has been something that has bothered me about you proposal for the
storage manager and i think i can now characterize that problem. Say i want
to compute the expression
(a + b) / c
converting
Richard,
There has been something that has bothered me about you proposal for the
storage manager and i think i can now characterize that problem. Say i
want to compute the expression
(a + b) / c
converting from tree values, using wide-int as the engine and then
storing the result in a
On Wed, Apr 3, 2013 at 6:16 PM, Kenneth Zadeck zad...@naturalbridge.com wrote:
On 04/03/2013 09:53 AM, Richard Biener wrote:
On Wed, Apr 3, 2013 at 2:05 PM, Kenneth Zadeck zad...@naturalbridge.com
wrote:
On 04/03/2013 05:17 AM, Richard Biener wrote:
In the end you will have a variable-size
On Tue, Apr 2, 2013 at 7:35 PM, Kenneth Zadeck zad...@naturalbridge.com wrote:
Yes, I agree that you win the challenge that it can be done.What you
have always failed to address is why anyone would want to do this. Or how
this would at all be desirable.But I completely agree that from
On Tue, Apr 2, 2013 at 9:08 PM, Kenneth Zadeck zad...@naturalbridge.com wrote:
this time for sure.
Almost ...
diff --git a/gcc/hwint.c b/gcc/hwint.c
index 330b42c..92d54a3 100644
--- a/gcc/hwint.c
+++ b/gcc/hwint.c
@@ -204,3 +204,35 @@ least_common_multiple (HOST_WIDE_INT a, HOST_WIDE_INT b)
{
yes, i had caught that when i merged it in with the patches that used
it, is it ok aside from that?
kenny
On 04/03/2013 05:32 AM, Richard Biener wrote:
On Tue, Apr 2, 2013 at 9:08 PM, Kenneth Zadeck zad...@naturalbridge.com wrote:
this time for sure.
Almost ...
diff --git a/gcc/hwint.c
On 04/03/2013 05:17 AM, Richard Biener wrote:
In the end you will have a variable-size storage in TREE_INT_CST thus
you will have at least to emit _code_ copying over meta-data and data
from the tree representation to the wide-int (similar for RTX CONST_DOUBLE/INT).
I'm objecting to the amount
On Wed, Apr 3, 2013 at 12:47 PM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
yes, i had caught that when i merged it in with the patches that used it, is
it ok aside from that?
Yes.
Thanks,
Richard.
kenny
On 04/03/2013 05:32 AM, Richard Biener wrote:
On Tue, Apr 2, 2013 at 9:08 PM,
On Wed, Apr 3, 2013 at 2:05 PM, Kenneth Zadeck zad...@naturalbridge.com wrote:
On 04/03/2013 05:17 AM, Richard Biener wrote:
In the end you will have a variable-size storage in TREE_INT_CST thus
you will have at least to emit _code_ copying over meta-data and data
from the tree
On 04/03/2013 09:53 AM, Richard Biener wrote:
On Wed, Apr 3, 2013 at 2:05 PM, Kenneth Zadeck zad...@naturalbridge.com wrote:
On 04/03/2013 05:17 AM, Richard Biener wrote:
In the end you will have a variable-size storage in TREE_INT_CST thus
you will have at least to emit _code_ copying over
committed as revision 197456
kenny
On 04/03/2013 08:05 AM, Richard Biener wrote:
On Wed, Apr 3, 2013 at 12:47 PM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
yes, i had caught that when i merged it in with the patches that used it, is
it ok aside from that?
Yes.
Thanks,
Richard.
kenny
On Sun, Mar 31, 2013 at 7:51 PM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
richard,
I was able to add everything except for the checking asserts.While I
think that this is a reasonable idea, it is difficult to add that to a
function that is defined in hwint.h because of circular
Richard,
did everything that you asked here. bootstrapped and regtested on
x86-64. ok to commit?
kenny
On 04/02/2013 05:38 AM, Richard Biener wrote:
On Sun, Mar 31, 2013 at 7:51 PM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
richard,
I was able to add everything except for the
On Tue, Apr 2, 2013 at 3:49 PM, Kenneth Zadeck zad...@naturalbridge.com wrote:
Richard,
did everything that you asked here. bootstrapped and regtested on x86-64.
ok to commit?
diff --git a/gcc/hwint.c b/gcc/hwint.c
index 330b42c..7e5b85c 100644
--- a/gcc/hwint.c
+++ b/gcc/hwint.c
@@ -204,3
On Wed, Feb 27, 2013 at 2:59 AM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
This patch contains a large number of the changes requested by Richi. It
does not contain any of the changes that he requested to abstract the
storage layer. That suggestion appears to be quite unworkable.
I of
Yes, I agree that you win the challenge that it can be done.What you
have always failed to address is why anyone would want to do this. Or
how this would at all be desirable.But I completely agree that from
a purely abstract point of view you can add a storage model.
Now here is why
this time for sure.
kenny
On 04/02/2013 10:54 AM, Richard Biener wrote:
On Tue, Apr 2, 2013 at 3:49 PM, Kenneth Zadeck zad...@naturalbridge.com wrote:
Richard,
did everything that you asked here. bootstrapped and regtested on x86-64.
ok to commit?
diff --git a/gcc/hwint.c b/gcc/hwint.c
richard,
I was able to add everything except for the checking asserts.While I
think that this is a reasonable idea, it is difficult to add that to a
function that is defined in hwint.h because of circular includes. I
could move this another file (though this appears to be the logical
committed as revision 197200.
kenny
On 03/27/2013 11:07 AM, Richard Biener wrote:
On Wed, Mar 27, 2013 at 3:23 PM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
On 03/27/2013 10:18 AM, Richard Biener wrote:
On Wed, Feb 27, 2013 at 1:27 AM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
richard,
adding the gcc_checking_assert is going to require that i include
system.h in hwint.h which seems to cause a loop. while in principle, i
agree with the assert, this is going to be a mess.
kenny
On 03/27/2013 10:13 AM, Richard Biener wrote:
On Wed, Feb 27, 2013 at 1:22 AM,
On Wed, Feb 27, 2013 at 1:22 AM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
Here is the first of my wide int patches with joseph's comments and the
patch rot removed.
I would like to get these pre approved for the next stage 1.
+ int shift = HOST_BITS_PER_WIDE_INT - (prec
On Wed, Feb 27, 2013 at 1:27 AM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
Here is the second of my wide int patches with the patch rot removed.
I would like to get these pre approved for the next stage 1.
On 10/05/2012 06:48 PM, Kenneth Zadeck wrote:
This patch adds machinery to
On 03/27/2013 10:18 AM, Richard Biener wrote:
On Wed, Feb 27, 2013 at 1:27 AM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
Here is the second of my wide int patches with the patch rot removed.
I would like to get these pre approved for the next stage 1.
On 10/05/2012 06:48 PM, Kenneth
On Wed, Feb 27, 2013 at 2:59 AM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
This patch contains a large number of the changes requested by Richi. It
does not contain any of the changes that he requested to abstract the
storage layer. That suggestion appears to be quite unworkable.
I
On Wed, Mar 27, 2013 at 3:23 PM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
On 03/27/2013 10:18 AM, Richard Biener wrote:
On Wed, Feb 27, 2013 at 1:27 AM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
Here is the second of my wide int patches with the patch rot removed.
I would like
Hi!
Thanks for all the recent reviews of memory leak plugging patches,
there are 4 still unreviewed from last week though.
- sched-deps leak fix:
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01197.html
- LRA leak fix:
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01239.html
- libcpp leak fix:
On Tue, 5 Mar 2013, Jakub Jelinek wrote:
Hi!
Thanks for all the recent reviews of memory leak plugging patches,
there are 4 still unreviewed from last week though.
- sched-deps leak fix:
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01197.html
- LRA leak fix:
On Tue, Mar 05, 2013 at 02:26:03PM +0100, Richard Biener wrote:
On Tue, 5 Mar 2013, Jakub Jelinek wrote:
Thanks for all the recent reviews of memory leak plugging patches,
there are 4 still unreviewed from last week though.
- sched-deps leak fix:
On Tue, 5 Mar 2013, Jakub Jelinek wrote:
On Tue, Mar 05, 2013 at 02:26:03PM +0100, Richard Biener wrote:
On Tue, 5 Mar 2013, Jakub Jelinek wrote:
Thanks for all the recent reviews of memory leak plugging patches,
there are 4 still unreviewed from last week though.
- sched-deps
On 03/05/2013 08:12 AM, Jakub Jelinek wrote:
Hi!
Thanks for all the recent reviews of memory leak plugging patches,
there are 4 still unreviewed from last week though.
- sched-deps leak fix:
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01197.html
This patch is ok. Thanks for working on
On 03/05/2013 08:12 AM, Jakub Jelinek wrote:
Hi!
Thanks for all the recent reviews of memory leak plugging patches,
there are 4 still unreviewed from last week though.
LRA leak fix:
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01239.html
This patch is ok too.
701 - 800 of 952 matches
Mail list logo
