search for: gcc7

If I compile libFLAC with GCC 7.1 I see many warnings like lpc.c: In function 'FLAC__lpc_compute_residual_from_qlp_coefficients': lpc.c:489:18: warning: this statement may fall through [-Wimplicit-fallthrough=] case 32: sum += qlp_coeff[31] * data[i-32]; ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ lpc.c:490:5: note: here case 31: sum += qlp_coeff[30] * data[i-31];

...si K?rkk?inen wrote: > Hi, > > On Mon, Mar 04, 2019 at 04:22:19PM -0500, Karl Johnson wrote: > > > > > > I updated my PR: [3]https://github.com/CentOS-virt7/xen-kernel/pull/18 > > > > Hi Karl, I've build and tested your PR, but without the GCC7 patch, and > > when I've tested it on el6, none of the guests had network access. > > I had to revert the bridge changes to have them working > > (CONFIG_BRIDGE_NETFILTER=m and CONFIG_BRIDGE=m). > > > > Why did you want the BRIDGE built-in inst...

...; } > > > > Still, what kind of corruption would move a genuine hbin to a > > non-page-sized offset in the file?  It seems unlikely to me ... > > > > Rich. > > > > None that I know of :-) However I don't see any other simple way to > silence that GCC7 warning and it seems harmless that way to me > (besides > the fact that the loop will have to make more iterations) So I've found a way to keep offsetting by 4k and keep GCC7 happy: while (off < h->endpages) { if (off + 0x1000 > off) off += 0x1000; else break; // of...

...; kernel upgrade. > > Kernel 4.9.161 doesn't have the patch for CVE-2019-8912 yet so we might > > wait until it get released. > > > > I updated my PR: https://github.com/CentOS-virt7/xen-kernel/pull/18 > > Hi Karl, I've build and tested your PR, but without the GCC7 patch, and > when I've tested it on el6, none of the guests had network access. > I had to revert the bridge changes to have them working > (CONFIG_BRIDGE_NETFILTER=m and CONFIG_BRIDGE=m). > > Why did you want the BRIDGE built-in instead of a module? > > Maybe you have some...

...on, Mar 04, 2019 at 04:22:19PM -0500, Karl Johnson wrote: > > > > > > > > > > I updated my PR: [3] > https://github.com/CentOS-virt7/xen-kernel/pull/18 > > > > > > > > Hi Karl, I've build and tested your PR, but without the GCC7 > patch, and > > > > when I've tested it on el6, none of the guests had network > access. > > > > I had to revert the bridge changes to have them working > > > > (CONFIG_BRIDGE_NETFILTER=m and CONFIG_BRIDGE=m). > > > > > &g...

On Wed, Feb 15, 2017 at 02:28:41PM -0500, Dawid Zamirski wrote: > Correct, however there's also no guarantee that seeking by 4k in > "garbage" data would not land you in registry data that happens to > evaluate to "hbin" as well. That's why I put "hbin" offset validation > check couple of lines below to make sure that the "hbin" we found

...nel on localversion option and adding Module.symver from /boot/symver-version.gz to module directory. Now I get another problem compiling the third party module (i2c-nct6775): "CONFIG_RETPOLINE=y but not supported by the compiler. Compiler update recomended. Stop." I tried using scl gcc7 and 8 but get the same issue. I checked that retpoline is related to Spectre but checking on centos with: cat /sys/devices/system/cpu/vulnerabilities/spectre_v2 I get: Mitigation: IBRS (kernel), IBPB and RETPOLINE seems disabled (I'm wrong?). I ridden in a blog post that I can disable thi...

...t kind of corruption would move a genuine hbin to a > > > non-page-sized offset in the file?  It seems unlikely to me ... > > > > > > Rich. > > > > > > > None that I know of :-) However I don't see any other simple way to > > silence that GCC7 warning and it seems harmless that way to me > > (besides > > the fact that the loop will have to make more iterations) > > So I've found a way to keep offsetting by 4k and keep GCC7 happy: > > while (off < h->endpages) { > if (off + 0x1000 > off) >...

...> > > > On Mon, Mar 04, 2019 at 04:22:19PM -0500, Karl Johnson wrote: > > > > > > > > I updated my PR: [3]https://github.com/CentOS-virt7/xen-kernel/pull/18 > > > > > > Hi Karl, I've build and tested your PR, but without the GCC7 patch, and > > > when I've tested it on el6, none of the guests had network access. > > > I had to revert the bridge changes to have them working > > > (CONFIG_BRIDGE_NETFILTER=m and CONFIG_BRIDGE=m). > > > > > > Why did you want...

...04:22:19PM -0500, Karl Johnson wrote: >> > > > > >> > > > > I updated my PR: [3] >> https://github.com/CentOS-virt7/xen-kernel/pull/18 >> > > > >> > > > Hi Karl, I've build and tested your PR, but without the GCC7 >> patch, and >> > > > when I've tested it on el6, none of the guests had network >> access. >> > > > I had to revert the bridge changes to have them working >> > > > (CONFIG_BRIDGE_NETFILTER=m and CONFIG_BRIDGE=m). >&gt...

.../boot/symver-version.gz to module directory. >> >> Now I get another problem compiling the third party module (i2c-nct6775): >> >> "CONFIG_RETPOLINE=y but not supported by the compiler. Compiler update >> recomended. Stop." >> >> I tried using scl gcc7 and 8 but get the same issue. >> >> I checked that retpoline is related to Spectre but checking on centos with: >> >> cat /sys/devices/system/cpu/vulnerabilities/spectre_v2 >> >> I get: >> >> Mitigation: IBRS (kernel), IBPB >> >> and RETPO...

...the caller might be looking at keys that are perfectly readable/writable (e.g. to identify Windows version from HKLM/Software/Microsoft/Windows NT/CurrentVersion) and other "corrupted" and irrelevant keys might prevent one from doing so. Changes in v3: * rebase on current master * fix GCC7 -Wunsafe-loop-optimizations warning by incrementing the "off" variable by 1 rather than 0x1000, the latter was assuming "garbage" data in between "hbins" would be aligned on 4096 bytes which does not have to be true and GCC7 is correct. Regards, Dawid Zamirs...

I use OpenSSH server on an embedded arm using GCC7 cross toolchain. I found that spamming connection attempts sometimes causes aborts in sshd. Upon getting this up in gdb I found that the pointer subtraction inside openbsd-compat/{strlcat.c,strlcpy.c} (and maybe elsewhere) causes the 32 bit pointer difference to wrap which triggers the abort becaus...

...> > loop. > > > > There are actually a few more of these in the existing code - I'm > > going to push a patch to fix these in a minute. > > > > Rich. > > > > I've just sent out v3 that fix this warning - it was a valid complaint > from GCC7 because off += 0x1000; in the loop body is not a good idea > anyway and it should have been off++; But surely headers can only ever be at 4K offsets from the start of the file? I wouldn't trust a random "hbin" somewhere in the middle since that might easily come from registry dat...

On Tue, Feb 14, 2017 at 12:05:20PM -0500, Dawid Zamirski wrote: > * hivex_open: when looping over hbin sections (aka pages), handle a > case where following hbin section may not begin at exactly at the end > of previous one. If this happens, scan the page section until next > one is found and validate it by checking declared offset with actual > one - if they match, all is

On Wed, Feb 27, 2019 at 4:44 AM Pasi K?rkk?inen <pasik at iki.fi> wrote: > Hi, > > On Mon, Feb 11, 2019 at 12:49:30PM +0200, Pasi K?rkk?inen wrote: > > Hi, > > > > On Sun, Feb 10, 2019 at 10:35:56PM -0500, Karl Johnson wrote: > > > Hello, > > > I built 4.9.155 for both el6 and el7, you can test them here: > > > [1] >

...test rebuild on at least amd64 with gcc-7/g++-7, but succeeds to build with gcc-6/g++-6. The severity of this report may be raised before the buster release. There is no need to fix this issue in time for the stretch release. The full build log can be found at: http://people.debian.org/~doko/logs/gcc7-20170126/xen_4.8.1~pre.2017.01.23-1_unstable_gcc7.log The last lines of the build log are at the end of this report. To build with GCC 7, either set CC=gcc-7 CXX=g++-7 explicitly, or install the gcc, g++, gfortran, ... packages from experimental. apt-get -t=experimental install g++ Common bui...

...s that GCC might try to turn this into an infinite > loop. > > There are actually a few more of these in the existing code - I'm > going to push a patch to fix these in a minute. > > Rich. > I've just sent out v3 that fix this warning - it was a valid complaint from GCC7 because off += 0x1000; in the loop body is not a good idea anyway and it should have been off++; Dawid

...!= off) {  > >   SET_ERRNO... > > } > > Still, what kind of corruption would move a genuine hbin to a > non-page-sized offset in the file?  It seems unlikely to me ... > > Rich. > None that I know of :-) However I don't see any other simple way to silence that GCC7 warning and it seems harmless that way to me (besides the fact that the loop will have to make more iterations)

On Wed, Feb 15, 2017 at 10:29:41PM +0000, Richard W.M. Jones wrote: > Yes, or even how about this (not tried it): > > while (off <= h->endpages - 0x1000) { > ... > } In fact this doesn't work either :-( I'll have another look at this tomorrow morning. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and