Re: GCC Testsuite patches break AIX
On Wed, 27 May 2020 at 22:40, Alexandre Oliva wrote:
>
> On May 27, 2020, Christophe Lyon via Gcc wrote:
>
> > On Wed, 27 May 2020 at 16:26, Jeff Law via Gcc wrote:
>
> >> Any thoughts on the massive breakage on the embedded ports in the
> >> testsuite?
>
> I wasn't aware of any. Indeed, one of my last steps before submitting
> the patchset was to fix problems that had come up in embedded ports,
> with gcc_adjust_linker_flags and corresponding changes to outputs.exp
> itself.
>
> >> Essentially every test that links is failing like this:
>
>
> >>
> >> > Executing on host:
> >> > /home/jenkins/workspace/c6x-elf/c6x-elf-obj/gcc/gcc/xgcc
> >> > -B/home/jenkins/workspace/c6x-elf/c6x-elf-obj/gcc/gcc/
> >> > /home/jenkins/gcc/gcc/testsuite/gcc.c-torture/execute/2112-1.c
> >> > gcc_tg.o-fno-diagnostics-show-caret
> >> > -fno-diagnostics-show-line-numbers
> >> > -fdiagnostics-color=never -fdiagnostics-urls=never-O0 -w -msim
> >> > {} {} -
> >> > Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm -o
> >> > ./2112-1.exe(timeout = 300)
> >> > spawn -ignore SIGHUP
> >> > /home/jenkins/workspace/c6x-elf/c6x-elf-obj/gcc/gcc/xgcc
> >> > -B/home/jenkins/workspace/c6x-elf/c6x-elf-obj/gcc/gcc/
> >> > /home/jenkins/gcc/gcc/testsuite/gcc.c-torture/execute/2112-1.c
> >> > gcc_tg.o
> >> > -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
> >> > -fdiagnostics-
> >> > color=never -fdiagnostics-urls=never -O0 -w -msim -Wl,-wrap,exit -Wl,-
> >> > wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm -o ./2112-1.exe^M
> >> > xgcc: error: : No such file or directory^M
>
> >> Sadly there's no additional output that would help us figure out what went
> >> wrong.
>
> > If that helps, I traced this down to the new gcc_adjust_linker_flags
> > function.
>
> Thanks. Yeah, H-P observed and submitted a similar report that made me
> wonder about empty arguments being passed to GCC. Jeff's report
> confirms the suspicion. See how there are a couple of {}s after -msim
> in the "Executing on host" line, that in the "spawn" line are completely
> invisible, only suggested by the extra whitespace. That was not quite
> visible in H-P's report, but Jeff's makes it clear.
>
> I suppose this means there are consecutive blanks in e.g. board's
> ldflags, and the split function is turning each consecutive pair of
Yes, I'm seeing this because of
set_board_info ldflags "[libgloss_link_flags] [newlib_link_flags]
$additional_options"
in arm-sim.exp
> blanks into an empty argument. I'm testing a fix (kludge?) in
> refs/users/aoliva/heads/testme 169b13d14d3c1638e94ea7e8f718cdeaf88aed65
>
> --
> Alexandre Oliva, freedom fighterhe/himhttps://FSFLA.org/blogs/lxo/
> Free Software Evangelist Stallman was right, but he's left :(
> GNU Toolchain Engineer Live long and free, and prosper ethically
g++ compiler produces an error on Redhat Linux # 4.8.5-39
Team, We have been compiling cpp files with g++ compiler on Redhat Linux OS machine and as part of this -mt option was given for g++ and it produced required binary in case # 1 but produced an error in case#2 , I'm sharing g++ version and the Redhat Linux OS version being used to compile the cpp code details below .. Can you please let us know what is the meaning of flag -mt and why it works in case#1 but not in case#2 Case#1 -- g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-23) Case# 2 g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39) In this case the error produced by compiler is g++: error: unrecognized command line option -mt your help will be greatly appreciated . Thanks, Kiran
Transitioning to a new Xtensa Port Maintainer
After a long run as the Xtensa port maintainer, it is time for me to move on. I nominate Max Filippov [cc'd] as the new maintainer. He has contributed numerous patches over the years which have required minimal comments from me. If there is anything I need to do to facilitate this, let me know. I'm happy to still review patches when needed. Thanks, Sterling Augustine
Re: g++ compiler produces an error on Redhat Linux # 4.8.5-39
Your question is inappropriate on this mailing list, and I already answered it on the gcc-help list anyway. On Thu, 28 May 2020 at 18:22, kiran kumar vangara via Gcc wrote: > > Team, > > We have been compiling cpp files with g++ compiler on Redhat Linux OS > machine and as part of this -mt option was given for g++ and it produced > required binary in case # 1 but produced an error in case#2 , I'm sharing > g++ version and the Redhat Linux OS version being used to compile the cpp > code details below .. Can you please let us know what is the meaning of > flag -mt and why it works in case#1 but not in case#2 > > Case#1 > -- > g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-23) > > Case# 2 > > g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39) > > In this case the error produced by compiler is > > g++: error: unrecognized command line option -mt > > your help will be greatly appreciated . > > Thanks, > Kiran
Re: PCH test errors
On 27/05/2020 15:46, Andrew Stubbs wrote: I'm testing amdgcn-amdhsa, and I get lot of PCH test failures with errors like this: gcc.dg/pch/common-1.c:1:22: error: one or more PCH files were found, but they were invalid gcc.dg/pch/common-1.c:1:22: error: use -Winvalid-pch for more information gcc.dg/pch/common-1.c:1:10: fatal error: common-1.h: No such file or directory Hi Alexandre, I've created a test toolchain for you on the GCC compute farm: gcc14.fsffrance.org Please see /home/ams_cs/gccobj and /home/amd_cs/install. I ran "make check RUNTESTFLAGS=pch.exp" already, so you should be able to see the errors in gcc/testsuite/gcc/gcc.log. The sources and objects are set world writeable, so you should be able to experiment (please set "umask 0" so I can clean up after). Andrew
Two new proposals to the upcoming C2X standard
Hello gcc team,
I have sent the following proposals to the committee, but they require them to
be implemented at least into two major compilers, so I am proposing them to be
implemented into gcc. This is going to be a rather lengthy e-mail, so TL;DR:
Proposal 1: New pointer-proof keyword _Lengthof to determine array length
Motivation: solve silent bugs when a pointer is accidentally used instead of an
array
Proposal 2: Allow compound literals of static lifetime inside body functions
Motivation: self-explanatory
Proposal 1: New pointer-proof keyword to determine array length
---
Extracting the number of elements in an array is a typical operation on C
programs, as relying on magic constants or macros is very error-prone and will
cause undefined behavior if the size of the array is somehow modified.
Typically, most developers use the following operation to determine the number
of elements inside an array, usually via a user-defined macro like #define
ARRAY_SIZE(a) sizeof (a) / sizeof *(a)
However, there is a well-known issue that occurs when a pointer is (most times
accidentally) used instead of an array. Despite the similarities between
pointers and arrays, a pointer will much likely return an unexpected value when
this construct is used, creating a silent error that can be only detected at
run-time.
By using C11 features and GNU extension typeof, the ARRAY_SIZE macro can be
improved so it returns a compile-time error when a pointer is given instead of
an array:
#define ARRAY_SIZE(a) \
_Generic(&(a), \
typeof (*a)**: (void)0, \
typeof (*a)*const *: (void)0, \
default: sizeof (a) / sizeof ((a)[0]))
If this macro was used on the example above, the following compile-time error
would trigger:
$ gcc lengthof.c -std=gnu11
lengthof.c: In function ‘foo’:
lengthof.c:7:30: error: void value not ignored as it ought to be
typeof (*a)*const *: (void)0, \
^~~
lengthof.c:11:29: note: in expansion of macro ‘ARRAY_SIZE’
for (size_t i = 0 ; i < ARRAY_SIZE(arr); i++) {
^~
However, error description is vague and confusing to the developer, and the GNU
extension typedef is not part of the standard, as of C11.
Since there is no portable, pointer-proof way to determine the number of
elements of an array, this document suggests adding a new keyword to the C
standard that aims not to introduce any breaking changes to existing code.
According to the standard, symbol names preceded by a leading underscore and a
capital letter or another underscore are reserved for the implementation.
Therefore, the _Lengthof operator is suggested, aiming to provide the same
functionality as the ARRAY_SIZE macro above, while providing better diagnostic
messages when a pointer is accidentally given.
The example above has been modified by introducing this new _Lengthof operator:
#include
#include
int main(const int argc, const char *argv[]) {
int arr[] = {1, 2, 3, 4, 5, 6};
for (size_t i = 0 ; i < _Lengthof arr; i++) {
printf("arr[%zu] = %d\n", i, arr[i]);
}
return 0;
}
Similarly to the sizeof operator, the _Lengthof operator returns a value of
type size_t that is resolved at compile-time, unless using _Lengthof on
variable-length arrays, where complexity is O(1), as in sizeof. Except from
this latter case, _Lengthof returns an integer constant that can be used with
other constructs such as _Static_assert. For example:
int main(const int argc, const char *argv[]) {
int arr[] = {1, 2, 3, 4, 5, 6};
_Static_assert (_Lengthof arr == 6);
return 0;
}
---
Proposal 2: Allow compound literals of static lifetime inside body functions
---
The current standard ISO/IEC 9899 6.5.2.5 (5) states:
“If the compound literal occurs outside the body of a function, the object has
static storage duration; otherwise, it has automatic storage duration
associated with the enclosing block.”
The following C11-compliant example provided below makes use of various C99
features (compound literals, designated initializers and variadic macros) and
allows defining an array of instances containing arrays of arbitrary size at
compile-time:
#include
#include
typedef const struct {
size_t len;
const char *buf;
} transfer;
#define TRANSFER(...) \
{ \
.len = sizeof (const char[]){__VA_ARGS__} \
/ sizeof *(const char[]){__VA_ARGS__}, \
.buf = (const char[]){__VA_ARGS__} \
}
static transfer tr[] = {
/* Using the optional convenience macro. */
TRANSFER(1, 2, 3, 4, 5, 6, 7, 8),
/* Or without using the optional convenience macro. */
{.len = 5, .buf = (const
gcc-8-20200528 is now available
Snapshot gcc-8-20200528 is now available on https://gcc.gnu.org/pub/gcc/snapshots/8-20200528/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-8 revision 83b84b6ef84ffc0ca25aef5c91720d8f82212a5c You'll find: gcc-8-20200528.tar.xzComplete GCC SHA256=73bb54a68f1ad2fdcfbeb2975666027ec95fd96100d6a04a6dd65c95e3267e4c SHA1=526fa43f8fd9dbbcdf789a280dbb2054b3016744 Diffs from 8-20200521 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: PCH test errors
On May 28, 2020, Andrew Stubbs wrote: > On 27/05/2020 15:46, Andrew Stubbs wrote: >> I'm testing amdgcn-amdhsa, and I get lot of PCH test failures with >> errors like this: >> >> gcc.dg/pch/common-1.c:1:22: error: one or more PCH files were found, >> but they were invalid >> gcc.dg/pch/common-1.c:1:22: error: use -Winvalid-pch for more information >> gcc.dg/pch/common-1.c:1:10: fatal error: common-1.h: No such file or >> directory > I've created a test toolchain for you on the GCC compute farm: > gcc14.fsffrance.org Thanks! I understand the problem, and I'm tempted to say it was a latent preexisting problem. gcn-hsa.h defines -mlocal-symbol-id=%b in CC1_SPEC. This is a target option not marked as pch_ignore, so option_affects_pch_p returns true for it, and default_pch_valid_p in targhooks.c compares the saved option in the PCH file with the active option in the current compilation. In our PCH tests, because of the design of the PCH testsuite, the basename of the header file matches the basename of the corresponding test file, so the compare used to pass. After the aux/dump revamp, %b changes in some link commands, and pch-creation commands look like link commands becuase they don't have -[cSE]. The link commands in which they don't change are those with a single input, when the output name is the basename of the input plus an optional executable extension. Since 'gcc foo.h -o foo.h.gch' is not such a command, %b becomes foo.h.gch-foo. That's what we'd use as basenames for dump and aux outputs, and that's what gets saved in the PCH file as local-symbol-id. The change to dumpbase in PCH commands was as desired. Though this is not a link command proper, one of the goals of the revamp was to arrange for separate compilations, with or without linking, to get different dump and aux outputs, even when compiling the same inputs. So, even if we were to recognize PCH as compilation commands, the presence of an explicit -o would (or should) derive from the output the basename that identifies the translation unit. Looking back at the PCH tests, there was no reason for the .h and the .c files of each test to share the same basename, it was just an implementation detail of the testsuite. Using a different name for the header would have caused the PCH tests to fail even before the revamp. I conclude from this that PCH was already mostly useless on this target, because of -mlocal-symbol-id. Marking -mlocal-symbol-id as PchIgnore in gcn.opt, as in the patchlet below, might be a proper fix for the problem, but I don't know enough about the target to tell whether doing so would be safe or correct. Andrew, do you? diff --git a/gcc/config/gcn/gcn.opt b/gcc/config/gcn/gcn.opt index 04c73d6..51e3878 100644 --- a/gcc/config/gcn/gcn.opt +++ b/gcc/config/gcn/gcn.opt @@ -71,7 +71,7 @@ Target Report RejectNegative Joined UInteger Var(stack_size_opt) Init(-1) -mstack-size= Set the private segment size per wave-front, in bytes. mlocal-symbol-id= -Target RejectNegative Report JoinedOrMissing Var(local_symbol_id) Init(0) +Target RejectNegative Report JoinedOrMissing IgnorePch Var(local_symbol_id) Init(0) Wopenacc-dims Target Var(warn_openacc_dims) Warning Another workaround, mainly for the testsuite, would be to recognize .h.gch as an executable extension in gcc.c, as in the patchlet below. Something conceptually like this, but further elaborated so as to recognize all cases of PCH compilation, and checking for the %i.gch pattern, would make the testsuite work for amdgcn-amdhsa even without ignoring -mlocal-symbol-id changes between PCH and compilations using it, and would avoid longer dump names in PCH compilations that used the default gch output name. PCH still wouldn't work on this target for other ways to name .gch files that GCC recognizes, such as those used by libstdc++-v3, and preserving %b unchanged for any of these possibilities just for -mlocal-symbol-id to work would defeat the purpose of the revamp, because then, building multiple such variants would get their dumps to overwrite each other. diff --git a/gcc/gcc.c b/gcc/gcc.c index e2362175f4..0a7410c 100644 --- a/gcc/gcc.c +++ b/gcc/gcc.c @@ -4973,6 +4973,7 @@ process_command (unsigned int decoded_options_count, : ((temp = strrchr (obase + 1, '.')) && (xlen = strlen (temp)) && (strcmp (temp, ".exe") == 0 +|| strcmp (temp, ".h.gch") == 0 #if defined(HAVE_TARGET_EXECUTABLE_SUFFIX) || strcmp (temp, TARGET_EXECUTABLE_SUFFIX) == 0 #endif So I see mainly the following courses of action: - if -mlocal-symbol-id can vary between PCH and PCH-using source, mark it as IgnorePch and the problem is fixed. - otherwise, change tests for PCH support so that different basenames are used, so it won't seem to work for this target. - regardless, it might make sense to implement the elaborate version of the gcc.c change above, to get shorter dump names in pch com
Re: Transitioning to a new Xtensa Port Maintainer
On Thu, May 28, 2020 at 10:12:04AM -0700, augustine.sterling--- via Gcc wrote: > After a long run as the Xtensa port maintainer, it is time for me to move > on. > > I nominate Max Filippov [cc'd] as the new maintainer. He has contributed > numerous patches over the years which have required minimal comments from > me. Sign him up by adding his name in binutils/MAINTAINERS. > If there is anything I need to do to facilitate this, let me know. I'm > happy to still review patches when needed. That sounds like you're not abandoning binutils entirely, so you could simply leave your name in binutils/MAINTAINERS where it is but put Max on the line before your entry. -- Alan Modra Australia Development Lab, IBM
Re: Transitioning to a new Xtensa Port Maintainer
Hi Alan, On Thu, May 28, 2020 at 7:53 PM Alan Modra via Gcc wrote: > > On Thu, May 28, 2020 at 10:12:04AM -0700, augustine.sterling--- via Gcc wrote: > > After a long run as the Xtensa port maintainer, it is time for me to move > > on. > > > > I nominate Max Filippov [cc'd] as the new maintainer. He has contributed > > numerous patches over the years which have required minimal comments from > > me. > > Sign him up by adding his name in binutils/MAINTAINERS. > > > If there is anything I need to do to facilitate this, let me know. I'm > > happy to still review patches when needed. > > That sounds like you're not abandoning binutils entirely, so you could > simply leave your name in binutils/MAINTAINERS where it is but put Max > on the line before your entry. I've committed this change to binutils/MAINTAINERS. -- Thanks. -- Max
[haifa-sched][DO_PREDICATION] execution test: wrong scheduling result.
Product: GCC
Component: rtl-optimization
Version: 7.3.0
After we enable the schedule DO_PREDICATION, we get wrong scheduling result in
sched2 pass.
The key dump is shown as following：
...(Unimportant things)
;; | 93 | 15 | a20=sxn([a19])
;; | 94 | 10 | t2=a20==0
;; | 95 |9 | pc={(t2!=0)?L107:pc}jump_insn1
;; | 159 | 10 | a21=0x8000
;; | 98 |9 | t0=a23!=a21
;; | 99 |8 | pc={(t0==0)?L173:pc}jump_insn2
;; | 105 |7 | a22=a23/a20 div_insn
;; | 106 |1 | a23=sxn(a22)
...(Unimportant things)
;; --- EBB Dependences --- from bb4 to bb6
;; insn codebb dep prio cost reservation
...(Unimportant things)
;; 9394 4 415 1 : 105(t,1) 99(a,0) 94(t,5)
;; 94 1645 4 110 1 : 106(t,1) 95(t,1)
;; 95 139 413 9 1 : 106(c,1) 99(a,1)nm
;; 159 129 5 010 1 : 98(t,1)
;; 98 1650 5 2 9 1 : 105(t,1) 106(t,1)m 99(t,1)
;; 99 139 515 8 1 : 105(c,1) 106(c,1)
;; 10537 6 4 7 1 : 106(t,6)m
;; 10694 6 6 1 1 :
...(Unimportant things)
When we enable the schedule DO_PREDICATION, we can produce conditional
execution insn.
Since insn 98(t0=a23!=a21) doesn't have dependence with jump_insn1 95
(pc={(t2!=0)?L107:pc}), so insn 98 can issue before jump_insn1 95.
And insn 93 (a20=sxn([a19])) can also issue before jump_insn1 95.
After that, insn 105(a22=a23/a20) can become conditional execution insn shown
as following dump:
;; 51--> 93 a20=sxn([a19]) :
rescanning insn with uid = 105.
;; dependencies resolved: insn105 predicated
;; Ready-->Q: insn105: queued for 1 cycles (change queue
index).
;; tick updated: insn105 into queue with cost=1
After predicating, insn 105 have become : [t0]a22=a23/a20
;; 52-->105 (t0) a22=a23/a20:
;; Ready list (t = 52):
...(Unimportant things)
;; Ready list (t = 56):94:50:prio=10
[52;56]:94
;; 56--> 94 t2=a20==0 :
...(Unimportant things)
;; Ready list (t = 57):95:51:prio=9
[56;57]:95
;; 57--> 95 pc={(t2!=0)?L107:pc}:
finally, insn 105([t0]a22=a23/a20) is issued before insn 95
(pc={(t2!=0)?L107:pc}).
However, insn 95 has decided reg a20 is valid not.
In this case, a20 is 0, so we get division by 0 error.
The scheduling result is shown as the following:
tstneq@ags t0, a23, a21 # [28] # 98
l16si@agl a20, a19, 0# [51] # 93
[t0] quos@sau a22, a23, a20 # [52] # 105
tsteqi@sau t2, a20, 0 # [53] # 94
[t2] b@pcu .L5, 1 # [54] # 95
[!t0] b@pcu .L28, 0# [55] # 99
..
Insn 105 (div_insn)should not be issued before insn 95(jump_insn1).
Note： This ebb is 3 basic-blocks.
Since supporting DO_PREDICATION target is little, it's difficult to recurrent
in other target.
How can we solve the problem?
Best wishes!
typedef long int ptrdiff_t;
typedef long unsigned int size_t;
typedef short unsigned int wchar_t;
typedef struct {
long long __max_align_ll __attribute__((__aligned__(__alignof__(long long;
long double __max_align_ld __attribute__((__aligned__(__alignof__(long
double;
} max_align_t;
typedef signed char __int8_t;
typedef unsigned char __uint8_t;
typedef short int __int16_t;
typedef short unsigned int __uint16_t;
typedef int __int32_t;
typedef unsigned int __uint32_t;
typedef long int __int64_t;
typedef long unsigned int __uint64_t;
typedef signed char __int_least8_t;
typedef unsigned char __uint_least8_t;
typedef short int __int_least16_t;
typedef short unsigned int __uint_least16_t;
typedef int __int_least32_t;
typedef unsigned int __uint_least32_t;
typedef long int __int_least64_t;
typedef long unsigned int __uint_least64_t;
typedef long int __intmax_t;
typedef long unsigned int __uintmax_t;
typedef long int __intptr_t;
typedef long unsigned int __uintptr_t;
typedef int _LOCK_T;
typedef int _LOCK_RECURSIVE_T;
typedef long __blkcnt_t;
typedef long __blksize_t;
typedef __uint64_t __fsblkcnt_t;
typedef __uint32_t __fsfilcnt_t;
typedef long _off_t;
typedef int __pid_t;
typedef short __dev_t;
typedef unsigned short __uid_t;
typedef unsigned short __gid_t;
typedef __uint32_t __id_t;
typedef unsigned short __ino_t;
typedef __uint32_t __mode_t;
__extension__ typedef long long _off64_t;
typedef _off_t __off_t;
typedef _off64_t __loff_t;
typedef long __key_t;
typedef long _fpos_t;
typedef long unsigned int __size_t;
typedef long signed int _ssize_t;
typedef _ssize_t __ssize_t;
typedef unsigned int wint_t;
typed
