--- Comment #22 from thiago at kde dot org 2007-01-11 18:42 ---
Is there any update on this bug?
According to http://sourceware.org/ml/binutils/2005-01/msg00401.html, a
protected function symbol cannot be used in a R_386_GOTOFF. I don't claim to
understand the full implications
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Source:
$ cat t.c
#include immintrin.h
__attribute__((target(avx2))) int f(void *ptr)
{
return _mm256_movemask_epi8(_mm256_loadu_si256
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58889
--- Comment #1 from Thiago Macieira thiago at kde dot org ---
This problem also happens with other combinations of functions in use and
compiler options.
My original problem happened on a 64-bit build with -march=corei7-avx and a
function
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Consider the following code:
#include immintrin.h
int f(void *p1, void *p2)
{
__m128i d1 = _mm_loadu_si128((__m128i*)p1);
__m128i d2 = _mm_loadu_si128
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59539
--- Comment #2 from Thiago Macieira thiago at kde dot org ---
I have to use _mm_loadu_si128 because non-VEX SSE requires explicit unaligned
loads.
Here's more food for thought:
__m128i result = _mm_cmpeq_epi16((__m128i*)p1, (__m128i*)p2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59539
--- Comment #12 from Thiago Macieira thiago at kde dot org ---
Thanks, rebuilding!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59539
--- Comment #13 from Thiago Macieira thiago at kde dot org ---
I can't confirm. trunk@206091:
$ ~/gcc4.9/bin/gcc -mavx -S -o - -O3 -xc - '#include immintrin.h
int f(void *p1, void *p2)
{
__m128i d1 = _mm_loadu_si128((__m128i*)p1);
__m128i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59539
--- Comment #14 from Thiago Macieira thiago at kde dot org ---
*facepalm* I had forgotten to make install!
It works:
$ ~/gcc4.9/bin/gcc -mavx -S -o - -O3 -xc - '#include immintrin.h
int f(void *p1, void *p2)
{
__m128i d1 = _mm_loadu_si128
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54202
Bug #: 54202
Summary: Overeager warning about freeing non-heap objects
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54202
--- Comment #2 from Thiago Macieira thiago at kde dot org 2012-08-08 14:21:59
UTC ---
To be honest, I don't want false-positive warnings. The code and data are
constructed so that it never frees the non-heap object (it has a reference
count of -1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54202
--- Comment #4 from Thiago Macieira thiago at kde dot org 2012-08-08 14:53:13
UTC ---
(In reply to comment #3)
Note that even for the uninitialized use case we warn for functions
that may be never executed at runtime. So - are you happy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54231
Bug #: 54231
Summary: LTO generates code for the wrong CPU if different
options used
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54231
--- Comment #1 from Thiago Macieira thiago at kde dot org 2012-08-11 22:30:50
UTC ---
Created attachment 27993
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27993
main.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54231
--- Comment #2 from Thiago Macieira thiago at kde dot org 2012-08-11 22:33:31
UTC ---
When adding the following source file to the library build:
#include stdlib.h
void bzero_sse2(char *, size_t);
void bzero_avx(char *, size_t);
extern int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54231
--- Comment #3 from Thiago Macieira thiago at kde dot org 2012-08-11 22:36:20
UTC ---
Another note: it appears the Intel compiler has the same bug. It produces the
following code when compiling with -O2 -ipo:
0340 my_bzero:
340
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54231
--- Comment #6 from Thiago Macieira thiago at kde dot org 2012-08-11 23:23:39
UTC ---
(In reply to comment #5)
Fixing this in the compiler isn't straight-forward. The _mm_stream functions
are just wrappers around builtin functions. It may work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54231
--- Comment #9 from Thiago Macieira thiago at kde dot org 2012-08-13 09:44:51
UTC ---
(In reply to comment #8)
If you do something like
gcc -c t1.c -mavx -flto
gcc -c t2.c -msse2 -flto
gcc t1.o t2.o -flto
then the link step will use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54231
--- Comment #10 from Thiago Macieira thiago at kde dot org 2012-08-13
09:53:32 UTC ---
Another test:
$ cat main_avx.c
#define BZERO bzero_avx
#pragma GCC target (avx)
#include main.c
$ cat main_sse2.c
#define BZERO bzero_sse2
#pragma GCC target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54231
--- Comment #11 from Thiago Macieira thiago at kde dot org 2012-08-13
10:12:48 UTC ---
Attaching __attribute__((target(xxx))) to the function does help.
It generates the following with the my_bzero function from comment 2:
02e0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54231
--- Comment #13 from Thiago Macieira thiago at kde dot org 2012-08-13
12:13:40 UTC ---
(In reply to comment #12)
Yes, there are similar option-related bugs for this. Note somebody needs
to sit down and document the desired semantics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54172
--- Comment #4 from Thiago Macieira thiago at kde dot org 2012-08-30 07:52:31
UTC ---
I'll post today.
I haven't yet looked up which mailing list you're even talking about.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54172
--- Comment #7 from Thiago Macieira thiago at kde dot org 2012-09-01 08:26:05
UTC ---
I posted the patches on Thursday, three patches because I found one more issue,
to both lists.
Will they be picked up from there and applied to the source tree?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54172
--- Comment #9 from Thiago Macieira thiago at kde dot org 2012-09-04 17:47:08
UTC ---
(In reply to comment #8)
(In reply to comment #7)
I posted the patches on Thursday, three patches because I found one more
issue,
to both lists.
I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54485
Thiago Macieira thiago at kde dot org changed:
What|Removed |Added
CC||thiago at kde dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54231
--- Comment #14 from Thiago Macieira thiago at kde dot org 2012-09-12
13:02:23 UTC ---
From GCC's own manual:
(Node Function attributes):
On the 386/x86_64 and PowerPC backends, the inliner will not
inline a function that has
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54988
--- Comment #3 from Thiago Macieira thiago at kde dot org 2012-10-22 14:43:11
UTC ---
This might be as I pointed out in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54231:
(Node Function attributes):
On the 386/x86_64 and PowerPC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56446
Bug #: 56446
Summary: Generate one fewer relocation when calling a checked
weakref function
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56446
--- Comment #3 from Thiago Macieira thiago at kde dot org 2013-02-25 22:27:14
UTC ---
This should not be done for non-PIC code. In those, it might be preferable to
make the actual call, as opposed to an indirect jump.
I also wonder what
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56446
--- Comment #4 from Thiago Macieira thiago at kde dot org 2013-02-25 22:28:07
UTC ---
One more detail: both ICC 13 and Clang 3.0 do the same thing as GCC.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56574
Thiago Macieira thiago at kde dot org changed:
What|Removed |Added
CC||thiago
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56727
Bug #: 56727
Summary: [4.7/4.8] [missed-optimization] Recursive call goes
through the PLT unnecessarily
Classification: Unclassified
Product: gcc
Version: 4.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064
Bug #: 57064
Summary: [clarification requested] Which overload with
ref-qualifier should be called?
Classification: Unclassified
Product: gcc
Version: 4.8.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064
--- Comment #1 from Thiago Macieira thiago at kde dot org 2013-04-25 00:45:00
UTC ---
Here's why I'm asking:
QString has members like:
QString arg(int, [other parameters]) const;
Which are used like so:
return QString(%1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064
--- Comment #2 from Thiago Macieira thiago at kde dot org 2013-04-25 00:45:39
UTC ---
This was a self-compiled, pristine GCC
gcc version 4.8.1 20130420 (prerelease) (GCC)
trunk at 198107
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064
--- Comment #3 from Thiago Macieira thiago at kde dot org 2013-04-25 00:53:20
UTC ---
One more note. Given:
void p(A );
void p(A );
void f(A a)
{
p(a);
}
like the member function case, this calls p(A ). It's slightly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064
--- Comment #6 from Thiago Macieira thiago at kde dot org 2013-04-25 06:51:33
UTC ---
void f(A a)
{
std::move(a).p();
}
_Z1fO1A:
.cfi_startproc
jmp _ZNR1A1pEv@PLT #
.cfi_endproc
Then this looks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064
--- Comment #8 from Thiago Macieira thiago at kde dot org 2013-04-25 07:13:44
UTC ---
Hmm... this might be an effect of the same bug. Can you try this on 4.9?
struct A {
A p() const ;
A p() ;
};
void f()
{
A().p().p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064
--- Comment #10 from Thiago Macieira thiago at kde dot org 2013-04-25
07:34:21 UTC ---
Great! That changes everything. Now I can provide a mutating arg() overload.
I'll just need some #ifdef and build magic to add the R, O overloads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064
--- Comment #14 from Thiago Macieira thiago at kde dot org 2013-04-26
06:16:04 UTC ---
Understood. The idea is that one would write:
QString str = QString(%1 %2).arg(42).arg(43);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064
--- Comment #16 from Thiago Macieira thiago at kde dot org 2013-04-26
13:45:35 UTC ---
Thanks for the hint.
However, returning an rvalue, even if moved-onto, will generate code for the
destructor. It's not a matter of efficiency, just
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57202
Bug #: 57202
Summary: Please make the intrinsics headers like immintrin.h be
usable without compiler flags
Classification: Unclassified
Product: gcc
Version: 4.8.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57202
Thiago Macieira thiago at kde dot org changed:
What|Removed |Added
Target|x86_64-*-* i?86-*-* |x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54172
Bug #: 54172
Summary: [4.7 Regression] __cxa_guard_acquire thread-safety
issue
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
I would like a new (optional) warning that would point out every C++ virtual
override that is done without the C++11 keyword that indicates
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Testcase:
class S
{
public:
S x() const __attribute__ ((__warn_unused_result__));
S y() const __attribute__ ((__warn_unused_result__));
S y
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
The option -march=core-avx2 to gcc is documented to enable:
Intel Core CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2,
SSE3, SSSE3, SSE4.1, SSE4.2, AVX, AVX2, AES, PCLMUL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59952
--- Comment #2 from Thiago Macieira thiago at kde dot org ---
The Ks and the Rs don't have it. The plain 4770 as well as 4770S do have it. I
guess we were too eager with TSX when the announcement came out 2 years ago: it
sounded like all Haswell
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59952
--- Comment #4 from Thiago Macieira thiago at kde dot org ---
(In reply to Mikael Pettersson from comment #3)
There are also Haswells that lack BMI2. I updated our dynamic binary
instrumentation engine for AVX2 about a year ago, but while our
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59952
--- Comment #7 from Thiago Macieira thiago at kde dot org ---
(In reply to Jakub Jelinek from comment #6)
Prerelease samples shouldn't count, people using those just can avoid using
-march=haswell and use -march=ivybridge -mavx2 or similar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59952
--- Comment #8 from Thiago Macieira thiago at kde dot org ---
(In reply to Thiago Macieira from comment #7)
(In reply to Jakub Jelinek from comment #6)
Prerelease samples shouldn't count, people using those just can avoid using
-march=haswell
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59952
--- Comment #10 from Thiago Macieira thiago at kde dot org ---
(In reply to Yukhin Kirill from comment #9)
I am checking and will get back to. I though all AVX2 parts had BMI1/2
The evidence seems to support that. I did check with a few
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57202
--- Comment #5 from Thiago Macieira thiago at kde dot org ---
(In reply to Marc Glisse from comment #4)
Can this be closed?
Oh, yeah, this is working fine in GCC 4.9.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59952
--- Comment #12 from Thiago Macieira thiago at kde dot org ---
GCC 4.9.0 got released with -march=haswell still enabling RTM and HLE, even
though there are Haswell parts without TSX.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59952
--- Comment #15 from Thiago Macieira thiago at kde dot org ---
(In reply to H.J. Lu from comment #14)
I think HLE is the part of TSX.
It is and should be removed from the list.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59952
--- Comment #19 from Thiago Macieira thiago at kde dot org ---
The prefix can be emitted for any CPU, you don't need a flag for that. However,
you cannot emit the XTEST instruction unless the CPU has HLE or RTM.
: unassigned at gcc dot gnu dot org
ReportedBy: thiago at kde dot org
GCC build triplet: i586-manbo-linux-gnu
GCC host triplet: i586-manbo-linux-gnu
GCC target triplet: i586-manbo-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40145
--- Comment #4 from thiago at kde dot org 2009-11-23 14:32 ---
My experience:
gcc 4.4 + binutils 2.18.50.20070820 + no -march: ok
gcc 4.4 + binutils 2.18.50.20070820 + -march=armv7-a: error
gcc 4.4 + binutils 2.19.51.0.2.20090204: ok in both cases
The instruction I had problems
--- Comment #1 from thiago at kde dot org 2010-03-03 14:41 ---
Problem also happens on:
gcc 4.4.3 on linux 32-bit
gcc 4.4.1 on linux ARM (armel gnueabi)
Also reproducible with -O1 -ftree-vrp.
--
thiago at kde dot org changed:
What|Removed |Added
--- Comment #2 from thiago at kde dot org 2010-03-03 14:44 ---
Also:
-O1 -ftree-vrp -fno-cprop-registers -fno-defer-pop
-fno-guess-branch-probability -fno-if-conversion -fno-if-conversion2
-fno-ipa-pure-const -fno-ipa-reference -fno-merge-constants
-fno-omit-frame-pointer -fno-split
--- Comment #1 from thiago at kde dot org 2010-03-03 14:46 ---
Anyone?
This is not a showstopper, but produces unnecessary (and incorrect) warnings.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40145
--- Comment #6 from thiago at kde dot org 2010-03-26 21:46 ---
Is this fix going to be backported to the 4.4.x line?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43247
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
--- Comment #23 from Thiago Macieira thiago at kde dot org 2012-01-16
14:56:50 UTC ---
I've changed my opinion on this matter. I think GCC is generating the proper
code (most efficient). It's ld that should accept this decision.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
--- Comment #26 from Thiago Macieira thiago at kde dot org 2012-01-18
13:28:05 UTC ---
ld *can* link, it just chooses not to.
$ cat foo.c
__attribute__((visibility(protected)))
void * foo (void) { return (void *)foo; }
$ gcc -fPIC -shared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
--- Comment #30 from Thiago Macieira thiago at kde dot org 2012-01-19
18:52:57 UTC ---
This does solve the problem.
It's just unfortunate that it does so by creating more work for the library
even if no executable ever takes the address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48856
Summary: Crash when compiling certain source code with C++0x
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48856
--- Comment #1 from Thiago Macieira thiago at kde dot org 2011-05-03 16:31:38
UTC ---
Created attachment 24171
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24171
Preprocessed sources showing the error (gzipped)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48856
--- Comment #4 from Thiago Macieira thiago at kde dot org 2011-05-03 17:20:13
UTC ---
Sorry, I forgot the information.
Version: 4.6.0
System: Linux 2.6.38, 32-bit
Command-line: g++ -std=c++0x qxmlschema.ii
GCC was configured with:
./configure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48856
--- Comment #5 from Thiago Macieira thiago at kde dot org 2011-05-03 17:21:09
UTC ---
To be exact on the version: gcc version 4.6.0 20110422 (prerelease) (GCC)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48856
--- Comment #6 from Thiago Macieira thiago at kde dot org 2011-05-03 17:42:02
UTC ---
(In reply to comment #3)
It would also be helpful to reduce the testcase:
http://gcc.gnu.org/bugs/minimize.html
Thanks for the suggestion. I can't promise I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48856
Thiago Macieira thiago at kde dot org changed:
What|Removed |Added
Status|WAITING |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49673
Summary: [C++0x] const variables initialised with constexpr
constructor placed in .data not .rodata
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131
Thiago Macieira thiago at kde dot org changed:
What|Removed |Added
CC||thiago at kde dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43247
--- Comment #10 from Thiago Macieira thiago at kde dot org 2010-12-22
10:35:23 UTC ---
This is still not fixed. I can reproduce now with a different testcase, in
4.5.1. However, this time, the same code works fine in 4.4. The reason is again
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43247
--- Comment #12 from Thiago Macieira thiago at kde dot org 2010-12-22
19:55:38 UTC ---
(In reply to comment #11)
The reason is again accessing an array out-of-bounds for elements that we
know to be there.
No that is undefined and different
: unassigned at gcc dot gnu dot org
ReportedBy: thiago at kde dot org
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-none-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43976
--- Comment #2 from thiago at kde dot org 2010-05-04 19:40 ---
Well, technically f.c has a type of 'char (__attribute__((aligned(4 [4]'.
Anyway, the point is that the variable is properly aligned, so the warning is
superfluous.
Or, in other words, we need a way to tell GCC I know
--- Comment #4 from thiago at kde dot org 2010-05-05 19:39 ---
(In reply to comment #3)
The struct Foo looks like an odd way to try and express
union Foo
{
int i;
char c[sizeof (int)];
};
Well, that is the objective, but you can't replace int with a non-POD type in
C++98. C
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
When compiling the attached preprocessed sources, GCC 5 (trunk r218173) prints
the following:
/home/thiago/src/qt/qt5/qtbase/src/corelib/tools
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
When compiling the attached preprocessed source, GCC 5 (trunk 218173) prints
the following ICE:
/home/thiago/src/qt/qt5/qtbase/src/corelib/io/qresource.cpp: In member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64111
--- Comment #1 from Thiago Macieira thiago at kde dot org ---
Created attachment 34136
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34136action=edit
Preprocessed output for the source file with the problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64110
--- Comment #1 from Thiago Macieira thiago at kde dot org ---
Created attachment 34138
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34138action=edit
Preprocessed sources for the build error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64111
--- Comment #2 from Thiago Macieira thiago at kde dot org ---
Created attachment 34137
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34137action=edit
Preprocessed output for the precompilation header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64110
--- Comment #2 from Thiago Macieira thiago at kde dot org ---
creduce reduced to the following testcase:
class A {
public:
short m_fn1() { return ucs; }
short ucs;
};
class C {
public:
int m_fn2();
} a;
A *b;
C c;
void fn1(A p1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64110
--- Comment #3 from Thiago Macieira thiago at kde dot org ---
This reduced testcase starts (apparently) with an uninitialised int i, but the
same problem happens if you initialise to 0 (for (int i = 0; i d; ++i))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64111
--- Comment #7 from Thiago Macieira thiago at kde dot org ---
Testcase works fine on GCC 4.9 and on this 5.0 without PCH. The error can only
be reproduced with PCH.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64111
Thiago Macieira thiago at kde dot org changed:
What|Removed |Added
Attachment #34136|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64111
Thiago Macieira thiago at kde dot org changed:
What|Removed |Added
Attachment #34137|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64111
--- Comment #10 from Thiago Macieira thiago at kde dot org ---
Actually, I removed my own #includes for the intrinsics, but they are still
there because of libstdc++-v3/config/cpu/i486/opt/bits/opt_random.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64111
Thiago Macieira thiago at kde dot org changed:
What|Removed |Added
Attachment #34141|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64111
--- Comment #15 from Thiago Macieira thiago at kde dot org ---
Created attachment 34149
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34149action=edit
Reduced testcase to minimum
This is the same testcase, now reduced to the minimum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64399
Thiago Macieira thiago at kde dot org changed:
What|Removed |Added
CC||thiago at kde dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64653
--- Comment #2 from Thiago Macieira thiago at kde dot org ---
Created attachment 34472
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34472action=edit
src1 assembly output by GCC 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64653
--- Comment #1 from Thiago Macieira thiago at kde dot org ---
Created attachment 34471
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34471action=edit
src1 assembly output by GCC 4.9
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Created attachment 34470
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34470action=edit
Test project
When the attached project is built
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Code:
template class
void tf()
{
extern void (*qt_memfill32)();
qt_memfill32();
}
void f() {
tfint();
}
When compiled with GCC 5.0, the object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65062
--- Comment #2 from Thiago Macieira thiago at kde dot org ---
(In reply to Andrew Pinski from comment #1)
it was just fixed yesterday, see bug 64898. Please check the latest GCC
before filing a bug especially during stage 4.
*** This bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886
--- Comment #8 from Thiago Macieira thiago at kde dot org ---
(In reply to H.J. Lu from comment #6)
(In reply to H.J. Lu from comment #5)
BTW, you should add -fsymbolic to -fPIC if the shared library will be
created by -Bsymbolic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886
--- Comment #7 from Thiago Macieira thiago at kde dot org ---
(In reply to H.J. Lu from comment #4)
(In reply to Thiago Macieira from comment #3)
Thanks H.J.!
Can I ask that -fsymbolic be the default? Otherwise, code with -fPIE MUST
add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886
--- Comment #3 from Thiago Macieira thiago at kde dot org ---
Thanks H.J.!
Can I ask that -fsymbolic be the default? Otherwise, code with -fPIE MUST add
-fsymbolic in GCC 5+, but can't add it prior because the option didn't exist.
Please leave
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Qt would like to optimise libraries by resolving relocations that loop back
into the library in question at link-time, disallowing interposing. The
libraries remain position-independent by always resolving symbols
1 - 100 of 284 matches
Mail list logo
