Re: Vector pointer modes
On 16/05/18 22:01, Richard Sandiford wrote: Andrew Stubbs writes: Hi all, I'm in the process of trying to update our AMD GCN port from GCC 7 to GCC 8+, but I've hit a problem ... It seems there's a new assumption that pointers and addresses will be scalar, but GCN load instructions require vectors of pointers. Basically, machine_mode has been replaced with scalar_int_machine mode in many places, and we were relying on vector modes being allowed. The changes are all coming from the Richard Sandiford's SVE patches. FWIW, I think that assumption was always there. The scalar_int_mode patches just made it more explicit (as in, more code would fail to build if it wasn't honoured, rather than just potentially ICEing). It was fine if done late enough, but now it's just blocked in TARGET_ADDR_SPACE_POINTER_MODE et al. However, having now finished a first rough forward-port (with the relevant bits of these hooks commented out and gcc_unreachable), I find that vector loads and stores are working perfectly, and there are no related ICEs in the testsuite (although, with vector widths less than 64 still on the to-do list, a lot of the testsuite doesn't do much vectorizing). Is this mostly about the RTL level concept of an address or pointer? If so, in what situations do you need the address or pointer itself to be a vector? SVE and AVX use unspecs for gathers and scatters, and I don't think in practice we lose anything by doing that. As far as the ISA is concerned, *all* vector loads and stores are scatter/gather. In our port we model a normal, contiguous vector load/store as a DImode base pointer until reload_completed, and then have a splitter expand that into a V64DImode with the appropriate set of lane addresses. Ideally this would happen earlier, so as to allow CSE to optimize the expansion, but we've not got there yet (and, as you say, would probably hit trouble). Andrew
Re: I want to dump something when I compile the program. How should I do ?
Hi, On Thu, May 17 2018, 冠人 王 via gcc wrote: > My work is to modify the gcc source code so as to customize the warning > message, when the programmer writing the program violating some rules. > When the violation occurs, I want to reveal some message such as "guanjen375 > warning: the rule ### is violated" on the window. > How should I do ? Should I modify some file in the gcc source code so that I > can print my own message? > Besides, I want to realize how GCC code executed, so I want to insert some > code into GCC source code to check waht happens when those code > be executed. I try to use "printf" but failed, the message I print > reveals when I make(after configure), but not reveals at compile time For this purpose, use fprintf to write your debug message to stderr. Martin > If you do not really understand what do I say, let me show an example: > $gcc -Wunused test.c > test.c:5:6: warning: unused variable ‘a’ [-Wunused-variable] int a; ^ > becomes > $gcc -Wunused test.c > HI,DAVIDtest.c:5:6: warning: unused variable ‘a’ [-Wunused-variable] int a; > ^
So what's the status of the Git migration?
Another year; another release; and still no sign of progress on the git migration. Any ideas on how much longer this is going to take? R.
Re: So what's the status of the Git migration?
On Thu, 17 May 2018, Richard Earnshaw (lists) wrote: > Another year; another release; and still no sign of progress on the git > migration. > > Any ideas on how much longer this is going to take? See git://thyrsus.com/repositories/gcc-conversion.git for the current version of the conversion machinery, including a TODO list (and see also http://esr.ibiblio.org/?p=7959 ). Presumably required work on the GCC side (deciding appropriate policies on branch deletion / non-fast-forward pushes, developing hooks / repository configuration to implement those policies and send commit mails, writing updates to documentation and scripts) could be done in parallel with the conversion work, but Jason may already have some of that done anyway. -- Joseph S. Myers jos...@codesourcery.com
Re: Auto-generated .rodata contents and __attribute__((section))
Hi, On Wed, 16 May 2018, Richard Biener wrote: > > Are constant pool entries merged at compile time or at link time? I > > would presume it should be done at link time because otherwise you're > > only merging entries within a single compilation unit (which doesn't > > sound that useful in a big project with hundreds of source files), > > right? > > constant pool entries are merged at compile time. There's no such thing > as mergeable constant pool sections Actually there is in ELF. Mergable sections can not only hold strings, but also fixed-size entities (e.g. 4 or 8 byte constants). Those are merged content-wise at link time and references properly rewritten. Of course, those still aren't per-function. Ciao, Michael.
Re: So what's the status of the Git migration?
Richard Earnshaw (lists) : > Another year; another release; and still no sign of progress on the git > migration. > > Any ideas on how much longer this is going to take? > > R. I'm still working on it. It's a slow process because the repo is so huge that full conversions take around 9 hours each, That means that on a good day I can test naybe two point changes. The current issue - and, I think, the last major one - is that there are over 150 nid-branch deletes to be resolved. -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own.
Are the extended algorithms in the header file going to be supported by gcc ?
Hi, the good book "C++17 STL Cookbook" in chapter 9 "Parallelism and Concurrency" describes some of the 69 algorithms that were extended to accept execution policies in order to run parallel on multiple cores. And, according to the provided examples, they all greatly simplify some aspects of parallelization with the standard algorithms. I'm using Ubuntu 16.04 with upgraded gcc version 7.2.0 (Ubuntu 7.2.0-1ubuntu1~16.04) and the header file is not present. In the official gcc documentation: https://gcc.gnu.org/onlinedocs/libstdc++/ manual/status.html the support to is flagged as "no" in the Table 1.5. C++ 2017 Implementation Status, and it seems that it is even not foreseen to be included in the upgraded gcc 8 version: https://gcc.gnu.org/projects/cxx-status.html So, the crucial question about these 69 extended algorithms in the header file is: are these extended algorithms going to be supported by the next releases of gcc, as they are already supported by Visual Studio, and soon by clang ? Looking forward to your kind feedback about this extremely important aspect of gcc. Marco
Re: Are the extended algorithms in the header file going to be supported by gcc ?
There is work ongoing to complete C++17 support in libstdc++, this includes providing support for the C++17 parallel algorithms. Marco Ippolito writes: > Hi, > > the good book "C++17 STL Cookbook" in chapter 9 "Parallelism and > Concurrency" describes some of the 69 algorithms that were extended to > accept execution policies in order to run parallel on multiple cores. And, > according to the provided examples, they all greatly simplify some aspects > of parallelization with the standard algorithms. > > I'm using Ubuntu 16.04 with upgraded gcc version 7.2.0 (Ubuntu > 7.2.0-1ubuntu1~16.04) and the header file is not present. > > In the official gcc documentation: https://gcc.gnu.org/onlinedocs/libstdc++/ > manual/status.html the support to is flagged as "no" in > the Table 1.5. C++ 2017 Implementation Status, > and it seems that it is even not foreseen to be included in the upgraded > gcc 8 version: https://gcc.gnu.org/projects/cxx-status.html > > So, the crucial question about these 69 extended algorithms in the header > file is: > are these extended algorithms going to be supported by the next releases of > gcc, as they are already supported by Visual Studio, and soon by clang ? > > Looking forward to your kind feedback about this extremely important aspect > of gcc. > Marco
Business intelligence of Accounting Software
Hello, Would you be interested in acquiring newly released Accounting Software Contact Information? Our entire list comes with complete contact information including direct phone numbers and emails. We also have other specialist such as: Ø QuickBooks Software Users Ø Financial Analytical Applications Users Ø Ecommerce Users Ø ERP Users Ø Configure Price Quote (CPQ) Users Please let me know the below and I shall get back to you with other list details accordingly. Target Specialist___? Target Geography___? Hope to hear from you soon. Regards, Pamela Crawford - Marketing Analyst This is an attempt to begin a conversation with you. If you would rather not hear from us, please respond mentioning UNSUBSCRIBE in the subject line. If you are not the right person please forward this email to the right person in your organization.
Re: Auto-generated .rodata contents and __attribute__((section))
On Thu, May 17, 2018 at 06:10:13PM +0200, Michael Matz wrote: > On Wed, 16 May 2018, Richard Biener wrote: > > > Are constant pool entries merged at compile time or at link time? I > > > would presume it should be done at link time because otherwise you're > > > only merging entries within a single compilation unit (which doesn't > > > sound that useful in a big project with hundreds of source files), > > > right? > > > > constant pool entries are merged at compile time. There's no such thing > > as mergeable constant pool sections > > Actually there is in ELF. Mergable sections can not only hold strings, > but also fixed-size entities (e.g. 4 or 8 byte constants). Those are > merged content-wise at link time and references properly rewritten. Of > course, those still aren't per-function. It also works correctly in combination with -ffunction-sections, -fdata-sections, -Wl,--gc-sections. And not with per-function constant pools like on arm-linux; I'm not sure how that could ever work. Segher
gcc-7-20180517 is now available
Snapshot gcc-7-20180517 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20180517/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch revision 260339 You'll find: gcc-7-20180517.tar.xzComplete GCC SHA256=78acc1dbad063ca5b42887b993de25bda208f1ebde20c1475d6c008de14bb067 SHA1=0455eca25828df63d5649420603694e131f117d1 Diffs from 7-20180510 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 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.
