libstdc++-libc6.1-1.so.2 libraries
Below is the error I receive when attempting to run a newly installed version of netscape 4.79 on centOS 4.0 (RHEL 3), which is my personal computer at home. This is the only browser that works on linux that is compatible with the Thorium installer for BMC Patrol. I downloaded the browser from netscapes website browser archive and used the prepackaged installer script with all defaults. [EMAIL PROTECTED] ~]$ cd /opt/netscape [EMAIL PROTECTED] netscape]$ ./netscape ./netscape: error while loading shared libraries: libstdc++-libc6.1-1.so.2: cannot open shared object file: No such file or directory To correct this I intend to install the necessary libraries. At this point I'm only guessing and have googled my way to the conclusion that I need to install libstdc++2.9-glibc2.1 to get the libstdc++-libc6.1-1.so.2 libraries for this version of netscape to run. I am fairly certain that I did not install properly but even so if the libraries were there, shouldn't they be somewhere in the directory I installed this in (maybe not and please don't bother responding if this is too moronic to answer)? The command I used to search for this is: ls -la /usr/lib/gcc2/libstdc++-libc6.1-1.so.2 ls -la /usr/local/bin/libstdc++-libc6.1-1.so.2 /usr/lib/gcc2 is the objdir I built it in. I followed the installation instructions exactly with using only the default settings. The only setting I entered was the objdir ( objdir is /usr/lib/gcc2 ). Below are the exact steps I took. Extracted tarball to /home/bill/files/gcc/gcc-2.95.3 mkdir /usr/lib/gcc2 cd /usr/lib/gcc2 /home/bill/files/gcc/gcc-2.95.3/configure make bootstrap make install This is the output from running /home/bill/files/gcc/gcc-2.95.3/config.guess i686-pc-linux-gnu The reason I used /usr/lib/gcc2 was because the instuctions sounded like you could install two versions of gcc and make a symbolic link between them. I assumed the current version of gcc libraries would be in /usr/lib and just wanted to keep them together. If none of this makes any sense please do not attemt to make any out of it and let me know if this is even the correct package to install to get the libstdc++-libc6.1-1.so.2 libraries on my system...or just let me know where to download the right thing if it is even part of gccIf you are able to please let me know how to get this installed onto my system. Thanks in advance! Bill
Re: Threading the compiler
On Nov 10, 2006, at 9:08 PM, Geert Bosch wrote: Most people aren't waiting for compilation of single files. If they do, it is because a single compilation unit requires parsing/compilation of too many unchanging files, in which case the primary concern is avoiding redoing useless compilation. The common case is that people just don't use the -j feature of make because 1) they don't know about it 2) their IDE doesn't know about it 3) they got burned by bad Makefiles 4) it's just too much typing I'll mention a case where compilation was wickedly slow even when using -j#. At The MathWorks, the system could take >45 minutes to compile. (This was partially due to the fact that the files were located on an NFS mounted drive. But also because C++ compilation is way slower than C compilation.) Experiments with distributed make showed promise. It would be interesting to see if parallelizing the compiler (instead of just using 'make -j#') will give us an overall gain. Though it also seems fruitful to pursue some of the other optimizations you mentioned. -bw
Miscompilation...
Hi all,
This program:
#include
struct tree_type {
unsigned int precision : 9;
};
void *bork(const void *Ty, unsigned Subpart) {
printf("Subpart == %08x\n", Subpart);
return 0;
}
const void *TConvertType(tree_type* type) {
asm("movl $1104150528, (%%esp)" : : );
const void *Ty = 0;
return bork(Ty, type->precision);
}
const void *foo(tree_type* type) {
asm("movl $1104150528, (%%esp)" : : );
const void *Ty = 0;
unsigned S = type->precision;
return bork(Ty, S);
}
int main()
{
struct tree_type t;
t.precision = 1;
TConvertType(&t);
foo(&t);
return 0;
}
Compiled with "c++ t.c" Should print out:
Subpart == 0001
Subpart == 0001
But instead prints out:
Subpart == 8fe50001
Subpart == 0001
(on my iMac). The problem seems to be that, in the TConvertType
function passes
"type->precision" as an HI instead of SI to the "bork" function. The
asm code is:
movl $1104150528, (%esp)
movl$0, -4(%ebp)
movl8(%ebp), %eax
movzwl (%eax), %eax
andw$511, %ax
movw%ax, 4(%esp)
movl-4(%ebp), %eax
movl%eax, (%esp)
call__Z4borkPKvj
for TConvertType, so the %ax isn't putting a full SI onto the stack,
leaving
garbage in the MSBs of 4(%esp), which "bork" expects to be 0, of course.
I believe I got the TOT -- .svn/entries says "svn://gcc.gnu.org/svn/
gcc/trunk". Is
this a known problem?
Thanks!
-bw
Re: Miscompilation...
On Apr 8, 2007, at 6:50 PM, Bill Wendling wrote:
Hi all,
This program:
#include
struct tree_type {
unsigned int precision : 9;
};
void *bork(const void *Ty, unsigned Subpart) {
printf("Subpart == %08x\n", Subpart);
return 0;
}
const void *TConvertType(tree_type* type) {
asm("movl $1104150528, (%%esp)" : : );
This should be
asm("movl $1104150528, 4(%%esp)" : : );
const void *Ty = 0;
return bork(Ty, type->precision);
}
const void *foo(tree_type* type) {
asm("movl $1104150528, (%%esp)" : : );
Same here.
const void *Ty = 0;
unsigned S = type->precision;
return bork(Ty, S);
}
int main()
{
struct tree_type t;
t.precision = 1;
TConvertType(&t);
foo(&t);
return 0;
}
Compiled with "c++ t.c" Should print out:
Subpart == 0001
Subpart == 0001
But instead prints out:
Subpart == 8fe50001
Subpart == 0001
Which means that this outputs:
Subpart == 41d1
Subpart == 0001
(on my iMac). The problem seems to be that, in the TConvertType
function passes
"type->precision" as an HI instead of SI to the "bork" function.
The asm code is:
movl $1104150528, (%esp)
And this would be:
movl $1104150528, 4(%esp)
movl$0, -4(%ebp)
movl8(%ebp), %eax
movzwl (%eax), %eax
andw$511, %ax
movw%ax, 4(%esp)
movl-4(%ebp), %eax
movl%eax, (%esp)
call__Z4borkPKvj
for TConvertType, so the %ax isn't putting a full SI onto the
stack, leaving
garbage in the MSBs of 4(%esp), which "bork" expects to be 0, of
course.
I believe I got the TOT -- .svn/entries says "svn://gcc.gnu.org/svn/
gcc/trunk". Is
this a known problem?
Thanks!
-bw
Re: Miscompilation...
On Apr 8, 2007, at 11:35 PM, Dave Korn wrote: I believe I got the TOT -- .svn/entries says "svn://gcc.gnu.org/svn/ gcc/trunk". Is this a known problem? It's the first I've heard of it, please file a PR. I'm slightly amazed this hasn't been causing bootstrap breakage already, it looks really wrong. Done: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31513 Thanks for confirming this! -bw
PPC 64bit library status?
For what are probably misguided reasons I am trying to build Apple style compilers which include gfortran, libffi and libobjc. This was not a particular problem with the latest apple-ppc-branch sources (apple-ppc-5013) until I got MacOS X 10.4 Tiger yesterday. On Darwin8/MacOS X 10.4 the Apple gcc build includes both 32 and 64 bit versions of libgcc, libiberty and libstdc++. When I alter the build_gcc script and the configure files to build gfortran, libffi and libobjc, the build tries to make 64 bit versions of libgfortran, libgfortranbegin, libffi and libobjc-gnu. There are a number of problems: 1. Since I am using a PPC7455 based computer 64bit executables won't run and the 64 bit libraries are effectively cross compilations. So the configure scripts need the same APPLE LOCAL mods used in libstdc+ + to avoid testing in the configure script whether the compiler can build executables. (with the -m64 flag the executables are built but they won't run). This would not be an issue on a PPC970(G5) cpu. 2. libgfortran.h line 63 defines int8_t. This is already defined in / usr/lib/ppc/types.h. So I think the libgfortran.h define needs to be conditional on _INT8_H. Even if the libraries build, will libffi or libobjc work on 64 bit PPC Since I don't have access to a 64 bit PPC machine I cannot test this. There is an even murkier question about what happens with Darwin 8 on x86. Bill Northcott
Re: PPC 64bit library status?
On 01/05/2005, at 1:11 AM, Andrew Pinski wrote: Even if the libraries build, will libffi or libobjc work on 64 bit PPC Since I don't have access to a 64 bit PPC machine I cannot test this. There was some talk about this earlier this year and then the support for building the 64bit libraries on darwin was turned off for both the 4.0.0 release and on the mainline. That much was sort of obvious. However, if they are enabled in the build, libobjc and libgfortran do build. Are they likely to be functional? Libffi does not build using the -m64 flag on the compiler. Note why again are you using Apple's branch. It does not get all fixes which the 4.0 release branch will get. Basically my logic is fairly simple. If I use Apple's OS, I feel happier using their compiler. While that creates some problems, it avoids others like the restFP,savFP issue. The code I am using was synced to the release gcc-4.0.0 on 20 April. So it is not that out of date. Bill Northcott
spec failure: unrecognized spec option ...
I have been building gcc-4.0.0 from Apple sources with tags in the
apple-ppc-5000 series.
I was getting lots of messages like this "spec failure: unrecognized
spec option 'Q'"
I notice that APPLE LOCAL tagged changes seem to turn spec warnings
on. Presumably they are off by default.
I amended /usr/lib/gcc/powerpc-apple-darwin8/4.0.0/specs line 26 and
27 from:
*cpp_unique_options:
%yC%{C|CC:%{!E:%eGCC does not support -C or -CC without -E}} %{!
traditional:%{!ftraditional:%{!traditional-cpp:%Q}}} %{!Q:-quiet} %
{nostdinc*} %{C} %{CC} %{v} %{I*&F*} %{P} %I %{MD:-MD %{!o:%b.d}%{o*:
%.d%*}} %{MMD:-MMD %{!o:%b.d}%{o*:%.d%*}} %{M} %{MM} %{MF*} %{MG} %
{MP} %{MQ*} %{MT*} %{!E:%{!M:%{!MM:%{MD|MMD:%{o*:-MQ %*} %
{trigraphs} %{remap} %{g3:-dD} %{H} %C %{D*&U*&A*} %{i*} %Z %i %
{fmudflap:-D_MUDFLAP -include mf-runtime.h} %{fmudflapth:-D_MUDFLAP -
D_MUDFLAPTH -include mf-runtime.h} %{E|M|MM:%W{o*}}
to:
*cpp_unique_options:
%yC%{C|CC:%{!E:%eGCC does not support -C or -CC without -E}} %{!Q:-
quiet} %{nostdinc*} %{C} %{CC} %{v} %{I*&F*} %{P} %I %{MD:-MD %{!o:%
b.d}%{o*:%.d%*}} %{MMD:-MMD %{!o:%b.d}%{o*:%.d%*}} %{M} %{MM} %{MF*} %
{MG} %{MP} %{MQ*} %{MT*} %{!E:%{!M:%{!MM:%{MD|MMD:%{o*:-MQ %*} %
{trigraphs} %{remap} %{g3:-dD} %{H} %C %{D*&U*&A*} %{i*} %Z %i %
{fmudflap:-D_MUDFLAP -include mf-runtime.h} %{fmudflapth:-D_MUDFLAP -
D_MUDFLAPTH -include mf-runtime.h} %{E|M|MM:%W{o*}}
All the warnings stopped.
I have no idea what is going on here. Can someone please give me
some clues.
Bill Northcott
Re: spec failure: unrecognized spec option ...
On 20/05/2005, at 3:51 AM, Mike Stump wrote: I have been building gcc-4.0.0 from Apple sources with tags in the apple-ppc-5000 series. I was getting lots of messages like this "spec failure: unrecognized spec option 'Q'" I amended /usr/lib/gcc/powerpc-apple-darwin8/4.0.0/specs rm -rf /usr/lib/gcc/*/4.0.0/specs Clearly that is the surgical solution, but what is the file there for? I have now realised that it is not generated as part of the compiler build process. In fact it is one of two files in Apple Xcode gcc-4.0 package which is not derived from the source code. The other is "/ Library/Application Support/Xcode/Specifications/GCC 4.0.xcspec" I now realise the warnings arise because the specs file is from a different compiler. Presumably these files serve some purpose. How do they affect the operation of the compiler? Bill Northcott
Re: spec failure: unrecognized spec option ...
On 21/05/2005, at 4:02 AM, Mike Stump wrote: I have now realised that it is not generated as part of the compiler build process. It used to be. Presumably these files serve some purpose. How do they affect the operation of the compiler? For the specs file, negatively. For the other, none, as it isn't consulted by the compiler. Xcode might use it however. So I understand that the specs file was a useless appendage in compilers with apple-gcc-40xx tags such as the standard Xcode 2.0 gcc-4. It is not built by apple-ppc-50xx tags. It should be removed when installing a 50xx compiler. Thanks for the help Bill Northcott
Re: could gfortran be tested on Darwin regress builds of 4.1?
On 30/07/2005, at 1:06 AM, Jack Howarth wrote: Well the gcc4.info for the package containing gfortran in fink has... Depends: gmp-shlibs (>= 4.1.3-11), cctools (>= 576-1) | odcctools (>= 576-200503 27), %N-shlibs, libiconv BuildDepends: gmp (>= 4.1.3-11), libiconv-dev which is a tad confusing since I guess it implies that cctools isn't needed to build gcc4/gfortran but is needed to use it. That seems weird since to build it and do a make check is to effectively use it. I built a working (builds functioning R and Octave) gfortran with Apple's gcc 4 on MacOS X 10.4.1 (Darwin 8.1). The only thing I needed to add was gmp, which built from the source without problems. The cc-tools in Darwin 8 is 590. So I think it would be a bad idea to install 576! If I get time, I will try the current code. Bill Northcott
gcc
Hi I'm new to the list. Wow it's great. Why isn't Richard Stallman working on gcc? I'm new to compiler design and I'm looking to learn all I can. I guess I'll have to catch on on the fly. Bill
development
Ok since I'm very new to this are there any switches when compiling this source for development purposes? Bill
Git question: Rebasing a user branch
I'm having a little difficulty with my workflow, and I'm hoping someone can spot the problem. I have a user branch set up with the contrib/git-add-user-branch.sh script. Here are the relevant portions of my .git/config: [remote "users/wschmidt"] url = git+ssh://wschm...@gcc.gnu.org/git/gcc.git fetch = +refs/users/wschmidt/heads/*:refs/remotes/users/wschmidt/* fetch = +refs/users/wschmidt/tags/*:refs/tags/users/wschmidt/* push = refs/heads/wschmidt/*:refs/users/wschmidt/heads/* [branch "wschmidt/builtins"] remote = users/wschmidt merge = refs/users/wschmidt/heads/builtins I originally created the branch from master. I then made 15 local commits, and pushed these upstream. I now want to rebase my branch from master, and reflect this state upstream. My recipe is: git checkout master git pull git checkout wschmidt/builtins git rebase master git push --dry-run users/wschmidt +wschmidt/builtins After the rebase step, git status shows: On branch wschmidt/builtins Your branch and 'users/wschmidt/builtins' have diverged, and have 39 and 15 different commits each, respectively. (use "git pull" to merge the remote branch into yours) nothing to commit, working tree clean Looks fine to me, so lets try the force push: wschmidt@marlin:~/newgcc/gcc/config/rs6000$ git push --dry-run users/wschmidt +wschmidt/builtins To git+ssh://gcc.gnu.org/git/gcc.git * [new branch] wschmidt/builtins -> wschmidt/builtins Well, that's odd, why is it trying to create a new branch? If I inadvisedly attempt to push without --dry-run, I am stopped from creating the new branch: remote: *** Shared development branches should be named devel/*, and should be documented in https://gcc.gnu.org/git.html . remote: error: hook declined to update refs/heads/wschmidt/builtins To git+ssh://gcc.gnu.org/git/gcc.git ! [remote rejected] wschmidt/builtins -> wschmidt/builtins (hook declined) error: failed to push some refs to 'git+ssh://wschm...@gcc.gnu.org/git/gcc.git' It seems wrong that it is trying to update refs/head/wschmidt/builtins (thus creating a new branch). It seems like there may be a missing "users/" needed someplace. But I am not at all confident that's correct. I'm a little suspicious of the push spec in my config. Can someone with strong git-fu give me any suggestions? Best regards, Bill
Re: Git question: Rebasing a user branch
On 2/4/20 4:31 PM, Andreas Schwab wrote: On Feb 04 2020, Bill Schmidt wrote: wschmidt@marlin:~/newgcc/gcc/config/rs6000$ git push --dry-run users/wschmidt +wschmidt/builtins To git+ssh://gcc.gnu.org/git/gcc.git * [new branch] wschmidt/builtins -> wschmidt/builtins Well, that's odd, why is it trying to create a new branch? You told it so, with the refspec you used. Instead you want to push to users/wschmidt/builtins on the remote side, ie. +wschmidt/builtins:users/wschmidt/builtins. Hm. If I'm understanding you correctly, this still attempts to create a new branch: wschmidt@marlin:~/newgcc/gcc/config/rs6000$ git push --dry-run users/wschmidt +wschmidt/builtins:users/wschmidt/builtins To git+ssh://gcc.gnu.org/git/gcc.git * [new branch] wschmidt/builtins -> users/wschmidt/builtins I expect I've misunderstood, though. Thanks! Bill Andreas.
Re: Git question: Rebasing a user branch
On 2/4/20 5:09 PM, Andreas Schwab wrote: On Feb 04 2020, Bill Schmidt wrote: Hm. If I'm understanding you correctly, this still attempts to create a new branch: wschmidt@marlin:~/newgcc/gcc/config/rs6000$ git push --dry-run users/wschmidt +wschmidt/builtins:users/wschmidt/builtins Sorry, that needs to be fully qualified, as it is not under refs/heads (and /heads/ was missing on the remote side): +wschmidt/builtins:refs/users/wschmidt/heads/builtins Thanks! That worked: git push users/wschmidt +wschmidt/builtins:refs/users/wschmidt/heads/builtins Regarding your other suggestion, I don't like to use -f given that I've noticed it will sometimes attempt to push other local branches as well. But it looks to be unnecessary with this method. Much obliged! Bill Andreas.
Re: GCC 9.3 Release Candidate available from gcc.gnu.org
On 2020-03-05 14:13, Jakub Jelinek wrote: The first release candidate for GCC 9.3 is available from https://gcc.gnu.org/pub/gcc/snapshots/9.3.0-RC-20200305/ ftp://gcc.gnu.org/pub/gcc/snapshots/9.3.0-RC-20200305/ and shortly its mirrors. It has been generated from git commit r9-8351-ge50627ff8cd54c3983614b34727323b333b9374d. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 9.3 on Thursday, March 12th. I bootstrapped and tested on power 7 and 8 BE and power 8 and 9 LE and saw nothing untoward. -- -Bill Seurer
Power ELFv2 ABI now openly published
At Cauldron this year, several people complained to me that our latest ABI document was behind a registration wall. I'm happy to say that we've finally gotten past the issues that were holding it there, and it is now openly available at: https://members.openpowerfoundation.org/document/dl/576 Thanks, Bill
Run one gcc test case multiple times with different option sets
Is there some way using deja-gnu to have a single test case run multiple
times using different sets of compiler options? I didn't see anything
in the documentation and didn't see any examples when I searched the
existing test cases (though of course I wasn't exactly sure what to look
for).
For example, something like this if I wanted to compile the test case
once with -Dfoo and once with -Dbar.
/* { dg-options "-Dfoo" } */
/* { dg-options "-Dbar" } */
That actually just uses the second set of options as-is.
Thanks!
--
-Bill Seurer
Re: Run one gcc test case multiple times with different option sets
On 04/01/16 10:48, Andrew Pinski wrote: On Fri, Apr 1, 2016 at 8:42 AM, Bill Seurer wrote: Is there some way using deja-gnu to have a single test case run multiple times using different sets of compiler options? I didn't see anything in the documentation and didn't see any examples when I searched the existing test cases (though of course I wasn't exactly sure what to look for). What most folks do is have two .c files; one that includes the other. So something like... #define foo #include "real-test-case.c" #undef foo #define bar #include "real-test-case.c" -- -Bill Seurer
Some aliasing questions
Hi,
I ran into a couple of aliasing issues with a project I'm working on,
and have some questions.
The first is an issue with TOC-relative addresses on PowerPC. These are
symbolic addresses that are to be loaded from a fixed slot in the table
of contents, as addressed by the TOC pointer (r2). In the RTL phases
prior to register allocation, these are described in an UNSPEC that
looks like this for an example store:
(set (mem/c:DI (unspec:DI [
(symbol_ref:DI ("*.LANCHOR0") [flags 0x182])
(reg:DI 2 2)
] UNSPEC_TOCREL) [1 svul+0 S8 A128])
(reg:DI 178))
The UNSPEC helps keep track of the r2 reference until this is split into
two or more insns depending on the memory model.
I discovered that alias.c:memrefs_conflict_p is unable to make
must-alias decisions about these, because it doesn't see into the UNSPEC
to find the symbol_ref. Thus it returns -1 (no information) when
comparing the above with:
(set (reg/f:DI 177)
(unspec:DI [
(symbol_ref:DI ("*.LANCHOR0") [flags 0x182])
(reg:DI 2 2)
] UNSPEC_TOCREL))
(set (reg:V2DI 159)
(mem:V2DI (and:DI (reg/f:DI 177)
(const_int -16 [0xfff0])) [4 *_11+0 S16
A128]))
But clearly the two addresses overlap.
I added the following hack, and the code then returns 1 (must-alias),
without regressing anything in the test suite.
Index: gcc/alias.c
===
--- gcc/alias.c (revision 234726)
+++ gcc/alias.c (working copy)
@@ -2213,6 +2213,12 @@ memrefs_conflict_p (int xsize, rtx x, int ysize, r
}
}
+ /* Some targets may hide a base address in an UNSPEC. Peel that away. */
+ if (GET_CODE (x) == UNSPEC)
+return memrefs_conflict_p (xsize, XVECEXP (x, 0, 0), ysize, y, c);
+ if (GET_CODE (y) == UNSPEC)
+return memrefs_conflict_p (xsize, x, ysize, XVECEXP (y, 0, 0), c);
+
if (CONSTANT_P (x))
{
if (CONST_INT_P (x) && CONST_INT_P (y))
Now, this is probably not right for a real fix, since it assumes that
any UNSPEC is ok for this, and that the base address will be found
recursively in the first position. I don't know whether any other
targets have similar issues. So:
(1) What is the best way to handle this? Would it be better to have
some sort of target hook?
(2) Are there other places in the aliasing infrastructure where this
UNSPEC use could be getting us into trouble?
Another issue I see involves disjoint alias sets. If you look closely
at the rtx's above, they have been marked as disjoint, belonging to
alias sets 1 and 4, respectively:
[1 svul+0 S8 A128]
[4 *_11+0 S16 A128]
The gimple involved is:
svul[0] = 0;
svul[1] = 1;
svul.1_9 = (sizetype) &svul;
_10 = svul.1_9 & 18446744073709551600; // i.e., -16 or 0xfff...f0
_11 = (__vector unsigned long *) _10;
vul.2_12 = *_11;
where svul is file-scope:
static unsigned long long svul[2] __attribute__ ((aligned (16)));
Here I am exposing the semantics of the vec_ld built-in, which aligns
the address to a 16-byte boundary by masking the low-order four bits.
But bitwise AND only works in an integer type, so some casting there may
be responsible for losing track of the fact that *_11 aliases svul.
However, it seems odd to imply that *_11 definitely does not alias svul.
So:
(3) Am I doing something wrong to expose the address masking this way?
(4) Are the alias sets bogus, or am I misinterpreting this? If they are
wrong, please point me to where they are computed and I can debug
further.
Thanks for any help! I haven't dug deeply into the aliasing analysis
before.
Bill
Re: Some aliasing questions
On Fri, 2016-04-08 at 13:41 -0700, Richard Henderson wrote:
> On 04/08/2016 11:10 AM, Bill Schmidt wrote:
> > The first is an issue with TOC-relative addresses on PowerPC. These are
> > symbolic addresses that are to be loaded from a fixed slot in the table
> > of contents, as addressed by the TOC pointer (r2). In the RTL phases
> > prior to register allocation, these are described in an UNSPEC that
> > looks like this for an example store:
> >
> > (set (mem/c:DI (unspec:DI [
> >(symbol_ref:DI ("*.LANCHOR0") [flags 0x182])
> >(reg:DI 2 2)
> > ] UNSPEC_TOCREL) [1 svul+0 S8 A128])
> > (reg:DI 178))
> >
> > The UNSPEC helps keep track of the r2 reference until this is split into
> > two or more insns depending on the memory model.
>
>
> That's why Alpha uses LO_SUM for pre-reload tracking of such things.
>
> Even though that's a bit of a liberty, since there's no HIGH to go along with
> the LO_SUM. But at least it allows the middle-end to continue to find the
> symbol.
Yes, that seems like a better way to handle this. I'll put this on the
to-do list for GCC 7. The fewer UNSPECs the better; ironically, I ran
into this while trying to remove some other UNSPECs...
>
> > (1) What is the best way to handle this? Would it be better to have
> > some sort of target hook?
>
> Perhaps, yes.
>
> > Another issue I see involves disjoint alias sets. If you look closely
> > at the rtx's above, they have been marked as disjoint, belonging to
> > alias sets 1 and 4, respectively:
> ...
> > _11 = (__vector unsigned long *) _10;
> ...
> > static unsigned long long svul[2] __attribute__ ((aligned (16)));
>
> Be consistent about unsigned long vs unsigned long long and this will be
> fixed.
Right -- we have some history here with these built-ins and their
signatures, which should have been designed to use long long all the
time to avoid inconsistencies between 32-bit and 64-bit targets.
Because long and long long are essentially synonyms on ppc64, I'm a bit
blind to spotting these situations. I think I will have to use
may-alias types for these during the expansion, as Richi suggested.
Thanks to both of you for the help!
Bill
>
>
> r~
>
Re: Some aliasing questions
On Tue, 2016-04-12 at 10:00 +0930, Alan Modra wrote:
> On Fri, Apr 08, 2016 at 01:41:05PM -0700, Richard Henderson wrote:
> > On 04/08/2016 11:10 AM, Bill Schmidt wrote:
> > > The first is an issue with TOC-relative addresses on PowerPC. These are
> > > symbolic addresses that are to be loaded from a fixed slot in the table
> > > of contents, as addressed by the TOC pointer (r2). In the RTL phases
> > > prior to register allocation, these are described in an UNSPEC that
> > > looks like this for an example store:
> > >
> > > (set (mem/c:DI (unspec:DI [
> > >(symbol_ref:DI ("*.LANCHOR0") [flags 0x182])
> > >(reg:DI 2 2)
> > > ] UNSPEC_TOCREL) [1 svul+0 S8 A128])
> > > (reg:DI 178))
> > >
> > > The UNSPEC helps keep track of the r2 reference until this is split into
> > > two or more insns depending on the memory model.
> >
> >
> > That's why Alpha uses LO_SUM for pre-reload tracking of such things.
> >
> > Even though that's a bit of a liberty, since there's no HIGH to go along
> > with
> > the LO_SUM. But at least it allows the middle-end to continue to find the
> > symbol.
>
> I wish I'd been made aware of the problem with alias analysis when I
> invented this scheme for -mcmodel=medium code..
It's certainly subtle. I had to be pretty lucky to discover it, as the
only effect is to rather harmlessly say "who knows" rather than giving a
definite answer.
>
> Back in gcc-4.3 days, when small-model code was the only option, we
> used to generate
> mem (plus ((reg 2) (const (minus ((symbol_ref)
> (symbol_ref toc_base))
> for a toc mem reference, which accurately reflects the addressing.
>
> The problem is that when splitting this to a high/lo_sum you lose the
> r2 reference in the lo_sum, and that allows r2 to die prematurely,
> breaking an important linker code editing optimisation.
>
> Hmm. Maybe if we rewrote the mem to
> mem (plus ((symbol_ref toc_base) (const (minus ((symbol_ref)
> (reg 2))
> It might look odd, but is no lie. r2 is equal to toc_base. Or
> perhaps we could lie a litte and simply omit the plus and toc_base
> reference?
>
> Either way, when we split to
> set (reg tmp) (high (const (minus ((symbol_ref) (reg 2)
> .. mem (lo_sum (reg tmp) (const (minus ((symbol_ref) (reg 2)
> both high and lo_sum reference r2 and the linker could happily replace
> rtmp in the lo_sum insn with r2 when the high address is known to be
> zero.
Yes, this sounds promising. And it really helps to know the history
here -- you saved me a lot of digging through the archives, since I
didn't want to rediscover the issue behind the present design.
>
> Bill, do you have test cases for the alias problem? Is this something
> that needs fixing for gcc-6?
>
Last question first ... no, I don't think it does. It's generally fine
for the structural aliasing to report "I don't know" and let other
checks decide whether aliasing can exist; it just isn't optimal. I only
spotted this because getting past this check allowed me to run into a
problem in my code that was exposed in the TBAA checks afterwards.
I ran into this with an experimental patch for GCC 7. I can send you a
copy of the patch, and point you to the test in the test suite that
exhibits the problem when that patch is applied. I'll do that offline.
Thanks, Alan!
Bill
Re: Please block seu...@linux.vnet.ibm.com from gcc-regression
On 04/19/16 04:56, Joseph Myers wrote: In the past few days, seu...@linux.vnet.ibm.com has sent half a gigabyte of huge messages such as <https://gcc.gnu.org/ml/gcc-regression/2016-04/msg03559.html> to gcc-regression, those messages containing no actual useful information about regressions caused by GCC commits. Overseers, could you block that address from posting to gcc-regression until we have confirmation that the process sending those messages to gcc-regression has stopped and will not be restarted and that there are no more such messages waiting in a mail queue somewhere (all the messages seem to be dated Sunday, but they are still coming through)? I apologize about that. I activated gcc 6 on our tester Sunday but failed to prime the source first. That caused the tester scripts to loop trying to get the source and failing. I updated the scripts yesterday to prevent this from happening in the future. -- -Bill Seurer
Re: possibly dead call from slsr_process_phi () to gimple_bb ()
> On Jul 25, 2016, at 4:04 AM, Richard Biener wrote: > > On Mon, 25 Jul 2016, Prathamesh Kulkarni wrote: > >> Hi, >> I am trying to write a WIP patch to warn for dead function calls, >> and incidentally it caught the following dead call to gimple_bb() from >> slsr_process_phi () in gimple-ssa-strength-reduction.c: >> >> if (SSA_NAME_IS_DEFAULT_DEF (arg)) >> arg_bb = single_succ (ENTRY_BLOCK_PTR_FOR_FN (cfun)); >> else >> gimple_bb (SSA_NAME_DEF_STMT (arg)); >> >> Presumably it should be: >> arg_bb = gimple_bb (SSA_NAME_DEF_STMT (arg)) ? > > Looks like so. Bill should know. Certainly looks that way. I'll get that cleaned up. Thanks for the report! Bill > > Richard. > >> Thanks, >> Prathamesh >> >> > > -- > Richard Biener > SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB > 21284 (AG Nuernberg) >
Problem with 447.dealII in spec2006 because of r240707
parameter_handler.cc: In member function 'double ParameterHandler::get_double(const string&) const': parameter_handler.cc:777:28: error: ISO C++ forbids comparison between pointer and integer [-fpermissive] AssertThrow ((s.c_str()!='\0') || (*endptr == '\0'), ^ With the recent revision r240707 comparing a pointer with \0 became an error. Unfortunately this is used in several spots in the test case 447.dealII in spec2006 (one example above). There doesn't appear to be a way to disable this error check and we're not supposed to change the spec test cases. Any ideas on how to work around this? -- -Bill Seurer
Re: Problem with 447.dealII in spec2006 because of r240707
On 10/04/16 10:38, Andrew Pinski wrote: On Tue, Oct 4, 2016 at 8:33 AM, Bill Seurer wrote: parameter_handler.cc: In member function 'double ParameterHandler::get_double(const string&) const': parameter_handler.cc:777:28: error: ISO C++ forbids comparison between pointer and integer [-fpermissive] AssertThrow ((s.c_str()!='\0') || (*endptr == '\0'), ^ With the recent revision r240707 comparing a pointer with \0 became an error. Unfortunately this is used in several spots in the test case 447.dealII in spec2006 (one example above). There doesn't appear to be a way to disable this error check and we're not supposed to change the spec test cases. Any ideas on how to work around this? Did you try -fpermissive ? Because that seems like it was listed ... That affects more than just this specific error. I reported it to spec via our company rep. Not sure how long their turnaround is on stuff like this. -- -Bill Seurer
vec_ld versus vec_vsx_ld on power8
Hi Tim, I'll discuss the loads here for simplicity; the situation for stores is analogous. There are a couple of differences between lvx and lxvd2x. The most important one is that lxvd2x supports unaligned loads, while lvx does not. You'll note that lvx will zero out the lower 4 bits of the effective address in order to force an aligned load. lxvd2x loads two doublewords into a vector register using big-endian element order, regardless of whether the processor is running in big-endian or little-endian mode. That is, the first doubleword from memory goes into the high-order bits of the vector register, and the second doubleword goes into the low-order bits. This is semantically incorrect for little-endian, so the xxpermdi swaps the doublewords in the register to correct for this. At optimization -O1 and higher, gcc will remove many of the xxpermdi instructions that are added to correct for LE semantics. In many vector computations, the lanes where the computations are performed do not matter, so we don't have to perform the swaps. For unaligned loads where we are unable to remove the swaps, this is still better than the alternative using lvx. An unaligned load requires a four-instruction sequence to load the two aligned quadwords that contain the desired data, set up a permutation control vector, and combine the desired pieces of the two aligned quadwords into a vector register. This can be pipelined in a loop so that only one load occurs per loop iteration, but that requires additional vector copies. The four-instruction sequence takes longer and increases vector register pressure more than an lxvd2x/xxpermdi. When the data is known to be aligned, lvx is equivalent to lxvd2x performance if we are able to remove the permutes, and is preferable to lxvd2x if not. There are cases where we do not yet use lvx in lieu of lxvd2x when we could do so and improve performance. For example, saving and restoring of vector parameters in a function prolog and epilog does not yet always use lvx. This is a performance opportunity we plan to improve in the future. A rule of thumb for your purposes is that if you can guarantee that you are using aligned data, you should use vec_ld and vec_st, and otherwise you should use vec_vsx_ld and vec_vsx_st. Depending on your application, it may be worthwhile to copy your data into an aligned buffer before performing vector calculations on it. GCC provides attributes that will allow you to specify alignment on a 16-byte boundary. Note that the above discussion presumes POWER8, which is the only POWER hardware that currently supports little-endian distributions and applications. Unaligned load/store performance on earlier processors was less efficient, so the tradeoffs differ. I hope this is helpful! Bill Schmidt, Ph.D. IBM Linux Technology Center You wrote: > I have a issue/question using VMX/VSX on Power8 processor on a little endian > system. > Using intrinsics function, if I perform an operation with vec_vsx_ld(â) - > vet_vsx_st(), the compiler will add > a permutation, and then perform an operations (memory correctly aligned) > lxvd2x â > xxpermdi â > operations â. > xxpermdi > stxvd2x â > If I use vec_ld() - vec_st() > lvx > operations â > stvx > Reading the ISA, I do not see a real difference between this 2 instructions ( > or I miss it) > So my 3 questions are: > Why do I have permutations ? > What is the cost of these permutations ? > What is the difference vet_vsx_ld and vec_ld for the performance ?
Re: vec_ld versus vec_vsx_ld on power8
Hi Tim,
Actually, I left out another very good reason why you may want to use
vec_vsx_ld/st. Sorry for forgetting this.
As you saw, vec_ld translates into the lvx instruction. This
instruction loads a sequence of 16 bytes into a vector register. For
big endian, the first byte in memory is loaded into the high order byte
of the register. For little endian, the first byte in memory is loaded
into the low order byte of the register.
This is fine if the data you are loading is arrays of characters, but is
not so fine if you are loading arrays of larger items. Suppose you are
loading four integers {1, 2, 3, 4} into a register with lvx. In big
endian you will see:
00 00 00 01 00 00 00 02 00 00 00 03 00 00 00 04
In little endian you will see:
04 00 00 00 03 00 00 00 02 00 00 00 01 00 00 00
But for this to be interpreted as a vector of integers ordered for
little endian, what you really want is:
00 00 00 04 00 00 00 03 00 00 00 02 00 00 00 01
If you use vec_vsx_ld, the compiler will generate a lxvw2x instruction
followed by an xxpermdi that swaps the doublewords. After the lxvw2x
you will have:
00 00 00 02 00 00 00 01 00 00 00 04 00 00 00 03
because the two LE doublewords are loaded in BE (reversed) order.
Swapping the two doublewords restores sanity:
00 00 00 04 00 00 00 03 00 00 00 02 00 00 00 01
So, even if your data is properly aligned, the use of vec_ld = lvx is
only correct if you are loading arrays of bytes. Arrays of anything
larger must use vec_vsx_ld to avoid errors.
Again, sorry for my previous omission!
Thanks,
Bill Schmidt, Ph.D.
IBM Linux Technology Center
On Fri, 2015-03-13 at 15:42 +, Ewart Timothée wrote:
> thank you very much for this answer.
> I know my memory is aligned so I will use vec_ld/st only.
>
> best
>
> Tim
>
>
>
>
>
Re: vec_ld versus vec_vsx_ld on power8
Hi Tim,
Sorry to have confused you. This stuff is a bit boggling the first 200
times you look at it...
For both 32-bit and 64-bit floating-point, you should use ld_vsx_vec on
both BE and LE machines, and the compiler will take care of doing the
right thing for you in both cases. You do not have to add any swaps
yourself.
When compiling for big-endian, ld_vsx_vec will translate into either
lxvw4x (for 32-bit floating-point) or lxvd2x (for 64-bit
floating-point). The values will be loaded into the register from
left-to-right (BE ordering).
When compiling for little-endian, ld_vsx_vec will translate into lxvd2x
followed by xxpermdi for both 32-bit and 64-bit floating-point. This
does the right thing in both cases. The values will be loaded into the
register from right-to-left (LE ordering).
The vector programming model is set up to allow you to usually code the
same way for both BE and LE. This is discussed more in Chapter 6 of the
ELFv2 ABI manual, which can be obtained from the OpenPOWER Connect
website (free registration required):
https://www-03.ibm.com/technologyconnect/tgcm/TGCMServlet.wss?alias=OpenPOWER&linkid=1n0000
Bill
On Fri, 2015-03-13 at 17:11 +, Ewart Timothée wrote:
> Hello,
>
> I am super confuse now
>
> scenario 1, what I have in m code:
> machine boots in LE.
>
> 1) memory: LE
> 2) I load (ld_vec)
> 3) register : LE
> 4) VSU compute in LE
> 5) I store (st_vec)
> 6) memory: LE
>
> scenario 2: ( I did not test but it is what I get if I order gcc to compiler
> in BE)
> machine boot in BE
>
> 1) memory: BE
> 2) I load (ld_vsx_vec)
> 3) register : BE
> 4) VSU compute in BE
> 5) I store (st_vsx_vec)
> 6) memory: BE
>
> At this point the VUS compute in both order
>
> chimera scenario 3, what I understand:
>
> machine boot in LE
>
> 1) memory: LE
> 2) I load (ld_vsx_vec) (the load swap the element)
> 3) register : BE
> 4) swap : LE
> 5) VSU compute in LE
> 6) swap : BE
> 5) I store (st_vsx_vec) (the store swap the element)
> 6) memory: BE
>
> I understand ld/st_vsx_vec load/store from LE/BE, but as the VXU can compute
> in both mode what should I swap (I precise I am working with 32/64 bits float)
>
> Best,
>
> Tim
>
> Timothée Ewart, Ph. D.
> http://www.linkedin.com/in/tewart
> timothee.ew...@epfl.ch
>
>
>
>
>
>
> > Le 13 Mar 2015 à 17:50, Bill Schmidt a écrit :
> >
> > Hi Tim,
> >
> > Actually, I left out another very good reason why you may want to use
> > vec_vsx_ld/st. Sorry for forgetting this.
> >
> > As you saw, vec_ld translates into the lvx instruction. This
> > instruction loads a sequence of 16 bytes into a vector register. For
> > big endian, the first byte in memory is loaded into the high order byte
> > of the register. For little endian, the first byte in memory is loaded
> > into the low order byte of the register.
> >
> > This is fine if the data you are loading is arrays of characters, but is
> > not so fine if you are loading arrays of larger items. Suppose you are
> > loading four integers {1, 2, 3, 4} into a register with lvx. In big
> > endian you will see:
> >
> > 00 00 00 01 00 00 00 02 00 00 00 03 00 00 00 04
> >
> > In little endian you will see:
> >
> > 04 00 00 00 03 00 00 00 02 00 00 00 01 00 00 00
> >
> > But for this to be interpreted as a vector of integers ordered for
> > little endian, what you really want is:
> >
> > 00 00 00 04 00 00 00 03 00 00 00 02 00 00 00 01
> >
> > If you use vec_vsx_ld, the compiler will generate a lxvw2x instruction
> > followed by an xxpermdi that swaps the doublewords. After the lxvw2x
> > you will have:
> >
> > 00 00 00 02 00 00 00 01 00 00 00 04 00 00 00 03
> >
> > because the two LE doublewords are loaded in BE (reversed) order.
> > Swapping the two doublewords restores sanity:
> >
> > 00 00 00 04 00 00 00 03 00 00 00 02 00 00 00 01
> >
> > So, even if your data is properly aligned, the use of vec_ld = lvx is
> > only correct if you are loading arrays of bytes. Arrays of anything
> > larger must use vec_vsx_ld to avoid errors.
> >
> > Again, sorry for my previous omission!
> >
> > Thanks,
> >
> > Bill Schmidt, Ph.D.
> > IBM Linux Technology Center
> >
> > On Fri, 2015-03-13 at 15:42 +, Ewart Timothée wrote:
> >> thank you very much for this answer.
> >> I know my memory is aligned so I will use vec_ld/st only.
> >>
> >> best
> >>
> >> Tim
> >>
> >>
> >>
> >>
> >>
> >
> >
>
Re: GCC 6.5 Release Candidate available from gcc.gnu.org
On 10/19/18 04:49, Jakub Jelinek wrote: The first release candidate for GCC 6.5 is available from https://gcc.gnu.org/pub/gcc/snapshots/6.5.0-RC-20181019/ ftp://gcc.gnu.org/pub/gcc/snapshots/6.5.0-RC-20181019/ and shortly its mirrors. It has been generated from SVN revision 265300. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 6.5 on Friday, October 26th. I bootstrapped and tested on power 7, power 8, and power 9 both BE and LE and saw no unexpected issues. -- -Bill Seurer
Re: GCC 7.4 Release Candidate available from gcc.gnu.org
On 11/29/18 04:24, Richard Biener wrote: A release candidate for GCC 7.4 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/7.4.0-RC-20181129/ and shortly its mirrors. It has been generated from SVN revision 266611. I have so far bootstrapped and tested the release candidate on x86_64-unknown-linux-gnu. Please test it and report any issues to bugzilla. If all goes well I'd like to release GCC 7.4 at the end of next week. I bootstrapped and tested on powerpc64le-unknown-linux-gnu and powerpc64-unknown-linux-gnu and all went well. -- -Bill Seurer
Re: [RFC][GCC][rs6000] Remaining work for inline expansion of strncmp/strcmp/memcmp for powerpc
On 12/3/18 8:34 AM, Florian Weimer wrote:
> * Aaron Sawdey:
>
>> If you are aware of any real world code that is faster when built
>> with -fno-builtin-strcmp and/or -fno-builtin-strncmp, please let me know
>> so I can look at avoiding those situations.
> Sorry, I have not tried to benchmark this.
>
> One more question: There's a hardware erratum on POWER9 DD2.1 related to
> VSX load instructions causing memory corruption when accessing
> cache-inhibited memory. It may not be very likely that strncmp is used
> on such memory, but memcpy and memmove definitely need to take that into
> account, and perhaps memset and memcmp as well.
>
> In the past, I did not receive positive feedback for my suggestion that
> we should have a separate family of string functions for device memory.
> (This is a general problem that is not specific to POWER.) So we still
> have the problem that at least some of the string functions in glibc
> need to be compatible with device memory.
>
> My concern here is that the GCC inline expansion could essentially
> disable the workaround we have in glibc memcpy and memmove for the
> hardware erratum.
I don't think we have a real concern here. DD2.1 is used in a particular
situation where GCC 4.8.5 is the supported compiler, and not used elsewhere.
So I'd prefer not to cripple the compiler for this specific use case. If
the customer with DD2.1 hardware chooses to use GCC 8 or later, and runs
into this problem, they can use -mno-builtin-mem{set,cmp} as a workaround.
Do you feel that's satisfactory?
We can also have a private discussion if you feel that's warranted.
Thanks,
Bill
>
> Thanks,
> Florian
>
Re: GCC 8.3 Release Candidate available from gcc.gnu.org
On 02/15/19 10:13, Jakub Jelinek wrote: The first release candidate for GCC 8.3 is available from https://gcc.gnu.org/pub/gcc/snapshots/8.3.0-RC-20190215/ ftp://gcc.gnu.org/pub/gcc/snapshots/8.3.0-RC-20190215/ and shortly its mirrors. It has been generated from SVN revision 268935. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 8.3 on Friday, February 22nd. I bootstrapped and tested on powerpc64. power 7 BE, power 8 BE, power 8 LE, and power 9 LE all went well. -- -Bill Seurer
Re: GCC 9.1 Release Candidate available from gcc.gnu.org
On 4/26/19 11:16 AM, Jakub Jelinek wrote: The first release candidate for GCC 9.1 is available from https://gcc.gnu.org/pub/gcc/snapshots/9.0.1-RC-20190426/ ftp://gcc.gnu.org/pub/gcc/snapshots/9.0.1-RC-20190426 and shortly its mirrors. It has been generated from SVN revision 270601. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 9.1 on Friday, May 3rd. I tested on powerpc64 on power 7 and power 8 BE and power 8 and power 9 LE and all went well. -- -Bill Seurer
Re: Second GCC 9.1 Release Candidate available from gcc.gnu.org
On 4/30/19 8:12 AM, Jakub Jelinek wrote: The second release candidate for GCC 9.1 is available from https://gcc.gnu.org/pub/gcc/snapshots/9.0.1-RC-20190430/ ftp://gcc.gnu.org/pub/gcc/snapshots/9.0.1-RC-20190430 and shortly its mirrors. It has been generated from SVN revision 270689. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 9.1 on Friday, May 3rd. All looks good on powerpc64. Bootstrap built and tested on powerpc64 power 7 and power 8 BE and power 8 and power 9 LE. -- -Bill Seurer
Re: -Wformat-diag: floating-point or floating point?
On 5/21/19 11:47 AM, Martin Sebor wrote: > The GCC coding style says to use "floating-point" as an adjective > rather than "floating point." After enhancing the -Wformat-diag > checker to detect this I found a bunch of uses of the latter, such > as in: > > gcc/c/c-decl.c:10944 > gcc/c/c-parser.c:9423, 9446, 9450, etc. > gcc/convert.c:418, 422 > gcc/cp/call.c:5070 > gcc/cp/cvt.c:886 > > Before I fix them all and adjust the tests, I want to make sure > we really want to follow this rule. The C standard uses both > interchangeably. With just one exception, the C++ standard uses > the hyphenated form. The hyphenated form is correct English, so I certainly prefer it. :-) Bill > > Thanks > Martin >
Re: -Wformat-diag: floating-point or floating point?
On 5/22/19 5:19 AM, Richard Earnshaw (lists) wrote: > On 21/05/2019 21:18, Bill Schmidt wrote: >> On 5/21/19 11:47 AM, Martin Sebor wrote: >>> The GCC coding style says to use "floating-point" as an adjective >>> rather than "floating point." After enhancing the -Wformat-diag >>> checker to detect this I found a bunch of uses of the latter, such >>> as in: >>> >>> gcc/c/c-decl.c:10944 >>> gcc/c/c-parser.c:9423, 9446, 9450, etc. >>> gcc/convert.c:418, 422 >>> gcc/cp/call.c:5070 >>> gcc/cp/cvt.c:886 >>> >>> Before I fix them all and adjust the tests, I want to make sure >>> we really want to follow this rule. The C standard uses both >>> interchangeably. With just one exception, the C++ standard uses >>> the hyphenated form. >> The hyphenated form is correct English, so I certainly prefer it. :-) >> > It's not quite as simple as that. Hyphens should be used to make it > clear what is the adjective and what is the noun: > >A floating-point number (hyphenated) is a number with a >floating point (no hyphen). > > In the first case 'floating-point' is the adjective and qualifies > number. In the second case 'floating' is the adjective and qualifies > 'point'. > > But this is English, so there are probably some exceptions even then - > but not in this case, I think. :-) English is always fun, agreed -- Martin cited the requirement to use "floating-point" when it's used as an adjective, which is certainly correct. There's a more interesting question around cavalier usage such as, "We should use floating point." I would argue that there is an implied noun "arithmetic" modified here, so this should also be hyphenated, but I daresay there would be people on both sides of this one... This is why grammar police usually die from friendly fire. :-) Bill > > R. >
Re: -Wformat-diag: floating-point or floating point?
On 5/22/19 9:58 AM, Martin Sebor wrote: > On 5/22/19 6:27 AM, Richard Earnshaw (lists) wrote: >> On 22/05/2019 13:17, Bill Schmidt wrote: >>> On 5/22/19 5:19 AM, Richard Earnshaw (lists) wrote: >>>> On 21/05/2019 21:18, Bill Schmidt wrote: >>>>> On 5/21/19 11:47 AM, Martin Sebor wrote: >>>>>> The GCC coding style says to use "floating-point" as an adjective >>>>>> rather than "floating point." After enhancing the -Wformat-diag >>>>>> checker to detect this I found a bunch of uses of the latter, such >>>>>> as in: >>>>>> >>>>>> gcc/c/c-decl.c:10944 >>>>>> gcc/c/c-parser.c:9423, 9446, 9450, etc. >>>>>> gcc/convert.c:418, 422 >>>>>> gcc/cp/call.c:5070 >>>>>> gcc/cp/cvt.c:886 >>>>>> >>>>>> Before I fix them all and adjust the tests, I want to make sure >>>>>> we really want to follow this rule. The C standard uses both >>>>>> interchangeably. With just one exception, the C++ standard uses >>>>>> the hyphenated form. >>>>> The hyphenated form is correct English, so I certainly prefer it. :-) >>>>> >>>> It's not quite as simple as that. Hyphens should be used to make it >>>> clear what is the adjective and what is the noun: >>>> >>>> A floating-point number (hyphenated) is a number with a >>>> floating point (no hyphen). >>>> >>>> In the first case 'floating-point' is the adjective and qualifies >>>> number. In the second case 'floating' is the adjective and qualifies >>>> 'point'. >>>> >>>> But this is English, so there are probably some exceptions even then - >>>> but not in this case, I think. :-) >>> >>> English is always fun, agreed -- Martin cited the requirement to use >>> "floating-point" when it's used as an adjective, which is certainly >>> correct. >>> >>> There's a more interesting question around cavalier usage such as, >>> "We should use floating point." I would argue that there is an implied >>> noun "arithmetic" modified here, so this should also be hyphenated, >>> but I daresay there would be people on both sides of this one... >> >> I would argue that leaving out "arithmetic" is the error. :-) > > I agree. Unfortunately, there are a few cases like that among > the diagnostics that my script has already fixed: > > decimal floating point not supported > comparing floating point with %<==%> or % is unsafe > ISO C does not support decimal floating point > > They probably should read > > decimal floating point types not supported > comparing floating-point values with %<==%> or % is unsafe > ISO C does not support decimal floating point types "decimal floating point types" does use "floating-point" to modify "types", so if you change those they should probably remain hyphenated. Technically the whole phrase "decimal floating point" modifies types together, and should be hyphenated together, but that just looks fussy and isn't common practice. None of those details are going to solve world hunger. :-) Thanks for fixing the general problem! For the edge cases, Richard's optimization looks better and better. :-P Bill > > I think they can be adjusted later if we think it's important, > after the checker is finalized and committed. I don't want to > complicate it too much by having to differentiate between > adjectives and nouns. The vast majority of the "floating point" > instances is has found are adjectives. > > Martin > > >>> This is why grammar police usually die from friendly fire. :-) >>> >> >> Sticking your head above the parapet is always fraught with danger :) >> >> >> R. >> >
Re: GCC 9.2 Release Candidate available from gcc.gnu.org
On 8/5/19 8:16 AM, Jakub Jelinek wrote: The first release candidate for GCC 9.2 is available from https://gcc.gnu.org/pub/gcc/snapshots/9.2.0-RC-20190805/ ftp://gcc.gnu.org/pub/gcc/snapshots/9.2.0-RC-20190805 and shortly its mirrors. It has been generated from SVN revision 274111. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 9.2 on Monday, August 12th. I bootstrapped and tested powerpc64 BE on power 7 and power 8 and powerpc64 LE on power 8 and power 9 and all looks well. -- -Bill Seurer
Re: SPEC 2017 profiling question (502.gcc_r and 505.mcf_r fail)
On 10/4/19 10:13 AM, Steve Ellcey wrote: I am curious if anyone has tried running 'peak' SPEC 2017 numbers using profiling. Now that the cactus lto bug has been fixed I can run all the SPEC intrate and fprate benchmarks with '-Ofast -flto -march=native' on my aarch64 box and get accurate results but when I try to use these options along with -fprofile-generate/-fprofile-use I get two verification errors: 502.gcc_r and 505.mcf_r. The gcc benchmark is generating different assembly language for some of its tests and mcf is generating different numbers that look too large to just be due to unsafe math optimizations. Has anyone else seen these failures? Have you tried -fno-strict-aliasing? There is a known issue with spec_qsort() that affects both of these benchmarks. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83201. Hope this helps, Bill Steve Ellcey sell...@marvell.com
Re: svn unavailable since more than an hour
On 10/30/19 1:29 PM, Rainer Emrich wrote: svn: E170013: Unable to connect to a repository at URL 'svn://gcc.gnu.org/svn/gcc/trunk' svn: E210002: Network connection closed unexpectedly I can ping gcc.gnu.org but if I tracert/traceroute to it I get: 24 server1.sourceware.org (209.132.180.131) 82.745 ms !X 82.740 ms !X 82.292 ms !X The !X means "communication administratively prohibited" apparently. -- -Bill Seurer
Re: GCC 7.5 Release Candidate available from gcc.gnu.org
On 11/5/19 6:45 AM, Richard Biener wrote:
The first release candidate for GCC 7.5 is available from
https://gcc.gnu.org/pub/gcc/snapshots/7.5.0-RC-20191105/
and shortly its mirrors. It has been generated from SVN revision 277823.
I have so far bootstrapped and tested the release candidate on
{x86_64,i586,ppc64le,s390x,aarch64}-linux. Please test it
and report any issues to bugzilla.
If all goes well, I'd like to release 7.5 on Thursday, November 14th.
I bootstrapped this on BE powerpc64 on power 7 and 8 and on LE powerpc64
on power 8 and 9 and nothing untoward was seen.
--
-Bill Seurer
Re: GCC 7.5 Release Candidate available from gcc.gnu.org
That second set of failures occurs already on 7.4.1...
On 11/7/19 5:48 AM, Matthias Klose wrote:
On 05.11.19 13:45, Richard Biener wrote:
The first release candidate for GCC 7.5 is available from
https://gcc.gnu.org/pub/gcc/snapshots/7.5.0-RC-20191105/
and shortly its mirrors. It has been generated from SVN revision
277823.
I have so far bootstrapped and tested the release candidate on
{x86_64,i586,ppc64le,s390x,aarch64}-linux. Please test it
and report any issues to bugzilla.
If all goes well, I'd like to release 7.5 on Thursday, November 14th.
With a distribution build (Ubuntu) on amd64, i386, armhf, arm64,
ppc64el and s390x, I don't see any regressions in the GCC testsuite
(compared to 7.4.0), except for two issues on ppc64el:
FAIL: gcc.target/powerpc/pr87532.c (test for excess errors)
Excess errors:
/build/gcc-7-8odB_r/gcc-7-7.4.0/src/gcc/testsuite/gcc.target/powerpc/pr87532.c:45:27:
warning: format '%d' expects argument of type 'int', but argument 2
has type 'size_t {aka long unsigned int}' [-Wformat=]
is a new test, and only caused by default hardening settings.
PASS: gcc.dg/vect/slp-perm-4.c execution test
FAIL: gcc.dg/vect/slp-perm-4.c scan-tree-dump-times vect "vectorized 1
loops" 1
PASS: gcc.dg/vect/slp-perm-4.c scan-tree-dump-times vect "gaps
requires scalar epilogue loop" 0
FAIL: gcc.dg/vect/slp-perm-4.c scan-tree-dump-times vect "vectorizing
stmts using SLP" 1
Matthias
Re: GCC 7.5 Release Candidate available from gcc.gnu.org
Er, sorry, I guess that is saying the same thing as it is broken in
7.5. Oops.
On 11/7/19 9:24 AM, Bill Schmidt wrote:
That second set of failures occurs already on 7.4.1...
On 11/7/19 5:48 AM, Matthias Klose wrote:
On 05.11.19 13:45, Richard Biener wrote:
The first release candidate for GCC 7.5 is available from
https://gcc.gnu.org/pub/gcc/snapshots/7.5.0-RC-20191105/
and shortly its mirrors. It has been generated from SVN revision
277823.
I have so far bootstrapped and tested the release candidate on
{x86_64,i586,ppc64le,s390x,aarch64}-linux. Please test it
and report any issues to bugzilla.
If all goes well, I'd like to release 7.5 on Thursday, November 14th.
With a distribution build (Ubuntu) on amd64, i386, armhf, arm64,
ppc64el and s390x, I don't see any regressions in the GCC testsuite
(compared to 7.4.0), except for two issues on ppc64el:
FAIL: gcc.target/powerpc/pr87532.c (test for excess errors)
Excess errors:
/build/gcc-7-8odB_r/gcc-7-7.4.0/src/gcc/testsuite/gcc.target/powerpc/pr87532.c:45:27:
warning: format '%d' expects argument of type 'int', but argument 2
has type 'size_t {aka long unsigned int}' [-Wformat=]
is a new test, and only caused by default hardening settings.
PASS: gcc.dg/vect/slp-perm-4.c execution test
FAIL: gcc.dg/vect/slp-perm-4.c scan-tree-dump-times vect "vectorized
1 loops" 1
PASS: gcc.dg/vect/slp-perm-4.c scan-tree-dump-times vect "gaps
requires scalar epilogue loop" 0
FAIL: gcc.dg/vect/slp-perm-4.c scan-tree-dump-times vect "vectorizing
stmts using SLP" 1
Matthias
Re: GCC 7.5 Release Candidate available from gcc.gnu.org
On 11/7/19 5:48 AM, Matthias Klose wrote:
On 05.11.19 13:45, Richard Biener wrote:
The first release candidate for GCC 7.5 is available from
https://gcc.gnu.org/pub/gcc/snapshots/7.5.0-RC-20191105/
and shortly its mirrors. It has been generated from SVN revision
277823.
I have so far bootstrapped and tested the release candidate on
{x86_64,i586,ppc64le,s390x,aarch64}-linux. Please test it
and report any issues to bugzilla.
If all goes well, I'd like to release 7.5 on Thursday, November 14th.
With a distribution build (Ubuntu) on amd64, i386, armhf, arm64,
ppc64el and s390x, I don't see any regressions in the GCC testsuite
(compared to 7.4.0), except for two issues on ppc64el:
FAIL: gcc.target/powerpc/pr87532.c (test for excess errors)
Excess errors:
/build/gcc-7-8odB_r/gcc-7-7.4.0/src/gcc/testsuite/gcc.target/powerpc/pr87532.c:45:27:
warning: format '%d' expects argument of type 'int', but argument 2
has type 'size_t {aka long unsigned int}' [-Wformat=]
is a new test, and only caused by default hardening settings.
PASS: gcc.dg/vect/slp-perm-4.c execution test
FAIL: gcc.dg/vect/slp-perm-4.c scan-tree-dump-times vect "vectorized 1
loops" 1
PASS: gcc.dg/vect/slp-perm-4.c scan-tree-dump-times vect "gaps
requires scalar epilogue loop" 0
FAIL: gcc.dg/vect/slp-perm-4.c scan-tree-dump-times vect "vectorizing
stmts using SLP" 1
I finally bisected this to r275208:
2019-08-30 Richard Biener mailto:rguenther%40suse.de>>
Backport from mainline
2019-05-27 Richard Biener mailto:rguenther%40suse.de>>
PR tree-optimization/90637
* tree-ssa-sink.c (statement_sink_location): Honor the
computed sink location for single-uses.
* gcc.dg/gomp/pr90637.c: New testcase.
2019-06-21 Richard Biener mailto:rguenther%40suse.de>>
PR tree-optimization/90930
* tree-ssa-reassoc.c (rewrite_expr_tree_parallel): Set visited
flag on new stmts to avoid re-processing them.
2019-05-15 Richard Biener mailto:rguenther%40suse.de>>
PR c/90474
* c-common.c (c_common_mark_addressable_vec): Also mark
a COMPOUND_LITERAL_EXPR_DECL addressable similar to
c_mark_addressable.
2019-04-25 Richard Biener mailto:rguenther%40suse.de>>
PR middle-end/90194
* match.pd: Add pattern to simplify view-conversion of an
empty constructor.
* g++.dg/torture/pr90194.C: New testcase.
2019-04-24 Richard Biener mailto:rguenther%40suse.de>>
PR middle-end/90213
* gimple-fold.c (fold_const_aggregate_ref_1): Do multiplication
by size and BITS_PER_UNIT on poly-wide-ints.
2019-04-15 Richard Biener mailto:rguenther%40suse.de>>
PR tree-optimization/90071
* tree-ssa-reassoc.c (init_range_entry): Do not pick up
abnormal operands from def stmts.
* gcc.dg/torture/pr90071.c: New testcase.
2019-03-13 Richard Biener mailto:rguenther%40suse.de>>
PR middle-end/89677
* tree-scalar-evolution.c (simplify_peeled_chrec): Do not
throw FP expressions at tree-affine.
* gcc.dg/torture/pr89677.c: New testcase.
This looks rather familiar, actually. I seem to recall an SLP
degradation from a change to tree-ssa-sink.c on trunk this release.
Richi, could there be a missing backport here?
Bill
Matthias
Re: GCC 7.5 Release Candidate available from gcc.gnu.org
On 11/11/19 7:26 AM, Richard Biener wrote:
On Fri, 8 Nov 2019, Bill Schmidt wrote:
On 11/7/19 5:48 AM, Matthias Klose wrote:
On 05.11.19 13:45, Richard Biener wrote:
The first release candidate for GCC 7.5 is available from
https://gcc.gnu.org/pub/gcc/snapshots/7.5.0-RC-20191105/
and shortly its mirrors. It has been generated from SVN revision 277823.
I have so far bootstrapped and tested the release candidate on
{x86_64,i586,ppc64le,s390x,aarch64}-linux. Please test it
and report any issues to bugzilla.
If all goes well, I'd like to release 7.5 on Thursday, November 14th.
With a distribution build (Ubuntu) on amd64, i386, armhf, arm64, ppc64el and
s390x, I don't see any regressions in the GCC testsuite (compared to 7.4.0),
except for two issues on ppc64el:
FAIL: gcc.target/powerpc/pr87532.c (test for excess errors)
Excess errors:
/build/gcc-7-8odB_r/gcc-7-7.4.0/src/gcc/testsuite/gcc.target/powerpc/pr87532.c:45:27:
warning: format '%d' expects argument of type 'int', but argument 2 has type
'size_t {aka long unsigned int}' [-Wformat=]
is a new test, and only caused by default hardening settings.
PASS: gcc.dg/vect/slp-perm-4.c execution test
FAIL: gcc.dg/vect/slp-perm-4.c scan-tree-dump-times vect "vectorized 1
loops" 1
PASS: gcc.dg/vect/slp-perm-4.c scan-tree-dump-times vect "gaps requires
scalar epilogue loop" 0
FAIL: gcc.dg/vect/slp-perm-4.c scan-tree-dump-times vect "vectorizing
stmts using SLP" 1
I finally bisected this to r275208:
2019-08-30 Richard Biener mailto:rguenther%40suse.de>>
Backport from mainline
2019-05-27 Richard Biener mailto:rguenther%40suse.de>>
PR tree-optimization/90637
* tree-ssa-sink.c (statement_sink_location): Honor the
computed sink location for single-uses.
* gcc.dg/gomp/pr90637.c: New testcase.
2019-06-21 Richard Biener mailto:rguenther%40suse.de>>
PR tree-optimization/90930
* tree-ssa-reassoc.c (rewrite_expr_tree_parallel): Set visited
flag on new stmts to avoid re-processing them.
2019-05-15 Richard Biener mailto:rguenther%40suse.de>>
PR c/90474
* c-common.c (c_common_mark_addressable_vec): Also mark
a COMPOUND_LITERAL_EXPR_DECL addressable similar to
c_mark_addressable.
2019-04-25 Richard Biener mailto:rguenther%40suse.de>>
PR middle-end/90194
* match.pd: Add pattern to simplify view-conversion of an
empty constructor.
* g++.dg/torture/pr90194.C: New testcase.
2019-04-24 Richard Biener mailto:rguenther%40suse.de>>
PR middle-end/90213
* gimple-fold.c (fold_const_aggregate_ref_1): Do multiplication
by size and BITS_PER_UNIT on poly-wide-ints.
2019-04-15 Richard Biener mailto:rguenther%40suse.de>>
PR tree-optimization/90071
* tree-ssa-reassoc.c (init_range_entry): Do not pick up
abnormal operands from def stmts.
* gcc.dg/torture/pr90071.c: New testcase.
2019-03-13 Richard Biener mailto:rguenther%40suse.de>>
PR middle-end/89677
* tree-scalar-evolution.c (simplify_peeled_chrec): Do not
throw FP expressions at tree-affine.
* gcc.dg/torture/pr89677.c: New testcase.
This looks rather familiar, actually. I seem to recall an SLP degradation
from a change to tree-ssa-sink.c on trunk this release. Richi, could there be
a missing backport here?
Not sure - it's reassoc that messes up things here and a
--param tree-reassoc-width=1 "fixes" the failure. For PR90930 I
restricted this to the last pass instance (but only on trunk).
Does it also fail on the GCC 8 and 9 branches? Ah, on GCC 8 at least
the default target setting for this seems to be 1 (it's non-FP,
maybe you changed that), with explicit --param tree-reassoc-width={2,3,4}
it also fails the same way.
OK; yes, I think one of our team did some refining of the reassoc
parameters in that timeframe, so this makes sense.
It's a bit late to try thinking about backporting this change
but I'll now consider it for GCC 9 at least.
So IMHO a latent issue, somehow the rev. triggered "inconsistent"
reassoc for the testcase. I'm going to leave it as-is for GCC 7.5
(with the testsuite regression).
Are you fine with that? An explicit --param tree-reassoc-width=1
on the testcase also would work for me if you prefer that.
I am fine with leaving the testcase regressed; we have a good
explanation and this isn't a serious issue for users. Thanks for
investigating!
Bill
Thanks,
Richard.
Re: -fsanitize=thread support on ppc64
TSan support was contributed to LLVM by a student working at one of the US National Labs a while back. I helped him with some of the PPC assembly programming. To my knowledge this is working, but I haven't tested this with GCC. Do you think we want to change the configuration for GCC this late in the release? I can run a quick test with TSan turned on to see where we're at. -- Bill Bill Schmidt, Ph.D. GCC for Linux on Power Linux on Power Toolchain IBM Linux Technology Center wschm...@linux.vnet.ibm.com > On Jan 23, 2017, at 6:53 AM, Maxim Ostapenko wrote: > > Hi, > > On 23/01/17 14:33, Jakub Jelinek wrote: >> Hi! >> >> I've noticed today there is tsan_rtl_ppc64.S file since the latest >> merge from upstream. Does that mean tsan is supposed to work >> on ppc64? Just powerpc64le-*-linux*, or powerpc64-*-linux* too? > > FWIW LLVM has build bots for both ppc64le-linux and ppc64be-linux, see: > http://lab.llvm.org:8011/builders/sanitizer-ppc64le-linux > http://lab.llvm.org:8011/builders/sanitizer-ppc64be-linux > > Thus TSan is supposed to work on ppc64, I guess. > > -Maxim > >> If yes, then libsanitizer/configure.tgt should be changed to reflect that >> change. >> >> Jakub >> >> >
Re: -fsanitize=thread support on ppc64
> On Jan 23, 2017, at 8:32 AM, Jakub Jelinek wrote:
>
> On Mon, Jan 23, 2017 at 08:22:30AM -0600, Bill Schmidt wrote:
>> TSan support was contributed to LLVM by a student working at one of the US
>> National Labs a while back. I helped him with some of the PPC assembly
>> programming. To my knowledge this is working, but I haven't tested this with
>> GCC. Do you think we want to change the configuration for GCC this late in
>> the
>> release? I can run a quick test with TSan turned on to see where we're at.
>
> I think it should be enabled if it works, even this late.
> I bet we need something like the following patch on top of
> the PR79168 patch.
>
> I'll test both patches on both ppc64le and ppc64.
Sounds good, thanks! Let me know if I can help in any way.
>
> Another question is, it seems upstream has s390{,x}-*-linux* support for
> asan/ubsan, does that work? In that case we should add it to configure.tgt
> too (similarly to the sparc*-*-linux* entry).
CCing Uli for the s390 question.
Bill
>
> 2017-01-23 Jakub Jelinek
>
> * configure.tgt: Enable tsan and lsan on powerpc64{,le}-*-linux*.
>
> --- libsanitizer/configure.tgt.jj 2016-11-09 15:22:50.0 +0100
> +++ libsanitizer/configure.tgt2017-01-23 15:25:21.059399613 +0100
> @@ -1,5 +1,5 @@
> # -*- shell-script -*-
> -# Copyright (C) 2012 Free Software Foundation, Inc.
> +# Copyright (C) 2012-2017 Free Software Foundation, Inc.
>
> # This program is free software; you can redistribute it and/or modify
> # it under the terms of the GNU General Public License as published by
> @@ -31,6 +31,11 @@ case "${target}" in
> fi
> ;;
> powerpc*-*-linux*)
> + if test x$ac_cv_sizeof_void_p = x8; then
> + TSAN_SUPPORTED=yes
> + LSAN_SUPPORTED=yes
> + TSAN_TARGET_DEPENDENT_OBJECTS=tsan_rtl_ppc64.lo
> + fi
> ;;
> sparc*-*-linux*)
> ;;
>
>
> Jakub
>
Re: -fsanitize=thread support on ppc64
> On Jan 23, 2017, at 8:32 AM, Jakub Jelinek wrote:
>
> On Mon, Jan 23, 2017 at 08:22:30AM -0600, Bill Schmidt wrote:
>> TSan support was contributed to LLVM by a student working at one of the US
>> National Labs a while back. I helped him with some of the PPC assembly
>> programming. To my knowledge this is working, but I haven't tested this with
>> GCC. Do you think we want to change the configuration for GCC this late in
>> the
>> release? I can run a quick test with TSan turned on to see where we're at.
>
> I think it should be enabled if it works, even this late.
> I bet we need something like the following patch on top of
> the PR79168 patch.
>
> I'll test both patches on both ppc64le and ppc64.
>
> Another question is, it seems upstream has s390{,x}-*-linux* support for
> asan/ubsan, does that work? In that case we should add it to configure.tgt
> too (similarly to the sparc*-*-linux* entry).
>
> 2017-01-23 Jakub Jelinek
>
> * configure.tgt: Enable tsan and lsan on powerpc64{,le}-*-linux*.
>
> --- libsanitizer/configure.tgt.jj 2016-11-09 15:22:50.0 +0100
> +++ libsanitizer/configure.tgt2017-01-23 15:25:21.059399613 +0100
> @@ -1,5 +1,5 @@
> # -*- shell-script -*-
> -# Copyright (C) 2012 Free Software Foundation, Inc.
> +# Copyright (C) 2012-2017 Free Software Foundation, Inc.
>
> # This program is free software; you can redistribute it and/or modify
> # it under the terms of the GNU General Public License as published by
> @@ -31,6 +31,11 @@ case "${target}" in
> fi
> ;;
> powerpc*-*-linux*)
I think you want a separate entry for powerpc64*-*-linux* -- IIRC, the
existing code will definitely not work for 32-bit due to TLS differences.
Thus be sure we don't enable TSAN for powerpc-*-linux.
Bill
> + if test x$ac_cv_sizeof_void_p = x8; then
> + TSAN_SUPPORTED=yes
> + LSAN_SUPPORTED=yes
> + TSAN_TARGET_DEPENDENT_OBJECTS=tsan_rtl_ppc64.lo
> + fi
> ;;
> sparc*-*-linux*)
> ;;
>
>
> Jakub
>
Re: -fsanitize=thread support on ppc64
> On Jan 23, 2017, at 8:47 AM, Jakub Jelinek wrote:
>
> On Mon, Jan 23, 2017 at 08:45:16AM -0600, Bill Schmidt wrote:
>>> 2017-01-23 Jakub Jelinek
>>>
>>> * configure.tgt: Enable tsan and lsan on powerpc64{,le}-*-linux*.
>>>
>>> --- libsanitizer/configure.tgt.jj 2016-11-09 15:22:50.0 +0100
>>> +++ libsanitizer/configure.tgt 2017-01-23 15:25:21.059399613 +0100
>>> @@ -1,5 +1,5 @@
>>> # -*- shell-script -*-
>>> -# Copyright (C) 2012 Free Software Foundation, Inc.
>>> +# Copyright (C) 2012-2017 Free Software Foundation, Inc.
>>>
>>> # This program is free software; you can redistribute it and/or modify
>>> # it under the terms of the GNU General Public License as published by
>>> @@ -31,6 +31,11 @@ case "${target}" in
>>> fi
>>> ;;
>>> powerpc*-*-linux*)
>>
>> I think you want a separate entry for powerpc64*-*-linux* -- IIRC, the
>> existing code will definitely not work for 32-bit due to TLS differences.
>> Thus be sure we don't enable TSAN for powerpc-*-linux.
>
> That is handled by the
>
>>> + if test x$ac_cv_sizeof_void_p = x8; then
>
> test (similarly how for both i?86-*-linux* and x86_64-*-linux* it is enabled
> only for LP64 multilib and not others). We want to enable it only for the
> 64-bit multilib, not 32-bit.
Ah, quite right. Sorry for the sloppy reading.
Bill
>
>>> + TSAN_SUPPORTED=yes
>>> + LSAN_SUPPORTED=yes
>>> + TSAN_TARGET_DEPENDENT_OBJECTS=tsan_rtl_ppc64.lo
>>> + fi
>>> ;;
>>> sparc*-*-linux*)
>>> ;;
>
> Jakub
>
Re: lvx versus lxvd2x on power8
Hi Igor, (Apologies for not threading this, I haven't received my digest for this list yet) You wrote: >I recently checked this old discussion about when/why to use lxvd2x instead of >lvsl/lvx/vperm/lvx to load elements from memory to vector: >https://gcc.gnu.org/ml/gcc/2015-03/msg00135.html >I had the same doubt and I was also concerned how performance influences on >these >approaches. So that, I created the following project to check which one is >faster >and how memory alignment can influence on results: >https://github.com/PPC64/load_vec_cmp >This is a simple code, that many loads (using both approaches) are executed in >a >simple loop in order to measure which implementation is slower. The project >also >considers alignment. >As it can be seen on this plot >(https://raw.githubusercontent.com/igorsnunes/load_vec_cmp/master/doc/LoadVecCompare.png) >an unaligned load using lxvd2x takes more time. >The previous discussion (as far as I could see) addresses that lxvd2x performs >better than lvsl/lvx/vperm/lvx in all cases. Is that correct? Is my analysis >wrong? >This issue concerned me, once lxvd2x is heavily used on compiled code. One problem with your analysis is that you are forcing the use of the xxswapd following the lxvd2x. Although this is technically required for a load in isolation to place elements in the correct lanes, in practice the compiler is able to remove almost all of the xxswapd instructions during optimization. Most SIMD code does not care about which lanes are used for calculation, so long as results in memory are placed properly. For computations that do care, we can often adjust the computations to still allow the swaps to be removed. So your analysis does not show anything about how code is produced in practice. Another issue is that you're throwing away the results of the loads, which isn't a particularly useful way to measure the costs of the latencies of the instructions. Typically with the pipelined lvx implementation, you will have an lvx feeding the vperm feeding at least one use of the loaded value in each iteration of the loop, while with lxvd2x and optimization you will only have an lxvd2x feeding the use(s). The latter is easier for the scheduler to cover latencies in most cases. Finally, as a rule of thumb, these kind of "loop kernels" are really bad for predicting performance, particularly on POWER. In the upcoming POWER9 processors, the swap issue goes away entirely, as we will have true little-endian unaligned loads (the indexed-form lxvx to replace lxvd2x/ xxswapd, and the offset-form lxv to reduce register pressure). Now, you will of course see slightly worse unaligned performance for lxvd2x versus aligned performance for lxvd2x. This happens at specific crossing points where the hardware has to work a bit harder. I hate to just say "trust me" but I want you to understand that we have been looking at these kinds of performance issues for several years. This does not mean that there are no cases where the pipelined lvx solution works better for a particular loop, but if you let the compiler optimize it (or do similar optimization in your own assembly code), lxvd2x is almost always better. Thanks, Bill
Re: GCC 6.4 Release Candidate available from gcc.gnu.org
On 06/28/2017 05:44 AM, Richard Biener wrote: A release candidate for GCC 6.4 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/6.4.0-RC-20170628/ and shortly its mirrors. It has been generated from SVN revision 249715. I have so far bootstrapped and tested the release candidate on x86_64-unknown-linux-gnu. Please test it and report any issues to bugzilla. If all goes well I'd like to release 6.4 on Tuesday, July 4th. I bootstrapped and tested on powerpc64 BE and LE (powerpc64-unknown-linux-gnu and powerpc64le-unknown-linux-gnu) and there were no problems. -- -Bill Seurer
Re: Building on gcc112 is stuck in msgfmt
On 08/28/2017 02:16 AM, Martin Liška wrote:
Hello.
I've just repeatedly seen stuck in build process:
make[5]: Entering directory
`/home/marxin/Programming/gcc/objdir/powerpc64le-unknown-linux-gnu/libstdc++-v3/po'
msgfmt -o de.mo ../../../../libstdc++-v3/po/de.po
49__asm volatile ("sc; mfcr %0"
Missing separate debuginfos, use: debuginfo-install
gettext-0.18.2.1-4.el7.ppc64le
(gdb) bt
#0 0x3fff85d8bac8 in sys_futex0 (val=-1, op=128, addr=0x3fff85db0520
) at ../../../libgomp/config/linux/powerpc/futex.h:49
#1 futex_wait (val=-1, addr=0x3fff85db0520 ) at
../../../libgomp/config/linux/powerpc/futex.h:62
#2 do_wait (val=-1, addr=) at
../../../libgomp/config/linux/wait.h:67
#3 gomp_mutex_lock_slow (mutex=0x3fff85db0520 ,
oldval=) at ../../../libgomp/config/linux/mutex.c:63
#4 0x3fff85d98b04 in gomp_mutex_lock (mutex=0x3fff85db0520
) at ../../../libgomp/config/linux/mutex.h:57
#5 goacc_register (disp=0x3fff85db0090 ) at
../../../libgomp/oacc-init.c:74
#6 0x3fff85d983fc in goacc_host_init () at ../../../libgomp/oacc-host.c:265
#7 0x3fff85d99c88 in goacc_runtime_initialize () at
../../../libgomp/oacc-init.c:657
#8 0x3fff85d7882c in initialize_env () at ../../../libgomp/env.c:1340
#9 0x3fff86525c74 in _dl_init_internal () from /lib64/ld64.so.2
#10 0x3fff865119cc in _dl_start_user () from /lib64/ld64.so.2
$ msgfmt --version
msgfmt (GNU gettext-tools) 0.18.2
Is it a known issue, has anybody spotted that as well?
Thanks,
Martin
I just did a build/test of current trunk (all languages, r251389) on a
powerpc64le RHEL 7.3 system that has the same version of msgfmt and it
went fine.
--
-Bill Seurer
Re: GCC 7.3 Release Candidate available from gcc.gnu.org
On 01/17/2018 10:46 AM, Richard Biener wrote: A release candidate for GCC 7.3 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/gcc-7.3.0-RC-20180117/ and shortly its mirrors. It has been generated from SVN revision 256792. I have so far bootstrapped and tested the release candidate on x86_64-unknown-linux-gnu. Please test it and report any issues to bugzilla. If all goes well I'd like to release 7.3 on Wednesday, January 24th. Everything looks good with this for powerpc64. -- -Bill Seurer
Re: GCC 8.1 Release Candidate available from gcc.gnu.org
On 04/25/2018 05:04 AM, Jakub Jelinek wrote: https://gcc.gnu.org/pub/gcc/snapshots/8.0.1-RC-20180425/ The first release candidate for GCC 8.1 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/8.0.1-RC-20180425 and shortly its mirrors. It has been generated from SVN revision 259636. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 8.1 on Wednesday, May 2nd. I bootstrapped and tested it on powerpc64 both LE (power 8 and power 9) and BE (power 8 and power 7) and it looks good. -- -Bill Seurer
Re: Second GCC 8.1 Release Candidate available from gcc.gnu.org
On 04/27/18 16:39, Jakub Jelinek wrote: The second release candidate for GCC 8.1 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/8.0.1-RC-20180427 and shortly its mirrors. It has been generated from SVN revision 259731. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 8.1 on Wednesday, May 2nd. I bootstrapped and tested it on powerpc64 BE and LE on power8 and power9 (LE) and power 8 and power 7 (BE) and saw no problems. -- -Bill Seurer
Re: GCC 8.2 Release Candidate available from gcc.gnu.org
On 07/19/18 07:28, Richard Biener wrote: A release candidate for GCC 8.2 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/8.2.0-RC-20180719/ and shortly its mirrors. It has been generated from SVN revision 262876. I have so far bootstrapped and tested the release candidate on x86_64-unknown-linux-gnu. Please test it and report any issues to bugzilla. If all goes well I'd like to release 8.2 on Thursday, July 26th. I bootstrapped and tested this on power 7 and power 8 big endian and power 8 and power 9 little endian and saw no problems. -- -Bill Seurer
Re: [fedora-arm] ARM summit at Plumbers 2011
Luke: Step back from the keyboard just a bit. :) It's true that the glass isn't completely full--- but it's pretty darned full! And we wouldn't be discussing the various GPL and other violations that you cite were it not for the overwhelming successes of Free Software, ARM, Linux, and Android. We are well past debating the merits of Free Software et. al, which itself is a huge milestone that we need to recognize. Now it's time to let the lawyers do their jobs. And they will, because there are tremendous sums of money at play. Money that wouldn't be there if it weren't for us developers. But we need to stay out of their way, while at the same time taking care to continue producing tangible things that are worth fighting over. As developers, we've won. Deal with it. Revel in it. And then get over it. I have observed all the hand-wringing regarding the state of ARM Linux, and it's obvious to everyone that there is still work to be done. ARM isn't like PCs, and that's obviously inconvenient for Linus but it's an essential part of ARM's success. Russell King has been overworked for a decade or more, attempting through sheer force of human/developer will to keep ARM Linux from running off the rails. As far as ARM Linux is concerned, I think we're dangerously close to being smothered by our own success. We have to learn to work smarter, because we can't work any harder. And I applaud Linaro and the countless others for recognizing this problem and looking for ways to resolve it. I for one would love to participate in the ARM Summit, but I'm a sole proprietor without an expense account to charge the travel costs to and they are too large for me to carry personally. I suspect I'm not the only one in that situation. The fact that there has been little response to the ARM Summit doesn't mean that nobody cares or that the problems seem to large to solve. It just means that we're going to have to find a different way to get this work done. b.g. -- Bill Gatliff b...@billgatliff.com
Re: [LLVMdev] updated code size comparison
On Dec 16, 2009, at 1:26 AM, Paolo Bonzini wrote: > On 12/16/2009 03:21 AM, John Regehr wrote: >> Hopefully the results are more fair and useful now. Again, feedback is >> appreciated. > > I would also avoid testcases using volatile. Smaller code on these > testcases is often a sign of miscompilation rather than optimization. > For example, > http://embed.cs.utah.edu/embarrassing/src_harvested_dec_09/076389.c is > miscompiled on GCC 3.4 and SunCC 5.10. > Perhaps just leaving out those volatile tescases which are miscompiled on other platforms, since not every volatile testcase fails for all compilers. :-) -bw
Re: [LLVMdev] Summer of Code 2009 "Support for an ELF writer"
On Mon, Apr 20, 2009 at 1:34 PM, Kirill Kononenko wrote: > Hello > > > So how did it happen that the only project which was a candidate for > libJIT Summer of Code in GNU, with the same title got selected in > LLVM? > > > Does it mean that the same genius idea came to two minds? > No. It's a conspiracy, of course. -bw
Dumb idea for accelerating FOSS development
First, the problem: I've got a C library I want to share. There are many users who want to use it. This should be as easy as breathing, but it's not! My users and I face what I'm calling "GNU/Linux Innovation Red Tape". This library is two files: sonic.c and sonic.h. To share it in Debian, first, I had to learn how to make a clean Debian package. Something like 30 files are involved, and in my case a few days of learning and laboring. Next, I have to grovel on the debian-mentor's list, and pray that Debian Sponsor Gods will take pity on me. No response from the Sponsor Gods so far... maybe I'll have more luck after they've finished the current release. Shouldn't we be ashamed that getting a package into Debian is harder than publishing an app for iPhones? Assuming I find a Debian sponsor, my package will be uploaded to Unstable, then Testing, and after a few years, Stable. Guess where my package has to be before my users are willing to link to it? Debian Stable. We're hosed. There's just no freaking way for my users to use my library. You know what they do? Every one of them bypasses the Innovation Red Tape, and simply copies my source code directly into their application. How's that as a reuse paradigm? My dumb idea for today is a way to break through this red tape. Unfortunately, while I could implement this idea in a few days, the red tape would keep it in limbo so long that I'll likely die of old age before it gets into Debian Stable. Oh, well... here's the dumb idea anyway... In short, support a syntax in gcc like: $ gcc myprog.c -lgit://github/~waywardgeek/sonic=0.1 In theory, this would cause gcc to do the following: - Check and see if the requested library has already been downloaded and built, and still in the cache - If not, download the latest compatible signed version, verify the signature, and compile it - link to the library in the cache A feature like this would make sharing C libraries as easy as breathing. My users wouldn't even have to 'apt-get install libsonic0-dev'. They would stop copying my source code, and just link to my library. Sharing of C libraries in FOSS land might increase dramatically. The year of GNU/Linux on the desktop would finally come, and we'd all march off to Paradise as heroes. Or not. Anyway, just my dumb idea for the day... If through some miracle this particular dumb idea appeals to the GCC Gods, I volunteer to write it. Bill
Re: Dumb idea for accelerating FOSS development
On Wed, Jan 12, 2011 at 8:43 AM, Axel Freyn wrote: > Hi, > On Wed, Jan 12, 2011 at 01:43:51PM +0100, Basile Starynkevitch wrote: >> On Wed, Jan 12, 2011 at 06:07:48AM -0500, Bill Cox wrote: >> > Unfortunately, while I could implement this idea in a few days, the >> > red tape would keep it in limbo so long that I'll likely die of old >> > age before it gets into Debian Stable. Oh, well... here's the dumb >> > idea anyway... In short, support a syntax in gcc like: >> > >> > $ gcc myprog.c -lgit://github/~waywardgeek/sonic=0.1 >> > >> > In theory, this would cause gcc to do the following: >> > >> > - Check and see if the requested library has already been >> > downloaded and built, and still in the cache >> > - If not, download the latest compatible signed version, verify >> > the signature, and compile it >> > - link to the library in the cache >> >> At a first glance, I find your idea crazy but nice (but what about header >> files *.h of the requested library?). I would be delighted to have it. Maybe >> others don't think that way (in particular, those not working on Linux, and >> those not working on a compiler running with a network connection). >> >> Very probably ccache is the better place to implement that, since it already >> do >> some (preprocessed) source code cache. http://ccache.samba.org/ >> >> However, my personal feeling is that GCC is quite conservative on the user >> features it is accepting. So I won't bet that your idea will be positively >> accepted. > Well, it is not exactly what you are asking for, but the depot_tools > used in the chromium developement might be a solution: > http://www.chromium.org/developers/how-tos/depottools > The can keep track of different libraries checkout out from svn or git > repositories, and calling "gclient sync" connects to all repositories > belonging to the project and verifies that all files are up-to-date. > May be that would be a better starting point than using gcc? > > Axel > Well, after a short nap, the thought of fixing this in gcc seems even dumber to me, though the problem is quite real. Another tool called before gcc could get the header and library files into a place where they could be used. It could even be compiler independent. A bit of Googling reveals Zero Install. Looks like these guys are trying to tackle the problem. Bill
gcc-3.4.6 and pdp11
I would like to know who supports pdp11 for 3.4.6 or even the latest 4.x version of gcc? Is it still being maintained ? I'm trying to cross compile a pdp11 on my i686 and I'm having problems. If I can talk to the maintainer(s) I can get some help and maybe even get involved in pdp11 support. Bill
libiberty
Everytime I compile gcc I see that libiberty is being compiled. Is this a needed library and if not how can I switch it off? I'm using glibc-2.1 and I'd like to figure out compiling 2.3 and I've done it before so I just have to remember how. I want to cut down on all that compile time. Bill
Ada
Are there any special switches or options needed to compile the ada package with the core gcc? I add the C++ libraries and they compile right along with the core. I've tried --enable-languages=c,c++,ada too and that doesn't do the ada libraries. Bill
gcc compile time
I used gcc-2.96 to compile gcc-3.4.6 core with the c++ libraries added. It took almost if not two hours to compile and that was with these options: make CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap This is supposed to save space. I want to cut down on compile time. Are there any options that can do that? Bill
ada
I tried that RPM for gnat 3.15 and it wants binutils 2.9 and well I built a binary version of binutils 2.16 with a 3.4.6 compiler. So RPM doesn't know binutils is installed. So what I need to do is force RPM to install this .rpm by overriding it's checking for dependancies. Would anyone happen to know what switches to use? The man I have on my RPM is pretty cryptic. I know this is a little OT. Bill
simple c compiler
Where's the simplest part of the source tree to learn from? GCC? Does that directory contain the compiler simple? I've pulled some inodes containing an old c compiler from a unix v7 but it's old k&r C. I want to see a multiple pass C compiler in ansi. Bill
Re: Wrong link?
Dave: Gerald, you've jumped to a false conclusion there; "was hijacked" should read "has bitrotted". "Hijacked" is a pejorative term, and also historically and factually inaccurate. Objsw.com maintained the FAQ initially, but some time ago (around 2001 off the top of my head) it became clear that it had fallen into disrepair, and Bill Gatliff, who was then and is now an active and valuable contributing member of the crossgcc community, volunteered to take it over. He then actively maintained it for several years and it was only when his website got hacked and wiped out sometime last year that the link became out of date. He has been slow in getting his website rebuilt and hasn't put the FAQ back up yet; which is why I've Cc'd him in on this thread. Indeed, "bitrotted" is in fact a better description of what is happening. Bill, you need to make your intentions clear as to whether you are able and willing to resume your maintainance duties. Are you going to get the crossgcc FAQ back up there? If not, probably the best thing to do would be to replace the paragraph with a reference to the mailing list ([EMAIL PROTECTED]) and to Dan Kegel's crosstool and the related website. Thanks for the kind words, Dave. I am still quite committed to the crossgcc community, but I'm doing a lot of work behind the scenes as of late. It's ironic that the security breach came through the Wiki software I had set up as a supplement to the FAQ. A wiki that _nobody_ seemed to pay any attention to. Ever. Even when it was clear that many of the information needs of the crossgcc community were not being well met by a FAQ-type document. Even when I had posted tutorials and detailed build procedures in the Wiki, which were really too detailed for a FAQ. I don't think that a blanket link to crosstool is what is needed, because there is a lot of information that crossgcc'ers need that crosstool doesn't address, for example how to integrate newlib into an embedded system. Crosstool doesn't even do newlib, in fact. I'm happy to resume hosting the crossgcc document, but I don't have the time at the moment to give it a major overhaul--- which is what it needs. And I hesitate to restore a document that is out of date. And I still think a Wiki is the way to go, and I'm willing to donate a dedicated machine and a more secure Wiki installation towards that goal. But since nobody contributed before, I don't have any reason to believe anyone will contribute now. Which makes me wonder if anyone is using it, and I don't have the time to maintain a document that nobody reads. We couldn't even get anyone to change the URL in the mailing list to point to the right place. To summarize, I'm happy to re-post the FAQ but it is out of date and has been for some time. It needs someone with the interest and time to update it. Furthermore, I'm willing to donate resources to provide a Wiki, which I think is a better way to provide the information that people might be looking for. But in both cases only if someone will actually use it. Suggestions welcome. At any rate, I would prefer the term "hijacked" not be used, since it is historically and factually inaccurate. b.g. -- Bill Gatliff [EMAIL PROTECTED]
Re: Wrong link?
Joe et al: But the GCC project already has a Wiki, at http://gcc.gnu.org/wiki which is actively maintained by the developers. I think it would be best to use that wiki, we'd have better odds that active developers would keep it current if it were in the wiki they use. I completely agree. I recommend that we dispense with the FAQ altogether and put what we know into the gcc wiki. The closer we work with the gcc team, the more likely it is that they will continue to support us. b.g. -- Bill Gatliff [EMAIL PROTECTED]
Libiberty
I haven't found anything in the docs that I see that explains the libiberty library. Can this be compiled without having to compile a whole new compiler? I am running 3.4.6 and what to cross compile for a pdp-11. I just want to compile the extra support and that's all. Bill
Re: Libiberty
- Original Message - From: "DJ Delorie" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 01, 2006 10:31 PM Subject: Re: Libiberty > > Please don't reply to me personally, use the mailing list. Sorry I just pressed reply. You personal address must have been there. Bill
Darwin cross-compiler build failures on ppc MacOSX/Darwin
I am trying to build a universal APPLE gcc on a MacOS PPC system, because I want to tweak it to add a couple extra features. The build fails as already described here: http://www.cocoabuilder.com/archive/message/cocoa/2005/6/24/139961 The problem seems to be around line 1626 of gcc/configure.ac in both Apple and FSF versions where the following appears: if test x$host != x$target then CROSS="-DCROSS_COMPILE" ALL=all.cross SYSTEM_HEADER_DIR='$(CROSS_SYSTEM_HEADER_DIR)' case "$host","$target" in # Darwin crosses can use the host system's libraries and headers, # because of the fat library support. Of course, it must be the # same version of Darwin on both sides. Allow the user to # just say --target=foo-darwin without a version number to mean # "the version on this system". *-*-darwin*,*-*-darwin*) hostos=`echo $host | sed 's/.*-darwin/darwin/'` targetos=`echo $target | sed 's/.*-darwin/darwin/'` if test $hostos = $targetos -o $targetos = darwin ; then CROSS= SYSTEM_HEADER_DIR='$(NATIVE_SYSTEM_HEADER_DIR)' with_headers=yes fi ;; i?86-*-*,x86_64-*-* \ | powerpc*-*-*,powerpc64*-*-*) CROSS="$CROSS -DNATIVE_CROSS" ;; esac elif test "x$TARGET_SYSTEM_ROOT" != x; then As far as I can see, the assumption of the test is currently incorrect and the logic of the test is flawed. The assumption is incorrect because, MacOS PPC systems do not have i386 code in their system libraries, only ppc and ppc64. MacOS Intel system have three way fat libraries with i386, ppc and ppc64 code. The logic seems to me to be flawed first because it confuses the build os with the host os on which the compiler being built is expected to run. Secondly it ignores what comes after "darwin" in the host and target names. As luck would have it, an FSF build seems the invoke configure in gcc with host=ppc-apple-darwin8.6.0 and target=i386-apple-darwin8. The test if test $hostos = $targetos -o $targetos = darwin ; then fails and the build succeeds. In the Apple build host gets set to ppc-apple-darwin8. So the test succeeds and the build fails because of the missing i386 code in the system libraries. There is similar code in the configure script of libstdc++. None of this is a problem on MacOS X Intel. The cross-compilers build without problems on an Intel Mac. This has also been reported by someone trying to use the SDKs to build a cross compiler on Linux which targeted i386 Darwin, I am afraid I have lost the reference. Cheers Bill Northcott
Re: Darwin cross-compiler build failures on ppc MacOSX/Darwin
On 14/06/2006, at 5:15 AM, Mike Stump wrote: None of this is a problem on MacOS X Intel. The cross-compilers build without problems on an Intel Mac. Well, apparently one solution is to fatten your system. My attempts to do that just resulted in a system that would not boot :-( Fortunately, I tried it on a spare disk. The other might be to try: x86-*-darwin*,*-*-darwin*) instead, and then use --with-sysroot=/. I have done something like that already. Basically breaking the configure test and adding --with-sysroot= to the CONFIGFLAGS definition in build-gcc. This allowed the powerpc-i686 build to go through. [ this list is for people that want to roll up their sleeves and fix their own problem. If you want us to fix it for you, just file a PR. :-) ] I am trying. Currently the cross-hosted compiler build still breaks, which seems to be an issue with the SDK. The link breaks like this: /usr/bin/ld: warning fat file: /usr/lib/system/libmathCommon.A.dylib does not contain an architecture that matches the specified -arch flag: i386 (file ignored) /usr/bin/ld: warning multiple definitions of symbol _strncmp ../libiberty/libiberty.a(strncmp.o) definition of _strncmp in section (__TEXT,__text) /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libSystem.dylib(strncmp.So) definition of _strncmp /usr/bin/ld: Undefined symbols: _fegetround referenced from libSystem expected to be defined in /usr/ lib/system/libmathCommon.A.dylib collect2: ld returned 1 exit status make[2]: *** [makedepend] Error 1 make[1]: *** [all-libcpp] Error 2 + exit 1 This would seem to be because libSystem.B.dylib references the system's libmathCommon. billn% otool -L /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/ libSystem.B.dylib /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libSystem.B.dylib: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.3) /usr/lib/system/libmathCommon.A.dylib (compatibility version 1.0.0, current version 210.0.0) This cannot be changed with install_name_tool because libSystem.B.dylib is a stub library. Any suggestions? Does the -isysroot compiler flag fix this sort of issue? It does not seem to be used in the gcc build. Bill
Re: Darwin cross-compiler build failures on ppc MacOSX/Darwin
On 14/06/2006, at 10:47 AM, Mike Stump wrote: Any suggestions? Does the -isysroot compiler flag fix this sort of issue? It does not seem to be used in the gcc build. I'd expect it might. Run with -v and see if isysroot is given to ld. If not, add -Wl,-isysroot=... to pass it down to ld. In later compilers, we do this automagically, given -isysroot. I have written this up on the problem report. -isysroot causes -isyslibroot to be given to ld. So you cannot add - Wl,-isyslibroot or the links fail with 'syslibroot multiply defined' The problem is that CFLAGS are not passed into the build of libgcc. So unless -DCROSS_COMPILE is in the option list for the compiles within libgcc --with-sysroot (TARGET_SYSTEM_ROOT) is ignored and libgcc link fails because there is no code in the linked libSystem library for the target architecture. So the configure script is the basic cause of the problem, because it assumes the system libraries are fat when they are not. I can't see how it hurts to test for fat libraries instead of assuming their presence. Bill
Re: Wrong link?
Gerald: Gerald Pfeifer wrote: On Wed, 24 May 2006, Bill Gatliff wrote: Indeed, "bitrotted" is in fact a better description of what is happening. I have tweaked the ChangeLog entry to say "gone", which is even more neutral, and will do the same on the 4.1 branch shortly. Gerald Thanks! b.g. -- Bill Gatliff [EMAIL PROTECTED]
Bootstrap of gcc-3.4.3 on Tru64 5.1B PR16787
I have now tested the -ieee flag. So this is a documentation error, because the vital option is not mentioned in the host specific note. I have added a suggested documentation change to PR16787. It would be good if someone could fix the documentation. Bill Northcott On 10/02/2005, at 12:56 PM, Andrew Pinski wrote: It is more likely to be fixed if a bug report is filed. Or you could try submitting a formal patch to the gcc-patches list, but this is much more work, and requires follow up. There is already a bug report, PR 16787. But the way to compile on Tru64 is to use -ieee so that we get IEEE floating points with NANs.
Re: Question on Gimple canonicalization
On Fri, 2013-04-12 at 15:51 +0100, Sofiane Naci wrote: > Hi, > > Consider the following sequence, which computes 2 addresses to access an > array: > > _2 = (long unsigned int) i_1(D); > _3 = _2 * 200; > _4 = _3 + 1000; > _6 = A2_5(D) + _4; > *_6[0] = 1; > _9 = _3 + 2000; > _10 = A2_5(D) + _9; > _11 = _2 * 4; > _13 = A1_12(D) + _11; > _14 = *_13; > *_10[0] = _14; > > > There is an opportunity for optimization here that the compiler misses, > probably due to the order of Gimple statements. If we rewrite > > _3 = _2 * 200; > _4 = _3 + 1000; > _6 = A2_5(D) + _4; > ... > _9 = _3 + 2000; > _10 = A2_5(D) + _9; > > as > > _3 = _2 * 200; > _4 = _3 + A2_5(D); > _6 = 1000 + _4; > ... > _9 = _3 + A2_5(D); > _10 = 1000 + _9; > > We can clearly omit instruction _9. > > As the widening multiply pass has been improved to consider constant > operands [1], this opportunity for optimization is lost as the widening > multiply pass converts the sequence into: > > _3 = i_1(D) w* 200; > _4 = WIDEN_MULT_PLUS_EXPR ; > _6 = A2_5(D) + _4; > ... > _9 = WIDEN_MULT_PLUS_EXPR ; > _10 = A2_5(D) + _9; > > > With this particular example, this causes a Dhrystone regression at the > AArch64 back end. > > Where in the front end could such an optimization take place? > > Bill, is this something that your Strength Reduction work [2] could be > addressing? Hm, no, this isn't really a strength reduction issue. You're not wanting to remove an unwanted multiply. This is more of a reassociation/value numbering concern. Essentially you have: = A2 + ((i * 200) + 1000) = A2 + ((i * 200) + 2000) which you'd like to reassociate into = (A2 + (i * 200)) + 1000 = (A2 + (i * 200)) + 2000 so the parenthesized expression can be seen as available by value numbering: T = A2 + (i * 200) = T + 1000 = T + 2000 But reassociation just looks at a single expression tree and doesn't know about the potential optimization. I'm not sure this fits well into any of the existing passes, but others will have more authoritative answers than me... Bill > > Thanks > Sofiane > > - > > [1] http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01751.html > [2] > http://gcc.gnu.org/wiki/cauldron2012?action=AttachFile&do=get&target=wschmid > t.pdf > > > > >
Re: Question on Gimple canonicalization
On Fri, 2013-04-12 at 11:18 -0500, Bill Schmidt wrote: > On Fri, 2013-04-12 at 15:51 +0100, Sofiane Naci wrote: > > Hi, > > > > Consider the following sequence, which computes 2 addresses to access an > > array: > > > > _2 = (long unsigned int) i_1(D); > > _3 = _2 * 200; > > _4 = _3 + 1000; > > _6 = A2_5(D) + _4; > > *_6[0] = 1; > > _9 = _3 + 2000; > > _10 = A2_5(D) + _9; > > _11 = _2 * 4; > > _13 = A1_12(D) + _11; > > _14 = *_13; > > *_10[0] = _14; > > > > > > There is an opportunity for optimization here that the compiler misses, > > probably due to the order of Gimple statements. If we rewrite > > > > _3 = _2 * 200; > > _4 = _3 + 1000; > > _6 = A2_5(D) + _4; > > ... > > _9 = _3 + 2000; > > _10 = A2_5(D) + _9; > > > > as > > > > _3 = _2 * 200; > > _4 = _3 + A2_5(D); > > _6 = 1000 + _4; > > ... > > _9 = _3 + A2_5(D); > > _10 = 1000 + _9; > > > > We can clearly omit instruction _9. > > > > As the widening multiply pass has been improved to consider constant > > operands [1], this opportunity for optimization is lost as the widening > > multiply pass converts the sequence into: > > > > _3 = i_1(D) w* 200; > > _4 = WIDEN_MULT_PLUS_EXPR ; > > _6 = A2_5(D) + _4; > > ... > > _9 = WIDEN_MULT_PLUS_EXPR ; > > _10 = A2_5(D) + _9; > > > > > > With this particular example, this causes a Dhrystone regression at the > > AArch64 back end. > > > > Where in the front end could such an optimization take place? > > > > Bill, is this something that your Strength Reduction work [2] could be > > addressing? > > Hm, no, this isn't really a strength reduction issue. You're not > wanting to remove an unwanted multiply. This is more of a > reassociation/value numbering concern. Essentially you have: > > = A2 + ((i * 200) + 1000) > = A2 + ((i * 200) + 2000) > > which you'd like to reassociate into > > = (A2 + (i * 200)) + 1000 > = (A2 + (i * 200)) + 2000 > > so the parenthesized expression can be seen as available by value > numbering: > > T = A2 + (i * 200) > = T + 1000 > = T + 2000 > > But reassociation just looks at a single expression tree and doesn't > know about the potential optimization. I'm not sure this fits well into > any of the existing passes, but others will have more authoritative > answers than me... All this said, it's not completely foreign to how the strength reduction pass is structured. The problem is that strength reduction looks for candidates of very restricted patterns, which keeps compile time down and avoids deep searching: (a * x) + b or a * (x + b). Your particular case adds only one more addend, but the number of ways that can be reassociated immediately adds a fair amount of complexity. If your example is extended to a two-dimensional array case, it becomes more complex still. So the methods used by strength reduction don't scale well to these more general problems. I imagine the existing canonical form for address calculations is good for some things, but not for others. Hopefully someone with more history in that area can suggest something. > > Bill > > > > > Thanks > > Sofiane > > > > - > > > > [1] http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01751.html > > [2] > > http://gcc.gnu.org/wiki/cauldron2012?action=AttachFile&do=get&target=wschmid > > t.pdf > > > > > > > > > >
History question: Thread-safe profiling instrumentation
Six years ago, Michael Matz proposed a patch for generating profile instrumentation in a thread-safe manner: http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00950.html Reading through the thread, I saw a few minor objections, but nothing to indicate the patch should be withdrawn. However, apparently the changes were never made. I'm curious about the history here. What was the reason for abandoning this? Was a better alternative found? Were all the counters made thread-local? My reason for asking involves a large heavily-threaded application that is improved by feedback-directed optimization on some platforms, but not on others. One theory is that a defective profile is generated due to counter dropouts from contention. I'm somewhat skeptical about this given that some platforms seem to do well with it, but it's possible. I'm hopeful that knowing why the thread-safe profiling patch wasn't implemented will give us more of a clue. Thanks for any help! Bill
Re: History question: Thread-safe profiling instrumentation
On Mon, 2013-04-22 at 13:13 -0700, Xinliang David Li wrote: > There is a similar patch (in google branches) from Rong Xu which > enables atomic profile counter update. > > http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00072.html Thanks, David! We'll take a look. > > On Mon, Apr 22, 2013 at 12:59 PM, Bill Schmidt > wrote: > > Six years ago, Michael Matz proposed a patch for generating profile > > instrumentation in a thread-safe manner: > > > > http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00950.html > > > > Reading through the thread, I saw a few minor objections, but nothing to > > indicate the patch should be withdrawn. However, apparently the changes > > were never made. > > > > I'm curious about the history here. What was the reason for abandoning > > this? Was a better alternative found? Were all the counters made > > thread-local? > > > > My reason for asking involves a large heavily-threaded application that > > is improved by feedback-directed optimization on some platforms, but not > > on others. One theory is that a defective profile is generated due to > > counter dropouts from contention. I'm somewhat skeptical about this > > given that some platforms seem to do well with it, but it's possible. > > Do you see lots of messages about insane profile data (under > -fprofile-correction)? Most of the such messages we see (in our large > multi-threaded applications) show only marginal errors. > We're still waiting on that data. We don't have direct access to the application so we're having to work at some remove. When we asked for it the first time, the build logs had unfortunately been purged. > > > I'm hopeful that knowing why the thread-safe profiling patch wasn't > > implemented will give us more of a clue. > > You can try out Rong's patch. He plan to submit it to trunk soon. Much obliged! Bill > > thanks, > > David > > > > > Thanks for any help! > > > > Bill > > >
Re: [RFC] vector subscripts/BIT_FIELD_REF in Big Endian.
On Mon, 2013-08-05 at 11:47 +0100, Tejas Belagod wrote:
> Hi,
>
> I'm looking for some help understanding how BIT_FIELD_REFs work with
> big-endian.
>
> Vector subscripts in this example:
>
> #define vector __attribute__((vector_size(sizeof(int)*4) ))
>
> typedef int vec vector;
>
> int foo(vec a)
> {
>return a[0];
> }
>
> gets lowered into array accesses by c-typeck.c
>
> ;; Function foo (null)
> {
>return *(int *) &a;
> }
>
> and gets gimplified into BIT_FIELD_REFs a bit later.
>
> foo (vec a)
> {
>int _2;
>
>:
>_2 = BIT_FIELD_REF ;
>return _2;
>
> }
>
> What's interesting to me here is the bitpos - does this not need
> BYTES_BIG_ENDIAN correction? This seems to be inconsistenct with what happens
> with reduction operations in the autovectorizer where the scalar result in
> the
> reduction epilogue gets extracted with a BIT_FIELD_REF but the bitpos there
> is
> corrected for BIG_ENDIAN.
a[0] is at the left end of the array in BIG_ENDIAN, and big-endian
machines number bits from the left, so bit position 0 is correct.
>
> ... from tree-vect-loop.c:vect_create_epilog_for_reduction ()
>
>/* 2.4 Extract the final scalar result. Create:
>s_out3 = extract_field */
>
>if (extract_scalar_result)
> {
>tree rhs;
>
>if (dump_enabled_p ())
> dump_printf_loc (MSG_NOTE, vect_location,
>"extract scalar result");
>
>if (BYTES_BIG_ENDIAN)
> bitpos = size_binop (MULT_EXPR,
> bitsize_int (TYPE_VECTOR_SUBPARTS (vectype) -
> 1),
> TYPE_SIZE (scalar_type));
>else
> bitpos = bitsize_zero_node;
>
>
> For eg:
>
> int foo(int * a)
> {
>int i, sum = 0;
>
>for (i=0;i<16;i++)
> sum += a[i];
>
>return sum;
> }
>
> gets autovectorized into:
>
> ...
>vect_sum_9.17_74 = [reduc_plus_expr] vect_sum_9.15_73;
>stmp_sum_9.16_75 = BIT_FIELD_REF ;
>sum_76 = stmp_sum_9.16_75 + sum_47;
>
> the BIT_FIELD_REF here seems to have been corrected for BYTES_BIG_ENDIAN
Yes, because something else is going on here. This is a reduction
operation where the sum ends up in the rightmost element of a vector
register that contains four 32-bit integers. This is at position 96
from the left end of the register according to big-endian numbering.
>
> If vec_extract is defined in the back-end, how does one figure out if the
> BIT_FIELD_REF is a product of the gimplifier's indirect ref folding or the
> vectorizer's bit-field extraction and apply the appropriate correction in
> vec_extract's expansion? Or am I missing something that corrects
> BIT_FIELD_REFs
> between the gimplifier and the RTL expander?
There is no inconsistency here.
Hope this helps!
Bill
>
> Thanks,
> Tejas.
>
Re: [RFC] vector subscripts/BIT_FIELD_REF in Big Endian.
On Mon, 2013-08-12 at 11:54 +0100, Tejas Belagod wrote: > >> What's interesting to me here is the bitpos - does this not need > >> BYTES_BIG_ENDIAN correction? This seems to be inconsistenct with what > >> happens > >> with reduction operations in the autovectorizer where the scalar result in > >> the > >> reduction epilogue gets extracted with a BIT_FIELD_REF but the bitpos > >> there is > >> corrected for BIG_ENDIAN. > > > > a[0] is at the left end of the array in BIG_ENDIAN, and big-endian > > machines number bits from the left, so bit position 0 is correct. > > > >> > >> ... > >>vect_sum_9.17_74 = [reduc_plus_expr] vect_sum_9.15_73; > >>stmp_sum_9.16_75 = BIT_FIELD_REF ; > >>sum_76 = stmp_sum_9.16_75 + sum_47; > >> > >> the BIT_FIELD_REF here seems to have been corrected for BYTES_BIG_ENDIAN > > > > Yes, because something else is going on here. This is a reduction > > operation where the sum ends up in the rightmost element of a vector > > register that contains four 32-bit integers. This is at position 96 > > from the left end of the register according to big-endian numbering. > > > > Thanks for your reply. > > Sorry, I'm still a bit confused here. The reduc_splus_ documentation says > > "Compute the sum of the signed elements of a vector. The vector is operand 1, > and the scalar result is stored in the least significant bits of operand 0 > (also a vector)." > > Shouldn't this mean the scalar result should be in bitpos 0 which is the left > end of the register in BIG ENDIAN? No. The least significant bits of any register are the rightmost bits, and big-endian numbering begins at the left. (I don't really like the commentary, since "least significant bits" isn't a very good term to use with vectors.) Analogously, a 64-bit integer is numbered with 0 on the left being the most significant bit, and 63 on the right being the least significant bit. Thanks, Bill > > Thanks, > Tejas > > >> If vec_extract is defined in the back-end, how does one figure out if the > >> BIT_FIELD_REF is a product of the gimplifier's indirect ref folding or the > >> vectorizer's bit-field extraction and apply the appropriate correction in > >> vec_extract's expansion? Or am I missing something that corrects > >> BIT_FIELD_REFs > >> between the gimplifier and the RTL expander? > > > > There is no inconsistency here. > > > > Hope this helps! > > Bill > > > >> Thanks, > >> Tejas. > >> > > > > > >
Generating minimum libstdc++ symbols for a new platform
Hi, It was recently pointed out to me that our new powerpc64le-linux-gnu target does not yet have a corresponding directory in libstdc ++-v3/config/abi/post/ to hold a baseline_symbols.txt for the platform. I've been looking around and haven't found any documentation for how the minimum baseline symbols file should be generated. Can someone please enlighten me about the process? Thanks, Bill
Re: [lto] What is lto_file_vtable for?
On Wed, Jun 11, 2008 at 4:38 PM, Ollie Wild <[EMAIL PROTECTED]> wrote: > From what I can tell from grepping the lto source, the vtable entry in > lto_file is set but never used. Is this old code that never got > removed or the beginning of an idea that never got implemented? > > I'm inclined to remove it if it's not doing anything. It was needed when the LTO reader had to map DWARF2 sections. It is obsolete now. --Bill
Re: [lto] C++. streaming, front-end specific tree nodes, IR types, and assembler names
On Fri, Aug 1, 2008 at 7:53 AM, Mark Mitchell <[EMAIL PROTECTED]> wrote: > That's going to make -flto slow. If we do it in a way that affects normal > -O0 compilation, this would be a bad thing. Maybe we should consider a > strategy where the front-end data structures live until the point of LTO > output, so that we can compute what we need at that point, based only on > what we are going to output. (And for DECL_COMDAT things, we should be > outputting LTO information only if actually referenced.) Before free_lang_specifics was added, I dropped some of the tree while streaming it out. The advantage of this is that it doesn't trash the FE-specfic info for the currently-running compilation, so that debug info should be good for object code emitted during a -flto compile and linked normally. To move toward a language-independent IR, however, it is good hygiene to strip this stuff so we aren't fooling ourselves. When the lto IR is streamed back in, lto1 will pick up the compilation more or less at the point where it stood when the IR was written out, and proactively cleaning the tree in free_lang_specifics will help us to anticipate problems further along in the pipeline that might presently be masked in our testing of lto1 by other streamer failures. I agree that doing early name mangling at streamout time, only for the declarations that are actually referenced and must be streamed out, could be a huge win in the presence of large but sparsely-used header files. I will try a few experiments here. I'm not terribly comfortable with aggressively cleaning the tree in free_lang_specifics until we've clarified a GIMPLE type system and a plan for adjusting early-generated debug info to reflect middle-end optimization. --Bill
Re: GCC 4.2.0 Status Report (2007-05-11)
On May 11, 2007, at 3:02 PM, Mark Mitchell wrote: Every time I think we're almost there with this release, I seem to manage to get stuck. :-( However, we're very close: the only PRs that I'm waiting for are: PR 30252: Wrong code generation, perhaps due to the C++ front end's representation for base classes. Jason, are you actively investigating this one? PR 31797: An infinite loop in the compiler while building RTEMS. Daniel, I see you've been commenting on this; are you working on the fix? If so, do you have an ETA? Please let me know the status of these soon. If we can't fix 'em, I'll just proceed with what we've got. Hi Mark, This one was just filed against 4.2.0: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31903 It is causing LLVM (at least) to fail to build. Do you think it's worth adding to the list? -bw
Re: GCC 4.2.0 Status Report (2007-05-11)
On May 11, 2007, at 5:15 PM, Mark Mitchell wrote: Bill Wendling wrote: This one was just filed against 4.2.0: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31903 It is causing LLVM (at least) to fail to build. Do you think it's worth adding to the list? Does it show up anywhere other than Darwin? On the basis of Darwin alone, I would not further hold up the release. That is not to say that I would not consider a patch to fix it, of course. Andrew Pinski wasn't able to reproduce the link error on Linux, and I've only seen it on Darwin. However, as Chris Lattner pointed out, this indicates a fairly serious problem (which shows up even on the Linux build) in that the symbols aren't getting internal linkage (they're in an anonymous namespace, so should). It could impact performance on large systems quite a bit. Certainly during linking. -bw
Re: GCC 4.2.0 Status Report (2007-05-11)
On May 12, 2007, at 6:32 AM, Andrew Pinski wrote: On 5/11/07, Bill Wendling <[EMAIL PROTECTED]> wrote: This one was just filed against 4.2.0: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31903 It is causing LLVM (at least) to fail to build. Do you think it's worth adding to the list? You know the regression is not on the 4.2 branch and only the trunk. I think Geoff applied the patch which caused the regression to your local 4.2 tree. So this is NOT a blocker for 4.2, only 4.3 when get around to fixing those regressions. Okay. Thanks, for checking on this! :-) -bw
Re: Code Samples
I'm sure there are some at your school's website. Or you can ask you TA for help with your homework. -bw On May 15, 2007, at 11:33 AM, craig clow wrote: Hello, Does anyone know of a good web site for sample C code supported by GCC 3.3.2? Specifically, I am looking for code that can read files from a directory and do I/O. thanks, Craig _ PC Magazines 2007 editors choice for best Web mailaward-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507
Re: RFC: Make dllimport/dllexport imply default visibility
On Jun 15, 2007, at 12:48 AM, Mark Mitchell wrote:
Consider:
struct __attribute__((vsibility ("hidden"))) S {
void __declspec(dllimport) f();
};
At present, we give "f" hidden visibility. That seems odd since the
user has explicitly told us that the symbol is coming from another
shared library.
I'm planning to make any dllimport or dllexport attribute imply
default
visibility. Is that a bad idea?
Perhaps I'm mistaken, but the above seems to indicate to me that the
structure (and, therefore, all of its fields) are hidden, one of its
functions is from an external and visible source. Because nothing
outside of the translation unit that has S can access f directly (only
through a function pointer), I don't see a problem with marking it as
a hidden part of S. That is, as long as it doesn't affect the original
f()'s visibility.
I'll ask the opposite question: what would be gained by giving this
default visibility?
-bw
Re: RFC: Make dllimport/dllexport imply default visibility
On Jun 15, 2007, at 3:45 PM, Mark Mitchell wrote:
Bill Wendling wrote:
Perhaps I'm mistaken, but the above seems to indicate to me that the
structure (and, therefore, all of its fields) are hidden, one of its
functions is from an external and visible source.
Yes. And, therefore, emitting a undefined reference to S::f with
hidden
linkage in the current translation unit causes S::f to have hidden
visibility in the shared object containing this translation unit. For
example, if the translation unit goes on to say:
void g() {
S s;
s.f();
}
we will now have an undefined reference to S::f with hidden
visibility.
As a result, S::f will have hidden visibility in the shared object
containing this translation unit. Thus, despite dllimport, the user
cannot actually import a function of a hidden class from another DLL.
That seems bad.
Okay. What I mentioned was based on the docs for 4.0.1 where it says:
"On Microsoft Windows and Symbian OS targets, the dllimport attribute
causes the compiler to reference a function or variable via a global
pointer to a pointer that is set up by the DLL exporting the symbol."
So my thoughts were, "because a hidden structure could still have a
pointer which points to global data, then this should be okay." But
the scenario you described is clearly bad.
-bw
gcc on SCO
Hello, Don't ask me why I did this but. I would like to report that the version of gcc 2.95, available at ftp://ftp2.sco.com/pub/skunkware/osr5/devtools/gcc/ designed for SCO osr5 will install on SCO osr6 and it works to the extent I have tested it. I compiled and installed joe source with the standard ./configure make make install The compiler should be downloaded and unpacked. Then the VOL files are accessed through the maintenance utility thus: scoadmin software etc. etc. etc The thought now occurs to me. Would there be any interest in a SCO binary of the latest gcc compiler? Could the 2.95 compiler make a 4.2 compiler? I am not a programmer but would be willing to give it a shot. Regards... Bill -- William C. House, CPA House & Albright, P.C. Huntsville, Alabama 1-256-539-8002 1-256-536-7236 fax
GCC 4.7.2 error handling type short
d\n", sizeof(unsigned short)); dumphex(1024, 256); } When run, I get this result: MAKIMG Intel Xenix Version 6.0 starting... fs_fsize = 354 fs_cgblocks = 358 fs_maxblock = 3145728 fs_cginodes = 48 fs_maxino = 36234 len = 2 000400 00 00 00 00 00 00 00 00 00 00 00 00 62 01 00 00 b... 000410 66 01 67 01 00 00 30 00 30 00 8A 8D E6 1B 00 00 f.g...0.0... 000420 6A 00 40 00 00 02 10 00 00 00 19 00 07 00 08 01 j.@. 000430 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000440 00 00 02 00 00 00 10 00 19 00 07 00 00 00 00 00 000450 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000460 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000470 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000490 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0004A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0004B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0004C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0004D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0004E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0004F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 As you can see the value at 0410 in the file, 6601 is returned as 358, which is correct. The 4-byte value following 67 01 00 00 is not returned for the unsigned int but rather 00 00 30 00 is returned next (which equals 3145728 decimal). While a sizeof(unsigned short) returns 2 bytes, in this case the pointer into the unioned buffer is moved 4 bytes. This bug makes it hell to you any of your products to build emulators for the 16-bit processors. Is there a definition for a 16-bit quantity that will work in a union? Thanks! Bill Beech NJ7P
Re: documentation of powerpc64{,le}-linux-gnu as primary platform
On 7/9/20 12:13 PM, Richard Biener via Gcc wrote:
On July 9, 2020 3:43:19 PM GMT+02:00, David Edelsohn via Gcc
wrote:
On Thu, Jul 9, 2020 at 9:07 AM Matthias Klose wrote:
On 7/9/20 1:58 PM, David Edelsohn via Gcc wrote:
On Thu, Jul 9, 2020 at 7:03 AM Matthias Klose
wrote:
https://gcc.gnu.org/gcc-8/criteria.html lists the little endian
platform first
as a primary target, however it's not mentioned for GCC 9 and GCC
10. Just an
omission?
https://gcc.gnu.org/legacy-ml/gcc-patches/2018-07/msg00854.html
suggests that
the little endian platform should be mentioned, and maybe the big
endian
platform should be dropped?
Jakub suggested to fix that for GCC 9 and GCC 10, and get a
consensus for GCC 11.
Why are you so insistent to drop big endian? No. Please leave
this alone.
No, I don't leave this alone. The little endian target is dropped in
GCC 9 and
GCC 10. Is this really what you intended to do?
No, it's not dropped. Some people are being pedantic about the name,
which is why Bill added {,le}. powerpc64-unknown-linux-gnu means
everything. If you want to add {,le} back, that's fine. But there
always is some variant omitted, and that doesn't mean it is ignored.
The more that one over-specifies and enumerates some variants, the
more that it implies the other variants intentionally are ignored.
I would appreciate that we would separate the discussion about
explicit reference to {,le} from the discussion about dropping the big
endian platform.
I think for primary platforms it is important to be as specific as possible
since certain regressions are supposed to block a release. That's less of an
issue for secondary platforms but it's still a valid concern there as well for
build issues.
Sorry, I've been on vacation and am a little late to this discussion. I
obviously agree with specifying both, since I did that for GCC 8 (and
assumed it would be propagated forward). I had forgotten I did this
when I subsequently noticed for GCC 9 that it was only
powerpc64-unknown-linux-gnu. I brought it up then and, IIRC, was told
by the maintainers that "LE is implied as well, don't worry about it."
It looks like thoughts on this have changed, so certainly I would agree
with putting "{,le}" back at this time.
I agree with David that BE isn't going anywhere anytime soon, so
anything that implies it should be a secondary platform is wrong. We
continue to support it and test it.
Matthias, if you want to post a patch for GCC 9 and GCC 10, I'm sure
that would be accepted (though I do not have the power to pre-approve
it). Or I can put it on my list for later in the summer when my life
settles down. Your choice.
Bill
Richard.
Thanks, David
Re: documentation of powerpc64{,le}-linux-gnu as primary platform
On 7/13/20 7:08 AM, Florian Weimer wrote: * Bill Schmidt via Gcc: Matthias, if you want to post a patch for GCC 9 and GCC 10, I'm sure that would be accepted (though I do not have the power to pre-approve it). Or I can put it on my list for later in the summer when my life settles down. Your choice. I posted a patch: <https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549947.html> Thanks, Florian! Bill Thanks, Florian
Re: 10-12% performance decrease in benchmark going from GCC8 to GCC9
On 8/10/20 3:30 AM, Jonathan Wakely via Gcc wrote: Hi Matt, The best thing to do here is file a bug report with the code to reproduce it: https://gcc.gnu.org/bugzill Thanks Also, be sure to follow the instructions at https://gcc.gnu.org/bugs/. Bill On Sat, 8 Aug 2020 at 23:01, Soul Studios wrote: Hi all, recently have been working on a new version of the plf::colony container (plflib.org) and found GCC9 was giving 10-12% worse performance on a given benchmark than GCC8. Previous versions of the colony container did not experience this performance loss going from GCC8 to GCC9. However Clang 6 and MSVC2019 show no performance loss going from the old colony version to the new version. The effect is repeatable across architectures - I've tested on xubuntu, windows running nuwen mingw, and on Core2 and Haswell CPUs, with and without -march=native specified. Compiler flags are: -O2;-march=native;-std=c++17 Code is attached with an absolute minimum use-case - other benchmarks have not shown such strong performance differences - including both simpler and more complex tests. So I cannot reduce further, please do not ask me to do so. The benchmark in question inserts into a container initially then iterates over container elements repeatedly, randomly erasing and/or inserting new elements. In addition I've attached the assembly output under both GCC8 and GCC9. In this case I have output from 8.2 and 9.2 respectively, but the same effects apply to 8.4 and 9.3. The output for 8 is a lot larger than 9, wondering if there's more unrolling occurring. Any questions let me know. I will help where I can, but my knowledge of assembly is limited. If supplying the older version of colony is useful I'm happy to do so. Nanotimer is a ~nanosecond-precision sub-timeslice cross-platform timer. Colony is a bucket-array-like unordered sequence container. Thanks, Matt
Installing a generated header file
Hi! I'm working on a project where it's desirable to generate a target-specific header file while building GCC, and install it with the rest of the target-specific headers (i.e., in lib/gcc//11.0.0/include). Today it appears that only those headers listed in "extra_headers" in config.gcc will be placed there, and those are assumed to be found in gcc/config/. In my case, the header file will end up in my build directory instead. Questions: * Has anyone tried something like this before? I didn't find anything. * If so, can you please point me to an example? * Otherwise, I'd be interested in advice about providing new infrastructure to support this. I'm a relative noob with respect to the configury code, and I'm sure my initial instincts will be wrong. :) Thanks for any help! Bill
Re: Installing a generated header file
Thanks for the pointer! I'll have a look at this.
Much obliged,
Bill
On 11/12/20 9:54 AM, Jonathan Wakely wrote:
On Thu, 12 Nov 2020 at 15:39, Bill Schmidt via Gcc wrote:
Hi! I'm working on a project where it's desirable to generate a
target-specific header
file while building GCC, and install it with the rest of the target-specific
headers
(i.e., in lib/gcc//11.0.0/include). Today it appears that only those
headers
listed in "extra_headers" in config.gcc will be placed there, and those are
assumed to
be found in gcc/config/. In my case, the header file will end up in my
build
directory instead.
Questions:
* Has anyone tried something like this before? I didn't find anything.
* If so, can you please point me to an example?
* Otherwise, I'd be interested in advice about providing new infrastructure to
support
this. I'm a relative noob with respect to the configury code, and I'm sure
my
initial instincts will be wrong. :)
I don't know how relevant it is to your requirement, but libstdc++
creates a target-specific $target/bits/c++config.h header for each
multilib target, but it installs them alongside the rest of the C++
library headers, not in lib/gcc//.
It's done with a bunch of shell commands that takes the
autoconf-generated config.h file, combines it with a template file
that's in the source repo (libstdc++-v3/include/bits/c++config) and
then modifies it with sed. See the ${host_builddir}/c++config.h target
in libstdc++-v3/include/Makefile.am for the gory details. The other
make targets below it (for gthr-single.h and gthr-posix.h) are also
target-specific.
Those headers are listed in the ${allcreated} variable which is a
prerequisite of the all-local target, and then in the install target
they get copied into place.
