Re: Increasing minimum 'i386' processor
Guillem Jover guil...@debian.org writes: Hi! On Sat, 2011-11-19 at 22:42:11 +, Ben Hutchings wrote: The i386 architecture was the first in Linux and in Debian, but we have long since dropped support for the original i386-compatible processors and now require a minimum of a 486-class processor. I think it is time to increase the minimum requirement to 586-class, if not for wheezy then immediately after. (Later it should be increased further, and eventually i386 should be reduced to a partial architecture that may be installed on amd64 systems.) This would allow the use of optimisations and new instructions throughout userland that improve performance for the vast majority of users. It seems gcc has been targetting i586 instruction set by default since gcc 4.4.0-1~exp1, although the triplet was not changed to match. On the discussion regarding multiarch tuples I proposed we should switch the triplet back to i386-linux-gnu to avoid this kind of confusion, fix the internal inconsistency and the one with other architectures (which do not track the base instruction set in the triplet) and so that we can use them directly as the multiarch tuples. For more details please see: http://lists.debian.org/debian-dpkg/2011/02/msg00061.html http://lists.debian.org/debian-dpkg/2011/02/msg00039.html regards, guillem While I agree that the triplet should be unique for all the reasons stated in the two mails I have to disagree with your conclusion to change the gcc triplet to i386-linux-gnu. A gcc compiling for i486-linux-gnu, i585-linux-gnu or even i686-linux-gnu is not compiling for the i386-linux-gnu ABI. You would be making the same mistake that arm does on i*86 too, making the triplet not unique. You could have a normal gcc and a i386-linux-gnu-gcc on your system. MfG Goswin -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5vbf2f8.fsf@frosties.localnet
Re: Increasing minimum 'i386' processor
On Nov 19, Ben Hutchings b...@decadent.org.uk wrote: I think it is time to increase the minimum requirement to 586-class, if not for wheezy then immediately after. I agree, it's time to weight the costs and benefits of supporting obsolete hardware at the expense of most users. (Later it should be increased further, and eventually i386 should be reduced to a partial architecture that may be installed on amd64 systems.) Yes, but how much later? :-) -- ciao, Marco signature.asc Description: Digital signature
Bug#614254: marked as done ([gcc-4.4] Please support ppc64)
Your message dated Sun, 20 Nov 2011 23:33:43 +0900 with message-id 4ec90fc7.3040...@gmail.com and subject line Re: Bug#614254: [gcc-4.4] Please support ppc64 has caused the Debian Bug report #614254, regarding [gcc-4.4] Please support ppc64 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 614254: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614254 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: gcc-4.4 Version: 4.4.5-12 Severity: wishlist Tags: patch Hi, Please support ppc64. Regards, -- Hiroyuki Yamamoto A75D B285 7050 4BF9 AEDA 91AC 3A10 59C6 5203 04DC diff -Nurd gcc-4.4-4.4.5.orig/debian/lib32gomp1.symbols.ppc64 gcc-4.4-4.4.5/debian/lib32gomp1.symbols.ppc64 --- gcc-4.4-4.4.5.orig/debian/lib32gomp1.symbols.ppc64 2011-02-18 13:03:01.0 +0900 +++ gcc-4.4-4.4.5/debian/lib32gomp1.symbols.ppc64 2011-02-19 06:45:26.0 +0900 @@ -1,4 +1,131 @@ libgomp.so.1 lib32gomp1 #MINVER# -#include libgomp1.symbols.common + GOMP_atomic_end@Base 4.4 + GOMP_atomic_start@Base 4.4 + GOMP_barrier@Base 4.4 + GOMP_critical_end@Base 4.4 + GOMP_critical_name_end@Base 4.4 + GOMP_critical_name_start@Base 4.4 + GOMP_critical_start@Base 4.4 + GOMP_loop_dynamic_next@Base 4.4 + GOMP_loop_dynamic_start@Base 4.4 + GOMP_loop_end@Base 4.4 + GOMP_loop_end_nowait@Base 4.4 + GOMP_loop_guided_next@Base 4.4 + GOMP_loop_guided_start@Base 4.4 + GOMP_loop_ordered_dynamic_next@Base 4.4 + GOMP_loop_ordered_dynamic_start@Base 4.4 + GOMP_loop_ordered_guided_next@Base 4.4 + GOMP_loop_ordered_guided_start@Base 4.4 + GOMP_loop_ordered_runtime_next@Base 4.4 + GOMP_loop_ordered_runtime_start@Base 4.4 + GOMP_loop_ordered_static_next@Base 4.4 + GOMP_loop_ordered_static_start@Base 4.4 + GOMP_loop_runtime_next@Base 4.4 + GOMP_loop_runtime_start@Base 4.4 + GOMP_loop_static_next@Base 4.4 + GOMP_loop_static_start@Base 4.4 + GOMP_loop_ull_dynamic_next@Base 4.4 + GOMP_loop_ull_dynamic_start@Base 4.4 + GOMP_loop_ull_guided_next@Base 4.4 + GOMP_loop_ull_guided_start@Base 4.4 + GOMP_loop_ull_ordered_dynamic_next@Base 4.4 + GOMP_loop_ull_ordered_dynamic_start@Base 4.4 + GOMP_loop_ull_ordered_guided_next@Base 4.4 + GOMP_loop_ull_ordered_guided_start@Base 4.4 + GOMP_loop_ull_ordered_runtime_next@Base 4.4 + GOMP_loop_ull_ordered_runtime_start@Base 4.4 + GOMP_loop_ull_ordered_static_next@Base 4.4 + GOMP_loop_ull_ordered_static_start@Base 4.4 + GOMP_loop_ull_runtime_next@Base 4.4 + GOMP_loop_ull_runtime_start@Base 4.4 + GOMP_loop_ull_static_next@Base 4.4 + GOMP_loop_ull_static_start@Base 4.4 + GOMP_ordered_end@Base 4.4 + GOMP_ordered_start@Base 4.4 + GOMP_parallel_end@Base 4.4 + GOMP_parallel_loop_dynamic_start@Base 4.4 + GOMP_parallel_loop_guided_start@Base 4.4 + GOMP_parallel_loop_runtime_start@Base 4.4 + GOMP_parallel_loop_static_start@Base 4.4 + GOMP_parallel_sections_start@Base 4.4 + GOMP_parallel_start@Base 4.4 + GOMP_sections_end@Base 4.4 + GOMP_sections_end_nowait@Base 4.4 + GOMP_sections_next@Base 4.4 + GOMP_sections_start@Base 4.4 + GOMP_single_copy_end@Base 4.4 + GOMP_single_copy_start@Base 4.4 + GOMP_single_start@Base 4.4 + GOMP_task@Base 4.4 + GOMP_taskwait@Base 4.4 + gomp_thread_destructor@Base 4.4 + omp_destroy_lock@Base 4.4 + omp_destroy_lock_@Base 4.4 + omp_destroy_nest_lock@Base 4.4 + omp_destroy_nest_lock_@Base 4.4 + omp_get_active_level@Base 4.4 + omp_get_active_level_@Base 4.4 + omp_get_ancestor_thread_num@Base 4.4 + omp_get_ancestor_thread_num_8_@Base 4.4 + omp_get_ancestor_thread_num_@Base 4.4 + omp_get_dynamic@Base 4.4 + omp_get_dynamic_@Base 4.4 + omp_get_level@Base 4.4 + omp_get_level_@Base 4.4 + omp_get_max_active_levels@Base 4.4 + omp_get_max_active_levels_@Base 4.4 + omp_get_max_threads@Base 4.4 + omp_get_max_threads_@Base 4.4 + omp_get_nested@Base 4.4 + omp_get_nested_@Base 4.4 + omp_get_num_procs@Base 4.4 + omp_get_num_procs_@Base 4.4 + omp_get_num_threads@Base 4.4 + omp_get_num_threads_@Base 4.4 + omp_get_schedule@Base 4.4 + omp_get_schedule_8_@Base 4.4 + omp_get_schedule_@Base 4.4 + omp_get_team_size@Base 4.4 + omp_get_team_size_8_@Base 4.4 + omp_get_team_size_@Base 4.4 + omp_get_thread_limit@Base 4.4 + omp_get_thread_limit_@Base 4.4 + omp_get_thread_num@Base 4.4 + omp_get_thread_num_@Base 4.4 + omp_get_wtick@Base 4.4 + omp_get_wtick_@Base 4.4 + omp_get_wtime@Base 4.4 + omp_get_wtime_@Base 4.4 + omp_in_parallel@Base 4.4 + omp_in_parallel_@Base 4.4 + omp_init_lock@Base 4.4 + omp_init_lock_@Base 4.4 + omp_init_nest_lock@Base 4.4 + omp_init_nest_lock_@Base 4.4 + omp_set_dynamic@Base 4.4 + omp_set_dynamic_8_@Base 4.4 + omp_set_dynamic_@Base 4.4 + omp_set_lock@Base 4.4 + omp_set_lock_@Base 4.4 +
Bug#649307: gnat-4.6: FTBFS on kfreebsd-amd64 (gengtype: Internal error: abort in get_output_file_with_visibility, at gengtype.c:1998)
On 11/19/2011 11:50 PM, Julien Cristau wrote: On Sat, Nov 19, 2011 at 23:32:48 +0100, Ludovic Brenta wrote: retitle 649307 FTBFS on kfreebsd-amd64: gengtype: Internal error: abort in get_output_file_with_visibility, at gengtype.c:1998 reassign 649307 src:gcc-4.6 severity 649307 important forcemerge 649307 637236 thanks Julien and everyone else, please stop filing FTBFS bugs automatically against gcc-4.6 or gnat-4.6. We monitor the buildds and are aware of FTBFS, so these bugs are not useful for us and only take away some of our precious time for triaging. Thanks. Indeed. They may not be useful to you bug they're useful to everyone else. Why are you downgrading this bug? It's a buildd issue, which somebody needs to investigate. The all port lights on green attitude by the release team (not only for kfreebsd) doesn't help with this either. Matthias -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ec90ee1.3030...@debian.org
Bug#649307: gnat-4.6: FTBFS on kfreebsd-amd64 (gengtype: Internal error: abort in get_output_file_with_visibility, at gengtype.c:1998)
On Sun, 2011-11-20 at 15:29 +0100, Matthias Klose wrote:
On 11/19/2011 11:50 PM, Julien Cristau wrote:
On Sat, Nov 19, 2011 at 23:32:48 +0100, Ludovic Brenta wrote:
retitle 649307 FTBFS on kfreebsd-amd64: gengtype: Internal error: abort in
get_output_file_with_visibility, at gengtype.c:1998
reassign 649307 src:gcc-4.6
severity 649307 important
forcemerge 649307 637236
thanks
Julien and everyone else, please stop filing FTBFS bugs automatically
against gcc-4.6 or gnat-4.6.
They're not automatic, the package *is* failing to build, and that issue
should be documented.
We monitor the buildds and are aware of
FTBFS, so these bugs are not useful for us and only take away some of
our precious time for triaging. Thanks.
Failures of other packages to build can't be blocked against oh, the
maintainers will know about it. Nor is anyone triaging said failures
going to automatically be aware that you know about the issue, what
progress (if any) has made towards resolving it, whether it's an issue
with GC{C,J} itself or a kernel or glibc issue, ...
In this particular case, it appears that the bug is actually in gcc and
that the gnat failure is a side-effect? In that case, the bug should be
marked as affecting the gnat package, so it shows up in gnat's bug list.
I see Julien already added the affects, but if that had been done when
the bug was reassigned then it would have been visible in gnat-4.6's bug
list before a duplicate was filed and I suspect at least some of the
animosity in this exchange could have been avoided.
They may not be useful to you bug they're useful to everyone else. Why
are you downgrading this bug?
It's a buildd issue, which somebody needs to investigate.
The log of #637236, which Julien's report got merged with, implies that
someone *is* and has been investigating.
As a general note, marking what are otherwise RC bugs as important so
that the package can migrate isn't really appropriate, at least not
without discussion with the release team (at which point we can e.g.
tell britney to ignore the problems for a particular version).
The all port lights
on green attitude by the release team (not only for kfreebsd) doesn't help
with
this either.
If you have specific concerns about the viability of specific ports,
then raise them appropriately (and preferably in a constructive manner).
Making snide remarks and then complaining that nobody's listening to the
issues isn't helpful.
Regards,
Adam
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1321807223.23841.44.ca...@hathi.jungle.funky-badger.org
Bug#622698: gcc-4.4: Please disable libstdc++- testsuite on sh4
Hi,
2011/11/18 Matthias Klose d...@debian.org:
tag 622698 + wontfix
thanks
On 04/14/2011 02:26 AM, Nobuhiro Iwamatsu wrote:
Package: gcc-4.4
Version: 4.4.5-14
Severity: wishlist
Tags: patch
sh4 needs much time in a test of gcc.
It is a test of libstdc++ to spend much time in that (about 28 hour).
I want to disable sh4's test of libstdc++ in the same way as arm*(Ubuntu).
Please disable libstdc++- testsuite on sh4.
I do not want to disable tests just because they take too long.
Yes, I agree.
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/cabmqnvkacsb9ye8r30o5zdzc7d0_mnywudf83uycmg3r8lm...@mail.gmail.com
