crash went away.
Here is the fix. It tests whether __thread actually works, not only whether
it is syntactically valid for the compiler. I have already submitted
copyright assignment papers for GCC.
2006-11-07 Bruno Haible <[EMAIL PROTECTED]>
* config/tls.m4 (GCC_CHECK_TLS):
Andrew Pinski wrote:
> > 2006-11-07 Bruno Haible <[EMAIL PROTECTED]>
> >
> > * config/tls.m4 (GCC_CHECK_TLS): Also check whether the libc supports
> > TLS via __thread.
>
> How well does this work with cross compiler?
The proposed patch changes on
l storage... no
in the situation of bug #28468.
2006-12-17 Bruno Haible <[EMAIL PROTECTED]>
* config/tls.m4 (GCC_CHECK_TLS): Also check whether the libc supports
TLS via __thread.
--- config/tls.m4.bak 2006-12-04 12:13:07.0 +0100
+++ config/tls.m4 2006-12
Paul Eggert wrote:
> Compiling everything with -fwrapv is simple. It has
> optimization drawbacks, but if that's the best we can do
> now, then we'll probably do it. And once we do it, human
> nature suggests that we will generally not bother with the
> painstaking analysis needed to omit -fwrapv
Hi,
The gcc docs say:
`-fwrapv'
... This flag enables some optimizations and disables others.
-fwrapv turns some undefined behaviour (according to C99) into well-defined
behaviour, therefore it is obvious that it can disable some optimizations.
But the other way around? Without -fwrapv t
Richard Kenner wrote:
> (3) How many programs are known to rely on wrap semantics? For each:
> (a) How hard was it to determine there was a problem with that
> assumption?
A piece of data for GNU clisp and cln:
- For clisp, it was easy to find out and fix all problems, because the
instead "-m 10",
- the hash function accesses 2 bytes of the input string (instead of 3),
- the hash table size drops to 53 (instead of 79).
Find attached a patch that does this.
cp/ChangeLog:
2005-06-05 Bruno Haible <[EMAIL PROTECTED]>
* Make-lang.in ($(srcdir)/cp
it for me will have to do
$ rm -f cp/cfns.h java/keyword.h
and rebuild and commit these files.
ChangeLog:
2005-06-06 Bruno Haible <[EMAIL PROTECTED]>
* doc/install.texi: Mention requirement for gperf-3.0.1.
cp/ChangeLog:
2005-06-05 Bruno Haible <[EMAIL PROTECTED]>
Hi,
The minimum support library version of MPC for building GCC 10 is not
correct.
After downloading gcc-10-20191229.tar.xz and
$ cd gcc-10-20191229/gcc/doc
$ ./install.texi2html
$ xdg-open HTML/prerequisites.html
I installed
- gmp 4.3.2 - works,
- mpfr 3.1.0 - works,
- mpc 0.8.1 - fa
For discussions around programming languages, within GNU, but not specific
to a particular GNU package, there is now a mailing list
.
The subscription page is here:
https://lists.gnu.org/mailman/listinfo/language-experts
You are invited to join if you have extensive experience in this area.
Topi
"#pragma GCC diagnostic" has a few limitations, which make it unusable to
resolve warnings like this one:
Jim Meyering wrote in [1]:
> $ cat in.c
> int f (void) __attribute__ ((__warn_unused_result__));
> void g (void) { (void) f (); }
> $ gcc -Werror -c in.c
> cc1: warnings be
Hi,
In gcc 4.1.0 the syntax of gcc-internal format strings - as defined in
pretty-print.c - has been extended to support reordering of arguments
(through the %n$ syntax). Now the Swedish translator of gcc.pot would
like to make use of this feature, but the infrastructure is not yet in
place. Curre
Joseph S. Myers wrote:
> To be clear, gettext tools are used in two ways in building new releases:
>
> * xgettext is run to update gcc.pot and cpplib.pot.
>
> * GCC is built with --enable-generated-files-in-srcdir, which uses msgfmt
> to create .gmo files and copy them into the source directory
Hi,
As the long-term GNU gettext maintainer, I would suggest to remove the intl/
directory from the GCC distribution.
The effect for the users would be:
* On systems without glibc, users who want an internationalized GCC
installation would have to install GNU gettext first. Then the GCC
Iain Sandoe wrote:
> As a maintainer for GCC on a non-glibc system, I would:
>
> (a) welcome a more modern version of intl, wih the bug-fixes etc.
That's why we make releases of GNU gettext. The newest release is 0.21.
Find below the list of improvements in libintl that will be relevant to GCC.
David Edelsohn wrote:
> The broad list of systems supported by GCC requires effort, but is one
> of its advantages.
GNU gettext is supported on a wide list of systems as well. Before we make
a GNU gettext release, we test in on glibc systems, FreeBSD, NetBSD, OpenBSD,
macOS, AIX, Solaris, Cygwin,
Hi Iain,
> So, indeed, part of this is quite straight forward - we can amend the
> Makefile.def
> to specify that GCC should use gettext-runtime (it will be used if the
> directory is
> present, otherwise there will be no intl support).
>
> The tricky part is that we need to use the runtime ‘un
Eric Gallager wrote:
> personally I see removing
> the intl/ subdirectory as just one possible solution to the issue of
> its autoconf macros being outdated
The autoconf macros are only the smaller part of the problem. The bigger
part is the C code of libintl. [1][2]
Bruno
[1] https://gcc.gnu.or
Iain Sandoe wrote:
> Yes (
> # We can use an in-tree build of libintl.
> if test -f ifelse([$1],,[../gettext-runtime],[$1])/uninstalled-config.sh;
> then
>
> relative_builddir='ifelse([$1],,[${top_builddir}/..],[$1]/..)/gettext-runtime'
> . ifelse([$1],,[../gettext-runtime],[$1])/uninstalle
Paul Eggert wrote:
> > AC_CHECK_FUNC *should not* just probe for linkability of a symbol
>
> ... Autoconf cannot
> be expected to know every signature of every function in every library.
Clang will surely not acquire knowledge about "every library", right,
only about the C library according to
Hi,
I was asked to post a patch for a bugzilla PR to gcc-patches@. Two questions
regarding https://gcc.gnu.org/contribute.html#testing :
1) This web page says:
"For a normal native configuration, running
make bootstrap
make -k check
from the top level of the GCC tree (not the
Hi Jonathan,
Thank you for your answer.
> No, don't configure in the source directory:
> https://gcc.gnu.org/wiki/FAQ#configure
OK.
> And it hasn't been necessary to run 'make bootstrap' for years, just
> running 'make' does exactly the same thing now.
Actually, "make" works better than "make
Paul Eggert wrote:
> I'd rather just switch, as Debian has.
I'd go one step further, and not only
make the ABI transition without changing the canonical triplet,
but also
make gcc and clang define -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64
among their predefines.
Rationale:
* We want that a
Arsen Arsenović wrote:
> An alternative that I pondered was to teach the linker about some notion
> of "compatibility strings" that it would compare and reject if
> different, plus teaching the compiler how to emit those, plus teaching
> glibc to tell the compiler to emit those.. We could have key
Hi,
Here's a case of a function whose compilation with -O2 -g (the default with
autoconf) on Linux/x86 has slowed down by 67% since the 4.2.2 release.
$ time gcc -c -O2 -g -Wall sha512.c
Measured user time.
gcc 3.2.2 42.2 sec
gcc 3.3.6 71 sec
gcc 3.4.4 29.0 sec
gcc
> Was it configured with --enable-checking=release?
No it wasn't.
Bruno
Dear Ian,
A comment regarding the GCC-in-C++ idea. In slide 16 you merely answer
"C++ is too complicated!"
with
"Maintainers will ensure that gcc continues to be maintainable."
C++ has, for example, 12 different ways to represent or invoke a function.
It has no buikt-in typesafe "enum"s. S
Arnaud Charlet wrote:
> One possibility is to do what we do for Ada: have a style/coding checker
> built into the compiler (C++ front-end) as a special switch, and enable this
> switch during bootstrap, so that any such coding style violation is
> transformed
> into an error
Yes, this can be the
Gabriel Dos Reis wrote:
> There is a subset of C++ templates stable enough over the years, that can be
> used without fear, uncertainty and doubt.
Absolutely. Can you specify this "usable" subset of C++ templates formally?
That would be valuable advice for maintainers. So that maintainers can deci
Ian Lance Taylor wrote:
> Whether we use C or C++, we need to try to ensure that interfaces are
> easy to understand, that the code is reasonably modular, that the
> internal documentation corresponds to the code, that it is possible
> for new developers to write new passes and to fix bugs.
Fully
Joe Buck wrote:
> the ABOUT-NLS file in the top of the tree. It seems to be wildly out of date
Yes, it is from May 2003.
You find the newest official ABOUT-NLS file in the gettext-0.16.1 distribution
on ftp.gnu.org.
Bruno
31 matches
Mail list logo
