* Luca Boccassi:
> On Mon, 15 May 2023 at 10:57, Florian Weimer wrote:
>>
>> * Luca Boccassi:
>>
>> > On Mon, 8 May 2023 at 23:08, Florian Weimer wrote:
>> >>
>> >> * Luca Boccassi:
>> >>
>> >> > But the more I thi
* Luca Boccassi:
> On Mon, 8 May 2023 at 23:08, Florian Weimer wrote:
>>
>> * Luca Boccassi:
>>
>> > But the more I think about it, the more I am convinced that the
>> > default option working best for Debian is the one that matches the
>> > pr
* Luca Boccassi:
> But the more I think about it, the more I am convinced that the
> default option working best for Debian is the one that matches the
> project's choice of a filesystem layout. After all, this is
> configurable in the toolchain for a reason.
It's not really configurable. You
* G. Branden Robinson:
> Perhaps the thing to do here is have, , yet another command-line
> option for GCC. The Ada language did something similar a couple of
> decades ago to tighten up the language for hard real-time demands, with
> what it called the "Ravenscar profile".[1] That proved
TL;DR: I want to propose a GCC 14 change which will impact
distributions, so I'd like to gather some feedback from Debian.
Clang has disabled support for a few historic C features by default over
the last few releases. This mirrors a process that Apple has begun in
Xcode even earlier (perhaps
* Matthias Klose:
> Starting with GCC 8, the configury allows to encode extra features into the
> architecture string. Debian and Ubuntu's armhf (hard float) architecture is
> configured with
>
> --with-arch=armv7-a --with-fpu=vfpv3-d16
>
> and now should be configured with
>
>
* Aurelien Jarno:
> I have been looking at the corresponding instruction, this is:
>
> 2ed0 <__cpu_indicator_init@GCC_4.8.0>:
> 2ed0: f3 0f 1e fb endbr32
>
> This is an Intel CET instruction, and it seems your CPU doesn't support
> executing it. Anyway this shows that
* Drew Parsons:
> An upstream author has asked whether we know of tools or compiler flags
> to help catch problems mixing 64 and 32 bit integers, for instance
> catching implicit conversions, as in
>
>int64_t n = ...;
>for (int32_t i=0; i ...
>}
>
> There is
* Lucas Nussbaum:
> Hi Michael,
>
> On 22/11/20 at 15:32 +0100, Michael Banck wrote:
>> Hi Lucas,
>>
>> That looks like an ICE, shouldn't that be filed with gfortran?
>
> Usually my logic is: if there's only one similar failure, I file a bug
> against the affected package, rather than against
* Florian Weimer:
>> * Concern for mips, mips64el, mipsel and ppc64el: no upstream support
>>in GCC
>>(Raised by the GCC maintainer; carried over from stretch)
>
> I'm surprised to read this. ppc64el features prominently in the
> toolchain work I do (thou
* Paul Gevers:
> * Concern for armel and armhf: only secondary upstream support in GCC
>(Raised by the GCC maintainer; carried over from stretch and buster)
glibc upstream lately has trouble finding qualified persons to
implement security fixes for the 32-bit Arm architecture.
> * Concern
* Hideki Yamane:
> I've read systemd's vulnerability article [1] and then I have
> a question, do we have any plan to enable "-fstack-clash-protection"
> by default? I cannot find any discussion about it.
There's a bug report requesting a build flags change:
* Luke Kenneth Casson Leighton:
> that is not a surprise to hear: the massive thrashing caused by the
> linker phase not being possible to be RAM-resident will be absolutely
> hammering the drives beyond reasonable wear-and-tear limits. which is
> why i'm recommending people try
* Niels Thykier:
> armel/armhf:
>
>
> * Undesirable to keep the hardware running beyond 2020. armhf VM
>support uncertain. (DSA)
>- Source: [DSA Sprint report]
Fedora is facing an issue running armhf under virtualization on arm64:
* Roland McGrath:
I can't see why you think --as-needed is fundamentally wrong or unnecessary.
It is fundamentally wrong because -lfoo means I demand that the
initializers of libfoo.so run, whether or not I called anything in it.
So it's more like static linking. 8-)
IMHO, the current
* Matthias Klose:
On 21.11.2009 06:20, Florian Weimer wrote:
* Steve Langasek:
It's been suggested to me that it might help Debian move forward on this
issue if I provide some background on why Canonical has chosen to not regard
this issue as critical for Ubuntu.
My personal impression
* Steve Langasek:
It's been suggested to me that it might help Debian move forward on this
issue if I provide some background on why Canonical has chosen to not regard
this issue as critical for Ubuntu.
My personal impression is that Debian does not view this issue as
critical, either.
* Philip Ashmore:
* Philip Ashmore:
/*HERE*/enum { value = (wanted = guess) ? result : next_value_type::value
};
Not a bug. You need to implement your own conditional operator at the
template level to make this work. The version with ?: is not valid
C++
Not valid C++ ? My
Package: libstdc++6-4.3-dev
Version: 4.3.3-13
The program below reads the input file in blocks of 8191 bytes (as
shown by strace). There's probably a mistake somewhere because it
should use 8192 byte blocks. (8191 byte blocks tend to maximize
misalignment.)
Recompiling with g++-4.4 doesn't
* Modestas Vainius:
While apparently, VT can't be implemented differently (except \d+),
what about size_t etc. then? They all can be implemented as regexps
too the most simple being 'any character'. However, in my opinion,
exact string matching is worthwhile to keep whenever possible.
Can't
* Florian Weimer:
I've asked the FSF for a clarification (the second time, the first
clarification resulted in the Java bytecode exception). Until we know
for sure how to interpret the exception, it's probably best not to
make GCC 4.4 the default compiler in sid/squeeze.
For the record, due
* Josselin Mouette:
Le vendredi 10 avril 2009 à 14:35 +0200, Florian Weimer a écrit :
At least with a strict interpretation, the run-time exception suffers
from a significant issue with compilers which are not licensed under a
GPLv3-compatible license (such as the GPLv2, or the QPL
Starting with version 4.4, the FSF the licenses the GCC run-time
library with a special exception:
| Under Section 7 of GPL version 3, you are granted additional
| permissions described in the GCC Runtime Library Exception, version
| 3.1, as published by the Free Software Foundation.
The
* Stéphane Glondu:
* The runtime (ocamlrun) is a pure C program, that can be compiled with
any C compiler. Customized runtimes (with functions implemented in C)
can be generated; in this case, a C file might be generated by
ocamlc{,.opt}, and this file is handled the same way as the
* Sylvain Le Gall:
But in Debian, we compile with GCC. And for the Int64 module,
functionality from libgcc2.c gets compiled into the binary. (This is
just the example I've verified.)
Int64 module is under LGPL + static link exception (and everything
related to runtime library). Does it
* Sylvain Le Gall:
byterun/ints.c, function caml_int64_div, the I64_div macro. This is
expanded into a plain division operator, and that is compiled into a
run-time library call by GCC.
I64_div is a function defined either in byterun/int64_emul.h o
byterun/int64_native.h. Reading both
* Cyprien LAPLACE:
This is still undefined. If you need machine address arithmetic, you
should use uintptr_t and hope for the best.
Does it mean that the loop indexed on an integer should become an
infinite loop ?
Not necessarily. However, the compiler may assume that foo() performs a
* Cyprien LAPLACE:
Hum, well .. another sample test:
/* c.c */
extern void func(void*);
void test()
{
register char (*foo)[32] = (typeof(foo))0-1024;
register int index;
for(index=0;index1024;index++) {
func(foo++);
}
}
This is still undefined. If you need
* Jason Kraftcheck:
The same syntax is accepted by the only other C++ compiler I have
access too: Sun's. I guess what I don't understand is why, if I
create a temporary by explicitly calling the copy constructor, that
temporary is treated as an rvalue.
The standard says so in section 3.10
* Pierre Habouzit:
Isn't it risky for partial upgrades from etch ? Shouldn't we wait for
lenny+1 to revert this ?
I second that, please don't revert the patch until lenny+1. FWIW I
believe the release team as a whole wanted the patch to be kept as well,
but I'll let the other members
Would anyone from the GNAT/Ada package maintainers be willing to take
over ada-reference-manual?
The package needs a major update for Ada 2005. It also doesn't meet my
personal standards for inclusion in main anymore because the documents
are generated by a non-free compiler (for which source
severity 447143 important
thanks
This bug is rather annoying because it breaks builds. Shall I upload
the patch from this bug report?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
There's a patch for GCC 4.1 (sorry, need to dig out the details) which
improves performance on Pentium 4s and Xeons (without adversely
impacting Opterons). Has this patch been applied to Debian's gcc-4.1
package? I couldn't find it in the Debian changelog.
--
To UNSUBSCRIBE, email to [EMAIL
* Drake Wilson:
extern int foo(int x);
int bar(void) { return foo(32); }
On i386 this compiles to
pushl %ebp
movl%esp, %ebp
subl$8, %esp
movl$32, (%esp)
callfoo
leave
ret
which doesn't correctly convert
* Martin Michlmayr:
Does help to compile it with -fwrapv ?
No.
Then it's a real bug in -fwrapv support, I guess. Without -fwrapv,
all bets are off AFAICS because the example code results in signed
integer overflow.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
* Joey Hess:
- Debian's userland has *always* supported at least the previous major
kernel version, and most often the previous two, or sometimes I
think, three major kernel versions.
This isn't a real argument, IMHO, because upstream no longer releases
major kernel versions.
OTOH,
* Steinar H. Gunderson:
-frepo is an optimization switch, designed to avoid multiple instantiations
of the same template (reducing its size). You should be able to compile just
fine without it, but your binaries will be bigger.
Thanks to the .gnu.linkonce sections, the finaly binary should be
A recent GAS update changed the length of this instruction:
adc 0(%ebx,%ecx,4),%edx
Previously, it was encoded as a four-octet sequence, now it's
equivalent to:
adc (%ebx,%ecx,4),%edx
-- which only needs three octets.
Is there a way to force the old behavior, without inserting nops?
(If
* Nathanael Nerode:
In gcc-3.4 and gcc-4.0, these functions have been replaced with out-of-line
functions, implemented in libstdc++.
Do these out-of-line functions avoid the LOCK prefix overhead on
non-SMP systems or, at least, non-threaded programs (for example,
using some dynamic linker
* Victor Hsieh:
std::basic_stringunsigned char ustr;
You have to provide an explicit specialization of
std::char_traitsunsigned char before you can use std::basic_string
like that. This means that your program is invalid.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
GCC support the D language with GDC
(http://home.earthlink.net/~dvdfrdmn/d). Can the debian package be built
with GDC ?
Will the D front end be converted to the tree-ssa framework?
Otherwise it's going to be obsolete in the forseeable future.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
* Fabrice LORRAIN:
Installing the full gcc suite on a sarge box, I discover that gnats-3.n
conflicts with all the preceding version.
I suppose you mean GNAT, not GNATS.
Is there a particular reason for that ? I didn't find the
information greping the changelog.
All those packages provide
Package: gcj-3.4
Version: 3.4.1-5
Severity: grave
Justification: renders package unusable
Invoking gcj-3.4 always fails:
$ gcj-3.4 --main=HelloWorld HelloWorld.java
gcj-3.4: libgcj.spec: No such file or directory
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy:
* Matthias Klose:
The following notes are added the 3.3 package descriptions:
What about the std::string ABI change in libstdc++6? This isn't
fixable by symbol versioning and can cause problems if empty strings
are passed across shared library boundaries.
* Justin Pryzby:
st7ctl.h:void drift();
This is not a prototype. In C, prototypes for function taking zero
parameters look like this:
st7ctl.h:void drift(void);
The reason is compatibility with KR C.
(Does anybody know to which bug trackers Justin's message was sent?
Isn't
Would someone please forward my message to
[EMAIL PROTECTED]?
SourceForge no longer accepts mail from me, without a meaningful error
message.
Are there any plans how handle the next C++ transition, and when to
start it?
--
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: atlas.cz, bigpond.com, di-ve.com, hotmail.com,
netscape.net, postino.it, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr.
Gregory Seidman [EMAIL PROTECTED] writes:
On Fri, Apr 30, 2004 at 01:31:53PM +0200, Florian Weimer wrote:
} Are there any plans how handle the next C++ transition, and when to
} start it?
Is there one on the horizon? I thought the 3.x series was maintaining
binary compatibility throughout
Daniel Jacobowitz [EMAIL PROTECTED] writes:
The soname of libstdc++ changed upstream from 3.3. and 3.4, and the
compiler implements a somewhat different flavor of C++ (it's much
closer to the standard now).
However, with symbol versioning and shared libgcc implemented in both
3.3 and 3.4, I
Package: gnat-3.4
Version: 3.4.0-1
Severity: normal
gnatchop invokes /usr/bin/gcc instead of /usr/bin/gcc-3.4:
/usr/bin/gcc -c -x ada -gnats -gnatu tmp.ada
gcc: installation problem, cannot exec `gnat1': No such file or
directory
-- System Information:
Debian Release: testing/unstable
APT
Preben Randhol [EMAIL PROTECTED] writes:
What do you mean? That it is a bad idea at the moment as nothing is
stable or that it is a bad idea whenever? I don't agree with the
latter.
What do you propose? Upstream is still at the beginning of shared
library support. They use rpath and have a
Matthew Wilcox [EMAIL PROTECTED] writes:
I confess to having made an omission when drawing up the gcc-3.2
transition plan. I concentrated on C++ and completely ignored other
languages. I do not know what (if anything) nees to be done for Java
or Fortran. However, I've done a small amount
I'm going to recompile the existing Ada packages in Debian using GNAT
3.15p, at least on x86.
This involves the following steps:
- Packaging GNAT 3.15p (mostly done). I'm going to omit DSO support
(see below).
- Fixing the FTBFS errors of current Ada packages (not necessarily
Miah Gregory [EMAIL PROTECTED] writes:
This concerns me a little. It seems to my untrained eye that this change
would mean that we're sacrificing large amounts of space in packages
compiled with GNAT, just to save rebuilding those packages when a new
version of GNAT is uploaded? Given that
Matthew Wilcox [EMAIL PROTECTED] writes:
On Sun, Mar 02, 2003 at 11:33:18AM +0100, Florian Weimer wrote:
Please drop shared library support altogether. It is currently not
worth the trouble. GNAT ABIs change from version to version, and the
run-time library can be built only
[EMAIL PROTECTED] (Jérôme Marant) writes:
Florian, I don't agree. I understand your arguments but honestly,
there is no more than one ACT release per year. So people don't
have to often rebuilt their programs and libraries.
I've looked at a few packages which would need DSOs and I came to the
Matthias Klose [EMAIL PROTECTED] writes:
Usually Florian keeps an open eye on gnat. AFAICR 3.14 passes an Ada
validation suite, which 3.15 does not yet pass (please correct me if I
am wrong). Therefore nobody packaged 3.15 yet.
I believe that it is reasonable (even desirable) to replace 3.14p
Joakim Olsson [EMAIL PROTECTED] writes:
Is there a simple solution out there ??? please tell me.
I think this bug will be fixed in GCC 3.3, at least I cannot reproduce
with GNAT from the GCC mainline.
Phil Edwards [EMAIL PROTECTED] writes:
Here's upstream's position on using GraphViz:
http://gcc.gnu.org/ml/gcc/2002-02/msg00946.html
Find me a libre tool that produces output as nice as dot's, and that
Doxygen knows how to work with, and I'll use it.
Yours truly,
Upstream
;-)
But
[EMAIL PROTECTED] (Martin v. Loewis) writes:
Florian Weimer [EMAIL PROTECTED] writes:
But using GraphViz, even in this way, is not consistent with FSF
policies--so it would be rather easy to force you to change it,
theoretically speaking.
Can you explain which FSF policy
Matthias Klose [EMAIL PROTECTED] writes:
-rw-r--r--1 willywilly 1884666 Nov 14 09:26
gcc-3.2_3.2.1ds5-0pre6.diff.gz
the big diff is the pregenerated libstdc++ documentation. The pages
are generated using doxygen and graphviz. Unfortunately graphviz is in
non-free ...
We could
Fruhwirth Clemens [EMAIL PROTECTED] writes:
- gnat-3.2 is required by gcc to build. It looks like gcc build
correctly with gnat-3.14p-3 of woody, so this could be probably
relaxed to 'gnat (=3.14p-3) | gnat-3.2'
I think this change is reasonable.
After all, all bets are off with GNAT 5.0
[EMAIL PROTECTED] (Jérôme Marant) writes:
The current gnat (3.14p) has passed validation tests
This is not correct. The Debian version hasn't passed *any*
validation tests.
and it is the latest stable release of gnat.
It is the latest public ACT release.
And it is likely to be official
Phil Brooke [EMAIL PROTECTED] writes:
What I'm really after here is some advice on where things might go with
the packages I'm considering.
GNAT 3.14p and GNAT in GCC 3.2 are not ABI compatible. GNAT in GCC
3.2 is not complete, ASIS and GLADE are missing. GNAT in GCC 3.2 has
bugs which
[EMAIL PROTECTED] (Jérôme Marant) writes:
This is not correct. The Debian version hasn't passed *any*
validation tests.
I don't get it. The debian package is built from the ACT
source.
Yes, but it links against a different libc version. This *can* make a
difference, especially in
Florian Weimer [EMAIL PROTECTED] writes:
Matthias Klose [EMAIL PROTECTED] writes:
[ARM]
well, it's not included in the gcc source. Not sure where Sam got this
manual ... Sam?
Someone converted in from the Scribe version, either Sam himself or
Laurent Guerby.
Laurent Guerby did the work
it.
It should be in the changes.html document for GCC 3.1.
--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT +49-711-685-5973/fax +49-711-685-5898
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED
Brian May [EMAIL PROTECTED] writes:
What is the upstream address?
Please read http://gcc.gnu.org/bugs.html . Submitting bugs via GNATS
(mind the S ;-) is the preferred method.
--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart http://CERT.Uni-Stuttgart.DE
part. I was extrapolating from a previous failure on
a broken installation.
--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT +49-711-685-5973/fax +49-711-685-5898
--
To UNSUBSCRIBE
Jochen Voss [EMAIL PROTECTED] writes:
there seems to be a mistake in the short package description
of libstdc++4. It reads
Description: The GNU stdc++ library version 3
where it should read ... version 4.
Why do you think so? GCC 3.1 was released with libstdc++ 3.1.
--
To
[EMAIL PROTECTED] (Jérôme Marant) writes:
I've read in the gcc ML that versioning libgnat as 3.15a
is erroneous, according to Robert Dewar.
It's still in the GCC CVS...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
71 matches
Mail list logo
