https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55203
--- Comment #24 from Romain Geissler ---
typo:
s/why the extra unused std::string wasn't used/why the extra unused std::string
wasn't diagnosed/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55203
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114394
--- Comment #5 from Romain Geissler ---
Hi,
Shall this be backported to release branches ?
Cheers,
Romain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88323
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Created attachment 57738
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57738&action=edit
Tentative patch
Hi,
Clang >= 18 now prin
++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
Following this bug on clang side:
https://github.com/llvm/llvm-project/issues/85656 where apparently clang folks
claim they fixed a mangling issue, I found out that clang >=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111057
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105562
--- Comment #28 from Romain Geissler ---
Ok it's clear. I haven't really played yet with sanitizers, I didn't know it
had these well known "issue" with creating more middle end false positive
warnings (I am used to them in LTO mode).
So I will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105562
--- Comment #25 from Romain Geissler ---
So it means we should rather go for "silencing" workaround from comment #19 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105562
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106238
--- Comment #10 from Romain Geissler ---
Hi,
It seems the reproducers from comment #1 and #5 don't happen anymore with gcc
13 or trunk. So it seems fixed.
Cheers,
Romain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107954
--- Comment #4 from Romain Geissler ---
In the latest agenda published
(https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3156.pdf) it seems that now
the next C revision has been delayed a bit.
At this point, is it known already if it will be o
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
Checking the source code, it seems that the underlying implementation of
generic_category/system_category message
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
Now that the -Woverloaded-virtual=1 is enabled by default with -Wall, the
following code raises warning while I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #31 from Romain Geissler ---
Ok thanks for confirming. I was about to ask for a deployment one of our
gcc-based toolchain in production containing the current gcc 13.1.1, I will
wait a bit that this patch lands in the gcc 13 branch t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #29 from Romain Geissler ---
Typo: If yes, given that you also maintain the gcc package in fedora 38
(https://src.fedoraproject.org/rpms/gcc/commits/f38), does it mean that
something built in some future up to date Fedora 38 won't ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109602
--- Comment #5 from Romain Geissler ---
Hi,
My intention was to try to raise upstream an issue that people packaging gcc
may hit in some cases. Gentoo has such a patch, but I also have a similar one
on my side since couple of years, it's only y
++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
I am wondering, would it make sense to import Gentoo's msgfmt patch ? In some
occasion, it seems that the build system of gcc/libstdc++ wrongly sets
LD_LIBRARY_PATH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106238
--- Comment #7 from Romain Geissler ---
Another case in real life code base (in this case Boost):
https://github.com/boostorg/algorithm/pull/113
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106238
--- Comment #6 from Romain Geissler ---
Hi,
After upgrading to the latest gcc trunk, I have hit another variant of this
problem. For people just willing to exchange containers with swap, just
swapping the arguments makes it work, and actually h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #34 from Romain Geissler ---
>From what I wrote here
https://sourceware.org/pipermail/libc-alpha/2022-November/143633.html
apparently I already tried gcc 12 back in end of november 2022 and all float
issues in glibc testsuite were go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #32 from Romain Geissler ---
Hi,
Thanks for the fix, indeed it has fixed quite some glibc maths tests ;)
FYI, most likely it's totally unrelated to this bug, for right now with latest
gcc trunk and glibc trunk on x86-64, I still se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108374
--- Comment #1 from Romain Geissler ---
I forgot to mention: this happens on x86-64 with -O1.
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
The following snippet produces an unexpected -Wstringop-overflow with gcc 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106238
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
--- Comment #3 from Romain Geissler ---
In my real life case B was std::string and used a "string literal" at call
site, and I guess using the implicit conversion from const char[] to
std::string is something that might happen in many call sites
++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
The following snippet issues a wrong -Wdangling-reference warning when compiled
with -Wall with current gcc trunk:
<: In function 'const A& g(const A&)&#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108077
Romain Geissler changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
erity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
I can't build llvm 15 with the current gcc 13, while it was working a few weeks
ago.
I tried to re
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
I raise this ticket (I agree not very important, and more a feature request
than a bug) following a similar one on C++/clang side and a remark from Aaron
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
While trying to rename an enum from one name to another in an existing
framework, I try to use the following mechanism that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100630
--- Comment #5 from Romain Geissler ---
Hi,
Thanks for providing a fix that quickly !
I backported it in my own copy of gcc 8 and 9 and it fixed my issue on these
branches as well.
Cheers,
Romain
NFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
I came across this issue today (which I think is unexpected) with gcc 8, 9 and
10. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93821
Romain Geissler changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465
--- Comment #3 from Romain Geissler ---
I have found another example in my code base raising this error:
#include
std::string f1()
{
std::string aString = "string";
aString = "bigger str";
return aString;
}
With: -O2 -std=gnu++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465
--- Comment #2 from Romain Geissler ---
Hi Martin,
Thanks for your investigation.
I have a few questions:
- Since the warning seems to be fully emitted by system headers, shouldn't it
be silenced by default ? Why isn't it the case here ? On co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98463
--- Comment #3 from Romain Geissler ---
Hi,
While I initially flagged this as a regression in gcc 11, it's indeed a latent
gcc bug which predates gcc 11. What makes it for my specific test case a
regression is because now tuple use [[no_unique_a
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
The following C++ code compiled with -std=gnu++20 -O2 -Werror=stringop-overread
emits a bogus warning
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
The following C++ code fails to compile with gcc trunk but works on gcc 9 and
10 (tested on
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Hi,
I would like to report a regression in trunk which for me result in glibc
segfaulting in the dynamic linker at the very
NCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
I am using the trunk from today (8th november, gi
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
When trying to ignore some uses of null object which apparently are done on
purpose in Boost::concept, I noticed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96291
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96003
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92484
Romain Geissler changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326
--- Comment #28 from Romain Geissler ---
Hi David,
Do you have plans to submit this patch for review when stage 1 of gcc 11 opens
?
Cheers,
Romain
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
It looks like "if" blocks without curly braces cannot be surrounded by pragma
d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94335
--- Comment #4 from Romain Geissler ---
Thanks Richard.
Indeed, beyond the false positive described in this bug, our whole code that
implement "relative pointer" is I think quite hacky and not very compiler
friendly (around alignment, aliasing r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94335
--- Comment #2 from Romain Geissler ---
Thanks for the explanation.
However few observations:
- Is it really expected that the wording of the warning seems to imply gcc
knows for sure that there is an invalid access ? What is the warning meant
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
The following code emits a false positive -Wstringop-overflow warning with gcc
trunk with -O2 and -O3.
It's reduced manually from a much
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
This snippet started to fail recently with gcc trunk. Note, it was working fine
with "g++ (GCC) 10.0.1 20200305", and it
ormal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
With gcc trunk the following fails, while it was working with gcc 8 and 9. I
think (but am not sure) the imp
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Hi,
When LTO
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
The following snippet fails with gcc trunk and with gcc 9 if I compile with
-std=gnu++20, but not with -std=gnu
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
Quite simple (and not important) "bug" report, recently Jason added the support
of -std=c++20 (instead of -std=c++2a), but it looks like the gnu co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92267
--- Comment #10 from Romain Geissler ---
Ok, I was not sure whether it was more important to have a given major branch
(ie all gcc 9 releases) consistent or favor compatibility with the biggest
number of gcc releases (cross branches). You replied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92267
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80922
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93821
--- Comment #2 from Romain Geissler ---
You may have misunderstood my intentions here. I was just trying to suggest a
change which I think is better for the consistency with the standard and with
clang which just implemented this change.
So yes
++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
A few hours ago the clang folks did add explicit support for the flag
-std=c++20, and not only did they change that, they also changed the value of
__cplusplus to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93017
--- Comment #5 from Romain Geissler ---
Ah actually I see this on branch gcc 8 as well, with ISL 0.21. And apparently
it is not making "make check" return an error code, so it's very possible that
I had this error before without noticing it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93017
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47857
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
The following snippet fails to build with clang >= 8 using libstdc++ >= 8.1.0:
#include
c
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
The following snippet is accepted by clang but reject by gcc (any version I
tested: 8, 9, and trunk):
class A
{
// Maybe unused to silence clang error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92484
--- Comment #2 from Romain Geissler ---
Yes this is what I did, I reverted back to ISL 0.21 which for me has been
working for the past months (don't know if it's a recommanded version though).
Shall we keep this bug open to track the upcoming su
: other
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
ISL 0.22 was released recently, and I tried to use it in builds of gcc 8, 9 and
10. It fails on all these three branches will millions of error, the first ones
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92063
--- Comment #1 from Romain Geissler ---
Python code is here:
https://github.com/python/cpython/blob/v3.7.4/Python/_warnings.c#L753
#define ascii_lower(c) ((c <= 127) ? Py_TOLOWER(c) : 0)
/* if filename.lower().endswith(".pyc"): */
10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
I have an ICE in gcc 10 when trying to setup a GNU tool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84579
--- Comment #10 from Romain Geissler ---
Ah thanks, I had backported this one as well, but not the one you mentionned:
commit 217597acb2493b727255b66cd199fafa065427b7
Author: marxin
Date: Wed Jul 24 07:00:48 2019 +
Fix off-by-one in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84579
Romain Geissler changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
After a bug report opened to lld here
https://bugs.llvm.org/show_bug.cgi?id=42030, lld folks rejected it as invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84579
--- Comment #6 from Romain Geissler ---
Hi,
After trying to build our own set of open source components with this patch
(among the sqlite, openssl, boost, tcmalloc), we have no link issues resulting
from this change. Tested with gcc 8 and gcc 9.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84579
--- Comment #5 from Romain Geissler ---
Hi,
Your patch applies cleanly to both gcc 8 and 9. I was able to bootstrap two
toochains gcc 8 and 9 with it, however it caused regression in the binutils
testsuite:
FAIL: ld-plugin/lto-3r
FAIL: ld-plugi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84579
--- Comment #3 from Romain Geissler ---
Hi,
@Martin (and @Richard), I have seen you submitted this patch
https://gcc.gnu.org/ml/gcc-patches/2019-07/msg01059.html which I guess would
fix this bug. If accepted in gcc 10, do you think it is safe to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84579
--- Comment #2 from Romain Geissler ---
Hi,
@Martin (and @Richard), I have seen you submitted this patch
https://gcc.gnu.org/ml/gcc-patches/2019-07/msg01059.html which I guess would
fix this bug. If accepted in gcc 10, do you think it is safe to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84561
--- Comment #5 from Romain Geissler ---
Hi,
With the new release of gcc 9, I am seeing new occurences of this issue. I am
trying to put a statement _string[len] = 0; after the strncpy to silence the
warning, but still it triggers sometimes. Is t
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
It looks like doing things like __builtin_strncmp(someString, "A\0", 2)
: UNCONFIRMED
Severity: normal
Priority: P3
Component: libbacktrace
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
CC: ian at gcc dot gnu.org
Target Milestone: ---
Hi,
I am trying to build and test gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57193
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87716
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
In today's release announcement
https://gcc.gnu.org/ml/gcc/2019-05/msg00024.html C++17 is now marked as no
longer experimental in gcc 9. Suppor
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
The following snippet started to be rejected between:
g++ (GCC) 8.3.1 20190225
and
g++ (GCC) 8.3.1 20190331
, only when using -std=gnu++17). Clang 8
verity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
The change introduced in r266380 makes newer gcc >= 8.3 and gcc 9 sometimes
incompatible with obj
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749
--- Comment #15 from Romain Geissler ---
Thanks for these remarks.
FYI, what I am following are the Linux From Scratch guidelines, which build the
initial gcc like this (with both c and C++ support, disabling libstdc++ build):
http://www.linuxfr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749
--- Comment #9 from Romain Geissler ---
This may be some naive question, but if we are currently trying to build a
libstdc++, shouldn't we assume there is no pre-existing libstdc++ and run the
different checks in the configure script either with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749
--- Comment #8 from Romain Geissler ---
Your patch is working.
I may add some context to better understand this strange scenario. In my case,
the config log says:
configure:80434: checking for utimensat
configure:80484: x86_64-1a-linux-gnu-g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749
--- Comment #5 from Romain Geissler ---
Note that it was building fine with gcc commit
4a4bec8257aa255cca9be7f24a61159cadb36942 from Fri Dec 28 (aka r267451), and the
same glibc commit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749
--- Comment #4 from Romain Geissler ---
Thanks I will test this ASAP.
I am using x86-64, and a very recent glibc near current master:
GLIBC_VERSION="2.28.90"
GLIBC_COMMIT="0253580a75decdaf22b6abce60d8265b2adb7dea"
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
With the latest move of libstdc++fs.so in libstdc++.so, I am seeing these new
build errors:
/workdir/src/gcc-9.0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84436
--- Comment #13 from Romain Geissler ---
Apparently the clang-tlbgen failures started with r265241. Checking if it still
happens on gcc trunk with r265463 reverted.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84436
--- Comment #12 from Romain Geissler ---
Hi,
I have tried the following script directly inside docker using the official
"debian:buster" docker image, so I hope it will not require much more
dependencies than what is written here.
Tested with x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84436
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
mal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
Today gcc always generates an error when you use a dynamic exception
specification with some exception. However I wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87822
--- Comment #10 from Romain Geissler ---
Thanks for the quick patch !
If no commit is planned in the branch 6, I am going to apply this patch on top
myself. I hope people do read the release notes to figure out about this
potential ABI breaking.
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
I am having core dumps when mixing libraries built with gcc 6.4.1 and the final
gcc 6.5.0 (I know gcc 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87780
--- Comment #5 from Romain Geissler ---
Hi,
Trying with today's trunk with this patch included, my clang PGO+LTO bootstrap
goes further, but then the generated clang fails to compile itself. Just
putting here the clang error for reference:
fata
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87428
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
1 - 100 of 153 matches
Mail list logo
