As requested, I am posting this patch to gcc-patches.
Problem description:
The detailed description and examples can be found in pr61662, but in
short: using "#ifdef __x86_64__" to determine the size of a 'long' does
not reliably yield the correct result. This causes _lrotl and _lrotr to
retu
Hi,
On 07/09/2014 03:53 AM, Tim Shen wrote:
+// This file is for general testcases in regex.
+// We use a single file for multiple testcases because it takes too long to
+// compile regex for each testcase in a single file.
+// Normal testcases in other files should be moved into this file in th
On 08/07/14 18:53 -0700, Tim Shen wrote:
+// libstdc++/61720
+void
+PR61720()
+{
+ bool test __attribute__((unused)) = true;
+
+ string test = R"("test\")";
Does this compile?
You've redeclared 'test'
On 09/07/14 09:48 +0200, Paolo Carlini wrote:
Hi,
On 07/09/2014 03:53 AM, Tim Shen wrote:
+// This file is for general testcases in regex.
+// We use a single file for multiple testcases because it takes too long to
+// compile regex for each testcase in a single file.
+// Normal testcases in o
Hi,
On 07/09/2014 10:08 AM, Jonathan Wakely wrote:
All the 28_regex tests run as part of the same target:
normal7) \
dirs="`cd $$srcdir; echo 26_*/* 28_*/[c-z]*`";; \
I've tried moving the 26_numeric tests to a different target but it
doesn't make much difference, the regex
On 09/07/14 10:10 +0200, Paolo Carlini wrote:
Hi,
On 07/09/2014 10:08 AM, Jonathan Wakely wrote:
All the 28_regex tests run as part of the same target:
normal7) \
dirs="`cd $$srcdir; echo 26_*/* 28_*/[c-z]*`";; \
I've tried moving the 26_numeric tests to a different target b
On Wed, Jul 09, 2014 at 09:08:40AM +0100, Jonathan Wakely wrote:
> >Thus the plan would be *all* the regex testcases in a single file!?! If I
> >understand correctly, that certainly doesn't make sense. In any
>
> Jakub pointed out that there are lots of useful tests for regexes in
> the glibc test
Hi,
On 07/09/2014 12:26 AM, Jason Merrill wrote:
I'd rather handle this in check_cv_quals_for_unify.
Yes, the below passes testing.
Thanks,
Paolo.
/
/cp
2014-07-09 Paolo Carlini
DR 1584
PR c++/57466
* pt.c (check_cv_quals_for_unify): Impleme
First of all, the recognized interval between pings is a week; please
don't ping more often than that.
On 04/07/14 11:57, Gopalasubramanian, Ganesh wrote:
> Hi,
>
> Attached is a patch that implements
> * Prefetch with immediate offset in the range 0 to 32760 (multiple of 8).
> Added a predi
Hello,
perhaps I could write bit more on my longer term plans. At the moment 30% of
firefox WPA is taken
by straming trees and another roughly 30% is taken by inliner. It is bit
anoying but relatively
easy to optimize inliner, but trees represent bigger problem.
According to the stats average
Richard,
>
> That is, have a tree_may_be_mergeable_p (), call it during the DFS
> walk storing it alongside the visited edges and thus obtain a result
> for each SCC, stream that as a flag (a special hash value is ugly,
> but well ... I guess it works). The important part is to make an SCC
> !tre
Hi,
On 07/09/2014 12:39 AM, Jason Merrill wrote:
On 07/07/2014 11:15 AM, Paolo Carlini wrote:
+ error ("only declarations can be marked %");
That's pretty unclear, since a definition is a declaration.
Let's split this into three error messages: If the problem is that
we're outside the
On Tue, Jul 8, 2014 at 10:12 PM, Mark Wielaard wrote:
> The java frontend is one of the only places where build_type_variant is
> still used. New code should use build_qualified_type. See gcc/tree.h.
>
> Build and tested on x86_64-unknown-linux-gnu.
Ok. Can build_type_variant be removed now?
Th
On Wed, Jul 9, 2014 at 12:33 AM, Jason Merrill wrote:
> On 07/08/2014 12:38 PM, Carlos O'Donell wrote:
>>
>> What rationale would you give for not warning on 1-1?
>
>
> Because it's not likely to be a case of argument transposition; it's more
> likely to be an expression that just happens to evalu
On Wed, Jul 09, 2014 at 12:26:09PM +0200, Richard Biener wrote:
> > I suppose we could use an INTEGER_CST distinct from the one in
> > TYPE_CACHED_VALUES for raw 0, with a TREE_LANG_FLAG set.
>
> Ick. (please no - at least make sure it doesn't survive anywhere to the
> middle-end, like fold or gi
On Wed, Jul 9, 2014 at 10:58 AM, Jan Hubicka wrote:
> Hello,
> perhaps I could write bit more on my longer term plans. At the moment 30% of
> firefox WPA is taken
> by straming trees and another roughly 30% is taken by inliner. It is bit
> anoying but relatively
> easy to optimize inliner, but
On Wed, Jul 9, 2014 at 12:32 PM, Jakub Jelinek wrote:
> On Wed, Jul 09, 2014 at 12:26:09PM +0200, Richard Biener wrote:
>> > I suppose we could use an INTEGER_CST distinct from the one in
>> > TYPE_CACHED_VALUES for raw 0, with a TREE_LANG_FLAG set.
>>
>> Ick. (please no - at least make sure it d
On Wed, 2014-07-09 at 12:23 +0200, Richard Biener wrote:
> On Tue, Jul 8, 2014 at 10:12 PM, Mark Wielaard wrote:
> > The java frontend is one of the only places where build_type_variant is
> > still used. New code should use build_qualified_type. See gcc/tree.h.
> >
> > Build and tested on x86_64-
On Wed, Jul 09, 2014 at 12:51:32PM +0200, Richard Biener wrote:
> At least it shouldn't (they are not required to be shared and usually are not
> if they've gone a transition from TREE_OVERFLOW to !TREE_OVERFLOW).
>
> Well, still feels ugly to me - but it's Jasons call in the end.
Another possibi
> This part can probably be speed up quite a bit by doing the SCC unification
> before materializing the SCC, that is, doing the "on-disk" format compare
> idea.
> The issue here is that for bigger SCCs that have hash collisions in their
> entries we need to do the edge walk - but eventually havin
On July 9, 2014 2:36:57 PM CEST, Jan Hubicka wrote:
>> This part can probably be speed up quite a bit by doing the SCC
>unification
>> before materializing the SCC, that is, doing the "on-disk" format
>compare idea.
>> The issue here is that for bigger SCCs that have hash collisions in
>their
>> e
On Wed, Jul 9, 2014 at 12:50 AM, Jan Hubicka wrote:
>> With the patch, GCC on AIX now responds that "ifunc" is supported.
>> The C and C++ attr-ifunc testcases now run and fail.
>
> This is unexpected. I am testing version of the patch with
>
> if (lookup_attribute ("ifunc", DECL_ATTRIBUTES (n-
>
> Are we sure it ever stabilizes? But yes, I had something like this in mind
> (just do one iteration always) in case we need to improve hashing.
Not necesarily - imagine two identical type variants, no matter how hard we
hash&rehash, they will be same as they are identical. We can just keep
Hi all,
These intrinsics are implemented as macros that map down to asms but the
types they accept are inconsistent with the ACLE spec. This patch fixes
them, although they should be reimplemented properly in C in the future.
This is a bugfix and it applies cleanly to trunk, 4.9 and 4.8.
I kn
> All of these warnings (-Wsizeof-pointer-memaccess, -Wsizeof-array-argument
> and -Wmemset-transposed-args) are implemented in a hackish way, because we
> fold everything too early. Perhaps for such analysis we want a FOLDED_EXPR
> which would have arguments what it has been folded to and the ori
I nearly missed those: there were two reference to gcc.gnu.org via
http in cgi-bin.
Applied.
Gerald
Index: cgi-bin/cvsweb.conf
===
RCS file: /cvs/gcc/wwwdocs/cgi-bin/cvsweb.conf,v
retrieving revision 1.7
diff -u -r1.7 cvsweb.conf
--
Richard,
during testing the gcc.target/mips/fuse-caller-save*.c test-cases with more
combinations of -march, -mabi, -fpic etc, I found that the checks for amount of
stores are rather fragile, so I removed them in this patch.
The remaining checks check for absence of $16. To address the risk t
Hi,
this is the first part of patch I comitted, changing the output machinery. It
has fix for the ifunc
"attribute".
Honza
Index: ChangeLog
===
--- ChangeLog (revision 212393)
+++ ChangeLog (working copy)
@@ -1,3 +1,14 @@
+2014-
Hello,
the implementation of homogenous float aggregates for the ELFv2 ABI has
unfortunately shown to have a bug in a corner case.
The problem is that because such aggregates are packed in the argument
save area, but each (4-byte) float occupies one of just 13 registers
on its own, we may run out
Hello,
last year, Bill added a patch to address PR 57949 by aligning aggregates
requiring at least 128-bit alignment at a quadword boundary in the
parameter save area:
https://gcc.gnu.org/ml/gcc-patches/2013-08/msg00803.html
Unfortunately, to implement this check, Bill's patch used a pre-existing
Hello,
running the ABI compatibility test suite against another compiler showed
strange effects caused by code in ADJUST_FIELD_ALIGN on rs6000:
#define ADJUST_FIELD_ALIGN(FIELD, COMPUTED) \
((TARGET_ALTIVEC && TREE_CODE (TREE_TYPE (FIELD)) == VECTOR_TYPE)\
? 128
Hi,
this is the last part enabling local aliases that seems to work now.
I think we can go ahead and try to enable section GC and SUPPORTS_ONE_ONLY.
Honza
Index: ChangeLog
===
--- ChangeLog (revision 212395)
+++ ChangeLog (workin
Hi,
this patch fixes the devirt10 and devirt15 failures - the problem was that we
did not look into alias target
when estimating devirt benefit.
Bootstrapped/regtested rs6000-aix, comitted.
* ipa-cp.c (devirtualization_time_bonus): Walk through aliases.
* ipa-inline-analysis.c (e
Since rs6000.h defines LOGICAL_OP_NON_SHORT_CIRCUIT to 0, powerpc*-*-*
should be a logical_op_short_circuit target. This fixes the following
failures.
< FAIL: gcc.dg/binop-xor1.c scan-tree-dump-times optimized "^" 1
< FAIL: gcc.dg/tree-ssa/ssa-dom-thread-4.c scan-tree-dump-times dom1
"Thre
On Mon, May 19, 2014 at 12:19 PM, Richard Biener wrote:
> On Fri, 16 May 2014, Jeff Law wrote:
>
>> On 05/14/14 03:06, Richard Biener wrote:
>> >
>> > The following fixes pre/post-inc/dec gimplification of promoted
>> > integer types. There is the issue with the way TYPE_OVERFLOW_UNDEFINED
>> > i
On Jul 8, 2014, at 9:01 PM, Andi Kleen wrote:
> With ICL enabled and an LTO boot strap the ICL build always errors
> out due to -Werror=maybe-undefined. The following patch fixes
> the LTO build for me by initializing the variables in question.
>
> All warnings were false positives as far as I c
> It is a driver patch, so you get something only
> when you invoke the driver,
> not when compiling with cc1 or cc1plus etc. directly.
>
> Just pick up any known ICE from bugzilla and try it...
Tried that with some recent ICEs:
* PR 61445 - generated expected repro
* PR 60990 and 61623 - reports
On Wed, Jul 09, 2014 at 10:17:01AM -0700, Mike Stump wrote:
> On Jul 8, 2014, at 9:01 PM, Andi Kleen wrote:
> > With ICL enabled and an LTO boot strap the ICL build always errors
> > out due to -Werror=maybe-undefined. The following patch fixes
> > the LTO build for me by initializing the variable
On Jul 9, 2014, at 12:48 AM, Paolo Carlini wrote:
>
> On 07/09/2014 03:53 AM, Tim Shen wrote:
>> +// This file is for general testcases in regex.
>> +// We use a single file for multiple testcases because it takes too long to
>> +// compile regex for each testcase in a single file.
>> +// Normal
> Ok.
>
> :-) I usually just expect people to check in such minor stuff once the
> discussion dies down
> and all the good feedback is incorporated.
Thanks for the tip. I am still learning the rules.
Cheers,
Dominique
The patch fixes the last issue with PR 61225.
Could it be reviewed?
TIA
Dominique
> FWIW, x86_64-darwin *passes* the test-cases you added with the patch series.
gcc.target/i386/sibcall-1.c fails in 32 bit mode:
FAIL: gcc.target/i386/sibcall-1.c scan-assembler-not mov
Cheers,
Dominique
On Wed, Jul 9, 2014 at 12:02 PM, Ulrich Weigand wrote:
> Hello,
>
> the implementation of homogenous float aggregates for the ELFv2 ABI has
> unfortunately shown to have a bug in a corner case.
>
> The problem is that because such aggregates are packed in the argument
> save area, but each (4-byte
On Wed, Jul 9, 2014 at 12:04 PM, Ulrich Weigand wrote:
> Hello,
>
> last year, Bill added a patch to address PR 57949 by aligning aggregates
> requiring at least 128-bit alignment at a quadword boundary in the
> parameter save area:
> https://gcc.gnu.org/ml/gcc-patches/2013-08/msg00803.html
>
> Un
On Wed, Jul 9, 2014 at 11:25 AM, David Edelsohn wrote:
> On Wed, Jul 9, 2014 at 12:04 PM, Ulrich Weigand wrote:
>> Hello,
>>
>> last year, Bill added a patch to address PR 57949 by aligning aggregates
>> requiring at least 128-bit alignment at a quadword boundary in the
>> parameter save area:
>>
On Wed, Jul 9, 2014 at 12:06 PM, Ulrich Weigand wrote:
> Hello,
>
> running the ABI compatibility test suite against another compiler showed
> strange effects caused by code in ADJUST_FIELD_ALIGN on rs6000:
>
> #define ADJUST_FIELD_ALIGN(FIELD, COMPUTED) \
> ((TARGET_ALTIVEC && TREE_CODE (TREE_T
Tom de Vries writes:
> Richard,
>
> during testing the gcc.target/mips/fuse-caller-save*.c test-cases with more
> combinations of -march, -mabi, -fpic etc, I found that the checks for amount
> of
> stores are rather fragile, so I removed them in this patch.
Which combinations specifically? I
On 9 July 2014 18:33, Mike Stump wrote:
> The other limit is how big the resulting program is. Too large, and it won’t
> test on a small memory system. Under a meg, and most people don’t care. As
> it climbs above that it starts mattering more.
If the test is driven by a data file containing
As pointed out by Dagobert Michelsen:
https://gcc.gnu.org/ml/gcc/2014-07/msg00083.html
Patch applies to trunk, gcc 4.9 and gcc 4.8 branches.
2014-07-09 Tom G. Christensen
* doc/install.texi: Remove links to defunct package providers for
Solaris
--- a/gcc/doc/install.texi
+++
On Jul 9, 2014, at 11:29 AM, Eric Christopher wrote:
>>> - The change only affects rare cases: passing a struct by value that is
>>> * not a float/vector special case, and
>>> * has a size of 1, 2, 4, 8, or 16 bytes, and
>>> * has an alignment requirement of 16 bytes or more
>> I copied the
On 07/08/14 00:38, Nagaraju Mekala wrote:
Hi Michael,
-Original Message-
From: Michael Eager [mailto:ea...@eagerm.com]
Sent: Tuesday, July 01, 2014 11:12 AM
To: David Holsgrove; gcc-patches@gcc.gnu.org
Cc: Edgar Iglesias; John Williams; Vidhumouli Hunsigida; Nagaraju Mekala; Ajit
Kumar
Hi,
actually I forgot one hunk in the tree. This time it makes speculative
devirtualuzation
to consider node and its alias to be equivalent.
This happens in ipa-devirt10 becuase one of targets appears in symbol table and
thus is redirected
to alias while the second doesn't.
* ipa-devir
Hi!
On Tue, 17 Jun 2014 23:03:47 +0200, Jakub Jelinek wrote:
> This patch adds the target directives.
> Tested both normally plus with target.c/splay-tree.c from
> gomp-4_0-branch@203409 plus the attached patch against
> target.c to implement the new to_pset map kind (5) and
> allow handling of N
David Edelsohn wrote:
> On Wed, Jul 9, 2014 at 12:06 PM, Ulrich Weigand wrote:
> > Hello,
> >
> > running the ABI compatibility test suite against another compiler showed
> > strange effects caused by code in ADJUST_FIELD_ALIGN on rs6000:
> >
> > #define ADJUST_FIELD_ALIGN(FIELD, COMPUTED) \
> >
Updated patch, after Uros’ comments (except testing for != 0 in the testcase;
I’d rather keep the existing > 0 test).
Bootstrapped and regtested on x86_64-apple-darwin13, tested by Uros on alpha.
Given that the patch is mostly x86 and alpha-specific, and Uros has approved it
from that point of v
On 07/09/2014 06:07 AM, Paolo Carlini wrote:
The third case, I don't think it can really happen,
because there are earlier checks which simply return error_mark_node if
a declaration is within the wrong class...
Not if it's a friend declaration:
struct A {
explicit A(int);
};
struct B {
e
OK.
Jason
On 09-07-14 20:32, Richard Sandiford wrote:
Tom de Vries writes:
Richard,
during testing the gcc.target/mips/fuse-caller-save*.c test-cases with more
combinations of -march, -mabi, -fpic etc, I found that the checks for amount of
stores are rather fragile, so I removed them in this patch.
Wh
Hi,
On 07/09/2014 10:34 PM, Jason Merrill wrote:
On 07/09/2014 06:07 AM, Paolo Carlini wrote:
The third case, I don't think it can really happen,
because there are earlier checks which simply return error_mark_node if
a declaration is within the wrong class...
Not if it's a friend declaration:
On 07/09/2014 10:40 AM, Manuel López-Ibáñez wrote:
All of these warnings (-Wsizeof-pointer-memaccess, -Wsizeof-array-argument
and -Wmemset-transposed-args) are implemented in a hackish way, because we
fold everything too early. Perhaps for such analysis we want a FOLDED_EXPR
which would have arg
OK, thanks.
Jason
Hi,
The following two patches are based on the earlier "dwarf2out.c: Pass
one cv_quals argument" and "Emit DW_tag_restrict_type" patches I posted
earlier. Since there currently is not even an early draft yet for DWARFv5,
just a collection of proposals that might or might not be adopted these
patch
gcc/ChangeLog
PR debug/60782
* dwarf2out.c (modified_type_die): Handle TYPE_QUAL_ATOMIC.
* opts.c (common_handle_option): Accept -gdwarf-5.
gcc/testsuite/ChangeLog
PR debug/60782
* gcc.dg/guality/atomic.c: New test.
include/ChangeLog
PR debug/607
gcc/ChangeLog
* dwarf2out.c (decl_user_align): New function.
(type_user_align): Likewise.
(modified_type_die): Add and handle align argument.
(add_bound_info): Likewise.
(base_type_for_mode): Call modified_type_die with zero user align.
(add_subscrip
When I previously changed __pbase_type_info::__pointer_catch to be pure
I was overlooking that it was defined in a different header. Oops.
This patch properly fixes the problem that the earlier patch was
intended to fix: an inline function needs to be defined in every
translation unit where it
On Wed, Jul 9, 2014 at 12:01 PM, Mike Stump wrote:
> On Jul 9, 2014, at 11:29 AM, Eric Christopher wrote:
- The change only affects rare cases: passing a struct by value that is
* not a float/vector special case, and
* has a size of 1, 2, 4, 8, or 16 bytes, and
* has an
On Wed, Jul 9, 2014 at 1:23 AM, Jonathan Wakely wrote:
> I can't actually reproduce the bug with trunk.
It's a BFS executor bug, so we need to #define
_GLIBCXX_REGEX_USE_THOMPSON_NFA (or use regex_search_debug instead)
and use styles other than ECMAScript.
I didn't notice that it's not a good id
Ping?
thanks,
Cong
On Tue, Jul 8, 2014 at 8:23 PM, Xinliang David Li wrote:
> Cong, can you ping this patch again? There does not seem to be
> pending comments left.
>
> David
>
> On Tue, Dec 17, 2013 at 10:05 AM, Cong Hou wrote:
>> Ping?
>>
>>
>> thanks,
>> Cong
>>
>>
>> On Mon, Dec 2, 2013
68 matches
Mail list logo