[Bug fortran/68993] MERGE does not evaluate its arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68993 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to Joost VandeVondele from comment #0) > I'm not 100% sure what the right answer is, i.e. if MERGE is defined by the > standard to do something special with respect to evaluating its arguments. > The origin is code like this: > > MERGE(C_NULL_PTR, C_LOC(pc), .NOT.PRESENT(pc))) > > is this standard conforming if pc is not present ? In that case MERGE is > supposed to return C_NULL_PTR, but I see no reason why C_LOC(pc) would not > be evaluated first. The above is using C binding features. Your example below has nothing to do with C binding. However, ... > > Gfortran and ifort behave differently in this respect.In the below code > ifort calls foo 4x while gfortran calls it 2x. both results are plausible as the code is invalid. 7.1.8.1 Evaluation of operands It is not necessary for a processor to evaluate all of the operands of an expression, or to evaluate entirely each operand, if the value of the expression can be determined otherwise. If a statement contains a function reference in a part of an expression that need not be evaluated, all entities that would have become defined in the execution of that reference become undefined at the completion of evaluation of the expression containing the function reference. C.4.2 Evaluation of function references If more than one function reference appears in a statement, they may be executed in any order (subject to a function result being evaluated after the evaluation of its arguments) and their values shall not depend on the order of execution. This lack of dependence on order of evaluation permits parallel execution of the function references (7.1.8.1). C.9.5 Argument association and evaluation (12.4.1.2) The provisions for expression evaluation give the processor considerable flexibility for obtaining expression values in the most efficient way possible. This includes not evaluating or only partially evaluating an operand, for example, if the value of the expression can be determined otherwise (7.1.8.1). This flexibility applies to function argument evaluation, including the order of argument evaluation, delaying argument evaluation, and omitting argument evaluation. A processor may delay the evaluation of an argument in a procedure reference until the execution of the procedure refers to the value of that argument, provided delaying the evaluation of the argument does not otherwise affect the results of the program. The processor may, with similar restrictions, entirely omit the evaluation of an argument not referenced in the execution of the procedure. This gives processors latitude for optimization (for example, for parallel processing). > While gfortran's way of doing things seem natural, I suspect it is not > standard conforming. gfortran can do whatever it wants here as the code is invalid. > > cat test.f90 > MODULE test > INTEGER, SAVE :: i=0 > CONTAINS > INTEGER FUNCTION foo() > i=i+1 > foo=i > END FUNCTION > END MODULE test > > USE test > WRITE(6,*) MERGE(foo(),foo(),.FALSE.) Does the evaluation of foo() in the above give merge(1, 2, .false.) or merge(2, 1,.false.)? Or, given that the 3rd argument is .false., gfortran replaced merge() with foo(). So, your code transforms to write(6,*) foo() write(6,*) foo() > WRITE(6,*) MERGE(foo(),foo(),.FALSE.) > WRITE(6,*) i > END I believe that this PR should be closed with INVALID.
[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 Eric Botcazou changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #45 from Eric Botcazou --- Fixed in GCC 6.
[Bug target/65618] [5/6 Regression] gnat bootstrap comparison failure on mips{,el}-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65618 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-12-19 Ever confirmed|0 |1 --- Comment #5 from Eric Botcazou --- Is this still an issue?
[Bug other/16507] gcc_s not found when linking 64-bit C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16507 Eric Botcazou changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #17 from Eric Botcazou --- .
[Bug c/59854] Types with specific endianness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59854 Eric Botcazou changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #2 from Eric Botcazou --- The scalar-storage-order branch has been merged into mainline (C & Ada only).
[Bug fortran/68993] New: MERGE does not evaluate its arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68993 Bug ID: 68993 Summary: MERGE does not evaluate its arguments Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch Target Milestone: --- I'm not 100% sure what the right answer is, i.e. if MERGE is defined by the standard to do something special with respect to evaluating its arguments. The origin is code like this: MERGE(C_NULL_PTR, C_LOC(pc), .NOT.PRESENT(pc))) is this standard conforming if pc is not present ? In that case MERGE is supposed to return C_NULL_PTR, but I see no reason why C_LOC(pc) would not be evaluated first. Gfortran and ifort behave differently in this respect.In the below code ifort calls foo 4x while gfortran calls it 2x. While gfortran's way of doing things seem natural, I suspect it is not standard conforming. > cat test.f90 MODULE test INTEGER, SAVE :: i=0 CONTAINS INTEGER FUNCTION foo() i=i+1 foo=i END FUNCTION END MODULE test USE test WRITE(6,*) MERGE(foo(),foo(),.FALSE.) WRITE(6,*) MERGE(foo(),foo(),.FALSE.) WRITE(6,*) i END > gfortran test.f90 && ./a.out 1 2 2 > ifort test.f90 && ./a.out 2 4 4
[Bug c/68994] New: GCC doesn't issue any diagnostic for missing end-of-line marker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68994
Bug ID: 68994
Summary: GCC doesn't issue any diagnostic for missing
end-of-line marker
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pponnuvel at gmail dot com
Target Milestone: ---
Considering a source file created like this
$ printf "int main(void) {return 0;}" > test.c
$ wc test.c
0 4 26 test.c
$ gcc -Wall -Wextra -pedantic-errors -std=c11 test.c
$ echo $?
0
(wc command reports 0 newlines)
C11 standard, ยง5.1.1.2, says
[..] A source file that is not empty shall end in a new-line character,
which shall not be immediately preceded by a backslash character before any
such
splicing takes place.
The above code violates this constraint. But gcc doesn't issue any diagnostic
about it.
Compiled using gcc 5.1.1/glibc 2.21 on Debian.
[Bug rtl-optimization/68991] -O3 generates misaligned xorv4si3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68991
--- Comment #7 from H.J. Lu ---
[hjl@gnu-tools-1 pr68991]$ cat x.cc
#include
#include
typedef std::string StringRef;
template
class ArrayRef {
public:
typedef const T *iterator;
typedef size_t size_type;
private:
const T *Data;
size_type Length;
public:
iterator begin() const { return Data; }
iterator end() const { return Data + Length; }
};
const unsigned MAX_SUBTARGET_FEATURES = 128;
class FeatureBitset : public std::bitset {
public:
FeatureBitset() : bitset() {}
FeatureBitset(const bitset& B) : bitset(B) {}
};
struct SubtargetFeatureKV {
const char *Key;
FeatureBitset Value;
FeatureBitset Implies;
bool operator<(StringRef S) const;
};
struct SubtargetInfoKV {
const char *Key;
const void *Value;
};
class SubtargetFeatures {
public:
FeatureBitset ToggleFeature(FeatureBitset Bits, StringRef String,
ArrayRef FeatureTable);
};
static inline bool hasFlag(StringRef Feature) {
char Ch = Feature[0];
return Ch == '+' || Ch =='-';
}
static inline std::string StripFlag(StringRef Feature) {
return Feature;
}
static const SubtargetFeatureKV *Find(StringRef S,
ArrayRef A) {
auto F = std::lower_bound(A.begin(), A.end(), S);
return F;
}
static
void ClearImpliedBits(FeatureBitset ,
const SubtargetFeatureKV *FeatureEntry,
ArrayRef FeatureTable) {
for (auto : FeatureTable) {
if (FeatureEntry->Value == FE.Value) continue;
if ((FE.Implies & FeatureEntry->Value).any()) {
Bits &= ~FE.Value;
ClearImpliedBits(Bits, , FeatureTable);
}
}
}
FeatureBitset
SubtargetFeatures::ToggleFeature(FeatureBitset Bits, StringRef Feature,
ArrayRef FeatureTable) {
const SubtargetFeatureKV *FeatureEntry =
Find(StripFlag(Feature), FeatureTable);
if (FeatureEntry) {
if ((Bits & FeatureEntry->Value) == FeatureEntry->Value) {
Bits &= ~FeatureEntry->Value;
ClearImpliedBits(Bits, FeatureEntry, FeatureTable);
}
}
return Bits;
}
[hjl@gnu-tools-1 pr68991]$ gcc -O3 -S x.cc -std=c++11 -mx32 -da
LRA turns
(insn 364 363 575 49 (set (reg:V4SI 288 [ vect__46.140 ])
(xor:V4SI (reg:V4SI 289)
(subreg:V4SI (reg:TI 287 [ MEM[(const struct bitset &)A_56 + 4] ])
0))) /usr/include/c++/5.3.1/bitset:163 3433 {*xorv4si3}
(expr_list:REG_DEAD (reg:V4SI 289)
(expr_list:REG_DEAD (reg:TI 287 [ MEM[(const struct bitset &)A_56 + 4]
])
(nil
into
(insn 364 363 575 49 (set (reg:V4SI 21 xmm0 [orig:288 vect__46.140 ] [288])
(xor:V4SI (reg:V4SI 21 xmm0 [289])
(mem:V4SI (plus:SI (reg/f:SI 44 r15 [orig:118 A ] [118])
(const_int 4 [0x4])) [9 MEM[(const struct bitset &)A_56 +
4]+0 S16 A32]))) /usr/include/c++/5.3.1/bitset:163 3433 {*xorv4si3}
(nil))
[Bug rtl-optimization/68910] [5/6 regression] huge stack frame and poor code with instruction scheduling at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68910 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Eric Botcazou --- Thanks for reporting the problem.
[Bug rtl-optimization/68910] [5/6 regression] huge stack frame and poor code with instruction scheduling at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68910 --- Comment #11 from Eric Botcazou --- Author: ebotcazou Date: Sat Dec 19 21:58:02 2015 New Revision: 231851 URL: https://gcc.gnu.org/viewcvs?rev=231851=gcc=rev Log: PR rtl-optimization/68910 * emit-rtl.c (set_unique_reg_note) <>REG_EQUAL>: Add bypass for USEs. * config/sparc/sparc.md (anddi3): Enable only in 64-bit mode. (iordi3): Likewise. (xordi3): Likewise. (one_cmpldi2): Likewise. (*anddi3_sp32): Delete. (*and_not_di_sp32): Likewise. (*iordi3_sp32): Likewise. (*or_not_di_sp32): Likewise. (*xordi3_sp32): Likewise. (*xor_not_di_sp32): Likewise. (32-bit DImode logical operations splitter): Likewise. (*one_cmpldi2_sp32): Likewise. Added: trunk/gcc/testsuite/gcc.target/sparc/20151219-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc.md trunk/gcc/emit-rtl.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/68910] [5/6 regression] huge stack frame and poor code with instruction scheduling at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68910 --- Comment #12 from Eric Botcazou --- Author: ebotcazou Date: Sat Dec 19 21:59:47 2015 New Revision: 231852 URL: https://gcc.gnu.org/viewcvs?rev=231852=gcc=rev Log: PR rtl-optimization/68910 * emit-rtl.c (set_unique_reg_note) <>REG_EQUAL>: Add bypass for USEs. * config/sparc/sparc.md (anddi3): Enable only in 64-bit mode. (iordi3): Likewise. (xordi3): Likewise. (one_cmpldi2): Likewise. (*anddi3_sp32): Delete. (*and_not_di_sp32): Likewise. (*iordi3_sp32): Likewise. (*or_not_di_sp32): Likewise. (*xordi3_sp32): Likewise. (*xor_not_di_sp32): Likewise. (32-bit DImode logical operations splitter): Likewise. (*one_cmpldi2_sp32): Likewise. Added: branches/gcc-5-branch/gcc/testsuite/gcc.target/sparc/20151219-1.c - copied unchanged from r231851, trunk/gcc/testsuite/gcc.target/sparc/20151219-1.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/sparc/sparc.md branches/gcc-5-branch/gcc/emit-rtl.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/61047] [4.9/5 Regression] wrong code at -O1 on x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61047 Eric Botcazou changed: What|Removed |Added Status|SUSPENDED |NEW
[Bug c++/58109] alignas() fails to compile with constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58109
TC changed:
What|Removed |Added
CC||rs2740 at gmail dot com
--- Comment #5 from TC ---
The test cases in this bug appear to work with GCC 4.9.0 or later; however a
somewhat similar example from http://stackoverflow.com/q/34376921/2756719 fails
to compile:
template
struct Base {
constexpr static int Align_ = alignof(T);
};
template
struct Derived : Base {
using Base_ = Base;
using Base_::Align_;
alignas(Align_) char buf[1];
};
[Bug libstdc++/68995] New: Including both and can cause ADL problems in std::function SFINAE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68995
Bug ID: 68995
Summary: Including both and can
cause ADL problems in std::function SFINAE
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
Repro adapted from http://stackoverflow.com/q/34334735/2756719:
#include
#include
#include
std::tr1::shared_ptr test() { return {}; }
std::function func = test;
This compiles iff the #include is commented out. When both
and are included, however, we get an error,
apparently because
template
using _Invoke = decltype(__callable_functor(std::declval<_Functor&>())
(std::declval<_ArgTypes>()...) );
in std::function does an unqualified call to __callable_functor, and picks up
both std::__callable_functor in from normal unqualified lookup,
and std::tr1::__callable_functor in from ADL, resulting in an
ambiguity, which in turn causes substitution failure in the converting
constructor template.
[Bug java/58117] Java not compiling on ia64-hp-hpux11.31 due to socklen_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58117 --- Comment #2 from Paul A. --- On Wed, Dec 16, 2015 at 02:44:17AM +, msebor at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58117 ... > --- Comment #1 from Martin Sebor --- > Is this a problem with one of the recent releases, either 4.9.3 or 5.3, or > with > trunk? If not, we should close this bug. Sure, go ahead an close it... unfortunately I can neither confirm nor deny about other versions, since I no longer have access to hpux.
[Bug bootstrap/67598] [6 Regression] Target powerpc-e500v2-linux-gnuspe failed to bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67598 --- Comment #4 from Arseny Solokha --- Technically, I can mark it RESOLVED, of course, but I'm not a gcc contributor.
[Bug tree-optimization/65337] [5/6 Regression] bootstrap-lto gnat1 linktime ICE: gcc/ada/exp_aggr.adb:6570:0: internal compiler error: in forward_edge_to_pdom, at tree-ssa-dce.c:1086
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65337 --- Comment #13 from Jan Hubicka --- Author: hubicka Date: Sun Dec 20 05:50:29 2015 New Revision: 231856 URL: https://gcc.gnu.org/viewcvs?rev=231856=gcc=rev Log: PR middle-end/65337 * tree-ssa-dce.c (bb_postorder): New static var. (forward_edge_to_pdom): Remove. (remove_dead_stmt): Instead of redirecting edges only keep an edge on a path to nearest live BB. (eliminate_unnecessary_stmts): Free bb_postorder. * cfganal.c (dfs_find_deadend): Add START_POINTES. * cfganal.h (inverted_post_order_compute): Update prototype. Modified: trunk/gcc/ChangeLog trunk/gcc/cfganal.c trunk/gcc/cfganal.h trunk/gcc/tree-ssa-dce.c
[Bug libstdc++/66059] make_integer_sequence should use a log(N) implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66059 --- Comment #14 from rhalbersma --- Ping to get this merged into the upcoming 5.4 release.
[Bug rtl-optimization/66206] Address of stack memory associated with local variable returned to caller
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66206 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-19 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Eric Botcazou --- The message is misleading though, the problem comes from the 'x' parameter and not from the 'x' local variable...
[Bug rtl-optimization/68991] -O3 generates misaligned xorv4si3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68991 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- You haven't provided preprocessed source, nor exact command line options. GCC uses the ix86_legitimate_combined_insn target hook to disallow misaligned memory into certain SSE instructions. (subreg:V4SI (reg:TI 245 [ MEM[(const struct bitset &)FeatureEntry_21 + 8] ]) 0) is not misaligned memory, it is a subreg of a pseudo register, so it is fine. If the replacement of the pseudo register with memory happens in some other pass, then it probably either should use the legitimate_combined_insn target hook or some other one. I think we have already a PR where that happens during live range shrinking.
[Bug bootstrap/68992] New: [6 Regression] bootstrap error on s390x-linux-gnu with r231848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68992 Bug ID: 68992 Summary: [6 Regression] bootstrap error on s390x-linux-gnu with r231848 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- build/genpreds ../../src/gcc/common.md ../../src/gcc/config/s390/s390.md > tmp-preds.c /bin/bash: line 1: 5355 Segmentation fault build/genpreds ../../src/gcc/common.md ../../src/gcc/config/s390/s390.md > tmp-preds.c Makefile:2274: recipe for target 's-preds' failed make[5]: *** [s-preds] Error 139 make[5]: *** Waiting for unfinished jobs make[5]: Leaving directory '/<>/build/gcc' Makefile:4492: recipe for target 'all-stage2-gcc' failed make[4]: *** [all-stage2-gcc] Error 2 make[4]: Leaving directory '/<>/build' Makefile:23142: recipe for target 'stage2-bubble' failed make[3]: *** [stage2-bubble] Error 2 make[3]: Leaving directory '/<>/build' Makefile:23345: recipe for target 'bootstrap' failed make[2]: *** [bootstrap] Error 2
[Bug bootstrap/68992] [6 Regression] bootstrap error on s390x-linux-gnu with r231848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68992 --- Comment #1 from Matthias Klose --- my last successful build was from 20151213.
[Bug c++/65977] Constexpr should be allowed in declaration of friend template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65977 --- Comment #4 from rhalbersma --- Ping to get this merged into the upcoming 5.4.
[Bug libstdc++/65978] missing constexpr on std::forward_as_tuple and std::tie (LWG issues 2275 and 2301)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65978 --- Comment #3 from rhalbersma --- Ping to get this merged into the upcoming 5.4.
[Bug c++/67371] Never executed "throw" in constexpr function fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67371 --- Comment #10 from rhalbersma --- Ping to get this merged into the upcoming 5.4 release.
[Bug c++/65985] [5/6 Regression] compiler segfault with assert() in constexpr constructor body
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65985 rhalbersma changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE |--- --- Comment #5 from rhalbersma --- This was closed as a dup of 65973, which is now fixed. Unfortunately, the assert() example still fails on trunk: http://melpon.org/wandbox/permlink/o14rXV7GBzNvnNSd
[Bug c++/67371] Never executed "throw" in constexpr function fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67371 --- Comment #11 from Markus Trippelsdorf --- (In reply to rhalbersma from comment #10) > Ping to get this merged into the upcoming 5.4 release. Only regressions should be backported. This isn't one.
[Bug c++/67371] Never executed "throw" in constexpr function fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67371 --- Comment #12 from Markus Trippelsdorf --- (In reply to Markus Trippelsdorf from comment #11) > (In reply to rhalbersma from comment #10) > > Ping to get this merged into the upcoming 5.4 release. > > Only regressions should be backported. This isn't one. s/regressions/regression fixes/
[Bug fortran/46846] Bogus warning: "Interface mismatch in dummy procedure .* has the wrong number of arguments" for intrinsic functions with optional arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46846 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-19 Summary|Warning of AINT as actual |Bogus warning: "Interface |argument ain't right|mismatch in dummy procedure ||.* has the wrong number of ||arguments" for intrinsic ||functions with optional ||arguments Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres --- This PR is a real mess. > lnblnk is a GNU extension. > char, ichar, int, and len_trim are also rejected by other compilers. I think gfortran is correct when rejecting the intrinsic functions in Table 13.3: Restricted specific intrinsic functions (Fortran 2015 draft). > The problem is that all those functions have an optional KIND= argument - > which, however, is not included in the specific functions (as backward > compatibility to Fortran 77). Thus, the warning is bogus - I agree and I have changed the summary. > but another question is whether this can lead to wrong code by not passing > NULL as second argument. I did not find such wrong codes, however I have opened pr68433 for wrong codes when including the optional argument in the interfaces. > I have not checked, but maybe the documentation should also be improved > (cf. James' posting to c.l.f) If so, I think it deserves a separate PR.
[Bug rtl-optimization/68991] -O3 generates misaligned xorv4si3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68991 --- Comment #6 from H.J. Lu --- I don't have a small testcase. I am testing https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=a93baf9afe49e059c9a7746608bdf7403fbaca42 to see if it fixes my problem.
