Committed attached patch as rev. 226923 to document the behavior of gfortran
when opening & closing symbolic links.
Clearing up some of the old libgfortran PRs...
FX
Index: ChangeLog
===
--- ChangeLog (revision 226922)
+++ Chan
On Aug 15, 2015, Andreas Schwab wrote:
> FAIL: gcc.target/aarch64/target_attr_crypto_ice_1.c (internal compiler error)
> In file included from
> /opt/gcc/gcc-20150815/gcc/testsuite/gcc.target/aarch64/target_attr_crypto_ice_1.c:4:0:
Are you sure this is a regression introduced by my patch? The
On m68k:
FAIL: gcc.c-torture/execute/20050316-1.c -O0 execution test
FAIL: gcc.c-torture/execute/20050316-2.c -O0 execution test
FAIL: gcc.c-torture/execute/20050316-3.c -O0 execution test
FAIL: gcc.c-torture/execute/simd-4.c -O0 execution test
FAIL: gcc.c-torture/execute/simd-6.c -O
Attached patch, committed as revision 226924, adjusts slightly the front-end’s
handling of floating-point built-ins, notably making BUILT_IN_SIGNBIT
type-generic. This generates better code for IEEE_IS_NEGATIVE and
IEEE_COPY_SIGN functions, through direct expansion by the compiler rather than
l
On Thu, 2015-06-11 at 14:36 +0300, Gleb Fotengauer-Malinovskiy wrote:
> On Fri, May 15, 2015 at 03:04:27PM +0200, Torvald Riegel wrote:
> > On Wed, 2015-05-06 at 17:54 +0300, Gleb Fotengauer-Malinovskiy wrote:
> > > 2015-05-06 Gleb Fotengauer-Malinovskiy
> > >
> > > PR libitm/61164
> > > *
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Danish team of translators. The file is available at:
http://translationproject.org/latest/gcc/da.po
(This file, 'gcc-5.2.0.da.po', has just
prepare_call_address in calls.c is the wrong place to handle -fno-plt.
We shoudn't force function address into register and hope that load
function address via GOT and indirect call via register will be folded
into indirect call via GOT, which doesn't always happen. Allso non-PIC
case can only be
On Wed, Aug 12, 2015 at 7:23 AM, Richard Biener wrote:
> On Wed, 12 Aug 2015, Richard Biener wrote:
>
>>
>> This brings FRE/PRE up to the same level as DOM in being able to
>> remove redundant conditionals. It does so by inserting temporary
>> conditional expressions proved to be true on single p
On Jun 15, 2015, at 7:30 AM, Kyrill Tkachov wrote:
>
> On 29/05/15 11:15, Kyrill Tkachov wrote:
>> On 29/05/15 10:08, Kyrill Tkachov wrote:
>>> Hi Mike,
>>>
>>> On 28/05/15 22:15, Mike Stump wrote:
So, the arm memcpy code of aligned data isn’t as good as it can be.
void *memcpy(v
On Sun, 16 Aug 2015, H.J. Lu wrote:
> prepare_call_address in calls.c is the wrong place to handle -fno-plt.
> We shoudn't force function address into register and hope that load
> function address via GOT and indirect call via register will be folded
> into indirect call via GOT, which doesn't al
On Sun, Aug 16, 2015 at 12:24 PM, Alexander Monakov wrote:
> On Sun, 16 Aug 2015, H.J. Lu wrote:
>
>> prepare_call_address in calls.c is the wrong place to handle -fno-plt.
>> We shoudn't force function address into register and hope that load
>> function address via GOT and indirect call via regi
BUILT_IN_SQRT is a bit special in the Fortran front-end, because it’s part of
our math built-ins which map one-to-one to Fortran intrinsics (and get special
treatment for that), but it is only a built-in we call directly in the
front-end when emitting code for NORM2.
I didn’t realize this corne
On Sun, Aug 16, 2015 at 12:39 PM, H.J. Lu wrote:
> On Sun, Aug 16, 2015 at 12:24 PM, Alexander Monakov
> wrote:
>
>>> + if (!TARGET_64BIT
>>> + || (ix86_cmodel == CM_LARGE_PIC
>>> + && DEFAULT_ABI != MS_ABI))
>>> + {
>>> + use_r
While reviewing some code, I noticed that the logic for
pretty-printing 'restrict' qualifiers is likely missing a
statement that sets 'previous'.
OK to commit?
2015-08-l6 Gary Funck
* c-pretty-print.c (pp_c_cv_qualifiers):
Set 'previous' for restrict qualifiers.
Index: c-pre
On Aug 16, 2015, Andreas Schwab wrote:
> On m68k:
> FAIL: gcc.c-torture/execute/20050316-1.c -O0 execution test
> FAIL: gcc.c-torture/execute/20050316-2.c -O0 execution test
> FAIL: gcc.c-torture/execute/20050316-3.c -O0 execution test
> FAIL: gcc.c-torture/execute/simd-4.c -O0 execut
On Aug 16, 2015, Andreas Schwab wrote:
> Alexandre Oliva writes:
>> On Aug 15, 2015, Andreas Schwab wrote:
>>
>>> FAIL: gcc.target/aarch64/target_attr_crypto_ice_1.c (internal compiler
>>> error)
>>
>>> In file included from
>>> /opt/gcc/gcc-20150815/gcc/testsuite/gcc.target/aarch64/target_a
On Fri, 7 Aug 2015, Hurugalawadi, Naveen wrote:
gcc/ChangeLog:
* match.pd (COS (negate @0) : New simplifier.
Please fix ChangeLog so it is well-parenthesized, the committed version is
even worse:
* match.pd (div (coss (op @0) : New simplifier.
What is this "div" a
Hi,
Please find attached the modified patch as per the comments.
Tested the patch on AArch64 and X86 without any regressions.
The other hunks of the earlier patch have been removed as per the earlier
comments due to failure in regressions.
Investigated those issues and found that its because of
Hi Marc Glisse,
Thanks for pointing out the error.
That "div" is not supposed to be there.
Exact pattern is:-
> * match.pd (coss (op @0) : New simplifier.
However, the exact pattern is present in the sources and a typo has
been introduced in the ChangeLog.
Sorry for the mistake.
Thanks,
Hi, all.
I'm pinging this patch: https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00030.html
And adding some more changes to it (they are not complete yet - so they are more
like an RFC).
In this patch I also try to make obstacks use the same block pool as object
pools. This seems rather easy to impl
20 matches
Mail list logo
