On Tue, Mar 1, 2011 at 8:34 PM, Matthias Klose wrote:
> I'll make gcc-4.5 the default for (at least some) architectures within the
> next
> two weeks before more transitions start. GCC-4.5 is already used as the
> default
> compiler for almost any other distribution, so there shouldn't be many
On Fri, Aug 6, 2010 at 11:03 AM, Matthias Klose wrote:
> On 06.08.2010 00:58, brian m. carlson wrote:
>>
>> On Thu, Aug 05, 2010 at 10:59:18PM +0200, Matthias Klose wrote:
>>>
>>> On 08.07.2010 01:42, brian m. carlson wrote:
Package: gcc-4.4
Version: 4.4.4-6
Severity: wishlist
On Fri, Feb 26, 2010 at 3:14 AM, Petr Salinger wrote:
> My point is a different one, see in #570889.
>
> 14997 gij-4.4 CALL open(0x8e59e58,O_RDONLY|O_LARGEFILE,0)
> 14997 gij-4.4 NAMI ".../defaults.properties"
> 14997 gij-4.4 RET open 10/0xa
> 14997 gij-4.4 CALL fstat(0xa,0xbfbf29ec)
> 149
On Thu, Feb 25, 2010 at 7:22 PM, Petr Salinger wrote:
>> On Thu, Feb 25, 2010 at 9:23 AM, Petr Salinger
>> wrote:
>>>
>>> The file, which have to be copied, have size 1701,
>>> but two pages (2*4096) are mmaped. It is allowed on both
>>> Linux and FreeBSD.
>>> When the 2nd page of that file would
On Mon, Nov 23, 2009 at 8:48 AM, Aurelien Jarno wrote:
>> Next steps:
>> (1) Wait for testsuite results to finish completely. Verify nothing
>> has regressed.
No regressions.
>> (2) Remove changes to gcc package debian/rules2 and re-run validation.
Some regressions caused by enabling cloog/ppl,
On Mon, Nov 23, 2009 at 5:22 AM, Aurelien Jarno wrote:
> Carlos O'Donell a écrit :
>> On Sun, Nov 22, 2009 at 5:05 PM, John David Anglin
>> wrote:
>>>> While I set out the glibc types exactly as before (binary compatible),
>>>> the alignment res
On Sun, Nov 22, 2009 at 5:05 PM, John David Anglin
wrote:
>> While I set out the glibc types exactly as before (binary compatible),
>> the alignment restrictions were changed subtly.
>
> Excellent debugging!
I have adjusted the glibc lock structure alignments to try and match
more accurately the
On Sun, Nov 22, 2009 at 2:51 PM, Carlos O'Donell
wrote:
> This happens because the original locale object was created at address
> 0xbff01c20. However, when apt-get calls "std::basic_ios std::char_traits >::init" it passes in the address 0xbff01c18.
> So we went from
On Sun, Nov 22, 2009 at 10:30 AM, John David Anglin
wrote:
>> > The problem appears to have gone away with head. I don't see it with
>> > hpux.
>> >
>>
>> Note that latest version of gcc 4.4 in Debian is built with
>> --disable-libstdcxx-pch, but the segfault is this present :(
>
> Personally, I
On Sat, Nov 21, 2009 at 5:37 AM, Aurelien Jarno wrote:
>
> I confirm, it's what I see in the testsuite log:
>
> | 77
> | __signbitl
> | version status: incompatible
> | GLIBCXX_3.4
> | type: function
> | status: added
If __signbitl is the only failure in the abi_check, then that's easy
to fix, th
On Fri, Nov 20, 2009 at 10:31 AM, Aurelien Jarno wrote:
> Domenico Andreoli a écrit :
>> On Thu, Nov 05, 2009 at 06:47:11PM +0100, Domenico Andreoli wrote:
>>> On Thu, Nov 5, 2009 at 5:43 PM, Matthias Klose wrote:
On 05.11.2009 14:30, Domenico Andreoli wrote:
> frankly i do not know what
On Sun, Nov 15, 2009 at 11:03 PM, Felipe Sateler wrote:
> I think the analysis it is wrong, because after the scons clean stage, the
> cache is deleted. Relevant section from debian/cdbs/1/class/scons.mk:
>
> scons-clean::
> $(DEB_SCONS_INVOKE) $(DEB_SCONS_CLEAN_TARGET) $(DEB_SCONS_OPTIONS)
What is the status of this bug?
Is it up to the package maintainer to disable cloog/ppl for hppa and
try the build again?
Speaking professionally, CodeSourcery enables cloog/ppl for our
toolchain products, but we do a lot of additional testing to verify
everything is working properly.
At the end
On Sat, Mar 22, 2008 at 6:10 PM, Aurelien Jarno <[EMAIL PROTECTED]> wrote:
> I have tried to build the glibc with GCC 4.3 on hppa, and rpcgen
> segfaults when it is used, so the build fails. I haven't start to
> investigate the problem (I started by the architectures where the
> problems were m
On Sat, Mar 22, 2008 at 6:10 PM, Aurelien Jarno <[EMAIL PROTECTED]> wrote:
> Carlos O'Donell a écrit :
>
> > On Sat, Mar 22, 2008 at 4:33 PM, Matthias Klose <[EMAIL PROTECTED]> wrote:
> >> For all ports besides alpha and hppa we plan to make GCC-4.3
On Sat, Mar 22, 2008 at 5:10 PM, Matthias Klose <[EMAIL PROTECTED]> wrote:
> Carlos O'Donell writes:
> > > - gij/gcj shows bus errors on hppa (either 4.2 or 4.3).
> >
> > Has gij/gcj ever worked on hppa-linux?
>
> at least the gij/gcj before addi
the architecture
> for the lenny release, use another (which?) compiler version, drop
> gcj/java support, or fix things)?
Cheers,
Carlos O'Donell
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> Aside from the evilness of doing binNMUs of this magnitude, I doubt a
> "transition" that doesn't change the SONAME will work. As soon as the
> new libstdc++ is installed, every c++ app on the box will instantly
> break. This means if anything happens e.g. to apt during the update, the
> system w
> >The issue is a rather pedantic one. Should an error be generated
> >by the compiler indicating that 'return 0' can never be reached?
>
> Not an error because the code is in fact correct, but a warning about
> unreachable code would be nice.
>
> Regards,
> Bart
>
Originally this had appeared
> Eugene,
>
> This code is completely correct as far as I can see. The second while is
> interpreted as a new while loop, and the closing; is short for {} in
> this case. I've expanded the code into a more intuitive form here:
>
> int main()
> {
> int a = 0;
>
> while (a == 0) {
> a =
> > > It should probably be LD_LIBRARY_PATH=whatever:$${LD_LIBRARY_PATH}
> > Even better, something like
> > LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}whatever.
> > It's generally not desirable to introduce null path components into
> > LD_LIBRARY_PATH if it was unset before, see #152099
> >
> > Changed my mind. After a posting from Linus on dri-devel and a discussion
> > about integer overflow (undefined) in C the following came out:
>
> Is integer overflow behaviour really undefined? If yes (I want it to be yes
> :),
> then, of course, it's the programmer's fault, not the compil
On Wed, Aug 21, 2002 at 11:55:27AM +0300, Alexei Khlebnikov wrote:
> > I think this program should not terminate at all because i will
> > always be one greater than oldi.
> > I think gcc3.0 has a problem with no optimization then but since
> > there is later version that works gcc 3.1.1, upgrade.
> >
> > With no optimization the program runs correctly by the rules of integers
> > representation in memory. See the explanation below.
> >
>
> I must have been asleep last night :} Thanks Alexei!
>
> gcc-3.1 generates similar code, don't have 3.2 on an i386 box
> to test. Though 3.2 on an hp
On Wed, Aug 21, 2002 at 11:55:27AM +0300, Alexei Khlebnikov wrote:
> > I think this program should not terminate at all because i will
> > always be one greater than oldi.
> > I think gcc3.0 has a problem with no optimization then but since
> > there is later version that works gcc 3.1.1, upgrade.
> I think this program should not terminate at all because i will
> always be one greater than oldi.
> I think gcc3.0 has a problem with no optimization then but since
> there is later version that works gcc 3.1.1, upgrade.
>
> Thanks,
> Andrew Pinski
>
Agreed. Infact it doesn't terminate on a
M,
> changes in the system include files which affected the result?
I thought that too, so I put features.h.orig back ontop of features.h.
And it still kept compiling. So I thought, I must have modified
the original back too. No problem, I'm compiling glibc, I have the
source lying around. diff'
es.
Currently 2.2.4-1 dies randomly with a seg'ing Zic while
walking timezones... odd :}
Hope this helps with understanding the problem.
Get someone to try the 'undef' beforehand case.
Cheers,
Carlos O'Donell Jr.
28 matches
Mail list logo
