Priority: P3
Component: c++
AssignedTo: 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
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
$ cat x.c
#include
#include
$ gcc -c x.c
/usr/lib64/gcc/x86_64-suse-linux/10/include/cpuid.h:228:1: error: redefinition
of ‘__get_cpuid_max’
228 | __get_cpuid_max (unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95483
--- Comment #2 from Thiago Macieira ---
Hello Evan
I was about to report that _mm_loadu_epi16 is missing, but I'm glad you've got
a more complete listing. FYI, here's a Godbolt link showing ICC and Clang with
this intrinsic: https://gcc.godbolt.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90129
Thiago Macieira changed:
What|Removed |Added
CC||thiago at kde dot org
--- Comment #3
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
Godbolt link: https://gcc.godbolt.org/z/bckr_n
Testcase:
#include
struct A;
struct V
{
V() = default;
V(const A &);
A make_a() c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92400
Thiago Macieira changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85577
Thiago Macieira changed:
What|Removed |Added
CC||thiago at kde dot org
--- Comment #8
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
Related to bug 47877 and bug 45065, but apparently different. Issue probably
goes back a long time.
We&#x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92855
--- Comment #3 from Thiago Macieira ---
The symbol in question is inline, therefore -fvisibility-inlines-hidden should
trigger and cause it to become hidden too.
Testcase showing that GCC will apply that:
#define VISIBILITY(x) __attribute__((vi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92855
--- Comment #5 from Thiago Macieira ---
(In reply to Alexander Monakov from comment #4)
> (FWIW, making 'f' a template in your example makes it non-hidden)
>
> Can you explain why you expect the command-line option to override the
> attribute on
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
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56446
--- Comment #3 from Thiago Macieira 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 would happen for a cal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56446
--- Comment #4 from Thiago Macieira 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 changed:
What|Removed |Added
CC||thiago at kde dot org
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 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 %2 %3 %4").arg(42).ar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064
--- Comment #2 from Thiago Macieira 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 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 surprising at
first gl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064
--- Comment #6 from Thiago Macieira 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 like a bug in 4.8.1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064
--- Comment #8 from Thiago Macieira 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();
}
I get:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064
--- Comment #10 from Thiago Macieira 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 without
removing the over
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064
--- Comment #14 from Thiago Macieira 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 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 of code size.
Anyway,
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 changed:
What|Removed |Added
Target|x86_64-*-* i?86-*-* |x86_64-*-* i?86-*-* arm-*-*
-
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
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54202
--- Comment #2 from Thiago Macieira 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). If the driver to th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54202
--- Comment #4 from Thiago Macieira 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 with the
> definitive warn
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 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 2012-08-11 22:33:31
UTC ---
When adding the following source file to the library build:
#include
void bzero_sse2(char *, size_t);
void bzero_avx(char *, size_t);
extern int avx_supported;
void my_bzero(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54231
--- Comment #3 from Thiago Macieira 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 :
340: dec%rsi
343: mov0x2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54231
--- Comment #6 from Thiago Macieira 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 correctly if you p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54231
--- Comment #9 from Thiago Macieira 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 -mavx -msse2, th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54231
--- Comment #10 from Thiago Macieira 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 ("sse2")
#include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54231
--- Comment #11 from Thiago Macieira 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 :
2e0: test %rsi,%r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54231
--- Comment #13 from Thiago Macieira 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 of combining translation
> uni
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54172
--- Comment #4 from Thiago Macieira 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 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 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 havn't seen any
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54485
Thiago Macieira changed:
What|Removed |Added
CC||thiago at kde dot org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54231
--- Comment #14 from Thiago Macieira 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 different target options th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54988
--- Comment #3 from Thiago Macieira 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 backends, the inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43247
--- Comment #10 from Thiago Macieira 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
accessing an array out-of-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43247
--- Comment #12 from Thiago Macieira 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 from the origina
NCONFIRMED
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 in
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: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Source:
$ cat t.c
#include
__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 ---
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 with __attribute__((target("a
ormal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Consider the following code:
#include
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 ---
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);
For non-VEX code, so fa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59539
--- Comment #12 from Thiago Macieira ---
Thanks, rebuilding!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59539
--- Comment #13 from Thiago Macieira ---
I can't confirm. trunk@206091:
$ ~/gcc4.9/bin/gcc -mavx -S -o - -O3 -xc - <<<'#include
int f(void *p1, void *p2)
{
__m128i d1 = _mm_loadu_si128((__m128i*)p1);
__m128i d2 = _mm_loadu_si128((__m128i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59539
--- Comment #14 from Thiago Macieira ---
*facepalm* I had forgotten to make install!
It works:
$ ~/gcc4.9/bin/gcc -mavx -S -o - -O3 -xc - <<<'#include
int f(void *p1, void *p2)
{
__m128i d1 = _mm_loadu_si128((__m128i*)p1);
__m128i d2 = _
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
--- Comment #23 from Thiago Macieira 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 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 foo.c
/usr/b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
--- Comment #30 from Thiago Macieira 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 of this protected function.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83562
--- Comment #3 from Thiago Macieira ---
This can easily be fixed by way of a trampoline that adjusts the parameter.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
Source:
$ cat test.cpp
extern const char str[] = R"(
#define FOO 1
#NOSORT
)";
Compiles just fine:
$ g++ -c test.cpp; echo $?
0
Preprocessed output loo
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89124
--- Comment #1 from Thiago Macieira ---
Worse:
$ cat test.cpp
#include
#ifdef __GNUC__
__attribute__((no_sanitize_address))
#endif
void f(void *ptr)
{
_mm256_loadu_si256((__m256i *)ptr);
}
$ gcc -c -mavx2 test.cpp
[same errors]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89124
--- Comment #2 from Thiago Macieira ---
-fsanitize=address missing from the command-line in the previous comment. It
should be:
gcc -c -mavx2 -fsanitize=address test.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89124
--- Comment #4 from Thiago Macieira ---
Or permit the inlining if the function is also __artificial__. It's documented,
but I don't see anyone needing to use that besides gcc's own headers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71660
--- Comment #19 from Thiago Macieira ---
And Qt has stopped complaining about this.
https://codereview.qt-project.org/227296
ty: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
Created attachment 45793
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45793&action=edit
example showing segmentat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89445
--- Comment #6 from Thiago Macieira ---
(In reply to Jakub Jelinek from comment #4)
> vmovupd (%rsi,%rax), %zmm1{%k1}{z}
> addq%rdx, %rax
> vmovupd (%rax), %zmm2{%k1}{z}
> vfmadd132pd %zmm0, %zmm2, %zmm1
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89445
--- Comment #7 from Thiago Macieira ---
Comment on attachment 45800
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45800
gcc9-pr89445.patch
Tested and works on my machine.
The movzbl that GCC 8 generated is also gone, but it inserted move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89445
--- Comment #8 from Thiago Macieira ---
Sorry, in editing I ended up removing an important point: GCC 8 also generates
the move *from* OpMask when I put it in the benchmark loop. So that's not a
regression, per se.
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
Test:
#include
int f(void *ptr)
{
__m128i data = _mm_loadl_epi64((__m128i *)ptr);
data = _mm_cvtepu8_epi16(data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87522
--- Comment #2 from Thiago Macieira ---
In the original case, all sources were compiled with -march=westmere, though
some files had -mavx added.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69471
Thiago Macieira changed:
What|Removed |Added
CC||thiago at kde dot org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69471
--- Comment #6 from Thiago Macieira ---
Clang is not affected:
$ clang -dM -E -xc /dev/null -march=sandybridge -march=native | grep AVX
#define __AVX2__ 1
#define __AVX__ 1
$ clang -dM -E -xc /dev/null -march=native -march=sandybridge | grep AV
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
In the following code, Clang and ICC emit a very optimal function that consists
of three instructions (including the tail call). MSVC emits a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87976
--- Comment #3 from Thiago Macieira ---
Workaround:
__m128i value64 = _mm_set_epi64x(0, value); // _mm_cvtsi64_si128(value);
asm ("" : "+x" (value64));
__m256i value256 = _mm256_broadcastq_epi64(value64);
++
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
It works in C:
$ cat test.c
__seg_gs char * ptr;
$ gcc -c test.c && echo Success
Success
But not in C++:
$ gcc -xc++ -c test.c
test.c:1:1: error: ‘__seg_gs’ does not nam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69549
--- Comment #1 from Thiago Macieira ---
Bump?
Still happening on 7.0 (built 20160502)
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
When a noexcept function gets optimised with tail-call, the frame disappears so
the unwinder cannot know that the function was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71660
--- Comment #8 from Thiago Macieira ---
(In reply to Peter Cordes from comment #7)
> 8B alignment is required for 8B objects to be efficiently lock-free (using
> SSE load / store for .load() and .store(), see
> https://stackoverflow.com/questions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71660
--- Comment #10 from Thiago Macieira ---
Actually, PR 65146 points out that the problem is not efficiency but
correctness. An under-aligned type could cross a cacheline boundary and thus
fail to be atomic in the first place.
Therefore, it is cor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71660
--- Comment #12 from Thiago Macieira ---
Another problem is that we've now had a couple of years with this issue, so
it's probably worse to make a change again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71660
--- Comment #14 from Thiago Macieira ---
(In reply to Peter Cordes from comment #13)
> If you want a struct with non-atomic members to match the layout of a struct
> with atomic members, do something like
>
> struct foo {
> char c;
> ali
iority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
Testcase (see also https://godbolt.org/g/H2xjNc for GCC and Clang build):
#include
#include
__attribute__((target("sse4.2")))
unsigned aesh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57202
--- Comment #10 from Thiago Macieira ---
> But that's what this bug report is for - to make the intrinsicsalways
available.
I never asked for them to be available in undecorated functions. Yes, that's
how both the Intel and Microsoft compilers b
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
Testcase:
===
[[noreturn]] void qt_assert() noexcept;
inline void qt_noop() {}
void f(int i)
{
switch (i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80460
--- Comment #7 from Thiago Macieira ---
(In reply to Jakub Jelinek from comment #1)
> The warning is done before optimizations (except GENERIC opts), and can
> hardly be done much later.
I imagined it would be the case. Treat this as low priorit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54202
--- Comment #6 from Thiago Macieira ---
ping.
If you can't fix GCC so that it can prove that the free is on a non-heap
object, then please change the warning to indicate that GCC may be wrong. For
example:
warning: free() may be called with non
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
$ cat f1.cpp
#pragma GCC diagnostic ignored "-Wfree-nonheap-object"
void myfree(void *ptr)
{
__builtin_free(ptr);
}
$ cat f2.cpp
void myfree(void *);
static c
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
See this copy of the Intel manual:
https://hjlebbink.github.io/x86doc/html/MOVQ.html (note the typo in the
_mm_move_epi64 intrinsic).
Clang addition: https://reviews.llvm.org/D21504
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
C++17 introduced inline variables and made all static constexpr members be
implicitly inline. With C++14, this code
NCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
$ cat test.cpp
class C {
public:
enum __attribute__((__deprecated__("Do not use"))) MyEn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59952
--- Comment #12 from Thiago Macieira ---
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 ---
(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 ---
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.
--- 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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886
--- Comment #3 from Thiago Macieira ---
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 that for a release or t
1 - 100 of 301 matches
Mail list logo
