https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71057
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71057
--- Comment #10 from Romain Geissler ---
Thanks ! The current gcc6 branch works fine now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71021
--- Comment #3 from Romain Geissler ---
Please note that this is the only target lib that fails for me. Others (like
libgomp) are fine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71021
--- Comment #2 from Romain Geissler ---
The very same thing happens with gcc 6.1.1.
: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Created attachment 38452
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38452=edit
Add "-pthre
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
I am having issues with code that used to build fine with gcc 4.9 and 5.3, but
doesn't work anymore with gcc 6.1.1 (20160725
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70977
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70977
--- Comment #10 from Romain Geissler ---
This is actually a dup of #70824 which was just fixed in trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71021
Romain Geissler changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71021
Romain Geissler changed:
What|Removed |Added
Resolution|FIXED |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72104
Romain Geissler changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78044
--- Comment #1 from Romain Geissler ---
Created attachment 39844
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39844=edit
test.i
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Created attachment 39843
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39843=edit
test.cpp
Hi,
I am having a fa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81976
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69725
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69725
--- Comment #19 from Romain Geissler ---
Note: don't forget to apply the gmp patch to the "configure" file too (wasted
some time myself because I did...)
++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
This simple snippet, when built with -fdump-lang-raw will ICE:
cat test.cpp
void f()
{
switch(1)
{
case 1:
break;
}
}
int i
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
I would to know if the following (currently not implemented) behaviour of
[[nodiscard]] would be useful or not. I am raising
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81577
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78063
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
NCONFIRMED
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 there is a regression in the Early VRP pass with -O2 th
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
When migrating some code base to gcc 8, I am hitting an issue on this snippet:
<
void f()
{
char aBuf[3 + 1];
strncpy(aBuf, "123", 3);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83955
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
As required in PR 84474, here is a more real life example of unexpected
-Wstringop-truncation. Let's
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
I can see some strange behavior for the warning -W=stringop-truncation with -O2
and current master, depending on how I enclose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84480
--- Comment #6 from Romain Geissler ---
Thanks ;)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84468
--- Comment #8 from Romain Geissler ---
I am currently testing a little variant of your patch (check that "nextbb" if
not NULL before trying to use it):
Index: gcc/tree-ssa-strlen.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84468
--- Comment #6 from Romain Geissler ---
Hi,
Tried to apply this patch on top of current trunk. During my build process, I
bootstrap a complete Linux/binutils/glibc/gcc toolchain following the Linux
From Scratch guidelines.
Without the patch,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84468
--- Comment #9 from Romain Geissler ---
Ok I was able to strip down the ICE to this very simple reproducer:
<
static char keyword[4];
static void f (void) { strncpy(keyword, "if ", 4); }
EOF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84480
--- Comment #1 from Romain Geissler ---
Hi,
I looked at the code. Actually all happens in tree-ssa-strlen.c, you have both
handle_builtin_stxncpy and maybe_diag_stxncpy_trunc. It happens that the logic
where you look at the next statement to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84468
--- Comment #3 from Romain Geissler ---
Ok there maybe a problem with the optimizer as you describe it in bug 84470.
However why does variant 3 from comment #0 yields a warning too ?
if (iCString)
{
strncpy(_cstring, iCString,
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
I have hit this case today. Let's consider that for any reason, you have a
wrapper around strncpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84468
--- Comment #13 from Romain Geissler ---
Hi,
It looks like that the code in #comment 11 works when you build just with -O2,
but not when you add debug symbols: -O2 -g. Do we have a way to ignore debug
statements when looking for the next
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84468
--- Comment #11 from Romain Geissler ---
Hi,
Indeed this version of the patch doesn't have any segv. However it seems that
it doesn't fix anymore the initial bug report. Does it actually passes the new
tests you introduced in your patch ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84555
--- Comment #1 from Romain Geissler ---
This example emits:
error: ‘char* __builtin_strncpy(char*, const char*, long unsigned int)’ output
truncated before terminating nul copying 3 bytes from a string of the same
length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84561
--- Comment #1 from Romain Geissler ---
Note: I am testing with gcc snapshot from 24th February + patch from PR 84468
manually applied (at least I think I did).
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
There is another -Wformat-truncation that I don't understand with -O2. It looks
like I may or may not get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84468
--- Comment #15 from Romain Geissler ---
Hi,
This latest patch seems to fix the occurences I have in my own code. Thanks ;)
Cheers,
Romain
rity: 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 trouble with this simple code snippet:
<
using pair_t = std::pair<int, int>;
using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67400
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81976
--- Comment #2 from Romain Geissler ---
Hi,
Note that in the meantime, this was fixed on trunk (gcc 8). I don't know when,
but it was fixed between December 2017 and now, and don't know with which
commit.
Cheers,
Romain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84670
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84601
--- Comment #2 from Romain Geissler ---
Hi,
FYI, I confirm that the patch you posted here
https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01578.html fixes my real test
case from which I extracted the reproducer from comment 1.
Cheers,
Romain
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 you want to build a project where for some reason you want to use fat LTO
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
There appear to be a recent regression, triggered when compiling tcmalloc. This
snippet:
#include
// A safe way of doing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84727
--- Comment #1 from Romain Geissler ---
Mmmh on Godbolt it seems to work with the gcc from today:
https://godbolt.org/g/91wxk7
So it's has been most likely fixed in the meantime.
: 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,
Is it expected that a shared library where
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87698
--- Comment #1 from Romain Geissler ---
Note: this is the source of the following error when linking with ld.lld 7.0:
ld.lld: error: corrupt input file: version definition index 0 for symbol
_libssh2_ntohu32 is out of bounds
>>> defined in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87698
--- Comment #3 from Romain Geissler ---
Well I might not understand everything but no I don't think I am comparing
uncomparable things.
I never build/link with -fno-lto, -flto is *always* provided.
See for example the case with fat objects:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87698
--- Comment #5 from Romain Geissler ---
Reduced test case:
> cat test.c
void f() {}
> cat test2.c
void f();
void g()
{
f();
}
> cat test.ver
{
local: *;
};
> gcc -g -flto -ffat-lto-objects -fPIC -o test.fat-objects.o -c test.c
> gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87698
--- Comment #6 from Romain Geissler ---
Versions of gcc and ld:
> gcc --version
gcc (GCC) 8.2.1 20181011
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87428
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
I have the following ICE when building llvm+clang+lld 7.0.0 (PGO + LTO profile)
on x64 with gcc from 28/10/2018 (while it was working fine with gcc from
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:
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
: 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
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=87362
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84436
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
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):
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=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
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 #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"
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=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.
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=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
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
: 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
: 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) does an
ou
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
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. Support has
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|---
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:
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
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 #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
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
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
: 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
: 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
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47857
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
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"): */
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 toolchain
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=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
: 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=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=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
: 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
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
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 more
1 - 100 of 150 matches
Mail list logo
