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 #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
: 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=87362
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81577
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,
I would to know if the following (currently not implemented) behaviour of
[[nodiscard]] would be useful or not. I am raising
++
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78063
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
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=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.
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=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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84670
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
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=84468
--- Comment #15 from Romain Geissler ---
Hi,
This latest patch seems to fix the occurences I have in my own code. Thanks ;)
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
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=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=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
: 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 #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=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=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=84480
--- Comment #6 from Romain Geissler ---
Thanks ;)
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
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
-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
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,
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
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
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
--- 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...)
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=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=72104
Romain Geissler changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
--- 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=70977
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
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=71021
Romain Geissler changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=71057
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
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
101 - 150 of 150 matches
Mail list logo
