https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87017
Peter VARGA changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #3 from Peter VARGA
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: developm...@faf-ltd.com
Target Milestone: ---
This MCVE compiles/runs with gcc 7.3, clang 6.0 and icc 18.0 [this is, what I
tested so far]:
#include
#include
#include
namespace FaF
{
template
class Allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744
--- Comment #15 from Peter VARGA <developm...@faf-ltd.com> ---
(In reply to Jonathan Wakely from comment #14)
> Installing your own glibc in a new location and trying to point GCC to it
> with -I /FaF/glibc/include is not "the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744
Peter VARGA <developm...@faf-ltd.com> changed:
What|Removed |Added
Status|RESOLVED|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744
--- Comment #10 from Peter VARGA <developm...@faf-ltd.com> ---
(In reply to Jonathan Wakely from comment #8)
> You need to recompile gcc telling it to use the new glibc.
>
> When GCC is built it creates fixed dependencies on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744
--- Comment #7 from Peter VARGA <developm...@faf-ltd.com> ---
This is the original version:
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744
--- Comment #6 from Peter VARGA <developm...@faf-ltd.com> ---
(In reply to Marc Glisse from comment #5)
> That's not how you use a different glibc. If you look at the include order
> printed by -v, it has to remain in that order (libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744
--- Comment #4 from Peter VARGA <developm...@faf-ltd.com> ---
(In reply to Andrew Pinski from comment #1)
> >-I /FaF/glibc/include
>
> Use -isystem instead or a true sysroot instead.
Can you post the full g++ command line options how you mean it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744
--- Comment #3 from Peter VARGA <developm...@faf-ltd.com> ---
(In reply to Andrew Pinski from comment #1)
> >-I /FaF/glibc/include
>
> Use -isystem instead or a true sysroot instead.
Sorry, but this does not help.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744
--- Comment #2 from Peter VARGA <developm...@faf-ltd.com> ---
Sorry, but this does not help.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: developm...@faf-ltd.com
Target Milestone: ---
Created attachment 43581
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43581=edit
error messages
I have installed gcc 7.3 in the /FaF directory and glibc 2.27 in the /FaF/gl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43714
Peter VARGA <developm...@faf-ltd.com> changed:
What|Removed |Added
CC| |developm.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71562
--- Comment #2 from Peter VARGA <developm...@faf-ltd.com> ---
I disagree 100% with your comment!
I am definitely NOT a genius and I needed 5 minutes to find out where the hard
coded size is set.
Look at the GNU Glibc - you can crash an ex
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: developm...@faf-ltd.com
Target Milestone: ---
Would it be possible to change the hard coded size <_S_local_capacity> in
in line #55 from 15 to a PREPROCESSOR_DEFINE whi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69925
--- Comment #2 from Peter VARGA <developm...@faf-ltd.com> ---
I expected honestly this answer but then almost every compiler warning can be
"overruled" by a bad programmer.
By the way I found out this behavior because
: trivial
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: developm...@faf-ltd.com
Target Milestone: ---
auto foo( const char * ) -> void;
int main()
{
char bar [100];
foo( bar );
}
In my opinion gcc should w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69723
--- Comment #1 from Peter VARGA <developm...@faf-ltd.com> ---
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.3/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: developm...@faf-ltd.com
Target Milestone: ---
It is here described:
http://stackoverflow.com/questions/35269414/gcc-does-not-warn-variable-set-but-not-used
auto foo() -> void
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69723
--- Comment #3 from Peter VARGA <developm...@faf-ltd.com> ---
Dear Jakob,
thank you for the explanation. But honestly, the "definition" when to warn is
in my eyes wrong. Even var++ is reading and then setting the variable in t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69723
--- Comment #5 from Peter VARGA <developm...@faf-ltd.com> ---
I do not understand what you mean with "Replace unused++ with unused = unused
+ 1".
How ever. I checked my example code in Compiler Explorer with clang and clang
gen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59812
Peter VARGA <developm...@faf-ltd.com> changed:
What|Removed |Added
CC| |developm.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: developm...@faf-ltd.com
#include atomic
typedef struct
{
boolbValid;
charsDateTime [20];
std::atomicbool bReadyToFlush;
} LogEntries;
typedef struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65512
--- Comment #7 from Peter VARGA developm...@faf-ltd.com ---
Due the fact some frameworks do NOT support gcc 5.0 yet I would like to know if
this bug is going to be fixed in a 4.9.X version or not.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: developm...@faf-ltd.com
#include atomic
class LogEntries
{
public:
charsDateTime [20];
std::atomicbool bReadyToFlush;
};
class LogThreads
{
public:
static LogEntries leLogEntries [10];
};
LogEntries
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: developm...@faf-ltd.com
#include atomic
typedef struct
{
charsDateTime [20];
std::atomicboolbReadyToFlush;
} LogEntries;
typedef struct
{
LogEntriesleLogEntries [1] {};
} LogThreads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65513
--- Comment #1 from Peter VARGA developm...@faf-ltd.com ---
One of these following steps do not produce any error message and the compiler
can finish successfully:
1) Add {} to the sDateTime member
2) Remove the std::atomic member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65512
--- Comment #1 from Peter VARGA developm...@faf-ltd.com ---
Output for the -v option:
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.9.2_source/configure --disable-multilib
Thread model: posix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65512
--- Comment #3 from Peter VARGA developm...@faf-ltd.com ---
1) I had no idea how the importance is qualified. Is my 1st bug report. For me
it was a blocker because I could not finish compiling
2) Not using -Werror is really a bit hard - don't you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65512
--- Comment #5 from Peter VARGA developm...@faf-ltd.com ---
1) There are bugs which are not important. It is always a point of view. As a
starter here I had 2 possibilities and I took the wrong. More or less you may
be right but it was a simple
29 matches
Mail list logo
