vance_one_utf8_char, unicode_space,
> unicode_digits, unicode_letters, Lex::is_unicode_space, etc. But you
> probably won't be able to use the code directly, and the code in the
> gofrontend directory is also shared with GoLLVM so it can't trivially
> be moved.
>
I believe the UTF-8 handling for the C family front ends is all in libcpp;
I don't think it's factored in a way to be useful to other front ends.
Jason
;
> > #endif
> >
> > Who is supposed to define abort here optionally? Can this be defined for
> > example by a target configuration header like gcc/config/rtems.h?
>
> I suppose for inhibit_libc we could use __builtin_trap () (but that might
> expand to abort() on some targets)
That seems straightforward. Does it address the RTEMS concern?
Or, should we suppress ENABLE_RUNTIME_CHECKING when inhibit_libc?
Jason
ary? Are there interesting targets that don't have a trap insn?
> 3. Add a new target hook for the gcc_assert() failure. This has the same
> problem as 2. with respect to customization by system and not architecture.
>
> 4. Disable gcc_assert() if inhibit_libc is defined.
>
> 5. Use builtin __rtems__ define in tsystem.h as a hack.
6. Suppress ENABLE_RUNTIME_CHECKING when inhibit_libc.
Jason
html
Let us know if anything is unclear.
Jason
t; }
>
Neither return should involve a copy, you don't need any extra annotation.
Jason
benefit GCC, but the case
> against std::unordered_map is often overstated.
>
> If the question was whether to prefer std::unordered_map or
> absl::node_hash_map then I would agree that std::unordered_map is a
> bad choice. But that's not the question.
>
Generally we want to use the GCC hash_map because it works with GCC garbage
collection (and PCH). Is that not relevant to your patch?
Jason
fixes the
libstdc++ test FAILs.
However, after discussing this briefly with Jason it occurred to us
that if the user declares an 'int main()' function, it's a pretty big
hint that they do want main() to return an int. And so having
undefined behaviour do to a missing return isn'
On 10/7/22 07:30, Jonathan Wakely wrote:
On Tue, 4 Oct 2022 at 23:25, Jason Merrill wrote:
On 9/28/22 16:15, Jonathan Wakely wrote:
As part of implementing a C++23 proposal [1] to massively increase the
scope of the freestanding C++ standard library some questions came up
about the special
On 10/4/22 11:11, Ben Boeckel wrote:
This patch adds initial support for ISO C++'s [P1689R5][], a format for
describing C++ module requirements and provisions based on the source
code. This is required because compiling C++ with modules is not
embarrassingly parallel and need to be ordered to ens
On 10/4/22 11:12, Ben Boeckel wrote:
This patch implements support for [P1689R5][] to communicate to a build
system the C++20 module dependencies to build systems so that they may
build `.gcm` files in the proper order.
Thanks!
Support is communicated through the following three new flags:
-
On 10/13/22 13:02, Arsen Arsenović wrote:
Hi,
On Friday, 7 October 2022 15:51:31 CEST Jason Merrill wrote:
* gcc.dg/noreturn-4.c: Likewise.
I'd be inclined to drop this test.
That seems like an odd choice, why do that over using another function
for the test case? (there'
On 10/13/22 16:14, Arsen Arsenović wrote:
On Thursday, 13 October 2022 19:24:41 CEST Jason Merrill wrote:
I was arguing that we don't need the new flag; there shouldn't be any
need to turn it off.
At the time, I opted to go with a more conservative route; I haven't
been around
On 10/14/22 06:04, Arsen Arsenović wrote:
On Thursday, 13 October 2022 23:16:02 CEST Jason Merrill wrote:
I liked in the previous version that you checked the return type of
main when !flag_hosted, here and in c_missing_noreturn_ok_p. Let's
bring that back.
Ah, right; I forgot about
On 10/19/22 04:40, Jakub Jelinek wrote:
Hi!
The screw-up on my side with libstdc++ testing (tested normally rather
than in C++23 mode) makes me wonder if we couldn't tweak the default
testing.
Dunno what libstdc++ testing normally does (just C++17?), make check-g++
tests by default { 98, 14, 17,
On 10/18/22 08:18, Ben Boeckel wrote:
On Tue, Oct 11, 2022 at 07:42:43 -0400, Ben Boeckel wrote:
On Mon, Oct 10, 2022 at 17:04:09 -0400, Jason Merrill wrote:
Can we share utf8 parsing code with decode_utf8_char in pretty-print.cc?
I can look at factoring that out. I'll have to decod
On 10/20/22 13:31, Ben Boeckel wrote:
On Thu, Oct 20, 2022 at 11:39:25 -0400, Jason Merrill wrote:
Oops, I was thinking this was in gcc as well. In libcpp there's
_cpp_valid_utf8 (which calls one_utf8_to_cppchar).
This routine has a lot more logic (including UCN decoding) an
ave a great day!
Done, thanks.
Jason
On 10/27/22 13:16, Ben Boeckel wrote:
Unicode does not support such values because they are unrepresentable in
UTF-16.
Signed-off-by: Ben Boeckel
---
libcpp/ChangeLog | 6 ++
libcpp/charset.cc | 4 ++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/libcpp/ChangeLog b/l
On 10/27/22 13:16, Ben Boeckel wrote:
This simplifies the interface for other UTF-8 validity detections when a
simple "yes" or "no" answer is sufficient.
Signed-off-by: Ben Boeckel
---
libcpp/ChangeLog | 6 ++
libcpp/charset.cc | 18 ++
libcpp/internal.h | 2 ++
3 fi
On 11/8/22 16:10, Ben Boeckel wrote:
This simplifies the interface for other UTF-8 validity detections when a
simple "yes" or "no" answer is sufficient.
libcpp/
* charset.cc: Add `_cpp_valid_utf8_str` which determines whether
a C string is valid UTF-8 or not.
* internal.
On 11/8/22 16:10, Ben Boeckel wrote:
Unicode does not support such values because they are unrepresentable in
UTF-16.
libcpp/
* charset.cc: Reject encodings of codepoints above 0x10.
UTF-16 does not support such codepoints and therefore all
Unicode rejects such value
ime options
elsewhere in the thread, but the #pragma idea sounds promising, as older
compilers can just ignore it.
Jason
Hi, thanks for your interest.
There are some ideas at https://gcc.gnu.org/wiki/EasyHacks
You might also look at Bugzilla PRs with a lot of interest, particularly
with severity of "enhancement". In the search results screen you can
display the number of CCs and duplicates using the "change column
ass" for
> any given type. (And then the convention would presumably be that a POD
> type is called "struct" and other types are "class".)
>
Yes, it might be worth adding -Wmismatched-tags to STRICT_WARN. Is
bootstrapping with VC++ is supported?
Jason
On 1/25/23 13:06, Ben Boeckel wrote:
Unicode does not support such values because they are unrepresentable in
UTF-16.
libcpp/
* charset.cc: Reject encodings of codepoints above 0x10.
UTF-16 does not support such codepoints and therefore all
Unicode rejects such value
On 1/25/23 13:06, Ben Boeckel wrote:
They affect the build, so report them via `-MF` mechanisms.
gcc/cp/
* module.cc (do_import): Report imported CMI files as
dependencies.
Both this and the mapper dependency patch seem to cause most of the
modules testcases to crash; please
prototype, this change seems unneeded.
{
make_write (pfile, fp, colmax);
}
+static void
+p1689r5_write_filepath (const char *name, FILE *fp)
+{
+ if (_cpp_valid_utf8_str (name))
+{
+ fputc ('"', fp);
+ for (const char* c = name; *c; c++)
+
I am pleased to announce that the GCC Steering Committee has appointed
Tobias Burnus as an additional OpenMP and libgomp maintainer.
Tobias, please update your listing in the MAINTAINERS file.
Cheers,
Jason
My patch for 106890 caused 109666, so I'd like to revert the 106890 patch
(r12-9441-g94569d91bd4c60) for 12.3.
Jason
On Tue, May 2, 2023 at 4:10 AM Richard Biener via Gcc
wrote:
> The first release candidate for GCC 12.3 is available from
>
> https://gcc.gnu.org/pub/gcc/sna
set, this (some C++ and a
> C89 requirement) must be exceedingly rare because it's a subset of the
> already tiny set of -fno-gnu89-inline -std=gnu89 packages.
Another reason for -fpermissive is ease of use. So if someone just
wants to get an older package to build, they can add -fpermissive
without having to figure out more detailed flags.
Alternatively, if we go the default -Werror=various route, adding
-Wno-error without any =foo to override everything might also be
fairly convenient.
In any case, I think we want an easy answer for the second group.
Jason
lar diagnostics from category 3 up to
category 2, both because code that relies on these patterns has gotten
less common and using these patterns by mistake has gotten more
harmful.
Jason
how you think this goal conflicts with your goal?
>
> Because now people will have to go through dozens and dozens of
> Makefiles, configure.in, *.m4
You shouldn't have to change any of those, just configure with CC="gcc
-fwhatever".
Jason
to upgrade all currently enabled pedwarns to errors without also
enabling pedwarns that depend on -pedantic/-Wpedantic;
-pedantic-errors does both; -Werror=pedantic makes only the latter set
errors, which seems unlikely to be useful to anyone.)
Jason
> is it in the interests of users for them to be errors by default (for C99
> > and later modes, in the cases that were valid in C89).
>
> Just to recap, those are controlled by
> -Wimplicit-function-declaration, -Wimplicit-int, -Wint-conversion, and
> -Wincompatible-pointer-types, roughly in increasing order of
> compatibility impact with old sources.
What would the impact be of making -Wint-conversion an error by
default only if the types are different sizes?
Jason
rming code is the
job of -pedantic(-errors).
Can you explain again why upgrading -Wint-conversion (instead of
-Wimplicit) isn't the right solution for catching these bugs? You
mentioned that this would need more changes to Fedora packages, but
wouldn't those cases also be fixing real bugs, unlike the changes needed to
avoid -Wimplicit in autoconf?
Jason
? If so, which GCC
> > version is expected to have this included?
>
> I wrote that prototype, but I haven't touched it since 2017, and I
> already have more than enough other work, alas. I'm happy to help if
> someone wants to pick up the work and finish it.
>
Maybe create a BZ and gcc.gnu.org/projects entry for this work?
Jason
t for Usenet-style flame wars like the one
he and you seem determined to start.
If you lead with "your work is bad and you should feel bad" that doesn't
tend to lead to constructive discussion.
Jason
.html ; for features not yet
implemented, the "No" links to the corresponding PR.
I definitely agree that we want the feature, but I don't expect to have
time to implement it myself for GCC 14. If you're interested in looking at
it, that's great! Please feel free to contact me with any questions.
Jason
oint it enough if you
> have the cycles.
I see the same thing with patch 4 on x86_64-pc-linux-gnu, e.g.
FAIL: g++.dg/modules/ben-1_a.C -std=c++17 (test for excess errors)
Excess errors:
/home/jason/gt/gcc/testsuite/g++.dg/modules/ben-1_a.C:9:1: internal
compiler error: Segmentation fault
On 5/12/23 10:24, Ben Boeckel wrote:
On Tue, Feb 14, 2023 at 16:50:27 -0500, Jason Merrill wrote:
I notice that the actual flags are all -fdep-*, though some of them are
-fdeps-* here, and the internal variables all seem to be fdeps_*. I
lean toward harmonizing on "deps", I think.
On 6/6/23 16:50, Ben Boeckel wrote:
Unicode does not support such values because they are unrepresentable in
UTF-16.
Pushed.
libcpp/
* charset.cc: Reject encodings of codepoints above 0x10.
UTF-16 does not support such codepoints and therefore all
Unicode rejects
On 6/17/23 10:43, Ben Boeckel wrote:
On Fri, Jun 16, 2023 at 23:55:53 -0400, Jason Merrill wrote:
I see the same thing with patch 4 on x86_64-pc-linux-gnu, e.g.
FAIL: g++.dg/modules/ben-1_a.C -std=c++17 (test for excess errors)
Excess errors:
/home/jason/gt/gcc/testsuite/g++.dg/modules/ben
I am pleased to announce that the GCC Steering Committee has decided
to adopt a Code of Conduct (https://gcc.gnu.org/conduct.html) for
interactions in GCC project spaces, including mailing lists, bugzilla,
and IRC.
The vast majority of the time, the GCC community is a very civil,
cooperative space
On 1/25/23 16:06, Ben Boeckel wrote:
They affect the build, so report them via `-MF` mechanisms.
Why isn't this covered by the existing code in preprocessed_module?
gcc/cp/
* module.cc (do_import): Report imported CMI files as
dependencies.
Signed-off-by: Ben Boeckel
---
On 1/25/23 16:06, Ben Boeckel wrote:
It affects the build, and if used as a static file, can reliably be
tracked using the `-MF` mechanism.
Hmm, this seems a bit like making all .o depend on the Makefile; it
shouldn't be necessary to rebuild all TUs that use modules when we add
another module
On 6/20/23 15:46, Ben Boeckel wrote:
On Tue, Feb 14, 2023 at 16:50:27 -0500, Jason Merrill wrote:
On 1/25/23 13:06, Ben Boeckel wrote:
Header units (including the standard library headers) are 100%
unsupported right now because the `-E` mechanism wants to import their
BMIs. A new mode (i.e
On 6/21/23 14:58, Ben Boeckel wrote:
libcpp/
* charset.cc: Allow `UCS_LIMIT` in UTF-8 strings.
Reported-by: Damien Guibouret
Fixes: c1dbaa6656a (libcpp: reject codepoints above 0x10, 2023-06-06)
Signed-off-by: Ben Boeckel
Applied, moving the Fixes line up and changing the commit
On 6/25/23 12:36, Ben Boeckel wrote:
On Fri, Jun 23, 2023 at 08:12:41 -0400, Nathan Sidwell wrote:
On 6/22/23 22:45, Ben Boeckel wrote:
On Thu, Jun 22, 2023 at 17:21:42 -0400, Jason Merrill wrote:
On 1/25/23 16:06, Ben Boeckel wrote:
They affect the build, so report them via `-MF` mechanisms
f a transitive
import changes you need to rebuild the direct import and then the importer.
I guess it shouldn't hurt to have the transitive imports in the -MF
file, as long as they aren't also in the p1689 file, so I'm not
particularly opposed to this change, but I don't see how it makes a
practical difference.
Jason
for this documentation.
Aaron noted that we should ask the Clang folks before using them, so they
> can evaluated whether the extension makes sense, since they might not be
> aware of them, and some might be broken. So I'd be interested whether you
> would also like us to ask whether you want to actually support these
> extensions.
>
Sounds good.
Jason
glibc. As I recall the glibc ld.so used
to have the behavior you seem to expect, but was deliberately changed
many years ago to the behavior you observe, I think for performance reasons.
Jason
oking for.
>
> I've now managed to dump the syntax tree of the compilation unit
> (tree_function_decl.saved_tree -> tree_exp.operands ->
> tree_statement_list.nodes). Thank you very much for the help!
>
> In order to print out the original code, I need to know which program
> code was translated to the individual nodes. Is there a chance to get
> the original tokens (or the offsets in the program code file) per
> tree_node without modifying the parser?
>
Generally we try to track the corresponding source location for a lot of
things and attach them to the relevant tree nodes (EXPR_LOCATION,
DECL_SOURCE_LOCATION). In many cases there is a lot of room for
improvement in this. For instance, for a class, instead of just storing
the location of the name, we could remember the range from the class-key to
the closing brace.
Jason
+507,117 @@ deps_write (const cpp_reader *pfile, FILE *fp, unsigned
int colmax)
make_write (pfile, fp, colmax);
}
+static void
+p1689r5_write_filepath (const char *name, FILE *fp)
This and the other p1689r5 functions need more comments, at least one at
the top explaining their purpose.
Jason
g the compiler directly.
Thanks,
--Ben
---
v7 -> v8:
- rename `DEPS_FMT_` enum variants to `FDEPS_FMT_` to match the
associated flag
- memory leak fix in the `join` specfunc implementation (also better
comments), both from Jason
- formatting fix in `mkdeps.cc` for `write_make_modules_d
ling, and it seems
appropriate to respect that.
I'm also (though less strongly) inclined to be permissive in C99 mode, and
only introduce the new strictness by default for C11/C17 modes.
Jason
Code Gen Options
> @section Options for Code Generation Conventions
>
> Maybe we should move them over there.
>
> But that wasn't really the direction of my question. I was wondering
> where we should document a future C version of -fpermissive.
>
My permerror patch proposes moving it to the Warning Options node, right
after -pedantic-errors.
Jason
tr` which determines whether
a C string is valid UTF-8 or not.
* internal.h: Add prototype for `_cpp_valid_utf8_str`.
Signed-off-by: Ben Boeckel
[going through patches in patchwork]
What's the status of this patch; did this ever get committed?
It was superseded.
Jason
ry is still the subject of research
and standardization efforts, though the current proposal (wg21.link/n4923)
is significantly simpler than the earlier TS that GCC implemented. I don't
know how much of the current implementation would carry over, but I'd be
cautious about tearing everything out just yet.
Jason
et))
I think we probably want the same formatting for lambdas in function
argument lists, e.g.
algorithm ([] (parms)
{
return foo;
});
Any other opinions?
Jason
On 1/10/24 15:59, Marek Polacek wrote:
On Wed, Jan 10, 2024 at 02:58:03PM -0500, Jason Merrill via Gcc wrote:
What formatting style do we want for non-trivial lambdas in GCC sources?
I'm thinking the most consistent choice would be
auto l = [&] (parms) // spac
On 1/10/24 16:41, Marek Polacek wrote:
On Wed, Jan 10, 2024 at 04:24:42PM -0500, Jason Merrill wrote:
On 1/10/24 15:59, Marek Polacek wrote:
On Wed, Jan 10, 2024 at 02:58:03PM -0500, Jason Merrill via Gcc wrote:
What formatting style do we want for non-trivial lambdas in GCC sources?
I&#
On 1/11/24 12:48, Martin Jambor wrote:
On Wed, Jan 10 2024, Jason Merrill via Gcc wrote:
What formatting style do we want for non-trivial lambdas in GCC sources?
I'm thinking the most consistent choice would be
auto l = [&] (parms) // space between ] (
{ // bra
ms inappropriate, as all clobbers
indicate that the target does not have a meaningful value at that point.
Probably better to use some front-end-local representation that gets
discarded by genericize.
Jason
wonder how much common code
> > there is
> > between the LLVM and the GCC tooling though and whether it makes sense
> > to keep it common (and working with both frontends)? The
> > pragmatic solution would have been to fork the repo on github to a
> > place not within the google group ...
>
> In tree would need convincing Google to assign the copyright.
Would it? Looks like it's under a free license (apache 2), not
everything in the tree is copyright FSF or GPL3.
Jason
rmine "fits the mailing list
> limits"? My mail UI (Thunderbird) doesn't show me the size of a message
> until I've actually sent it.
>
> > As a last resort
> > do a series splitting the re-generation out (but I guess this would
> > confuse the CI as well and of course for the push you want to squash
> > again).
>
> Yeah, unless the CI would only ever test full series, this wouldn't help.
> It's also imo even more cumbersome than simply stripping the generated
> file parts from emails.
>
Massive patches need special handling either way; I wouldn't lift the
mailing list limits because of this change.
I'm in favor of this change for typical patches.
Jason
ECL. And the comments say that the default values for parameters
> are encoded in the type of the function. But I can't find it.
The TYPE_ARG_TYPES of a FUNCTION_TYPE is a TREE_LIST where the
TREE_PURPOSE is the default argument.
Jason
echnology; people are more or less
comfortable with their current workflow and uninclined to experiment with
someone else's new thing, even if it could eventually be a big improvement.
I think that the office hours, for both sourceware and the toolchain, offer
a better path for building enthusiasm about a new direction.
Is gerrit still installed?
Jason
On Mon, Apr 22, 2024 at 11:24 PM Tom Tromey wrote:
> Jason> Someone mentioned earlier that gerrit was previously tried
> Jason> unsuccessfully.
>
> We tried it and gdb and then abandoned it. We tried to integrate it
> into the traditional gdb development style, having i
inkage, which allows
inlining.
Relatedly, I wonder if we want to build GCC with -fno-semantic-interposition?
Jason
On 4/30/24 12:22, Jakub Jelinek wrote:
On Tue, Apr 30, 2024 at 03:09:51PM -0400, Jason Merrill via Gcc wrote:
On Fri, Apr 26, 2024 at 5:44 AM Aldy Hernandez via Gcc wrote:
In implementing prange (pointer ranges), I have found a 1.74% slowdown
in VRP, even without any code path actually using
On 5/1/24 12:15, Jeff Law wrote:
On 4/22/24 9:24 PM, Tom Tromey wrote:
Jason> Someone mentioned earlier that gerrit was previously tried
Jason> unsuccessfully.
We tried it and gdb and then abandoned it. We tried to integrate it
into the traditional gdb development style, having i
On Tue, May 28, 2024 at 10:36 AM Paul Eggert wrote:
>
> On 2024-05-28 01:20, Jonathan Wakely wrote:
> > I am not aware of any distro ever changing the default -std setting for g++
> > or clang++. Are you attempting to solve a non-problem, but introducing new
> > ones?
>
> If it's a non-problem for
C++
> >> > version as that's more likely to hurt than help.
> >
> > Yes.
>
> OK, thanks, I installed the attached.
Thanks, though I don't think all that code needs to go;
AC_PROG_CXX_STDCXX_EDITION_TRY still looks useful for a project that
relies on features from a particular standard. We just don't want
AC_PROG_CXX to invoke it.
Jason
On Wed, May 29, 2024 at 1:34 PM Tom Tromey wrote:
> >>>>> "Jason" == Jason Merrill writes:
>
> Jason> Thanks, though I don't think all that code needs to go;
> Jason> AC_PROG_CXX_STDCXX_EDITION_TRY still looks useful for a project that
> Jason&
does not enable significant
optimizations. Any feedback about this?
Jason
On Thu, Jun 27, 2024 at 2:38 PM Richard Biener
wrote:
> > Am 27.06.2024 um 19:04 schrieb Jason Merrill via Gcc :
> >
> > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2434r1.html
> > proposes to require that repeated unspecified comparisons be
> > s
Since the RC I've fixed a few 14/15 C++ regressions with extremely safe
patches, and wonder what you think about pushing them to the branch at this
point:
115583, 115986, 115561
Sorry these came so late.
Jason
On Tue, Jul 23, 2024 at 8:51 AM Jakub Jelinek via Gcc
wrote:
> The first
On Mon, Jul 29, 2024 at 4:34 AM Richard Biener
wrote:
> On Sun, Jul 28, 2024 at 11:46 PM Jason Merrill via Gcc
> wrote:
> >
> > Since the RC I've fixed a few 14/15 C++ regressions with extremely safe
> > patches, and wonder what you think about pushing them to t
r or not embedding source files) (security concerns) are not technically
mutually exclusive. The fundamental technical problem may be that clang require
to open the actual file during the compilation. It looks like both GCC and MSVC
doesn’t have the problem.
Sounds like the primary motivation for this clang change doesn't apply
to GCC.
Jason
On 9/3/24 11:53 AM, Iain Sandoe wrote:
On 3 Sep 2024, at 16:08, Jason Merrill via Gcc wrote:
On 9/3/24 7:30 AM, Jonathan Wakely wrote:
On Tue, 3 Sept 2024, 10:15 Iain Sandoe, mailto:i...@sandoe.co.uk>> wrote:
Hi Folks,
When we build a C++ binary module (CMI/BMI), we obviousl
ably the
same, but I haven't been in its code myself to know.
Certainly these tools are complicated when the preprocessor output isn't
enough to reproduce the compilation. It might be nice to have some
combined preprocessed form of the primary translation unit and any
interface units it depends on...
Jason
ponse to a couple of different
patches that could have been simplified in C++14, but am failing to find
those messages now.
Jason
rting
instructions.
Jason
On 9/16/24 11:14 AM, Florian Weimer wrote:
* Jason Merrill via Gcc:
We moved to a bootstrap requirement of C++11 in GCC 11, 8 years after
support was stable in GCC 4.8.
Note that some documentation still says C++03, for example:
| The directories gcc, libcpp and fixincludes may use C++03
en making a lot of
improvements to GCC diagnostic output lately and is generally in charge of
diagnostics.
Jason
Thanks for the report! Please file it at
https://gcc.gnu.org/bugzilla/enter_bug.cgi?product=gcc
On Mon, Mar 10, 2025 at 10:47 AM Qwert Nerdish via Gcc
> wrote:
>
> > Correct link is https://godbolt.org/z/GfeTobMvs
> >
> > On Mon, Mar 10, 2025 at 4:45 PM Qwert Nerdish
> > wrote:
> >
> > > On thi
=i686 --build=i686-redhat-linux
--enable-serial-configure
Thread model: posix
gcc version 4.9.4 (GCC)
All other compiler components built fine except libjava .
I see in :
i686-redhat-linux/libjava/classpath/config.log :
configure:25378:
/home/adm-jason/rpmbuild/BUILD/gcc-releases-gcc-4.9
501 - 587 of 587 matches
Mail list logo
