[Bug target/108764] [RISCV] Cost model for RVB is too aggressive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108764 Sinan changed: What|Removed |Added Target||riscv --- Comment #1 from Sinan --- In the given test case, rv64gc generates better code than rv64gc_zba since asm is less and simpler. In this case, we have an instruction chain like, ashldi3: reg80=reg79 << 3; adddi3: reg81=reg80+reg78; movdi: reg82=reg80; where ashldi3 has two uses, then combining ashldi3+adddi3 isn't really free. I think one solution is to change the cost model of such complex instructions to the sum of the cost for each part. E.g. cost for shNadd = COSTS_N_INSNS (SINGLE_SHIFT_COST) + COSTS_N_INSNS (1) # cost of addition
[Bug target/108764] New: [RISCV] Cost model for RVB is too aggressive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108764
Bug ID: 108764
Summary: [RISCV] Cost model for RVB is too aggressive
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sinan.lin at linux dot alibaba.com
Target Milestone: ---
The cost model of instructions like shNadd, add.uw, ... are set to
COSTS_N_INSNS (1), which brings bad codegen in some cases.
Here is a test case for the problem.
```
#include
int64_t foo (void * ptr, int value, int64_t num);
int64_t clear1 (int64_t *array, int64_t *end, int64_t size)
{
return array + size < end ? foo(array, 0, size * 8) : 0;
}
```
generates asm with -march=rv64gc_zba -O3
```
clear1:
sllia4,a2,3
sh3add a5,a2,a0
bgtua1,a5,.L4
li a0,0
ret
.L4:
mv a2,a4
li a1,0
tailfoo
```
generates asm with -march=rv64gc -O3
```
clear1:
sllia2,a2,3
add a5,a0,a2
bgtua1,a5,.L4
li a0,0
ret
.L4:
li a1,0
tailfoo
```
[Bug jit/108762] Add support for target-dependent builtins in libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108762 --- Comment #1 from Antoni --- Created attachment 54452 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54452&action=edit Add support for machine-dependant builtins
[Bug d/108763] va_arg usage in D doesn't compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108763 --- Comment #4 from Steven Schveighoffer --- I don't think it's worth a major effort. Nobody is using this kind of varargs in D these days, it's mostly for legacy code (newer code will use template varargs). When I filed this bug, it was because I thought there was just a missing piece in the library, I did not expect it to be a conscious decision to omit this feature. I'm OK with closing this if the effort is great. Don't spend time on it, projects can avoid doformat pretty easily. I was hoping for a quick fix!
[Bug d/108763] va_arg usage in D doesn't compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108763 --- Comment #3 from Andrew Pinski --- Reading the code on I think it would need some huge work to get it working on GDC really. Especially on aarch64. Mainly because the way var_args is defined is something which is very much target specific. and GCC implements var_args internally to optimize some cases sometimes.
[Bug d/108763] va_arg usage in D doesn't compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108763
--- Comment #2 from Steven Schveighoffer ---
(In reply to Andrew Pinski from comment #1)
> https://github.com/dlang/dmd/blob/master/druntime/src/core/vararg.d
>
> version (GNU) { /* TypeInfo-based va_arg overload unsupported */ }
>
> ...
oof. This is somewhat of a problem, because the undead package
(https://github.com/dlang/undead) uses it inside doformat, and this means that
anyone wanting to use those packages cannot do so with GDC.
The undead package is a collection of modules that are no longer in mainline D,
and so the point is to be able to use older modules with older code.
If this is deemed to be unsupportable, then people will just have to live with
not being able to use GDC for programs using that package. I also can look at
possibly disabling the offending code for GDC users, and then people can use
the other parts of undead (e.g. undead.xml)
Thanks for pointing that out!
[Bug d/108763] va_arg usage in D doesn't compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108763
--- Comment #1 from Andrew Pinski ---
https://github.com/dlang/dmd/blob/master/druntime/src/core/vararg.d
version (GNU) { /* TypeInfo-based va_arg overload unsupported */ }
...
[Bug d/108763] New: va_arg usage in D doesn't compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108763
Bug ID: 108763
Summary: va_arg usage in D doesn't compile
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: schveiguy at gmail dot com
Target Milestone: ---
Compiling a valid D module that uses varargs does not compile. The following is
the source of `test.d`:
```d
import core.vararg;
void foo(...)
{
ubyte[128] buf;
foreach(ti; _arguments)
{
va_arg(_argptr, ti, buf.ptr);
}
}
```
This is confirmed a valid module using both other D compilers, dmd and ldc.
The output information of -v is:
COLLECT_GCC=/opt/compiler-explorer/gcc-12.2.0/bin/gdc
Target: x86_64-linux-gnu
Configured with: ../gcc-12.2.0/configure
--prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --enable-clocale=gnu
--enable-languages=c,c++,fortran,ada,objc,obj-c++,go,d --enable-ld=yes
--enable-gold=yes --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-linker-build-id --enable-lto --enable-plugins --enable-threads=posix
--with-pkgversion=Compiler-Explorer-Build-gcc--binutils-2.38
--enable-libstdcxx-backtrace=yes
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.2.0 (Compiler-Explorer-Build-gcc--binutils-2.38)
COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' '/app/output.s'
'-masm=intel' '-S' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
'-dumpdir' '/app/'
/opt/compiler-explorer/gcc-12.2.0/bin/../libexec/gcc/x86_64-linux-gnu/12.2.0/d21
-quiet -dumpdir /app/ -dumpbase output.d -dumpbase-ext .d -masm=intel
-mtune=generic -march=x86-64 -g -version -fdiagnostics-color=always -o
/app/output.s -imultiarch x86_64-linux-gnu -iprefix
/opt/compiler-explorer/gcc-12.2.0/bin/../lib/gcc/x86_64-linux-gnu/12.2.0/ -v
GNU D (Compiler-Explorer-Build-gcc--binutils-2.38) version 12.2.0
(x86_64-linux-gnu)
compiled by GNU C version 9.4.0, GMP version 6.2.1, MPFR version 4.1.0,
MPC version 1.2.1, isl version isl-0.24-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU D (Compiler-Explorer-Build-gcc--binutils-2.38) version 12.2.0
(x86_64-linux-gnu)
compiled by GNU C version 9.4.0, GMP version 6.2.1, MPFR version 4.1.0,
MPC version 1.2.1, isl version isl-0.24-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
binary
/opt/compiler-explorer/gcc-12.2.0/bin/../libexec/gcc/x86_64-linux-gnu/12.2.0/d21
version v2.100.1
predefs GNU D_Version2 LittleEndian GNU_DWARF2_Exceptions GNU_StackGrowsDown
GNU_InlineAsm D_LP64 assert D_PreConditions D_PostConditions D_Invariants
D_ModuleInfo D_Exceptions D_TypeInfo all X86_64 D_HardFloat Posix linux
CRuntime_Glibc CppRuntime_Gcc
As far as the command line, it would be:
gdc -o test test.d
The compiler output is:
:7:11: error: none of the overloads of template
'core.stdc.stdarg.va_arg' are callable using argument types
'!()(__va_list_tag[1], TypeInfo, ubyte*)'
7 | va_arg(_argptr, ti, buf.ptr);
| ^
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/include/d/core/stdc/stdarg.d:172:7:
note: Candidates are: 'va_arg(T)(ref va_list ap)'
172 | T va_arg(T)(ref va_list ap); // intrinsic
| ^
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/include/d/core/stdc/stdarg.d:271:10:
note: 'va_arg(T)(ref va_list ap, ref T parmn)'
271 | void va_arg(T)(ref va_list ap, ref T parmn); // intrinsic
| ^
The expected function should be implemented as identified in the D library
here: https://dlang.org/phobos/core_vararg.html#.va_arg
[Bug tree-optimization/108757] We do not simplify (a - (N*M)) / N + M -> a / N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757 --- Comment #11 from Chip Kerchner --- Nevermind, using a similar example that Segher gave, it would failed too.
[Bug tree-optimization/108757] We do not simplify (a - (N*M)) / N + M -> a / N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757 --- Comment #10 from Chip Kerchner --- Oops that should be 31 * -2, not 33.
[Bug jit/108762] New: Add support for target-dependent builtins in libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108762 Bug ID: 108762 Summary: Add support for target-dependent builtins in libgccjit Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- I'll soon post a patch for this.
[Bug tree-optimization/108757] We do not simplify (a - (N*M)) / N + M -> a / N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757 --- Comment #9 from Chip Kerchner --- Doesn't this work for powers of two (N) and signed values (for A, N and M)? (59 - (33 * -2)) / -2 + 31 = -62 + 31 = -29 and 59 / -2 = -29
[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477 Bug 87477 depends on bug 95107, which changed state. Bug 95107 Summary: ICE in hash_operand, at fold-const.c:3768 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95107 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/95107] ICE in hash_operand, at fold-const.c:3768
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95107 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #15 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug fortran/108609] New test case gfortran.dg/pr108527.f90 in r13-5479-g22afa4947584c7 ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108609 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |10.5 Resolution|--- |FIXED --- Comment #7 from anlauf at gcc dot gnu.org --- Fixed.
[Bug fortran/108527] [13 Regression] ICE in compare_bound_int(): Bad expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108527 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|13.0|10.5 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #13 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug fortran/108609] New test case gfortran.dg/pr108527.f90 in r13-5479-g22afa4947584c7 ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108609 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:684a5a8734c4269786089f5d4ba0fbf79f190f3a commit r10-11207-g684a5a8734c4269786089f5d4ba0fbf79f190f3a Author: Harald Anlauf Date: Wed Feb 1 21:01:32 2023 +0100 Fortran: error recovery on invalid array section [PR108609] The testcase for PR108527 uncovered a latent issue with invalid array sections that resulted in different paths being taken on different architectures. Detect the invalid array declaration for a clean recovery. gcc/fortran/ChangeLog: PR fortran/108609 * expr.c (find_array_section): Add check to prevent interpreting an mpz non-integer constant as an integer. gcc/testsuite/ChangeLog: PR fortran/108609 * gfortran.dg/pr108527.f90: Adjust test pattern. (cherry picked from commit 88a2a09dd4529107e7ef7a6e7ce43acf96457173)
[Bug fortran/95107] ICE in hash_operand, at fold-const.c:3768
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95107 --- Comment #14 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:2db200ea8a63dd580b47002d9464afc7a7b5e90e commit r10-11208-g2db200ea8a63dd580b47002d9464afc7a7b5e90e Author: Harald Anlauf Date: Mon Feb 6 20:59:51 2023 +0100 Fortran: ASSOCIATE variables should not be TREE_STATIC [PR95107] gcc/fortran/ChangeLog: PR fortran/95107 * trans-decl.c (gfc_finish_var_decl): With -fno-automatic, do not make ASSOCIATE variables TREE_STATIC. gcc/testsuite/ChangeLog: PR fortran/95107 * gfortran.dg/save_7.f90: New test. (cherry picked from commit c36f3da534e7f411c5bc48c5b6b660e238167480)
[Bug fortran/108527] [13 Regression] ICE in compare_bound_int(): Bad expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108527 --- Comment #12 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:2965a4f925461d7814972845fe480e03856fe3fe commit r10-11206-g2965a4f925461d7814972845fe480e03856fe3fe Author: Harald Anlauf Date: Tue Jan 24 22:36:25 2023 +0100 Fortran: fix ICE in compare_bound_int [PR108527] gcc/fortran/ChangeLog: PR fortran/108527 * resolve.c (compare_bound_int): Expression to compare must be of type INTEGER. (compare_bound_mpz_t): Likewise. (check_dimension): Fix comment on checks applied to array section and clean up associated logic. gcc/testsuite/ChangeLog: PR fortran/108527 * gfortran.dg/pr108527.f90: New test. Co-authored-by: Steven G. Kargl (cherry picked from commit 22afa4947584c701633a79fd8750c9ceeaa96711)
[Bug tree-optimization/108757] We do not simplify (a - (N*M)) / N + M -> a / N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757 --- Comment #8 from Segher Boessenkool --- No, addition and subtraction are well defined for all inputs, for unsigned integers.
[Bug tree-optimization/108757] We do not simplify (a - (N*M)) / N + M -> a / N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757 --- Comment #7 from Peter Bergner --- (In reply to Segher Boessenkool from comment #6) > No? Take a=59 as counterexample: > > (a - (N*M)) / N + M = (59 - 2*30)/30 + 2 = ~0UL/30 + 2 For unsigned integers, isn't having a < N*M UB so we're free to do as we wish for either the optimized and non-optimized sequences? Meaning, can't we assume here that a >= N*M?
[Bug tree-optimization/108757] We do not simplify (a - (N*M)) / N + M -> a / N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757 --- Comment #6 from Segher Boessenkool --- No? Take a=59 as counterexample: (a - (N*M)) / N + M = (59 - 2*30)/30 + 2 = ~0UL/30 + 2 but a / N = 59/30 = 1 Integer division in C is division towards zero, almost no normal algebraic simplifications apply there.
[Bug tree-optimization/108757] We do not simplify (a - (N*M)) / N + M -> a / N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757 --- Comment #5 from Peter Bergner --- (In reply to Segher Boessenkool from comment #4) > If N is a power of two optimising this to a/N is valid, but for other values > of N it is not (division is not the inverse of multiplication in C). It also > only works for unsigned of course. Isn't this valid for any N & M, such that M is a factor of N? Meaning, as long as N / M has no remainder, it seems like this should be ok. For example, N = 30 & M = 2 should be just as ok as the N = 32 & M = 2 case, correct?
[Bug libstdc++/108760] ranges::iota is not included in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108760 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-02-11 CC||ppalka at gcc dot gnu.org
[Bug tree-optimization/108757] We do not simplify (a - (N*M)) / N + M -> a / N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #4 from Segher Boessenkool --- If N is a power of two optimising this to a/N is valid, but for other values of N it is not (division is not the inverse of multiplication in C). It also only works for unsigned of course.
[Bug c++/108761] Add option to produce a unique section for non-COMDAT __attribute__((section("foo"))) object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108761 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > I think rather section should have a secondary argument which mark as > needing to append the function name on it ... s/function name/decl assembly name/
[Bug c++/108761] Add option to produce a unique section for non-COMDAT __attribute__((section("foo"))) object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108761 --- Comment #1 from Andrew Pinski --- I think an option would be the wrong appoarch because many of the times, you are marking a variable inside a section exactly because you want it to be part of an "array". I think rather section should have a secondary argument which mark as needing to append the function name on it ...
[Bug c/107557] [12/13 Regression] ICE -fsanitize=undefined and VLA as argument type to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107557 --- Comment #6 from Martin Uecker --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611562.html
[Bug target/108316] ICE in maybe_gen_insn via expand_SCATTER_STORE when vectorizing for SVE since r13-2737-g4a773bf2f08656
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108316 Jakub Jelinek changed: What|Removed |Added Summary|[13 Regression] ICE in |ICE in maybe_gen_insn via |maybe_gen_insn via |expand_SCATTER_STORE when |expand_SCATTER_STORE when |vectorizing for SVE since |vectorizing for SVE since |r13-2737-g4a773bf2f08656 |r13-2737-g4a773bf2f08656| Priority|P1 |P3 --- Comment #6 from Jakub Jelinek --- Removing regression tag, keeping open for above mentioned improvements.
[Bug ipa/108605] [13 Regression] ICE in ipa_push_agg_values_from_jfunc with offsets >= INT_MAX since r13-3359-g656b2338c8f248
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108605 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Should be fixed now.
[Bug ipa/108605] [13 Regression] ICE in ipa_push_agg_values_from_jfunc with offsets >= INT_MAX since r13-3359-g656b2338c8f248
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108605 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:00a49047b504b27a8dd19d819c7bc48d54078767 commit r13-5818-g00a49047b504b27a8dd19d819c7bc48d54078767 Author: Jakub Jelinek Date: Sat Feb 11 15:57:54 2023 +0100 ipa-cp: Punt for too large offsets [PR108605] Seems most of IPA uses unsigned type for byte offsets ipa-param-manipulation.h: unsigned unit_offset; ipa-param-manipulation.h: unsigned unit_offset; ipa-param-manipulation.h: void register_replacement (tree base, unsigned unit_offset, tree replacement); ipa-param-manipulation.h: tree lookup_replacement (tree base, unsigned unit_offset); ipa-param-manipulation.h: unsigned unit_offset); ipa-prop.h: unsigned unit_offset; ipa-prop.h: tree get_value (int index, unsigned unit_offset, bool by_ref) const; ipa-prop.h: tree get_value (int index, unsigned unit_offset) const; ipa-prop.h: const ipa_argagg_value *get_elt (int index, unsigned unit_offset) const; ipa-cp.cc:ipa_argagg_value_list::get_elt (int index, unsigned unit_offset) const ipa-cp.cc: unsigned prev_unit_offset = 0; ipa-cp.cc:ipa_argagg_value_list::get_value (int index, unsigned unit_offset) const ipa-cp.cc:ipa_argagg_value_list::get_value (int index, unsigned unit_offset, ipa-cp.cc: unsigned other_offset = other.m_elts[i].unit_offset; ipa-cp.cc: unsigned prev_unit_offset = 0; ipa-cp.cc: unsigned prev_unit_offset = 0; ipa-cp.cc: unsigned this_offset = elts[i].unit_offset; ipa-cp.cc: unsigned prev_unit_offset = 0; ipa-cp.cc:unsigned unit_offset = aglat->offset / BITS_PER_UNIT; ipa-cp.cc: unsigned prev_unit_offset = 0; ipa-param-manipulation.cc: unsigned unit_offset; ipa-param-manipulation.cc:isra_get_ref_base_and_offset (tree expr, tree *base_p, unsigned *unit_offset_p) ipa-param-manipulation.cc: unsigned unit_offset, ipa-param-manipulation.cc: unsigned unit_offset) ipa-param-manipulation.cc:ipa_param_body_adjustments::lookup_replacement (tree base, unsigned unit_offset) ipa-param-manipulation.cc: unsigned unit_offset; ipa-prop.cc: unsigned unit_offset = bit_offset / BITS_PER_UNIT; ipa-sra.cc: unsigned unit_offset; ipa-sra.cc: unsigned unit_offset; ipa-sra.cc: unsigned unit_offset, unsigned unit_size) ipa-sra.cc: unsigned offset = argacc->unit_offset + delta_offset; so before converting a HOST_WIDE_INT bit offset to unsigned byte offset we need to punt for too large offsets. Some places do that, e.g. isra_get_ref_base_and_offset has if (offset < 0 || (offset / BITS_PER_UNIT) > UINT_MAX) return false; but ipa_agg_value_from_jfunc doesn't. The following patch fixes that. 2023-02-11 Jakub Jelinek PR ipa/108605 * ipa-cp.cc (ipa_agg_value_from_jfunc): Return NULL_TREE also if item->offset bit position is too large to be representable as unsigned int byte position. * c-c++-common/pr108605.c: New test.
[Bug tree-optimization/108757] We do not simplify (a - (N*M)) / N + M -> a / N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757 --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #2) > I am not sure this can be done in the normal case unless you know the range > of a to be [64...INF] . > The wrap around case might be an issue ... > But I am not 100% sure. It is. Just print foo(0).
[Bug driver/108350] Windows: invoking gcc via symlink does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350 Gerald Pfeifer changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||gerald at pfeifer dot com --- Comment #38 from Gerald Pfeifer --- Marking this as RESOLVED FIXED based on the previous comments and affirmative reports on gcc-patches@.
[Bug driver/108350] Windows: invoking gcc via symlink does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350 jon_y <10walls at gmail dot com> changed: What|Removed |Added CC||10walls at gmail dot com --- Comment #37 from jon_y <10walls at gmail dot com> --- Nixman's patch has been committed to master branch as e2bb55ec3b70cf45088bb73ba9ca990129328d60.
