https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744
Peter VARGA changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|WORKSFORME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744
--- Comment #15 from Peter VARGA ---
(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 default settings".
>
> As has been explained
: 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=87017
Peter VARGA changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #3 from Peter VARGA ---
++
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&action=edit
error messages
I have installed gcc 7.3 in the /FaF directory and glibc 2.27 in t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744
--- Comment #2 from Peter VARGA ---
Sorry, but this does not help.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744
--- Comment #3 from Peter VARGA ---
(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 #4 from Peter VARGA ---
(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 #6 from Peter VARGA ---
(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 (libstdc++ before glibc, in
> particular),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744
--- Comment #7 from Peter VARGA ---
This is the original version:
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744
--- Comment #10 from Peter VARGA ---
(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 C library. You can't
> just point it to a
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 #1 from Peter VARGA ---
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: ../gcc-4.9.3_source/configure --disa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69723
--- Comment #3 from Peter VARGA ---
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 this
case it does NOT make sense!
Just imagin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69723
--- Comment #5 from Peter VARGA ---
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
generates a warning as it should be.
OK. You
: 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 warn t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69925
--- Comment #2 from Peter VARGA ---
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 I used it in STL and there is
almost every parameter
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=71562
--- Comment #2 from Peter VARGA ---
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 existing system when running
./conf
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: developm...@faf-ltd.com
#include
typedef struct
{
charsDateTime [20];
std::atomicbReadyToFlush;
} LogEntries;
typedef struct
{
LogEntriesleLogEntries [1] {};
} LogThreads;
Compiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65512
--- Comment #1 from Peter VARGA ---
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
gcc version 4.9.2 (GCC)
CO
mponent: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: developm...@faf-ltd.com
#include
class LogEntries
{
public:
charsDateTime [20];
std::atomic bReadyToFlush;
};
class LogThreads
{
public:
static LogEntries leLogEntries [10];
};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65513
--- Comment #1 from Peter VARGA ---
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 #3 from Peter VARGA ---
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 think?! My workaround i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65512
--- Comment #5 from Peter VARGA ---
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 misunderstanding. AND I d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65512
--- Comment #7 from Peter VARGA ---
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
typedef struct
{
boolbValid;
charsDateTime [20];
std::atomic bReadyToFlush;
} LogEntries;
typedef struct
{
LogEntries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59812
Peter VARGA changed:
What|Removed |Added
CC||developm...@faf-ltd.com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43714
Peter VARGA changed:
What|Removed |Added
CC||developm...@faf-ltd.com
--- Comment #3
29 matches
Mail list logo
