On Tue, Aug 12, 2014 at 08:17:15AM +0200, Dodji Seketeli wrote:
> Marek Polacek a écrit:
>
>
> > diff --git gcc/testsuite/gcc.dg/concat.c gcc/testsuite/gcc.dg/concat.c
> > index 0b9d6f6..e3bfd46 100644
> > --- gcc/testsuite/gcc.dg/concat.c
> > +++ gcc/testsuite/gcc.dg/concat.c
> > @@ -1,6 +1,7 @
On Tue, Aug 12, 2014 at 7:23 AM, Gopalasubramanian, Ganesh
wrote:
>> > +2014-06-10 Ganesh Gopalasubramanian
>> > +
>> > +
>> > + * config/i386/i386.c (ix86_expand_sse2_mulvxdi3): Issue
>> > +instructions "vpmuludq" and "vpaddq" instead of "vpmacsdql" for
>> > +handling 32-bit multiplicatio
Marek Polacek a écrit:
> diff --git gcc/testsuite/gcc.dg/concat.c gcc/testsuite/gcc.dg/concat.c
> index 0b9d6f6..e3bfd46 100644
> --- gcc/testsuite/gcc.dg/concat.c
> +++ gcc/testsuite/gcc.dg/concat.c
> @@ -1,6 +1,7 @@
> /* Copyright (C) 2001 Free Software Foundation, Inc. */
>
> /* { dg-do
> Checking for this specific AST may cause failures with future versions of
> isl that choose a different schedule. Could you write a regular expression
> that checks that there is no if-condition contained in a for loop? I think
> this best models the issue that was addressed in the original bug r
On 11 August 2014 19:14, Ramana Radhakrishnan wrote:
> On Mon, Aug 11, 2014 at 3:35 AM, Zhenqiang Chen
> wrote:
>> On 8 August 2014 23:22, Ramana Radhakrishnan
>> wrote:
>>> On Tue, Aug 5, 2014 at 10:31 AM, Zhenqiang Chen
>>> wrote:
Hi,
For some large constants, ARM will split t
Hi Uros!
> > +2014-06-10 Ganesh Gopalasubramanian
> > +
> > +
> > + * config/i386/i386.c (ix86_expand_sse2_mulvxdi3): Issue
> > +instructions "vpmuludq" and "vpaddq" instead of "vpmacsdql" for
> > +handling 32-bit multiplication.
> >
> OK for mainline and release branches.
I would like
On 08/11/14 14:02, Jason Merrill wrote:
A customer was recently complaining about G++ rejecting code that tries to pass
a type with a non-trivial copy constructor through ..., which is undefined in
C++98 and conditionally-supported in C++11. In GCC 3.1 and below we gave a
warning and then did a
On 8/12/14 7:38, Mike Stump wrote:
> On Aug 11, 2014, at 2:27 PM, Chen Gang wrote:
>> Welcome additional disccusions or completions, and if no any additional
>> reply within 1 week, I shall send patch v2 for it (still use sprintf).
>
> So, my take is it is easier for a maintainer to re-review i
On 11/08/14 18:03, Richard Biener wrote:
> On Sat, Aug 9, 2014 at 2:33 PM, Kugan
> wrote:
>> Hi,
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52904
>>
>> Tescase was generating warning: assuming signed overflow does not occur
>> when simplifying conditional to constant [-Wstrict-overflow]
Ping 2, and pasted my observation about this ICE, and may someone can help?
The main cause for the ICE is in the function symtab_get_node:
gcc_checking_assert (TREE_CODE (decl) == FUNCTION_DECL
|| (TREE_CODE (decl) == VAR_DECL
&& (TREE_STATIC (d
On Aug 11, 2014, at 3:01 PM, Janis Johnson wrote:
> The check for effective target arm_v8_neon_ok passes even if __ARM_ARCH
> is not 8 or greater, but then some tests fail because intrinsic functions
> used in the test have not been declared. This patch requires that
> __ARM_ARCH be 8 or greater.
According to section 2.6.1 in the openacc spec, fortran loop variables
should be implicitly private like in openmp. This patch does just so.
Also, while working on this patch, I noticed that I made the check for
variables appearing in multiple openacc clauses too strict. A private
variable may also
[ dup, sorry ]
On Aug 11, 2014, at 2:58 PM, Janis Johnson wrote:
> Two tests in gcc.target/arm add options that conflict with thumb1
> multilib flags; skip them. Tested with arm-none-linux-gnu for mainline
> and 4.9 for a variety of multilib flags.
>
> OK for mainline and 4.9 branch?
So, my ta
On Aug 11, 2014, at 3:00 PM, Janis Johnson wrote:
> Test gcc.dg/pr59418.c adds ARM-specific options for an ARM target, but
> those options conflict with flags for a thumb1 multilib. Don't add
> the extra ARM flags for a thumb1 multilib. Tested with arm-none-linux-gnu
> for mainline and 4.9 with
On Aug 11, 2014, at 2:58 PM, Janis Johnson wrote:
> Two tests in gcc.target/arm add options that conflict with thumb1
> multilib flags; skip them. Tested with arm-none-linux-gnu for mainline
> and 4.9 for a variety of multilib flags.
>
> OK for mainline and 4.9 branch?
So, my take is you can se
On Aug 11, 2014, at 2:59 PM, Janis Johnson wrote:
> Test gcc.target/arm/neon-vext-execute.c checks that the compiler can
> generate neon instructions, but it should also check that the test will
> be run using hardware that supports neon, which this patch adds.
> Tested with arm-none-linux-gnu for
On Aug 11, 2014, at 2:27 PM, Chen Gang wrote:
> Welcome additional disccusions or completions, and if no any additional
> reply within 1 week, I shall send patch v2 for it (still use sprintf).
So, my take is it is easier for a maintainer to re-review if you do it without
additional delay. I’d r
On Aug 11, 2014, at 2:02 PM, Jason Merrill wrote:
>
> On considering the request, it occurred to me that we could handle variadic
> arguments of non-trivial types the same way we handle normal value arguments
> of such types: pass by invisible reference. So this patch implements that.
> Sinc
Add pattern: abs (abs (x)) -> abs (x)
* match.pd: Add new pattern.
[gcc/testsuite/gcc.dg/tree-ssa]
* match.c: New test-case.
Thanks,
Prathamesh
Index: gcc/match.pd
===
--- gcc/match.pd (revision 213814)
+++ gcc/match.pd (working cop
Sorry, it is a typo :(
Patch v2:
--
2014-08-11 Yi Yang
gcc:
* bb-reorder.c (pass_partition_blocks::gate): Replace check.
* c-family/c-common.c (handle_section_attribute): Remove
user_defined_section_attribute
* final.c (rest_of_handle_final): ditto
* toplev.c (user_defined_se
The check for effective target arm_v8_neon_ok passes even if __ARM_ARCH
is not 8 or greater, but then some tests fail because intrinsic functions
used in the test have not been declared. This patch requires that
__ARM_ARCH be 8 or greater. Tested for arm-none-linux-gnu for mainline
and 4.9 with a
Test gcc.dg/pr59418.c adds ARM-specific options for an ARM target, but
those options conflict with flags for a thumb1 multilib. Don't add
the extra ARM flags for a thumb1 multilib. Tested with arm-none-linux-gnu
for mainline and 4.9 with a variety of multilib flags.
OK for mainline and the 4.9 b
Test gcc.target/arm/neon-vext-execute.c checks that the compiler can
generate neon instructions, but it should also check that the test will
be run using hardware that supports neon, which this patch adds.
Tested with arm-none-linux-gnu for mainline and 4.9 with a variety of
multilib flags.
OK for
Two tests in gcc.target/arm add options that conflict with thumb1
multilib flags; skip them. Tested with arm-none-linux-gnu for mainline
and 4.9 for a variety of multilib flags.
OK for mainline and 4.9 branch?
Janis
2014-08-11 Janis Johnson
* gcc.target/arm/pr48784.c: Skip for thumb1
Thanks. This is committed.
I leaned toward obvious as well but figured I already had two
patches that needed a review, so why not. :)
On 8/11/2014 3:05 PM, Arnaud Charlet wrote:
>> This patch is needed to make Ada compile for *-*-rtems*
>> on GCC 4.8, 4.9, and the head. Is is ok to commit?
> Yes.
On 08/12/2014 04:25 AM, Joseph S. Myers wrote:
> On Sun, 10 Aug 2014, Chen Gang wrote:
>
>> For "[%d]" in sprintf(), theoretically, the maximize size is 14 -- for
>> 0x8000, it is sizeof("[-2147483648]"). Normally, it may not cause
>> real world bug, but if another issues occur, it may lead th
On 8/11/2014 3:09 PM, Arnaud Charlet wrote:
>>> This patch is needed to make Ada compile for *-*-rtems*
>>> on GCC 4.8, 4.9, and the head. Is is ok to commit?
>> OK.
> Actually, these includes should go in gsocket.h, as done on other targets,
> which also answers your previous question.
Where do y
A customer was recently complaining about G++ rejecting code that tries
to pass a type with a non-trivial copy constructor through ..., which is
undefined in C++98 and conditionally-supported in C++11. In GCC 3.1 and
below we gave a warning and then did a bitwise copy. From GCC 3.2 to
4.4 we
On Mon, Aug 11, 2014 at 1:41 PM, Yi Yang wrote:
> Replace checking user_defined_section_attribute with directly checking
> DECL_SECTION_NAME. The former does not work in the presence of IPA.
>
> See also: discussion on the same patch in Google branch:
> https://gcc.gnu.org/ml/gcc-patches/2014-08/m
I ported this to trunk.
Shall I commit this patch to the Google 4_8/4_9 branches first?
On Mon, Aug 11, 2014 at 12:46 PM, Teresa Johnson wrote:
> Ok, thanks. This seems reasonable. Can you send the patch to trunk as well?
> Teresa
>
> On Mon, Aug 11, 2014 at 12:35 PM, Yi Yang wrote:
>> Patch v2
Replace checking user_defined_section_attribute with directly checking
DECL_SECTION_NAME. The former does not work in the presence of IPA.
See also: discussion on the same patch in Google branch:
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00749.html
--
2014-08-11 Yi Yang
gcc:
* bb-reo
On Mon, Aug 11, 2014 at 08:19:52PM +, Joseph S. Myers wrote:
> On Sat, 9 Aug 2014, Marek Polacek wrote:
>
> > + /* Maybe we want to issue the C90/C99 compat warning, which is more
> > + specific than -pedantic. */
> > + if (warn_c90_c99_compat > 0)
> > {
> >diagnostic_set_i
On Sun, 10 Aug 2014, Chen Gang wrote:
> For "[%d]" in sprintf(), theoretically, the maximize size is 14 -- for
> 0x8000, it is sizeof("[-2147483648]"). Normally, it may not cause
> real world bug, but if another issues occur, it may lead things worse.
Negative values certainly don't make sens
On 08/10/2014 04:22 PM, Chen Gang wrote:
>
> I guess, I find the root cause:
>
Although I say "I guess", in fact, I already had related proofs for it.
- When configure "libjava/classpath", "--disable-core-jni" is passed
as parameter explicitly (can check "x86_64-.../libjava/classpatch/
c
On Sat, 9 Aug 2014, Marek Polacek wrote:
> + /* Maybe we want to issue the C90/C99 compat warning, which is more
> + specific than -pedantic. */
> + if (warn_c90_c99_compat > 0)
> {
>diagnostic_set_info (&diagnostic, gmsgid, &ap, location, DK_WARNING);
That seems wrong; it mea
> > This patch is needed to make Ada compile for *-*-rtems*
> > on GCC 4.8, 4.9, and the head. Is is ok to commit?
>
> OK.
Actually, these includes should go in gsocket.h, as done on other targets,
which also answers your previous question.
Can you please repost an updated patch for review?
Arn
> This patch is needed to make Ada compile for *-*-rtems*
> on GCC 4.8, 4.9, and the head. Is is ok to commit?
OK.
> 2014-08-11 Joel Sherrill
>
> * socket.c: Add conditionals for RTEMS. Add include of
> and so correct prototype of gethostbyname_r() is used.
> This patch is needed to make Ada compile for *-*-rtems*
> on GCC 4.8, 4.9, and the head. Is is ok to commit?
Yes. This one even falls under the obvious category IMO.
> 2014-08-11 Joel Sherrill
>
> * s-osinte-rtems.adb: Correct formatting of line in license block.
On 11-Aug-14, at 3:24 PM, John David Anglin wrote:
Tested on hppa-unknown-linux-gnu, hppa2.0w-hp-hpux11.11 and hppa64-
hp-hpux11.11 with no observed regressions.
Committed to trunk, 4.9 and 4.8.
There is a problem...
Patch reverted.
Dave
--
John David Anglin dave.ang...@bell.net
This is the patch I checked in as subversion id 213834.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/constraints.md
Ok, thanks. This seems reasonable. Can you send the patch to trunk as well?
Teresa
On Mon, Aug 11, 2014 at 12:35 PM, Yi Yang wrote:
> Patch v2
>
> ..
>
> diff --git gcc/bb-reorder.c gcc/bb-reorder.c
> index fa6f62f..a1b3e65 100644
> --- gcc/bb-reorder.c
> +++ gcc/bb-reorder.c
> @@ -95,7 +95,6 @@
Patch v2
..
diff --git gcc/bb-reorder.c gcc/bb-reorder.c
index fa6f62f..a1b3e65 100644
--- gcc/bb-reorder.c
+++ gcc/bb-reorder.c
@@ -95,7 +95,6 @@
#include "expr.h"
#include "params.h"
#include "diagnostic-core.h"
-#include "toplev.h" /* user_defined_section_attribute */
#include "tree-pass.h
The Go language was changed slightly so that comma-ok assignments now
return the ok value as an untyped boolean value rather than as the named
type "bool". The effect of this is that programs can use an existing
variable of a boolean type that is not actually "bool". This patch by
Chris Manghane
With a large function, the 'b' branch may not be able to reach its
target without a long branch stub. Gas doesn't provide
a long branch stub for a branch without a link register (i.e., it
considers branches with link registers calls). This patch
changes pa_asm_output_mi_thunk() to use a bl br
Thanks for pointing out this!
It seems to me that this user_defined_section_attribute variable is
useless now and should be removed. It is intended to work in this way:
for each function {
parse into tree (setting user_defined_section_attribute)
do tree passes
do RTL passes (using user_d
On Mon, Aug 11, 2014 at 3:06 PM, Kirill Yukhin wrote:
> On 11 Aug 13:51, Jakub Jelinek wrote:
>> On Mon, Aug 11, 2014 at 03:47:07PM +0400, Kirill Yukhin wrote:
>> > @@ -9020,7 +9025,8 @@ standard_sse_constant_opcode (rtx insn, rtx x)
>> > }
>> >
>> > case 2:
>> > - if (get_attr_mode
On Aug 11, 2014, at 10:57 AM, Jakub Jelinek wrote:
>
>> + if (timeout != -1)
>> +{
>> + signal (SIGALRM, alarm_handler);
>> + alarm (timeout);
>> +}
>
> Not sure how much portable signal/alarm is. So probably should be guarded
> by the existence of signal.h, SIGALRM being def
OK with a comment explaining how we can get there.
Jason
On 8/11/2014 1:15 PM, Mike Stump wrote:
> On Aug 11, 2014, at 8:08 AM, Joel Sherrill wrote:
>> +#if defined(__rtems__)
>> +#include
>> +/* Required, for read(), write(), and close() */
>> +#endif
> Strikes me as exceptionally odd. Should be done unconditionally, and any
> system that doesn’t l
On Aug 11, 2014, at 8:08 AM, Joel Sherrill wrote:
> +#if defined(__rtems__)
> +#include
> +/* Required, for read(), write(), and close() */
> +#endif
Strikes me as exceptionally odd. Should be done unconditionally, and any
system that doesn’t like that should be the odd ball.
Hi,
while working on a patchlet for the simple c++/54377 I noticed a latent
issue, which goes normally unnoticed because template/typename17.c uses
the catch all dg-error "". The issue is that, whereas for C++98 we give
a sensible error message, for C++11 only the late "last resort" check in
Committed and pushed to branch dmalcolm/jit:
gcc/testsuite/
* jit.dg/test-threads.c: New test case, running all of the
individual test cases in separate threads.
* jit.dg/test-combination.c: Move inclusion of the various
individual testcases into...
* jit.dg
On Mon, Aug 11, 2014 at 05:04:20PM +0100, Gary Benson wrote:
> + case 's':
> + seed = atoi (optarg);
> + break;
> +
> + case 't':
> + timeout = atoi (optarg);
> + break;
> +
> + case 'm':
> + maxcount = atoi (optarg);
> + break;
> + }
> +}
> +
On Aug 11, 2014, at 2:06 AM, Richard Earnshaw wrote:
> Not quite, read the subject line again.
Doh. I did miss that entirely. The solutions I gave were for other cases than
the case at hand.
> I'm not sure what the correct change to the testsuite is here.
The below is close, let me refine it
Fixing some bugs substituting through constraints. In particular, when
diagnosing an error, make sure that we use the right arguments.
There was also a bug caused by substitution through a decltype-type.
In particular, when folding a non-dependent expression containing a
decltype-type, the inner t
On Mon, Aug 11, 2014 at 11:10:59AM +0200, Tom de Vries wrote:
> +use File::Temp;
> +use File::Copy qw(cp mv);
> + # Copy the permissions to the temp file (in perl 2.15 and later).
> + cp $diff, $tmp or die "Could not copy patch file to temp file: $!";
That's File::Copy 2.15, not Perl 2.15
On 08/01/2014 07:59 AM, Marek Polacek wrote:
Thanks for taking this on, sorry it's taken so long to respond.
+convert_like_real (location_t loc, conversion *convs, tree expr, tree fn,
+ int argnum, int inner, bool issue_conversion_warnings,
bool c_cast_p, tsu
On Fri, Aug 08, 2014 at 03:31:48PM -0400, David Edelsohn wrote:
> Okay.
>
> Note that you or Carrot will have to be careful about the merge of
> movdi_internal64 as both of your patches affect that pattern.
Carrot has checked in his patch, and I will adapt my patch (and replace the
constraint wm
Now that the -Wc90-c99-compat warning is in, the next step was to implement
the -Wc99-c11-compat warning, which is what this patch is about.
Luckily the implementation is quite straightforward, since there are
no specialized options similar to -Wlong-long that should be taken into
account - thus no
Looks good.
-Andi
David Malcolm wrote:
> On Mon, 2014-08-11 at 08:06 -0700, Andi Kleen wrote:
> > Gary Benson writes:
> > > srand(time(NULL));
> >
> > That's really bad, can never be reproduced. If you use a random
> > seed like this you need to at least print it.
>
> How about taking the random seed and the num
On Mon, 2014-08-11 at 08:06 -0700, Andi Kleen wrote:
> Gary Benson writes:
>
> >srand(time(NULL));
>
> That's really bad, can never be reproduced. If you use a random seed
> like this you need to at least print it.
How about taking the random seed and the number of iterations as
command-line a
This patch is needed to make Ada compile for *-*-rtems*
on GCC 4.8, 4.9, and the head. Is is ok to commit?
2014-08-11 Joel Sherrill
* socket.c: Add conditionals for RTEMS. Add include of
and so correct prototype of gethostbyname_r() is used.
---
gcc/ada/socket.c | 7 ++-
1
This patch is needed to make Ada compile for *-*-rtems*
on GCC 4.8, 4.9, and the head. Is is ok to commit?
2014-08-11 Joel Sherrill
* s-osinte-rtems.adb: Correct formatting of line in license block.
---
gcc/ada/s-osinte-rtems.adb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
d
This patch is needed to make Ada compile for *-*-rtems*
on GCC 4.8, 4.9, and the head. Is is ok to commit?
2014-08-11 Joel Sherrill
* Makefile.in: Add CFLAGS_FOR_TARGET to GNATLIBCFLAGS_FOR_C.
---
libada/Makefile.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/li
Gary Benson writes:
>srand(time(NULL));
That's really bad, can never be reproduced. If you use a random seed
like this you need to at least print it.
-Andi
--
a...@linux.intel.com -- Speaking for myself only
On Fri, Aug 8, 2014 at 3:22 PM, Yi Yang wrote:
> Friendly ping.
Sorry, was OOO.
The solution of preventing splitting for named sections is good - but
it looks like there is already code that should prevent this. See the
user_defined_section_attribute check here - why is that not set? Looks
like
Hi Jan,
> * g++.dg/ipa/devirt-37.C: New testcase.
it seems something is very wrong with this testcase: initially, all
scans FAILed because the dump file didn't exist. But even with -O2
added to dg-options, the failures remain because either the wording is
different
FAIL: g++.dg/ipa/devirt
The following fixes SLP pure/hybrid detection with patterns.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk
sofar.
Richard.
2014-08-11 Richard Biener
PR tree-optimization/62075
* tree-vect-slp.c (vect_detect_hybrid_slp_stmts): Properly
handle u
Jakub Jelinek wrote:
> On Mon, Aug 11, 2014 at 10:27:03AM +0100, Gary Benson wrote:
> > This patch adds a simple fuzzer for the libiberty C++ demangler.
> > You can run it like this:
> >
> > make -C /path/to/build/libiberty/testsuite fuzz-demangler
> >
> > It will run until it dumps core (usual
> Did you try your code with 64bit pointer types?
Yes. It seems that the result is the same.
> In any case, I don't think it is worth spending time on this. I would check
> in the scop detection that we disable the handling of unsigned and pointer
> types. It is a complex thing to model and the a
Hello,
I have initially sent a patch for this at
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01144.html. But then a
patch for a similarly expressed issue
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01521.html (which I think
is the same underlying problem) was committed. As the PR
preprocesso
Hi,
I've observed SPEC2006 failure on avx512-vlbwdq branch.
It was caused by hardreg_cprop. In maybe_mode_change it was
assumed, that all values of the same register class and same mode.
are ok. This is not the case for i386/avx512. We need to honor
HARD_REGNO_MODE_OK.
Patch bellow does it.
Ok fo
On 11 Aug 13:51, Jakub Jelinek wrote:
> On Mon, Aug 11, 2014 at 03:47:07PM +0400, Kirill Yukhin wrote:
> > @@ -9020,7 +9025,8 @@ standard_sse_constant_opcode (rtx insn, rtx x)
> > }
> >
> > case 2:
> > - if (get_attr_mode (insn) == MODE_XI
> > + if (TARGET_AVX512VL
> > + ||
On Mon, Aug 11, 2014 at 9:36 AM, Thomas Preud'homme
wrote:
> In the code dealing with folding of structure and union initialization, there
> is a
> check that the size of the constructor is the same as the field being read.
> However, in the case of bitfield this test can be wrong because it reli
On Mon, Aug 11, 2014 at 03:47:07PM +0400, Kirill Yukhin wrote:
> @@ -9020,7 +9025,8 @@ standard_sse_constant_opcode (rtx insn, rtx x)
> }
>
> case 2:
> - if (get_attr_mode (insn) == MODE_XI
> + if (TARGET_AVX512VL
> + ||get_attr_mode (insn) == MODE_XI
Formatting, add s
Hello,
This patch introduces new way of generating all-0 and all-1
vectors.
Boostrapped.
Is it ok for trunk?
gcc/
* config/i386/i386.c (standard_sse_constant_opcode): Use
vpxord/vpternlog
if avx512 is availible.
--
Thanks, K
diff --git a/gcc/config/i386/i386.c b/gcc/config/i3
Thomas Preud'homme writes:
> In the code dealing with folding of structure and union initialization,
> there is a
> check that the size of the constructor is the same as the field being read.
> However, in the case of bitfield this test can be wrong because it relies on
> TYPE_SIZE to get the
On Sat, Aug 9, 2014 at 6:28 AM, Felix Yang wrote:
> Attached please find the patch and testcase for PR62037.
>
> DEF1 can be a GIMPLE_NOP and gimple_bb will be NULL then. The patch
> checks for that.
> Bootstrapped on x86_64-suse-linux. OK for trunk? Please commit this
> patch if it's OK.
>
Thank
On Mon, Aug 11, 2014 at 3:35 AM, Zhenqiang Chen
wrote:
> On 8 August 2014 23:22, Ramana Radhakrishnan
> wrote:
>> On Tue, Aug 5, 2014 at 10:31 AM, Zhenqiang Chen
>> wrote:
>>> Hi,
>>>
>>> For some large constants, ARM will split them during expanding, which
>>> makes impossible to hoist them ou
The following finally removes the SSA checking code from the
gimple_duplicate_loop_to_header_edge CFG hook. We've tamed
it down previously and now there is predictive commoning that
also doesn't get the chance to complete its work before that
checking runs.
Applied as obvious.
Richard.
2014-08
On 11/08/14 09:53, Richard Earnshaw wrote:
> On 11/08/14 08:49, Thomas Preud'homme wrote:
>> Being 32-bit wide in size, constant pool entries are always filled as 32-bit
>> quantities. This works fine for little endian system but gives some incorrect
>> results for big endian system when the value
On Mon, Aug 11, 2014 at 10:27:03AM +0100, Gary Benson wrote:
> This patch adds a simple fuzzer for the libiberty C++ demangler.
> You can run it like this:
>
> make -C /path/to/build/libiberty/testsuite fuzz-demangler
>
> It will run until it dumps core (usually only a few seconds).
>
> Is thi
Ping ^ 2?
Thanks!
-Zhenqiang
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Zhenqiang Chen
> Sent: Tuesday, April 29, 2014 5:38 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Ramana Radhakrishnan
> Subject: [PING] [PATCH, ARM] Set
Hi,
I noticed that we can remove the scope parameter from two parser
functions. Tested x86_64-linux.
Thanks,
Paolo.
2014-08-11 Paolo Carlini
* parser.c (cp_parser_diagnose_invalid_type_name,
cp_parser_make_typename_type): Remove scope parameter.
Hi all,
This patch adds a simple fuzzer for the libiberty C++ demangler.
You can run it like this:
make -C /path/to/build/libiberty/testsuite fuzz-demangler
It will run until it dumps core (usually only a few seconds).
Is this ok to commit?
Thanks,
Gary
--
2014-08-11 Gary Benson
On Thu, 7 Aug 2014, Richard Biener wrote:
> On Thu, 7 Aug 2014, Richard Biener wrote:
>
> >
> > The following are the non-cleanup parts. The patch moves us
> > to compress streams (what data-streamer thinks of "streams")
> > instead of whole sections. This enables us to only need
> > a single
On 11-08-14 10:18, Yury Gribov wrote:
On 08/11/2014 11:22 AM, Tom de Vries wrote:
I'm now using mktemp from File::Temp.
The script now relies on external Perl modules. This is probably fine because
AFAIK File::Temp and File::Copy are available included in all distributions.
+use File::Copy "c
On 08/08/14 18:53, Mike Stump wrote:
> On Aug 7, 2014, at 1:38 AM, Kyrill Tkachov wrote:
>>
>> Thanks for the detailed explanation, the linker errors I was seeing were
>> about relocations being truncated.
>
> Ah, those are bugs in your port! You should be able to generate large code
> and the
On 11/08/14 08:49, Thomas Preud'homme wrote:
> Being 32-bit wide in size, constant pool entries are always filled as 32-bit
> quantities. This works fine for little endian system but gives some incorrect
> results for big endian system when the value is *accessed* with a mode smaller
> than 32-bit
On 08/11/2014 11:22 AM, Tom de Vries wrote:
+if ($#ARGV == 1 && ("$ARGV[0]" eq "-i" || "$ARGV[0]" eq "--inline")) {
I'd do >= 1 but that's a question of personal preference.
What is the purpose of that proposed change ?
Kind of laying foundation for adding more flags in the future. But as I
On Sat, Aug 9, 2014 at 2:33 PM, Kugan wrote:
> Hi,
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52904
>
> Tescase was generating warning: assuming signed overflow does not occur
> when simplifying conditional to constant [-Wstrict-overflow] due to VRP
> missing the value range.
>
> This seems
Being 32-bit wide in size, constant pool entries are always filled as 32-bit
quantities. This works fine for little endian system but gives some incorrect
results for big endian system when the value is *accessed* with a mode smaller
than 32-bit in size. Suppose the case of the value 0x1234 that is
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
>
> No regression were observed on any of the tests. The ChangeLog is as
> follows:
>
>
> 2014-08-11 Thomas Preud'homme
>
> * gimple-fold.c (fold_ctor_reference): Don't fold
On 31/07/2014 00:08, Joseph S. Myers wrote:
> On Mon, 7 Jul 2014, Sylvestre Ledru wrote:
>
>> Hello,
>>
>> On 17/06/2014 19:41, Joseph S. Myers wrote:
>>> On Tue, 17 Jun 2014, Sylvestre Ledru wrote:
>>>
OK. I will do that.
We should test the following:
* default => run just -Wreturn-
In the code dealing with folding of structure and union initialization, there
is a
check that the size of the constructor is the same as the field being read.
However, in the case of bitfield this test can be wrong because it relies on
TYPE_SIZE to get the size of the field being read but TYPE_SIZ
On 11/08/2014 09:11, Roman Gareev wrote:
I am confused. It seems you attached some kind of reduced version of
btCollisionWorld.cpp? How did you obtain it? Did you compile and test
with these versions?
I’ve manually selected parts of code, which produce the scope.
I’ve found out that this bug i
On 04-08-14 13:50, Yury Gribov wrote:
> thanks for the review.
Np, I'm personally happy to see that script is useful.
> I've now interpreted it such that --inline prints to stdout what it
> would print to the patch file otherwise, that is, both log and patch.
> Printing just the log to stdo
On Thu, Aug 7, 2014 at 5:54 PM, Bin.Cheng wrote:
> On Thu, Aug 7, 2014 at 5:43 PM, Bin Cheng wrote:
>> Hi,
>>
>> The case depends on GCC inlining of global function, but the callee won't be
>> inlined because it's global function and considered over-writable during
>> run-time.
> It won't be inli
> I am confused. It seems you attached some kind of reduced version of
> btCollisionWorld.cpp? How did you obtain it? Did you compile and test
> with these versions?
I’ve manually selected parts of code, which produce the scope.
I’ve found out that this bug is most probably caused by absence of
p
1 - 100 of 101 matches
Mail list logo
