Hi,
This adds the folding of x & ((~x) | y)) into x & y on the tree
level via fold-const.c
There is already partly done on the RTL level but it would be a good
thing for the tree level also.
OK for 4.8 (yes I know we have not branched yet but I thought I would
send it out so I don't forget abou
So, the issue here is that fold_non_dependent_expr_sfinae checks
potential_constant_expression, and doesn't fold anything which isn't one.
One approach would be to only guard cxx_constant_value with
require_potential_constant_expression within a template.
Another approach would be to check po
OK.
Jason
On 6 January 2012 04:59, Richard Henderson wrote:
> Ping. Reposting the patch as it required updates to HEAD.
This appears to have caused PR51876. Could you take a quick look ?
cheers
Ramana
>
>
> r~
When outputting PCH/LTO, the compiler tries to generate mangled names
for all decls before discarding language-specific data. But that
doesn't make sense for templates, and leads to conflicts in this case.
Fixed by refusing to mangle templates.
Tested x86_64-pc-linux-gnu, applying to trunk.
c
The mangling code didn't handle complex literals, leading to a crash.
Jakub's patch implements the standard ABI mangling for them; I just
added a testcase.
Tested x86_64-pc-linux-gnu, applying to trunk. It is a regression in
4.4, 4.5, and 4.6 as well, as 4.3 gave a sorry about mangling call_e
On Mon, Jan 16, 2012 at 07:37:43PM +, Robert Millan wrote:
> El 27 de desembre de 2011 12:25, Robert Millan ha escrit:
> > El 19 de desembre de 2011 21:04, Robert Millan ha escrit:
> >> This small patch fixes a build regression on GNU/kFreeBSD.
> >
> > Ping!
>
> Ping again. Please note that
El 27 de desembre de 2011 12:25, Robert Millan ha escrit:
> El 19 de desembre de 2011 21:04, Robert Millan ha escrit:
>> This small patch fixes a build regression on GNU/kFreeBSD.
>
> Ping!
Ping again. Please note that Gerald Pfeifer has volunteered to commit
the patch once it is approved.
--
> For the record, what is TPF ?
One of IBM's s390x operating systems. ../gcc/configure --target=tpf
Ah! I read that as "pointer to aggregate" :-P
This breaks separates the libstdc++ source files for C++11 from the
C++03 sources, and puts C++11 files in a new source directory,
src-c++11, which is compiled into libstdc++11convenience.a, and linked
in to libstdc++ in the same manner that libsupc++ uses.
Thus, no change to user-level or tool-l
There were two problems with build_static_cast_1's handling of this
testcase:
1) We weren't using unlowered_expr_type to get the type of the
expression, so we were comparing int to the internal bit-field type,
which doesn't match.
2) We were trying to bind an lvalue reference to a bit-field
Dear Tobias,
> Build and regtested on x86-64-linux.
> OK for the trunk? (And [together with (a)] for the 4.6 branch?)
OK - thanks!
Paul
Dear Tobias,
> Thus, I decided to backout the patch Rev. 181199 (cf. PR, comment 1) - and
> implement a simple TREE_READONLY in trans-decl.c.
I think that was a very sensible decision :-)
>
> Build and regtested on x86-64-linux.
> OK for the 4.7 trunk?
>
OK, thanks for the patch.
Paul
On Jan 16, 2012, at 9:14 AM, Rainer Orth wrote:
> As suggested in the PR, it would be better to just skip the test to
> avoid noise in mail-report.log:
Usually we avoid noise in the testing log files by making testcases pass? I
know, this one is kinda inelegant, but I'd just leave it as is. If
Dear all,
current gfortran uses FL_PARAMETER for _vtab and _init_def;
unfortunately, that will fail sometimes to properly read the symbols; in
the PR _vtab->_extension's symbol is not properly read, depending on the
USE statement order.
I tried to debug it, but I was not very successful. In
Ian Lance Taylor writes:
> I have committed a patch to libgo to update it to the weekly.2011-12-22
> release. As usual I am not including all the changes here, only the
> ones to files which are specific to gccgo. Bootstrapped and ran Go
> testsuite on x86_64-unknown-linux-gnu. Committed to ma
Hi,
in this diagnostic issue we incorrectly print unsigned template
arguments as signed. The fix seems straightforward: just use the very
same algorithm used in dump_generic_node for INTEGER_CST, thus dispatch
to either pp_wide_integer or pp_unsigned_wide_integer.
Booted and tested C++ (tes
Dear all,
PR 50981 is about passing an absent argument to an elemental procedure.
a) Passing an absent optional dummy as actual.
4.4-4.7 Regression, fixed for 4.7; backporting pending.
b) Passing an unallocated allocatable or not associated pointer as actual
F2008/GCC 4.6 feature. Fixed by this
As suggested in the PR, it would be better to just skip the test to
avoid noise in mail-report.log:
WARNING: libitm.c++/static_ctor.C compilation failed to produce executable
The following patch does just that, and simplifies the dg-skip-if on the
way.
Bootstrapped without regressions on i386-pc
As reported in PR libitm/51822, the libitm.c++/eh-1.C test FAILs on
Solaris with
terminate called after throwing an instance of 'int'
I found that the failures are for two different reasons:
* Enabling ld.so.1 debugging (LD_DEBUG=bindings), it turned out that the
64-bit failures on Solaris 10
Torvald Riegel writes:
> On Mon, 2011-11-21 at 15:06 +0100, Rainer Orth wrote:
>> * _ITM_getThreadnum is the only symbol in libitm.map that isn't present
>> in the library. It's documented as missing and should perhaps be
>> removed from the map?
>
> Yes, this is not supported anymore.
Here
Hello Everyone,
This patch is for the Cilkplus branch. It adds a "(int)" cast for a for
loop condition which uses VEC_length.
Thanking You,
Yours Sincerely,
Balaji V. Iyer. diff --git a/gcc/ChangeLog.cilk b/gcc/ChangeLog.cilk
index b51ddcd..8d65ca2 100644
--- a/gcc/ChangeLog.cilk
+++ b/gcc/
Richard Henderson writes:
> On 11/21/2011 09:23 AM, Rainer Orth wrote:
>> Richard Henderson writes:
>>
>>> This is only ok if the compiler and library are build with default options.
>>> If you use --with-arch=corei7-avx then we may well use AVX insns all through
>>> the library, not just in th
Not really - you handle both ptr and *ptr in the same predicate and
call both "address escaped". What I suggested was sth like
I think I confused myself and you by asking the wrong question in the
first place.
Actually, what I want is to handle VAR_DECL correctly, and your original
sugges
On Thu, 12 Jan 2012, Martin Jambor wrote:
> Hi,
>
> On Thu, Jan 12, 2012 at 03:23:31PM +0100, Richard Guenther wrote:
> > On Thu, 12 Jan 2012, Martin Jambor wrote:
> >
> > > Hi,
> > >
> > > I tend to believe that this is the SRA part of a fix for PR 50444 (and
> > > possibly some strict alignme
Cary Coutant writes:
> gcc/testsuite/ChangeLog:
>
> PR debug/45682
> * g++.dg/debug/dwarf2/nested-3.C: New test.
As per this comment from Jakub in another subthread:
Just a testcase comment, I bet this will surely fail on Darwin
or other targets that aren't capable of mergin
On Mon, Jan 16, 2012 at 3:29 PM, Aldy Hernandez wrote:
> As discussed in the PR, the problem here is that we are using
> ptr_deref_may_alias_global_p() to determine if a dereferenced address
> escapes, whereas we were previously using the now non existent
> is_call_clobbered. The function ptr_der
> Maybe the best solution would be to remove the SUBREG case from the generic
> apply_distributive_law subroutine, and instead add a special check for the
> distributed subreg case right at the above place in simplify_set; i.e. to
> perform the inverse distribution only if it is already guaranteed
As discussed in the PR, the problem here is that we are using
ptr_deref_may_alias_global_p() to determine if a dereferenced address
escapes, whereas we were previously using the now non existent
is_call_clobbered. The function ptr_deref_may_alias_global_p() does not
understand SSA_NAMEs, where
Richard Kenner wrote:
> > > The problem appears to be that an RTX expression like
> > >
> > > (minus:QI (subreg:QI (reg:SI 64 [ a ]) 0)
> > > (subreg:QI (reg:SI 66 [ b ]) 0))
> > >
> > > seems to be considered non-canonical by combine, and is instead
> > > transformed into
> > >
On 01/16/2012 02:38 PM, Jakub Jelinek wrote:
> Fixed thusly, bootstrapped on s390-linux --with-mode=esa. Ok for trunk?
>
> 2012-01-16 Jakub Jelinek
>
> PR bootstrap/51860
> * config/s390/s390.c (s390_chunkify_start): Don't skip
> call insns followed by NOTE_INSN_CALL_ARG_LOC
Hi!
We get a -fcompare-debug failure on s390 -mesa on c-common.c, the
problem is in s390_chunkify_start which behaves differently when
a call is followed by NOTE_INSN_CALL_ARG_LOCATION.
We skip the calls that are followed by that note in order to
avoid inserting jumps and literal pools in between
On Mon, 16 Jan 2012, Richard Guenther wrote:
> On Mon, 16 Jan 2012, Richard Guenther wrote:
>
> > On Fri, 13 Jan 2012, Joseph S. Myers wrote:
> >
> > > On Fri, 13 Jan 2012, Richard Guenther wrote:
> > >
> > > > This fixes PR37985 where since
> > > > http://gcc.gnu.org/ml/gcc-patches/2006-08/ms
Eric Botcazou writes:
>> All EH-related tests fail with a recent upgrade on Solaris 10. Interestingly,
>> the old implementation keeps working with the upgrade.
>
> I've applied the attached patch to mainline and 4.6 branch. It reverts back
> to
> the old pattern matching code in the Solaris 8
On Mon, 16 Jan 2012, Richard Guenther wrote:
> On Mon, 16 Jan 2012, Jakub Jelinek wrote:
>
> > On Mon, Jan 16, 2012 at 09:35:08AM +0100, Richard Guenther wrote:
> > > But that's of course intended. Attributes or redirection on the
> > > extern inline variant are completely meaningless.
> > >
>
On Mon, 16 Jan 2012, Richard Guenther wrote:
> On Fri, 13 Jan 2012, Joseph S. Myers wrote:
>
> > On Fri, 13 Jan 2012, Richard Guenther wrote:
> >
> > > This fixes PR37985 where since
> > > http://gcc.gnu.org/ml/gcc-patches/2006-08/msg01041.html we
> > > mark conversions produced by convert_to_i
On Mon, 16 Jan 2012, Jakub Jelinek wrote:
> On Mon, Jan 16, 2012 at 09:35:08AM +0100, Richard Guenther wrote:
> > But that's of course intended. Attributes or redirection on the
> > extern inline variant are completely meaningless.
> >
> > > If you want to keep olddecl as is, then IMHO we should
On 01/13/2012 08:21 PM, Georg-Johann Lay wrote:
> I really don't expect anyone to run test suites on any platform or target
> supported by GCC. Such an approach is completely useless because of the amount
> of time and system resources and I never proposed that.
>
> But it appears that many of th
On Mon, Jan 16, 2012 at 09:35:08AM +0100, Richard Guenther wrote:
> But that's of course intended. Attributes or redirection on the
> extern inline variant are completely meaningless.
>
> > If you want to keep olddecl as is, then IMHO we should add a new bool
> > argument to merge_decls and if th
On Jan 13, 2012, at 10:59 PM, DJ Delorie wrote:
>
>> That should not be necessary as there is a mode check below. Do you
>> hit the issue only when the VOID_TYPE_P check is true? In that case
>> simply delete it - it has become obsolete.
>
> That seems to be happening, yes, but there are othe
On Fri, Jan 13, 2012 at 6:18 PM, Michael Matz wrote:
> Hi,
>
> the stack-var conflict generation code needs 13 (out of 34) seconds, with
> -O0 on the second testcase of PR46590. Most of the time is spent in
> generating the same conflicts again and again at each basic block (the
> time right now
On Fri, Jan 13, 2012 at 5:52 PM, Tobias Burnus wrote:
> Dear all,
>
> seemingly may (potential) users still do not realize that gfortran's
> multi-image coarray support is not yet usable as only the basic libcaf
> infrastructure (registering, deregistering, argument passing, syncing, start
> up/cl
On Fri, 13 Jan 2012, Joseph S. Myers wrote:
> On Fri, 13 Jan 2012, Richard Guenther wrote:
>
> > This fixes PR37985 where since
> > http://gcc.gnu.org/ml/gcc-patches/2006-08/msg01041.html we
> > mark conversions produced by convert_to_integer with TREE_NO_WARNING.
> > This may shadow "real" stmt
On Fri, 13 Jan 2012, Jakub Jelinek wrote:
> On Fri, Jan 13, 2012 at 11:05:36AM +0100, Richard Guenther wrote:
> > This fixes the ICEs that occur with redeclared extern inline functions
> > in some circumstances. It avoids the cgraph confusion by _not_ merging
> > the two decls in this case but si
On Sun, 15 Jan 2012, Jakub Jelinek wrote:
> Hi!
>
> The recent changes in tree_function_versioning broke the following
> testcase. If DECL_RESULT exists, but has void type, then we used to
> remap_decl it before, but now we don't, so in this case the same RESULT_DECL
> is used in two different f
On Fri, 13 Jan 2012, Jason Merrill wrote:
> While looking at the -fmem-stats results for this testcase, I noticed about
> 500MB of overhead coming from the VEC_safe_push in cp_lexer_new_main. This is
> happening because when we allocate space for a vector, the allocator pads it
> out some, and th
47 matches
Mail list logo
