Re: Newlib/Cygwin now under GIT
[Somehow I managed to drop newlib from the recipient list. Re-added] On Mar 10 19:19, Corinna Vinschen wrote: On Mar 10 17:03, Joseph Myers wrote: On Tue, 10 Mar 2015, Corinna Vinschen wrote: Hi fellow developers, I'm happy to inform you that the move of Newlib/Cygwin from the src CVS repository to the new, combined GIT repository is now final. I note that this repository includes the include/ directory, in its larger binutils-gdb form rather than the smaller GCC form. How much of this is actually relevant for newlib? Keep in mind that this is a combined repo for newlib and Cygwin. Cygwin needs include/ for its dumper tool, which is a helper to create core files readable by GDB. It includes bfd.h elf/common.h elf/external.h and all files included by those. Mostly it relates to libiberty and object file formats, for use of code that's not included in this repository (which does not include libiberty). If little or none of this code is actually used in newlib, it might make sense to remove the unused files so it's clear they do not need merging from the other repositories. Of course, I have no problems to remove unused files, just not now. I'm still looking for a small problem in the repo, so please no unsolicited pushes for now. The problems in the repo are fixed. If you had a problem accessing the repo in the last couple of minutes, it was me moving the problematic repo out and a repaired repo back into place. Sorry about that. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpWuZvkD6blj.pgp Description: PGP signature
[Bug testsuite/63175] [4.9 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2 basic block vectorized using SLP 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63175 --- Comment #36 from Martin Sebor msebor at gcc dot gnu.org --- Author: msebor Date: Tue Mar 10 21:06:41 2015 New Revision: 221336 URL: https://gcc.gnu.org/viewcvs?rev=221336root=gccview=rev Log: 2015-03-10 Martin Sebor mse...@redhat.com PR testsuite/63175 * gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c (main1): Move checking of results into main to prevent it from getting optimized away. * gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a-pr63175.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a-pr63175.c Modified: branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c
[Bug target/65368] [4.8/4.9/5 Regression]_bzhi_u32 intrinsic generates incorrect code when -O1 or above is specified and index is an immediate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65368 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Tue Mar 10 21:03:21 2015 New Revision: 221335 URL: https://gcc.gnu.org/viewcvs?rev=221335root=gccview=rev Log: PR target/65368 * config/i386/i386.md (bmi2_bzhi_mode3): Removed define_insn, new define_expand. (*bmi2_bzhi_mode3, *bmi2_bzhi_mode3_1): New define_insns. * gcc.target/i386/bmi2-bzhi-2.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/bmi2-bzhi-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog
[Bug c++/65382] New: pointer-to-noexcept-function typealias allowed via using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65382
Bug ID: 65382
Summary: pointer-to-noexcept-function typealias allowed via
using
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vgheorgh at gmail dot com
According to 15.4 Exception specifications [except.spec]/2, the following code
should be rejected,
#include iostream
using fptr = void(*)() noexcept; // should not be accepted
// typedef void (*FPTR)() noexcept; // rejected by the compiler
void f() noexcept
{
std::cout void f() noexcept std::endl;
}
int main()
{
fptr fp = f;
fp();
}
Replacing using with a typedef makes the compiler emit an error, however the
code above compiles just fine, and it shouldn't.
Re: Undefined behavior due to 6.5.16.1p3
On Wed, Mar 11, 2015 at 05:08:16PM +0100, Vincent Lefevre wrote:
On 2015-03-11 14:27:25 +0100, Robbert Krebbers wrote:
But what about long long on 32 bits machines. For example:
union {
long long a;
struct { char b1; long long b2; } b;
} u;
Will GCC perform similar optimizations as for the case of big structs? I
tried to play around with long long in Martin's example, but failed to
trigger unexpected behaviors in GCC.
I've not tried, but how about something like:
struct S { long a, b, c, d; };
union U {
struct S a;
struct { char b1; struct S b2; } b;
};
u.b.b2 = u.a;
or: u.a = u.b.b2;
IMHO, struct S should be large enough to avoid using registers as
a temporary area (just in case...).
There is some PR about it in our bugzilla, and the conclusion is that
it is both invalid (in C only one union member can be active at any time,
we as extension allow type punning through unions etc.)
and we really don't want to support it.
Jakub
[Bug go/64999] s390x libgo test failure in TestMemoryProfiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999 --- Comment #46 from boger at us dot ibm.com --- (In reply to Ian Lance Taylor from comment #45) If we change the PC returned by backtrace_full, and then use that changed PC to look up file/line information, we might get different results. That seems clear. My next question is: when does this matter? There are two ways that we use the result of runtime_callers: either we use the file/line information, or we use the PC. If we use the file/line information, all is well, and there is nothing to discuss. If we use the PC, as in runtime.Callers, then it's true that if we pass that PC back to libbacktrace we may get different file/line information. But, so what? We've already lost the original file/line information anyhow. The idea is that the changed PC will be the same as the PC returned by the gc library. Therefore, we should get approximately the same file/line information as the gc library gets. That is why runtime/pprof/pprof.go in the gc library backs up the PC to the call instruction: because it knows that it has the PC after the call instruction. Let me just respond to this last paragraph for now. If the pc values in gc are always the instruction following the call (or the excepting instruction), and runtime_callers expects it to be that way, and we want gc and gccgo to return the same results, then I don't understand why backtrace_full and backtrace_simple should ever decrement the pc for any platform. There is a brief mention of this in comment 9 -- that we can make use the fact that the pc had been decremented by inspecting it and making use of the fact that is an abnormal pc value; however I don't see anywhere in the libgo code where it does this, and besides, for some platforms after the pc is decremented it is still a normal looking pc so there is no way to know if it had been decremented. Getting the right pc and the right instruction seems more important than preserving some information that is currently not being used and can't be used on all platforms. That means, if the decrement was removed completely from backtrace_full and backtrace_simple then the pc values would be correct for each platform and the line numbers would be determined based on the correct pc. And then we would still need the BackupPC function for those cases where the call instruction was needed as is done in pprof.go and some extra stuff for s390 and s390x for their various call instructions to get the right number of bytes to back up.
[Bug preprocessor/65238] [5 Regression] __has_attribute is not handled properly with -traditional-cpp.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65238 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 35014 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35014action=edit gcc5-pr65238.patch Untested fix.
[Bug other/65384] Intel MPX does not support x32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65384 --- Comment #1 from Matthias Klose doko at gcc dot gnu.org --- patch posted at https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00627.html
[Bug go/64683] FAIL: runtime/pprof -- testing.go:278: The entry did not match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64683 vries at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2015-03-11 Resolution|FIXED |--- Ever confirmed|0 |1 --- Comment #8 from vries at gcc dot gnu.org --- Test fails again (for x86_64, but not with -m32), with similar message: ... --- FAIL: TestMemoryProfiler (2.17s) testing.go:278: The entry did not match: (0|1): (0|2097152) \[1: 2097152\] @ 0x[0-9,a-f x]+ # 0x[0-9,a-f]+ pprof_test\.allocateTransient2M\+0x[0-9,a-f]+ .*/mprof_test.go:30 # 0x[0-9,a-f]+ runtime_pprof_test\.TestMemoryProfiler\+0x[0-9,a-f]+.*/mprof_test.go:65 ...
Re: Newlib/Cygwin now under GIT
On Mar 10 17:03, Joseph Myers wrote: On Tue, 10 Mar 2015, Corinna Vinschen wrote: Hi fellow developers, I'm happy to inform you that the move of Newlib/Cygwin from the src CVS repository to the new, combined GIT repository is now final. I note that this repository includes the include/ directory, in its larger binutils-gdb form rather than the smaller GCC form. How much of this is actually relevant for newlib? Keep in mind that this is a combined repo for newlib and Cygwin. Cygwin needs include/ for its dumper tool, which is a helper to create core files readable by GDB. It includes bfd.h elf/common.h elf/external.h and all files included by those. Mostly it relates to libiberty and object file formats, for use of code that's not included in this repository (which does not include libiberty). If little or none of this code is actually used in newlib, it might make sense to remove the unused files so it's clear they do not need merging from the other repositories. Of course, I have no problems to remove unused files, just not now. I'm still looking for a small problem in the repo, so please no unsolicited pushes for now. (Apart from include/, various shared toplevel files and directories are out of sync between the three repositories - GCC, binutils-gdb, newlib-cygwin - and could do with someone identifying unmerged changes and applying them to the repositories missing them.) This is a common problem. I guess newlib/cygwin got the oldest set and, afaik, the GCC toplevel stuff is kind of the master. It would be nice if we had some automatism in place to keep all former src repos in sync. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp32Rp5q6RAm.pgp Description: PGP signature
Re: [PATCH, PR target/65103, 1/3] Fix cost of PIC register in ix86_address_cost
Hello! Test O2 ref patchedOfast + LTO ref patched 164.gzip12 0 (-100%)39 0 (-100%) 175.vpr 0 0 (-0%) 4 0 (-100%) 176.gcc 141 6 (-96%) 294 10 (-97%) 181.mcf 4 0 (-100%)4 2 (-50%) Do you also have executable sizes at hand? 2015-03-10 Ilya Enkovich ilya.enkov...@intel.com PR target/65103 * config/i386/i386.c (ix86_address_cost): Fix cost of a PIC register. gcc/testsuite/ 2015-03-10 Ilya Enkovich ilya.enkov...@intel.com PR target/65103 * gcc.target/i386/pr65103-1.c: New. LGTM, just a nit below. Otherwise, OK for mainline as a bugfix (but please wait for a day if there are any objections from release managers). + /* Attempt to minimize number of registers in the address. This is now a displaced comment. Please integrate it in the main comment. Thanks, Uros.
Re: [C++ Patch] PR 65370
On 03/10/2015 01:03 PM, Paolo Carlini wrote:
Good question, but we don't have this issue, because for that we emit
anyway:
65370.C:11:36: error: default argument specified in explicit
specialization [-fpermissive]
Cint::C(const CU, bool = false);
nothing changes about that kind of testcase, usual behavior.
Ah. So here we can ignore any template instantiation or specialization,
with a comment that check_explicit_specialization will handle them. But
I suspect that checking the decl itself will be better; I would expect
checking the context to lead you to accept
template class Cint {
template typename U
C(const CU, bool);
};
template typename U Cint::C(const CU, bool = false);
Since here Cint is a specialization of C, but the constructor is not
itself a partial instantiation.
Jason
Re: Fwd: [PATCH]Remve xfail for wrapped target from libstdc++-v3/testsuite/27_io/ios_base/sync_with_stdio/1.cc
On 05/02/15 11:28 +, Renlin Li wrote:
Hi all,
This patch simply remove the target selector. It should pass for all target
which applies.
The comment in the code is not correct. stderr is redirected, not the stdout.
Therefore, the return status which is streamed into stdout should properly
captured even by wrapped target.
The history of this test is curious. Paolo changed the redirect to fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14866 but then a year
later Mark added the support for the unwrapped effective target to
XFAIL this test, adding the incorrect comment ... even though
presumably it wasn't actually failing after Paolo's fix! Maybe Mark
was merging something from a CodeSourcery branch where the test still
failed.
The unwrapped target is used elsewhere in gcc/testsuite so it's
still useful even if we remove it from this libstdc++ test.
Okay for trunk?
OK, thanks.
libstdc++-v3/ChangeLog:
2015-02-03 Renlin Lirenlin...@arm.com
* testsuite/27_io/ios_base/sync_with_stdio/1.cc: Remve xfail for
wrapped target.
diff --git a/libstdc++-v3/testsuite/27_io/ios_base/sync_with_stdio/1.cc
b/libstdc++-v3/testsuite/27_io/ios_base/sync_with_stdio/1.cc
index 6edaef3..1c9fa60 100644
--- a/libstdc++-v3/testsuite/27_io/ios_base/sync_with_stdio/1.cc
+++ b/libstdc++-v3/testsuite/27_io/ios_base/sync_with_stdio/1.cc
@@ -23,12 +23,6 @@
// @require@ %-*.tst
// @diff@ %-*.tst %-*.txt
-// This test fails on platforms using a wrapper, because this test
-// redirects stdout to a file and so the exit status printed by the
-// wrapper is not visibile to DejaGNU. DejaGNU then assumes that the
-// test exited with a non-zero exit status.
-// { dg-do run { xfail { ! unwrapped } } }
-
#include cstdio
#include sstream
#include iostream
[Bug preprocessor/65387] New: cpp -C emits extraneous comment header on every file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65387 Bug ID: 65387 Summary: cpp -C emits extraneous comment header on every file Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: bugs at stellardeath dot org cpp is often (mis)used for non-C files, many Fortran projects for example prefer to run a separate preprocessor step by invoking cpp by hand instead of relying on the built-in preprocessing of the fortran compiler (don't ask why - I don't understand it either). In order not to mess up anything in the non-C file, cpp is usually invoked as cpp -C -P -traditional The -C flag started to make problems in recent versions(?), as this now emits a large comment header on every file: # echo asd | cpp -C -P /* Copyright (C) 1991-2015 Free Software Foundation, Inc. This file is part of the GNU C Library. The GNU C Library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. The GNU C Library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with the GNU C Library; if not, see http://www.gnu.org/licenses/. */ /* This header is separate from features.h so that the compiler can include it implicitly at the start of every compilation. It must not itself include features.h or any other header that includes features.h because the implicit include comes before any feature test macros that may be defined in a source file before it first explicitly includes a system header. GCC knows the name of this header in order to preinclude it. */ /* glibc's intent is to support the IEC 559 math functionality, real and complex. If the GCC (4.9 and later) predefined macros specifying compiler intent are available, use them to determine whether the overall intent is to support these features; otherwise, presume an older compiler has intent to support these features and define these macros by default. */ /* wchar_t uses ISO/IEC 10646 (2nd ed., published 2011-03-15) / Unicode 6.0. */ /* We do not support C11 threads.h. */ asd Would it be too much trouble to not include this extraneous header? Kind regards, Lorenz
Re: SPIR-V and GCC
Hi! On Fri, 6 Mar 2015 15:23:21 + (UTC), BogDan bog_dan...@yahoo.com wrote: This http://www.g-truc.net/post-0714.html great article explans better what SPIR-V is. Note that I don't know anything about SPIR-V, and I'm currently too busy to learn about it, but: I checked them a little bit and I'm afraid it might be a a few problems to create a SPIR-V backend: These look -- at least superficially -- similar to issues we (that is, primarily Bernd, CCed) faced, when creating a Nvidia PTX backend (primarily for offloading use, as part of the OpenACC project we're currently working on). 1. SPIR-V a binary Intermediate Language format but it's still not machine code. It seems gcc backends produces a text machine code, so I think will not be possible to produce SPIR-V a binary format directly from GCC backend. (Not a problem for text-based PTX.) Indeed I don't know if it's feasible to have GCC backends generate output in a binary format -- but then, I don't think this is a show-stopper? I'm assuming that any binary format can be represented in a textual format, and then converted into the desired binary format by an assembler? 2. Because SPIR-V is not a machine format, it doesn't have any registers. Instead it's using IDs for everything [1]. I didn't find a way to create IDs instead of registers in GCC. [1] https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.html#_instructions In the nvptx backend, we currently disable all register allocation, under the assumption that there is an unbounded register file, with the registers having arbitrary names -- does that match the SPIR-V model? 3. SPIR-V supports some non-standard types[2], will it be a problems to support these types in GCC frontend/backend? [2] https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.html#_types Certainly GCC can be taught about non-standard types, but you'll have to see at which stage of the compilation process this is best done. Grüße, Thomas signature.asc Description: PGP signature
[PATCH] Backport ubsan fix to 4.9
I'd like to backport the following patch that suppresses bogus ubsan errors.
I had to tweak the testcase a bit since 4.9 doesn't know -fno-sanitize-recover.
Bootstrapped/regtested on x86_64-linux, ok for 4.9?
2015-03-10 Marek Polacek pola...@redhat.com
Backported from mainline
2014-12-04 Marek Polacek pola...@redhat.com
PR middle-end/56917
* fold-const.c (fold_unary_loc): Perform the negation in A's type
when transforming ~ (A - 1) or ~ (A + -1) to -A.
* c-c++-common/ubsan/pr56917.c: New test.
--- gcc/fold-const.c
+++ gcc/fold-const.c
@@ -8324,9 +8324,14 @@ fold_unary_loc (location_t loc, enum tree_code code,
tree type, tree op0)
integer_onep (TREE_OPERAND (arg0, 1)))
|| (TREE_CODE (arg0) == PLUS_EXPR
integer_all_onesp (TREE_OPERAND (arg0, 1)
- return fold_build1_loc (loc, NEGATE_EXPR, type,
- fold_convert_loc (loc, type,
- TREE_OPERAND (arg0, 0)));
+ {
+ /* Perform the negation in ARG0's type and only then convert
+to TYPE as to avoid introducing undefined behavior. */
+ tree t = fold_build1_loc (loc, NEGATE_EXPR,
+ TREE_TYPE (TREE_OPERAND (arg0, 0)),
+ TREE_OPERAND (arg0, 0));
+ return fold_convert_loc (loc, type, t);
+ }
/* Convert ~(X ^ Y) to ~X ^ Y or X ^ ~Y if ~X or ~Y simplify. */
else if (TREE_CODE (arg0) == BIT_XOR_EXPR
(tem = fold_unary_loc (loc, BIT_NOT_EXPR, type,
--- gcc/testsuite/c-c++-common/ubsan/pr56917.c
+++ gcc/testsuite/c-c++-common/ubsan/pr56917.c
@@ -0,0 +1,43 @@
+/* PR middle-end/56917 */
+/* { dg-do run } */
+/* { dg-options -fsanitize=undefined } */
+
+#include stdio.h
+
+#define INT_MIN (-__INT_MAX__ - 1)
+#define LONG_MIN (-__LONG_MAX__ - 1L)
+#define LLONG_MIN (-__LONG_LONG_MAX__ - 1LL)
+
+int __attribute__ ((noinline,noclone))
+fn1 (unsigned int u)
+{
+ return (-(int) (u - 1U)) - 1;
+}
+
+long __attribute__ ((noinline,noclone))
+fn2 (unsigned long int ul)
+{
+ return (-(long) (ul - 1UL)) - 1L;
+}
+
+long long __attribute__ ((noinline,noclone))
+fn3 (unsigned long long int ull)
+{
+ return (-(long long) (ull - 1ULL)) - 1LL;
+}
+
+int
+main (void)
+{
+ fputs (UBSAN TEST START\n, stderr);
+
+ if (fn1 (__INT_MAX__ + 1U) != INT_MIN
+ || fn2 (__LONG_MAX__ + 1UL) != LONG_MIN
+ || fn3 (__LONG_LONG_MAX__ + 1ULL) != LLONG_MIN)
+__builtin_abort ();
+
+ fputs (UBSAN TEST END\n, stderr);
+ return 0;
+}
+
+/* { dg-output UBSAN TEST START(\n|\r\n|\r)UBSAN TEST END } */
Marek
Re: [PATCH/AARCH64] Add missing definition of crypto instruction on cortex-a57.md
On 11/03/2015 02:11, 박준모 wrote: Hi all, This patch only affect sha2 crypto instruction's order when gcc performs instruction scheduling(rtl-sched1,2). There are no definition for crypto_sha256_fast, crypto_sha256_slow on cortex-a57.md. This makes poor result of instruction scheduling when we use sha2 crypto instructions. This idea already applied on cortex-a53.md. so I think it can apply on GCC5(even we only accepts regression fixes.). Is this ok? The approach makes sense - however please resubmit the patch with a Changelog entry and a proper plain text email so that the patch is archived on the GCC mailing lists. HTML email is bounced from the lists, please only use plain text when submitting patches or writing emails to the GCC mailing lists. regards Ramana Thanks, Junmo Park.
[patch] disable libmpx x32 multilib builds
current trunk fails to build on x86*-linux, when configured for x32 multilibs
because libmpx doesn't support these. Disable them.
ok for the trunk?
* Disable libmpx x32 multilib builds.
--- a/config-ml.in
+++ b/config-ml.in
@@ -102,6 +102,7 @@
Makefile=${ac_file-Makefile}
ml_config_shell=${CONFIG_SHELL-/bin/sh}
ml_realsrcdir=${srcdir}
+ml_srcbase=`basename $ml_realsrcdir`
# Scan all the arguments and set all the ones we need.
@@ -220,6 +221,10 @@
if [ ${dir} = . ]; then
true
else
+# libmpx is not supported on x32
+if [ ${ml_srcbase}-${dir} = libmpx-x32 ]; then
+ continue
+fi
if [ -z ${multidirs} ]; then
multidirs=${dir}
else
[PATCH, TSAN] Fix a crash in ScopedReport::AddThread
Hi Jakub, with my OPC UA Server, I observe a reproducible crash in ScopedReport::AddThread: tctx==NULL in if ((u32)rep_-threads[i]-id == tctx-tid). Apparently, Dmitry has already fixed that in the obvious way. So we should cherry pick these two changes from LLVM: 224508 and 224755 See attachment. Builds cleanly and fixes the problem for me. OK for trunk? Thanks Bernd. patch-tsan-crash.diff Description: Binary data
Re: [PATCH/AARCH64] Add missing definition of crypto instruction on cortex-a57.md
Attached patch as text. 2015-03-11 Junmo Park junmoz.p...@samsung.com * config/arm/cortex-a57.md (cortex_a57_crypto_simple): Add crypto_sha256_fast. (cortex_a57_crypto_complex): Add crypto_sha256_slow. Ok to commit to trunk? OK, Thanks Sebastian. regards Ramana Thanks, Sebastian
[Bug middle-end/65391] unnecessary load of conditionally updated pointer in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65391 --- Comment #3 from Aaron Sawdey acsawdey at linux dot vnet.ibm.com --- I tried applying the patch that Thomas posted for 64616 (https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00272.html) to trunk 221350 but that did not change the generated code for this test case on powerpc64le.
Re: Undefined behavior due to 6.5.16.1p3
On 2015-03-11 17:39:31 +0100, Jakub Jelinek wrote:
On Wed, Mar 11, 2015 at 05:31:01PM +0100, Vincent Lefevre wrote:
(in C only one union member can be active at any time,
we as extension allow type punning through unions etc.)
I disagree that it is an extension. The standard does not say
that one union member can be active at any time.
That is not a standard wording, but what I meant is
6.2.6.1p7 - that when you store some union member other union members take
unspecified values.
Well, the values are unspecified, but the value can sometimes be
deduced from what is stored.
BTW, the C11 draft I have says:
When a value is stored in a member of an object of union type, the
bytes of the object representation that do not correspond to that
member but do correspond to other members take unspecified values.
Note the that do not correspond to that member but do correspond to
other members.
This means that on a machine where an int takes 4 bytes, if one has:
union { unsigned char a[8]; int b; } u = { .a = { 0 } };
u.b = 1;
Then the last 4 bytes of u.a take unspecified values. But the first
4 bytes depend on the representation of the int 1, and if this
representation is well-specified by the implementation (e.g. no
padding bits...), which can sometimes be deduced, then the first
4 bytes of u.a are known and one can access them via u.a.
--
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: [PATCH] PR target/65242, Fix powerpc abort in gen_add2_insn
On 03/11/15 08:44, David Edelsohn wrote: On Mon, Mar 9, 2015 at 7:30 PM, Michael Meissner meiss...@linux.vnet.ibm.com wrote: This bug was one I unfortunately introduced with the -mupper-regs support. If the reload pass needed to reload a PLUS operation (for example, due to using odd address with the LD/STD instructions), it would go through all of the registers you could load DImode into, and see if it is a preferred register class. This lead the compiler to believe it could do integer arithmetic in the floating point registers. This patch fixes the problem, by not allowing PLUS to be reloaded into FPR registers. I have done bootstraps and make checks on both a big endian Power7 and a little endian Power8 system, and there were no regressions. Is the patch ok to apply? I do not believe it needs to be back ported to GCC 4.9 since the -mupper-regs changes are not installed currently on that branch. [gcc] 2015-03-09 Michael Meissner meiss...@linux.vnet.ibm.com PR target/65242 * config/rs6000/rs6000.c (rs6000_preferred_reload_class): Do not allow reloads of PLUS in floating point/VSX registers. [gcc/testsuite] 2015-03-09 Michael Meissner meiss...@linux.vnet.ibm.com PR target/65242 * g++.dg/pr65242.C: New test. This is okay. What about Jeff Law's Bugzilla comment #6 to change ?m to !m in the movdi_internal64 pattern? That also seems reasonable. It doesn't matter much to me either way as long as it gets fixed :-) Avoiding floating point registers via preferred reload class is a valid approach. My only concern then would be cases where we have similar looking arithmetic and even though we no longer prefer the FP classes, we still end up selecting that problematical alternative -- say perhaps because the pseudos in question have many other uses where FP regs make sense. I know we could get into those kind of situations on the PA because of the weird way in which integer multiplies were implemented (FP unit, using FP regs) -- which could occur even when using '?' to disparage those alternatives. I'm not familiar enough with PPC implementations to know if we can get into that same situation with that port. Jeff
[Bug tree-optimization/62173] [5/6 Regression] 64bit Arch can't ivopt while 32bit Arch can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|5.0 |6.0 Summary|[5 Regression] 64bit Arch |[5/6 Regression] 64bit Arch |can't ivopt while 32bit |can't ivopt while 32bit |Arch can|Arch can --- Comment #37 from Jakub Jelinek jakub at gcc dot gnu.org --- Ok.
[Bug tree-optimization/64705] Bad code generation of sieve on x86-64 because of too aggressive IV optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64705 --- Comment #7 from Vladimir Makarov vmakarov at gcc dot gnu.org --- (In reply to amker from comment #6) Since it works on gcc 3.4, so I consider this as a regression and applied the patch. Should be fixed now. Hi Vlad, could you please help me verify that the original benchmark is fixed too? Thanks very much! Yes, it was fixed. Thanks for working on this.
Re: [PATCH/AARCH64] Add missing definition of crypto instruction on cortex-a57.md
James Greenhalgh wrote: On Wed, Mar 11, 2015 at 04:24:07PM +, Ramana Radhakrishnan wrote: Attached patch as text. 2015-03-11 Junmo Park junmoz.p...@samsung.com * config/arm/cortex-a57.md (cortex_a57_crypto_simple): Add crypto_sha256_fast. (cortex_a57_crypto_complex): Add crypto_sha256_slow. Ok to commit to trunk? OK, Thanks Sebastian. As far as I can see, this patch still hasn't made it to gcc-patches. Could you please send a copy (or a commit revision number), for those of us interested? Committed r221349. Sebastian
[Bug tree-optimization/62173] [5 Regression] 64bit Arch can't ivopt while 32bit Arch can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173 --- Comment #36 from Jiong Wang jiwang at gcc dot gnu.org --- and for rtl level improvement, need to enable DF_DU_CHAIN build on top of existing DF_UD_CHAIN (may cause extra compile time resource consumption). one draft patch is here, no feedback yet. https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00736.html as both tree and rtl fix contain generic code modifications, I think it's better to defer it to next stage-1 given the issue itself is enhancement not bug.
Re: Undefined behavior due to 6.5.16.1p3
BTW, the following is forbidden (and makes no sense), but is accepted
by GCC without a warning:
int foo (void)
{
union { char a[8]; int b; } u = { .a = { 0 }, .b = 1 };
return u.b;
}
--
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369 Thomas Preud'homme thopre01 at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||thopre01 at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |thopre01 at gcc dot gnu.org
[Bug fortran/65397] [Coarrays][OOP] ICE in resolve_ordinary_assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65397 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- The problem is in resolve_ordinary_assign (resolve.c): 9428 /* Assign the 'data' of a class object to a derived type. */ 9429 if (lhs-ts.type == BT_DERIVED 9430 rhs-ts.type == BT_CLASS) 9431gfc_add_data_component (rhs); But the RHS is: (gdb) p rhs-expr_type $2 = EXPR_FUNCTION (gdb) p rhs-symtree-name $3 = 0x71f45f90 _F.caf_get And adding ._data fails in class.c as: 211 gfc_symbol *derived = e-symtree-n.sym-ts.u.derived; (gdb) p e-symtree-n.sym-ts.u.derived $4 = (gfc_symbol *) 0x0
[Bug testsuite/65394] r221327 causes gcc.dg/ipa/pr63569.c to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65394 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-12 Component|ipa |testsuite Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. Testsuite issue I think.
[Bug c++/65398] New: [C++11] GCC rejects constexpr variable definitions with valid initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65398
Bug ID: 65398
Summary: [C++11] GCC rejects constexpr variable definitions
with valid initialization
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Created attachment 35017
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35017action=edit
g++ -v
The sample code below should be compiled successfully but gcc 5.0 rejects it.
= sample code =
constexpr char s[] = abc;
constexpr char c = *(s[0] + 1);
int main() {}
= sample code =
cf. http://melpon.org/wandbox/permlink/jRbgl6YCTXHSspI9
Note that gcc 4.9.2 accepts it.
cf. http://melpon.org/wandbox/permlink/bwuaSYUvgwAjRTfo
Note also that gcc 5.0 accepts if s[0] is replaced with s.
= sample code =
constexpr char s[] = abc;
constexpr char c = *(s + 1);
int main() {}
= sample code =
cf. http://melpon.org/wandbox/permlink/sy0THyfnSq6XCT0L
[Bug target/64342] [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64342 Bug 64342 depends on bug 64895, which changed state. Bug 64895 Summary: RA picks the wrong register for -fipa-ra https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64895 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/65397] [Coarrays][OOP] ICE in resolve_ordinary_assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65397 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- See also gfortran.dg/coarray_38.f90 of https://gcc.gnu.org/ml/fortran/2015-03/msg00057.html (assuming it will eventually appear on the server)
[Bug fortran/65397] New: [Coarrays][OOP] ICE in resolve_ordinary_assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65397 Bug ID: 65397 Summary: [Coarrays][OOP] ICE in resolve_ordinary_assign Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org The following valid program ICEs with -fcoarray=lib in resolve_ordinary_assign. subroutine five implicit none type t integer, pointer :: a integer :: b end type t type t2 class(t), allocatable :: caf2[:] end type t2 class(t), save, allocatable :: caf[:] type(t) :: x type(t2) :: y x = caf[4] ! ICE x = y%caf2[5] ! ICE end subroutine five
[Bug sanitizer/65400] New: tsan mis-compiles inlineable C functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65400 Bug ID: 65400 Summary: tsan mis-compiles inlineable C functions Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: bernd.edlinger at hotmail dot de CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Created attachment 35018 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35018action=edit stripped down test case Hi, I am not sure when this started, probably in february where I was busy with other tasks, but current trunk miscompiles numerous simple C functions if optimizations are enabled. I isolated one example in the OPC UA ANSI-C stack, and crated a small test case from it. It mis-compiles with these set of options: gcc -O2 -fsanitize=thread,undefined -c opcua_string.c the problem is here: 04b0 OpcUa_String_Clear: 4b0: 53 push %rbx 4b1: 48 89 fbmov%rdi,%rbx 4b4: 48 8b 7c 24 08 mov0x8(%rsp),%rdi 4b9: e8 00 00 00 00 callq 4be OpcUa_String_Clear+0xe 4ba: R_X86_64_PC32 __tsan_func_entry-0x4 4be: 48 85 dbtest %rbx,%rbx 4c1: 74 1d je 4e0 OpcUa_String_Clear+0x30 4c3: 48 89 dfmov%rbx,%rdi 4c6: e8 00 00 00 00 callq 4cb OpcUa_String_Clear+0x1b 4c7: R_X86_64_PC32 __tsan_read1-0x4 4cb: 80 3b 00cmpb $0x0,(%rbx) 4ce: 75 10 jne4e0 OpcUa_String_Clear+0x30 4d0: 48 89 dfmov%rbx,%rdi 4d3: 5b pop%rbx 4d4: e9 27 fb ff ff jmpq 0 OpcUa_String_Clear.part.0 4d9: 0f 1f 80 00 00 00 00nopl 0x0(%rax) 4e0: 5b pop%rbx 4e1: e9 00 00 00 00 jmpq 4e6 OpcUa_String_Clear+0x36 4e2: R_X86_64_PC32 __tsan_func_exit-0x4 a call to __tsan_func_exit is missing before jmpq OpcUa_String_Clear.part.0 note that OpcUa_String_Clear.part.0 also call __tsan_func_entry thus the call stack is completely scrambled: OpcUa_String_Clear.part.0: 0: 55 push %rbp 1: 53 push %rbx 2: 48 89 fbmov%rdi,%rbx 5: 48 83 ec 08 sub$0x8,%rsp 9: 48 8b 7c 24 18 mov0x18(%rsp),%rdi e: e8 00 00 00 00 callq 13 OpcUa_String_Clear.part.0+0x13 f: R_X86_64_PC32__tsan_func_entry-0x4 The with other optimization levels or without -fsanitize=undefined, this example compiles correctly, but some other function start to have problems.
[Bug tree-optimization/65391] missed store motion for conditionally updated pointer in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65391 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization CC||rguenth at gcc dot gnu.org Component|middle-end |tree-optimization Summary|unnecessary load of |missed store motion for |conditionally updated |conditionally updated |pointer in loop |pointer in loop --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- The issue is that invariant/store motion doesn't see the unconditional store to *o_ptr before the loop and thus thinks that the conditional one may trap. LIM doesn't consider stores/loads in blocks that are post-dominated by the loop header to alter that loops effectively accessed set of references. I think considering only the loop preheader is good enough - but we also do not analyze memory references in non-loop areas (loop preheaders would need to be added here as well).
[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369 --- Comment #11 from Markus Trippelsdorf trippels at gcc dot gnu.org --- 0x1a00 +1024: bl 0x15b0 _init+112 0x1a04 +1028: ld r2,24(r1) 0x1a08 +1032: lwz r9,224(r1) 0x1a0c +1036: addir3,r1,200 0x1a10 +1040: addir4,r1,380 0x1a14 +1044: stw r9,380(r1) 0x1a18 +1048: lwz r9,228(r1) 0x1a1c +1052: stw r9,384(r1) 0x1a20 +1056: lwz r9,232(r1) 0x1a24 +1060: stw r9,388(r1) 0x1a28 +1064: lwz r9,236(r1) 0x1a2c +1068: stw r9,392(r1) 0x1a30 +1072: lwz r9,240(r1) 0x1a34 +1076: stw r9,396(r1) 0x1a38 +1080: lwz r9,244(r1) 0x1a3c +1084: stw r9,400(r1) 0x1a40 +1088: lwz r9,248(r1) 0x1a44 +1092: stw r9,404(r1) 0x1a48 +1096: lwz r9,252(r1) 0x1a4c +1100: stw r9,408(r1) 0x1a50 +1104: lwz r9,256(r1) 0x1a54 +1108: stw r9,412(r1) 0x1a58 +1112: lwz r9,260(r1) 0x1a5c +1116: stw r9,416(r1) 0x1a60 +1120: lwz r9,264(r1) 0x1a64 +1124: stw r9,420(r1) 0x1a68 +1128: lwz r9,268(r1) 0x1a6c +1132: stw r9,424(r1) 0x1a70 +1136: lwz r9,272(r1) 0x1a74 +1140: stw r9,428(r1) 0x1a78 +1144: lwz r9,276(r1) 0x1a7c +1148: stw r9,432(r1) 0x1a80 +1152: lwz r9,280(r1) 0x1a84 +1156: stw r9,436(r1) 0x1a88 +1160: lwz r9,284(r1) 0x1a8c +1164: stw r9,440(r1) 0x1a90 +1168: bl 0x1cb0 md4_transform 0x1a94 +1172: li r3,0 0x1a98 +1176: b 0x1784 main+388 0x1a9c +1180: bl 0x15e0 _init+160 0x1aa0 +1184: ld r2,24(r1) ---Type return to continue, or q return to quit--- 0x1aa4 +1188: cmpdi cr7,r3,0 0x1aa8 +1192: beq cr7,0x1988 main+904 0x1aac +1196: li r3,1 0x1ab0 +1200: b 0x1998 main+920 0x1ab4 +1204: bl 0x15f0 _init+176 = 0x1ab8 +1208: ld r2,24(r1) 0x1abc +1212: .long 0x0 0x1ac0 +1216: .long 0x100 0x1ac4 +1220: .long 0x1280
[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369 Thomas Preud'homme thopre01 at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed|2015-03-10 00:00:00 |2015-03-12 --- Comment #10 from Thomas Preud'homme thopre01 at gcc dot gnu.org --- (In reply to Martin Sebor from comment #8) Created attachment 35016 [details] Test case for nettle md4 test failure. The attached test case reduced from Nettle 3.0 test 7 in testsuite/md4-test.c reproduces the suspected gcc 5.0 incorrect code generation on ppc64le. Compile with -O3 and run and observe a SIGABRT. I don't have access to such a machine right now so I would appreciate if somebody can give me the instruction that causes the abort. Thanks
[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW CC||thomas.preudhomme at arm dot com, ||trippels at gcc dot gnu.org --- Comment #9 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Started with r210843.
[Bug rtl-optimization/64895] RA picks the wrong register for -fipa-ra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64895 vries at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |vries at gcc dot gnu.org --- Comment #8 from vries at gcc dot gnu.org --- Author: vries Date: Thu Mar 12 06:59:34 2015 New Revision: 221372 URL: https://gcc.gnu.org/viewcvs?rev=221372root=gccview=rev Log: Use actual_call_used_reg_set to find conflicting regs 2015-03-12 Tom de Vries t...@codesourcery.com * lra-lives.c (check_pseudos_live_through_calls): Use actual_call_used_reg_set instead of call_used_reg_set, if available. Modified: trunk/gcc/ChangeLog trunk/gcc/lra-lives.c
[Bug testsuite/65394] [5 Regression] r221327 causes gcc.dg/ipa/pr63569.c to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65394 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |5.0 Summary|r221327 causes |[5 Regression] r221327 |gcc.dg/ipa/pr63569.c to |causes gcc.dg/ipa/pr63569.c |fail|to fail
[Bug c++/65396] Function template default template arguments not merged
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65396 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-12 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Presumably this rule was never implemented for function templates when they started being allowed default template arguments.
[Bug c++/65399] New: error: invalid use of non-static data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65399
Bug ID: 65399
Summary: error: invalid use of non-static data member
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
I've just had a go at compiling gcc trunk with clang.
It says
/usr/bin/../lib/gcc/x86_64-redhat-linux/5.0.0/../../../../include/c++/5.0.0/stdexcept:83:28:
error: invalid use of non-static data member '_M_s'
It seems for the attached code, clang and gcc don't agree.
typedef unsigned long size_t;
struct __sso_string
{
struct __str
{
const char* _M_p;
size_t _M_string_length;
char _M_local_buf[16];
};
union {
__str _M_s;
char _M_bytes[sizeof(_M_s)];
};
};
[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369 --- Comment #12 from Thomas Preud'homme thopre01 at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #11) 0x1a00 +1024: bl 0x15b0 _init+112 0x1a04 +1028: ld r2,24(r1) 0x1a08 +1032: lwz r9,224(r1) 0x1a0c +1036: addir3,r1,200 0x1a10 +1040: addir4,r1,380 0x1a14 +1044: stw r9,380(r1) 0x1a18 +1048: lwz r9,228(r1) 0x1a1c +1052: stw r9,384(r1) 0x1a20 +1056: lwz r9,232(r1) 0x1a24 +1060: stw r9,388(r1) 0x1a28 +1064: lwz r9,236(r1) 0x1a2c +1068: stw r9,392(r1) 0x1a30 +1072: lwz r9,240(r1) 0x1a34 +1076: stw r9,396(r1) 0x1a38 +1080: lwz r9,244(r1) 0x1a3c +1084: stw r9,400(r1) 0x1a40 +1088: lwz r9,248(r1) 0x1a44 +1092: stw r9,404(r1) 0x1a48 +1096: lwz r9,252(r1) 0x1a4c +1100: stw r9,408(r1) 0x1a50 +1104: lwz r9,256(r1) 0x1a54 +1108: stw r9,412(r1) 0x1a58 +1112: lwz r9,260(r1) 0x1a5c +1116: stw r9,416(r1) 0x1a60 +1120: lwz r9,264(r1) 0x1a64 +1124: stw r9,420(r1) 0x1a68 +1128: lwz r9,268(r1) 0x1a6c +1132: stw r9,424(r1) 0x1a70 +1136: lwz r9,272(r1) 0x1a74 +1140: stw r9,428(r1) 0x1a78 +1144: lwz r9,276(r1) 0x1a7c +1148: stw r9,432(r1) 0x1a80 +1152: lwz r9,280(r1) 0x1a84 +1156: stw r9,436(r1) 0x1a88 +1160: lwz r9,284(r1) 0x1a8c +1164: stw r9,440(r1) 0x1a90 +1168: bl 0x1cb0 md4_transform 0x1a94 +1172: li r3,0 0x1a98 +1176: b 0x1784 main+388 0x1a9c +1180: bl 0x15e0 _init+160 0x1aa0 +1184: ld r2,24(r1) ---Type return to continue, or q return to quit--- 0x1aa4 +1188: cmpdi cr7,r3,0 0x1aa8 +1192: beq cr7,0x1988 main+904 0x1aac +1196: li r3,1 0x1ab0 +1200: b 0x1998 main+920 0x1ab4 +1204: bl 0x15f0 _init+176 = 0x1ab8 +1208: ld r2,24(r1) 0x1abc +1212: .long 0x0 0x1ac0 +1216: .long 0x100 0x1ac4 +1220: .long 0x1280 Alright, so the last 8 bytes of buffer and digest differ. I'll unwind this tomorrow. Thanks!
[CHKP, PATCH] Fix instrumented indirect calls with propagated pointers
Hi,
Instrumented function pointer may be propagated into not instrumented indirect
call and vice versa. It requires additional call modifications (either remove
bounds or change callee). Bootstrapped and tested on x86_64-unknown-linux-gnu.
OK for trunk?
Thanks,
Ilya
--
gcc/
2015-03-12 Ilya Enkovich ilya.enkov...@intel.com
* cgraph.c (cgraph_edge::redirect_call_stmt_to_callee): Add
redirection for instrumented calls.
* tree-chkp.h (chkp_copy_call_skip_bounds): New.
(chkp_redirect_edge): New.
* tree-chkp.c (chkp_copy_call_skip_bounds): New.
(chkp_redirect_edge): New.
gcc/testsuite/
2015-03-12 Ilya Enkovich ilya.enkov...@intel.com
* gcc.target/i386/mpx/chkp-fix-calls-1.c: New.
* gcc.target/i386/mpx/chkp-fix-calls-2.c: New.
diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index 5ca1901..a0b0465 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -1278,14 +1278,25 @@ cgraph_edge::redirect_call_stmt_to_callee (void)
{
cgraph_edge *e = this;
- tree decl = gimple_call_fndecl (e-call_stmt);
- tree lhs = gimple_call_lhs (e-call_stmt);
+ tree decl;
+ tree lhs;
gcall *new_stmt;
gimple_stmt_iterator gsi;
+ bool skip_bounds = false;
#ifdef ENABLE_CHECKING
cgraph_node *node;
#endif
+ /* We might propagate instrumented function pointer into
+ not instrumented function and vice versa. In such a
+ case we need to either fix function declaration or
+ remove bounds from call statement. */
+ if (callee)
+skip_bounds = chkp_redirect_edge (e);
+
+ decl = gimple_call_fndecl (e-call_stmt);
+ lhs = gimple_call_lhs (e-call_stmt);
+
if (e-speculative)
{
cgraph_edge *e2;
@@ -1391,7 +1402,8 @@ cgraph_edge::redirect_call_stmt_to_callee (void)
}
if (e-indirect_unknown_callee
- || decl == e-callee-decl)
+ || (decl == e-callee-decl
+ !skip_bounds))
return e-call_stmt;
#ifdef ENABLE_CHECKING
@@ -1416,13 +1428,19 @@ cgraph_edge::redirect_call_stmt_to_callee (void)
}
}
- if (e-callee-clone.combined_args_to_skip)
+ if (e-callee-clone.combined_args_to_skip
+ || skip_bounds)
{
int lp_nr;
- new_stmt
- = gimple_call_copy_skip_args (e-call_stmt,
- e-callee-clone.combined_args_to_skip);
+ new_stmt = e-call_stmt;
+ if (e-callee-clone.combined_args_to_skip)
+ new_stmt
+ = gimple_call_copy_skip_args (new_stmt,
+ e-callee-clone.combined_args_to_skip);
+ if (skip_bounds)
+ new_stmt = chkp_copy_call_skip_bounds (new_stmt);
+
gimple_call_set_fndecl (new_stmt, e-callee-decl);
gimple_call_set_fntype (new_stmt, gimple_call_fntype (e-call_stmt));
diff --git a/gcc/testsuite/gcc.target/i386/mpx/chkp-fix-calls-1.c
b/gcc/testsuite/gcc.target/i386/mpx/chkp-fix-calls-1.c
new file mode 100644
index 000..cb4d229
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/mpx/chkp-fix-calls-1.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -fcheck-pointer-bounds -mmpx } */
+
+#include math.h
+
+double
+test1 (double x, double y, double (*fn)(double, double))
+{
+ return fn (x, y);
+}
+
+double
+test2 (double x, double y)
+{
+ return test1 (x, y, copysign);
+}
diff --git a/gcc/testsuite/gcc.target/i386/mpx/chkp-fix-calls-2.c
b/gcc/testsuite/gcc.target/i386/mpx/chkp-fix-calls-2.c
new file mode 100644
index 000..951e7de
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/mpx/chkp-fix-calls-2.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options -O3 -fcheck-pointer-bounds -mmpx -fno-inline } */
+
+#include math.h
+
+double
+test1 (double x, double y, double (*fn)(double, double))
+{
+ return fn (x, y);
+}
+
+double
+test2 (double x, double y)
+{
+ return test1 (x, y, copysign);
+}
diff --git a/gcc/tree-chkp.c b/gcc/tree-chkp.c
index d2df4ba..2d2090f 100644
--- a/gcc/tree-chkp.c
+++ b/gcc/tree-chkp.c
@@ -500,6 +500,62 @@ chkp_expand_bounds_reset_for_mem (tree mem, tree ptr)
expand_normal (bndstx);
}
+/* Build a GIMPLE_CALL identical to CALL but skipping bounds
+ arguments. */
+
+gcall *
+chkp_copy_call_skip_bounds (gcall *call)
+{
+ bitmap bounds;
+ unsigned i;
+
+ bitmap_obstack_initialize (NULL);
+ bounds = BITMAP_ALLOC (NULL);
+
+ for (i = 0; i gimple_call_num_args (call); i++)
+if (POINTER_BOUNDS_P (gimple_call_arg (call, i)))
+ bitmap_set_bit (bounds, i);
+
+ call = gimple_call_copy_skip_args (call, bounds);
+ gimple_call_set_with_bounds (call, false);
+
+ BITMAP_FREE (bounds);
+ bitmap_obstack_release (NULL);
+
+ return call;
+}
+
+/* Redirect edge E to the correct node according to call_stmt.
+ Return 1 if bounds removal from call_stmt should be done
+ instead of redirection. */
+
+bool
+chkp_redirect_edge (cgraph_edge *e)
+{
+ bool instrumented = false;
+
+ if (e-callee-instrumentation_clone
+ || chkp_function_instrumented_p (e-callee-decl))
+instrumented =
[Bug other/65384] Intel MPX does not support x32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65384 --- Comment #2 from ienkovich at gcc dot gnu.org --- Author: ienkovich Date: Thu Mar 12 08:58:08 2015 New Revision: 221378 URL: https://gcc.gnu.org/viewcvs?rev=221378root=gccview=rev Log: libmpx/ PR other/65384 * configure.ac: Fix x32 test. * configure: Regenerate. Modified: trunk/libmpx/ChangeLog trunk/libmpx/configure trunk/libmpx/configure.ac
Re: [PATCH, CHKP, PR target/65044] Restrict pointer bounds checker with Sanitizer
2015-03-12 12:02 GMT+03:00 Jakub Jelinek ja...@redhat.com:
On Thu, Mar 12, 2015 at 11:51:51AM +0300, Ilya Enkovich wrote:
On 09 Mar 15:51, Jakub Jelinek wrote:
On Mon, Mar 02, 2015 at 01:25:43PM +0300, Ilya Enkovich wrote:
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -1376,6 +1376,11 @@ process_options (void)
{
if (targetm.chkp_bound_mode () == VOIDmode)
error (-fcheck-pointer-bounds is not supported for this
target);
+
+ if (flag_sanitize SANITIZE_ADDRESS)
+ error (-fcheck-pointer-bounds is not supported with Address
Sanitizer);
+
+ flag_check_pointer_bounds = 0;
}
Doesn't this disable -fcheck-pointer-bounds always?
I'd expect you want to clear flag_check_pointer_bounds only if you issued
one of the two errors...
Jakub
Whoops! Here is a less destructive version.
Ok for trunk. Did the old version pass make check? If so, perhaps you want
to add
(incrementally) some test that would actually verify that
-fcheck-pointer-bounds does what it should do (e.g. by scanning tree dumps
etc.).
Thanks! I sent previous version before make check. There are several
chkp tests which would fail.
Ilya
Jakub
[PING^2] [PATCH] [AArch64, NEON] Improve vmulX intrinsics
Hi,
This is a ping for: https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00775.html
Regtested with aarch64-linux-gnu on QEMU.
This patch has no regressions for aarch64_be-linux-gnu big-endian target too.
OK for the trunk? Thanks.
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 219845)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,38 @@
+2014-12-11 Felix Yang felix.y...@huawei.com
+ Jiji Jiang jiangj...@huawei.com
+
+ * config/aarch64/aarch64-simd.md (aarch64_mul_nmode,
+ aarch64_sumull_nmode, aarch64_sumullmode,
+ aarch64_simd_sumull2_nmode, aarch64_sumull2_nmode,
+ aarch64_sumull_lanemode, aarch64_sumull2_lanemode_internal,
+ aarch64_sumull_laneqmode, aarch64_sumull2_laneqmode_internal,
+ aarch64_smull2_lanemode, aarch64_umull2_lanemode,
+ aarch64_smull2_laneqmode, aarch64_umull2_laneqmode,
+ aarch64_fmulxmode, aarch64_fmulxmode, aarch64_fmulx_lanemode,
+ aarch64_pmull2v16qi, aarch64_pmullv8qi): New patterns.
+ * config/aarch64/aarch64-simd-builtins.def (vec_widen_smult_hi_,
+ vec_widen_umult_hi_, umull, smull, smull_n, umull_n, mul_n, smull2_n,
+ umull2_n, smull_lane, umull_lane, smull_laneq, umull_laneq, pmull,
+ umull2_lane, smull2_laneq, umull2_laneq, fmulx, fmulx_lane, pmull2,
+ smull2_lane): New builtins.
+ * config/aarch64/arm_neon.h (vmul_n_f32, vmul_n_s16, vmul_n_s32,
+ vmul_n_u16, vmul_n_u32, vmulq_n_f32, vmulq_n_f64, vmulq_n_s16,
+ vmulq_n_s32, vmulq_n_u16, vmulq_n_u32, vmull_high_lane_s16,
+ vmull_high_lane_s32, vmull_high_lane_u16, vmull_high_lane_u32,
+ vmull_high_laneq_s16, vmull_high_laneq_s32, vmull_high_laneq_u16,
+ vmull_high_laneq_u32, vmull_high_n_s16, vmull_high_n_s32,
+ vmull_high_n_u16, vmull_high_n_u32, vmull_high_p8, vmull_high_s8,
+ vmull_high_s16, vmull_high_s32, vmull_high_u8, vmull_high_u16,
+ vmull_high_u32, vmull_lane_s16, vmull_lane_s32, vmull_lane_u16,
+ vmull_lane_u32, vmull_laneq_s16, vmull_laneq_s32, vmull_laneq_u16,
+ vmull_laneq_u32, vmull_n_s16, vmull_n_s32, vmull_n_u16, vmull_n_u32,
+ vmull_p8, vmull_s8, vmull_s16, vmull_s32, vmull_u8, vmull_u16,
+ vmull_u32, vmulx_f32, vmulx_lane_f32, vmulxd_f64, vmulxq_f32,
+ vmulxq_f64, vmulxq_lane_f32, vmulxq_lane_f64, vmulxs_f32): Rewrite
+ using builtin functions.
+ * config/aarch64/iterators.md (UNSPEC_FMULX, UNSPEC_FMULX_LANE,
+ VDQF_Q): New unspec and int iterator.
+
2015-01-19 Jiong Wang jiong.w...@arm.com
Andrew Pinski apin...@cavium.com
Index: gcc/config/aarch64/arm_neon.h
===
--- gcc/config/aarch64/arm_neon.h (revision 219845)
+++ gcc/config/aarch64/arm_neon.h (working copy)
@@ -7580,671 +7580,6 @@ vmovn_u64 (uint64x2_t a)
return result;
}
-__extension__ static __inline float32x2_t __attribute__ ((__always_inline__))
-vmul_n_f32 (float32x2_t a, float32_t b)
-{
- float32x2_t result;
- __asm__ (fmul %0.2s,%1.2s,%2.s[0]
- : =w(result)
- : w(a), w(b)
- : /* No clobbers */);
- return result;
-}
-
-__extension__ static __inline int16x4_t __attribute__ ((__always_inline__))
-vmul_n_s16 (int16x4_t a, int16_t b)
-{
- int16x4_t result;
- __asm__ (mul %0.4h,%1.4h,%2.h[0]
- : =w(result)
- : w(a), x(b)
- : /* No clobbers */);
- return result;
-}
-
-__extension__ static __inline int32x2_t __attribute__ ((__always_inline__))
-vmul_n_s32 (int32x2_t a, int32_t b)
-{
- int32x2_t result;
- __asm__ (mul %0.2s,%1.2s,%2.s[0]
- : =w(result)
- : w(a), w(b)
- : /* No clobbers */);
- return result;
-}
-
-__extension__ static __inline uint16x4_t __attribute__ ((__always_inline__))
-vmul_n_u16 (uint16x4_t a, uint16_t b)
-{
- uint16x4_t result;
- __asm__ (mul %0.4h,%1.4h,%2.h[0]
- : =w(result)
- : w(a), x(b)
- : /* No clobbers */);
- return result;
-}
-
-__extension__ static __inline uint32x2_t __attribute__ ((__always_inline__))
-vmul_n_u32 (uint32x2_t a, uint32_t b)
-{
- uint32x2_t result;
- __asm__ (mul %0.2s,%1.2s,%2.s[0]
- : =w(result)
- : w(a), w(b)
- : /* No clobbers */);
- return result;
-}
-
-#define vmull_high_lane_s16(a, b, c)\
- __extension__ \
-({ \
- int16x4_t b_ = (b); \
- int16x8_t a_ = (a); \
- int32x4_t result;\
- __asm__ (smull2 %0.4s, %1.8h, %2.h[%3] \
-: =w(result) \
-:
[Bug target/65044] ICE: SIGSEGV in contains_struct_check with -fsanitize=address -fcheck-pointer-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65044 --- Comment #2 from ienkovich at gcc dot gnu.org --- Author: ienkovich Date: Thu Mar 12 09:23:06 2015 New Revision: 221379 URL: https://gcc.gnu.org/viewcvs?rev=221379root=gccview=rev Log: gcc/ PR target/65044 * toplev.c (process_options): Restrict Pointer Bounds Checker usage with Address Sanitizer. gcc/testsuite/ PR target/65044 * gcc.target/i386/pr65044.c: New. Added: trunk/gcc/testsuite/gcc.target/i386/pr65044.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/toplev.c
[Bug target/65103] [i386] GOTOFF relocation is not propagated into address expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65103 --- Comment #1 from ienkovich at gcc dot gnu.org --- Author: ienkovich Date: Thu Mar 12 09:53:36 2015 New Revision: 221380 URL: https://gcc.gnu.org/viewcvs?rev=221380root=gccview=rev Log: gcc/ PR target/65103 * config/i386/i386.c (ix86_address_cost): Fix cost of a PIC register. gcc/testsuite/ PR target/65103 * gcc.target/i386/pr65103-1.c: New. Added: trunk/gcc/testsuite/gcc.target/i386/pr65103-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/65388] Wrong comparison in same_succ_def::equal() tree-ssa-tail-merge.c:590
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65388 --- Comment #8 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Thu Mar 12 08:34:00 2015 New Revision: 221376 URL: https://gcc.gnu.org/viewcvs?rev=221376root=gccview=rev Log: PR tree-optimization/65388 Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/tree-ssa-tail-merge.c --- Comment #9 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Thu Mar 12 08:31:36 2015 New Revision: 221375 URL: https://gcc.gnu.org/viewcvs?rev=221375root=gccview=rev Log: PR tree-optimization/65388 * tree-ssa-tail-merge.c (same_succ_def::equal): Fix typo in comparison. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/tree-ssa-tail-merge.c
Re: Offloading GSOC 2015
Hi Thomas, How can i progress about giving official proposal? Which topics are GCC interested in? So far, i have been tried to influence the evolution of the omp 4.0 accelerator model. Sum up of my small achievements until now - Using Shared Memory in a efficient way --- I allowed array privatization for private/firstprivate clause of teams and distribute directives --- But it is not possible to use private/firstprivate for big arrays. --- That's why I added dist_private([CHUNK] var-list) and dist_firstprive([CHUNK] var-list) clause in order to use shared memory for big arrays. briefly it is not putting all array into shared memory. it is putting chunk of array into shared memory. and each block is dealing with own chunk. --- I added dist_lastprivate([CHUNK] var-list). Basically lastprivate is not exist according to omp 4.0 standards, since there is no way to do synchronization among GPU Blocks. But i took off this clause doesn't need sync because it is using CHUNK. Thus, i can re-collect data from shared memory. (you can see its animation at slide page 11-12 ) - Extension of device clause --- I behave target directive as a task. Since i implemented based on OmpSs, thus OmpSs can manage my task. --- I didn't wait used to pass integer for device() clause. Thus runtime automatically started to manage multiple GPU. (OmpSs runtime is already doing this) --- Also device-to-device data transfer became available. (Normally there is no way to do this in omp) (you can see its animation at slide page 10 ) Additionally, Nowadays i am working on 2 topic 1 - How to take advantage Dynamic parallelism. --- While doing this, I am comparing dynamic parallelism with creation extra threads in advance instead creating new kernel. Because DP causes overhead and sometimes it might need communication between child-parent thread. (for example when reduction occurred. and only way to communicate global memory) 2 - Trying to find some advantages of Dynamic compilation. (from opencl side is already available. form nvidia side it is just announced with 7.0 nvrtc runtime compilation) Best Regards, Güray Özen ~grypp 2015-03-11 13:53 GMT+01:00 Thomas Schwinge tho...@codesourcery.com: Hi! On Tue, 3 Mar 2015 16:16:21 +0100, guray ozen guray.o...@gmail.com wrote: I finished my master at Barcelona Supercomputing Center and i started to do PhD. My master thesis code generation OpenMP 4.0 for GPU accelerators. And i am still working on it. Last year i presented my research compiler MACC at IWOMP'14 which is based on OmpSs runtime (http://pm.bsc.es/). You can check here my paper and related paper http://portais.fieb.org.br/senai/iwomp2014/presentations/Guray_Ozen.pptx http://link.springer.com/chapter/10.1007%2F978-3-319-11454-5_16 As far as i know, GCC 5 will come with OpenMP 4.0 and OpenACC offloading. I am wondering that are there a any project related code generation within gsoc 2015? Because when i checked todo list about offloading, i couldn't come accross. or what am i supposed to do? The idea that you propose seems like a fine project for GSoC -- definitely there'll be enough work to be done. ;-) Somebody from the GCC side needs to step up as a mentor. Grüße, Thomas
Re: [PATCH, CHKP, PR target/65044] Restrict pointer bounds checker with Sanitizer
On 09 Mar 15:51, Jakub Jelinek wrote:
On Mon, Mar 02, 2015 at 01:25:43PM +0300, Ilya Enkovich wrote:
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -1376,6 +1376,11 @@ process_options (void)
{
if (targetm.chkp_bound_mode () == VOIDmode)
error (-fcheck-pointer-bounds is not supported for this target);
+
+ if (flag_sanitize SANITIZE_ADDRESS)
+ error (-fcheck-pointer-bounds is not supported with Address
Sanitizer);
+
+ flag_check_pointer_bounds = 0;
}
Doesn't this disable -fcheck-pointer-bounds always?
I'd expect you want to clear flag_check_pointer_bounds only if you issued
one of the two errors...
Jakub
Whoops! Here is a less destructive version.
Thanks,
Ilya
--
gcc/
2015-03-11 Ilya Enkovich ilya.enkov...@intel.com
PR target/65044
* toplev.c (process_options): Restrict Pointer Bounds Checker
usage with Address Sanitizer.
gcc/testsuite/
2015-03-11 Ilya Enkovich ilya.enkov...@intel.com
PR target/65044
* gcc.target/i386/pr65044.c: New.
diff --git a/gcc/testsuite/gcc.target/i386/pr65044.c
b/gcc/testsuite/gcc.target/i386/pr65044.c
new file mode 100644
index 000..4f318d6
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr65044.c
@@ -0,0 +1,12 @@
+/* { dg-error -fcheck-pointer-bounds is not supported with Address Sanitizer
} */
+/* { dg-do compile } */
+/* { dg-require-effective-target mpx } */
+/* { dg-options -fcheck-pointer-bounds -mmpx -fsanitize=address } */
+
+extern int x[];
+
+void
+foo ()
+{
+ x[0] = 0;
+}
diff --git a/gcc/toplev.c b/gcc/toplev.c
index 99cf180..b06eed3 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -1375,7 +1375,17 @@ process_options (void)
if (flag_check_pointer_bounds)
{
if (targetm.chkp_bound_mode () == VOIDmode)
- error (-fcheck-pointer-bounds is not supported for this target);
+ {
+ error (-fcheck-pointer-bounds is not supported for this target);
+ flag_check_pointer_bounds = 0;
+ }
+
+ if (flag_sanitize SANITIZE_ADDRESS)
+ {
+ error (-fcheck-pointer-bounds is not supported with
+Address Sanitizer);
+ flag_check_pointer_bounds = 0;
+ }
}
/* One region RA really helps to decrease the code size. */
[Bug target/39429] compiler create bad asm codes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39429 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||ramana at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |4.5.0 --- Comment #10 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Fixed in 4.5.0 but not earlier.
[Bug target/65044] ICE: SIGSEGV in contains_struct_check with -fsanitize=address -fcheck-pointer-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65044 ienkovich at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ienkovich at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from ienkovich at gcc dot gnu.org --- Fixed
[Bug target/37954] odd sized packed structures passed by value, under ARM, cause lockup of application
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37954 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||ramana at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |4.4.0 --- Comment #15 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Fixed. ... Wont fix on the 4.3 branch which is now long dead.
[wwwdocs] Update 4.9.2 status link from RC announcement to release announcement
This just updates the status link on the homepage from the 4.9.2-rc1 announcement to the final release announcement a week later. Committed to CVS. Index: index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v retrieving revision 1.955 diff -u -r1.955 index.html --- index.html 6 Feb 2015 22:36:02 - 1.955 +++ index.html 12 Mar 2015 09:37:46 - @@ -188,7 +188,7 @@ /dtdd Status: !--GCC 4.9 status below-- - a href=https://gcc.gnu.org/ml/gcc/2014-10/msg00195.html;2014-10-23/a + a href=https://gcc.gnu.org/ml/gcc/2014-10/msg00260.html;2014-10-30/a !--GCC 4.9 status above-- (regression fixes and docs only). br /
[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369 --- Comment #15 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Alan Modra from comment #13) Markus, are you sure about comment #9? I completely disabled the bswap pass and still see a failure of the testcase at -O3. Incidentally, if I compile with -O2 -fno-inline, the testcase fails on the first iteration rather than the second (unaligned case) iteration. Yes r210842 is fine, r210843 fails with -O3.
[Bug c/65403] New: -Wno-error=not implemented is an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65403 Bug ID: 65403 Summary: -Wno-error=not implemented is an error Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: diagnostic Severity: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org If you want to silence warnings you can use -Wno-XXX without caring about whether a compiler implements -WXXX already. This doesn't seem to work with -Wno-error=XXX which errors on unknown XXX. It seems to me that we should treat -W[no-]error=XXX the same as -Wno-XXX for unknown XXX as it certainly will enable/disable errors for the warning XXX both if present or not present (no warnings anyway). gcc-5 -Wall -Werror -Wno-error=logical-not-parentheses -S t.c gcc-4.8 -Wall -Werror -Wno-error=logical-not-parentheses -S t.c cc1: error: -Werror=logical-not-parentheses: no option -Wlogical-not-parentheses gcc-5 -Wno-error=foo -S t.c cc1: error: -Werror=foo: no option -Wfoo
[Bug go/65404] New: cgo tool on powerpc-linux-gnu maybe incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65404 Bug ID: 65404 Summary: cgo tool on powerpc-linux-gnu maybe incomplete Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: doko at gcc dot gnu.org CC: cmang at google dot com cgo tool on powerpc-linux-gnu maybe incomplete the symptom noted at https://launchpad.net/bugs/1431032 shows an error: dist/src/github.com/lxc/lxd/shared/container.go:11:2: C source files not allowed when not using cgo: sqlite3-binding.c another not yet implemented issue is the support for PPC relocations, reported as https://github.com/golang/go/issues/10118
[Bug c/65402] New: global register variables miscompiled when unit contains sse4.2 functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65402
Bug ID: 65402
Summary: global register variables miscompiled when unit
contains sse4.2 functions
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mattiase at acm dot org
The mere presence of a function with the attribute target(sse4.2) is enough
for gcc to miscompile other functions with respect to global register
variables:
code below! -
__attribute__((target(sse4.2))) void F(void) {}
register long gr1 asm(r12);
register long gr2 asm(r13);
long G(void);
int H(void) {
gr1 = G(); /* Any code at all, really. */
return 1;
}
- code above!
The existence of F causes H to save/restore all global register variables in
its prologue/epilogue, which of course makes these variables impossible to use
inside H. Comment out the definition of F, and the problem disappears.
This occurs in GCC 4.9.2 on x86-64 (Linux), with -O0 or -O2.
Possible workaround: move the register declarations to above F. This is not
always easy (in our case, F is really the stuff in ia32intrin.h that happened
to be included from header files that we need for the types in the register
variable declarations).
Although it's good practice to put the global register declarations at the top
of the unit, not doing so shouldn't cause functions below to be miscompiled.
This appears to be a regression; the bug is not present in GCC 4.8.1.
[Bug rtl-optimization/65235] Simplifying vec_select of vec_concat miscompiles when first element of vec_concat is const_int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65235 --- Comment #8 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Thu Mar 12 13:40:50 2015 New Revision: 221387 URL: https://gcc.gnu.org/viewcvs?rev=221387root=gccview=rev Log: [simplify-rtx] PR 65235: Calculate element size correctly when simplifying (vec_select (vec_concat (const_int) (...)) [...]) PR rtl-optimization 65235 * simplify-rtx.c (simplify_binary_operation_1, VEC_SELECT case): When first element of vec_concat is const_int, calculate its size using second element. PR rtl-optimization 65235 * gcc.target/aarch64/pr65235_1.c: New test. Added: trunk/gcc/testsuite/gcc.target/aarch64/pr65235_1.c Modified: trunk/gcc/ChangeLog trunk/gcc/simplify-rtx.c trunk/gcc/testsuite/ChangeLog
[linaro/gcc-4_9-branch] Merge from gcc-4_9-branch and backports
Hi all we have merged the gcc-4_9-branch into linaro/gcc-4_9-branch up to revision 221341 as r221360. We have also backported this set of revisions: * r212011 as r221216 : PR tree-optimization/61607 * r214942 as r221216 : Abstract away marking loops for removal * r214957 as r221216 : Sanity check removed loops * r215012 as r221216 : PR bootstrap/63204 * r215016 as r221216 : PR ipa/63196 * r215612 as r221194 : Tighten predicates on SIMD shift intrinsics * r215722 as r221196 : Wire up vqdmullh_laneq_s16 and vqdmullh_laneq_s32 * r216663 as r221239 : [testsuite] revert changes on check_effective_target_arm_*_ok * r217706 as r221240 : [testsuite] new set of Neon intrinsics tests * r217707 as r221241 : [testsuite] fix vbic/vorn Neon tests * r217725 as r221339 : Improve modeled latency between FP operations and FP-GP register moves * r217780 as r221302 : Adjust generic move costs * r217852 as r221300 : Add range-check for Symbol + offset addressing * r217938 as r221301 : Add vector pattern for __builtin_ctz * r218115 as r221216 : PR tree-optimization/64083 * r218463 as r221242 : [testsuite] Fix vaddl and vaddw tests * r218486 as r221344 : Bics instruction generation for aarch64 * r218503 as r221344 : additional bics patterns * r218733 as r221216 : PR tree-optimization/64284 * r218746 as r221216 : PR middle-end/64246 * r219764 as r221242 : [testsuite] Add explicit dependency on Neon Cumulative Saturation flag * r219765 as r221242 : [testsuite] Be more verbose, and actually confirm that a test was checked. * r219767 as r221242 : [testsuite] Add vld1_lane tests * r219914 as r221242 : [testsuite] Add vldX_dup test. * r219917 as r221242 : [testsuite] Add vmla and vmls tests. * r219918 as r221242 : [testsuite] Add vmla_lane and vmls_lane tests. * r219919 as r221242 : [testsuite] Add vtrn tests. Refactor vzup and vzip tests. * r219920 as r221242 : [testsuite] Add vmlal and vmlsl tests. * r219921 as r221242 : [testsuite] Add vmlal_lane and vmlsl_lane tests. * r219922 as r221242 : [testsuite] Add vmlal_n and vmlsl_n tests. * r219930 as r221242 : [testsuite] Add vqdmlal and vqdmlsl tests. * r219931 as r221242 : [testsuite] Add vqdmlal_lane and vqdmlsl_lane tests * r219932 as r221242 : [testsuite] Add vqdmlal_n and vqdmlsl_n tests. * r219934 as r221242 : [testsuite] Add vsli_n and vsri_n tests. * r219937 as r221242 : [testsuite] Add vsubl tests, put most of the code in common with vaddl in vXXXl.inc. * r219938 as r221242 : [testsuite] Add vsubw tests, putting most of the code in common with vaddw * r219939 as r221242 : [testsuite] Add vmovn tests. * r219940 as r221242 : [testsuite] Add vmul_lane tests. * r219941 as r221242 : [testsuite] Add vmul_n tests. * r219942 as r221242 : [testsuite] Add vmull tests. * r219943 as r221242 : [testsuite] Add vmull_lane tests. * r219944 as r221242 : [testsuite] Add vmull_n tests. * r219945 as r221242 : [testsuite] Add vqdmulh tests. * r219946 as r221242 : [testsuite] Add vqdmulh_lane tests. * r219947 as r221242 : [testsuite] Add vqdmulh_n tests. * r219948 as r221242 : [testsuite] Add vqdmull tests. * r219949 as r221242 : [testsuite] Add vqdmull_lane tests. * r219950 as r221242 : [testsuite] Add vqdmull_n tests. * r220117 as r221242 : [testsuite] Add vsubhn, vraddhn and vrsubhn tests. * r220118 as r221242 : [testsuite] Add vmla_n and vmls_n tests. * r220119 as r221242 : [testsuite] Add vpadd, vpmax and vpmin tests. * r220121 as r221242 : [testsuite] Add vmovl tests. * r220122 as r221242 : [testsuite] Add vmnv tests. * r220123 as r221242 : [testsuite] Add vpadal tests. * r220124 as r221242 : [testsuite] Add vpaddl tests. * r220126 as r221242 : Fix incorrect ChangeLog formatting. * r220353 as r221242 : [testsuite] Add vmax, vmin, vhadd, vhsub and vrhadd tests. * r220491 as r221216 : PR tree-optimization/64878 * r220751 as r221343 : [Haifa Scheduler] Fix latent bug in macro-fusion/instruction grouping * r220860 as r221215 : [AArch64] Fix wrong-code bug in right-shift SISD patterns This will be part of our 2015.03 4.9 release. Thanks Yvan
[PATCH][OpenMP] Fix declare target variables in fortran modules
Hi,
We have a problem with declare target variables in fortran modules, here is a
small reproducer:
+ share.f90:
module share
integer :: var_x
!$omp declare target(var_x)
end module
+ test.f90:
use share
var_x = 10
!$omp target update to(var_x)
end
+
$ gfortran -fopenmp -c share.f90
$ gfortran -fopenmp -c test.f90
$ gfortran -fopenmp share.o test.o
$ ./a.out
libgomp: Duplicate node
+
This happens because the var_x is added into offload tables for both share.o and
test.o. The patch below fixes this issue. Regtested on x86_64-linux and
i686-linux. However I'm not sure how to create a regression test, which would
compile 2 separate objects, and check run-time result.
diff --git a/gcc/varpool.c b/gcc/varpool.c
index 707f62f..5929d92 100644
--- a/gcc/varpool.c
+++ b/gcc/varpool.c
@@ -173,7 +173,7 @@ varpool_node::get_create (tree decl)
node = varpool_node::create_empty ();
node-decl = decl;
- if ((flag_openacc || flag_openmp)
+ if ((flag_openacc || flag_openmp) !DECL_EXTERNAL (decl)
lookup_attribute (omp declare target, DECL_ATTRIBUTES (decl)))
{
node-offloadable = 1;
Thanks,
-- Ilya
[Bug c++/65399] error: invalid use of non-static data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65399 --- Comment #3 from David Binderman dcb314 at hotmail dot com --- (In reply to Jonathan Wakely from comment #2) (Also you should have seen the duplicate bug with *exactly* the same error message when submitting this one) Agreed, I should have done, but I didn't. It looks like a problem in the search mechanism. While my gcc trunk sources are less than one day old, it seems that the error is in fedora alpha 22, for their gcc dated 20150226.
Re: inline asm clobbers
On Mar 11, 2015, at 8:53 PM, David Wohlferd d...@limegreensocks.com wrote: ... I would agree that one should avoid it. I'd be wary of removing it from GCC at this point since it might break working code. It certainly would. It’s not all that common, but I have seen this done in production code. Come to think of it, this certainly makes sense in machines where some instructions act on fixed registers. Really? While I've seen much code that uses clobbers, I have never (until this week) see anyone attempt to clobber by index. Since I'm basically an i386 guy, maybe this is a platform thing? Do you have some examples/links? The example I remember was not in open code. It may have been cleaned up by now, but as supplied to us by the vendor, there were some bits of assembly code that needed a scratch register and used a fixed register (t0 == %8) for that purpose rather than having GCC deal with temporaries. So there was a clobber with “8” in it. Obviously there’s a better way in that instance, but if GCC had removed the feature before we found and cleaned up that code, we would have had a failure on our hands. An example of hardwired registers I remember is some VAX instructions (string instructions). You could write those by name, of course, but if you didn’t know that GCC supports names, you might just use numbers. On machines like VAX where the register names are really just numbers (R0, R1, etc.) that isn’t such a strange thing to do. Register names would be nice as an additional capability. Every example I've ever seen uses register names. Perhaps that what you've seen before? No; I didn’t know that gcc supports register names. The examples I had seen all use numbers. Or more often, preprocessor symbols. It may be that’s because the most common asm code I run into is MIPS coprocessor references, and while general registers may be known by name, coprocessor registers may not be. Or it may just be a case of lack of awareness. paul
Re: [PATCH][OpenMP] Fix declare target variables in fortran modules
On Thu, Mar 12, 2015 at 04:56:35PM +0300, Ilya Verbin wrote:
This happens because the var_x is added into offload tables for both share.o
and
test.o. The patch below fixes this issue. Regtested on x86_64-linux and
i686-linux. However I'm not sure how to create a regression test, which would
compile 2 separate objects, and check run-time result.
Ok with proper ChangeLog entry.
As for testcase, won't dg-additional-sources help?
I mean, does it fail without your patch even if you just do
gfortran -fopenmp -o a.out share.f90 test.f90; ./a.out ?
--- a/gcc/varpool.c
+++ b/gcc/varpool.c
@@ -173,7 +173,7 @@ varpool_node::get_create (tree decl)
node = varpool_node::create_empty ();
node-decl = decl;
- if ((flag_openacc || flag_openmp)
+ if ((flag_openacc || flag_openmp) !DECL_EXTERNAL (decl)
lookup_attribute (omp declare target, DECL_ATTRIBUTES (decl)))
{
node-offloadable = 1;
Jakub
Re: [PATCH][simplify-rtx] PR 65235: Calculate element size correctly when simplifying (vec_select (vec_concat (const_int) (...)) [...])
On Thu, Mar 12, 2015 at 2:28 PM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote: The patch fixes that by calculating the size of the first element by taking the size of the outer mode and subtracting the size of the second element. I've added an assert to make sure that the second element is not also a const_int, as a vec_concat of const_ints doesn't make sense as far as I can see. I'm not sure about the assert, can't we just punt in this case? Ok, here's a patch returning 0 in that case. The assert had never triggered in my testing anyway, but I agree we want to just cancel the simplification rather than ICE. Bootstrapped and tested on aarch64-none-linux-gnu, arm-none-linux-gnueabihf, x86_64-linux-gnu. This bug appears on trunk, 4.9 and 4.8, so it's not a regression on the release branches but it is a wrong-code bug. I think that the fix would be acceptable for GCC 5 without the assert. Thanks for reviewing. Richard, do you think this can go in for GCC 5 now? What about 4.9 and 4.8? The bug appears there as well. Sure - it's a wrong-code fix. Ok for trunk and branches (after a while). Thanks, Richard. Thanks, Kyrill 2015-03-12 Kyrylo Tkachov kyrylo.tkac...@arm.com PR rtl-optimization 65235 * simplify-rtx.c (simplify_binary_operation_1, VEC_SELECT case): When first element of vec_concat is const_int, calculate its size using second element. 2015-03-12 Kyrylo Tkachov kyrylo.tkac...@arm.com PR rtl-optimization 65235 * gcc.target/aarch64/pr65235_1.c: New test.
[Bug c/65403] -Wno-error=not implemented is an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65403 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Besides that the error also complains about -Werror= instead of -Wno-error=
[Bug rtl-optimization/65235] Simplifying vec_select of vec_concat miscompiles when first element of vec_concat is const_int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65235 ktkachov at gcc dot gnu.org changed: What|Removed |Added Known to work||5.0 Known to fail|5.0 | --- Comment #9 from ktkachov at gcc dot gnu.org --- Fixed on trunk. Will backport to branches later.
[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369 --- Comment #14 from Alan Modra amodra at gmail dot com --- That should be -O3 -fno-inline.
Re: [PATCH][simplify-rtx] PR 65235: Calculate element size correctly when simplifying (vec_select (vec_concat (const_int) (...)) [...])
The patch fixes that by calculating the size of the first element by
taking the size of the outer mode and subtracting the size of the second
element.
I've added an assert to make sure that the second element is not also a
const_int, as a vec_concat of const_ints doesn't make sense as far
as I can
see.
I'm not sure about the assert, can't we just punt in this case?
Ok, here's a patch returning 0 in that case.
The assert had never triggered in my testing anyway, but I agree we
want to just cancel the simplification rather than ICE.
Bootstrapped and tested on aarch64-none-linux-gnu,
arm-none-linux-gnueabihf, x86_64-linux-gnu.
This bug appears on trunk, 4.9 and 4.8, so it's not a regression on the
release branches but it is a wrong-code bug.
I think that the fix would be acceptable for GCC 5 without the assert.
Thanks for reviewing.
Richard, do you think this can go in for GCC 5 now?
What about 4.9 and 4.8? The bug appears there as well.
Thanks,
Kyrill
2015-03-12 Kyrylo Tkachov kyrylo.tkac...@arm.com
PR rtl-optimization 65235
* simplify-rtx.c (simplify_binary_operation_1, VEC_SELECT case):
When first element of vec_concat is const_int, calculate its size
using second element.
2015-03-12 Kyrylo Tkachov kyrylo.tkac...@arm.com
PR rtl-optimization 65235
* gcc.target/aarch64/pr65235_1.c: New test.commit 9946603f73e89f50d6610a943f770627ed533dbc
Author: Kyrylo Tkachov kyrylo.tkac...@arm.com
Date: Thu Feb 26 16:40:52 2015 +
[simplify-rtx] Calculate vector size correctly when simplifying (vec_select (vec_concat (const_int) (...)) [...])
diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
index a003b41..5d17498 100644
--- a/gcc/simplify-rtx.c
+++ b/gcc/simplify-rtx.c
@@ -3555,7 +3555,21 @@ simplify_binary_operation_1 (enum rtx_code code, machine_mode mode,
while (GET_MODE (vec) != mode
GET_CODE (vec) == VEC_CONCAT)
{
- HOST_WIDE_INT vec_size = GET_MODE_SIZE (GET_MODE (XEXP (vec, 0)));
+ HOST_WIDE_INT vec_size;
+
+ if (CONST_INT_P (XEXP (vec, 0)))
+ {
+ /* vec_concat of two const_ints doesn't make sense with
+ respect to modes. */
+ if (CONST_INT_P (XEXP (vec, 1)))
+ return 0;
+
+ vec_size = GET_MODE_SIZE (GET_MODE (trueop0))
+ - GET_MODE_SIZE (GET_MODE (XEXP (vec, 1)));
+ }
+ else
+ vec_size = GET_MODE_SIZE (GET_MODE (XEXP (vec, 0)));
+
if (offset vec_size)
vec = XEXP (vec, 0);
else
diff --git a/gcc/testsuite/gcc.target/aarch64/pr65235_1.c b/gcc/testsuite/gcc.target/aarch64/pr65235_1.c
new file mode 100644
index 000..ca12cd5
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/pr65235_1.c
@@ -0,0 +1,30 @@
+/* { dg-do run } */
+/* { dg-options -O2 } */
+
+#include arm_neon.h
+
+int
+main (int argc, char** argv)
+{
+ int64x1_t val1;
+ int64x1_t val2;
+ int64x1_t val3;
+ uint64x1_t val13;
+ uint64x2_t val14;
+ uint64_t got;
+ uint64_t exp;
+ val1 = vcreate_s64(UINT64_C(0x80008000));
+ val2 = vcreate_s64(UINT64_C(0xf38d));
+ val3 = vcreate_s64(UINT64_C(0x7fff809b));
+ /* Expect: val13 = 80001553. */
+ val13 = vcreate_u64 (UINT64_C(0x80001553));
+ /* Expect: val14 = 0010 0002 . */
+ val14 = vcombine_u64(vcgt_s64(vqrshl_s64(val1, val2),
+vshr_n_s64(val3, 18)),
+ vshr_n_u64(val13, 11));
+ /* Should be . */
+ got = vgetq_lane_u64(val14, 0);
+ exp = 0;
+ if(exp != got)
+__builtin_abort ();
+}
[Bug rtl-optimization/65401] [5 Regression] make_field_assignment broken for big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65401 --- Comment #2 from Jeffrey A. Law law at redhat dot com --- I was in this code recently, so mine.
[Ada] handle 'Code_Address on targets with function descriptors
For P a subprogram, P'Code_Address is expected to return the address at which the machine code for P starts. It differs from 'Address on targets where function symbol names denote the address of a function descriptor, a record from which the code address can be fetched (e.g. on ppc-aix). On such targets, P'Address is expected to return the descriptor address, and it does. P'Code_Address should fetch the code address from the, descriptor but we have nothing in place to achieve that today. It just returns the same as 'Address. The attached patch is the gigi part of a change to fix this, relying on a tm definition that we'll be submitting later on. With everything in place, the testcase below is expected to display OK. Bootstrapped and regtested on x86_64-pc-linux-gnu Olivier 2015-03-12 Olivier Hainque hain...@adacore.com * gcc-interface/trans.c (Attribute_to_gnu) Code_Address case: On targets where a function symbol designates a function descriptor, fetch the function code address from the descriptor. -- with System, Ada.Unchecked_Conversion; with Ada.Text_IO; use Ada.Text_IO; procedure Code_Addr_P is Addr, Code_Addr : System.Address; type Fn_Descriptor is record Fn_Address : System.Address; end record; type Descriptor_Access is access all Fn_Descriptor; function To_Descriptor_Access is new Ada.Unchecked_Conversion (System.Address, Descriptor_Access); Da : Descriptor_Access; use type System.Address; begin Addr := Code_Addr_P'Address; Code_Addr := Code_Addr_P'Code_Address; Da := To_Descriptor_Access (Addr); if Da.Fn_Address /= Code_Addr then raise Program_Error; end if; Put_Line (OK); end; fndesc.diff Description: Binary data
[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369 Alan Modra amodra at gmail dot com changed: What|Removed |Added Last reconfirmed|2015-03-12 00:00:00 |2015-03-10 0:00 CC||amodra at gmail dot com --- Comment #13 from Alan Modra amodra at gmail dot com --- Markus, are you sure about comment #9? I completely disabled the bswap pass and still see a failure of the testcase at -O3. Incidentally, if I compile with -O2 -fno-inline, the testcase fails on the first iteration rather than the second (unaligned case) iteration.
[Bug go/64999] s390x libgo test failure in TestMemoryProfiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999 --- Comment #51 from boger at us dot ibm.com --- Here is the change I made to go-callers.c. This patch along with my previous changes to extern.go and pprof.go allows the test identified in this issue to report the correct line number on ppc64le. I wanted to post it here for comments before I do the bootstrap build and test on ppc64 and ppc64le in case there is a concern with using an #if defined. This is in libgo/runtime and I didn't see any other examples where it used the GOARCH value in C code so that is why I did it this way. === --- libgo/runtime/go-callers.c (revision 221039) +++ libgo/runtime/go-callers.c (working copy) @@ -83,6 +83,10 @@ callback (void *data, uintptr_t pc, const char *fi } loc = arg-locbuf[arg-index]; +#if defined(__powerpc64__) || defined(__s390__) || defined(__s390x__) + if ((pc 1) == 1) +pc++; +#endif loc-pc = pc; /* The libbacktrace library says that these strings might disappear,
[PATCH] Make split_block and create_basic_block type-safe
After noticing tree-parloop.c passing crap to split_block (a tree
rather than a gimple or an rtx) I noticed those CFG functions simply
take void * pointers. The following patch fixes that and adds
two overloads, one for GIMPLE use and one for RTL use.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Ok at this stage?
Thanks,
Richard.
2015-03-12 Richard Biener rguent...@suse.de
* cfghooks.h (create_basic_block): Replace with two overloads
for RTL and GIMPLE.
(split_block): Likewise.
* cfghooks.c (split_block): Rename to ...
(split_block_1): ... this.
(split_block): Add two type-safe overloads for RTL and GIMPLE.
(split_block_after_labels): Call split_block_1.
(create_basic_block): Rename to ...
(create_basic_block_1): ... this.
(create_basic_block): Add two type-safe overloads for RTL and GIMPLE.
(create_empty_bb): Call create_basic_block_1.
* cfgrtl.c (fixup_fallthru_exit_predecessor): Use
split_block_after_labels.
* omp-low.c (expand_parallel_call): Likewise.
(expand_omp_target): Likewise.
(simd_clone_adjust): Likewise.
* tree-chkp.c (chkp_get_entry_block): Likewise.
* cgraphunit.c (init_lowered_empty_function): Use the GIMPLE
create_basic_block overload.
(cgraph_node::expand_thunk): Likewise.
* tree-cfg.c (make_blocks): Likewise.
(handle_abnormal_edges): Likewise.
* tree-inline.c (copy_bb): Likewise.
Index: gcc/cfghooks.c
===
--- gcc/cfghooks.c (revision 221379)
+++ gcc/cfghooks.c (working copy)
@@ -505,8 +505,8 @@ redirect_edge_and_branch_force (edge e,
the labels). If I is NULL, splits just after labels. The newly created
edge
is returned. The new basic block is created just after the old one. */
-edge
-split_block (basic_block bb, void *i)
+static edge
+split_block_1 (basic_block bb, void *i)
{
basic_block new_bb;
edge res;
@@ -550,12 +550,24 @@ split_block (basic_block bb, void *i)
return res;
}
+edge
+split_block (basic_block bb, gimple i)
+{
+ return split_block_1 (bb, i);
+}
+
+edge
+split_block (basic_block bb, rtx i)
+{
+ return split_block_1 (bb, i);
+}
+
/* Splits block BB just after labels. The newly created edge is returned. */
edge
split_block_after_labels (basic_block bb)
{
- return split_block (bb, NULL);
+ return split_block_1 (bb, NULL);
}
/* Moves block BB immediately after block AFTER. Returns false if the
@@ -696,8 +708,8 @@ split_edge (edge e)
HEAD and END are the first and the last statement belonging
to the block. If both are NULL, an empty block is created. */
-basic_block
-create_basic_block (void *head, void *end, basic_block after)
+static basic_block
+create_basic_block_1 (void *head, void *end, basic_block after)
{
basic_block ret;
@@ -714,12 +726,25 @@ create_basic_block (void *head, void *en
return ret;
}
+basic_block
+create_basic_block (gimple_seq seq, basic_block after)
+{
+ return create_basic_block_1 (seq, NULL, after);
+}
+
+basic_block
+create_basic_block (rtx head, rtx end, basic_block after)
+{
+ return create_basic_block_1 (head, end, after);
+}
+
+
/* Creates an empty basic block just after basic block AFTER. */
basic_block
create_empty_bb (basic_block after)
{
- return create_basic_block (NULL, NULL, after);
+ return create_basic_block_1 (NULL, NULL, after);
}
/* Checks whether we may merge blocks BB1 and BB2. */
Index: gcc/cfghooks.h
===
--- gcc/cfghooks.h (revision 221379)
+++ gcc/cfghooks.h (working copy)
@@ -196,12 +196,14 @@ extern edge redirect_edge_succ_nodup (ed
extern bool can_remove_branch_p (const_edge);
extern void remove_branch (edge);
extern void remove_edge (edge);
-extern edge split_block (basic_block, void *);
+extern edge split_block (basic_block, rtx);
+extern edge split_block (basic_block, gimple);
extern edge split_block_after_labels (basic_block);
extern bool move_block_after (basic_block, basic_block);
extern void delete_basic_block (basic_block);
extern basic_block split_edge (edge);
-extern basic_block create_basic_block (void *, void *, basic_block);
+extern basic_block create_basic_block (rtx, rtx, basic_block);
+extern basic_block create_basic_block (gimple_seq, basic_block);
extern basic_block create_empty_bb (basic_block);
extern bool can_merge_blocks_p (basic_block, basic_block);
extern void merge_blocks (basic_block, basic_block);
Index: gcc/cfgrtl.c
===
--- gcc/cfgrtl.c(revision 221379)
+++ gcc/cfgrtl.c(working copy)
@@ -4047,7 +4047,7 @@ fixup_fallthru_exit_predecessor (void)
edge, we have to split that block. */
if (c == bb)
{
- bb = split_block (bb, NULL)-dest;
+
[Bug rtl-optimization/65401] [5 Regression] make_field_assignment broken for big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65401 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- In the 9345 else if (GET_CODE (rhs) == AND 9346paradoxical_subreg_p (XEXP (rhs, 0)) 9347GET_CODE (SUBREG_REG (XEXP (rhs, 0))) == MEM 9348CONST_INT_P (XEXP (rhs, 1)) 9349rtx_equal_for_field_assignment_p (gen_rtx_MEM (GET_MODE (dest), 9350 XEXP (SUBREG_REG (XEXP (rhs, 0)), 0)), 9351dest)) hunks (two similar ones) sometimes GET_MODE (SUBREG_REG (XEXP (rhs, 0))) is == GET_MODE (dest), then it is certainly safe for big endian and you shouldn't need to even create a new MEM. For the other case, I'd say when increasing the mode size you really need to adjust the address of the mem for endianity, dunno if it is possible to have also narrower dest than the SUBREG_REG MEM, in that case punt? Oh, and please use MEM_P instead of GET_CODE () == MEM.
Re: [PATCH] Fix PR44563 more
CFG cleanup currently searches for calls that became noreturn and fixes them up (splitting block and removing the fallthru). Previously that was technically necessary as propagation may have turned an indirect call into a direct noreturn call and the CFG verifier would have barfed. Today we guard that with GF_CALL_CTRL_ALTERING and thus we remember the previous call analysis. Yep, I remember introducing this in back in tree-SSA branch days as kind of aftertought. The following patch removes the CFG cleanup code (which is expensive because gimple_call_flags () is quite expensive, not to talk about walking all stmts). This leaves the fixup_cfg passes to perform the very same optimization (relevant propagators can also be teached to call fixup_noreturn_call, but I don't think that's very important). Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. I'm somewhat undecided whether this is ok at this stage and if we _do_ want to make propagators fix those (previously indirect) calls up earlier at the same time. Honza - I think we performed this in CFG cleanup for the sake of CFG checking, not for the sake of prompt optimization, no? It is first time I hear this. We have verify_flow_info. I think most of CFG cleanups was scheudled because we need update-ssa and that would bomb on unreachable basic blocks. This would make PR44563 a pure IPA pass issue. Soo - testing revealed a single case where we mess up things (and the verifier noticing only because of a LHS on a noreturn call...). The following patch makes all propagators handle the noreturn transition (the paths in all but PRE are not exercised by bootstrap or testsuite :/). This patch makes CFG cleanup independent on BB size (during analysis, merge_blocks and delete_basic_block are still O(n)) - which is a very much desired property. It also changes fixup_cfg to produce a dump only when run as separate pass (otherwise the .optimized dump changes and I get tons of scan related fails) - that also reduces noise in the very many places we dump functions (they are dumped anyway for all cases). Bootstrap and regtest running on x86_64-unknown-linux-gnu. I wonder if you can throw this on firefox/chromium - the critical paths are devirtualization introducing __builtin_unreachable. I built chromium and firefox without problems with your patch. This patch should get a good speedup on all compiles (we run CFG-cleanup a _lot_), by removing pointless IL walks and expensive gimple_call_flags calls on calls. Yes, i definitely like it. The expensiveness of cfg-cleanup always quite bothered me. On unrelated note, I think it is possible to do cfg-cleanup with only fixed number of passes over CFG (my old RTL code did that but it was changed since then adding crossjumping). Both RTL and tree cfg cleanups have complicated history, there are probably quite few ways to get them cheaper. Thanks for working on it. As I noted in PR I plan to finally fix the inliner non-linearity with the sreal metrics next stage1 too. Honza
[Bug target/65358] wrong parameter passing code with tail call optimization on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65358 --- Comment #8 from Honggyu Kim hong.gyu.kim at lge dot com --- (In reply to Mikael Pettersson from comment #6) (In reply to Honggyu Kim from comment #4) Can I add this testcase with your modification as my first gcc contribution? :) Sure, just attach it to this PR as a new test case. I've just submitted a patch for testcase by making it to check the entire argument values. https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00704.html Thanks for you help.
[Bug libstdc++/65352] arrayT,0::begin()/end() etc. forms a null reference and breaks on clang+ubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65352 --- Comment #3 from TC rs2740 at gmail dot com --- Depends on how http://cplusplus.github.io/LWG/lwg-active.html#2443 comes out in LEWG, it might be a good idea to go with a solution that maintains the `constexpr`-ness so that it doesn't have to be redone again if the committee ends up making, say, begin() and end() constexpr. Of course, you are a lot more familiar with the committee's workings than I do :)
[PATCH][ARM] New testcase to check parameter passing bug
Hi,
I have wrote a testcase that reproduces argument overwriting bug during arm
code generation.
I wrote this testcase with the help of Mikael Pettersson.
If some format is not proper to run in gcc testsuite framework, please
correct me.
Please refer to the following bugzilla link for details:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65358
Honggyu
---
gcc/testsuite/ChangeLog|5 +
gcc/testsuite/gcc.target/arm/pr65358.c | 34
2 files changed, 39 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/arm/pr65358.c
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 5302dbd..9acd12a 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2015-03-13 Honggyu Kim hong.gyu@lge.com
+
+ PR target/65235
+ * gcc.target/arm/pr65358.c: New test for sibcall argument passing bug.
+
2015-03-12 Kyrylo Tkachov kyrylo.tkac...@arm.com
PR rtl-optimization/65235
diff --git a/gcc/testsuite/gcc.target/arm/pr65358.c
b/gcc/testsuite/gcc.target/arm/pr65358.c
new file mode 100644
index 000..d663dcf
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/pr65358.c
@@ -0,0 +1,34 @@
+/* PR target/65358 */
+/* { dg-do compile { target arm*-*-* } } */
+/* { dg-options -O2 } */
+
+struct pack
+{
+ int fine;
+ int victim;
+ int killer;
+};
+
+int __attribute__ ((__noinline__, __noclone__))
+bar (int a, int b, struct pack p)
+{
+ if (a != 20 || b != 30)
+__builtin_abort ();
+ if (p.fine != 40 || p.victim != 50 || p.killer != 60)
+__builtin_abort ();
+ return 0;
+}
+
+int __attribute__ ((__noinline__, __noclone__))
+foo (int arg1, int arg2, int arg3, struct pack p)
+{
+ return bar (arg2, arg3, p);
+}
+
+int main (void)
+{
+ struct pack p = { 40, 50, 60 };
+
+ (void) foo (10, 20, 30, p);
+ return 0;
+}
--
1.7.9.5
[Bug target/65358] wrong parameter passing code with tail call optimization on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65358 Honggyu Kim hong.gyu.kim at lge dot com changed: What|Removed |Added Known to fail||4.9.2 --- Comment #9 from Honggyu Kim hong.gyu.kim at lge dot com --- (In reply to James Greenhalgh from comment #7) Confirmed with native and cross compilers for arm-*-*, at least as far back as GCC 4.6.3. Thanks for the confirmation. I also added gcc-4.9.2 in Known to fail list.
[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369 Thomas Preud'homme thopre01 at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW Last reconfirmed|2015-03-10 00:00:00 |2015-03-12 0:00 Assignee|thopre01 at gcc dot gnu.org|unassigned at gcc dot gnu.org --- Comment #27 from Thomas Preud'homme thopre01 at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #26) So, on my version of the testcase with r210843 -O3 -mcpu=power8 there are like 49 32 bit load in host endianness found at: _105 = MEM[(const unsigned char *)load_src_25]; occurrences, so I've added a quick hack (should have used dbg counters parhaps), and with BSWAPCNT=16 it works fine, with BSWAPCNT=17 it fails. In the *.optimized dump, I've noticed that this single load matters for vectorization in md4_update function, with BSWAPCNT=16 a chunk of code isn't vectorized, with BSWAPCNT=17 it is. So very well this might just trigger a latent bug in the vectorizer or powerpc backend. Using trunk I get the following difference for bswap @@ -1110,10 +,10 @@ nettle_md4_update (struct md4_ctx * ctx, _100 = MEM[(const uint8_t *)data_149 + 1B]; _101 = (unsigned int) _100; _102 = _101 8; + _106 = MEM[(const uint8_t *)data_149]; _104 = *data_149; _105 = (unsigned int) _104; _123 = _99 | _105; - _106 = _102 | _123; Which looks perfectly fine. So yeah, I guess the problem is at a different level.
Re: [PATCH] Speed-up def_builtin_const (ix86_valid_target_attribute)
2015-03-09 Martin Liska marxin.li...@gmail.com
* config/i386/i386.c (def_builtin): Collect union of all
possible masks.
(ix86_add_new_builtins): Do not iterate over all builtins
in cases that isa value has no intersection with possible masks
and(or) last passed value is equal to the provided.
---
gcc/config/i386/i386.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index ab8f03a..5f180b6 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -30592,6 +30592,8 @@ struct builtin_isa {
static struct builtin_isa ix86_builtins_isa[(int) IX86_BUILTIN_MAX];
+/* Union of all masks that are part of builtin_isa structures. */
+static HOST_WIDE_INT defined_isa_values = 0;
/* Add an ix86 target builtin function with CODE, NAME and TYPE. Save the
MASK
of which isa_flags to use in the ix86_builtins_isa array. Stores the
@@ -30619,6 +30621,7 @@ def_builtin (HOST_WIDE_INT mask, const char *name,
if (!(mask OPTION_MASK_ISA_64BIT) || TARGET_64BIT)
{
ix86_builtins_isa[(int) code].isa = mask;
+ defined_isa_values |= mask;
I think you can move this down to set_and_not_build_p set. Please add also
comment explaining the caching mehanism.
mask = ~OPTION_MASK_ISA_64BIT;
if (mask == 0
@@ -30670,6 +30673,14 @@ def_builtin_const (HOST_WIDE_INT mask, const char
*name,
static void
ix86_add_new_builtins (HOST_WIDE_INT isa)
{
+ /* Last cached isa value. */
+ static HOST_WIDE_INT last_tested_isa_value = 0;
+
+ if ((isa defined_isa_values) == 0 || isa == last_tested_isa_value)
Heer you need to compare (isa defined_isa_values) == (isa
last_tested_isa_value) right, because we have isa flags that enable no
builtins.
Honza
[Bug c++/65350] [C++14] operator new[] should not be called if # of initializer elements exceeds # of elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65350 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Component|c |c++ --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org --- Correcting component as pointed out by NightStrike.
[Bug c++/65415] New: using, base class static member function template, and decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65415
Bug ID: 65415
Summary: using, base class static member function template, and
decltype
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
From http://stackoverflow.com/questions/29013260.
Minimized repro:
struct default_check
{
templatetypename U static int check(...);
};
struct is_addable : default_check
{
using default_check::check; // #1
using type = decltype(checkvoid(0));
};
int main() {}
gcc HEAD 5.0.0 20150312 (experimental) reports
prog.cc:9:31: error: expected primary-expression before 'void'
using type = decltype(checkvoid(0));
^
prog.cc:9:31: error: expected ')' before 'void'
prog.cc:9:16: error: expected type-specifier before 'decltype'
using type = decltype(checkvoid(0));
^
i.e., for some reason the `check` brought in by `using` isn't found. Oddly
enough, commenting out line #1 makes the code compile.
(The original code in the linked SO question had a separate check() overload in
is_addable. In that case, lookup for some reason only found the is_addable
overload and not the base class one brought in by `using`)
[Bug tree-optimization/44563] GCC uses a lot of RAM when compiling a large numbers of functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #29 from Richard Biener rguenth at gcc dot gnu.org ---
Sth like
@@ -672,8 +650,18 @@ cleanup_tree_cfg_bb (basic_block bb)
if (single_succ_p (bb)
can_merge_blocks_p (bb, single_succ (bb)))
{
- merge_blocks (bb, single_succ (bb));
- return true;
+ /* If there is a merge opportunity with the predecessor
+ do nothing now but wait until we process the predecessor.
+This happens when we visit BBs in a non-optimal order and
+avoids quadratic behavior with adjusting stmts BB pointer. */
+ if (single_pred_p (bb)
+ can_merge_blocks_p (single_pred (bb), bb))
+ ;
+ else
+ {
+ merge_blocks (bb, single_succ (bb));
+ return true;
+ }
}
return retval;
in addition should do the job. Iteration on the predecessor should
cover both merges (so we don't actually need to revisit this block itself).
[Bug sanitizer/65400] tsan mis-compiles inlineable C functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65400
--- Comment #1 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
I think the trouble starts at opcua_string.c.039t.fnsplit :
OpcUa_String_Clear (struct OpcUa_String * a_pString)
{
...
bb 5:
# _25 = PHI 0(2), 1(3), 0(4)
if (_25 == 0)
goto bb 7;
else
goto bb 6;
bb 6:
OpcUa_String_Clear.part.0 (a_pString_3(D));
goto bb 8;
bb 7:
TSAN_FUNC_EXIT ();
bb 8:
return;
}
[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369 --- Comment #22 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Could you please attach the unreduced testcase?
[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369
--- Comment #24 from Martin Sebor msebor at gcc dot gnu.org ---
Created attachment 35020
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35020action=edit
Unreduced translation unit of the test program.
Compil and run like so:
$ gcc -O3 -Wall -Werror gcc-65369.i valgrind ./a.out
==86961== Memcheck, a memory error detector
==86961== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==86961== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==86961== Command: ./a.out
==86961==
buffer[] = { \xe3 \x3b \x4d \xdc \x9c \x38 \xf2 \x19 \x9c \x3e \x7b \x16 \x4f
\xcc \x05 \x36 }
digest[] = { \xe3 \x3b \x4d \xdc \x9c \x38 \xf2 \x19 \x9c \x3e \x7b \x16 \x4f
\xcc \x05 \x36 }
buffer[] = { \xdd \x41 \x11 \xdd \x66 \x91 \x3a \xe2 \xf3 \x9a \xdf \xbc \x43
\x82 \x14 \xd6 }
digest[] = { \xe3 \x3b \x4d \xdc \x9c \x38 \xf2 \x19 \x9c \x3e \x7b \x16 \x4f
\xcc \x05 \x36 }
a.out: gcc-65369.c:41: main: Assertion `0 == memcmp (buffer, digest, sizeof
buffer - 1)' failed.
==86961==
==86961== HEAP SUMMARY:
==86961== in use at exit: 97 bytes in 1 blocks
==86961== total heap usage: 3 allocs, 2 frees, 295 bytes allocated
==86961==
==86961== LEAK SUMMARY:
==86961==definitely lost: 0 bytes in 0 blocks
==86961==indirectly lost: 0 bytes in 0 blocks
==86961== possibly lost: 97 bytes in 1 blocks
==86961==still reachable: 0 bytes in 0 blocks
==86961== suppressed: 0 bytes in 0 blocks
==86961== Rerun with --leak-check=full to see details of leaked memory
==86961==
==86961== For counts of detected and suppressed errors, rerun with: -v
==86961== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Aborted
[Bug c/65403] -Wno-error=not implemented is an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65403
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-03-12
CC||manu at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
For fixing the output, the following should be enough:
Index: opts.c
===
--- opts.c (revision 221118)
+++ opts.c (working copy)
@@ -2341,11 +2341,12 @@ enable_warning_as_error (const char *arg
new_option[0] = 'W';
strcpy (new_option + 1, arg);
option_index = find_opt (new_option, lang_mask);
if (option_index == OPT_SPECIAL_unknown)
{
- error_at (loc, -Werror=%s: no option -%s, arg, new_option);
+ error_at (loc, -W%s=%s: no option -%s,
+ value ? error : no-error, arg, new_option);
}
else
{
const diagnostic_t kind = value ? DK_ERROR : DK_WARNING;
[Bug libgcj/52579] [4.8/4.9/5 regression] i386_w32_fallback_frame_state should care ffi raw-closure stub function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52579 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-03-12 CC||ktietz at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org --- This issue seems to be fixed in 5.0 by Richard's work on libffi. Could you please check, if issue is fixed for you?
[Bug rtl-optimization/63491] Ice in LRA with simple vector test case on power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63491 --- Comment #10 from Peter Bergner bergner at gcc dot gnu.org --- Strange, this fails with my builds on our internal POWER8 box, but doesn't with my build on the external gcc112 POWER8 compile farm system. I'll try and track down what the difference is and see if I can recreate it on the external system.
[Bug go/65404] cgo tool on powerpc-linux-gnu maybe incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65404 --- Comment #1 from Ian Lance Taylor ian at airs dot com --- There is nothing in the cgo tool which would cause this error. When the command runs go, which go tool is actually running? The difference may be that on platforms other than powerpc-linux-gnu it is running the go tool from the gc compiler, but on powerpc-linux-gnu it is running the go tool from the gccgo compiler. This could potentially happen because the gc compiler does not support 32-bit powerpc.
[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369 --- Comment #20 from Martin Sebor msebor at gcc dot gnu.org --- The original test doesn't show any valgrind errors so these could be the result of using delta to reduce the test case.
[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369 --- Comment #19 from Jakub Jelinek jakub at gcc dot gnu.org --- Yeah. In md4_digest, for (i = 0; i 16 - 2; i++) look writes data[0] through data[13], data[14] is stored after the loop, but data[15] is uninitialized, but md5_transform reads it and uses it.
[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369 --- Comment #23 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 35019 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35019action=edit pr65369.c Adjusted testcase that now works reliably at -O0, and even with -O3 -fno-inline, but fails with -O3 on powerpc64le-linux. Works on x86_64-linux. Contains LP64 dependency right now...
[Bug fortran/60898] [4.8/4.9/5 Regression] model compile error with gfortran 4.7 and gcc 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60898 --- Comment #24 from Mikael Morin mikael at gcc dot gnu.org --- Author: mikael Date: Thu Mar 12 16:08:48 2015 New Revision: 221395 URL: https://gcc.gnu.org/viewcvs?rev=221395root=gccview=rev Log: PR fortran/60898 fortran/ * resolve.c (resolve_symbol): Check that the symbol found by name lookup really is the current symbol being resolved. testsuite/ * gfortran.dg/entry_20.f90: New. Added: branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/entry_20.f90 Modified: branches/gcc-4_9-branch/gcc/fortran/ChangeLog branches/gcc-4_9-branch/gcc/fortran/resolve.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
