[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel and AMD CPUs with AVX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 --- Comment #12 from Jakub Jelinek --- I've posted the patches (so far only lightly tested): https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606021.html https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606022.html It is still Sunday in AoE, so we still have stage1 there.
[Bug other/107634] Very long filenames and URLs for sphinx-based docs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107634 --- Comment #10 from Eric Botcazou --- > About the number of files. Yes, that's the biggest change when it comes to > Sphinx and I see it also as a drawback. However, it's the only valid file > naming scheme supported by Sphinx and there are projects with non-trivial > docs where the average size of a file matches to what we have: The granularity is IMO problematic and will very likely not coax people into updating the documentation (to say the least), which is counter-productive. Why do we need to recursively split sections into sub-sections like this? │ ├── extensions-to-the-c-language-family │ │ ├── 128-bit-integers.rst │ │ ├── additional-floating-types.rst │ │ ├── alternate-keywords.rst │ │ ├── an-inline-function-is-as-fast-as-a-macro.rst │ │ ├── arithmetic-on-void-and-function-pointers.rst │ │ ├── arrays-of-length-zero.rst │ │ ├── arrays-of-variable-length.rst │ │ ├── attribute-syntax.rst │ │ ├── binary-constants-using-the-0b-prefix.rst │ │ ├── built-in-functions-for-memory-model-aware-atomic-operations.rst │ │ ├── built-in-functions-to-perform-arithmetic-with-overflow-checking.rst │ │ ├── c++-style-comments.rst │ │ ├── case-ranges.rst │ │ ├── cast-to-a-union-type.rst │ │ ├── complex-numbers.rst │ │ ├── compound-literals.rst │ │ ├── conditionals-with-omitted-operands.rst │ │ ├── constructing-function-calls.rst │ │ ├── decimal-floating-types.rst │ │ ├── declaring-attributes-of-functions │ │ │ ├── aarch64-function-attributes.rst │ │ │ ├── amd-gcn-function-attributes.rst │ │ │ ├── arc-function-attributes.rst │ │ │ ├── arm-function-attributes.rst │ │ │ ├── avr-function-attributes.rst │ │ │ ├── blackfin-function-attributes.rst │ │ │ ├── bpf-function-attributes.rst │ │ │ ├── c-sky-function-attributes.rst │ │ │ ├── common-function-attributes.rst │ │ │ ├── epiphany-function-attributes.rst │ │ │ ├── h8-300-function-attributes.rst │ │ │ ├── ia-64-function-attributes.rst │ │ │ ├── m32c-function-attributes.rst │ │ │ ├── m32r-d-function-attributes.rst │ │ │ ├── m68k-function-attributes.rst │ │ │ ├── mcore-function-attributes.rst │ │ │ ├── mep-function-attributes.rst │ │ │ ├── microblaze-function-attributes.rst │ │ │ ├── microsoft-windows-function-attributes.rst │ │ │ ├── mips-function-attributes.rst │ │ │ ├── msp430-function-attributes.rst │ │ │ ├── nds32-function-attributes.rst │ │ │ ├── nios-ii-function-attributes.rst │ │ │ ├── nvidia-ptx-function-attributes.rst │ │ │ ├── powerpc-function-attributes.rst │ │ │ ├── risc-v-function-attributes.rst │ │ │ ├── rl78-function-attributes.rst │ │ │ ├── rx-function-attributes.rst │ │ │ ├── s-390-function-attributes.rst │ │ │ ├── sh-function-attributes.rst │ │ │ ├── symbian-os-function-attributes.rst │ │ │ ├── v850-function-attributes.rst │ │ │ ├── visium-function-attributes.rst │ │ │ ├── x86-function-attributes.rst │ │ │ └── xstormy16-function-attributes.rst │ │ ├── declaring-attributes-of-functions.rst │ │ ├── designated-initializers.rst │ │ ├── determining-the-alignment-of-functions-types-or-variables.rst │ │ ├── dollar-signs-in-identifier-names.rst │ │ ├── double-word-integers.rst │ │ ├── enumerator-attributes.rst │ │ ├── fixed-point-types.rst │ │ ├── format-checks-specific-to-particular-target-machines.rst │ │ ├── function-names-as-strings.rst │ │ ├── getting-the-return-or-frame-address-of-a-function.rst │ │ ├── half-precision-floating-point.rst │ │ ├── hex-floats.rst │ │ ├── how-to-use-inline-assembly-language-in-c-code.rst │ │ ├── incomplete-enum-types.rst │ │ ├── label-attributes.rst │ │ ├── labels-as-values.rst │ │ ├── legacy-sync-built-in-functions-for-atomic-memory-access.rst │ │ ├── locally-declared-labels.rst │ │ ├── macros-with-a-variable-number-of-arguments.rst │ │ ├── mixed-declarations-labels-and-code.rst │ │ ├── named-address-spaces.rst │ │ ├── nested-functions.rst │ │ ├── non-constant-initializers.rst │ │ ├── non-lvalue-arrays-may-have-subscripts.rst │ │ ├── nonlocal-gotos.rst │ │ ├── object-size-checking-built-in-functions.rst │ │ ├── other-built-in-functions-provided-by-gcc.rst │ │ ├── pointer-arguments-in-variadic-functions.rst │ │ ├── pointers-to-arrays-with-qualifiers-work-as-expected.rst │ │ ├── pragmas-accepted-by-gcc.rst │ │ ├── prototypes-and-old-style-function-definitions.rst │ │ ├── referring-to-a-type-with-typeof.rst │ │ ├── slightly-looser-rules-for-escaped-newlines.rst │ │ ├── specifying-attributes-of-types.rst │ │ ├── specifying-attributes-of-variables.rst │ │ ├── statement-attributes.rst │ │ ├── statements-and-declarations-in-expressions.rst │ │
[Bug tree-optimization/107672] New: [13 Regression] ICE during GIMPLE pass: slp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107672 Bug ID: 107672 Summary: [13 Regression] ICE during GIMPLE pass: slp Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: creatorsmithmdt at gmail dot com Target Milestone: --- The slp GIMPLE pass now ICE's on this code, which it did not previously. While I am aware GCJ is not currently part of GCC, the GIMPLE it generates is valid and should not be ICE'ing. It does not ICE on O1. This bug occurs on my msterstable branch. (https://github.com/Zopolis4/gcj/commits/msterstable) Given that GCJ is not currently part of GCC, and this bug is thus harder to reproduce as one has to compile my fork, is there a better way for me to report this? Maybe I could just send the generated GIMPLE that ICE's? ~/g/x/libjava> /bin/bash ./libtool --tag=GCJ --mode=compile /home/zopolis4/gcjbuild/./gcc/gcj -B/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava/ -B/home/zopolis4/gcjbuild/./gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem /usr/local/x86_64-pc-linux-gnu/include -isystem /usr/ local/x86_64-pc-linux-gnu/sys-include-fomit-frame-pointer -Usun -fclasspath= -fbootclasspath=/home/zopolis4/gcjbuild/../gcj/libjava/classpath/lib --encoding=UTF-8 -Wno- deprecated -fbootstrap-classes -g -O2 -c -o gnu/java/security/hash.lo -fsource-filename=/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava/classpath/lib/classes -MT gnu/j ava/security/hash.lo -MD -MP -MF gnu/java/security/hash.deps @gnu/java/security/hash.list libtool: compile: /home/zopolis4/gcjbuild/./gcc/gcj -B/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava/ -B/home/zopolis4/gcjbuild/./gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem /usr/local/x86_64-pc-linux-gnu/include -isystem /usr/local/x86_64-pc-linux-gnu/sys-include -fomit-frame-pointer -Usun -fclasspath= -fbootclasspath=/home/zopolis4/gcjbuild/../gcj/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c -fsource-filename=/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava/classpath/lib/classes -MT gnu/java/security/hash.lo -MD -MP -MF gnu/java/security/hash.deps @gnu/java/security/hash.list -fPIC -o gnu/java/security/.libs/hash.o during GIMPLE pass: slp /home/zopolis4/gcj/libjava/classpath/gnu/java/security/hash/Whirlpool.java: In class 'gnu.java.security.hash.Whirlpool': /home/zopolis4/gcj/libjava/classpath/gnu/java/security/hash/Whirlpool.java: In method 'gnu.java.security.hash.Whirlpool.transform(byte[],int)': In file included from /home/zopolis4/gcj/libjava/classpath/gnu/java/security/hash/Tiger.java:863, from /home/zopolis4/gcj/libjava/classpath/gnu/java/security/hash/Sha512.java:277, from /home/zopolis4/gcj/libjava/classpath/gnu/java/security/hash/Sha384.java:275, from /home/zopolis4/gcj/libjava/classpath/gnu/java/security/hash/Sha256.java:248, from /home/zopolis4/gcj/libjava/classpath/gnu/java/security/hash/Sha160.java:239, from /home/zopolis4/gcj/libjava/classpath/gnu/java/security/hash/RipeMD160.java:289, from /home/zopolis4/gcj/libjava/classpath/gnu/java/security/hash/RipeMD128.java:255, from /home/zopolis4/gcj/libjava/classpath/gnu/java/security/hash/MD5.java:369, from /home/zopolis4/gcj/libjava/classpath/gnu/java/security/hash/MD4.java:336, from /home/zopolis4/gcj/libjava/classpath/gnu/java/security/hash/MD2.java:255, from /home/zopolis4/gcj/libjava/classpath/gnu/java/security/hash/IMessageDigest.java:31, from /home/zopolis4/gcj/libjava/classpath/gnu/java/security/hash/Haval.java:805, from /home/zopolis4/gcj/libjava/classpath/gnu/java/security/hash/HashFactory.java:1764, from /home/zopolis4/gcj/libjava/classpath/gnu/java/security/hash/BaseHash.java:437, from :575: /home/zopolis4/gcj/libjava/classpath/gnu/java/security/hash/Whirlpool.java:299: internal compiler error: Segmentation fault 299 | n0 = (in[offset++] & 0xFFL) << 56 | 0xdac2af crash_signal /home/zopolis4/gcjbuild/../gcj/gcc/toplev.cc:314 0x1d10ee7 supportable_widening_operation(vec_info*, tree_code, _stmt_vec_info*, tree_node*, tree_node*, tree_code*, tree_code*, int*, vec*) /home/zopolis4/gcjbuild/../gcj/gcc/tree-vect-stmts.cc:12196 0x1d3094c vectorizable_conversion /home/zopolis4/gcjbuild/../gcj/gcc/tree-vect-stmts.cc:5064 0x1d31a18 vect_analyze_stmt(vec_info*, _stmt_vec_info*, bool*, _slp_tree*, _slp_instance*, vec*) /home/zopolis4/gcjbuild/../gcj/gcc/tree-vect-stmts.cc:11247 0x106344e vect_slp_analyze_node_operations_1
[Bug analyzer/106854] [[gnu::malloc(deallocator)]] for non-pointer functions (e.g., fd)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106854 Sam James changed: What|Removed |Added CC||ericb at gcc dot gnu.org --- Comment #8 from Sam James --- Something similarish came up with gnutls recently: https://gitlab.com/gnutls/gnutls/-/merge_requests/1652#note_1138078435.
[Bug fortran/107669] [13 Regression] commit r13-3931-59a63247992eb13153b82c4902aadf111460eac2 causes lots of testcase failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107669 seurer at gcc dot gnu.org changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #1 from seurer at gcc dot gnu.org --- I am seeing this on powerpc64, too. FAIL: libgomp.fortran/is_device_ptr-2.f90 -O (internal compiler error: in gfc_omp_check_optional_argument, at fortran/trans-openmp.cc:137) FAIL: libgomp.fortran/is_device_ptr-2.f90 -O (test for excess errors) FAIL: libgomp.fortran/optional-map.f90 -O0 (internal compiler error: in gfc_omp_check_optional_argument, at fortran/trans-openmp.cc:137) FAIL: libgomp.fortran/optional-map.f90 -O0 (test for excess errors) FAIL: libgomp.fortran/optional-map.f90 -O1 (internal compiler error: in gfc_omp_check_optional_argument, at fortran/trans-openmp.cc:137) FAIL: libgomp.fortran/optional-map.f90 -O1 (test for excess errors) FAIL: libgomp.fortran/optional-map.f90 -O2 (internal compiler error: in gfc_omp_check_optional_argument, at fortran/trans-openmp.cc:137) FAIL: libgomp.fortran/optional-map.f90 -O2 (test for excess errors) FAIL: libgomp.fortran/optional-map.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error: in gfc_omp_check_optional_argument, at fortran/trans-openmp.cc:137) FAIL: libgomp.fortran/optional-map.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: libgomp.fortran/optional-map.f90 -O3 -g (internal compiler error: in gfc_omp_check_optional_argument, at fortran/trans-openmp.cc:137) FAIL: libgomp.fortran/optional-map.f90 -O3 -g (test for excess errors) FAIL: libgomp.fortran/optional-map.f90 -Os (internal compiler error: in gfc_omp_check_optional_argument, at fortran/trans-openmp.cc:137) FAIL: libgomp.fortran/optional-map.f90 -Os (test for excess errors) FAIL: libgomp.fortran/use_device_addr-1.f90 -O0 (internal compiler error: in gfc_omp_check_optional_argument, at fortran/trans-openmp.cc:137) FAIL: libgomp.fortran/use_device_addr-1.f90 -O0 (test for excess errors) FAIL: libgomp.fortran/use_device_addr-1.f90 -O1 (internal compiler error: in gfc_omp_check_optional_argument, at fortran/trans-openmp.cc:137) FAIL: libgomp.fortran/use_device_addr-1.f90 -O1 (test for excess errors) FAIL: libgomp.fortran/use_device_addr-1.f90 -O2 (internal compiler error: in gfc_omp_check_optional_argument, at fortran/trans-openmp.cc:137) FAIL: libgomp.fortran/use_device_addr-1.f90 -O2 (test for excess errors) FAIL: libgomp.fortran/use_device_addr-1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error: in gfc_omp_check_optional_argument, at fortran/trans-openmp.cc:137) FAIL: libgomp.fortran/use_device_addr-1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: libgomp.fortran/use_device_addr-1.f90 -O3 -g (internal compiler error: in gfc_omp_check_optional_argument, at fortran/trans-openmp.cc:137) FAIL: libgomp.fortran/use_device_addr-1.f90 -O3 -g (test for excess errors) FAIL: libgomp.fortran/use_device_addr-1.f90 -Os (internal compiler error: in gfc_omp_check_optional_argument, at fortran/trans-openmp.cc:137) FAIL: libgomp.fortran/use_device_addr-1.f90 -Os (test for excess errors) FAIL: libgomp.fortran/use_device_addr-2.f90 -O0 (internal compiler error: in gfc_omp_check_optional_argument, at fortran/trans-openmp.cc:137) FAIL: libgomp.fortran/use_device_addr-2.f90 -O0 (test for excess errors) FAIL: libgomp.fortran/use_device_addr-2.f90 -O1 (internal compiler error: in gfc_omp_check_optional_argument, at fortran/trans-openmp.cc:137) FAIL: libgomp.fortran/use_device_addr-2.f90 -O1 (test for excess errors) FAIL: libgomp.fortran/use_device_addr-2.f90 -O2 (internal compiler error: in gfc_omp_check_optional_argument, at fortran/trans-openmp.cc:137) FAIL: libgomp.fortran/use_device_addr-2.f90 -O2 (test for excess errors) FAIL: libgomp.fortran/use_device_addr-2.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error: in gfc_omp_check_optional_argument, at fortran/trans-openmp.cc:137) FAIL: libgomp.fortran/use_device_addr-2.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: libgomp.fortran/use_device_addr-2.f90 -O3 -g (internal compiler error: in gfc_omp_check_optional_argument, at fortran/trans-openmp.cc:137) FAIL: libgomp.fortran/use_device_addr-2.f90 -O3 -g (test for excess errors) FAIL: libgomp.fortran/use_device_addr-2.f90 -Os (internal compiler error: in gfc_omp_check_optional_argument, at fortran/trans-openmp.cc:137) FAIL: libgomp.fortran/use_device_addr-2.f90 -Os (test for excess errors)
[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel and AMD CPUs with AVX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 Xi Ruoyao changed: What|Removed |Added Summary|gcc and libatomic can use |gcc and libatomic can use |SSE for 128-bit atomic |SSE for 128-bit atomic |loads on Intel CPUs with|loads on Intel and AMD CPUs |AVX |with AVX Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-11-14
[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel CPUs with AVX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 --- Comment #11 from Sam James --- (In reply to GGanesh from comment #10) > Can we extend this patch to AMD processors as well. If not, I will plan to > submit the patch for stage-1! GCC 13 (as of today) is in stage 3 - see https://gcc.gnu.org/develop.html, but it may or may not still be possible to submit it (not my call).
[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349 --- Comment #44 from Andrew Downing --- (In reply to Richard Biener from comment #43) > (In reply to Andrew Downing from comment #41) > > > Thus for types without a non-trivial ctor/dtor you do not need to use > > > placement new. So take your example and remove the placement new. > > > Does that change its semantics? > > > > These are C++17 rules. > > > > 4.5/1) An object is created by a definition, by a new-expression, when > > implicitly changing the active member of a union, or when a temporary object > > is created. > > > > 6.8/1) The lifetime of an object of type T begins when: storage with the > > proper alignment and size for type T is obtained, and if the object has > > non-vacuous initialization, its initialization is complete. > > > > double d; > > > > My interpretation of the above rules would be that only a double object is > > created in the storage for d because T in 6.8/1 is set to double by the > > definition of d. According to these rules the only way to change the dynamic > > type of the object in d's storage would be with placement new (pre C++20). > > memcpy only overwrites the object representation. It doesn't affect it's > > type or lifetime. > > What would > > *(long *) = 1; > > do? My reading of earlier standards say it starts lifetime of a new object > of type long (the storage of 'd' gets reused). Following that stmt a read > like > > foo (d); > > invokes undefined behavior (it accesses the storage of effective type long > via an effective type of double). The same example with placement new > would be > > *(new () long) = 1; > > and I'm arguing the placement new is not required to start the lifetime > of an object of type long in the storage of 'd'. It's been a while since I've though about this stuff. double d; *(long *) = 1; That would be lead to undefined behavior because it's breaking the strict aliasing rules. *(new () long) = 1; That would be ok because new creates a long object in the storage of d before dereferencing.
[Bug libstdc++/105611] std::shift_left/right should not use ranges::next
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105611 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-11-14
[Bug target/107671] i386: Missed optimization: use of bt in bit test pattern (using -O2 -mtune=core2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107671 --- Comment #2 from Iain Buclaw --- Expected generated code would be: --- bt32_setb*: ... shrl$5, %edx movl(%eax,%edx,4), %edx xorl%eax, %eax btl %ecx, %edx setb%al ... --- bt32_setae*: ... shrl$5, %edx movl(%eax,%edx,4), %edx xorl%eax, %eax btl %ecx, %edx setae %al ... --- bt32v_setb*: ... xorl%eax, %eax btl %esi, %edi setb%al ... --- bt32v_setae*: ... xorl%eax, %eax btl %esi, %edi setae %al ... --- bt64_setb*: ... shrq$6, %rax movq(%rdi,%rax,8), %rcx xorl%eax, %eax btq %rsi, %rcx setb%al ... --- bt64_setae*: ... shrq$6, %rax movq(%rdi,%rax,8), %rcx xorl%eax, %eax btq %rsi, %rcx setae %al ... --- bt64v_setb*: ... xorl%eax, %eax btq %rsi, %rdi setb%al ... --- bt64v_setae*: ... xorl%eax, %eax btq %rsi, %rdi setae %al ...
[Bug target/107671] i386: Missed optimization: use of bt in bit test pattern (using -O2 -mtune=core2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107671
--- Comment #1 from Iain Buclaw ---
Non-pointer variants also not detected.
---
int bt32v_setb(const __UINT32_TYPE__ v, __UINT32_TYPE__ bitnum)
{
return ((v & (1 << (bitnum & 31 != 0;
}
int bt64v_setb(const __UINT64_TYPE__ v, __UINT64_TYPE__ bitnum)
{
return ((v & (1L << (bitnum & 63 != 0;
}
int bt32v_setb2(const __UINT32_TYPE__ v, __UINT32_TYPE__ bitnum)
{
return (v >> (bitnum & 31)) & 1;
}
int bt64v_setb2(const __UINT64_TYPE__ v, __UINT64_TYPE__ bitnum)
{
return (v >> (bitnum & 63)) & 1;
}
int bt32v_setae(const __UINT32_TYPE__ v, __UINT32_TYPE__ bitnum)
{
return ((v & (1 << (bitnum & 31 == 0;
}
int bt64v_setae(const __UINT64_TYPE__ v, __UINT64_TYPE__ bitnum)
{
return ((v & (1L << (bitnum & 63 == 0;
}
int bt32v_setae2(const __UINT32_TYPE__ v, __UINT32_TYPE__ bitnum)
{
return !((v >> (bitnum & 31)) & 1);
}
int bt64v_setae2(const __UINT64_TYPE__ v, __UINT64_TYPE__ bitnum)
{
return !((v >> (bitnum & 63)) & 1);
}
[Bug target/107671] New: i386: Missed optimization: use of bt in bit test pattern when LHS is an array index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107671
Bug ID: 107671
Summary: i386: Missed optimization: use of bt in bit test
pattern when LHS is an array index
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
int bt32_setb(const __UINT32_TYPE__ *p, __UINT32_TYPE__ bitnum)
{
return ((p[bitnum >> 5] & (1 << (bitnum & 31 != 0;
}
int bt64_setb(const __UINT64_TYPE__ *p, __UINT64_TYPE__ bitnum)
{
return ((p[bitnum >> 6] & (1L << (bitnum & 63 != 0;
}
int bt32_setb2(const __UINT32_TYPE__ *p, __UINT32_TYPE__ bitnum)
{
return (p[bitnum >> 5] >> (bitnum & 31)) & 1;
}
int bt64_setb2(const __UINT64_TYPE__ *p, __UINT64_TYPE__ bitnum)
{
return (p[bitnum >> 6] >> (bitnum & 63)) & 1;
}
int bt32_setae(const __UINT32_TYPE__ *p, __UINT32_TYPE__ bitnum)
{
return ((p[bitnum >> 5] & (1 << (bitnum & 31 == 0;
}
int bt64_setae(const __UINT64_TYPE__ *p, __UINT64_TYPE__ bitnum)
{
return ((p[bitnum >> 6] & (1L << (bitnum & 63 == 0;
}
int bt32_setae2(const __UINT32_TYPE__ *p, __UINT32_TYPE__ bitnum)
{
return !((p[bitnum >> 5] >> (bitnum & 31)) & 1);
}
int bt64_setae2(const __UINT64_TYPE__ *p, __UINT64_TYPE__ bitnum)
{
return !((p[bitnum >> 6] >> (bitnum & 63)) & 1);
}
[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel CPUs with AVX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 GGanesh changed: What|Removed |Added CC||Ganesh.Gopalasubramanian@am ||d.com --- Comment #10 from GGanesh --- Apologies for late response! We would update the AMD APM manuals in the next revision. For all AMD architectures, Processors that support AVX extend the atomicity for cacheable, naturally-aligned single loads or stores from a quadword to a double quadword. which means all 128b instructions, even the *MOVDQU instructions, are atomic if they end up being naturally aligned. Can we extend this patch to AMD processors as well. If not, I will plan to submit the patch for stage-1!
[Bug ipa/107670] New: Suspicious redundant code in ipa-cp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107670 Bug ID: 107670 Summary: Suspicious redundant code in ipa-cp Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: fxue at os dot amperecomputing.com CC: marxin at gcc dot gnu.org Target Milestone: --- Function "ipa_prop_read_jump_functions()" in ipa-prop.c: ipa_check_create_node_params (); ipa_check_create_edge_args (); These two are also called inside the immediately following statement: ipa_register_cgraph_hooks(); Function "ipa_fn_summary_read()" in ipa-fnsummary.cc: ipa-cp's hooks will be registered twice in this function. One is indirectly done by ipa_prop_read_jump_functions(), and the other is by a nearby call to ipa_register_cgraph_hooks.
[Bug fortran/107669] New: [13 Regression] commit r13-3931-59a63247992eb13153b82c4902aadf111460eac2 causes lots of testcase failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107669 Bug ID: 107669 Summary: [13 Regression] commit r13-3931-59a63247992eb13153b82c4902aadf111460eac2 causes lots of testcase failure Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: haochen.jiang at intel dot com Target Milestone: --- After commit r13-3931-59a63247992eb13153b82c4902aadf111460eac2, we got lots of failure in the following libgomp.fortran testcases. libgomp.fortran/is_device_ptr-2.f90 libgomp.fortran/optional-map.f90 libgomp.fortran/use_device_addr-1.f90 libgomp.fortran/use_device_addr-2.f90 libgomp.fortran/use_device_ptr-optional-2.f90 libgomp.fortran/use_device_ptr-optional-3.f90 libgomp.oacc-fortran/optional-data-copyin-by-value.f90 They all got ICE like this: internal compiler error: in gfc_omp_check_optional_argument, at fortran/trans-openmp.cc:137. You might also get an email sent by my script later.
[Bug analyzer/106235] RFE: -fanalyzer could complain about tainted data triggering assertion failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106235 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from David Malcolm --- Implemented for GCC 13 by the above patch.
[Bug analyzer/106235] RFE: -fanalyzer could complain about tainted data triggering assertion failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106235
--- Comment #3 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:d777b38cde91a87f2345dcd13901862a9513562a
commit r13-3947-gd777b38cde91a87f2345dcd13901862a9513562a
Author: David Malcolm
Date: Sun Nov 13 17:53:23 2022 -0500
analyzer: new warning: -Wanalyzer-tainted-assertion [PR106235]
This patch adds a new -Wanalyzer-tainted-assertion warning to
-fanalyzer's "taint" mode (which also requires -fanalyzer-checker=taint).
It complains about attacker-controlled values being used in assertions,
or in any expression affecting control flow that guards a "noreturn"
function. As noted in the docs part of the patch, in such cases:
- when assertion-checking is enabled: an attacker could trigger
a denial of service by injecting an assertion failure
- when assertion-checking is disabled, such as by defining NDEBUG,
an attacker could inject data that subverts the process, since it
presumably violates a precondition that is being assumed by the code.
For example, given:
#include
int __attribute__((tainted_args))
test_tainted_assert (int n)
{
assert (n > 0);
return n * n;
}
compiling with
-fanalyzer -fanalyzer-checker=taint
gives:
t.c: In function 'test_tainted_assert':
t.c:6:3: warning: use of attacked-controlled value in condition for
assertion [CWE-617] [-Wanalyzer-tainted-assertion]
6 | assert (n > 0);
| ^~
'test_tainted_assert': event 1
|
|4 | test_tainted_assert (int n)
| | ^~~
| | |
| | (1) function 'test_tainted_assert' marked with
'__attribute__((tainted_args))'
|
+--> 'test_tainted_assert': event 2
|
|4 | test_tainted_assert (int n)
| | ^~~
| | |
| | (2) entry to 'test_tainted_assert'
|
'test_tainted_assert': events 3-6
|
|/usr/include/assert.h:106:10:
| 106 | if (expr)
\
| | ^
| | |
| | (3) use of attacker-controlled value for
control flow
| | (4) following 'false' branch (when 'n <=
0')...
|..
| 109 | __assert_fail (#expr, __FILE__, __LINE__,
__ASSERT_FUNCTION); \
| | ~
| | |
| | (5) ...to here
| | (6) treating '__assert_fail' as an assertion
failure handler due to '__attribute__((__noreturn__))'
|
The testcases have various examples for BUG and BUG_ON from the
Linux kernel; there, the diagnostic treats "panic" as an assertion
failure handler, due to '__attribute__((__noreturn__))'.
gcc/analyzer/ChangeLog:
PR analyzer/106235
* analyzer.opt (Wanalyzer-tainted-assertion): New.
* checker-path.cc (checker_path::fixup_locations): Pass false to
pending_diagnostic::fixup_location.
* diagnostic-manager.cc (get_emission_location): Pass true to
pending_diagnostic::fixup_location.
* pending-diagnostic.cc (pending_diagnostic::fixup_location): Add
bool param.
* pending-diagnostic.h (pending_diagnostic::fixup_location): Add
bool param to decl.
* sm-taint.cc (taint_state_machine::m_tainted_control_flow): New.
(taint_diagnostic::describe_state_change): Drop "final".
(class tainted_assertion): New.
(taint_state_machine::taint_state_machine): Initialize
m_tainted_control_flow.
(taint_state_machine::alt_get_inherited_state): Support
comparisons being tainted, based on their arguments.
(is_assertion_failure_handler_p): New.
(taint_state_machine::on_stmt): Complain about calls to assertion
failure handlers guarded by an attacker-controller conditional.
Detect attacker-controlled gcond conditionals and gswitch index
values.
(taint_state_machine::check_control_flow_arg_for_taint): New.
gcc/ChangeLog:
PR analyzer/106235
* doc/gcc/gcc-command-options/option-summary.rst: Add
-Wno-analyzer-tainted-assertion.
*
doc/gcc/gcc-command-options/options-that-control-static-analysis.rst:
Add -Wno-analyzer-tainted-assertion.
gcc/testsuite/ChangeLog:
PR analyzer/106235
* gcc.dg/analyzer/taint-assert-BUG_ON.c: New test.
* gcc.dg/analyzer/taint-assert-macro-expansion.c:
[Bug libstdc++/104167] Implement C++20 std::chrono::utc_clock, std::chrono::tzdb etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104167 --- Comment #2 from Jonathan Wakely --- Patch for time zones and incomplete formatting support: https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605926.html
[Bug tree-optimization/107668] [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107668
--- Comment #2 from David Binderman ---
Reduced C++ code seems to be:
--- /home/dcb36/cvise/bug862.cc ---
float dot();
float intersectcylinder_md;
void intersectcylinder(float ) {
float nd = dot();
dist = 0 / nd;
float offset = intersectcylinder_md + dist;
if (offset < 0)
dist = nd;
}
[Bug tree-optimization/107668] [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107668 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #1 from David Binderman --- I see this also in C++ code with flags -O1 -march=znver3 -ffast-math. The problem first seems to occur sometime between git hash 52672be7d328df50 and 05432288d4e56055, some 28 commits later. I have a cvise job running.
[Bug analyzer/106235] RFE: -fanalyzer could complain about tainted data triggering assertion failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106235 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-11-13 Ever confirmed|0 |1 --- Comment #2 from David Malcolm --- Testing a patch for this...
[Bug fortran/94104] Request for diagnostic improvement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94104 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |13.0 --- Comment #6 from anlauf at gcc dot gnu.org --- Fixed for gcc-13. Closing. Thanks for the patch!
[Bug libstdc++/107660] Running binaries compiled with g++11 or later produces different results than g++ version 10 or earlier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107660 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #4) > std::mt19937 r11-4535-g822c1d21a3c710 Hmm, this might be expected
[Bug fortran/94104] Request for diagnostic improvement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94104 --- Comment #5 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:58e7732a2feddf475e72b232bf16494d84a41acf commit r13-3946-g58e7732a2feddf475e72b232bf16494d84a41acf Author: José Rui Faustino de Sousa Date: Wed Nov 9 21:30:25 2022 +0100 Fortran: diagnostics for actual arguments to pointer dummy arguments [PR94104] Error message improvement. In Fortran 2008 actual procedure arguments associated with a pointer, intent(in) attribute, dummy argument can also have the target attribute, not just pointer. gcc/fortran/ChangeLog: PR fortran/94104 * interface.cc (gfc_compare_actual_formal): Improve error message dependent on Fortran standard level. gcc/testsuite/ChangeLog: PR fortran/94104 * gfortran.dg/parens_2.f90: Adjust to improved error message. * gfortran.dg/PR94104a.f90: New test. * gfortran.dg/PR94104b.f90: New test.
[Bug c++/107660] Running binaries compiled with g++11 or later produces different results than g++ version 10 or earlier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107660 --- Comment #4 from Andrew Pinski --- std::mt19937
[Bug c++/97052] Internal compiler error with substitution failure in template parameter list of concept declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97052 Andrew Pinski changed: What|Removed |Added CC||wjwray at gmail dot com --- Comment #6 from Andrew Pinski --- *** Bug 107662 has been marked as a duplicate of this bug. ***
[Bug c++/107662] [10 concepts] ICE using concept with dependent template parameter to define variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107662 Andrew Pinski changed: What|Removed |Added Known to fail||9.5.0 Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 97052. *** This bug has been marked as a duplicate of bug 97052 ***
[Bug c++/107662] [10 concepts] ICE using concept with dependent template parameter to define variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107662 --- Comment #1 from Andrew Pinski --- Created attachment 53894 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53894=edit testcase Next time please paste the testcase instead of just a link to godbolt .
[Bug web/107650] Sphinx generated web pages don't have "up" (to the section TOC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107650 --- Comment #4 from Andrew Pinski --- (In reply to Martin Liška from comment #3) > (In reply to Andrew Pinski from comment #0) > > The texinfo generated HTML has an up link which links to the section that > > the page is linked from. > > While the Sphinx generated HTML does not. > > An example for texinfo is > > https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/eBPF-Options.html#eBPF-Options > > compared to > > https://gcc.gnu.org/onlinedocs/gcc/gcc-command-options/machine-dependent- > > options/ebpf-options.html . > > > > Is there a way to get this feature back? as it is useful when browsing the > > manual. > > No, I don't think it was useful as one was missing complete navigation that > is right now on the left. Except the navigation does not fully replace the up button. An example is if you scroll down on the top level TOC down to the "Nios II Options" (not on the navigation on the left) and click it. The navigation on the left does not scroll down to the same location. Making it harder to figure out where you are. > > > > > The other thing that would be a nice feature back is having next/previous/up > > links at the start also and not just at the end of the page. > > > > The order of previous and next on the bottom of the page is ok even though > > it is swapped from what it was previously. > > The layout is better in Sphinx as it corresponds to expect layout (similarly > to web browsers). So that is broken. Having it on the top and the bottom is still useful. Maybe you clicked the wrong link but it was the next one you either have to use the left/right links at the buttom or you have to understand the left/right curser keys are bound to previous/next page. Again still confusing. Most web UI designers have ignored UI design for years how humans work and just make broken things we should not repeat the same mistakes.
[Bug middle-end/107656] post sphinx conversion, can't tell between a target macro or a target hook
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107656 --- Comment #3 from Andrew Pinski --- (In reply to Martin Liška from comment #2) > Yes, it's a small drawback. IT IS NOT A SMALL DRAWBACK. It is a huge one really. Especially when a new developer is trying to write a backend, they can't figure out if it was a target hook or a target macro one is. The return type is only part is not described anywhere to say it is the difference either. Epsecially when reading each of these sections seperately. I only noticed this because I am going to try to improve the documentation on some of these and this caught my eye and made me even more confused (I looked at the new documentation first and I was wait isn't one a target hook and then I had to go look at the previous texinfo documentation to see that was true).
[Bug web/107651] Having two different kind of indexes is very useful still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107651 --- Comment #12 from Andrew Pinski --- Created attachment 53893 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53893=edit Screen shot of the index When I see a row like these rows, I think __builtin_mips_any_cabs_cond_ps (C++ function) is related to _Complex keyword but they are 100% not related at all.
[Bug web/107651] Having two different kind of indexes is very useful still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107651 --- Comment #11 from Andrew Pinski --- (In reply to Martin Liška from comment #10) > > But the sphinx generated index is not very useful as it lists all options > > under symbols heading which is very confusing to programmers. > > It's a minor limitation, one can still jump to individual listings of > options: > https://gcc.gnu.org/onlinedocs/gcc/gcc-command-options.html That is a TOC and NOT an index. IT IS NOT A MINOR LIMITATION. Compare this to the texinfo generated one: https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Option-Index.html (yes the f and m is still combined) But the - is ignored. Plus the layout of the index is better. The two parrallel columns of the sphinx generated index is also bad because the order is first column then the second which means scrolling back up for the wrapping. IS there a way to fix that? Plus when I saw symbol I was thinking function/variable name and not -,&,etc. The texinfo generated index splits out the symbols even which seems like sphinx should be able to do too which will improve the look slightly. Searching is not just about knowing keywords but looking into similar named things which is another reason why the two column for the generated index is bad idea.
[Bug tree-optimization/107668] New: [13 Regression] ICE: in clear_nan, at value-range.h:1167 with -fsanitize=float-cast-overflow and _Complex int
loat.cc:1904 0x2568f53 float_binary_op_range_finish /repo/gcc-trunk/gcc/range-op-float.cc:1886 0x2568f53 foperator_mult::op1_range(frange&, tree_node*, frange const&, frange const&, relation_trio) const /repo/gcc-trunk/gcc/range-op-float.cc:2143 0x24414d7 gori_compute::compute_operand1_range(vrange&, gimple_range_op_handler&, vrange const&, tree_node*, fur_source&, value_relation*) /repo/gcc-trunk/gcc/gimple-range-gori.cc:1095 0x2440193 gori_compute::compute_operand_range(vrange&, gimple*, vrange const&, tree_node*, fur_source&, value_relation*) /repo/gcc-trunk/gcc/gimple-range-gori.cc:692 0x2441e2f gori_compute::compute_operand2_range(vrange&, gimple_range_op_handler&, vrange const&, tree_node*, fur_source&, value_relation*) /repo/gcc-trunk/gcc/gimple-range-gori.cc:1243 0x24408ca gori_compute::compute_operand_range(vrange&, gimple*, vrange const&, tree_node*, fur_source&, value_relation*) /repo/gcc-trunk/gcc/gimple-range-gori.cc:694 0x2441e2f gori_compute::compute_operand2_range(vrange&, gimple_range_op_handler&, vrange const&, tree_node*, fur_source&, value_relation*) /repo/gcc-trunk/gcc/gimple-range-gori.cc:1243 0x24423b2 gori_compute::compute_operand1_and_operand2_range(vrange&, gimple_range_op_handler&, vrange const&, tree_node*, fur_source&, value_relation*) /repo/gcc-trunk/gcc/gimple-range-gori.cc:1263 0x2440ac0 gori_compute::compute_operand_range(vrange&, gimple*, vrange const&, tree_node*, fur_source&, value_relation*) /repo/gcc-trunk/gcc/gimple-range-gori.cc:689 0x2441553 gori_compute::compute_operand1_range(vrange&, gimple_range_op_handler&, vrange const&, tree_node*, fur_source&, value_relation*) /repo/gcc-trunk/gcc/gimple-range-gori.cc:1150 0x2440193 gori_compute::compute_operand_range(vrange&, gimple*, vrange const&, tree_node*, fur_source&, value_relation*) /repo/gcc-trunk/gcc/gimple-range-gori.cc:692 0x243fe91 gori_compute::compute_logical_operands(vrange&, vrange&, gimple_range_op_handler&, irange const&, tree_node*, fur_source&, tree_node*, bool) /repo/gcc-trunk/gcc/gimple-range-gori.cc:935 0x2440750 gori_compute::compute_operand_range(vrange&, gimple*, vrange const&, tree_node*, fur_source&, value_relation*) /repo/gcc-trunk/gcc/gimple-range-gori.cc:674 0x2441553 gori_compute::compute_operand1_range(vrange&, gimple_range_op_handler&, vrange const&, tree_node*, fur_source&, value_relation*) /repo/gcc-trunk/gcc/gimple-range-gori.cc:1150 0x2440193 gori_compute::compute_operand_range(vrange&, gimple*, vrange const&, tree_node*, fur_source&, value_relation*) /repo/gcc-trunk/gcc/gimple-range-gori.cc:692 0x2443ee2 gori_compute::outgoing_edge_range_p(vrange&, edge_def*, tree_node*, range_query&) /repo/gcc-trunk/gcc/gimple-range-gori.cc:1373 0x2434dee ranger_cache::edge_range(vrange&, edge_def*, tree_node*, ranger_cache::rfd_mode) /repo/gcc-trunk/gcc/gimple-range-cache.cc:964 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See https://gcc.gnu.org/bugs/ for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-3944-20221113164720-g43435c7eb0f-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r13-3944-20221113164720-g43435c7eb0f-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.0.0 20221113 (experimental) (GCC)
[Bug web/107650] Sphinx generated web pages don't have "up" (to the section TOC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107650 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- (In reply to Andrew Pinski from comment #0) > The texinfo generated HTML has an up link which links to the section that > the page is linked from. > While the Sphinx generated HTML does not. > An example for texinfo is > https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/eBPF-Options.html#eBPF-Options > compared to > https://gcc.gnu.org/onlinedocs/gcc/gcc-command-options/machine-dependent- > options/ebpf-options.html . > > Is there a way to get this feature back? as it is useful when browsing the > manual. No, I don't think it was useful as one was missing complete navigation that is right now on the left. > > The other thing that would be a nice feature back is having next/previous/up > links at the start also and not just at the end of the page. > > The order of previous and next on the bottom of the page is ok even though > it is swapped from what it was previously. The layout is better in Sphinx as it corresponds to expect layout (similarly to web browsers).
[Bug middle-end/107656] post sphinx conversion, can't tell between a target macro or a target hook
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107656 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org Last reconfirmed||2022-11-13 --- Comment #2 from Martin Liška --- Yes, it's a small drawback. One can distinguish macros by missing return type, but I can imagine adding a .. note:: Target macro for such macros that have arguments. These w/o arguments are hopefully distinguishable from hooks.
[Bug c/107653] how-to-use-inline-assembly-language-in-c-code page is huge and should be split up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107653 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2022-11-13 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org CC||marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- Confirmed, the shared doc/md.rst file is shared in between gcc and gccint manual, where md.rst contains many ' .. only:: gccint' directives. But yes, we should split it a bit.
[Bug web/107651] Having two different kind of indexes is very useful still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107651 --- Comment #10 from Martin Liška --- > But the sphinx generated index is not very useful as it lists all options > under symbols heading which is very confusing to programmers. It's a minor limitation, one can still jump to individual listings of options: https://gcc.gnu.org/onlinedocs/gcc/gcc-command-options.html Plus, there's a built-in search capability that can point you to an option if you know the name.
[Bug web/107651] Having two different kind of indexes is very useful still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107651 --- Comment #9 from Andrew Pinski --- (In reply to Martin Liška from comment #8) > You can quickly find 'vectorize' option in the sphinx version of the Index. But the sphinx generated index is not very useful as it lists all options under symbols heading which is very confusing to programmers.
[Bug web/107643] [13 Regression] sphinx generated indexes are not working at all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107643 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #14 from Martin Liška --- Ok, so it's possible with a small workaround: https://stackoverflow.com/questions/36235578/how-can-i-include-the-genindex-in-a-sphinx-toc
[Bug web/107643] [13 Regression] sphinx generated indexes are not working at all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107643 --- Comment #13 from Andrew Pinski --- (In reply to Martin Liška from comment #12) > (In reply to Andrew Pinski from comment #11) > > (In reply to CVS Commits from comment #8) > > > > > It is confusing that 'Indexes and tables' contains TODO. One gets > > > Index by clicking to the Index link. > > > > I don't see an Index link. There is no link to the top TOC anywhere either. > > Can you see the mouse pointer on the screenshot? It points to a hyperlink > called Index. What's still missing? It is so little compared to anything else on the screen, it can't be seen. And why not a direct link from the TOC?
[Bug other/107634] Very long filenames and URLs for sphinx-based docs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107634 --- Comment #9 from Andrew Pinski --- (In reply to Martin Liška from comment #7) > c-behavior/architecture.rst > c-behavior/arrays-and-pointers.rst > c-behavior/characters.rst > c-behavior/declarators.rst > c-behavior/environment.rst > c-behavior/floating-point.rst > c-behavior/hints.rst > c-behavior/identifiers.rst > c-behavior/integers.rst > c-behavior/library-functions.rst > c-behavior/locale-specific-behavior.rst > c-behavior/preprocessing-directives.rst > c-behavior/qualifiers.rst > c-behavior/statements.rst > c-behavior/compount-types.rst > c-behavior/translation.rst Is there a way to get C implementation defined behavior in one source file which gets split up is better? That would make it easier to modify and no need for the longer file names there. > ./c++-implementation-defined-behavior.rst > ./conditionally-supported-behavior.rst > ./exception-handling.rst Likewise for the C++ implementation defined behavior which right now you have listed as on the toplevel when it is not. > c++-extensions/backwards-compatibility.rst Just Why not ext instead of extensions (at least remove the s). > c++-extensions/c++-concepts.rst concepts > c++-extensions/interface-and-impl-pragmas.rst template-pragmas > c++-extensions/var-and-type-attrs.rst > c++-extensions/deprecated-features.rst Just deprecated. > c++-extensions/function-pointer.rst func-ptr > c++-extensions/function-multiversioning.rst multiversioning > c++-extensions/restricting-pointer-aliasing.rst restrict > c++-extensions/type-traits.rst > c++-extensions/vague-linkage.rst > c++-extensions/volatile.rst > c++-extensions/wheres-the-template.rst > ./c++-extensions.rst > c-extensions/128-bit-integers.rst again c-ext 128bit-int > c-extensions/additional-floating-types.rst float-types > c-extensions/alternate-keywords.rst > c-extensions/inline-function.rst inline > c-extensions/void-fns-arithmetic.rst void-funcs-addition > c-extensions/arrays-of-length-zero.rst zero length arrays > c-extensions/arrays-of-variable-length.rst variable length array > c-extensions/attribute-syntax.rst attributes > c-extensions/0b-prefix-arithmetic.rst 0b literals > c-extensions/memory-model-builtins.rst atomics > c-extensions/arithmetic-overflow-builtins.rst just overflow > c-extensions/c++-style-comments.rst line comments > c-extensions/case-ranges.rst > c-extensions/cast-to-a-union-type.rst union-cast > c-extensions/complex-numbers.rst complex > c-extensions/compound-literals.rst > c-extensions/omitted-operands-conditionals.rst > c-extensions/constructing-fn-calls.rst > c-extensions/decimal-floating-types.rst dfp > c-extensions/function-attrs/aarch64.rst > c-extensions/function-attrs/amd-gcn.rst > c-extensions/function-attrs/arc.rst > c-extensions/function-attrs/arm.rst > c-extensions/function-attrs/avr.rst > c-extensions/function-attrs/blackfin.rst > c-extensions/function-attrs/bpf.rst > c-extensions/function-attrs/c-sky.rst > c-extensions/function-attrs/common.rst > c-extensions/function-attrs/epiphany.rst > c-extensions/function-attrs/h8-300.rst > c-extensions/function-attrs/ia-64.rst > c-extensions/function-attrs/m32c.rst > c-extensions/function-attrs/m32r-d.rst > c-extensions/function-attrs/m68k.rst > c-extensions/function-attrs/mcore.rst > c-extensions/function-attrs/mep.rst > c-extensions/function-attrs/microblaze.rst > c-extensions/function-attrs/microsoft-windows.rst > c-extensions/function-attrs/mips.rst > c-extensions/function-attrs/msp430.rst > c-extensions/function-attrs/nds32.rst > c-extensions/function-attrs/nios-ii.rst > c-extensions/function-attrs/nvidia-ptx.rst > c-extensions/function-attrs/powerpc.rst > c-extensions/function-attrs/risc-v.rst > c-extensions/function-attrs/rl78.rst > c-extensions/function-attrs/rx.rst > c-extensions/function-attrs/s-390.rst > c-extensions/function-attrs/sh.rst > c-extensions/function-attrs/symbian-os.rst > c-extensions/function-attrs/v850.rst > c-extensions/function-attrs/visium.rst > c-extensions/function-attrs/x86.rst > c-extensions/function-attrs/xstormy16.rst target-attr > c-extensions/function-attrs.rst > c-extensions/designated-initializers.rst > c-extensions/fn-and-var-alignment.rst > c-extensions/dollar-signs.rst > c-extensions/double-word-integers.rst > c-extensions/enumerator-attributes.rst > c-extensions/fixed-point-types.rst > c-extensions/target-format-checks.rst > c-extensions/function-names-as-strings.rst > c-extensions/fn-frame-address.rst > c-extensions/half-precision-floating-point.rst > c-extensions/hex-floats.rst > c-extensions/inline-assembly.rst > c-extensions/incomplete-enum-types.rst > c-extensions/label-attributes.rst > c-extensions/labels-as-values.rst > c-extensions/legacy-memory-atomics.rst legacy-sync-atomics > c-extensions/locally-declared-labels.rst > c-extensions/variadic-macros.rst > c-extensions/mixed-declarations-labels.rst > c-extensions/named-address-spaces.rst >
[Bug other/107634] Very long filenames and URLs for sphinx-based docs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107634 --- Comment #8 from Martin Liška --- About the number of files. Yes, that's the biggest change when it comes to Sphinx and I see it also as a drawback. However, it's the only valid file naming scheme supported by Sphinx and there are projects with non-trivial docs where the average size of a file matches to what we have: gcc manual: TOTAL files: 312 Total LOC: 68643 Average LOC: 220 Median LOC: 104 linux kernel: TOTAL files: 3198 Total LOC: 649105 Average LOC: 202 Median LOC: 485 godot game engine: === TOTAL files: 1262 Total LOC: 308497 Average LOC: 244 Median LOC: 325 coreboot: === TOTAL files: 354 Total LOC: 36916 Average LOC: 104 Median LOC: 139 Note the GCC manual contains many target-specific sections and I don't believe they should be presented at a single HTML page: extensions-to-the-c-language-family/declaring-attributes-of-functions/ - 35 files extensions-to-the-c-language-family/target-builtins/ - 36 files gcc-command-options/machine-dependent-options/ - 62 files Where I can imagine merging the files are following sub-folders: extensions-to-the-c++-language/backwards-compatibility.rst [27] extensions-to-the-c++-language/c++-concepts.rst [44] extensions-to-the-c++-language/c++-interface-and-implementation-pragmas.rst [97] extensions-to-the-c++-language/c++-specific-variable-function-and-type-attributes.rst [95] extensions-to-the-c++-language/deprecated-features.rst [43] extensions-to-the-c++-language/extracting-the-function-pointer-from-a-bound-pointer-to-member-function.rst [48] extensions-to-the-c++-language/function-multiversioning.rst [65] extensions-to-the-c++-language/restricting-pointer-aliasing.rst [52] extensions-to-the-c++-language/type-traits.rst [165] extensions-to-the-c++-language/vague-linkage.rst [80] extensions-to-the-c++-language/when-is-a-volatile-c++-object-accessed.rst [58] extensions-to-the-c++-language/wheres-the-template.rst [131] ./extensions-to-the-c++-language.rst [34] c-implementation-defined-behavior/architecture.rst [47] c-implementation-defined-behavior/arrays-and-pointers.rst [46] c-implementation-defined-behavior/characters.rst [93] c-implementation-defined-behavior/declarators.rst [14] c-implementation-defined-behavior/environment.rst [18] c-implementation-defined-behavior/floating-point.rst [88] c-implementation-defined-behavior/hints.rst [35] c-implementation-defined-behavior/identifiers.rst [28] c-implementation-defined-behavior/integers.rst [66] c-implementation-defined-behavior/library-functions.rst [19] c-implementation-defined-behavior/locale-specific-behavior.rst [12] c-implementation-defined-behavior/preprocessing-directives.rst [54] c-implementation-defined-behavior/qualifiers.rst [53] c-implementation-defined-behavior/statements.rst [14] c-implementation-defined-behavior/structures-unions-enumerations-and-bit-fields.rst [78] c-implementation-defined-behavior/translation.rst [20] ./c-implementation-defined-behavior.rst [46] gnu-objective-c-features/compatibilityalias.rst [26] gnu-objective-c-features/constant-string-objects.rst [64] gnu-objective-c-features/exceptions.rst [79] gnu-objective-c-features/fast-enumeration.rst [221] gnu-objective-c-features/garbage-collection.rst [81] gnu-objective-c-features/gnu-objective-c-runtime-api.rst [98] gnu-objective-c-features/load-executing-code-before-main.rst [141] gnu-objective-c-features/messaging-with-the-gnu-objective-c-runtime.rst [145] gnu-objective-c-features/synchronization.rst [36] gnu-objective-c-features/type-encoding.rst [280] known-causes-of-trouble-with-gcc/actual-bugs-we-havent-fixed-yet.rst [14] known-causes-of-trouble-with-gcc/certain-changes-we-dont-want-to-make.rst [236] known-causes-of-trouble-with-gcc/common-misunderstandings-with-gnu-c.rst [296] known-causes-of-trouble-with-gcc/disappointments-and-misunderstandings.rst [102] known-causes-of-trouble-with-gcc/fixed-header-files.rst [39] known-causes-of-trouble-with-gcc/incompatibilities-of-gcc.rst [233] known-causes-of-trouble-with-gcc/interoperation.rst [153] known-causes-of-trouble-with-gcc/standard-libraries.rst [33] known-causes-of-trouble-with-gcc/warning-messages-and-error-messages.rst [46] language-standards-supported-by-gcc/c++-language.rst [71] language-standards-supported-by-gcc/c-language.rst [139] language-standards-supported-by-gcc/d-language.rst [11] language-standards-supported-by-gcc/go-language.rst [10] language-standards-supported-by-gcc/objective-c-and-objective-c++-languages.rst [62] language-standards-supported-by-gcc/references-for-other-languages.rst [13] That's a reduction of ~50 files. To be honest, the split is mandatory thing and there's not much I can do about it. Just a note for the old .texi files: we used to have files (./gcc/doc/invoke.texi ./gcc/doc/extend.texi, ./gcc/fortran/intrinsic.texi) that tend to have 1000s of lines which is not ideal either.
[Bug web/107643] [13 Regression] sphinx generated indexes are not working at all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107643 --- Comment #12 from Martin Liška --- (In reply to Andrew Pinski from comment #11) > (In reply to CVS Commits from comment #8) > > > It is confusing that 'Indexes and tables' contains TODO. One gets > > Index by clicking to the Index link. > > I don't see an Index link. There is no link to the top TOC anywhere either. Can you see the mouse pointer on the screenshot? It points to a hyperlink called Index. What's still missing?
[Bug other/107634] Very long filenames and URLs for sphinx-based docs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107634 --- Comment #7 from Martin Liška --- So first to the original issue reported by David. Yes, the filenames were selected based on chapter's caption and thus some of them are very long. For gcc documentation, I'm suggesting following name scheme where the entire path since base folder (gcc/doc/gcc) should be at maximum 50 characters w/o .rst extension: ./binary-compatibility.rst ./c++-implementation-defined-behavior.rst c-behavior/architecture.rst c-behavior/arrays-and-pointers.rst c-behavior/characters.rst c-behavior/declarators.rst c-behavior/environment.rst c-behavior/floating-point.rst c-behavior/hints.rst c-behavior/identifiers.rst c-behavior/integers.rst c-behavior/library-functions.rst c-behavior/locale-specific-behavior.rst c-behavior/preprocessing-directives.rst c-behavior/qualifiers.rst c-behavior/statements.rst c-behavior/compount-types.rst c-behavior/translation.rst ./c-behavior.rst ./conditionally-supported-behavior.rst ./contributing.rst ./contributors.rst ./copyright.rst ./exception-handling.rst c++-extensions/backwards-compatibility.rst c++-extensions/c++-concepts.rst c++-extensions/interface-and-impl-pragmas.rst c++-extensions/var-and-type-attrs.rst c++-extensions/deprecated-features.rst c++-extensions/function-pointer.rst c++-extensions/function-multiversioning.rst c++-extensions/restricting-pointer-aliasing.rst c++-extensions/type-traits.rst c++-extensions/vague-linkage.rst c++-extensions/volatile.rst c++-extensions/wheres-the-template.rst ./c++-extensions.rst c-extensions/128-bit-integers.rst c-extensions/additional-floating-types.rst c-extensions/alternate-keywords.rst c-extensions/inline-function.rst c-extensions/void-fns-arithmetic.rst c-extensions/arrays-of-length-zero.rst c-extensions/arrays-of-variable-length.rst c-extensions/attribute-syntax.rst c-extensions/0b-prefix-arithmetic.rst c-extensions/memory-model-builtins.rst c-extensions/arithmetic-overflow-builtins.rst c-extensions/c++-style-comments.rst c-extensions/case-ranges.rst c-extensions/cast-to-a-union-type.rst c-extensions/complex-numbers.rst c-extensions/compound-literals.rst c-extensions/omitted-operands-conditionals.rst c-extensions/constructing-fn-calls.rst c-extensions/decimal-floating-types.rst c-extensions/function-attrs/aarch64.rst c-extensions/function-attrs/amd-gcn.rst c-extensions/function-attrs/arc.rst c-extensions/function-attrs/arm.rst c-extensions/function-attrs/avr.rst c-extensions/function-attrs/blackfin.rst c-extensions/function-attrs/bpf.rst c-extensions/function-attrs/c-sky.rst c-extensions/function-attrs/common.rst c-extensions/function-attrs/epiphany.rst c-extensions/function-attrs/h8-300.rst c-extensions/function-attrs/ia-64.rst c-extensions/function-attrs/m32c.rst c-extensions/function-attrs/m32r-d.rst c-extensions/function-attrs/m68k.rst c-extensions/function-attrs/mcore.rst c-extensions/function-attrs/mep.rst c-extensions/function-attrs/microblaze.rst c-extensions/function-attrs/microsoft-windows.rst c-extensions/function-attrs/mips.rst c-extensions/function-attrs/msp430.rst c-extensions/function-attrs/nds32.rst c-extensions/function-attrs/nios-ii.rst c-extensions/function-attrs/nvidia-ptx.rst c-extensions/function-attrs/powerpc.rst c-extensions/function-attrs/risc-v.rst c-extensions/function-attrs/rl78.rst c-extensions/function-attrs/rx.rst c-extensions/function-attrs/s-390.rst c-extensions/function-attrs/sh.rst c-extensions/function-attrs/symbian-os.rst c-extensions/function-attrs/v850.rst c-extensions/function-attrs/visium.rst c-extensions/function-attrs/x86.rst c-extensions/function-attrs/xstormy16.rst c-extensions/function-attrs.rst c-extensions/designated-initializers.rst c-extensions/fn-and-var-alignment.rst c-extensions/dollar-signs.rst c-extensions/double-word-integers.rst c-extensions/enumerator-attributes.rst c-extensions/fixed-point-types.rst c-extensions/target-format-checks.rst c-extensions/function-names-as-strings.rst c-extensions/fn-frame-address.rst c-extensions/half-precision-floating-point.rst c-extensions/hex-floats.rst c-extensions/inline-assembly.rst c-extensions/incomplete-enum-types.rst c-extensions/label-attributes.rst c-extensions/labels-as-values.rst c-extensions/legacy-memory-atomics.rst c-extensions/locally-declared-labels.rst c-extensions/variadic-macros.rst c-extensions/mixed-declarations-labels.rst c-extensions/named-address-spaces.rst c-extensions/nested-functions.rst c-extensions/non-constant-initializers.rst c-extensions/non-lvalue-arrays.rst c-extensions/nonlocal-gotos.rst c-extensions/object-size-builtins.rst c-extensions/other-fn-builtins.rst c-extensions/pointer-arg-in-var-fns.rst c-extensions/qualified-array-pointers.rst c-extensions/pragmas-accepted-by-gcc.rst c-extensions/prototypes-and-old-style-fns.rst c-extensions/typeof-reference.rst c-extensions/escaped-newlines-rules.rst c-extensions/type-attrs.rst c-extensions/var-attrs.rst c-extensions/statement-attributes.rst
[Bug web/107650] Sphinx generated web pages don't have "up" (to the section TOC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107650 --- Comment #2 from Andrew Pinski --- Index is different from TOC. The up should goto the section TOC and not the index of the section.
[Bug web/107643] [13 Regression] sphinx generated indexes are not working at all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107643 --- Comment #11 from Andrew Pinski --- (In reply to CVS Commits from comment #8) > It is confusing that 'Indexes and tables' contains TODO. One gets > Index by clicking to the Index link. I don't see an Index link. There is no link to the top TOC anywhere either.
[Bug other/107655] [meta-bug] tracker bug for issues encountered in the texinfo-to-sphinx migration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107655 Bug 107655 depends on bug 107643, which changed state. Bug 107643 Summary: [13 Regression] sphinx generated indexes are not working at all https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107643 What|Removed |Added Status|RESOLVED|NEW Resolution|FIXED |---
[Bug web/107643] [13 Regression] sphinx generated indexes are not working at all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107643 Andrew Pinski changed: What|Removed |Added Status|RESOLVED|NEW Resolution|FIXED |--- --- Comment #10 from Andrew Pinski --- Still not fixed. The "Indexes and tables" page still does NOT link the index.
[Bug web/107643] [13 Regression] sphinx generated indexes are not working at all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107643 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Martin Liška --- Closing now.
[Bug other/107655] [meta-bug] tracker bug for issues encountered in the texinfo-to-sphinx migration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107655 Bug 107655 depends on bug 107643, which changed state. Bug 107643 Summary: [13 Regression] sphinx generated indexes are not working at all https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107643 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug web/107643] [13 Regression] sphinx generated indexes are not working at all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107643 --- Comment #8 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:c64fd69420fd153f9fb16a603ff0a711fbde8335 commit r13-3942-gc64fd69420fd153f9fb16a603ff0a711fbde8335 Author: Martin Liska Date: Sun Nov 13 15:16:12 2022 +0100 sphinx: include todolist only if INCLUDE_TODO env. set It is confusing that 'Indexes and tables' contains TODO. One gets Index by clicking to the Index link. PR web/107643 ChangeLog: * doc/baseconf.py: Set include_todo tag if INCLUDE_TODO env is set. * doc/indices-and-tables.rst: Use include_todo tag.
[Bug ipa/107667] IPA: Speculatively reuse existing specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107667 --- Comment #1 from Christoph Müllner --- RFC patch can be found on list: https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605936.html
[Bug ipa/107666] IPA: Speculatively dereferencing function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107666 --- Comment #1 from Christoph Müllner --- RFC patch can be found on list: https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605934.html
[Bug other/107655] [meta-bug] tracker bug for issues encountered in the texinfo-to-sphinx migration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107655 Bug 107655 depends on bug 107620, which changed state. Bug 107620 Summary: Build errors when using sphinx https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107620 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug other/107620] Build errors when using sphinx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107620 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Martin Liška --- > > I found that using that allowed me to build html documentation. However I > seemed to need in addition a whole bunch of stuff to build latex and pdf > documentation. Yes, these dependencies are usually installed if you install python3-Sphinx-latex package.
[Bug other/107620] Build errors when using sphinx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107620 --- Comment #5 from Martin Liška --- > Is the above error due to not installing sphinx 5.3.0? Yes, and you should get a better message now. > I assumed installing sphinx 5.3.0 would help, but after installing sphinx > 5.3.0, I get a different error: > > Extension error: > Could not import extension gcc_sphinx (exception: No module named > 'gcc_sphinx') > Makefile:84: recipe for target 'info' failed Should be fixed with r13-3871-g70f1c41061b2b5.
[Bug other/107620] Build errors when using sphinx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107620 --- Comment #4 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:5e749ee3019d7917184af30dab8d09c933c0a4a1 commit r13-3940-g5e749ee3019d7917184af30dab8d09c933c0a4a1 Author: Martin Liska Date: Sun Nov 13 15:07:17 2022 +0100 configure: always set SPHINX_BUILD During the Sphinx-migration development, I used SPHINX_BUILD='' in order to skip building info and manual pages in gcc folder. However, we've got HAS_SPHINX_BUILD which is the correct flag for that. With the patch, one will get a nicer error message when sphinx-build is missing and one builds (explicitly) a target which depends on it. PR other/107620 gcc/ChangeLog: * configure: Regenerate. * configure.ac: Always set sphinx-build. libgomp/ChangeLog: * configure: Regenerate. * configure.ac: Always set sphinx-build. libiberty/ChangeLog: * configure: Regenerate. * configure.ac: Always set sphinx-build. libitm/ChangeLog: * configure: Regenerate. * configure.ac: Always set sphinx-build. libquadmath/ChangeLog: * configure: Regenerate. * configure.ac: Always set sphinx-build.
[Bug ipa/107667] New: IPA: Speculatively reuse existing specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107667 Bug ID: 107667 Summary: IPA: Speculatively reuse existing specializations Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: christophm30 at gmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- This is a feature request, not a bug report. GCC already does an excellent job in specializing functions in ipa-cp. Such specialized functions often result in much faster execution because the additional information enables additional optimizations (e.g. vectorization). Different call sites can have different specializations and some call sites might not get specialized at all. When looking at the not-specialized call sites, there is one strategy that can be applied: add guards to test if existing specializations can be reused and if so call them. Such an optimization has to be built into ipa-cp and collects all specialized functions, and the constants that are propagated. At the end of the propagation stage, the call graph is changed to add speculative edges to the specialized functions with guards that test if the actual arguments match the constants. To demonstrate the effect, let's consider the following program part: func_1() myfunc(1) func_2() myfunc(2) func_i(i) myfunc(i) In this case the transformation would do the following: func_1() myfunc.constprop.1() // myfunc() with arg0 == 1 func_2() myfunc.constprop.2() // myfunc() with arg0 == 2 func_i(i) if (i == 1) myfunc.constprop.1() // myfunc() with arg0 == 1 else if (i == 2) myfunc.constprop.2() // myfunc() with arg0 == 2 else myfunc(i) Similar to `-devirtualize-speculatively`, such an optimization can be gated using a flag (e.g. `-fipa-guarded-specialization`). One example where this optimization would trigger is x264 (also part of CPU2017), where the function pointer `get_ref` is assigned a single time during startup, and then called multiple times with constant arguments (8 or 16) or with "unknown" arguments which are actually matching the constants at runtime. In combination with PR ipa/107666 (which converts the function pointers into guarded direct calls), this allows propagating the constants into `pixel_avg`, where (limited as documented in PR 106352) vectorization will be enabled.
[Bug ipa/107666] New: IPA: Speculatively dereferencing function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107666 Bug ID: 107666 Summary: IPA: Speculatively dereferencing function pointers Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: christophm30 at gmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- This is a feature request, not a bug report. GCC already does speculative call graph optimizations (ipa-devirt does so when enabled via -fdevirtualize-speculatively). The idea is to identify virtual functions that will most likely always have the same target, which cannot be (easily) proven, and convert them into direct calls. A major benefit is that direct calls can be optimized by ipa-cp. The idea is applicable to function pointers as well: identify indirect calls, which most likely will call the same target, and convert them into guarded direct calls. Given the existing infrastructure to add speculative edges, we only need to focus on "strongly believe". One approach would be to do the following: * Analysis 1: Collection of function pointer type assignments (e.g. p->cb = mycb ==> field "cb" of record points to function "mycb") * Analysis 2: Collection of indirect calls (e.g. p->cb() ==> field "cb" of record is used in a the analysed function) * Propagation: Iterate over indirect calls and lookup possible function pointer type assignments; If one is available, then convert it into a speculative (guarded) direct call. * Transformation: Use existing infrastructure to emit guarded direct calls (gimple_ic). Similar to `-devirtualize-speculatively`, such an optimization can be gated using a flag (e.g. `-fipa-guarded-deref`). One example where this optimization would trigger is x264 (also part of CPU2017), where the function pointer `get_ref` is assigned a single time during startup, and then called multiple times with constant arguments (8 or 16). Dereferencing these function pointers would allow further optimization if propagated by ipa-cp.
[Bug middle-end/107661] [13 Regression] lambdas get merged incorrectly in tempaltes, cause llvm-12 miscompilation since r13-3358-ge0403e95689af7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107661 Martin Jambor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org Last reconfirmed||2022-11-13 --- Comment #6 from Martin Jambor --- Interesting, I'll have a look.
[Bug middle-end/107661] [13 Regression] lambdas get merged incorrectly in tempaltes, cause llvm-12 miscompilation since r13-3358-ge0403e95689af7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107661 Sergei Trofimovich changed: What|Removed |Added Summary|[13 Regression] lambdas get |[13 Regression] lambdas get |merged incorrectly in |merged incorrectly in |tempaltes, cause llvm-12|tempaltes, cause llvm-12 |miscompilation |miscompilation since ||r13-3358-ge0403e95689af7 --- Comment #5 from Sergei Trofimovich --- Bisected down to r13-3358-ge0403e95689af7 (looks very relevant): commit e0403e95689af7d562c7d04f706e9e25115747ff Author: Martin Jambor Date: Tue Oct 18 14:14:26 2022 +0200 ipa-cp: Better representation of aggregate values we clone for This patch replaces linked lists of ipa_agg_replacement_value with vectors of similar structures called ipa_argagg_value and simplifies how we compute them in the first place. Having a vector should also result in less overhead when allocating and because we keep it sorted, it leads to logarithmic searches. The slightly obnoxious "argagg" bit in the name can be changed into "agg" after the next patch removes our current ipa_agg_value type. The patch also introduces type ipa_argagg_value_list which serves as a common view into a vector of ipa_argagg_value structures regardless whether they are stored in GC memory (required for IPA-CP transformation summary because we store trees) or in an auto_vec which is hopefully usually only allocated on stack. The calculation of aggreagete costant values for a given subsert of callers is then rewritten to compute known constants for each edge (some pruning to skip obviously not needed is still employed and should not be really worse than what I am replacing) and these vectors are there intersected, which can be done linearly since they are sorted. The patch also removes a lot of heap allocations of small lists of aggregate values and replaces them with stack based auto_vecs. As Richard Sandiford suggested, I use std::lower_bound from rather than re-implementing bsearch for array_slice. The patch depends on the patch which adds the ability to construct array_slices from gc-allocated vectors.
[Bug web/107643] [13 Regression] sphinx generated indexes are not working at all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107643 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-11-13 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #7 from Martin Liška --- (In reply to Andrew Pinski from comment #5) > How is this invalid when the docs still say todo on them? Oh, this one. The 'TODO' refers to todolist extension which lists all todos in the documentation and is excluded in the non-development version of the documentation. Anyway, I'm going to remove it.
[Bug web/107651] Having two different kind of indexes is very useful still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107651 --- Comment #8 from Martin Liška --- (In reply to Andrew Pinski from comment #6) > Also search bars are not very useful if you say searching for an option and > it turns up non option related stuff. It's not searching only options, but also in titles and content of pages. > An example of that is you search for vectorize you it turns up the extension > page. > > Indexes are useful for searching and researching and having the options all > in one place. You can quickly find 'vectorize' option in the sphinx version of the Index.
[Bug web/107651] Having two different kind of indexes is very useful still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107651 --- Comment #7 from Martin Liška --- (In reply to Andrew Pinski from comment #3) > Your index page has both options and symbols intermixed and not two > different pages. Funny how you said one thing and it is exact opposite. Index page contains everything: Titles, all directives and stuff that is marked with '.. index:' directive. What did I say is exact opposite, can you explain it, please? > Also that page is not linked anywhere from the site. It is linked: https://gcc.gnu.org/onlinedocs/gcc/indices-and-tables.html# As I showed in the screenshot. We can put it directly to https://gcc.gnu.org/onlinedocs/gcc/indices-and-tables.html if we want. > > Oh also the formatting on some of things looks off. Look at x86 and you will > see what I am talking about. Yes, it's the result of the conversion, where 'x86' is commonly used in '.. index:' directives.
[Bug web/107651] Having two different kind of indexes is very useful still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107651 --- Comment #6 from Andrew Pinski --- Also search bars are not very useful if you say searching for an option and it turns up non option related stuff. An example of that is you search for vectorize you it turns up the extension page. Indexes are useful for searching and researching and having the options all in one place.
[Bug web/107651] Having two different kind of indexes is very useful still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107651 --- Comment #5 from Andrew Pinski --- Oh wait I just realized that symbol here is -. That is just useless. And even not ignoring f or m as part of the option in the index will also be useless and just having parts in m and f.
[Bug web/107651] Having two different kind of indexes is very useful still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107651 --- Comment #4 from Andrew Pinski --- Symbols are listed separately but again not on a separate page. Plus the two columns make it difficult to read on mobile. Again this still different from my request too.
[Bug other/107655] [meta-bug] tracker bug for issues encountered in the texinfo-to-sphinx migration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107655 Bug 107655 depends on bug 107651, which changed state. Bug 107651 Summary: Having two different kind of indexes is very useful still https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107651 What|Removed |Added Status|RESOLVED|NEW Resolution|INVALID |---
[Bug web/107651] Having two different kind of indexes is very useful still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107651 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|NEW Ever confirmed|0 |1 Last reconfirmed||2022-11-13 --- Comment #3 from Andrew Pinski --- Your index page has both options and symbols intermixed and not two different pages. Funny how you said one thing and it is exact opposite. Also that page is not linked anywhere from the site. Oh also the formatting on some of things looks off. Look at x86 and you will see what I am talking about.
[Bug web/107643] [13 Regression] sphinx generated indexes are not working at all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107643 --- Comment #6 from Andrew Pinski --- (In reply to Martin Liška from comment #3) > The preferred way of searching is using the Search text input on the left. > It works very well. Expect if you don't know the name of an option reading the index is important.
[Bug other/107655] [meta-bug] tracker bug for issues encountered in the texinfo-to-sphinx migration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107655 Bug 107655 depends on bug 107643, which changed state. Bug 107643 Summary: [13 Regression] sphinx generated indexes are not working at all https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107643 What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |---
[Bug web/107643] [13 Regression] sphinx generated indexes are not working at all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107643 Andrew Pinski changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #5 from Andrew Pinski --- How is this invalid when the docs still say todo on them?
[Bug middle-end/107498] Wrong optimization leads to unaligned access when compiling OpenLDAP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107498 --- Comment #11 from Eric Botcazou --- > FWIW, the issue does not show when compiling with clang. This probably means that GCC generates better/smaller code then.
[Bug other/107655] [meta-bug] tracker bug for issues encountered in the texinfo-to-sphinx migration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107655 Bug 107655 depends on bug 107651, which changed state. Bug 107651 Summary: Having two different kind of indexes is very useful still https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107651 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug web/107651] Having two different kind of indexes is very useful still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107651 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- (In reply to Andrew Pinski from comment #0) > The texinfo generated indexes had two different kind of index. > One for options and one for Concepts. > I think for the user manual this should definitely stay around. > > If we could split it the concepts even further like lists all pargmas > together and all attributes together that would even be better. Sphinx is even better here, it builds index listing based on Directives (types of category): https://gcc.gnu.org/onlinedocs/gcc/genindex.html > > Since indexes are currently broken, PR 107643. It is hard to tell what it > will be like. They are all avaiable.
[Bug other/107655] [meta-bug] tracker bug for issues encountered in the texinfo-to-sphinx migration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107655 Bug 107655 depends on bug 107643, which changed state. Bug 107643 Summary: [13 Regression] sphinx generated indexes are not working at all https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107643 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug web/107643] [13 Regression] sphinx generated indexes are not working at all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107643 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Martin Liška --- Invalid.
[Bug web/107643] [13 Regression] sphinx generated indexes are not working at all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107643 --- Comment #3 from Martin Liška --- The preferred way of searching is using the Search text input on the left. It works very well.
[Bug web/107643] [13 Regression] sphinx generated indexes are not working at all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107643 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Created attachment 53892 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53892=edit Screenshot There's a screenshot that should link to Index where you have the expected listing.
[Bug web/107644] [13 Regression] Sphinx generated web pages is not using the full width of the window
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107644 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-11-13 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Confirmed. I know there are other templates (RTD) that works better with full screen width: https://docs.kernel.org/ Please file bug at https://github.com/pradyunsg/furo.
[Bug other/107621] sphinx generated documents has too much white space on the top
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107621 --- Comment #8 from Martin Liška --- (In reply to Andrew Pinski from comment #6) > How does this fancy stuff work on a text based browser like links or lynx? It works very well based on what I've seen using lynx browser. > Do we really need this fancy stuff for a manual? I hope yes, it was one of the drivers. The old documentation is legacy, purely formatted HTML w/o search capability and no text formatting. > Seriously this is getting out of hand.
[Bug other/107655] [meta-bug] tracker bug for issues encountered in the texinfo-to-sphinx migration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107655 Bug 107655 depends on bug 107621, which changed state. Bug 107621 Summary: sphinx generated documents has too much white space on the top https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107621 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug other/107621] sphinx generated documents has too much white space on the top
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107621 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org --- Comment #7 from Martin Liška --- This is fixed as Gerald fixed up set-up of the server.
[Bug other/107620] Build errors when using sphinx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107620 Ramana Radhakrishnan changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #3 from Ramana Radhakrishnan --- I worked around this by installing everything in $SRCDIR/doc/requirements.txt. pip3 install -r requirements.txt I found that using that allowed me to build html documentation. However I seemed to need in addition a whole bunch of stuff to build latex and pdf documentation. Ramana
[Bug middle-end/107498] Wrong optimization leads to unaligned access when compiling OpenLDAP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107498 --- Comment #10 from John Paul Adrian Glaubitz --- (In reply to Eric Botcazou from comment #9) > > Program received signal SIGBUS, Bus error. > > 0x010ceda4 in mdb_node_add (mc=0x14327b8, indx=, > > key=0x7fee0a0, data=0x7fee090, pgno=0, flags=0) at > > ./../../../libraries/liblmdb/mdb.c:7366 > > 7366mp->mp_lower += sizeof(indx_t); > > (gdb) p mp > > $1 = (MDB_page *) 0x1463caa > > Thanks. So that's definitely *not* a compiler bug but a programming error > as per the 6.5.3.2(4) clause of the ISO C standard: FWIW, the issue does not show when compiling with clang.
[Bug middle-end/107498] Wrong optimization leads to unaligned access when compiling OpenLDAP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107498 Eric Botcazou changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #9 from Eric Botcazou --- > Program received signal SIGBUS, Bus error. > 0x010ceda4 in mdb_node_add (mc=0x14327b8, indx=, > key=0x7fee0a0, data=0x7fee090, pgno=0, flags=0) at > ./../../../libraries/liblmdb/mdb.c:7366 > 7366mp->mp_lower += sizeof(indx_t); > (gdb) p mp > $1 = (MDB_page *) 0x1463caa Thanks. So that's definitely *not* a compiler bug but a programming error as per the 6.5.3.2(4) clause of the ISO C standard: "The unary * operator denotes indirection. If the operand points to a function, the result is a function designator; if it points to an object, the result is an lvalue designating the object. If the operand has type "pointer to type", the result has type "type". If an invalid value has been assigned to the pointer, the behavior of the unary * operator is undefined.(106)" (106) Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer, an address inappropriately aligned for the type of object pointed to, and the address of an object after the end of its lifetime.
[Bug tree-optimization/107326] [13 Regression] ICE: verify_gimple failed (error: type mismatch in binary expression) since r13-3219-g25413fdb2ac249
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107326 Ramana Radhakrishnan changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #4 from Ramana Radhakrishnan --- Fixed ?
[Bug tree-optimization/105867] [12/13 Regression] incorrect dangling-pointer warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105867 Andrea Griffini changed: What|Removed |Added CC||agriff at tin dot it --- Comment #4 from Andrea Griffini --- Created attachment 53891 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53891=edit Simpler version that triggers the bug This code compiled on 12.2.0 with -O3 -Wall generates a warning about storing the address of a local variable. Surprisingly (for me) adding either of the two `printf` statements makes the warning go away. The code seems correct to me; a doubly linked list of all instances of Node is kept by inserting nodes in constructor and removing them in destructor.
[Bug c++/107638] [13 Regression] options.h:239:36: error: token "." is not valid in preprocessor expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107638 Jan-Benedict Glaw changed: What|Removed |Added CC||jbg...@lug-owl.de --- Comment #2 from Jan-Benedict Glaw --- Seen also for --target=sparc-wrs-vxworks, sh-wrs-vxworks, powerpc-wrs-vxworks, mips-wrs-vxworks, i686-wrs-vxworks.
