[Bug c++/60211] [4.9/5 Regression] ICE with #pragma GCC ivdep and for-loop on global scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60211 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-29 Summary|ICE with #pragma GCC ivdep |[4.9/5 Regression] ICE with |and for-loop on global |#pragma GCC ivdep and |scope |for-loop on global scope Ever confirmed|0 |1
[Bug lto/64076] [4.9/5 Regression] ICE: in update_visibility_by_resolution_info, at ipa-visibility.c:427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64076 tbsaunde at gcc dot gnu.org changed: What|Removed |Added CC||tbsaunde at gcc dot gnu.org --- Comment #2 from tbsaunde at gcc dot gnu.org --- what happens is this: testcase_2.o contains thunks to call s:: from vtables for each of x y and z. However testcase_2.C is compiled without t being a base so there's no thunk for t. So when testcase_1.C is compiled with t as a base of s we have an ironly thunk for t's vtable to call s::f and prevailing regular definitions of the other thunks. The result of that is triping the assert because we have one externally visible ironly thunk, and others that come from testcase_2.o
[Bug fortran/64432] New: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
Bug ID: 64432
Summary: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong
result for integer(4)::rate
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: anlauf at gmx dot de
I just discovered that the 20141227 snapshot breaks SYSTEM_CLOCK when
the COUNT_RATE argument is a 32-bit integer:
% cat gfcbug128.f90
program gfcbug128
integer(4) :: count_rate, count_max
call system_clock (count_rate=count_rate)
call system_clock (count_max=count_max)
print *, count_rate, count_max
end
GNU Fortran (GCC) 5.0.0 20141227 (experimental)
produces:
% head -11 gfcbug128.f90.003t.original
gfcbug128 ()
{
integer(kind=4) count_max;
integer(kind=4) count_rate;
{
integer(kind=8) count_rate.0;
_gfortran_system_clock_8 (0B, count_rate.0, 0B);
count_rate = (integer(kind=4)) count_rate.0;
_gfortran_system_clock_4 (0B, 0B, count_max);
whereas my 4.9 or other older installations give:
% head -7 gfcbug128.f90.003t.original-49
gfcbug128 ()
{
integer(kind=4) count_max;
integer(kind=4) count_rate;
_gfortran_system_clock_4 (0B, count_rate, 0B);
_gfortran_system_clock_4 (0B, 0B, count_max);
On my Linux system, the _4 version has count_rate=1000,
the _8 version is 100.
:-(
[Bug fortran/60357] [F08] structure constructor with unspecified values for allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60357 --- Comment #7 from janus at gcc dot gnu.org --- Author: janus Date: Mon Dec 29 10:45:21 2014 New Revision: 219098 URL: https://gcc.gnu.org/viewcvs?rev=219098root=gccview=rev Log: 2014-12-29 Janus Weil ja...@gcc.gnu.org PR fortran/60357 * array.c (check_constructor): Ignore empty expressions. * expr.c (check_alloc_comp_init): Check if constructor expression exists. * primary.c (build_actual_constructor): Warn for absent alloc-comp initializers in pre-2008 standards. 2014-12-29 Janus Weil ja...@gcc.gnu.org PR fortran/60357 * gfortran.dg/alloc_comp_constructor_7.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_constructor_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/primary.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/60357] [F08] structure constructor with unspecified values for allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60357 --- Comment #8 from janus at gcc dot gnu.org --- The original problem in comment 0 is fixed with r219098. Thanks to Anthony for reporting this! TODO: The segfault reported by Dominique in comment 4 and 5.
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
--- Comment #1 from Harald Anlauf anlauf at gmx dot de ---
Modifying the test code as follows:
% cat gfcbug128b.f90
program gfcbug128b
integer(4) :: count_rate, count_max
call system_clock (count_rate=count_rate,count_max=count_max)
call system_clock (count_rate=count_rate)
call system_clock (count_max=count_max)
end
% head -12 gfcbug128b.f90.003t.original
gfcbug128b ()
{
integer(kind=4) count_max;
integer(kind=4) count_rate;
{
integer(kind=8) count_rate.0;
_gfortran_system_clock_4 (0B, count_rate, count_max);
_gfortran_system_clock_8 (0B, count_rate.0, 0B);
count_rate = (integer(kind=4)) count_rate.0;
_gfortran_system_clock_4 (0B, 0B, count_max);
shows that the logic in trans-intrinsic.c::conv_intrinsic_system_clock
does not cover the case of single arguments:
gfc_expr *count = code-ext.actual-expr;
gfc_expr *count_rate = code-ext.actual-next-expr;
gfc_expr *count_max = code-ext.actual-next-next-expr;
/* The INTEGER(8) version has higher precision, it is used if both COUNT
and COUNT_MAX can hold 64-bit values, or are absent. */
if ((!count || count-ts.kind = 8)
(!count_max || count_max-ts.kind = 8))
kind = 8;
else
kind = gfc_default_integer_kind;
type = gfc_get_int_type (kind);
/* Evaluate our arguments. */
This probably needs to be amended.
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 Harald Anlauf anlauf at gmx dot de changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #2 from Harald Anlauf anlauf at gmx dot de --- Introduced in r211686. FX?
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #3 from janus at gcc dot gnu.org --- (In reply to Harald Anlauf from comment #0) I just discovered that the 20141227 snapshot breaks SYSTEM_CLOCK when the COUNT_RATE argument is a 32-bit integer: Confirmed. Probably due to r211686.
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-29 CC||janus at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/58906] [OOP] SELECT TYPE with CLASS IS generates ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58906 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #2 from janus at gcc dot gnu.org --- Segfaults with 4.8, 4.9 and trunk. Slightly reduced test case: TYPE :: child CLASS(*), DIMENSION(:), POINTER :: arr END TYPE CONTAINS SUBROUTINE f(r) CLASS(child) :: r SELECT TYPE ( r ) CLASS IS ( child ) SELECT TYPE( iarr=r%arr ) TYPE IS ( INTEGER ) CALL func( iarr ) END SELECT END SELECT END SUBROUTINE END
[Bug fortran/60507] Passing function call into procedure argument not caught
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60507 --- Comment #6 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #5) What is the status of the patch in comment 4? Alive 'n' kickin' ;) Still applies (with a bit of fuzz) and regtests cleanly.
[Bug target/64368] [5 Regression] Several libstdc++ test failures on darwin and others after r218964.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64368 --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org --- Who is waving anything away? I've been fixing things for Darwin at all hours of the day, while on vacation and while ill, so don't appreciate that comment. I have run the years in valgrind and saw no problem on Linux. Someone could always try debugging things themselves, even if just posting full stack traces to this report.
[Bug c++/64433] New: Segmentation fault while compiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64433
Bug ID: 64433
Summary: Segmentation fault while compiling
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: aleksis at mikrotik dot com
This code causes segmentation fault while compiling.
#include cstddef
templateint Num
class N {
static constexpr int num = Num;
};
templateclass T using NDef = Noffsetof(T, T::m);
templateclass T using TDef = NDefT;
GCC version: 4.9.2
compiled with: g++ --std=c++11 -c test.cpp
system: Linux 3.18.1-1-ARCH #1 SMP PREEMPT Wed Dec 17 15:40:09 CET 2014 x86_64
GNU/Linux
[Bug fortran/63552] [OOP] Type-bound procedures rejected as actual argument to dummy procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63552 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #2 from janus at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #0) call co_reduce(a,x%tbp) 1 Error: Expected argument list at (1) That error comes from 'gfc_match_varspec' (in primary.c). In general I think it's not possible to decide at parse-time whether the TBP should have an argument list here or not (depending on whether the dummy is a procedure, which may not be known while parsing). The error should probably move to resolution stage, where all argument checking is done.
[Bug target/64387] ICE: in extract_insn, at recog.c:2327 (unrecognizable insn) with -ffloat-store -mavx512er
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64387 tocarip.intel at gmail dot com changed: What|Removed |Added CC||tocarip.intel at gmail dot com --- Comment #1 from tocarip.intel at gmail dot com --- Created attachment 34343 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34343action=edit Proposed patch.
[Bug target/64387] ICE: in extract_insn, at recog.c:2327 (unrecognizable insn) with -ffloat-store -mavx512er
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64387 --- Comment #2 from tocarip.intel at gmail dot com --- Can also be reproduced with -mavx2 instead of -mavx512er. Proposed patch fixes both cases. Testing in progress.
[Bug fortran/63552] [OOP] Type-bound procedures rejected as actual argument to dummy procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63552
--- Comment #3 from janus at gcc dot gnu.org ---
This draft patch gets rid of the error and regtests cleanly:
Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c(Revision 219098)
+++ gcc/fortran/primary.c(Arbeitskopie)
@@ -1987,11 +1987,13 @@ gfc_match_varspec (gfc_expr *primary, int equiv_fl
{
if (sub_flag)
primary-value.compcall.actual = NULL;
- else
+ else if (!matching_actual_arglist)
{
gfc_error (Expected argument list at %C);
return MATCH_ERROR;
}
+ else
+primary-expr_type = EXPR_VARIABLE;
}
break;
However I then get another error on the test case in comment 0:
call co_reduce(a,x%tbp)
1
Error: OPERATOR argument at (1) must be a PURE function
This is obviously bogus since 'tbp' is bound to a PURE function. For the
commented-out line I get:
call co_reduce(a,x%ppc)
1 2
Fehler: A argument at (1) has type INTEGER(4) but the function passed as
OPERATOR at (2) returns REAL(4)
(which I guess is diagnosed correctly?)
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |fxcoudert at gcc dot gnu.org --- Comment #4 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- I'm not sure this is a bug, but this was definitely by design (as the comment indicates). I think this is allowed by the successive standards (which are, in any case, very weakly worded). The root of the problem is that we want to allow for SYSTEM_CLOCK to return high-precision values for large integer kinds, and fall back to lower-precision results that fit in fewer bytes for smaller integer kinds. Thus, one should call SYSTEM_CLOCK once with all the necessary arguments, and not multiple times with varying argument types. The only other consistent option I can see would be to simply go for high-resolution results in all cases, but that would mean that SYSTEM_CLOCK with 32-bit integers would wrap around in less than an hour. If you have another idea, please post a list of what you think should happen in all various cases (all possible combinations of arguments have to be allowed).
[Bug target/64368] [5 Regression] Several libstdc++ test failures on darwin and others after r218964.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64368 --- Comment #10 from Hans-Peter Nilsson hp at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #9) Who is waving anything away? I wasn't referring to you. Apparently I was referring to a comment that was supposed to be ignored. I've been fixing things for Darwin at all hours of the day, while on vacation and while ill, so don't appreciate that comment. Sorry! Your work and diligence is much appreciated. Get well soon. HNY. Someone could always try debugging things themselves, even if just posting full stack traces to this report. Bare-metal simulator setup without gdb, unfortunately. brgds, H-P
[Bug target/64368] [5 Regression] Several libstdc++ test failures on darwin and others after r218964.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64368 --- Comment #11 from Hans-Peter Nilsson hp at gcc dot gnu.org --- Created attachment 34344 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34344action=edit Call-trace for testsuite/22_locale/locale/cons/6.cc on cris-elf, a newlib target Plain execution trace from 22_locale/locale/cons/6.cc compiled with default testsuite options, so inlining and whatever effects apply. In the trace, lines with denotes function calls, are returns, with indentation supposed to show the call-level. The first four columns are the hexadecimal values of the first four parameters as applicable (actually, parameter registers but none are larger than 32 bits here, so same thing) / ditto return values, padded with random contents. (The fifth column is cumulative execution times at each call-level.) By a quick glance it seems the freed-but-not-allocated pointer, 0x5e23a, is also the argument to the last call to strlen. HTH.
[Bug fortran/60357] [F08] structure constructor with unspecified values for allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60357 Andre Vehreschild vehre at gmx dot de changed: What|Removed |Added CC||vehre at gmx dot de --- Comment #9 from Andre Vehreschild vehre at gmx dot de --- Hi Janus, be careful with the code in comment #4 and #5. When I remember correctly then it was me who added the allocate trying to understand how Fortran worked there. Meaning: That must not be valid Fortran. In fact, does my current work on this pr and on #61275 report that Me%y is already allocated and must not be reallocated again. That is, I may already have a patch that touches the issue. I just need to figure, if allocating the component explicitly is valid in Fortran. Do you know something about that? I am still reading the Fortran standards, but haven't found the location that answers my question. Andre
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #5 from Harald Anlauf anlauf at gmx dot de --- (In reply to Francois-Xavier Coudert from comment #4) I'm not sure this is a bug, but this was definitely by design (as the comment indicates). I think this is allowed by the successive standards (which are, in any case, very weakly worded). Well, let's see: the standard says: COUNT RATE (optional) shall be an integer or real scalar. It is an INTENT (OUT) argument. It is assigned a processor-dependent approximation to the number of processor clock counts per second, or zero if there is no clock. You're right, it does not say anything about consistency. Nevertheless, I would prefer if a program that always uses e.g. default integer == integer(4), the low-resolution (msec) version continues to be used consistently. That's what other compilers do and what gfortran = 4.9 did. Also, the presence of a second argument (see comment #1) should not change the behavior. OTOH, it is the responsibility of a user to consistently use arguments of the same type and kind to get consistent behavior. (I.e. not mixing integer and real or integer(4) and integer(8)). I do take care of that. The root of the problem is that we want to allow for SYSTEM_CLOCK to return high-precision values for large integer kinds, and fall back to lower-precision results that fit in fewer bytes for smaller integer kinds. How is this fallback done? Do you truncate the resolution? E.g. high res. - low res.: divide count_rate and count by 1000? Thus, one should call SYSTEM_CLOCK once with all the necessary arguments, and not multiple times with varying argument types. Note that I did *not* call SYSTEM_CLOCK with varying argument types. You're probably not aware of existing (f95) code that deals with the problem of wrapping, which is always present (count does not necessarily start with 0 at start of the program), although not very likely with integer(8)... ;-) The only other consistent option I can see would be to simply go for high-resolution results in all cases, but that would mean that SYSTEM_CLOCK with 32-bit integers would wrap around in less than an hour. No, that doesn't make sense. If you have another idea, please post a list of what you think should happen in all various cases (all possible combinations of arguments have to be allowed). Let's see: - For any number of arguments present (1, 2 or 3) - always integer(4): msec resolution (as before) - always integer(=8): usec resolution (or whatever is possible) - always real: I don't care, but I think it might be a good idea to use the same as for integer of a compatible kind. - different types and/or kinds: I don't care, since one should expect problems (wrapping or truncation) anyway. But presence of non-presence should never make a difference if consistent types and kinds are used.
[Bug tree-optimization/64434] New: Performance regression after operand canonicalization (r216728).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434 Bug ID: 64434 Summary: Performance regression after operand canonicalization (r216728). Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ysrumyan at gmail dot com We noticed huge regression on eembc1.1 and eembc2.0 for 32-bit target at x86. It can be reproduced on attached test-case: before this fix number of %esp references in assembly was 2 but after r216728 - 24. Note that simple fix resolving this issue was sent for review.
[Bug tree-optimization/64434] Performance regression after operand canonicalization (r216728).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434 --- Comment #1 from Yuri Rumyantsev ysrumyan at gmail dot com --- Created attachment 34345 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34345action=edit simple reproducer Need to compile with -m32 on x86 platform.
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #6 from Harald Anlauf anlauf at gmx dot de --- (In reply to Harald Anlauf from comment #5) Also, the presence of a second argument (see comment #1) should not change the behavior. To make that explicit: % cat gfcbug128c.f90 program gfcbug128c integer(4) :: count_rate, count_max call system_clock (count_rate=count_rate,count_max=count_max) print *, count_rate, count_max call system_clock (count_rate=count_rate) call system_clock (count_max=count_max) print *, count_rate, count_max end gfortran 5 gives: 1000 2147483647 100 2147483647 any other compiler: 1000 2147483647 1000 2147483647 I'd have a hard time to explain that to anybody.
[Bug target/64393] ICE: in extract_insn, at recog.c:2327 (unrecognizable insn) with -mavx512vbmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64393
tocarip.intel at gmail dot com changed:
What|Removed |Added
CC||tocarip.intel at gmail dot com
--- Comment #2 from tocarip.intel at gmail dot com ---
Created attachment 34346
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34346action=edit
Proposed patch.
Added (untested patch) allows k{or,xoer,...} for avx512vbmi case, and fixes
this problem. However I'm not sure, that just enabling whole avx512bw isn't a
better idea.
[Bug sanitizer/64435] New: [5.0.0 Regression] Bootstrap failure in libsanitizer on AArch64 with Linux kernel = 3.15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435
Bug ID: 64435
Summary: [5.0.0 Regression] Bootstrap failure in libsanitizer
on AArch64 with Linux kernel = 3.15
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: david.abdurachmanov at gmail dot com
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
I finally started testing GCC trunk (5.0.0) on AArch64 before release is made.
I quickly find out that I couldn't bootstrap GCC on APM Mustang board with APM
Linux images (F19 + 3.12 kernel), but it worked fine with QEMU + F21 + 3.17
kernel). Failure details are below.
The culprit is 34c65c43f1518bf85f93526ad373adc6a683b4c5 from Linux repository.
Commit details are provided below.
Simply put __sanitizer___kernel_{uid,gid}_t depends on kernel version. =3.15
it's unsigned int and =3.16 it's unsigned short.
# GCC trunk failure #
In file included from
../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:176:0:
../../../../libsanitizer/sanitizer_common/sanitizer_internal_defs.h:272:72:
error: size of array 'assertion_failed__1006' is negative
typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1]
^
../../../../libsanitizer/sanitizer_common/sanitizer_internal_defs.h:266:30:
note: in expansion of macro 'IMPL_COMPILER_ASSERT'
#define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__)
^
../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h:1285:3:
note: in expansion of macro 'COMPILER_CHECK'
COMPILER_CHECK(sizeof(__sanitizer_##TYPE) == sizeof(TYPE))
^
../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:1006:1:
note: in expansion of macro 'CHECK_TYPE_SIZE'
CHECK_TYPE_SIZE(__kernel_old_uid_t);
^
../../../../libsanitizer/sanitizer_common/sanitizer_internal_defs.h:272:72:
error: size of array 'assertion_failed__1007' is negative
typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1]
^
../../../../libsanitizer/sanitizer_common/sanitizer_internal_defs.h:266:30:
note: in expansion of macro 'IMPL_COMPILER_ASSERT'
#define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__)
^
../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h:1285:3:
note: in expansion of macro 'COMPILER_CHECK'
COMPILER_CHECK(sizeof(__sanitizer_##TYPE) == sizeof(TYPE))
^
../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:1007:1:
note: in expansion of macro 'CHECK_TYPE_SIZE'
CHECK_TYPE_SIZE(__kernel_old_gid_t);
^
make[4]: *** [sanitizer_platform_limits_posix.lo] Error 1
make[4]: *** Waiting for unfinished jobs
# Linux Commit #
commit 34c65c43f1518bf85f93526ad373adc6a683b4c5
Author: Will Deacon will.dea...@arm.com
Date: Mon Jun 2 11:47:29 2014 +0100
arm64: uid16: fix __kernel_old_{gid,uid}_t definitions
Whilst native arm64 applications don't have the 16-bit UID/GID syscalls
wired up, compat tasks can still access them. The 16-bit wrappers for
these syscalls use __kernel_old_uid_t and __kernel_old_gid_t, which must
be 16-bit data types to maintain compatibility with the 16-bit UIDs used
by compat applications.
This patch defines 16-bit __kernel_old_{gid,uid}_t types for arm64
instead of using the 32-bit types provided by asm-generic.
Signed-off-by: Will Deacon will.dea...@arm.com
Acked-by: Arnd Bergmann a...@arndb.de
Cc: sta...@vger.kernel.org
Signed-off-by: Catalin Marinas catalin.mari...@arm.com
diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild
index 42c7eec..0b3fcf8 100644
--- a/arch/arm64/include/asm/Kbuild
+++ b/arch/arm64/include/asm/Kbuild
@@ -30,7 +30,6 @@ generic-y += msgbuf.h
generic-y += mutex.h
generic-y += pci.h
generic-y += poll.h
-generic-y += posix_types.h
generic-y += preempt.h
generic-y += resource.h
generic-y += rwsem.h
diff --git a/arch/arm64/include/uapi/asm/posix_types.h
b/arch/arm64/include/uapi/asm/posix_types.h
new file mode 100644
index 000..7985ff6
--- /dev/null
+++ b/arch/arm64/include/uapi/asm/posix_types.h
@@ -0,0 +1,10 @@
+#ifndef __ASM_POSIX_TYPES_H
+#define __ASM_POSIX_TYPES_H
+
+typedef unsigned short __kernel_old_uid_t;
+typedef unsigned short __kernel_old_gid_t;
+#define __kernel_old_uid_t __kernel_old_uid_t
+
+#include asm-generic/posix_types.h
+
+#endif /* __ASM_POSIX_TYPES_H */
[Bug c++/64433] Segmentation fault while compiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64433 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-29 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- r181112 still rejects this, r181150 already ICEs.
[Bug tree-optimization/64434] [5 Regression] Performance regression after operand cannibalization (r216728).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-29 CC||hjl.tools at gmail dot com Target Milestone|--- |5.0 Summary|Performance regression |[5 Regression] Performance |after operand |regression after operand |canonicalization (r216728). |cannibalization (r216728). Ever confirmed|0 |1
[Bug tree-optimization/64434] [5 Regression] Performance regression after operand cannibalization (r216728).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |WAITING --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- Please show before and after assembly codes. Do we get slowdown on all processors?
[Bug target/64386] ICE: in extract_insn, at recog.c:2327 (unrecognizable insn) with -mavx512bw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64386 tocarip.intel at gmail dot com changed: What|Removed |Added CC||tocarip.intel at gmail dot com --- Comment #2 from tocarip.intel at gmail dot com --- Created attachment 34347 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34347action=edit Proposed patch. This (untested) patch fixes it.
[Bug tree-optimization/64434] [5 Regression] Performance regression after operand cannibalization (r216728).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434 --- Comment #3 from Yuri Rumyantsev ysrumyan at gmail dot com --- I put into attachment two assembly files for test-case compiled with -O2 -m32 -S options.
[Bug tree-optimization/64434] [5 Regression] Performance regression after operand cannibalization (r216728).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434 --- Comment #4 from Yuri Rumyantsev ysrumyan at gmail dot com --- Created attachment 34348 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34348action=edit assembly files for test.c Assembly file fro test.c
[Bug tree-optimization/64434] [5 Regression] Performance regression after operand cannibalization (r216728).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434 --- Comment #5 from Yuri Rumyantsev ysrumyan at gmail dot com --- Created attachment 34349 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34349action=edit assembly file before r216728 Assembly file.
[Bug tree-optimization/64434] [5 Regression] Performance regression after operand cannibalization (r216728).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434 --- Comment #6 from Yuri Rumyantsev ysrumyan at gmail dot com --- H.J. I put before/after assembly files into bug attachment. We saw slowdown on SLM and HSW for 32-bit on eembc2.0, e.g. des degradated on 36% (SLM) and 7%(HSW). But we did not see slowdown on any 64-bit x86. 2014-12-29 18:48 GMT+03:00 hjl.tools at gmail dot com gcc-bugzi...@gcc.gnu.org: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |WAITING --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- Please show before and after assembly codes. Do we get slowdown on all processors? -- You are receiving this mail because: You reported the bug.
[Bug tree-optimization/64434] [5 Regression] Performance regression after operand cannibalization (r216728).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434 --- Comment #7 from H.J. Lu hjl.tools at gmail dot com --- r216728 generates much longer code sequences. Where does it come from? Does -m64 also generate longer code sequences?
[Bug tree-optimization/64436] New: optimize-bswapdi-3.c fails on aarch64_be-none-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64436 Bug ID: 64436 Summary: optimize-bswapdi-3.c fails on aarch64_be-none-elf Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: thopre01 at gcc dot gnu.org gcc.dg/optimize-bswapdi-3.c started to fail about 2 weeks ago. Investigation shows that the way bswap create the symbolic number that corresponds to a bitwise OR is broken for big endian target. There also seems to be some bug in the computation of the range (in bswap terms) of that same symbolic number. Here is the the testsuite log: FAIL: gcc.dg/optimize-bswapdi-3.c scan-tree-dump-times bswap 64 bit bswap implementation found at 3 FAIL: gcc.dg/optimize-bswapdi-3.c scan-tree-dump-times bswap 64 bit load in target endianness found at 3
[Bug tree-optimization/64436] optimize-bswapdi-3.c fails on aarch64_be-none-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64436 thopre01 at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-12-29 Ever confirmed|0 |1
[Bug fortran/60357] [F08] structure constructor with unspecified values for allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60357 --- Comment #10 from janus at gcc dot gnu.org --- (In reply to Andre Vehreschild from comment #9) I just need to figure, if allocating the component explicitly is valid in Fortran. For sure. I think both the examples in comment 4 and 5 are actually valid Fortran code. In order to make sure we're talking about the same thing, let's have a look at the following code: Type A integer :: X = 1 integer, allocatable :: y end type Type(A) :: Me allocate(Me%y) print *,A Me = A(X=1, y=2) print *,B print *, Me%y end This is a variant of the example above that produced the segfault. I inserted some print statements in order to debug it. It prints at runtime: A B Program received signal SIGSEGV: Segmentation fault - invalid memory reference. This shows clearly that the segfault occurs when we try to access Me%y in the last print statement, meaning that it is probably unallocated although it clearly should be. -fdump-tree-original shows that the problem is in the translation of the structure constructor assignment, which apparently leaves the y-component unallocated.
[Bug tree-optimization/64434] [5 Regression] Performance regression after operand cannibalization (r216728).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434 --- Comment #8 from Yuri Rumyantsev ysrumyan at gmail dot com --- The issue is caused by operand canonicalization, i.e. there is special operand odering for commutative operations to have the same representation for a + b and b + a. If computation of second operand requires more operations this may lead to live range increasing ( for live variables computed by first operand). If we swap these operands we get live range shrinking which is essential for 32-bit targets having only few registers. Hope it will help you to understand the problem. 2014-12-29 19:36 GMT+03:00 hjl.tools at gmail dot com gcc-bugzi...@gcc.gnu.org: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434 --- Comment #7 from H.J. Lu hjl.tools at gmail dot com --- r216728 generates much longer code sequences. Where does it come from? Does -m64 also generate longer code sequences? -- You are receiving this mail because: You reported the bug.
[Bug target/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412 --- Comment #4 from iverbin at gcc dot gnu.org --- (In reply to H.J. Lu from comment #3) (In reply to iverbin from comment #2) (In reply to H.J. Lu from comment #1) (In reply to iverbin from comment #0) To reproduce using Intel Xeon Phi emulation: 1. Build offload and host compilers as described in https://gcc.gnu.org/wiki/Offloading#How_to_try_offloading_enabled_GCC 2. Run make check-target-libgomp RUNTESTFLAGS=c.exp=e.53.5.c Can you create a stanalone testcase for the Intel Xeon Phi offload cross compiler? It will be easier to debug. The offload model in GCC implies 2 compilers: one produces IR for OpenMP target regions, and another compiles this IR for Intel Xeon Phi. There is no single compiler, which could stream offload IR out, then stream it in, and then compile. I can reduce e.53.5.c testcase, not sure whether this is helpful. Can you use gcc -v -save-temps to see what is passed to the offload compiler and feed them to the offload compiler directly? Yes, this is possible. However, the function preload_common_nodes, modified in r218767, is used for both IN/OUT streaming, therefore the IR should be produced and consumed by compilers built from the same sources. Here are the reduced testcase and corresponding IR for: gcc -fopenmp -O1 -S pr64412.c To reproduce the error: 1. Configure and make gcc with: --enable-as-accelerator-for=x86_64-unknown-linux --host=x86_64-intelmicemul-linux --build=x86_64-intelmicemul-linux --target=x86_64-intelmicemul-linux 2. Run: as pr64412.s -o pr64412.o x86_64-unknown-linux-accel-x86_64-intelmicemul-linux-gnu-gcc -xlto -fopenmp -O1 -shared -fPIC pr64412.o
[Bug target/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412 --- Comment #5 from iverbin at gcc dot gnu.org --- Created attachment 34350 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34350action=edit Source code
[Bug target/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412 --- Comment #6 from iverbin at gcc dot gnu.org --- Created attachment 34351 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34351action=edit pr64412.s
[Bug tree-optimization/64434] [5 Regression] Performance regression after operand canonicalization (r216728).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Summary|[5 Regression] Performance |[5 Regression] Performance |regression after operand|regression after operand |cannibalization (r216728). |canonicalization (r216728). --- Comment #9 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Yuri Rumyantsev from comment #8) The issue is caused by operand canonicalization, i.e. there is special operand odering for commutative operations to have the same representation for a + b and b + a. If computation of second operand requires more operations this may lead to live range increasing ( for live variables computed by first operand). If we swap these operands we get live range shrinking which is essential for 32-bit targets having only few registers. Are there any benefits for operand canonicalization for x86-64? Testcases in r216728 seems to indicate that it is a good thing to do. There may be a case where operand canonicalization even wins for x86.
[Bug tree-optimization/64434] [5 Regression] Performance regression after operand canonicalization (r216728).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434 --- Comment #10 from rguenther at suse dot de rguenther at suse dot de --- On December 29, 2014 5:56:25 PM CET, ysrumyan at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434 --- Comment #8 from Yuri Rumyantsev ysrumyan at gmail dot com --- The issue is caused by operand canonicalization, i.e. there is special operand odering for commutative operations to have the same representation for a + b and b + a. If computation of second operand requires more operations this may lead to live range increasing ( for live variables computed by first operand). If we swap these operands we get live range shrinking which is essential for 32-bit targets having only few registers. Hope it will help you to understand the problem. This is essentially a scheduling issue (and thus also related to TER). I played with the idea of a SSA life-range reducing BB scheduling without much success. The trick of swapping operands to expand the expensive one first sounds good to me. 2014-12-29 19:36 GMT+03:00 hjl.tools at gmail dot com gcc-bugzi...@gcc.gnu.org: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434 --- Comment #7 from H.J. Lu hjl.tools at gmail dot com --- r216728 generates much longer code sequences. Where does it come from? Does -m64 also generate longer code sequences? -- You are receiving this mail because: You reported the bug.
[Bug fortran/47674] gfortran.dg/realloc_on_assign_5.f03: Segfault at run time for deferred (allocatable) string length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47674 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org --- Comment #9 from Thomas Koenig tkoenig at gcc dot gnu.org --- I have a patch (not a pretty one, though).
[Bug fortran/60357] [F08] structure constructor with unspecified values for allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60357 --- Comment #11 from Andre Vehreschild vehre at gmx dot de --- Hi Janus, before you invest too much time into that: My current patch level produces intermediate code as attached (for a slightly different program, also attached). I was solving the (re-)alloc on assign issue like in PR61275. I now run into the runtime error: At line 15 of file test_pr60357.f08: Attempting to allocate already allocated variable 'de'. Obviously I have over fullfilled the needed allocs: (1) a.5.y is allocated (2) a.4.y is allocated (3) a.0.y is allocated (4) de.y is allocated (5) a.2.y is allocated I am wondering which allocs should really be done, and which one are accidently added. I doubt that (1) and (2) should be there. (3) and (5) are ok imho. Now my client (the reporter of the bug, Antony) tells me, that (4) is valid Fortran (valid by ifort), but the allocate(De%y) is useless there, as it is freed before the constructor assign with implicit alloc is done. With my current patch level, your program would be running fine, because I would auto alloc y on the assignment. To summarize my questions: Which allocs should be done? Given the too allocs in (1) and (2) are removed, would the intermediate code be correct for the fortran? Can you help me on this. Regards, Andre On Mon, 29 Dec 2014 16:42:01 + janus at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60357 --- Comment #10 from janus at gcc dot gnu.org --- (In reply to Andre Vehreschild from comment #9) I just need to figure, if allocating the component explicitly is valid in Fortran. For sure. I think both the examples in comment 4 and 5 are actually valid Fortran code. In order to make sure we're talking about the same thing, let's have a look at the following code: Type A integer :: X = 1 integer, allocatable :: y end type Type(A) :: Me allocate(Me%y) print *,A Me = A(X=1, y=2) print *,B print *, Me%y end This is a variant of the example above that produced the segfault. I inserted some print statements in order to debug it. It prints at runtime: A B Program received signal SIGSEGV: Segmentation fault - invalid memory reference. This shows clearly that the segfault occurs when we try to access Me%y in the last print statement, meaning that it is probably unallocated although it clearly should be. -fdump-tree-original shows that the problem is in the translation of the structure constructor assignment, which apparently leaves the y-component unallocated.
[Bug fortran/60357] [F08] structure constructor with unspecified values for allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60357 --- Comment #12 from Andre Vehreschild vehre at gmx dot de --- Created attachment 34353 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34353action=edit test_pr60357.f08
[Bug fortran/60289] allocating class(*) pointer as character gives type-spec requires the same character-length parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60289 --- Comment #5 from Andre Vehreschild vehre at gmx dot de --- Patch available in: https://gcc.gnu.org/ml/fortran/2014-12/msg00133.html
[Bug regression/64437] New: hang with iconv on the configure : checking whether the C compiler works
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64437 Bug ID: 64437 Summary: hang with iconv on the configure : checking whether the C compiler works Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression Assignee: unassigned at gcc dot gnu.org Reporter: dark_footix at yahoo dot fr Created attachment 34354 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34354action=edit mipsel-linux-uclibc config file for buildroot Hi, I create a mips toolchain 4.9.2 with the config file in attachment. For the gcc in result, I try to configure the iconv, but the pc freeze on the log checking whether the C compiler works Do you have some advice ?
[Bug libstdc++/53579] libstdc++ configure use CXXFLAGS instead of CXXFLAGS_FOR_TARGET
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53579 --- Comment #3 from Anatol anatol.pomozov at gmail dot com --- I just hit this issue when tried to build cross-tools for arm64. CFLAGS_FOR_TARGET works as expected and I was assuming that CXXFLAGS_FOR_TARGET is used instead of CXXFLAGS. If CXXFLAGS_FOR_TARGET is not honored now, what is recommended workaround for cross-compilers that need different CXXFLAGS for host and target?
[Bug regression/64437] hang with iconv on the configure : checking whether the C compiler works
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64437 --- Comment #1 from fredm dark_footix at yahoo dot fr --- Created attachment 34355 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34355action=edit configure file of iconv checking whether the C compiler works appear line 4048
[Bug regression/64437] hang with iconv on the configure : checking whether the C compiler works
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64437 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-12-29 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- Yes how did you configure GCC? Run gdb on the resulting compiler to see why it is hanging.
[Bug regression/64437] hang with iconv on the configure : checking whether the C compiler works
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64437 --- Comment #3 from fredm dark_footix at yahoo dot fr --- configure:4058: checking whether the C compiler works configure:4080: ccache /home/sah0027/worksets/5.2.11e38_7241/sources/hardco/toolchain/broadcom/PROJ/broadcom_4.9.2/MAIN/bin/mipsel-linux-gcc -O2 -ggdb3 -fPIC -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -fdiagnostics-color=always -isystem /home/sah0027/worksets/5.2.11e38_7241/build/build/DEV/PROJ/ETISALAT/REL/2014-10-21_V8.0.7e2/output/staging/include -isystem /home/sah0027/worksets/5.2.11e38_7241/build/build/DEV/PROJ/ETISALAT/REL/2014-10-21_V8.0.7e2/output/staging/usr/include -L/home/sah0027/worksets/5.2.11e38_7241/build/build/DEV/PROJ/ETISALAT/REL/2014-10-21_V8.0.7e2/output/staging/lib -L/home/sah0027/worksets/5.2.11e38_7241/build/build/DEV/PROJ/ETISALAT/REL/2014-10-21_V8.0.7e2/output/staging/usr/lib -Wl,-rpath-link,/home/sah0027/worksets/5.2.11e38_7241/build/build/DEV/PROJ/ETISALAT/REL/2014-10-21_V8.0.7e2/output/staging/lib -Wl,-rpath-link,/home/sah0027/worksets/5.2.11e38_7241/build/build/DEV/PROJ/ETISALAT/REL/2014-10-21_V8.0.7e2/output/staging/usr/lib conftest.c 5
[Bug regression/64437] hang with iconv on the configure : checking whether the C compiler works
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64437
--- Comment #4 from fredm dark_footix at yahoo dot fr ---
cat conftest.c
/* confdefs.h */
#define PACKAGE_NAME
#define PACKAGE_TARNAME
#define PACKAGE_VERSION
#define PACKAGE_STRING
#define PACKAGE_BUGREPORT
#define PACKAGE_URL
#define PACKAGE libiconv
#define VERSION 1.14
/* end confdefs.h. */
int
main ()
{
;
return 0;
}
[Bug target/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|WAITING |NEW --- Comment #7 from H.J. Lu hjl.tools at gmail dot com --- Confirmed.
[Bug sanitizer/64435] [5.0.0 Regression] Bootstrap failure in libsanitizer on AArch64 with Linux kernel = 3.15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435 --- Comment #1 from David Abdurachmanov david.abdurachmanov at gmail dot com --- Created attachment 34356 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34356action=edit RFC patch (tested) Bootstrapped on aarch64-linux-gnu machine with F19 + 3.12 and on QEMU with F21 + 3.17.
[Bug sanitizer/64435] [5.0.0 Regression] Bootstrap failure in libsanitizer on AArch64 with Linux kernel = 3.15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435 --- Comment #2 from David Abdurachmanov david.abdurachmanov at gmail dot com --- linux/version.h does not bring any additional kernel headers, its fully standalone and seems fine to include. There might be a problem is someone builds a distribution with GCC 5 and kernel =3.15 and then decides to update the kernel creating mismatch with libsanitizer.
[Bug libstdc++/64438] New: Removing string-conversion requirement causes libstdc++-v3 fails on AArch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64438 Bug ID: 64438 Summary: Removing string-conversion requirement causes libstdc++-v3 fails on AArch64. Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: belagod at gcc dot gnu.org This patch: https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01780.html causes UNSUPPORTED tests to get compiled on AArch64. FAIL: 21_strings/basic_string/numeric_conversions/char/dr1261.cc (test for excess errors) UNRESOLVED: 21_strings/basic_string/numeric_conversions/char/dr1261.cc compilation failed to produce executable FAIL: 21_strings/basic_string/numeric_conversions/char/stod.cc (test for excess errors) UNRESOLVED: 21_strings/basic_string/numeric_conversions/char/stod.cc compilation failed to produce executable FAIL: 21_strings/basic_string/numeric_conversions/char/stof.cc (test for excess errors) UNRESOLVED: 21_strings/basic_string/numeric_conversions/char/stof.cc compilation failed to produce executable FAIL: 21_strings/basic_string/numeric_conversions/char/stoi.cc (test for excess errors) UNRESOLVED: 21_strings/basic_string/numeric_conversions/char/stoi.cc compilation failed to produce executable FAIL: 21_strings/basic_string/numeric_conversions/char/stol.cc (test for excess errors) UNRESOLVED: 21_strings/basic_string/numeric_conversions/char/stol.cc compilation failed to produce executable FAIL: 21_strings/basic_string/numeric_conversions/char/stold.cc (test for excess errors) UNRESOLVED: 21_strings/basic_string/numeric_conversions/char/stold.cc compilation failed to produce executable FAIL: 21_strings/basic_string/numeric_conversions/char/stoll.cc (test for excess errors) UNRESOLVED: 21_strings/basic_string/numeric_conversions/char/stoll.cc compilation failed to produce executable FAIL: 21_strings/basic_string/numeric_conversions/char/stoul.cc (test for excess errors) UNRESOLVED: 21_strings/basic_string/numeric_conversions/char/stoul.cc compilation failed to produce executable FAIL: 21_strings/basic_string/numeric_conversions/char/stoull.cc (test for excess errors) UNRESOLVED: 21_strings/basic_string/numeric_conversions/char/stoull.cc compilation failed to produce executable FAIL: 21_strings/basic_string/numeric_conversions/char/to_string.cc (test for excess errors) UNRESOLVED: 21_strings/basic_string/numeric_conversions/char/to_string.cc compilation failed to produce executable
[Bug target/53988] [SH] tst Rm,Rn not used for QI/HImode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53988
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed||2014-12-29
Resolution|FIXED |---
Ever confirmed|0 |1
--- Comment #4 from Oleg Endo olegendo at gcc dot gnu.org ---
The change in r192982 results in wrong code:
int test (short x, short* y, int z, int w)
{
return x y[0] ? z : w;
}
mov.w @r5,r1// sign extended y[0], bits[31:16] = 1
tst r4,r1 // r4 bits [31:16] undefined
bf .L5
mov r7,r0
rts
nop
.align 1
.L5:
rts
mov r6,r0
The *tstmode_t_zero insns blindly accept subregs. They have to check whether
both operands have been sign extended or at least one of them has been zero
extended (to mask out the unwanted high bits).
[Bug target/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |5.0
[Bug target/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412 --- Comment #8 from H.J. Lu hjl.tools at gmail dot com --- Created attachment 34357 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34357action=edit A patch Can you try this?
[Bug c/64439] New: Incorrect location of -Wunused-value or false negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64439
Bug ID: 64439
Summary: Incorrect location of -Wunused-value or false negative
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chengniansun at gmail dot com
For the expression a ((b = 0) != 0), GCC warns that the expression value
((b = 0) != 0) is not used. Should it point to the whole expression rather
this sub-expression? Or this is a false negative of -Wunused-value?
$: cat s.c
void f(int a, int b) {
a ((b = 0) != 0);
}
$:
$: gcc-trunk -c -Wunused-value s.c
s.c: In function ‘f’:
s.c:2:17: warning: value computed is not used [-Wunused-value]
a ((b = 0) != 0);
^
$:
$: clang-trunk -c -Wunused-value s.c
s.c:2:5: warning: expression result unused [-Wunused-value]
a ((b = 0) != 0);
~ ^ ~~
1 warning generated.
$:
$:
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
--- Comment #7 from Harald Anlauf anlauf at gmx dot de ---
(In reply to Harald Anlauf from comment #5)
(In reply to Francois-Xavier Coudert from comment #4)
If you have another idea, please post a list of what you think should happen
in all various cases (all possible combinations of arguments have to be
allowed).
Let's see:
- For any number of arguments present (1, 2 or 3)
- always integer(4): msec resolution (as before)
- always integer(=8): usec resolution (or whatever is possible)
- always real: I don't care, but I think it might be a good idea
to use the same as for integer of a compatible kind.
- different types and/or kinds: I don't care, since one should
expect problems (wrapping or truncation) anyway.
But presence of non-presence should never make a difference
if consistent types and kinds are used.
I played around with other compilers and posted the result at:
https://groups.google.com/forum/?hl=en#!topic/comp.lang.fortran/5aoFFRNBP0g
The only compiler that allows for different timer resolutions and
produces an at least self-consistent result appears to be Intel.
It actually treats each argument separately: if it is a 4-byte
argument, it returns values referring to the low-res (0.1 msec) version;
for an 8-byte argument one gets the high-res (1 usec) version.
(Confirmed by looking at the explicit assembler code).
That would be even simpler than any of the versions I discussed above.
The actual implementation then might generate a call to
_gfortran_system_clock_{4,8} for each present argument,
with the respective kind taken into account.
[Bug c++/64422] basic_string::erase is unresloved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64422 Bernd Edlinger bernd.edlinger at hotmail dot de changed: What|Removed |Added Attachment #34341|0 |1 is obsolete|| --- Comment #3 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Created attachment 34358 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34358action=edit Proposed Fix updated, with test case.
[Bug fortran/55534] -Wno-missing-include-dirs does not work with gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55534 --- Comment #9 from Harald Anlauf anlauf at gmx dot de --- (In reply to Manuel López-Ibáñez from comment #8) (In reply to Manuel López-Ibáñez from comment #7) The ideal fix for this would adding a function like: I forgot about this bug and redid the above from scratch. But this time, I actually tested that it works: https://gcc.gnu.org/ml/fortran/2014-10/msg00019.html Has this patch been applied? I checked r219084. The bug is still there: % gfc-trunk -Wno-missing-include-dirs xxx.f90 -I /no/such/dir f951: Warning: Nonexistent include directory '/no/such/dir' [-Wmissing-include-dirs] At least I now see the colors...
[Bug target/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412 --- Comment #9 from iverbin at gcc dot gnu.org --- (In reply to H.J. Lu from comment #8) Created attachment 34357 [details] A patch Can you try this? Thank you, e.53.5.c now passed. However for-3.c and for-11.C still fails with another unrecognizable insn. I attached reduced testcase (pr64412_2).
[Bug target/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412 --- Comment #10 from iverbin at gcc dot gnu.org --- Created attachment 34359 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34359action=edit pr64412_2.c
[Bug target/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412 --- Comment #11 from iverbin at gcc dot gnu.org --- Created attachment 34360 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34360action=edit pr64412_2.s
[Bug target/57037] GCC does not generate non-temporal stores on i386 with SSE2+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57037 --- Comment #1 from Harald Anlauf anlauf at gmx dot de --- (In reply to Harald Anlauf from comment #0) gfortran (using -Ofast -fprefetch-loop-arrays) exactly reproduces the performance of the Intel compiler without temporal stores. It appears that this is an important optimization. I tried a current snapshot from trunk (r219084) and found that -fprefetch-loop-arrays now gives an additional boost, matching Intel v15 for the above code, even without the streaming stores.
[Bug c/64423] Incorrect column number of -Wchar-subscripts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64423 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |5.0 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Let me take a look (next week).
[Bug target/63681] ICE in cfg_layout_initialize, at cfgrtl.c:4233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63681 --- Comment #5 from Mikael Pettersson mikpelinux at gmail dot com --- The ICE on bfin-elf started for 4.9 with r204985, and stopped for 5.0 with r210683. Backporting r210683 to current 4.9 branch is easy and fixes the ICE there too. I haven't checked c6x. See also: https://gcc.gnu.org/ml/gcc-patches/2014-01/msg6.html https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01725.html
[Bug fortran/55534] -Wno-missing-include-dirs does not work with gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55534 --- Comment #10 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Harald Anlauf from comment #9) (In reply to Manuel López-Ibáñez from comment #8) (In reply to Manuel López-Ibáñez from comment #7) The ideal fix for this would adding a function like: I forgot about this bug and redid the above from scratch. But this time, I actually tested that it works: https://gcc.gnu.org/ml/fortran/2014-10/msg00019.html Has this patch been applied? An equivalent one has. The remaining problem (I think) is that the warning is given when -I is processed, so the order of -I and -Wno-missing-include-dirs matters. In your example, the order should be correct, but the driver unhelpfully re-orders the command-line as: f951 xxx.f90 -I /no/such/dir -quiet -dumpbase xxx.f90 -mtune=generic -march=x86-64 -auxbase xxx -Wno-missing-include-dirs -fintrinsic-modules-path finclude -o /tmp/ccwz8Va5.s If I invoke f951 manually, it works: f951 -Wno-missing-include-dirs ~/xxx.f90 -I /no/such/dir -Wno-missing-include-dirs However, if I invoke it like this it doesn't work: f951 -Wno-missing-include-dirs ~/xxx.f90 -I /no/such/dir -Wno-missing-include-dirs because prune_options removes duplicated options by keeping the last one. Thus, the fix is either to buffer the arguments to -I and process them after all options have been processed or move just the warning code to such a latter phase. I'm not sure what is simpler. This is what the C/C++ FE does (see incpath.c add_path, which is called when -I is processed and c-opts.c register_include_chains, which is called after options processing and gives the diagnostics). Note that this applies to all warnings given by add_path_to_list, since ideally they should be disabled by --no-warnings (aka -w), but currently it depends on the order they are given.
Opportunity Never Wait for Anybody : New Session Announcement For Distance Learning Courses
Get MBA, E-MBA , MMS, DMS, PGDBM ,DBM etc done without disturbing your job... Any Certificate NO Donation / Percentage Barrier International Attestations by Ministry of External Affairs and Foreign Affairs (Charges apply*) GIVE US AN OPPORTUNITY TO MAKE YOUR CAREER: Please reply to this mail providing following details to obtain detail information about our Institute, Course, Exams etc. Name: Contact No.: Email id : Course of Interest: Specialization: Query: Qualifications Work Experience : Address Details: When you're ready to make the time, my help is just a phone call or e-mail away. With your success in mind, For ISMS Indian School of Management Studies, Anushka ISMS Email :- anus...@ismsedu.com Website :- www.ismsedu.com
[Bug target/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Attachment #34357|0 |1 is obsolete|| --- Comment #12 from H.J. Lu hjl.tools at gmail dot com --- Created attachment 34361 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34361action=edit A new patch Please try the new patch.
[Bug c++/64433] Segmentation fault while compiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64433 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org --- Issue is access of the type of a COMPONENT_REF in finish_offsetof. For the template the COMPONENT_REF has NULL_TREE type. Actually it seems that we should check here for in-template case.
[Bug c/64439] Incorrect location of -Wunused-value or false negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64439 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org --- It doesn't seem a false negative to me. It is a bit strange that we get different locations for equivalent expressions: s.c:2:17: warning: value computed is not used [-Wunused-value] a ((b = 0) != 0); ^ s.c:3:18: warning: value computed is not used [-Wunused-value] ((b = 0) != 0) a; ^ But I'm not sure if it is a bug. Someone would need to look at gcc while compiling the testcase under a debugger to understand why the difference exists at all.
[Bug regression/64437] hang with iconv on the configure : checking whether the C compiler works
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64437 fredm dark_footix at yahoo dot fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #5 from fredm dark_footix at yahoo dot fr --- Sorry, I did a mismatch of pre build lib with my previous toolchain This bug is closed
[Bug c/64440] New: -Wdiv-by-zero false negative on const variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64440
Bug ID: 64440
Summary: -Wdiv-by-zero false negative on const variables
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chengniansun at gmail dot com
In the following test case, the variable b is constant zero. However, GCC
does not warn div-by-zero on the expression a / b. More details are shown as
below:
$: cat t.c
int f (int a) {
const int b = 0;
return a / b;
}
$:
$: gcc-trunk -c -Wdiv-by-zero t.c
$:
$: clang-trunk -c -Wdivision-by-zero t.c
t.c:3:12: warning: division by zero is undefined [-Wdivision-by-zero]
return a / b;
^ ~
1 warning generated.
$:
[Bug c/64440] -Wdiv-by-zero false negative on const variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64440 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- In C, const int is not a constant expression and -Wdiv-by-zero only warns about integer constant expressions.
[Bug fortran/52010] [OOP] Intrinsic assignment of a CLASS to a TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52010 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added CC||damian at sourceryinstitute dot or ||g --- Comment #8 from Paul Thomas pault at gcc dot gnu.org --- In fact, it appears that both tests are fixed by the current patch in PR63205. This works fine: module m_test implicit none type ta private integer :: i = 99 contains procedure :: suba end type ta type tb private class(ta), pointer :: pa = null() contains procedure :: disp end type tb contains function suba( a, v) result(b) class(ta), target, intent(inout) :: a type(tb) :: b integer :: v a%i = v b%pa = a end function suba subroutine disp (arg) class(tb), intent(in) :: arg print *, arg%pa%i end subroutine end module m_test use m_test class(ta), allocatable :: tgt type(tb) :: PTR allocate (tgt) ptr = tgt%suba(42) call ptr%disp deallocate (tgt) end Paul
[Bug bootstrap/50139] in-tree GMP/PPL/CLooG is misconfigured
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50139 --- Comment #3 from nightstrike nightstrike at gmail dot com --- Both cloog and ppl have been removed from GCC in favor of just isl. GCC 4.8 removes ppl in 2012: https://gcc.gnu.org/ml/gcc-patches/2012-06/msg01470.html GCC 5.0 removes cloog: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01167.html There's other relevant posts, but you get the idea. Anyway, this should eventually be closed.
[Bug c/64440] -Wdiv-by-zero false negative on const variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64440
--- Comment #2 from Chengnian Sun chengniansun at gmail dot com ---
(In reply to Andrew Pinski from comment #1)
In C, const int is not a constant expression and -Wdiv-by-zero only warns
about integer constant expressions.
Thanks for your reply. It seems GCC sometimes does consider const int for
other types of warnings (but not for -Wdiv-by-zero). See the following, with
-O3, GCC warns that the left shift count is negative.
$: cat t.c
int f(int a) {
const char c = -4;
return a c;
}
$: gcc-trunk -Wall -c t.c -O3
t.c: In function ‘f’:
t.c:3:12: warning: left shift count is negative
return a c;
^
$:
