https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121078
H.J. Lu changed:
What|Removed |Added
Attachment #61909|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121078
--- Comment #6 from H.J. Lu ---
Created attachment 61909
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61909&action=edit
A patch
Try this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121150
--- Comment #2 from H.J. Lu ---
(In reply to Jonathan Wakely from comment #1)
> There is no long anywhere here. The problem is that size_t is 32 bits, and
> using an INT64 suffix won't change that: the value will still be too large
> for size_t.
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
I got
FAIL: 20_util/hash/int128.cc -std=c++17 execution test
with -mx32:
/export/gnu/import/git/sources/gcc/libstdc++-v3/testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120908
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |13.5
Status|NEW
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: rguenther at suse dot de
Blocks: 120003
Target Milestone: ---
For
extern union {
int i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121062
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |16.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121078
--- Comment #3 from H.J. Lu ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #2)
> > --- Comment #1 from H.J. Lu ---
> > Please try
> >
> > https://patchwork.sourceware.org/project/gcc/list/?series=49715
>
> Unfortunately, the tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121078
H.J. Lu changed:
What|Removed |Added
Status|NEW |WAITING
|NEW
Assignee|unassigned at gcc dot gnu.org |hjl.tools at gmail dot
com
Last reconfirmed||2025-07-16
--- Comment #1 from H.J. Lu ---
Please try
https://patchwork.sourceware.org/project/gcc/list/?series=49715
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
--- Comment #24 from H.J. Lu ---
(In reply to Filip Kastl from comment #23)
> testcase.c
> enum { ST, SB, ET, EB, WT, WB }
> LBM_initializeGrid() {
> double *grid;
> grid[ST] = grid[SB] = grid[ET] = grid[EB] =
> grid[WT] = gr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
--- Comment #22 from H.J. Lu ---
(In reply to Filip Kastl from comment #21)
> Oh, ok. I misunderstood.
>
> Well, you have SPEC CPU 2017, right? Then setting
>
No, I don't. Please extract a small testcase.
> OPTIMIZE= -Ofast -march=znve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
--- Comment #20 from H.J. Lu ---
(In reply to Filip Kastl from comment #19)
> Well, if you want to reproduce the lbm slowdown, you need a Zen2 or Zen5
> machine. I'm not sure how I would produce a testcase that would also
> uncover the slowdown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
--- Comment #18 from H.J. Lu ---
(In reply to Filip Kastl from comment #17)
> This is the replacement that causes the slowdown (well, two replacements):
>
> --
> Replace:
>
> (insn 2224 2228 20 (set (reg:V4DF 1604)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121062
--- Comment #5 from H.J. Lu ---
Created attachment 61867
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61867&action=edit
A patch
I am testing this combined patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121015
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
|NEW
Assignee|unassigned at gcc dot gnu.org |hjl.tools at gmail dot
com
Last reconfirmed||2025-07-14
--- Comment #1 from H.J. Lu ---
Created attachment 61859
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61859&action=edit
A patc
ormal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
Target Milestone: ---
Target: x86-64
[hjl@gnu-zen4-1 pr121015]$ cat x.c
typede
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120870
--- Comment #20 from H.J. Lu ---
(In reply to Sam James from comment #19)
> (In reply to Sam James from comment #18)
> > (In reply to H.J. Lu from comment #17)
> > > Created attachment 61837 [details]
> > > A patch
> > >
> > > Please try this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121045
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: hubicka at ucw dot cz
Target Milestone: ---
I got
xg++: error:
/export/gnu/import/git/gitlab/x86-gcc-test/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120870
--- Comment #17 from H.J. Lu ---
Created attachment 61837
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61837&action=edit
A patch
Please try this. No idea why it works for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120870
--- Comment #15 from H.J. Lu ---
(In reply to Sam James from comment #10)
> Created attachment 61824 [details]
> ceval.i.xz
>
> ceval.o is broken.
>
> ```
> $ gcc -c -fno-strict-overflow -O2 -mavx -mtune=znver2 -std=c11
> -fvisibility=hidden -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121015
H.J. Lu changed:
What|Removed |Added
Attachment #61829|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121015
H.J. Lu changed:
What|Removed |Added
Attachment #61827|0 |1
is obsolete|
gcc dot gnu.org |hjl.tools at gmail dot
com
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #4 from H.J. Lu ---
Created attachment 61827
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61827&action=edit
A patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
H.J. Lu changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #15 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
--- Comment #14 from H.J. Lu ---
(In reply to Filip Kastl from comment #11)
> (In reply to H.J. Lu from comment #9)
> > Created attachment 61803 [details]
> > A patch
> >
> > Please try this.
>
> Tried applying this on top of r16-1644-gaba3b9d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119703
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |16.0
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101366
H.J. Lu changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120725
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118276
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120725
Bug 120725 depends on bug 118276, which changed state.
Bug 118276 Summary: memset 88 uses rep stosq while 80 uses SSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118276
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120725
Bug 120725 depends on bug 102294, which changed state.
Bug 102294 Summary: memset expansion is sometimes slow for small sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102294
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120725
Bug 120725 depends on bug 108585, which changed state.
Bug 108585 Summary: memset uses SSE stores but afterwards does not but if used
"" will use them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108585
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108585
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |16.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102294
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120725
Bug 120725 depends on bug 119704, which changed state.
Bug 119704 Summary: x86: partially disobeyed strategy rep-based request for
inlined memset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119704
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120725
Bug 120725 depends on bug 119703, which changed state.
Bug 119703 Summary: x86: spurious branches for inlined memset in ranges (40;
64) when requesting unrolled loops without simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119703
W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119704
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120708
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120725
Bug 120725 depends on bug 101366, which changed state.
Bug 101366 Summary: memset codegen for constant sized does not use SSE
instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101366
What|Removed |Adde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120725
Bug 120725 depends on bug 120708, which changed state.
Bug 120708 Summary: ix86_expand_set_or_cpymem ignores MOVE_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120708
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84719
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |16.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120725
Bug 120725 depends on bug 84719, which changed state.
Bug 84719 Summary: gcc's __builtin_memcpy performance with certain number of
bytes is terrible compared to clang's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84719
What|Remo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70308
H.J. Lu changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120725
Bug 120725 depends on bug 70308, which changed state.
Bug 70308 Summary: memset generates rep stosl instead of rep stosq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70308
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120670
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120725
Bug 120725 depends on bug 120683, which changed state.
Bug 120683 Summary: vector_loop/unrolled_loop generates poor codes on
memset/memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120683
What|Removed |Adde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120683
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
--- Comment #10 from H.J. Lu ---
(In reply to Filip Kastl from comment #8)
> The same commit (r16-1644-gaba3b9d3a48a07) causes ~20% slowdown of 470lbm
> from 2006 SPEC on Zen5 with -Ofast -march=native -flto -fprofile-use.
>
> https://lnt.opens
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
--- Comment #9 from H.J. Lu ---
Created attachment 61803
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61803&action=edit
A patch
Please try this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120900
--- Comment #11 from H.J. Lu ---
(In reply to H.J. Lu from comment #10)
> This makes C similar to C++:
>
> diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
> index 8bbd6ebc66a..0da6c65fc6a 100644
> --- a/gcc/c/c-decl.cc
> +++ b/gcc/c/c-decl.cc
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120683
H.J. Lu changed:
What|Removed |Added
CC||pheeck at gcc dot gnu.org
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 120943, which changed state.
Bug 120943 Summary: [16 Regression] 5% slowdown of 527.cam4_r on Zen{4,5} since
r16-1643-gd073bb6cfc219d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120943
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120943
H.J. Lu changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
H.J. Lu changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120923
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2025-07-03
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120933
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
|1
Status|UNCONFIRMED |WAITING
CC|hjl at gcc dot gnu.org |hjl.tools at gmail dot
com
--- Comment #1 from H.J. Lu ---
Please try:
https://patchwork.sourceware.org/project/gcc/list/?series=48886
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120908
--- Comment #6 from H.J. Lu ---
Fixed for GCC 16 so far
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120933
--- Comment #4 from H.J. Lu ---
(In reply to Florian Weimer from comment #3)
> Yes, compatibility with old glibc is a concern, considering this can be
> difficult to test, and failures can be largely silent.
What are your suggestions?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120936
--- Comment #7 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #5)
> And
> +FAIL: gcc.target/i386/pr120936-10.c check-function-bodies foo
> +FAIL: gcc.target/i386/pr120936-11.c check-function-bodies foo
> +FAIL: gcc.target/i386/pr120936
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120933
--- Comment #2 from H.J. Lu ---
This should be opt-in since it requires glibc fix
https://sourceware.org/bugzilla/show_bug.cgi?id=31372
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120908
H.J. Lu changed:
What|Removed |Added
Summary|*tls_global_dynamic_64_ has an implicit RDI |c_64_ has an implicit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120936
H.J. Lu changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hjl.tools at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120936
H.J. Lu changed:
What|Removed |Added
Summary|x86_function_profiler emits |[12/13/14/15/16 Regression]
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: liuhongt at gcc dot gnu.org
Target Milestone: ---
Target: x86-64
[hjl@gnu-tgl-3 tmp]$ cat t.c
void
foo (void)
{
}
[hjl@gnu-tgl-3 tmp]$ gcc -O2 -pg -S t.c
[hjl@gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81501
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81501
H.J. Lu changed:
What|Removed |Added
Attachment #61788|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
--- Comment #26 from H.J. Lu ---
(In reply to Sam James from comment #25)
> (In reply to H.J. Lu from comment #24)
> > Created attachment 61789 [details]
> > A patch to add --enable-x86-64-mfentry
>
> When wouldn't we want this enabled? Is it j
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: fweimer at redhat dot com
Target Milestone: ---
Target: x86-64
Should -mtls-dialect=gnu2 be default on x86-64 for GCC 16?
||
Attachment #61785|0 |1
is obsolete||
Assignee|unassigned at gcc dot gnu.org |hjl.tools at gmail dot
com
--- Comment #24 from H.J. Lu ---
Created attachment 61789
--> https://gcc.gnu.org/bugzi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120908
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
||
Assignee|unassigned at gcc dot gnu.org |hjl.tools at gmail dot
com
--- Comment #13 from H.J. Lu ---
Created attachment 61788
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61788&action=edit
A patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
--- Comment #22 from H.J. Lu ---
(In reply to H.J. Lu from comment #21)
> Created attachment 61785 [details]
> A patch to warn -pg without -mfentry with shrink wrapping enabled
__fentry__ was added in 2010:
commit d22e4cc9397ed41534c9422d0b0ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
H.J. Lu changed:
What|Removed |Added
Attachment #61784|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
H.J. Lu changed:
What|Removed |Added
Attachment #61783|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
--- Comment #18 from H.J. Lu ---
(In reply to Uroš Bizjak from comment #17)
> (In reply to H.J. Lu from comment #16)
>
> > SHRINK_WRAPPING_ENABLED is for checking if shrink wrapping is enabled.
> True, but we could place mcount at entry only fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
--- Comment #16 from H.J. Lu ---
(In reply to Uroš Bizjak from comment #15)
> Comment on attachment 61783 [details]
> A patch to place mcount at the function entry with shrink
>
> >@@ -493,7 +493,7 @@ ix86_using_red_zone (void)
> > static bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
H.J. Lu changed:
What|Removed |Added
Attachment #61782|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
--- Comment #11 from H.J. Lu ---
(In reply to cuilili from comment #10)
> (In reply to Sam James from comment #9)
> > Thanks both.
> >
> > H.J.'s is slightly less pessimising because it'll only affect functions
> > where we actually emit a call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
--- Comment #8 from H.J. Lu ---
(In reply to cuilili from comment #6)
> Created attachment 61781 [details]
> Disable separate shrink wrapping for profile
>
> How about changing it like this, like shrink wrap.
Looks reasonable. Need tests. Yo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
--- Comment #13 from H.J. Lu ---
This controls where to generate the mount call:
/* Return true, if profiling code should be emitted before
prologue. Otherwise it returns false.
Note: For x86 with "hotfix" it is sorried. */
static bool
i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
--- Comment #12 from H.J. Lu ---
The expected outputs are
[hjl@gnu-zen4-1 pr120881]$ gprof -C a.out
/export/home/hjl/bugs/gcc/pr120881/x.c:3: (f1:0x4004a0) 2000 executions
/export/home/hjl/bugs/gcc/pr120881/x.c:8: (f2:0x4004b0) 1000 executions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
H.J. Lu changed:
What|Removed |Added
Attachment #61780|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
--- Comment #4 from H.J. Lu ---
Created attachment 61780
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61780&action=edit
A patch
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
I'd like to check that "1: callmcount" is placed in the proper place,
like in:
f2:
.LFB0:
.cfi_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
--- Comment #3 from H.J. Lu ---
(In reply to cuilili from comment #2)
> I think it is an old bug, since shrink wrap, NOTE_INSN_PROLOGUE_END does not
> represent the entry bb.
There are
(note 99 98 100 2 NOTE_INSN_PROLOGUE_END)
(insn 100 99 3 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120888
--- Comment #6 from H.J. Lu ---
(In reply to jcmvbkbc from comment #5)
> Thanks, the attachment 61770 [details] fixes almost all regressions
> introduced by the r16-170-ga670ebde3995, except one:
> gfortran.dg/c_char_tests_5.f90 is still broken.
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: liuhongt at gcc dot gnu.org, ubizjak at gmail dot com
Target Milestone: ---
Target: x86-64
There is:
(define_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120902
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120900
H.J. Lu changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Comment #10 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120900
--- Comment #9 from H.J. Lu ---
C++ does
/* If this is a typedef that names the class for linkage purposes
(7.1.3p8), apply any attributes directly to the type. */
if (TREE_CODE (decl) == TYPE_DECL
&& OVERLOAD_TYPE_P (TREE_TYPE (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120900
--- Comment #8 from H.J. Lu ---
C++ builds the canonical type for vector, not for record. C builds both.
onent: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
(gdb) call debug (type)
(gdb) whatis type
type = const_tree
(gdb) call debug_tree (type)
constant 32>
unit-size constant 4>
align:32 warn_if_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120900
H.J. Lu changed:
What|Removed |Added
CC||ubizjak at gmail dot com
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120900
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
1 - 100 of 2993 matches
Mail list logo
