Hi all,
When I was testing the ccmp set of patches on aarch64, I found a
testcase which would ICE. This patch adds the testcase. I don't know
if this testcase ICEs due to other local set of patches though.
Thanks,
Andrew Pinski
2014-08-16 Andrew Pinski
* gcc.c-torture/compile/20140
Hi,
This patch fixes an issue in the C frontend wherein the result of a
cast-expression sometimes retains the type qualifiers of the operand
type. It is incorrect for a cast-expression to have a qualified type
because cast-expressions are rvalues.
This incorrect semantics can be seen through use
On Aug 16, 2014, at 5:28 PM, Gerald Pfeifer wrote:
> The patch below shaves 404 warnings from stage 1 when bootstrapping
> with clang 3.4.1 (i386-unknown-freebsd10.0).
>
> Regardless of whether we agree with that warning in clang, keeping
> things consistent and not using struct once and class i
The patch below shaves 404 warnings from stage 1 when bootstrapping
with clang 3.4.1 (i386-unknown-freebsd10.0).
Regardless of whether we agree with that warning in clang, keeping
things consistent and not using struct once and class in other places
makes sense. And I believe Mike was affirmati
Hello,
here is a patch extending DSE to handle calls to memset, memcpy and
memmove. A number of alias functions didn't have a version taking an
ao_ref*, so I added those. Instead of naming things _1, _2, etc I took
advantage of C++ and overloaded. I kept ref_maybe_used_by_call_p so we are
sti
On Sat, 2014-08-16 22:01:40 +0200, Marc Glisse wrote:
> For your tests, I thought the sequence was:
>
> checkout some revision of gcc
> build a native gcc at this revision
> use it to build a bunch of cross-compilers at the same revision
There are actually two different build strategies implemen
On Sat, 16 Aug 2014, Jan-Benedict Glaw wrote:
On Sat, 2014-08-16 17:10:12 +0200, Manuel López-Ibáñez
wrote:
On 16 August 2014 16:56, Jan-Benedict Glaw wrote:
There's --enable-werror-always, though that didn't trigger before (et
least not for the printf'ish checks.) So what's specifically di
On Sat, 2014-08-16 18:35:41 +0200, Manuel López-Ibáñez
wrote:
> On 16 August 2014 17:19, Manuel López-Ibáñez wrote:
> > Actually, I just noticed I committed the wrong patch and afterwards I
> > was not building Fortran.
>
> I spoke too fast. Although it is true I haven't build Fortran after
> t
This patch fixes a regression introduced in 4.9 in reworking the
handling of branch tables. The branch
table markers inserted by pa_reorg prevent the removal of jump tables
in the delayed branch pass. This
results in the branch table being left in the instruction stream when
it should have
On 16 August 2014 17:19, Manuel López-Ibáñez wrote:
> Actually, I just noticed I committed the wrong patch and afterwards I
> was not building Fortran.
I spoke too fast. Although it is true I haven't build Fortran after
the patch went it, I just did and I didn't get the above errors.
Can anyone
Actually, I just noticed I committed the wrong patch and afterwards I
was not building Fortran.
I will revert the patch and fix it. Sorry!
Thanks for noticing this!
Cheers,
Manuel.
On 16 August 2014 17:10, Manuel López-Ibáñez wrote:
> On 16 August 2014 16:56, Jan-Benedict Glaw wrote:
>> Ther
On Sat, 2014-08-16 17:10:12 +0200, Manuel López-Ibáñez
wrote:
> On 16 August 2014 16:56, Jan-Benedict Glaw wrote:
> > There's --enable-werror-always, though that didn't trigger before (et
> > least not for the printf'ish checks.) So what's specifically different
> > with this new function?
>
>
On 16 August 2014 16:56, Jan-Benedict Glaw wrote:
> There's --enable-werror-always, though that didn't trigger before (et
> least not for the printf'ish checks.) So what's specifically different
> with this new function?
Sorry, I don't find that option here: https://gcc.gnu.org/install/configure.
On Sat, 2014-08-16 16:22:13 +0200, Manuel López-Ibáñez
wrote:
> Could you explain a bit the setup of the buildbot?
>
> >From the logs, it is not evident that it is bootstrapping the
> compiler, and the first stage compiler should not be using -Werror. If
> not that, there must be some difference
A wild guess,
Perhaps you are re-building from a partially build tree, and
c-format.c is not being recompiled? That sounds weird but I cannot
think about anything else.
Cheers,
Manuel.
On 16 August 2014 16:22, Manuel López-Ibáñez wrote:
> Hi JBG,
>
> Could you explain a bit the setup of the b
Hi JBG,
Could you explain a bit the setup of the buildbot?
From the logs, it is not evident that it is bootstrapping the
compiler, and the first stage compiler should not be using -Werror. If
not that, there must be some difference between the buildbot setup and
the default setup in x86_64-gnu-li
Hi!
Wrongly replied to the CVS list. Maybe we'd have a reply-to header
there?
MfG, JBG
- Forwarded message from Jan-Benedict Glaw -
Date: Sat, 16 Aug 2014 15:50:41 +0200
From: Jan-Benedict Glaw
To: m...@gcc.gnu.org
Cc: gcc-...@gcc.gnu.org
Subject: Re: r214024 - in /trunk/gcc: ChangeLo
Hello!
Attached patch fixes the problem with false data dependency on output
register for popcnt, lzcnt and tzcnt insns on sandybridge and haswell
targets.
The new insn pattern shadows existing one, and after reload, the
clearing isns is split out of the insn. This way the clearing insn can
be sc
On Thu, 14 Aug 2014, Richard Biener wrote:
> See $subject.
>
> Ok?
I had the same change, but did not get to submit it while traveling
last week.
Is there anything else we need to do for the version change?
Gerald
On 16/08/2014 13:28, Roman Gareev wrote:
Richard, could you please review these patches? We would be very glad
for your comments.
P.S: I’ve attached an improved ChangeLog_entry.
The patch and changelog looks good to me, but we still need a
non-graphite reviewer oking the changes.
Tobias
Hi,
this patch wraps ipa_polymorphic_call_context into a C++ class. There are no
functional changes.
I am heading to restructure the code in a way so call contextes can be used in
forward propagation
and replace current ipa-cp BINFO walk. The goal is to split
get_polymorphic_call_info in a way
21 matches
Mail list logo
