Re: [arch-general] about the removal of that systemd symlink...
2013/5/13 Karol Blazewicz karol.blazew...@gmail.com On Mon, May 13, 2013 at 7:32 AM, David Benfell benf...@parts-unknown.org wrote: Hi all, I was alarmed, I think unnecessarily, when I saw the message that a symlink for systemd was removed on an upgrade. As near as I can tell, the boot sequence still relies on init, which links to the right place. Is there a better way to keep track of changes like this so I'm not surprised? Thanks! Not reading pacman's output may lead to problems. Well, some people seldom read pacman's output. e.g. I use a cron job to use pacman to update the system, and I don't read the log very often. Why do you think it's a bad way? Maybe some people haven't installed systemd-sysvcompat and still use 'init=/bin/systemd' .
Re: [arch-general] about the removal of that systemd symlink...
Am 13.05.2013 10:18, schrieb Iru Cai: Well, some people seldom read pacman's output. e.g. I use a cron job to use pacman to update the system, and I don't read the log very often. That's your own fault then. Why do you think it's a bad way? Maybe some people haven't installed systemd-sysvcompat and still use 'init=/bin/systemd' . The wiki has told you to use init=/usr/lib/systemd/systemd for quite some time. signature.asc Description: OpenPGP digital signature
Re: [arch-general] about the removal of that systemd symlink...
On Sunday 12 May 2013 22:32:03 David Benfell wrote: Hi all, I was alarmed, I think unnecessarily, when I saw the message that a symlink for systemd was removed on an upgrade. As near as I can tell, the boot sequence still relies on init, which links to the right place. Is there a better way to keep track of changes like this so I'm not surprised? Thanks! -- David Benfell / benf...@parts-unknown.org Please see https://parts-unknown.org/node/2 for GnuPG information (or the attachment you don't understand) There was a post installation message.
Re: [arch-general] Linux 3.9.2-1-ARCH cures blank screen
On 05/13/13 08:15, Ralf Mardorf wrote: On Mon, 13 May 2013 00:53:17 +0200, Whiskers catwhee...@operamail.com wrote: The blank screen I first reported in January with Linux-3.7.3-1-i686 seems to have been cured by the latest update to Linux-3.9.2-1-i686 (and/or other updates that have happened at the same time). (Using the nouveau graphics driver). But the desktop and mouse settings in XFCe4 aren't all working. Are you sure that this is caused by the kernel and/or graphics driver? I'm a Xfce only user for a long time and experience it as a PITA. If I would know another DE, that would be similar near to the wanted work flow and that would be less odd, I would switch the DE. It's normal that lot of options are broken and reporting them to upstream as a bug, only does lead to flame. However, what exactly doesn't work? The default buttons and wheel settings should work as expected. Even while there's lot of very bad code for desktop stuff, a lot of, if not all default settings should work as expected. Customized settings at least often need to be manually restored after package updates. The latest updates for Xfce on Arch where annoying, I e.g. had to switch from a .svg to a .png for the menu icon, because the .svg I used for a long time, can't be used anymore. But there are also very serious issues, I for example had to remove gvfs, because it does make external drives spin down and up again and again. The menu is a complete mess and it can't be fixed with Alacarte or other menu editors, it only can be done without such a tool. FWIW, I'm using the open source ATI and the kernel-rt from AUR on 64 bit architecture. Sometimes I use a NVIDIA on the same machine and experienced the nouveau driver as better working, unfortunately the graphics can have impact to real-time audio abilities so I sometimes prefer to use an ATI. I've got a mobility radeon (rv620) chip and I've had a ton of problems with xfce. I was not using any login manager and xfce was always crashing the X session and getting me to tty, it was horrible (far from stable IMHO). @Whiskers maybe custom /etc/X11/xorg.conf.d/ profiles could help you with mouse/keyboard issues, i have to do it once in a chromium OS laptop and it solved the issues just fine. I felt more comfortable with lxde/openbox i found it more solid than xfce.
Re: [arch-general] Linux 3.9.2-1-ARCH cures blank screen
Am 13.05.2013 08:15, schrieb Ralf Mardorf: It's normal that lot of options are broken and reporting them to upstream as a bug, only does lead to flame. Do you have any examples? -- xmpp b...@schafweide.org bjo.nord-west.org | nord-west.org | freifunk-ol.de
[arch-general] RME cards: How to show board revision and the loaded firmware version?
Preliminary question and regarding to this question multiposted: Does anybody still use a RME HDSPe AIO ;)? Hi, since the issues I get for my RME HDSPe AIO didn't became less, but more within the last two years, I cleaned a primary partition to install XP, just to test, if there are issues caused by the mobo, that will appear, even when not using a *nix driver, but the proprietary driver and latest RME firmware. I'm a Linux only user, so sometime ago I installed FreeBSD, just to test, if the RME card isn't borked, since on Linux only 2 ADAT channels do work, fortunately all 8 ADAT channels work, using the FreeBSD driver (no TotalMix). I bought the card, because it was recommended by members of the Linux audio community. Don't get me wrong, the blame is on me, I decided to buy the card and had no time to use it within the first weeks, I only want to point out, that I did research before I bought the card. I wonder, if there are different revisions of the RME board? I know I've written this several times, but somebody might not have read it and it's a while ago since I ask for the situation of this card on other machines. Is there a command that shows the board revision and used firmware version? I run my Arch install without the alsa-firmware package and installed it now. $ uname -r 3.8.11-rt8-1-rt $ pacman -Q alsa-firmware error: package 'alsa-firmware' was not found $ sudo pacman -Syu alsa-firmware warning: ardour: ignoring package upgrade (2.8.16-1 = 3.1-1) alsa-firmware-1.0.27-2 $ pacman -Q alsa-firmware alsa-firmware 1.0.27-2 Can anybody use a HDSPe AIO on Linux with all available sample rates? Store alsamixer settings? Does hdspeconf run? Use latency = 10.7 ms? Use any latency even = 10.7 ms with getting absolutely no xruns? Use all ADAT channels? [root@archlinux rocketmouse]# tuning # service rtirq status PID CLS RTPRIO NI PRI %CPU STAT COMMAND 36 FF 90 - 130 0.0 Sirq/8-rtc0 178 FF 85 - 125 0.0 Sirq/18-snd_hdsp 179 FF 80 - 120 0.0 Sirq/20-snd_ice1 180 FF 79 - 119 0.0 Sirq/21-snd_ice1 75 FF 75 - 115 0.0 Sirq/16-ohci_hcd 78 FF 75 - 115 0.0 Sirq/19-ehci_hcd 86 FF 74 - 114 0.2 Sirq/17-ohci_hcd 91 FF 73 - 113 0.0 Sirq/17-ohci_hcd 34 FF 70 - 110 0.0 Sirq/1-i8042 24 FF 50 - 90 0.0 Sirq/9-acpi 51 FF 50 - 90 0.0 Sirq/42-radeon 70 FF 50 - 90 0.0 Sirq/14-pata_ati 71 FF 50 - 90 0.0 Sirq/15-pata_ati 79 FF 50 - 90 0.0 Sirq/22-ahci 165 FF 50 - 90 0.0 Sirq/7-parport0 460 FF 50 - 90 0.1 Sirq/43-enp3s0 3 FF 1 - 41 0.1 Sksoftirqd/0 13 FF 1 - 41 0.1 Sksoftirqd/1 # grep 18: /proc/interrupts 18: 0 4 IO-APIC-fasteoi snd_hdspm Mon May 13 10:31:03 CEST 2013 - 3.8.11-rt8-1-rt - Arch Linux \r (\l) [root@archlinux rocketmouse]# tuning-rice # service rtirq status PID CLS RTPRIO NI PRI %CPU STAT COMMAND 36 FF 90 - 130 0.0 Sirq/8-rtc0 178 FF 85 - 125 0.0 Sirq/18-snd_hdsp 75 FF 75 - 115 0.0 Sirq/16-ohci_hcd 78 FF 75 - 115 0.0 Sirq/19-ehci_hcd 86 FF 74 - 114 0.2 Sirq/17-ohci_hcd 91 FF 73 - 113 0.0 Sirq/17-ohci_hcd 34 FF 70 - 110 0.0 Sirq/1-i8042 24 FF 50 - 90 0.0 Sirq/9-acpi 51 FF 50 - 90 0.0 Sirq/42-radeon 70 FF 50 - 90 0.0 Sirq/14-pata_ati 71 FF 50 - 90 0.0 Sirq/15-pata_ati 79 FF 50 - 90 0.0 Sirq/22-ahci 165 FF 50 - 90 0.0 Sirq/7-parport0 460 FF 50 - 90 0.1 Sirq/43-enp3s0 3 FF 1 - 41 0.1 Sksoftirqd/0 13 FF 1 - 41 0.1 Sksoftirqd/1 # grep 18: /proc/interrupts 18: 0 4 IO-APIC-fasteoi snd_hdspm Mon May 13 10:31:47 CEST 2013 - 3.8.11-rt8-1-rt - Arch Linux \r (\l) OT: I noticed a thread at LAU about a PCIe card from another vendor, that was recommended to work with Linux, but it doesn't (or didn't?). Are there any PCIe cards available in the price range and audio quality of the HDSPe AIO, that are DEFINITIVELY known as working with Linux? Regards, Ralf
Re: [arch-general] about the removal of that systemd symlink...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/13/2013 12:26 AM, Hussam Al-Tayeb wrote: On Sunday 12 May 2013 22:32:03 David Benfell wrote: Hi all, I was alarmed, I think unnecessarily, when I saw the message that a symlink for systemd was removed on an upgrade. As near as I can tell, the boot sequence still relies on init, which links to the right place. Is there a better way to keep track of changes like this so I'm not surprised? Thanks! -- David Benfell / benf...@parts-unknown.org Please see https://parts-unknown.org/node/2 for GnuPG information (or the attachment you don't understand) There was a post installation message. Yes, if I take your message correctly, that was the message that alarmed me. Since systemd is the new init, I wanted to be sure that booting would still work correctly. I haven't tried, but I'm guessing it will. I'm just wanting to be kept better abreast. Thanks! - -- David Benfell / benf...@parts-unknown.org Please see https://parts-unknown.org/node/2 for GnuPG information (or the attachment you don't understand) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRkK90AAoJELJhbl/uPb4SBdYP/RFqJenOCPb69GConmp3iTzm wcB/W0LXb85or24mnN6IlwmAiIva+QOn1pDok3NtUStWNuDGvcBDvFn544it1ePL SLgvDVqxQiaBKR+UsKbgM1ikLtwZVjx0m50D+20ckI/HHfjbnFbXjXIE01dvvBBL c+AhGQyx2Yn9C2Bv0S8Q/xI9R9oaGPxc9MUPrmQT6OIwtIdzjF+4uEgB5r+BDJMS HlyoqMQ0wJbau0NhNzwsxtiffXQq0sEIVwUyTdaDlsQW9Ge7lkX7VnMCchT2+bsY l/W7WWcOPUR+PdVctkFypj5Fpe6xkGEaSi3KOAN3sOX77+mHL81LSPtDipSgllOT nyaoJI9CWsf/zy1SkeVuybnIH+3ew636vR4zqR+2JpJxxlNWz1HqK7TdzyO8fEB8 /SaiU7mhaqznMdj9a2BlHr46gB41zoC3ZVQOSZhVoW6PSFCvQd2wJrd0VHmf1nTP k0FPIfNMi+UuhTgx9llXbN5yKy9nHU5PIV5aco1NBt11nn+C4dO0UKbFrsJW33Gy RPCohXukyWPWevrbjr1jp2QGN/yBQhqok+IKAZtS0/aA2VpMHkIsaHR5mcotYu8j pLdT+IgWOGje4xT8FhlvR7JC1AfuVIfyt1Paw9FIelnJXXuOawqhu61tinovd/yO TetC/wErACT1HPgYSC8K =aued -END PGP SIGNATURE-
Re: [arch-general] about the removal of that systemd symlink...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/13/2013 01:03 AM, Karol Blazewicz wrote: Not reading pacman's output may lead to problems. Why do you think it's a bad way? It's precisely because I *did* read pacman's output that I was alarmed. Like I say, I think it's okay. But I'd like to keep better abreast of changes--and especially the thinking that goes into them--so I understand the pacman output when I see it. - -- David Benfell / benf...@parts-unknown.org Please see https://parts-unknown.org/node/2 for GnuPG information (or the attachment you don't understand) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRkLADAAoJELJhbl/uPb4SnCQP+wU03UatdwyQlfs/wA/FTcz/ yz9iYVqtfb0lpkEBODO2GqW3fsu+MEYemic1dcS53xtxVdOOSMc3j2aiIU1MOw+d cvdUXJvFVv/wT4//8+msqx4zMKWTK1vU+ufWVW8JKJMxT445NjFC7Tacjzkxz6zH QHJm1cOH/MWzyBSBJ9ui/BNj+4Sbbivv0IzKuJcxw/CDJjMMMmUB+yd8Op1MP4bv ktpV/aLRHcoD5MEp2IA/JirHin759W9+84cDu60kMMJJD/pY6wZBJzwXjtwemOLl +6AcLtt1uvVeUvbo4jP9QUYm7jUw5ZGck1VjChBuVQrysZaHBWxBelXpxL1lnHPX 0QZDvwmC/tqwCAYCxKr9fOLWvZr90eC8ioOfo+NWWhQR9o2AaxJTzQ0Ef6iHOG8B 0QovcIu9lCLLIcviipdhYTmrxXxmt5B8bZrmQTSLBbv9T94PjBRE6qHigN8TskiZ e1yMUw7qzWaq/vFzQlfNQRju7KbOcITeCRYK3uwuFp9LLlnC5S2JWWU2Ahj26ont 9aprGVlS0EB13cE8mZdCYBp/ea1VYwmYHQtc9nqx/8noyMDrHx51DzyGT9SIE3oR JKNz7deSzwUsqk/nxbuxQwl0OaQvM3qwXM5VxejE0L2teAq2w48Fv+ilLW4PMjuN OfhHKp1ouvtFsjftarZ4 =ohCh -END PGP SIGNATURE-
Re: [arch-general] about the removal of that systemd symlink...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/13/2013 01:19 AM, Thomas Bächler wrote: The wiki has told you to use init=/usr/lib/systemd/systemd for quite some time. When I was configuring the bootloaders (grub in two cases, gummiboot in another), I was following the installation instructions, and I didn't see this. Is it the Arch recommendation to add this kernel option at boot time? Or will /sbin/init point to /usr/lib/systemd/systemd for the foreseeable future? - -- David Benfell / benf...@parts-unknown.org Please see https://parts-unknown.org/node/2 for GnuPG information (or the attachment you don't understand) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRkLEJAAoJELJhbl/uPb4SMVEQALxb+98KQblHHGMCnerLYQQs kKXgd6GsXqhAEtjoRtntDz9lZO0ljC0nyXd6xKNOD1QzFTSV3XTN+L168Cdy9KBE 68Xy+fSkvHuR4/q9L/eK/vPByFzbHDWCrnqHzPwz2bbax+tsBQhmsk0lj7Z2tEMb GTpCvC0iskbU9aKuD/xXDaogyrzsIcR8PaKe18gW2Qxw9vW1XakU2B5MHlCFDMvD 9Dl6BIxcYtgUpciiYxflijJI5myZh9O6xAZQFmUd3TG23RqdCjhxi4oRUcGJLphJ q+5mC9Zv1Z5tNhjYjnoWSjpvtqdxFn9DcER+IuXcTw9s95Iq8TLb4+3zyw7hftHS oHcKKiM/cVCBO6kdGLG5iHx0AmjN/DxFrJxTECgfeU6TsvWZdIfHMRn0UZ6hIs3s Va6ys2s7NL8NqbGq7ed+3p2Klj2/b6UDsN3mkWt0GTD93zGgrPXMrudUZEQsQy9l kq9xRwRjcmfr3twgtkaNaKAUCF6XsxNN48l4ANShcZ/OkO7LT03ANwbbwvVcbAld 8EUL9jkrVOZuC2gvKiDIB9GTk+CGDROR3JVR8S41gr7NbrE84PcHqnQ+tOE0cJbh tVet4ptQT3P6gOlO1kxS6UBvQ3Z72kcmFUNBzi6eze3Vmq+fcsP7tgQag1743Pcr UGn7i9O8knJzitOp5ww7 =c0Lm -END PGP SIGNATURE-
Re: [arch-general] about the removal of that systemd symlink...
Am 13.05.2013 11:23, schrieb David Benfell: On 05/13/2013 01:19 AM, Thomas Bächler wrote: The wiki has told you to use init=/usr/lib/systemd/systemd for quite some time. When I was configuring the bootloaders (grub in two cases, gummiboot in another), I was following the installation instructions, and I didn't see this. At least, all places that used to say to use init=/bin/systemd have been changed to the new path. Is it the Arch recommendation to add this kernel option at boot time? Or will /sbin/init point to /usr/lib/systemd/systemd for the foreseeable future? As long as the kernel default for the init process is /sbin/init, we will keep probably the /sbin/init symlink for systemd. We may add /usr/lib/systemd/systemd to be the default in mkinitcpio and drop the /sbin/init symlink at some point (just a stupid idea of mine right now). In any case, booting a default installation without init= is supported and recommended, and we will make sure it keeps working. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Linux 3.9.2-1-ARCH cures blank screen
On 13-05-2013 08:30, Joaquin Villanova wrote: I've got a mobility radeon (rv620) chip and I've had a ton of problems with xfce. I was not using any login manager and xfce was always crashing the X session and getting me to tty, it was horrible (far from stable IMHO). That has been a problem for a long time and people recurrently ask how to solve it. Uncheck Save session for future logins at the logout menu, then delete everything inside ~/.config/xfce4-session and the problem should go away. -- Mauro Santos
Re: [arch-general] about the removal of that systemd symlink...
On Mon, 13 May 2013 10:19:36 +0200 Thomas Bächler tho...@archlinux.org wrote: Am 13.05.2013 10:18, schrieb Iru Cai: Well, some people seldom read pacman's output. e.g. I use a cron job to use pacman to update the system, and I don't read the log very often. That's your own fault then. Why do you think it's a bad way? Maybe some people haven't installed systemd-sysvcompat and still use 'init=/bin/systemd' . The wiki has told you to use init=/usr/lib/systemd/systemd for quite some time. The pacman warning wasn't wasted on me; I had to edit my /boot/grub/menu.lst - one day, I'll change to a more modern boot manager. -- -- ^^ -- Whiskers -- ~~
Re: [arch-general] Linux 3.9.2-1-ARCH cures blank screen
On Mon, 13 May 2013 10:41:57 +0100 Mauro Santos registo.maill...@gmail.com wrote: On 13-05-2013 08:30, Joaquin Villanova wrote: I've got a mobility radeon (rv620) chip and I've had a ton of problems with xfce. I was not using any login manager and xfce was always crashing the X session and getting me to tty, it was horrible (far from stable IMHO). That has been a problem for a long time and people recurrently ask how to solve it. XFCe has been pretty stable for me; I don't think it has ever crashed, although there have been a few passing quirks. Uncheck Save session for future logins at the logout menu, then delete everything inside ~/.config/xfce4-session and the problem should go away. That doesn't restore my desktop or mouse-button settings, nor does deleting them and re-making them. The pointer and keyboard settings are still working, fortunately! -- -- ^^ -- Whiskers -- ~~
Re: [arch-general] Linux 3.9.2-1-ARCH cures blank screen
On Mon, 13 May 2013 09:30:49 +0200 Joaquin Villanova joaquin.villanova.rom...@alumnos.upm.es wrote: [...] @Whiskers maybe custom /etc/X11/xorg.conf.d/ profiles could help you with mouse/keyboard issues, i have to do it once in a chromium OS laptop and it solved the issues just fine. I felt more comfortable with lxde/openbox i found it more solid than xfce. I have been pondering a change in window manager and desktop; I'll look at that combination - I like things uncluttered :)) -- -- ^^ -- Whiskers -- ~~
Re: [arch-general] 'Check out-of-date packages' tool
On 05/12/2013 03:21 PM, Anatol Pomozov wrote: Hi On Sat, May 11, 2013 at 1:25 PM, Don deJuan donjuans...@gmail.com wrote: On 05/11/2013 11:26 AM, Anatol Pomozov wrote: Hi everyone Per discussion in 'pacman-dev' maillist [1] I implemented a tool that tries to find Arch out-of-date packages. The tool scans PKGBUILD files is /var/abs directory, extracts download url and then tries to probe download urls for the next version. Next versions look like X.Y.Z+1 X.Y+1.0 X+1.0.0 If any of the new versions presents on the download server it reports to user as 'new version available'. Here is the tool sources https://github.com/anatol/pkgoutofdate To make its usage even more pleasant I added it to AUR https://aur.archlinux.org/packages/pkgoutofdate-git/ To use it please install pkgoutofdate-git package: $ yaourt -S pkgoutofdate-git Then update abs database and run tool itself: $ sudo abs pkgoutofdate That's it. The result looks like ... closure-linter: new version found - 2.3.8 = 2.3.9 perl-data-dump: new version found - 1.21 = 1.22 wgetpaste: new version found - 2.20 = 2.21 fillets-ng-data: new version found - 1.0.0 = 1.0.1 tablelist: new version found - 5.5 = 5.6 .. There are some fals positive and negative results though, mostly because download servers return different sort of weird responses. I still work on work-arounds for all these cases. Hope you find this tool useful and it will help to make Arch software even more bleeding edge. [1] https://mailman.archlinux.org/pipermail/pacman-dev/2013-March/thread.html#16850 Does this only work for packages found in the ABS or will it also work for AUR packages one might be maintaining? Only ABS right now. I did it because it is easy to traverse files under /var/abs and parse them. AUR requires additional step on fetching PKGBUILD from server. It should be fairly easy to add it. What is the recommended way to fetch files from aur? Just 'wget https://aur.archlinux.org/packages/pk/pkgoutofdate-git/PKGBUILD'? I would do it that was as it seems the easiest way to get just the PKGBUILD. Or could you add a flag where we can pass a directory, say where we store PKGBUILDs for the AUR we maintain. Thanks for the great tool though.
Re: [arch-general] libvirtd - save shutdown and systemd
On Wed, May 8, 2013 at 5:52 PM, Guus Snijders gsnijd...@gmail.com wrote: So at least one way would be place a script that calls /etc/rc.d/libvirtd-guests stop (or equivalent, it's not hard to replace) in /etc/systemd/system-shutdown/ . My main question is if this would be a correct way or that i could better write some custom unit file to do this? The tricky part is that i am /not/ interested in an automatic resume of previously running guests, only saving them in case i forgot. I'm not sure if it's of any help, but there is already a /lib/systemd/system/libvirt-guests.service unit that calls /etc/rc.d/libvirtd-guests. =-Jameson
[arch-general] gcc: loop do not terminate
I have just been hit by something:
lano1106@hpmini ~/dev/gcc-test $ g++ --version
g++ (GCC) 4.8.0 20130502 (prerelease)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
lano1106@hpmini ~/dev/gcc-test $ g++ -O2 -o test1 test1.cpp test1_init.cpp
lano1106@hpmini ~/dev/gcc-test $ ./test1
item 0
a: 1
lano1106@hpmini ~/dev/gcc-test $ g++ -O1 -o test1 test1.cpp test1_init.cpp
lano1106@hpmini ~/dev/gcc-test $ ./test1
item 0
a: 1
lano1106@hpmini ~/dev/gcc-test $ g++ -O0 -o test1 test1.cpp test1_init.cpp
lano1106@hpmini ~/dev/gcc-test $ ./test1
item 0
a: 1
item 1
a: 2
lano1106@hpmini ~/dev/gcc-test $ cat test1.h
struct A
{
int a;
int b;
int c;
};
struct B
{
int numelem;
/*
* Old C trick to define a dynamically sizable array just by allocating
* sizeof(B) + (numelem-1)*sizeof(A) memory.
*/
A item[1];
};
void initArr(B *p);
lano1106@hpmini ~/dev/gcc-test $ cat test1_init.cpp
#include test1.h
void initArr(B *p)
{
p-numelem = 2;
p-item[0].a = 1;
p-item[1].a = 2;
}
lano1106@hpmini ~/dev/gcc-test $ cat test1.cpp
/*
* Author: Olivier Langlois oliv...@trillion01.com
*
* Purpose: Small test to highlight gcc optimization bug
*/
#include stdio.h
#include string.h
#include test1.h
/*
* Create a B array with the intent of only using the first item.
* The 19 other items sole purpose is to create a buffer large enough
* to accomodate A array needs.
*/
#define MAXBLEN 20
int main(int argc, char *argv[])
{
B arr[MAXBLEN];
memset(arr,0,sizeof(arr));
initArr(arr);
for( int i = 0; i arr[0].numelem; ++i )
{
printf( item %d\n
a: %d\n,
i,
arr[0].item[i].a);
}
return 0;
}
From gcc website, this is not a bug:
Loops do not terminate
This is often caused by out-of-bound array accesses or by signed integer
overflow which both result in undefined behavior according to the ISO C
standard. For example
int
SATD (int* diff, int use_hadamard)
{
int k, satd = 0, m[16], dd, d[16];
...
for (dd=d[k=0]; k16; dd=d[++k])
satd += (dd 0 ? -dd : dd);
accesses d[16] before the loop is exited with the k16 check. This causes
the compiler to optimize away the exit test because the new value of k must be
in the range [0, 15] according to ISO C.
GCC starting with version 4.8 has a new option
-fno-aggressive-loop-optimizations that may help here. If it does, then this is
a clear sign that your code is not conforming to ISO C and it is not a GCC bug.
I am surprised that I didn't hit the problem before but I am seriously
considering using '-fno-aggressive-loop-optimizations' in my own makepkg.conf.
I just want to test others feeling on this discovery to see if it wouldn't be a
good idea to make the switch standard in Arch...
CONFIDENTIALITY : This e-mail and any attachments are confidential and may be
privileged. If you are not a named recipient, please notify the sender
immediately and do not disclose the contents to another person, use it for any
purpose or store or copy the information in any medium.
Re: [arch-general] gcc: loop do not terminate
On Mon, May 13, 2013 at 2:20 PM, LANGLOIS Olivier PIS -EXT
olivier.pis.langl...@transport.alstom.com wrote:
I have just been hit by something:
lano1106@hpmini ~/dev/gcc-test $ g++ --version
g++ (GCC) 4.8.0 20130502 (prerelease)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
lano1106@hpmini ~/dev/gcc-test $ g++ -O2 -o test1 test1.cpp test1_init.cpp
lano1106@hpmini ~/dev/gcc-test $ ./test1
item 0
a: 1
lano1106@hpmini ~/dev/gcc-test $ g++ -O1 -o test1 test1.cpp test1_init.cpp
lano1106@hpmini ~/dev/gcc-test $ ./test1
item 0
a: 1
lano1106@hpmini ~/dev/gcc-test $ g++ -O0 -o test1 test1.cpp test1_init.cpp
lano1106@hpmini ~/dev/gcc-test $ ./test1
item 0
a: 1
item 1
a: 2
lano1106@hpmini ~/dev/gcc-test $ cat test1.h
struct A
{
int a;
int b;
int c;
};
struct B
{
int numelem;
/*
* Old C trick to define a dynamically sizable array just by
allocating
* sizeof(B) + (numelem-1)*sizeof(A) memory.
*/
A item[1];
};
void initArr(B *p);
lano1106@hpmini ~/dev/gcc-test $ cat test1_init.cpp
#include test1.h
void initArr(B *p)
{
p-numelem = 2;
p-item[0].a = 1;
p-item[1].a = 2;
}
lano1106@hpmini ~/dev/gcc-test $ cat test1.cpp
/*
* Author: Olivier Langlois oliv...@trillion01.com
*
* Purpose: Small test to highlight gcc optimization bug
*/
#include stdio.h
#include string.h
#include test1.h
/*
* Create a B array with the intent of only using the first item.
* The 19 other items sole purpose is to create a buffer large enough
* to accomodate A array needs.
*/
#define MAXBLEN 20
int main(int argc, char *argv[])
{
B arr[MAXBLEN];
memset(arr,0,sizeof(arr));
initArr(arr);
for( int i = 0; i arr[0].numelem; ++i )
{
printf( item %d\n
a: %d\n,
i,
arr[0].item[i].a);
}
return 0;
}
From gcc website, this is not a bug:
Loops do not terminate
This is often caused by out-of-bound array accesses or by signed integer
overflow which both result in undefined behavior according to the ISO C
standard. For example
int
SATD (int* diff, int use_hadamard)
{
int k, satd = 0, m[16], dd, d[16];
...
for (dd=d[k=0]; k16; dd=d[++k])
satd += (dd 0 ? -dd : dd);
accesses d[16] before the loop is exited with the k16 check. This causes
the compiler to optimize away the exit test because the new value of k must
be in the range [0, 15] according to ISO C.
GCC starting with version 4.8 has a new option
-fno-aggressive-loop-optimizations that may help here. If it does, then this
is a clear sign that your code is not conforming to ISO C and it is not a GCC
bug.
I am surprised that I didn't hit the problem before but I am seriously
considering using '-fno-aggressive-loop-optimizations' in my own
makepkg.conf. I just want to test others feeling on this discovery to see if
it wouldn't be a good idea to make the switch standard in Arch...
The only time the switch makes a difference is when the program is
already incorrect. I really doubt Arch is going to enable a flag
slowing down all programs to make invalid programs behave
*differently* (not necessary as they were intended to behave, just
*differently*).
GCC is correctly noticing a situation that would result in undefined
behaviour, and optimizing based on the assumption that it never
happens. The solution is to write valid code not relying on undefined
behaviour - accessing beyond the end of an array is undefined
behaviour regardless of whether there's more allocated memory.
C99 has this feature as a flexible-length array member using `foo
array[];` and that might be valid C++11 but I'm not sure and I don't
feel like digging through the standard. Using `foo array[0]` will also
work because it's a GNU extension, but keep in mind that you've left
the land of standard C++.
Compilers are going to get better and better at optimizing away code
that's not needed if the program is assumed to be correct. I recommend
using another language if you don't want to worry about incorrect code
that seems to work now breaking from future optimizations.
[arch-general] gtkmm and VMware Workstation
Hello! An advice for VMware Workstation users: upgrading to gtkmm 2.24.3-1 on x86_64 makes VMware Workstation 8.0.6 crash on start or after a few seconds. I don't know about other versions. It happens with kernel 3.8.11 and 3.9.2. Downgrading to gtkmm 2.24.2-2 solves it (after an hour of trial and error). I'll create a bug report tomorrow. Too late for me now. Best Regards, Guillermo Leira
Re: [arch-general] gcc: loop do not terminate
The only time the switch makes a difference is when the program is already incorrect. I really doubt Arch is going to enable a flag slowing down all programs to make invalid programs behave *differently* (not necessary as they were intended to behave, just *differently*). GCC is correctly noticing a situation that would result in undefined behaviour, and optimizing based on the assumption that it never happens. The solution is to write valid code not relying on undefined behaviour - accessing beyond the end of an array is undefined behaviour regardless of whether there's more allocated memory. C99 has this feature as a flexible-length array member using `foo array[];` and that might be valid C++11 but I'm not sure and I don't feel like digging through the standard. Using `foo array[0]` will also work because it's a GNU extension, but keep in mind that you've left the land of standard C++. Compilers are going to get better and better at optimizing away code that's not needed if the program is assumed to be correct. I recommend using another language if you don't want to worry about incorrect code that seems to work now breaking from future optimizations. I hear you. I, however, disagree when you qualify the old C trick pattern as incorrect. My A B toy structs are a simplification of what I have seen in the AMD ADL SDK and was causing the loop problem with: http://code.google.com/p/overdrive5/ What is debatable, IMO, is how widespread the usage of this particular pattern is. Personally, I am not using it but I knew it for having seen it in the past a couple of times. My expectations of compiler optimization is that they should be transparent and respect the intent of the program. This optimization switch must probably be doing a lot of good stuff but this particular manifestation is, IMO, a stunning reinterpretation of an explicit request to iterate n times. CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.
Re: [arch-general] about the removal of that systemd symlink...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/13/2013 02:32 AM, Thomas Bächler wrote: In any case, booting a default installation without init= is supported and recommended, and we will make sure it keeps working. Good. That alleviates a lot of my concern. - -- David Benfell / benf...@parts-unknown.org Please see https://parts-unknown.org/node/2 for GnuPG information (or the attachment you don't understand) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRkWXRAAoJELJhbl/uPb4S59MP/Rz7nYSX174lrFrOZ916UITn 1eMBbPq4O/4FUKWpqQ6E5XNVHRohzfzuYbD8aLhDcSK58wMz0wDjdIjxqaCjw5dl O/V2BLDsEks0NaaLKdrrZSTtote8xPTzl5Y5iuJXEHO8t+3+DnddDFr6U+SeDKpE VDiUyELqL2aHNiO7JSHPHRrzjPK6h3G/xIWCXW6xvv2iz0Tcv/Rv5CfUS0oMqThC IQH2ZcQwR0Aw1dE4+S1l0dT4XQ0YLhIrRNt421iT35WhSp03yVl+cN842IQCzdQB tgX/nSfiKhZm9LAwJa0Abwb+SgvdaPF2VZDMhp04ZAzf6ZW7mi8mlWdVvs7RUlb+ AilE+jCDP3C82OQCysnbpCajER9Tw7V4l0MxV0VW0DhPh8VbuRQP7t7+ojij6WFr 9M0ibZH2hEVgzSd6LpTAD/NYeHtTA+TlilvFGcSZVlpOzOn2xYQRvcFAOBumUJsu ANAIluvldz+hhBdd89mfXVitWAc9sZL+7TI/f2xPzNZaGganSD7mv8LDA8kbdOUT 7BFQ7eSCdoStBz20cC7PBpOXluZq0p/+vmo1NBPfwk/x12FRsMEM6RyvlwB9lzxI VOUPO6owPbsS7KUVe3cPS2bzDHFIO3rH7BOvXY098bhV7gv1MfvikRtQG0zoJgS9 uPhj/ZZTUcPJujQKUaI0 =6x/W -END PGP SIGNATURE-
Re: [arch-general] gcc: loop do not terminate
On Mon, May 13, 2013 at 4:59 PM, LANGLOIS Olivier PIS -EXT olivier.pis.langl...@transport.alstom.com wrote: The only time the switch makes a difference is when the program is already incorrect. I really doubt Arch is going to enable a flag slowing down all programs to make invalid programs behave *differently* (not necessary as they were intended to behave, just *differently*). GCC is correctly noticing a situation that would result in undefined behaviour, and optimizing based on the assumption that it never happens. The solution is to write valid code not relying on undefined behaviour - accessing beyond the end of an array is undefined behaviour regardless of whether there's more allocated memory. C99 has this feature as a flexible-length array member using `foo array[];` and that might be valid C++11 but I'm not sure and I don't feel like digging through the standard. Using `foo array[0]` will also work because it's a GNU extension, but keep in mind that you've left the land of standard C++. Compilers are going to get better and better at optimizing away code that's not needed if the program is assumed to be correct. I recommend using another language if you don't want to worry about incorrect code that seems to work now breaking from future optimizations. I hear you. I, however, disagree when you qualify the old C trick pattern as incorrect. My A B toy structs are a simplification of what I have seen in the AMD ADL SDK and was causing the loop problem with: http://code.google.com/p/overdrive5/ What is debatable, IMO, is how widespread the usage of this particular pattern is. Personally, I am not using it but I knew it for having seen it in the past a couple of times. My expectations of compiler optimization is that they should be transparent and respect the intent of the program. This optimization switch must probably be doing a lot of good stuff but this particular manifestation is, IMO, a stunning reinterpretation of an explicit request to iterate n times. According to the C and C++ standards, it's undefined behaviour to index past the end of an array with a given size. It's not debatable whether it's incorrect - the standards committee explicitly considered this case and finally standardized a way to do it without undefined behaviour in C99.
