https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81827
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81814
Marek Polacek changed:
What|Removed |Added
Component|tree-optimization |middle-end
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81768
Tom de Vries changed:
What|Removed |Added
Keywords|ice-on-valid-code |ice-on-invalid-code
--- Comment #2 from T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81860
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |7.3
Summary|Call to undefine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81874
Bug ID: 81874
Summary: [6.3/6.4][mips]internal compiler error: in do_SUBST,
at combine.c:725
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81875
Bug ID: 81875
Summary: omp for loop optimized away
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81863
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81875
Tom de Vries changed:
What|Removed |Added
Keywords||patch
--- Comment #1 from Tom de Vries -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81864
Richard Biener changed:
What|Removed |Added
Keywords||build
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81805
--- Comment #10 from Tom de Vries ---
[ Redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01333.html, using PR81875
instead of PR81844, since PR81844 was overwritten ]
Filed comment 3 as PR81875 - omp for loop optimized away
This PR remains fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81867
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81868
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81867
--- Comment #2 from Richard Biener ---
*** Bug 81868 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81869
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81870
--- Comment #3 from Richard Biener ---
(In reply to Petr from comment #2)
> I see, so if I understand it correctly then:
>
> 1. `__builtin_assume_aligned()` should be used to promote the type to a
> higher than natural alignment, for example 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81863
--- Comment #2 from Arnd Bergmann ---
This is a reduced test case that triggers with gcc-4.9 and higher (latest
tested is 7.1.1)
$ arm-linux-gnueabi-gcc-7.1.1 -mword-relocations -march=armv7-a -O2 -Wall -c
test-ww_mutex.c
$ objdump -dr test-ww_m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81814
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81876
Bug ID: 81876
Summary: [7 Regression] bogus -Wstrict-overflow warning with
-O3
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81814
--- Comment #11 from rguenther at suse dot de ---
On Thu, 17 Aug 2017, mpolacek at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81814
>
> Marek Polacek changed:
>
>What|Removed |Add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81814
--- Comment #12 from Marek Polacek ---
Sure, let me see.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81877
Bug ID: 81877
Summary: [7 Regression] Incorrect results with lto and -fipa-cp
and -fipa-cp-clone
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81783
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81876
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81863
--- Comment #3 from Arnd Bergmann ---
The __builtin_prefetch() that caused the problem in the test case from comment
2 might be a red herring, I already noticed earlier that the bug shows up both
in configurations that use a built-in function and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81877
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81863
Yvan Roux changed:
What|Removed |Added
CC||yroux at gcc dot gnu.org
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81864
--- Comment #2 from Andrew Roberts ---
I can confirm gcc 7.2.0 builds ok on x86-64, arm and aarch64 with
--enable-gather-detailed-mem-stats.
So its just 8.0.0 which is failing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878
Bug ID: 81878
Summary: --disable-bootstrap --enable-languages=c,ada fails
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priorit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81877
Martin Liška changed:
What|Removed |Added
CC||enkovich.gnu at gmail dot com
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878
--- Comment #1 from Andreas Schwab ---
In a cross build that would use the build tools, see TOOLS_FLAGS_TO_PASS_NATIVE
vs TOOLS_FLAGS_TO_PASS_CROSS.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81785
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81827
--- Comment #4 from Richard Biener ---
Author: rguenth
Date: Thu Aug 17 10:04:04 2017
New Revision: 251143
URL: https://gcc.gnu.org/viewcvs?rev=251143&root=gcc&view=rev
Log:
2017-08-17 Richard Biener
PR tree-optimization/81827
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81827
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81827
--- Comment #6 from Richard Biener ---
Well, if this program is really supposed to "recursively" allocate all members
where the number of members increases exponentially with the number of levels.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878
Richard Biener changed:
What|Removed |Added
Summary|--disable-bootstrap |--disable-bootstrap
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81389
--- Comment #13 from Marc Glisse ---
(In reply to rockeet from comment #7)
> @Marc @Jakub @Martin
> Intel CPU document says: operand of _mm_cmpestri can be memory or mm
> register, when the operand is memory, it does not require alignment.
That'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878
--- Comment #4 from Richard Biener ---
Btw, it looks even wrong -- the host C++ compiler built some of the objects in
the failing link (libcpp.a). So xg++ might end up linking the wrong
standard library (try building with clang++ and libc++?)
.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878
--- Comment #5 from Richard Biener ---
(In reply to Eric Botcazou from comment #3)
> > I see. I suppose it should use the build tools if not bootstrapping as well
> > (and/or for stage1). Isn't this all set up correctly from the toplevel make
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81818
--- Comment #10 from Andrew Roberts ---
I've attached the output for gcc 7.2.0 with -fmem-report (as
gcc-7.2.0-fmem-report.tar.bz2).
g++ -Ox -fmem-report -c testmap.cpp
where -Ox is one of: -O0, -O1, -O2, -O3, or -O1 -fgcse
This is across: x64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81818
--- Comment #11 from Andrew Roberts ---
Created attachment 41992
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41992&action=edit
gcc-7.2.0 -fmem-report output for arm, aarch64, and x86-64
Output for gcc 7.2.0 with -fmem-report (as gcc-7.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81877
--- Comment #3 from Martin Liška ---
Created attachment 41993
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41993&action=edit
Patch to reduce the problem
Can be reduced by given patch. The function is called for following loop:
:
# b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878
--- Comment #6 from Richard Biener ---
(In reply to Richard Biener from comment #5)
> (In reply to Eric Botcazou from comment #3)
> > > I see. I suppose it should use the build tools if not bootstrapping as
> > > well
> > > (and/or for stage1).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81864
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81877
--- Comment #4 from rguenther at suse dot de ---
On Thu, 17 Aug 2017, marxin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81877
>
> --- Comment #3 from Martin Liška ---
> Created attachment 41993
> --> https://gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81879
Bug ID: 81879
Summary: Bad compilation of small program if LTO is used
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878
--- Comment #7 from Richard Biener ---
Ah, it works when leaving CC alone and only changing CXX. Somewhat
inconsistent I guess. Let me try if bootstrap also still works.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81879
--- Comment #1 from Frediano Ziglio ---
This is weird. If after the
x86_64-w64-mingw32-g++ -flto -O2 -g -save-temps -Wall -Werror -Wextra
-static -mconsole -o test.exe test.cpp
command I run
x86_64-w64-mingw32-g++ -v test.exe.ltrans0.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878
--- Comment #8 from Eric Botcazou ---
> As can be seen in the result:
>
> make[3]: Entering directory '/tmp/obj/gcc/ada/tools'
> gcc -c -g -O2 -W -Wall -gnatpg -gnata -I- -I../rts -I.
> -I/tmp/trunk2/gcc/ada ../rts/s-casuti.adb -o s-casuti.o
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81861
--- Comment #8 from chefmax at gcc dot gnu.org ---
Author: chefmax
Date: Thu Aug 17 11:58:13 2017
New Revision: 251145
URL: https://gcc.gnu.org/viewcvs?rev=251145&root=gcc&view=rev
Log:
2017-08-17 Maxim Ostapenko
PR target/81861
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81864
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81877
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81864
--- Comment #5 from Martin Liška ---
So started with r249991 where a new static variable of hash_table was added.
Well, the implementation of memory statistics is bit fragile as it requires
that static construction of mem_alloc_description X happ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804
Oleg Endo changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #13 from Ole
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81864
--- Comment #6 from Martin Liška ---
Created attachment 41995
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41995&action=edit
Patch candidate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878
--- Comment #9 from Richard Biener ---
Index: Makefile.in
===
--- Makefile.in (revision 251140)
+++ Makefile.in (working copy)
@@ -78,7 +78,7 @@ CXX_LFLAGS = \
# Variables for gnatt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878
--- Comment #10 from Richard Biener ---
Created attachment 41996
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41996&action=edit
patch for the missed optimization
Testing this to address the missed optimization(s). This happens to fix th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81864
--- Comment #7 from Andrew Roberts ---
Works for me on x86-64, trying aarch64 now.
pecs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/path/to/gcc/svn/lib/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-svn/configure --prefix=/path/to/gcc/svn
--disable-multilib --enable-languages=c,c++,fortran
Thread model: posix
gcc version 8.0.0 20170817
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878
--- Comment #11 from Eric Botcazou ---
> ===
> --- Makefile.in (revision 251140)
> +++ Makefile.in (working copy)
> @@ -78,7 +78,7 @@ CXX_LFLAGS = \
> # Variables for gnattools, nat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81879
--- Comment #2 from Frediano Ziglio ---
It seems that this do_widen replacement with an invalid pointer goes on and on,
looking at differences in the generated executable:
--
---: 00 00
---: 48 8b 10mov(%rax),%rdx
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81863
--- Comment #5 from Yvan Roux ---
Thinking more about it, I think that the right place to fix it is in the define
of TARGET_HAVE_MOVT or TARGET_USE_MOVT, but I'm a bit confused with these two
macros.
My understanding of their semantic, is that i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804
--- Comment #14 from Oleg Endo ---
(In reply to Ian Lance Taylor from comment #25)
> I have no particular concerns with dropping the bitfield code, but clearly it
> has to be tested on a couple of little-endian platforms.
Can we try to narrow it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878
--- Comment #12 from Richard Biener ---
Author: rguenth
Date: Thu Aug 17 13:39:58 2017
New Revision: 251150
URL: https://gcc.gnu.org/viewcvs?rev=251150&root=gcc&view=rev
Log:
2017-08-17 Richard Biener
PR ada/81878
* Makefile.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81881
Bug ID: 81881
Summary: [8 Regression] bootstrap failed on x86
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81702
Jan Hubicka changed:
What|Removed |Added
CC||jason at redhat dot com
--- Comment #4 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81877
--- Comment #6 from Richard Biener ---
Created attachment 41998
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41998&action=edit
patch for the missed optimization
Patch I am testing, fixing the missed optimization (and this testcase as a
s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81881
Richard Biener changed:
What|Removed |Added
CC||ubizjak at gmail dot com
Target Miles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81880
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81864
--- Comment #8 from Andrew Roberts ---
aarch64 also ok with gcc-8.0.0 for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81814
--- Comment #13 from Marek Polacek ---
Author: mpolacek
Date: Thu Aug 17 14:33:13 2017
New Revision: 251152
URL: https://gcc.gnu.org/viewcvs?rev=251152&root=gcc&view=rev
Log:
PR middle-end/81814
* fold-const.c (operand_equal_for_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79542
--- Comment #10 from John Marino ---
The original updates by rguenth were lost by the bugzilla-wide data failure,
and the rework only fixed the target milestone. I don't have permission to fix
the missing data, so I'm going to paste the contents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81869
--- Comment #5 from H.J. Lu ---
==19335==
==19335== HEAP SUMMARY:
==19335== in use at exit: 3,187,351,790 bytes in 240,687 blocks
==19335== total heap usage: 10,232,166 allocs, 9,991,479 frees,
177,590,129,479 bytes allocated
==19335==
==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81869
--- Comment #6 from H.J. Lu ---
This
==19335==still reachable: 3,185,786,922 bytes in 240,513 blocks
probably kills 32-bit hosts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81861
Maxim Ostapenko changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81814
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81877
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81877
--- Comment #8 from rguenther at suse dot de ---
On Thu, 17 Aug 2017, amonakov at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81877
>
> Alexander Monakov changed:
>
>What|Removed |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81881
--- Comment #1 from H.J. Lu ---
I can't reproduce it now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81873
Martin Sebor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72804
--- Comment #6 from Peter Bergner ---
Author: bergner
Date: Thu Aug 17 15:56:48 2017
New Revision: 251153
URL: https://gcc.gnu.org/viewcvs?rev=251153&root=gcc&view=rev
Log:
gcc/
PR target/72804
* config/rs6000/vsx.md (*vsx_le_per
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
Eric Gallager changed:
What|Removed |Added
Target||x86_64-apple-darwin17.0.0
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59949
--- Comment #3 from Jonas Jelten ---
This bug is still present in g++ 6.4.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39466
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67075
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71192
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81787
Eric Gallager changed:
What|Removed |Added
Keywords||diagnostic
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80227
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
ARMwbOY
eha92a5z.pdf
Description: Binary data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65870
--- Comment #1 from Jonas Jelten ---
This is probably the same as bug 59949, and still present in 6.4.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81803
--- Comment #5 from James Cowgill ---
I have just noticed this which seems curious. Is the 39 -> 40 combine really a
valid transformation? It seems we've lost the sign extension and we're just
putting a 32-bit value into a 64-bit register without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81859
--- Comment #4 from Martin Sebor ---
Author: msebor
Date: Thu Aug 17 16:50:06 2017
New Revision: 251157
URL: https://gcc.gnu.org/viewcvs?rev=251157&root=gcc&view=rev
Log:
PR c/81859 - [8 Regression] valgrind error from warn_about_normalization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81859
Martin Sebor changed:
What|Removed |Added
Keywords||patch
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78919
--- Comment #1 from Jonas Jelten ---
Probably the same as bug 59949, if the default value is always created for a
template even if the call overwrites the default value.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804
--- Comment #15 from Ian Lance Taylor ---
I mean simply to build the compiler on a couple of little-endian systems using
fp-bit and make sure that the floating point code works correctly. I don't
mean test fp-bit separately, though that's not a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81877
--- Comment #9 from Alexander Monakov ---
I don't understand how LIM may deduce that store sinking is safe without
considering may-alias relations. If it is UB to write the same object from
different declared-independent iterations, then I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81882
Bug ID: 81882
Summary: attribute ifunc documentation uses invalid code
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81882
Martin Sebor changed:
What|Removed |Added
Keywords||documentation
Status|UNCONFIR
1 - 100 of 142 matches
Mail list logo
