On Thu, Oct 24, 2013 at 10:35 PM, Jeff Law wrote:
> On 10/24/13 07:40, Richard Biener wrote:
we were supposed to remove mudflap for 4.9, no?
>>> Really? I guess it hasn't been removed yet since the include is still
>>> there? who is doing that?
>>
>>
>> Yeah, nobody has done i
As discovered by Richard B. under PR rtl-optimization/58831, the peephole2
pass has been context-sensitive for a long time when scratch registers are
needed, in the sense that the behaviour of the pass for a given function is
dependent on what happened for the previously optimized function.
Obv
Committed to dmalcolm/jit branch:
This is a work-in-progress, and currently doesn't achieve very deep
coverage of the code, due to mismatching types.
gcc/testsuite/
* jit.dg/harness.h (main): Wrap with #ifndef TEST_PROVIDES_MAIN
* jit.dg/test-fuzzer.c: New.
---
gcc/testsuite/Chan
On 10/24/13 14:56, Steven Bosscher wrote:
Bootstrapped and regression tested on x86_64-unknown-linux-gnu. Obviously
the mudflap specific tests were deleted and not run and were manually
ignored when comparing testsuite runs.
OK for the trunk?
The flags in c.opt should be retained as NOPs. Or
This is a very old bug in the alias.c machinery, which is exposed during
the sched2 pass. We have in .split4:
(insn 23 22 24 4 (set (mem/f:DI (reg/v/f:DI 4 si [orig:90 p2 ] [90]) [3
*p2_9(D)+0 S8 A64])
(symbol_ref:DI ("d") )) pr58831-1.c:12 85
{*movdi_internal}
(expr_list:REG_DEAD
On Thu, Oct 24, 2013 at 03:22:42PM -0600, Jeff Law wrote:
> On 10/24/13 14:56, Steven Bosscher wrote:
> >>Bootstrapped and regression tested on x86_64-unknown-linux-gnu. Obviously
> >>the mudflap specific tests were deleted and not run and were manually
> >>ignored when comparing testsuite runs.
>
On Mon, 21 Oct 2013, Mike Stump wrote:
> On Oct 21, 2013, at 3:28 AM, Vidya Praveen wrote:
> > Tests gcc.dg/20050922-1.c and gcc.dg/20050922-2.c includes stdlib.h. This
> > can
> > be a issue especially since they define uint32_t.
>
> > OK for 4.7, 4.8?
>
> For release branches, you'd need to
Hi Tobias,
On Thu, 24 Oct 2013, Tobias Burnus wrote:
Any comments? Or is the patch OK?
thanks for doing this.
Index: htdocs/gcc-4.9/changes.html
===
+With the new http://gcc.gnu.org/onlinedocs/gcc/Loop_002dSpecific-Pragmas.ht
On 10/24/13 15:53, Marek Polacek wrote:
On Thu, Oct 24, 2013 at 03:22:42PM -0600, Jeff Law wrote:
On 10/24/13 14:56, Steven Bosscher wrote:
Bootstrapped and regression tested on x86_64-unknown-linux-gnu. Obviously
the mudflap specific tests were deleted and not run and were manually
ignored whe
On 10/24/2013 05:02 AM, Richard Sandiford wrote:
> Do we actually need to do a conversion here at all? It looks like the
> modes of "expected" and "desired" should already match "mem", so we could
> just use create_input_operand.
This works. I've committed the following to mainline, and will
tes
On Oct 24, 2013, at 2:26 AM, Vidya Praveen wrote:
> On Mon, Oct 21, 2013 at 06:40:28PM +0100, Mike Stump wrote:
>> On Oct 21, 2013, at 3:28 AM, Vidya Praveen wrote:
>>> Tests gcc.dg/20050922-1.c and gcc.dg/20050922-2.c includes stdlib.h. This
>>> can
>>> be a issue especially since they define u
On Wed, Oct 23, 2013 at 11:18 PM, Jakub Jelinek wrote:
> On Wed, Oct 23, 2013 at 09:40:21PM -0700, Cong Hou wrote:
>> On Wed, Oct 23, 2013 at 8:52 AM, Joseph S. Myers
>> wrote:
>> > On Tue, 22 Oct 2013, Cong Hou wrote:
>> >
>> >> For abs(char/short), type conversions are needed as the current abs
I stumbled on a case like this:
If the multipliers allowed for addressing modes are dependent on actual
mode, in some cases compiler
refuses to recognize address as legitimate.
It boils down to this place in expr.c where address_mode is incorrectly
used instead of actual mode.
I rebootstraped and
Hi Tobias,
On Thu, 24 Oct 2013, Tobias Burnus wrote:
the attached patch updates the gomp project patch.
(Besides adding an item for the OpenMP 4.0 merge, I removed the "95" from
"Fortran 95" as Fortran is backward compatible and gfortran is effectively a
Fortran 66/77/90/95/2003/2008 compiler [
I noticed that some of the macros in tree.h that act on trees have
parameters named "CODE", rather "NODE", which is confusing when in the
presence of other macros that act on enum tree_code values.
The attached patch renames such params for macros that I believe act on
trees (mostly because they g
On Oct 24, 2013, at 2:05 AM, Jan-Benedict Glaw wrote:
> - enum raw_str_phase { RAW_STR_PREFIX, RAW_STR, RAW_STR_SUFFIX };
> - raw_str_phase phase = RAW_STR_PREFIX;
> + enum raw_str_phase { RAW_STR_PREFIX, RAW_STR, RAW_STR_SUFFIX } phase =
> RAW_STR_PREFIX;
Since no one else chimed in… seems
On Thu, Oct 24, 2013 at 6:22 PM, Mike Stump wrote:
> On Oct 24, 2013, at 2:05 AM, Jan-Benedict Glaw wrote:
>> - enum raw_str_phase { RAW_STR_PREFIX, RAW_STR, RAW_STR_SUFFIX };
>> - raw_str_phase phase = RAW_STR_PREFIX;
>> + enum raw_str_phase { RAW_STR_PREFIX, RAW_STR, RAW_STR_SUFFIX } phase =
On Oct 24, 2013, at 6:25 PM, Andrew Pinski wrote:
>> enum raw_str_phase phase = RAW_STR_PREFIX;
>
> This is a good work around but please add a comment of why this is
> needed (to work around a bug in XLC++).
Oh, curious, I was assuming that file was compiled by the C compiler… not as
obvious
On Thu, 24 Oct 2013, Hans-Peter Nilsson wrote:
> On Mon, 21 Oct 2013, Mike Stump wrote:
>
> > On Oct 21, 2013, at 3:28 AM, Vidya Praveen wrote:
> > > Tests gcc.dg/20050922-1.c and gcc.dg/20050922-2.c includes stdlib.h. This
> > > can
> > > be a issue especially since they define uint32_t.
> >
> >
Oleg Endo wrote:
> The attached patch fixes volatile mem stores on SH so that they won't
> result in redundant sign/zero extensions and will utilize available
> addressing modes. This is similar to what has been done to fix memory
> loads in http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01315.html
Yup, my registers are smaller than Pmode.
This is what I ended up with...
Some notes: I lie to gcc and tell it that $fp (reg 22) is two bytes
when it's really one. None of the register classes have reg 23 (used
for the upper half of $fp) in them. Reg 23 is also listed as being
two bytes, to ke
On 10/24/13 15:28, Eric Botcazou wrote:
This is a very old bug in the alias.c machinery, which is exposed during
the sched2 pass. We have in .split4:
(insn 23 22 24 4 (set (mem/f:DI (reg/v/f:DI 4 si [orig:90 p2 ] [90]) [3
*p2_9(D)+0 S8 A64])
(symbol_ref:DI ("d") )) pr58831-1.c:12 85
{
On 10/24/13 18:20, Igor Shevlyakov wrote:
I stumbled on a case like this:
If the multipliers allowed for addressing modes are dependent on actual
mode, in some cases compiler
refuses to recognize address as legitimate.
It boils down to this place in expr.c where address_mode is incorrectly
used i
On 10/24/13 15:10, Eric Botcazou wrote:
As discovered by Richard B. under PR rtl-optimization/58831, the peephole2
pass has been context-sensitive for a long time when scratch registers are
needed, in the sense that the behaviour of the pass for a given function is
dependent on what happened for
On 10/24/13 02:24, Ilya Enkovich wrote:
2013/10/24 Jeff Law :
On 10/21/13 08:20, Ilya Enkovich wrote:
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 8d220f3..79bd0f9 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
+@deftypefn {Target Hook} rtx TARGET_LOAD_BOUNDS_FOR_ARG (rtx @var{slot
Hello,
I noticed that in some cases we were failing to find aliasing information
because we were only looking at an SSA_NAME variable, missing the fact
that it was really an ADDR_EXPR. The attached patch passes
bootstrap+testsuite, does it make sense? (I am a bit afraid of losing some
type in
On 10/24/13 02:36, Ilya Enkovich wrote:
2013/10/24 Richard Henderson :
On 10/23/2013 02:41 PM, Jeff Law wrote:
Out of curiosity, did you consider and/or discuss with Richard whether or not
to make these target-dependent or target-independent builtins? I realize it's
a bit problematic with Rich
On 10/24/13 23:23, Marc Glisse wrote:
Hello,
I noticed that in some cases we were failing to find aliasing
information because we were only looking at an SSA_NAME variable,
missing the fact that it was really an ADDR_EXPR. The attached patch
passes bootstrap+testsuite, does it make sense? (I am
On 10/21/13 05:59, Ilya Enkovich wrote:
Hi,
This patch adds attributes 'bnd_variable_size' and 'bnd_legacy' used by
Pointers Checker.
Bootstrapped and tested on linux-x86_64.
Thanks,
Ilya
--
gcc/
2013-10-21 Ilya Enkovich
* c-family/c-common.c (handle_bnd_variable_size_attribute)
On 10/21/13 05:49, Ilya Enkovich wrote:
Hi,
This patch introduces built-in functions used by Pointers Checker and flag to
enable Pointers Checker. Builtins available for user are expanded in
expand_builtin. All other builtins are not allowed in expand until generic
version of Pointers Cheker
On 10/23/13 21:00, David Malcolm wrote:
I went through the various requirements listed in the doc and
investigated what happens when they're violated. Some lead to immediate
build failure in gengtype (which is relatively sane), but some lead to
silent lack of field-traversal. The details:
Yea,
On 10/21/13 06:10, Ilya Enkovich wrote:
Hi,
This patch introduces two new contructor types supported by
cgraph_build_static_cdtor.
'B' type is used to initialize static objects (bounds) created by Pointers
Checker. The difference of this type from the regular constructor is that 'B'
construc
Gerald Pfeifer wrote:
On Thu, 24 Oct 2013, Tobias Burnus wrote:
Any comments? Or is the patch OK?
thanks for doing this.
Thanks for looking at the patch. However, the patch has a link problem.
The documentation is at
http://gcc.gnu.org/onlinedocs/gcc/Loop_002dSpecific-Pragmas.html
That'
On Thu, 24 Oct 2013, Jeff Law wrote:
On 10/24/13 23:23, Marc Glisse wrote:
Hello,
I noticed that in some cases we were failing to find aliasing
information because we were only looking at an SSA_NAME variable,
missing the fact that it was really an ADDR_EXPR. The attached patch
passes bootstra
On Thu, Oct 24, 2013 at 11:14:42PM -0600, Jeff Law wrote:
> On 10/24/13 15:10, Eric Botcazou wrote:
> >As discovered by Richard B. under PR rtl-optimization/58831, the peephole2
> >pass has been context-sensitive for a long time when scratch registers are
> >needed, in the sense that the behaviour
Jason Merrill wrote:
On 10/10/2013 04:46 AM, Tobias Burnus wrote:
I considered to add the annotation also to C++11's range-based loops,
but as those are unlikely to vectorize, I didn't do so.
I would think that a range-based loop over an array should vectorize
nicely:
int ar[8];
for (int i: a
Hi Richard,
>> Did you just propose:
>>
>> --- stor-layout.c.orig 2013-10-22 10:46:49.233261818 +0200
>> +++ stor-layout.c 2013-10-24 14:54:00.425259062 +0200
>> @@ -471,27 +471,7 @@
>> static enum machine_mode
>> mode_for_array (tree elem_type, tree size)
>> {
>> - tree elem_size;
>> - unsigned
On Fri, Oct 25, 2013 at 08:22:22AM +0200, Tobias Burnus wrote:
> Jason Merrill wrote:
> >On 10/10/2013 04:46 AM, Tobias Burnus wrote:
> >>I considered to add the annotation also to C++11's range-based loops,
> >>but as those are unlikely to vectorize, I didn't do so.
> >
> >I would think that a ran
Hi Kirill,
with the current trunk (newst "git" mirror version), bootstrapping fails
here with the following error. Did you forget to commit one file?
g++ -c -g -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-
101 - 139 of 139 matches
Mail list logo
