Re: Getting spurious FAILS in testsuite?
On 06/01/2017 05:59 AM, Georg-Johann Lay wrote: Hi, when I am running the gcc testsuite in $builddir/gcc then $ make check-gcc RUNTESTFLAGS='ubsan.exp' comes up with spurious fails. This was discussed before, and the suspicion was that it was a linux kernel bug. There were multiple kernel fixes pointed at, it wasn't clear which one was required to fix it. I have Ubuntu 16.04 LTS on my laptop, and I see the problem. I can't run the ubsan testsuites with -j factor greater than one and get reproducible results. There may also be other ways to trigger the problem. See for instance the thread https://gcc.gnu.org/ml/gcc/2016-07/msg00117.html The first message in the thread from Andrew Pinski mentions that the log output is corrupted from apparent buffer overflow. Jim
xz instead of bzip2
Dear GCC developers, What happens here ! "Weekly snapshots now use xz compression [2017-05-24] ...instead of bzip2." Are you aware that a better implementation / format exists for this purposes?: http://lzip.nongnu.org/ Review of xz: http://lzip.nongnu.org/xz_inadequate.html Please do the right thing.. pgpZ5F7IIxkox.pgp Description: OpenPGP digital signature
Re: xz instead of bzip2
On Jun 05 2017, Matias Fonzo wrote: > Dear GCC developers, > > What happens here ! > > "Weekly snapshots now use xz compression [2017-05-24] > ...instead of bzip2." > > Are you aware that a better implementation / format exists for this > purposes?: > > http://lzip.nongnu.org/ > > Review of xz: > > http://lzip.nongnu.org/xz_inadequate.html > > > Please do the right thing.. http://lists.gnu.org/archive/html/coreutils/2017-01/msg9.html Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: xz instead of bzip2
On Mon, 05 Jun 2017 20:24:50 +0200 Andreas Schwab wrote: > On Jun 05 2017, Matias Fonzo wrote: > > > Dear GCC developers, > > > > What happens here ! > > > > "Weekly snapshots now use xz compression [2017-05-24] > > ...instead of bzip2." > > > > Are you aware that a better implementation / format exists for this > > purposes?: > > > > http://lzip.nongnu.org/ > > > > Review of xz: > > > > http://lzip.nongnu.org/xz_inadequate.html > > > > > > Please do the right thing.. > > http://lists.gnu.org/archive/html/coreutils/2017-01/msg9.html > > Andreas. > I respect Jim Meyering for his career in the GNU project. I do not like that he adopted xz as his toy, but this is a personal opinion (nothing against the person really). If someone can refute the arguments found in the article, I will change my mind about lzip and I will start supporting xz. pgpvydFskj6ru.pgp Description: OpenPGP digital signature
Re: xz instead of bzip2
Hello Andreas et all, Andreas Schwab wrote: http://lists.gnu.org/archive/html/coreutils/2017-01/msg9.html In the above link I read the following affirmation by Jim Meyering: "I found/find that xz is superior to lzip". But he does not back his affirmation with any evidence. Appeal to autority is obsolete since at least the Renaissance. Unless someone can refute the defects of xz, my opinion is that using xz is damaging to users. But if you are going to appeal to autority, at least appeal to the author of the thing, who said that "XZ Utils is already an over-engineered pig". http://www.mail-archive.com/xz-devel@tukaani.org/msg00076.html I just refuse to believe that some of the best developers in the world may think seriously about using a format that "protects" its padding bytes with a CRC32. http://www.nongnu.org/lzip/xz_inadequate.html#misguided Best regards, Antonio.
Re: Problem with "" vs <> headers and fixincludes
On 06/01/17 07:24, Douglas B Rupp wrote: > > This is a reproducer for a problem we have with fixincludes on > vxworks6.6. The desired output is > FOO= 1 > > The problem is the rules for handling headers enclosed in quotes can > cause gcc to #include the original header not the patched header. > > It seems like a problem that could theoretically occur on any target, so > what is the solution (other than copying each and every header into > include-fixed)? You have to have a include-fixed/h/foo.h header that has the line > #include "arch/x86.h" No way around that. fixincludes doesn't change the language.
libatomic IFUNC question (arm & libat_have_strexbhd)
I have a question about the use of IFUNCs in libatomic. I was looking at the
arm implementation and in gcc/libatomic/config/linux/arm/host-config.h I see:
extern bool libat_have_strexbhd HIDDEN;
# define IFUNC_COND_1 libat_have_strexbhd
I also see that gcc/libatomic/config/linux/arm/init.c has:
bool libat_have_strexbhd;
static void __attribute__((constructor))
init_cpu_revision (void)
{
}
What I don't see is any place that libat_have_strexbhd would ever get
set. What am I missing here? init_cpu_revision is going to get called
when libatomic is first loaded since it is a constructor but it doesn't
seem to do anything and it isn't going to set libat_have_strexbhd as far
as I can see.
Steve Ellcey
sell...@cavium.com
Fw: xz instead of bzip2
Begin forwarded message: Date: Mon, 5 Jun 2017 20:17:57 -0300 From: Matias Fonzo To: R0b0t1 Subject: Re: xz instead of bzip2 On Mon, 5 Jun 2017 15:44:25 -0500 R0b0t1 wrote: > On Mon, Jun 5, 2017 at 1:08 PM, Matias Fonzo > wrote: > > Dear GCC developers, > > > > What happens here ! > > > > "Weekly snapshots now use xz compression [2017-05-24] > > ...instead of bzip2." > > > > Are you aware that a better implementation / format exists for this > > purposes?: > > > > http://lzip.nongnu.org/ > > > > Review of xz: > > > > http://lzip.nongnu.org/xz_inadequate.html > > > > > > Please do the right thing.. > > > > Hello, > > That article is rather interesting but unfortunately it does not > compare and contrast. It only lists facts of XZ but does so mostly in > a vacuum, so I can't really tell whether or not those things are > actually bad without trusting the author. Typically I would have no > trouble doing this and would want to follow up on the author's claims, > but in this case (the article is associated with lzip) I'm more wary > of spending time doing that. > > My personal experience with the XZ format finds it better for > releases, as compression tends to take longer (but give a better > ratio) than decompression. Section 2.7 is kind of interesting in that > case, as it claims that LZMA2 has a lower compression ceiling than > LZMA. I don't know how far typical compression strays from the > ideal. http://lzip.nongnu.org/lzip_benchmark.html > 2.9 is fairly minor but I do agree with it. It and the later sections > lead me to my next point: most of the discussion seems to be on the > failure of XZ's format to provide proper error checking. However in > practice I have not found anyone to rely on the error checking > provided by compressed data formats, and have had it suggested that > doing so is an exercise in futility. That most software projects > provide digests of their source archives seems to agree with this. > Trying to provide error checking within the archive itself falls prey > to the two general's problem > (https://en.wikipedia.org/wiki/Two_Generals'_Problem) and based on the > LZip author's argument error checking should probably be removed from > both formats. > > While I'm not sure this should reflect on the author, I am not able to > understand his conclusion in 2.10, 2.10.3, and 2.10.4. It doesn't seem > to be explained how is he detecting false positives (the given > formulas describe what he is doing with the false positive rate after > it is found). Thus to me it seems entirely likely he might be > interpreting things backwards; CRC algorithms actually pass through a > large number of errors compared to digest algorithms, so figure 3 > makes no sense. Besides that I can't really find out how it is > relevant to the main argument. > > Mr. Fonzo, if you think this is worth the consideration of the GCC > developers, you might consider contacting the author of that web page > so that he is able to explain it. However that is still predicated on > one of the developers wanting to entertain a discussion. > > R0b0t1. pgp9L9b3zcMLi.pgp Description: OpenPGP digital signature
Re: Problem with "" vs <> headers and fixincludes
T-Bird snafu resend: On 06/05/17 14:52, Bruce Korb wrote: > On 06/01/17 07:24, Douglas B Rupp wrote: >> >> This is a reproducer for a problem we have with fixincludes on >> vxworks6.6. The desired output is >> FOO= 1 >> >> The problem is the rules for handling headers enclosed in quotes can >> cause gcc to #include the original header not the patched header. >> >> It seems like a problem that could theoretically occur on any target, so >> what is the solution (other than copying each and every header into >> include-fixed)? > You have to have a include-fixed/h/foo.h header that has the line > >> #include "arch/x86.h" > > No way around that. fixincludes doesn't change the language. >
Re: libatomic IFUNC question (arm & libat_have_strexbhd)
* Steve Ellcey:
> I have a question about the use of IFUNCs in libatomic. I was looking at the
> arm implementation and in gcc/libatomic/config/linux/arm/host-config.h I see:
>
> extern bool libat_have_strexbhd HIDDEN;
> # define IFUNC_COND_1 libat_have_strexbhd
>
> I also see that gcc/libatomic/config/linux/arm/init.c has:
>
> bool libat_have_strexbhd;
> static void __attribute__((constructor))
> init_cpu_revision (void)
> {
> }
>
> What I don't see is any place that libat_have_strexbhd would ever get
> set. What am I missing here? init_cpu_revision is going to get called
> when libatomic is first loaded since it is a constructor but it doesn't
> seem to do anything and it isn't going to set libat_have_strexbhd as far
> as I can see.
Setting the variable in the constructor wouldn't influence IFUNC
resolver behavior because those can run before ELF constructors
(even with lazy binding).
