Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: j...@jak-linux.org
Target Milestone: ---
Created attachment 38713
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38713&action=edit
C++ reproducer
In contrast to strptime(), std::get_time() r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71556
--- Comment #1 from Julian Andres Klode ---
To be clear, while the attachment uses the (I assume still) non-standard
C.UTF-8, the same also happens with the C locale, and the "" locale in an
en_IE.UTF-8 environment.
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: j...@jak-linux.org
Target Milestone: ---
I only tested this on amd64, but see for yourself:
+ cat t.cc
struct foo {
foo();
~foo();
};
foo *test() {
static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81501
--- Comment #1 from Julian Andres Klode ---
To qualify the performance overhead, I added empty constructors and destructors
with noinline, and compiled the code with g++ and clang++, and then ran a loop
1 over the function.
The clang cod
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: j...@jak-linux.org
Target Milestone: ---
Created attachment 41726
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41726&action=edit
Minimized example
Compiling a rec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81408
--- Comment #1 from Julian Andres Klode ---
Created attachment 41727
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41727&action=edit
preprocessed source of a.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81408
--- Comment #2 from Julian Andres Klode ---
Build log with -v:
Using built-in specs.
COLLECT_GCC=/usr/bin/g++-7
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgvers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81408
--- Comment #3 from Julian Andres Klode ---
7.1.0-9 corresponds to "SVN 20170705 (r250006) from the gcc-7-branch."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81408
--- Comment #4 from Julian Andres Klode ---
Note that apt has 1219 loops, so 134 is almost 11% of the loops causing the
warning, compared to about 0.7% (8) before.
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: j...@jak-linux.org
Target Milestone: ---
Created attachment 40721
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40721&action=edit
Reproducer
We define three macros in APT:
#define APT_IGNORE_DEPRECAT
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: j...@jak-linux.org
Target Milestone: ---
Created attachment 42701
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83139
--- Comment #1 from Julian Andres Klode ---
Created attachment 42702
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42702&action=edit
generated .i file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83139
--- Comment #2 from Julian Andres Klode ---
Apparently, this is because check_path() is being inlined and checks that the
argument is NULL. Then when it sees the second use of pbuf, it considers it
possible that it is NULL.
I'm not sure it's rea
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: j...@jak-linux.org
Target Milestone: ---
In the attached test case, the aarch64 target inserts a uxtb instruction that
is not needed:
ldrbw1, [x0]
orr w1, w1, 32
uxtbw1, w1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77729
--- Comment #2 from Julian Andres Klode ---
Created attachment 39676
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39676&action=edit
Aarch64 output at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77729
--- Comment #1 from Julian Andres Klode ---
Created attachment 39675
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39675&action=edit
C reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77729
--- Comment #3 from Julian Andres Klode ---
Created attachment 39677
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39677&action=edit
arm (thumb2) output at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77729
--- Comment #5 from Julian Andres Klode ---
Created attachment 39678
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39678&action=edit
ppc64le
Hmm, AFAICT the same seems to happen on powerpc64le:
lbz 9,0(3) # L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77729
--- Comment #6 from Julian Andres Klode ---
(In reply to Andrew Pinski from comment #4)
> Note this testcase needs to be improved as I have a patch which converts a
> switch with just one case and a default into anew if statement.
FWIW, The issu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77729
--- Comment #9 from Julian Andres Klode ---
(In reply to Andrew Pinski from comment #8)
> This looks like missing removal of casts.
>
> Note in C, char_var|32 is really the same as ((int)char_var)|32
Well. The loads of the byte are already zero
onent: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@jak-linux.org
Created attachment 22161
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22161
C file
The attached code compiles into an executable that takes 1.6 seconds to run,
when compiled with clang, it tak
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186
--- Comment #1 from Julian Andres Klode 2010-10-26
14:30:24 UTC ---
Created attachment 22162
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22162
Clang's assember
Attaching the assembler output from clang, it should help understand which
op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186
--- Comment #3 from Julian Andres Klode 2010-10-26
14:32:27 UTC ---
System information:
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-5'
--with-bugurl=file:///usr/share/doc/gc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186
--- Comment #5 from Julian Andres Klode 2010-10-26
14:53:24 UTC ---
(In reply to comment #4)
> GCC's output is significantly faster at -O3 or without the noinline attribute
I just tested and at -O3, gcc-4.4 creates slow code and gcc-4.5 fast cod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186
--- Comment #7 from Julian Andres Klode 2010-10-26
15:00:37 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > GCC's output is significantly faster at -O3 or without the noinline
> > attribute
>
> I just tested and at -O3, gcc-4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186
--- Comment #8 from Julian Andres Klode 2010-10-26
15:25:56 UTC ---
(In reply to comment #6)
> You get this kind of speedup if the compiler knows that the result of the loop
> is
>
> sum=(b*(b-1)-a*(a-1))/2
>
> In which case the timing is meani
26 matches
Mail list logo
