When I run eix-test-obsolete it reports a strange package:
...
The following installed packages are not in the database:
sys-kernel/-MERGING-gentoo-sources
sys-kernel/-MERGING-gentoo-sources
--
But there is no package by the name sys-kernel/-MERGING-gentoo-sources.
Where does this come from?
on 06/30/2011 12:10 PM Thanasis wrote the following:
When I run eix-test-obsolete it reports a strange package:
...
The following installed packages are not in the database:
sys-kernel/-MERGING-gentoo-sources
sys-kernel/-MERGING-gentoo-sources
--
But there is no package by the name
В Чтв, 30/06/2011 в 12:44 +0300, Thanasis пишет:
on 06/30/2011 12:10 PM Thanasis wrote the following:
When I run eix-test-obsolete it reports a strange package:
...
The following installed packages are not in the database:
sys-kernel/-MERGING-gentoo-sources
on 06/30/2011 01:00 PM Peter Volkov wrote the following:
It must be some kind of transient emerge side effect, but it happens no
matter if at that time something gets merged or not.
Check /var/db/pkg/sys-kernel I guess it has -MERGING-gentoo-sources
directory. Probably it's safe to remove
On 6/30/11 12:00 PM, Peter Volkov wrote:
В Чтв, 30/06/2011 в 12:44 +0300, Thanasis пишет:
on 06/30/2011 12:10 PM Thanasis wrote the following:
When I run eix-test-obsolete it reports a strange package:
...
The following installed packages are not in the database:
On Fri, 01 Jul 2011 00:30:57 +0200
Alex Schuster wo...@wonkology.org wrote:
Who will file the bug report now?
Thanks for the confirmation.
GCC-4.5.2, some may claim, is already old hat. I just tried
the same experiment using GCC-4.6.0 and there is no problem.
The program works with O2
On 07/01/2011 02:35 AM, Nikos Chantziaras wrote:
On 07/01/2011 12:45 AM, Frank Peters wrote:
Hello,
After banging my head for a while over some strange results, I began
to suspect GCC-4.5.2, the latest version in portage, was creating
faulty code.
It seems to a correct suspicion.
[...]
int n;
On 07/01/2011 03:04 AM, Frank Peters wrote:
On Fri, 01 Jul 2011 02:44:36 +0300
Nikos Chantziarasrea...@arcor.de wrote:
Your code is buggy, because you're breaking C's aliasing rules. You are
not allowed to use a different pointer type to dereference a variable of
a different type. Doing so
On Fri, 01 Jul 2011 02:44:36 +0300
Nikos Chantziaras rea...@arcor.de wrote:
unsigned long int *px = (unsigned long int*)x;
And here you can read more thorough information about strict aliasing:
http://labs.qt.nokia.com/2011/06/10/type-punning-and-strict-aliasing
Thanks for this link.
On Fri, 01 Jul 2011 02:44:36 +0300
Nikos Chantziaras rea...@arcor.de wrote:
And here you can read more thorough information about strict aliasing:
http://labs.qt.nokia.com/2011/06/10/type-punning-and-strict-aliasing
You've saved the day in more ways than one.
A few days ago I posted
On Fri, 1 Jul 2011 00:58:46 + (UTC)
Duncan 1i5t5.dun...@cox.net wrote:
I had wondered if this might be an undefined behavior optimization bug,
Well, the amd64 users list may not be the appropriate place to discuss
C programming, but the problem here stems from attempting to do things
Frank Peters posted on Thu, 30 Jun 2011 21:23:21 -0400 as excerpted:
Anyway, I'm glad I presented this issue. It has definitely improved my
understanding. GCC has dozens, if not hundreds, of compile options and
I know the actual function of only a small few.
Indeed. The gcc manpage is a
Frank Peters posted on Thu, 30 Jun 2011 21:04:29 -0400 as excerpted:
On Fri, 01 Jul 2011 02:44:36 +0300 Nikos Chantziaras rea...@arcor.de
wrote:
And here you can read more thorough information about strict aliasing:
http://labs.qt.nokia.com/2011/06/10/type-punning-and-strict-aliasing
Frank Peters frank.pet...@comcast.net skribis:
A few days ago I posted about a possible problem with a floating
point test called the UCBTEST. After examining the source code
of this test, I see violations of aliasing rules throughout.
It's hard to efficiently manipulate variables without
On Fri, 1 Jul 2011, Frank Peters wrote:
On Fri, 1 Jul 2011 00:58:46 + (UTC)
Duncan 1i5t5.dun...@cox.net wrote:
I had wondered if this might be an undefined behavior optimization bug,
Well, the amd64 users list may not be the appropriate place to discuss
C programming, but the problem
On Thu, Jun 30, 2011 at 6:23 PM, Frank Peters frank.pet...@comcast.net wrote:
On Fri, 1 Jul 2011 00:58:46 + (UTC)
Duncan 1i5t5.dun...@cox.net wrote:
I had wondered if this might be an undefined behavior optimization bug,
Well, the amd64 users list may not be the appropriate place to
On Thu, 30 Jun 2011 21:36:38 -0700
Mark Knecht markkne...@gmail.com wrote:
I think it's completely appropriate for this list. This distro expects
that we put CFLAG options in make.conf so I need to hear about this
stuff even if I don't have to background to completely understand
what's
17 matches
Mail list logo
