http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811
--- Comment #23 from __vic d.v.a at ngs dot ru ---
What actual status of this bug is? Is it fixed or still not?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56811
--- Comment #9 from __vic d.v.a at ngs dot ru ---
Is there any progress and/or solid plan? The last available version of G++ for
HP-UX is 4.7.1 (here
http://h21007.www2.hp.com/portal/site/dspp/menuitem.863c3e4cbcdc3f3515b49c108973a801?ciid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54513
Bug #: 54513
Summary: undefined reference to `___tls_get_addr' when
linking .so with libstdc++.a
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54513
--- Comment #1 from __vic d.v.a at ngs dot ru 2012-09-07 07:19:43 UTC ---
Note: compiler with stdlib was built manually from sources
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54513
--- Comment #3 from __vic d.v.a at ngs dot ru 2012-09-07 08:58:39 UTC ---
$ g++ -shared -static-libstdc++ -static-libgcc -Wl,-s -Wl,--no-undefined 1.cpp
/lib/ld-linux.so.2
works fine. Thanks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56815
Bug #: 56815
Summary: void pointer arithmetic
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56815
--- Comment #1 from __vic d.v.a at ngs dot ru 2013-04-02 17:00:23 UTC ---
Slightly modified:
int main()
{
void *p = 0;
p++;
}
$ gcc -std=c++98 source.cpp
source.cpp:4:6: error: arithmetic on a pointer to void
p++;
~^
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56815
--- Comment #3 from __vic d.v.a at ngs dot ru 2013-04-02 17:10:15 UTC ---
(In reply to comment #2)
void* arithmetic is a GCC extension.
But why my examples are treated differently?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56815
--- Comment #5 from __vic d.v.a at ngs dot ru 2013-04-03 06:24:43 UTC ---
(In reply to comment #4)
From gcc manpage, the option '-std=' specifies base standard and
accept some GNU extensions that do not contradict it.
If you would
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56815
__vic d.v.a at ngs dot ru changed:
What|Removed |Added
Severity|normal |minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53680
Bug #: 53680
Summary: Link problems with static libstdc++
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53680
--- Comment #2 from __vic d.v.a at ngs dot ru 2012-06-15 08:30:06 UTC ---
$ uname -a
Linux m246 2.6.18-194.26.1.el5 #1 SMP Tue Nov 9 12:54:40 EST 2010 i686 i686
i386 GNU/Linux
$ cat /etc/*-release
CentOS release 5.4 (Final)
When building
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53680
--- Comment #3 from __vic d.v.a at ngs dot ru 2012-06-15 08:34:13 UTC ---
When I'm trying link libstdc++.a statically to my .so I see messages like:
undefined versioned symbol name std::defer_lock@@GLIBCPP_3
$ nm libstdc++.a | grep @
shows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49894
__vic d.v.a at ngs dot ru changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #13 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53680
--- Comment #4 from __vic d.v.a at ngs dot ru 2012-06-15 08:57:21 UTC ---
Note: undocumented configure option --disable-symvers helps but I think
building with default parameters must work properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53680
--- Comment #5 from __vic d.v.a at ngs dot ru 2012-06-15 10:22:36 UTC ---
The exact description:
$ g++ -o formats/alcatel_alm9_decoder.fmt -shared -Llib -static-libgcc -O3
-Wl,-s -Wl,--no-undefined src/alcatel_alm9_decoder.o formats.a decoder.a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53680
--- Comment #8 from __vic d.v.a at ngs dot ru 2012-06-15 10:30:30 UTC ---
(In reply to comment #6)
(In reply to comment #4)
Note: undocumented configure option --disable-symvers helps but I think
building with default parameters must work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53680
--- Comment #9 from __vic d.v.a at ngs dot ru 2012-06-15 10:33:13 UTC ---
(In reply to comment #7)
isn't this PR 52689 ?
Probably it is.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53680
--- Comment #10 from __vic d.v.a at ngs dot ru 2012-06-15 10:36:24 UTC ---
When 4.7.1 will be released?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811
--- Comment #18 from __vic d.v.a at ngs dot ru 2012-06-27 10:19:18 UTC ---
GCC 4.7.1 still fails to link .so against static libstdc++.a in 64-bit mode:
$ g++ -shared -fPIC -static-libgcc -static-libstdc++ -o 1.so 1.cpp
/usr/bin/ld:
/opt/gcc-4.6.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811
--- Comment #19 from __vic d.v.a at ngs dot ru 2012-06-27 10:27:14 UTC ---
I'm sorry, compiler version was 4.6.1 in previous example.
Output for 4.7.1:
$ g++ -shared -fPIC -static-libgcc -static-libstdc++ -o 1.so 1.cpp
/usr/bin/ld:
/opt/gcc-4.7.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56811
--- Comment #13 from __vic d.v.a at ngs dot ru ---
(In reply to Alexander from comment #12)
fixed in GCC 4.8.3
What about 4.9 branch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936
__vic d.v.a at ngs dot ru changed:
What|Removed |Added
Summary|Binary code bloat with |[4.9 Regression] Binary
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: d.v.a at ngs dot ru
Example:
#includelist
struct C { int a, b; };
int main()
{
std::listC l;
l.emplace_back(1, 2);
}
$ g++ -std=c++11 -Wall example.cpp
In file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63274
--- Comment #1 from __vic d.v.a at ngs dot ru ---
And yes, in this case I can just write
l.push_back({1, 2});
But both cases should be acceptable for compiler, IMO.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50025
__vic d.v.a at ngs dot ru changed:
What|Removed |Added
CC||d.v.a at ngs dot ru
++
Assignee: unassigned at gcc dot gnu.org
Reporter: d.v.a at ngs dot ru
Test program:
#includestring
int hello()
{
std::string st(abc);
return st.length();
}
Build:
$ g++ -shared -fPIC -static-libgcc -static-libstdc++ -Wl,-s -o $@ $?
Sizes of result:
gcc-4_7-string.so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936
--- Comment #1 from __vic d.v.a at ngs dot ru ---
If we use iostream classes (without std::string) the difference isn't so
dramatic:
4.7: 800320
4.8: 838944
4.9: 868664
May be it's connected with locales? Has std::string any dependences
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936
--- Comment #2 from __vic d.v.a at ngs dot ru ---
Non-stripped binary built with 4.9 has many symbols from locale. 4.8 - doesn't.
How std::string uses locales???
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: d.v.a at ngs dot ru
#includestring
#includeiostream
int main()
{
std::string st{1U, '0'};
std::cout st.length() '\n';
std::cout st '\n';
}
Prints:
2
☺0
Must
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61658
--- Comment #1 from __vic d.v.a at ngs dot ru ---
If replace with:
std::string st(1U, '0');
then prints as expected:
1
0
Why {1U, '0'} is treated as std::initializer_listchar ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49020
Summary: Invalid std::strchr prototype in cstring
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libstdc++
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49020
--- Comment #3 from __vic d.v.a at ngs dot ru 2011-05-17 12:24:56 UTC ---
(In reply to comment #1)
You haven't said which version of gcc or which platform.
Actually 3.4.3 on Linux and Windows (MinGW) but in SVN trunk version (r169421)
/trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49020
--- Comment #4 from __vic d.v.a at ngs dot ru 2011-05-17 12:31:50 UTC ---
(In reply to comment #1)
With a recent GCC and recent glibc I get:
In which version of GCC can I find valid implementation?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49020
__vic d.v.a at ngs dot ru changed:
What|Removed |Added
Version|unknown |4.1.1
--- Comment #5 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49020
__vic d.v.a at ngs dot ru changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #7 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49020
--- Comment #9 from __vic d.v.a at ngs dot ru 2011-05-18 05:33:24 UTC ---
The libstdc++ uses glibc anyway? What about alternative implementations like
hp-gcc for HP-UX?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49020
--- Comment #10 from __vic d.v.a at ngs dot ru 2011-05-18 05:36:38 UTC ---
(In reply to comment #8)
3.4 and 4.1 are ancient history, active release series are listed on the home
page, http://gcc.gnu.org/
Yes, I know. But I have no ability
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49020
--- Comment #12 from __vic d.v.a at ngs dot ru 2011-05-18 09:06:26 UTC ---
(In reply to comment #11)
I don't know what hp-gcc is, but on non-glibc platforms the overloads aren't
correct, see PR 33935
PR 33935 is mostly about overloads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49020
__vic d.v.a at ngs dot ru changed:
What|Removed |Added
Status|CLOSED |UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49020
--- Comment #16 from __vic d.v.a at ngs dot ru 2011-05-18 09:55:34 UTC ---
Initial problem is that the following standard-conforming code is not compiled
by GCC.
#includecstring
templateclass Iter
void f(Iter i1, Iter i2)
{
}
int main
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49020
__vic d.v.a at ngs dot ru changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #19 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
__vic d.v.a at ngs dot ru changed:
What|Removed |Added
CC||d.v.a at ngs dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
__vic d.v.a at ngs dot ru changed:
What|Removed |Added
CC||d.v.a at ngs dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49894
Summary: Uniform initialization in constructor (C++0x)
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49894
--- Comment #1 from __vic d.v.a at ngs dot ru 2011-07-29 06:28:47 UTC ---
class mutex
{
::pthread_mutex_t mtx;
public:
constexpr mutex() : mtx(PTHREAD_MUTEX_INITIALIZER) {}
};
Compiles fine... What is the difference?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49894
--- Comment #3 from __vic d.v.a at ngs dot ru 2011-07-29 10:13:16 UTC ---
test.cpp:7:84: error: could not convert '{{0, 0}, 0, , 0}' from
'brace-enclosed initializer list' to 'pthread_cond_t'
Initializer is:
{{0, 0}, 0, , 0}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49894
--- Comment #4 from __vic d.v.a at ngs dot ru 2011-07-29 10:17:35 UTC ---
Created attachment 24861
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24861
Preprocessor output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
--- Comment #6 from __vic d.v.a at ngs dot ru 2011-08-02 03:25:10 UTC ---
Why not say
constexpr cond_variable() : cond PTHREAD_COND_INITIALIZER { }
What if PTHREAD_COND_INITIALIZER is a just scalar?
You can define it as follows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936
--- Comment #11 from __vic d.v.a at ngs dot ru ---
Main problem hides in src/c++11/cow-string-inst.cc here:
namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
// These came from c++98/misc-inst.cc, repeat them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936
--- Comment #9 from __vic d.v.a at ngs dot ru ---
For 4.9 this change was enough for me:
--- libstdc++-v3/src/c++11/functexcept.cc2014-01-03 02:30:10.0
+0400
+++ libstdc++-v3/src/c++11/functexcept.cc2014-11-06 18:40:20.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936
--- Comment #10 from __vic d.v.a at ngs dot ru ---
What brings new dependences on locales?
Assignee: unassigned at gcc dot gnu.org
Reporter: d.v.a at ngs dot ru
Host: x86_64-linux
Target: x86_64-linux
Build: x86_64-linux
gcc-5.1.0-RC-20150412.tar.bz2 build error:
...
libtool: compile:
/home/vdyachenko/usr/misc/gcc/gcc-5.1.0-RC-20150412
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65763
--- Comment #2 from __vic d.v.a at ngs dot ru ---
Will it help? OK, I'll try.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65763
--- Comment #6 from __vic d.v.a at ngs dot ru ---
(In reply to __vic from comment #2)
Will it help? OK, I'll try.
Yes. Has been built successfully.
Thanks!
P.S. I've read doc about building in a separate directory but all previous
versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936
--- Comment #6 from __vic d.v.a at ngs dot ru ---
5.1-RC (gcc-5.1.0-RC-20150412) - the same problem. Suppose in GCC 6 too?
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: d.v.a at ngs dot ru
Target Milestone: ---
Compilation of this code:
#include
int main()
{
int arr[std::experimental::string_view("s").length()];
}
produces error:
error: ISO C++ forbids variable le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68133
--- Comment #2 from __vic ---
Too much black magic in the library already...
I think this is defect in specification/design of the class. But it's easier
for you guys to reach the committee than for me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936
--- Comment #17 from __vic ---
Created attachment 38319
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38319=edit
Dirty patch for GCC 5/6
This dirty patch created for GCC5 solves the problem for GCC6 as well.
(out_of_range will not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71214
__vic changed:
What|Removed |Added
CC||d.v.a at ngs dot ru
--- Comment #1 from __vic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936
--- Comment #30 from __vic ---
Excellent job, Jonathan! With gcc-7-20170212 the binaries are slim again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936
--- Comment #19 from __vic ---
No plans for 6.2?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #36 from __vic ---
What about 6.2?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936
--- Comment #20 from __vic ---
Patch attachment 38319 solves the problem for GCC 6.2 as well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936
--- Comment #22 from __vic ---
Of course. It's comment for people like me who needs solution right now
(actually since 2014...)
++
Assignee: unassigned at gcc dot gnu.org
Reporter: d.v.a at ngs dot ru
Target Milestone: ---
Updated GCC 6.2 -> 6.3 and now see following build error:
$ g++ -std=c++14 -pthread -c -MMD -pedantic-errors -Isrc/main
-I/usr/local/ssl/include -DASIO_STANDALONE -DASIO_SEPARATE_COMPILAT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78926
__vic changed:
What|Removed |Added
Known to work||6.2.0
Host|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78926
--- Comment #5 from __vic ---
$ gcc -flto -ffunction-sections -fdata-sections -I. -I.. -I../include
-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack
-m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78926
--- Comment #3 from __vic ---
See the first $. Or you mean openssl objects?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78926
--- Comment #7 from __vic ---
But it works with 6.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78926
--- Comment #8 from __vic ---
OpenSSL v 1.0.2j
$ env CC="gcc -flto -ffunction-sections -fdata-sections" AR=gcc-ar
RANLIB=gcc-ranlib ./config threads no-shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78926
--- Comment #9 from __vic ---
$ ld --version
GNU gold (GNU Binutils 2.27) 1.12
Built from sources. Both gold and BFD produce the same result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78926
--- Comment #12 from __vic ---
Actually it can be 6.1 as well. Don't remember exactly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78926
--- Comment #11 from __vic ---
Yes. As it is said in Comment 0:
> OpenSSL library (static) built with previous version - GCC 6.2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78926
--- Comment #13 from __vic ---
Rebuilt openssl with 6.3, the problem has gone.
What was that? Bug in the previous version or in the new one?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936
--- Comment #23 from __vic ---
Jonathan, have you tried to merge you patch with mine? Yours lacks decoupling
of string and iostream in c++11/cow-string-inst.o. I think it's a reason why
code size was unaffected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63191
__vic changed:
What|Removed |Added
CC||d.v.a at ngs dot ru
--- Comment #18 from __vic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78926
--- Comment #14 from __vic ---
GCC 7-RC1 now reports
lto1: fatal error: bytecode stream in file ‘lib/libssl.a’ generated with LTO
version 5.1 instead of the expected 6.0
compilation terminated.
lto-wrapper: fatal error: g++ returned 1 exit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59423
__vic changed:
What|Removed |Added
CC||d.v.a at ngs dot ru
--- Comment #1 from __vic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936
--- Comment #34 from __vic ---
Fixed in 7.1.
Shouldn't we close this bug?
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: d.v.a at ngs dot ru
Target Milestone: ---
This code
struct settings
{
enum class step { step1_clear, step2_copy };
step step;
};
inline const char *to_text(enum settings::step v
81 matches
Mail list logo
