[Bug libgcj/28226] [4.2 Regression] posix.cc:222: error: invalid conversion from 'const void*' to 'void*'
--- Comment #5 from ghazi at gcc dot gnu dot org 2006-07-08 18:53 --- FWIW, Solaris 10 had the same problem and cause, and is now also fixed. Thanks, --Kaveh -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||ghazi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28226
[Bug testsuite/36714] FAIL: gcc.target/i386/quad-sse.c scan-assembler-not call
--- Comment #2 from ghazi at gcc dot gnu dot org 2008-11-15 20:28 --- *** This bug has been marked as a duplicate of 37517 *** -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36714
[Bug testsuite/37517] gcc.target/i386/quad-sse.c fails with -fPIC
--- Comment #9 from ghazi at gcc dot gnu dot org 2008-11-15 20:28 --- *** Bug 36714 has been marked as a duplicate of this bug. *** -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||dominiq at lps dot ens dot ||fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37517
[Bug tree-optimization/38261] New: [4.4 regression] gcc.dg/torture/ipa-pta-1.c & gcc.dg/tree-ssa/alias-2.c fail with -fpic/-fPIC
The testcases gcc.dg/torture/ipa-pta-1.c and gcc.dg/tree-ssa/alias-2.c used to
work with -fpic/-fPIC on the trunk, but now fail. The alias-2.c testcase
worked in 4.2, 4.3 with -fpic/-fPIC also, and the testcase doesn't appear to
have changed. I think ipa-pta-1.c was added only on the trunk a few months ago
so there's no comparison with previous releases, however it did work on the
trunk up until very recently.
They both passed here:
http://gcc.gnu.org/ml/gcc-testresults/2008-11/msg01383.html
And they both started failing here:
http://gcc.gnu.org/ml/gcc-testresults/2008-11/msg01516.html
Based on the timing, I suspect that the cause is related.
--
Summary: [4.4 regression] gcc.dg/torture/ipa-pta-1.c &
gcc.dg/tree-ssa/alias-2.c fail with -fpic/-fPIC
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org
GCC target triplet: x86_64-*-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38261
[Bug bootstrap/38262] New: [4.4 regression] GCC components unnecessarily link with shared gmp/mpfr
As noted here: http://gcc.gnu.org/ml/gcc/2008-11/msg00234.html various components of GCC (xgcc, gcov, etc) are linking unnecessarily with gmp/mpfr. I believe we only need to do that for executables linked against libbackend.a (like cc1). The result is exposed when gmp/mpfr are shared libraries and appear in the ldd output. This bug was previously fixed in PR35107 but regressed during the graphite merge. http://gcc.gnu.org/viewcvs/trunk/gcc/Makefile.in?r1=139854&r2=139893 -- Summary: [4.4 regression] GCC components unnecessarily link with shared gmp/mpfr Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org BugsThisDependsOn: 35107 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38262
[Bug testsuite/38263] New: gcc.dg/ipa/ipacost-2.c fails with -fpic/-fPIC
The testcase gcc.dg/ipa/ipacost-2.c fails with -fpic/-fPIC, and has been doing so since it was added to the testsuite back in August. August results: http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg02784.html Current results: http://gcc.gnu.org/ml/gcc-testresults/2008-11/msg02234.html Is this test something that should work with -fpic/-fPIC? Could it pass if some function were made static and/or it was compiled with -fpie? Or does it indicate a bug in the compiler? -- Summary: gcc.dg/ipa/ipacost-2.c fails with -fpic/-fPIC Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38263
[Bug bootstrap/38262] [4.4 regression] GCC components unnecessarily link with shared gmp/mpfr
--- Comment #2 from ghazi at gcc dot gnu dot org 2008-11-25 23:08 --- (In reply to comment #1) > Subject: Re: New: [4.4 regression] GCC components unnecessarily link with > shared gmp/mpfr > Here is a patch from Dwarak for fixing this. > He will send this to review on gcc-patches@ list. > Sebastian Pop > -- > AMD - GNU Tools Thanks, however I don't understand why in this patch xgcc and cpp are being linked with BACKENDLIBS. They don't linked with libbackend.a. Also, there are many more places where you do need to add BACKENDLIBS like cc1plus, cc1obj, f951, jc1, etc. See here for all the places you'll need to catch: http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00187.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-25 23:08:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38262
[Bug bootstrap/38262] [4.4 regression] GCC components unnecessarily link with shared gmp/mpfr
--- Comment #5 from ghazi at gcc dot gnu dot org 2008-11-26 19:11 --- (In reply to comment #3) > Subject: Re: [4.4 regression] GCC components unnecessarily link with shared > gmp/mpfr > Thanks for catching the missing parts. > Here is the updated patch. Does this patch look correct? Yes it looks correct, thanks for working on it. --Kaveh -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38262
[Bug tree-optimization/38261] [4.4 Regression] gcc.dg/torture/ipa-pta-1.c & gcc.dg/tree-ssa/alias-2.c fail with -fpic/-fPIC
--- Comment #2 from ghazi at gcc dot gnu dot org 2008-11-27 16:59 --- (In reply to comment #1) > Can you use ./contrib/gcc_update to update your gcc source tree > so that we can tell which revisions you are using? Thanks. Done, however it only works for 4.3 and trunk, not 4.2. I assume that's intentional, i.e. the mechanism in gcc_update never got backported for the 4.2 branch? -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-27 16:59:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38261
[Bug libgcj/10353] [4.2/4.3/4.4 regression] Java testsuite failures
--- Comment #32 from ghazi at gcc dot gnu dot org 2008-12-11 01:10 --- (In reply to comment #31) > How can this be a regression bug if there's not a single known-to-work > revision? When I originally opened this PR, my opening comment noted that the java failures I encountered were regressions from the 3.2.x series. Annoyingly my comment doesn't actually list the testcases that were failing. That doesn't seem like something I would normally leave out. :-) After some digging I realized that's because the PR originally listed them in the Summary: field. Somewhere along the line this PR got renamed to a generic "java testsuite failures", I think it was Eric in comment#14. You can see the original summary here from the gcc-bugs mailing list: http://gcc.gnu.org/ml/gcc-bugs/2003-04/msg00378.html For the record, those failing testcases were: Array_3, TLtest, Thread_Join, Thread_Wait_Interrupt & Throw_2. Here is my testsuite results from the 3.2.3 release where the testcases pass: http://gcc.gnu.org/ml/gcc-testresults/2003-04/msg01566.html Here is a 3.3.x result from around the same time showing the failures: http://gcc.gnu.org/ml/gcc-testresults/2003-04/msg01574.html Anyway, I no longer have access to solaris boxes. I looked for recent testsuite results to see if those testcases are still failing. It was hard because many people seem to post solaris2 results without java enabled. (You know who you are!) Here's a couple from 4.4 trunk on solaris2.10 and 2.11 that shows they aren't failing. In fact the results actually look pretty good: http://gcc.gnu.org/ml/gcc-testresults/2008-11/msg01758.html http://gcc.gnu.org/ml/gcc-testresults/2008-11/msg00647.html I originally reported the bugs against solaris2.7, so I don't know if the testcases got "fixed" by the OS upgrade or something done in GCC. Someone with an older solaris would have to double check. Maybe Joe Buck who has solaris2.8 could help with that. If Joe's tests show that the specific failures I mentioned don't appear in solaris2.8, then I would say it's fair to either close this PR and note the remaining solaris failures in their own PRs, or at least no longer call this PR a "regression". I would lean towards the former, i.e. close this PR once we verify an older solaris release and track any remaining failures in new PRs. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||joe dot buck at synopsys dot ||com Known to work||3.2.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10353
[Bug objc++/31032] [4.3/4.4 Regression] expected tree that contains 'decl with RTL' structure, have 'field_decl' in assemble_external_real, at varasm.c:2225
--- Comment #12 from ghazi at gcc dot gnu dot org 2008-12-12 22:31 --- I can narrow it down on mainline to somewhere between revisions 142545 and 142574 according to my testsuite results below: http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg00786.html http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg00896.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.2.0 |4.2.0 4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31032
[Bug objc++/31032] [4.3/4.4 Regression] expected tree that contains 'decl with RTL' structure, have 'field_decl' in assemble_external_real, at varasm.c:2225
--- Comment #13 from ghazi at gcc dot gnu dot org 2008-12-23 01:18 --- I reverified the bug on the 4.3 branch today, checking results for x86_64-linux posted here: http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg02099.html The logfile shows the same error: bitfield-1.mm:113: internal compiler error: tree check: expected tree that contains 'decl with RTL' structure, have 'field_decl' in assemble_external_real, at varasm.c:2220 The 4.4 trunk seems fixed per the above comments. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.3.0 |4.3.0 4.3.3 Last reconfirmed|2008-02-08 05:01:56 |2008-12-23 01:18:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31032
[Bug rtl-optimization/35729] const volatile variable access incorrectly hoisted out of loop
--- Comment #12 from ghazi at gcc dot gnu dot org 2009-01-17 02:50 --- Reconfirming for (x86 && pic): http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg01601.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2008-03-30 15:02:14 |2009-01-17 02:50:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35729
[Bug rtl-optimization/30957] Misscompare with variable expansion optimization
--- Comment #17 from ghazi at gcc dot gnu dot org 2009-01-17 02:56 --- Reconfirming that gcc.dg/pr30957-1.c still XFAILs for me on x86_64. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC|ghazi at gcc dot gnu dot org| Last reconfirmed|2008-01-09 18:13:13 |2009-01-17 02:56:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30957
[Bug testsuite/29404] "make check" fails to compile library testcases
--- Comment #9 from ghazi at gcc dot gnu dot org 2009-01-17 03:03 --- Reconfirming... I can see on a linux-gnu box that it's compiling the libiberty testsuite with stage1 gcc. That masks the error of missing libgcc bits used in stage3 libiberty, but still it should be using the stage3 xgcc to compile the testcases. Ditto for mpfr/gmp if you build them in-tree. gcc -DHAVE_CONFIG_H -g -O2 -I.. -I../../../egcc-SVN20090116/libiberty/testsuite/../../include -DHAVE_CONFIG_H -I.. -o test-pexecute ../../../egcc-SVN20090116/libiberty/testsuite/test-pexecute.c ../libiberty.a -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2008-02-02 05:19:13 |2009-01-17 03:03:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29404
[Bug testsuite/38263] gcc.dg/ipa/ipacost-2.c fails with -fpic/-fPIC
--- Comment #2 from ghazi at gcc dot gnu dot org 2009-01-17 03:36 --- Reconfirming the problem with (x86 && pic), e.g.: http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg01601.html Jan, any comments? -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-17 03:36:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38263
[Bug other/40302] New: GCC must hard-require MPC before release
GCC optionally uses the MPC library for complex numbers. As per this message, we must hard-require MPC prior to the next release: http://gcc.gnu.org/ml/gcc/2009-05/msg00346.html -- Summary: GCC must hard-require MPC before release Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40302
[Bug other/40302] GCC must hard-require MPC before release
-- ghazi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ghazi at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Priority|P3 |P1 Last reconfirmed|-00-00 00:00:00 |2009-05-30 03:40:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40302
[Bug other/40302] [4.5 Regression] GCC must hard-require MPC before release
--- Comment #2 from ghazi at gcc dot gnu dot org 2009-06-01 06:02 --- Remember to update the webpage: http://gcc.gnu.org/gcc-4.5/changes.html Add the MPC library dependency in the "Caveats" section, and add the benefits of using MPC in the "General Optimizer Improvements" section. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40302
[Bug fortran/40318] New: Complex division by zero in gfortran returns wrong results
Complex division by zero in gfortran returns NaN. This is expected for 0/0, but other finite/zero should return Inf. This impacts the testcase gfortran.dg/real_const_3.f90 in two values incorrectly computed: complex :: z = (-0.1,-2.2)/(0.0,0.0) complex :: z2 = (0.1,1)/0 See: http://gcc.gnu.org/ml/fortran/2009-05/msg00423.html This should be fixed in gcc-4.5 by using MPC for division, but older versions of GCC should add special case handling in the fortran frontend simplification code. -- Summary: Complex division by zero in gfortran returns wrong results Product: gcc Version: 4.3.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40318
[Bug fortran/40318] Complex division by zero in gfortran returns wrong results
--- Comment #2 from ghazi at gcc dot gnu dot org 2009-06-01 08:35 --- (In reply to comment #1) > Kaveh, > After looking into the problem, I think (nan + i nan) is > an acceptable result for z = (-0.1,-2.2)/(0.0,0.0) > because of the standard definition of complex division. > For z2 = (0.1,1)/0, I think that you are correct, and > gfortran should give (inf + i inf). Why is one different than the other? I don't know fortan promotion rules, but in C, the latter case promotes to (0.1,1.0)/(0.0,0.0) which looks very much like the first case. Does fortran handle type promotion differently? Regardless, I don't know that any "standard definition" of complex division applies here. The canonical algebraic formula is undefined mathematically in the presence of division by zero. So at least in C there are rules telling us what to do, and they say return Inf. Does fortran follow a standard here we can compare against or are we guessing? :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40318
[Bug other/40302] [4.5 Regression] GCC must hard-require MPC before release
--- Comment #3 from ghazi at gcc dot gnu dot org 2009-06-01 17:45 --- Remember to upload the MPC tarball (whatever version we settle on) to: ftp://gcc.gnu.org/pub/gcc/infrastructure/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40302
[Bug fortran/40318] Complex division by zero in gfortran returns wrong results
--- Comment #10 from ghazi at gcc dot gnu dot org 2009-06-01 18:14 --- (In reply to comment #9) > If MPC returns inf or (inf + i inf) and the MPC developers do not consider > this to be a bug in their library, then gfortran will need to handle the > division by zero during constant folding as a special case. I believe the goals for MPC are to follow C99 rules for special cases. Thus the return value of (inf + i inf) is intentional for MPC and not a bug in their thinking. I entirely agree that the compile-time and runtime results should be identical. If it is your intention to preserve the existing runtime behavior, then we should do the same in the fortran folder and special case this if/when converting complex division to use MPC. Does this mean this PR should be closed as "invalid" ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40318
[Bug fortran/40318] Complex division by zero in gfortran returns wrong results
--- Comment #13 from ghazi at gcc dot gnu dot org 2009-06-02 15:16 ---
(In reply to comment #11)
> What is disturbing is Example 2 in G.5.1 on page 470! Does gcc's runtime
> implementation of complex division mirror Example 2? I can understand
> the need to avoid under/overflow, but _Cdivd() seems overly complicated.
Here is GCC's runtime implementation of complex division from libgcc2.c. It
looks like it does mirror example 2. While the runtime evaluation seems to be
fine, the middle-end folder still has bugs. See PR30789.
#if defined(L_divsc3) || defined(L_divdc3) \
|| defined(L_divxc3) || defined(L_divtc3)
CTYPE
CONCAT3(__div,MODE,3) (MTYPE a, MTYPE b, MTYPE c, MTYPE d)
{
MTYPE denom, ratio, x, y;
CTYPE res;
/* ??? We can get better behavior from logarithmic scaling instead of
the division. But that would mean starting to link libgcc against
libm. We could implement something akin to ldexp/frexp as gcc builtins
fairly easily... */
if (FABS (c) < FABS (d))
{
ratio = c / d;
denom = (c * ratio) + d;
x = ((a * ratio) + b) / denom;
y = ((b * ratio) - a) / denom;
}
else
{
ratio = d / c;
denom = (d * ratio) + c;
x = ((b * ratio) + a) / denom;
y = (b - (a * ratio)) / denom;
}
/* Recover infinities and zeros that computed as NaN+iNaN; the only cases
are nonzero/zero, infinite/finite, and finite/infinite. */
if (isnan (x) && isnan (y))
{
if (c == 0.0 && d == 0.0 && (!isnan (a) || !isnan (b)))
{
x = COPYSIGN (INFINITY, c) * a;
y = COPYSIGN (INFINITY, c) * b;
}
else if ((isinf (a) || isinf (b)) && isfinite (c) && isfinite (d))
{
a = COPYSIGN (isinf (a) ? 1 : 0, a);
b = COPYSIGN (isinf (b) ? 1 : 0, b);
x = INFINITY * (a * c + b * d);
y = INFINITY * (b * c - a * d);
}
else if ((isinf (c) || isinf (d)) && isfinite (a) && isfinite (b))
{
c = COPYSIGN (isinf (c) ? 1 : 0, c);
d = COPYSIGN (isinf (d) ? 1 : 0, d);
x = 0.0 * (a * c + b * d);
y = 0.0 * (b * c - a * d);
}
}
__real__ res = x;
__imag__ res = y;
return res;
}
#endif /* complex divide */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40318
[Bug testsuite/40544] FAIL: gcc.dg/torture/builtin-math-6.c
--- Comment #2 from ghazi at gcc dot gnu dot org 2009-06-24 15:46 --- This is a problem with mpc-0.6, fixed in the MPC svn repo. http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01157.html Testing with mpc-0.6 is still useful because it exercises major changes in the fortran frontend. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC|ghazi at caip dot rutgers |ghazi at gcc dot gnu dot org |dot edu | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40544
[Bug other/40302] [4.5 Regression] GCC must hard-require MPC before release
--- Comment #4 from ghazi at gcc dot gnu dot org 2009-06-27 06:23 --- Delete all the cpp HAVE_mpc goo. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40302
[Bug other/40302] [4.5 Regression] GCC must hard-require MPC before release
--- Comment #5 from ghazi at gcc dot gnu dot org 2009-07-02 18:14 --- Make sure to re-enable the commented out tests in gfortran.dg/integer_exponentiation_4.f90. See: http://gcc.gnu.org/ml/fortran/2009-06/msg00288.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40302
[Bug testsuite/40544] FAIL: gcc.dg/torture/builtin-math-6.c
-- ghazi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ghazi at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-17 07:42:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40544
[Bug testsuite/40544] FAIL: gcc.dg/torture/builtin-math-6.c
--- Comment #3 from ghazi at gcc dot gnu dot org 2009-07-17 07:43 --- Fixed as part of this: http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00815.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40544
[Bug middle-end/30789] complex folding inexact
--- Comment #1 from ghazi at gcc dot gnu dot org 2009-07-21 17:20 --- Joseph - I'm working on this one, but I'd appreciate it if you could help compile a list of good test inputs beyond the one in the first comment. I.e. especially for the annex G stuff. That way I can be more confident I'm writing it correctly. You can just list the inputs, you don't need to create an actual testcase. I'll do that. Thanks! -- ghazi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ghazi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-06-01 21:55:09 |2009-07-21 17:20:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30789
[Bug rtl-optimization/34999] Incorrect FDE entries with hot/cold code section splitting (partition_hot_cold_basic_blocks)
--- Comment #26 from ghazi at gcc dot gnu dot org 2009-08-06 19:54 --- The patch fixed the bb-reorg.c and pr34999.c testsuite failures on my x86_64 box on mainline. However I still see the failures on the 4.4 branch. Jakub - Is your patch suitable for 4.4? If so, will you please backport it? Thanks. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2009-07-24 15:37:04 |2009-08-06 19:54:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34999
[Bug middle-end/30789] complex folding inexact
--- Comment #3 from ghazi at gcc dot gnu dot org 2009-08-12 22:28 --- (In reply to comment #2) Joseph - Thanks for your reply and testvalues. > There are also cases for exact rounding where you'd expect MPC to produce > the right results but would *not* expect operations executed at runtime to > produce exactly those results. For example, (1.0 + DBL_EPSILON + 1.0i) * > (1.0 - DBL_EPSILON + 1.0i), which would only work at runtime if the code > happens to use exactly the right fused multiply-add operation. What is the "right result" for this case? GCC with MPC produces: -4.93038065763132378382330353301741393545754021943139377981e-32 + 2.0i) Unpatched GCC as well as the runtime on my x86_64 box says: 0.0 + 2.0i So the runtime here is not using the fused instruction? Is the MPC value correct? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30789
[Bug middle-end/24729] New: function calls created by builtins do not make use of inline definitions
When doing transformations on builtins, if the builtin results in a function
call that has an inline expansion, GCC emits a library call not the inline
function body. E.g. glibc defines an inline for fputc_unlocked. Given this
code:
#define _GNU_SOURCE
#include
#define MAX 1
int main ()
{
int i;
for (i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=24729
[Bug middle-end/24729] function calls created by builtins do not make use of inline definitions
--- Comment #2 from ghazi at gcc dot gnu dot org 2005-11-08 04:28 --- I'm not convinced it's the same issue. With regard to 17402, comment #6 by Joseph there refers specifically to static inlines in that builtins shouldn't generate calls to "file-scope statics". However in my case glibc is instantiating *extern inlines* and it seems legitimate that gcc could (should) generate calls which take advantage of them. (Plus they're much much faster!) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24729
[Bug middle-end/24729] function calls created by builtins do not make use of inline definitions
--- Comment #4 from ghazi at gcc dot gnu dot org 2005-11-14 01:00 ---
Builtin fputs{_unlocked} et al. are transformed via fold_builtin as well as
expand. AFAICT folding is done rather early, so perhaps this can be fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24729
[Bug c/18382] define __pic__ and/or __PIC__ in c-cppbuiltins.c instead of scattershot in target config
--- Comment #5 from ghazi at gcc dot gnu dot org 2005-11-22 03:27 --- Updated patch installed on mainline: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01575.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2005- |patches/2005- |09/msg00302.html|11/msg01575.html Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18382
[Bug middle-end/25022] New: [4.2,4.1,4.0,3.4 regression] failure to transform the unlocked stdio calls
Given the following program:
#define _GNU_SOURCE
#include
int main ()
{
fputs_unlocked("\n", stdout);
return 0;
}
GCC fails to turn fputs_unlocked into fputc_unlocked. This fails in all GCC
versions as of 3.4 through mainline, but works in gcc-3.3 so it's a regression.
The regular "locked" stdio transformation fputs->fputc works.
--
Summary: [4.2,4.1,4.0,3.4 regression] failure to transform the
unlocked stdio calls
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25022
[Bug middle-end/25022] [4.2,4.1,4.0,3.4 regression] failure to transform the unlocked stdio calls
--- Comment #1 from ghazi at gcc dot gnu dot org 2005-11-24 16:51 --- This happens because the replacement functions are obtained in builtins.c from the array implicit_built_in_decls. This array is initialized to null when the replacement function is an "extension" builtin, as are all _unlocked stdio calls. Therefore, no _unlocked calls will ever be replaced with another _unlocked call. I'm testing a patch. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ghazi at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-24 16:51:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25022
[Bug middle-end/24729] function calls created by builtins do not make use of inline definitions
--- Comment #5 from ghazi at gcc dot gnu dot org 2005-11-24 17:03 ---
Here's a version of the testcase that doesn't rely on _unlocked functions since
25022 inhibits the unlocked transformations. Compile at -O2 with and without
-DPUTCHAR_DIRECT to see the effect. Using putchar directly makes use of the
extern inline and transforms into _IO_putc, whereas the printf call only gets
as far as turning into putchar.
#include
#undef putchar
int main ()
{
#ifdef PUTCHAR_DIRECT
putchar('\n');
#else
printf ("\n");
#endif
return 0;
}
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2005-11-24 17:03:24
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24729
[Bug middle-end/25022] [3.4/4.0/4.1/4.2 regression] failure to transform the unlocked stdio calls
--- Comment #2 from ghazi at gcc dot gnu dot org 2005-11-26 01:25 --- Subject: Bug 25022 Author: ghazi Date: Sat Nov 26 01:25:20 2005 New Revision: 107535 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107535 Log: PR middle-end/25022 * builtins.c (expand_builtin_printf, expand_builtin_fprintf, fold_builtin_fputs, fold_builtin_printf, fold_builtin_fprintf): Lookup the explicit replacement functions for any unlocked stdio builtin transformations. testsuite: * gcc.c-torture/execute/builtins/fprintf.c, gcc.c-torture/execute/builtins/fputs-lib.c, gcc.c-torture/execute/builtins/fputs.c, gcc.c-torture/execute/builtins/lib/fprintf.c, gcc.c-torture/execute/builtins/lib/printf.c, gcc.c-torture/execute/builtins/printf.c: Test the unlocked style. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/execute/builtins/fprintf.c trunk/gcc/testsuite/gcc.c-torture/execute/builtins/fputs-lib.c trunk/gcc/testsuite/gcc.c-torture/execute/builtins/fputs.c trunk/gcc/testsuite/gcc.c-torture/execute/builtins/lib/fprintf.c trunk/gcc/testsuite/gcc.c-torture/execute/builtins/lib/printf.c trunk/gcc/testsuite/gcc.c-torture/execute/builtins/printf.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25022
[Bug middle-end/25022] [3.4/4.0/4.1/4.2 regression] failure to transform the unlocked stdio calls
--- Comment #3 from ghazi at gcc dot gnu dot org 2005-11-26 01:31 --- Subject: Bug 25022 Author: ghazi Date: Sat Nov 26 01:31:54 2005 New Revision: 107536 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107536 Log: PR middle-end/25022 * builtins.c (expand_builtin_printf, expand_builtin_fprintf, fold_builtin_fputs, fold_builtin_printf, fold_builtin_fprintf): Lookup the explicit replacement functions for any unlocked stdio builtin transformations. testsuite: * gcc.c-torture/execute/builtins/fprintf.c, gcc.c-torture/execute/builtins/fputs-lib.c, gcc.c-torture/execute/builtins/fputs.c, gcc.c-torture/execute/builtins/lib/fprintf.c, gcc.c-torture/execute/builtins/lib/printf.c, gcc.c-torture/execute/builtins/printf.c: Test the unlocked style. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/builtins.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/execute/builtins/fprintf.c branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/execute/builtins/fputs-lib.c branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/execute/builtins/fputs.c branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/execute/builtins/lib/fprintf.c branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/execute/builtins/lib/printf.c branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/execute/builtins/printf.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25022
[Bug middle-end/25022] [3.4/4.0 regression] failure to transform the unlocked stdio calls
--- Comment #5 from ghazi at gcc dot gnu dot org 2005-11-27 14:47 --- 4.0 patch here: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01845.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2005- |patches/2005- |11/msg01772.html|11/msg01845.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25022
[Bug middle-end/25120] New: [3.4/4.0/4.1/4.2] builtin printf/fprintf is confused by -fexec-charset
With a program compiled with e.g. -O2 -fexec-charset=IBM1047, the builtin
handlers for printf and fprintf get confused because they check for matching
stuff in the format string like "%s", "%s\n", "%c" and trailing "\n" using the
host's charset values. So they don't match correctly when compiling strings in
the target charset and thus fail to do the appropriate transformations. This
is merely a slight pessimization.
However what's worse is they'll do incorrect transformations if the user's
program happens to have matching strings. E.g.
printf ("hello world\012");
In the above, "\012" is ascii "\n" but it's something else in other charsets.
However, GCC will still transform this call into puts with the "\012" stripped
off. This yields "wrong code".
--
Summary: [3.4/4.0/4.1/4.2] builtin printf/fprintf is confused by
-fexec-charset
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: wrong-code, missed-optimization
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25120
[Bug middle-end/25120] [3.4/4.0/4.1/4.2] builtin printf/fprintf is confused by -fexec-charset
--- Comment #1 from ghazi at gcc dot gnu dot org 2005-11-27 15:52 --- This is the same bug as PR 18785 and probably has a similar solution. I'm working on a patch. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ghazi at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-27 15:52:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25120
[Bug middle-end/25120] builtin printf/fprintf is confused by -fexec-charset
--- Comment #3 from ghazi at gcc dot gnu dot org 2005-11-27 16:59 --- Yes same conceptual problem, but entirely different GCC location. This bug lies in builtins.c and PR 20110 lies in c-format.c. What I mean is that they be fixed separately and should not have any bugzilla dependencies. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25120
[Bug middle-end/25120] builtin *printf handlers are confused by -fexec-charset
--- Comment #4 from ghazi at gcc dot gnu dot org 2005-11-27 17:01 --- builtin sprintf (and _chk friends) also have the problem, changed summary to reflect that. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Summary|builtin printf/fprintf is |builtin *printf handlers are |confused by -fexec-charset |confused by -fexec-charset http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25120
[Bug middle-end/25120] builtin *printf handlers are confused by -fexec-charset
-- ghazi at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25120
[Bug middle-end/25120] builtin *printf handlers are confused by -fexec-charset
--- Comment #6 from ghazi at gcc dot gnu dot org 2005-11-28 02:45 --- *** Bug 20109 has been marked as a duplicate of this bug. *** -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25120
[Bug middle-end/20109] printf optimizations and non-ASCII character sets
--- Comment #2 from ghazi at gcc dot gnu dot org 2005-11-28 02:45 --- *** This bug has been marked as a duplicate of 25120 *** -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||ghazi at gcc dot gnu dot org Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20109
[Bug objc/7098] ObjC front end doesn't understand attributes on method parameters
--- Comment #4 from ghazi at gcc dot gnu dot org 2005-11-28 03:16 --- Andrew, any progress on this one? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7098
[Bug middle-end/21988] GCC should transform printf("%s",foo) and printf("foo") into fputs(foo,stdout)
--- Comment #2 from ghazi at gcc dot gnu dot org 2005-11-28 03:23 --- Getting stdout wrapped in an inline function is not hard. I can create something fixincl or whatever to capture that. The part I don't know how to do is expand that inline function's body into the code stream from fold_builtin_printf or expand_builtin_printf. Just inserting the inline function call as the right parameter to fputs and calling expand() used to just magically work when we had the RTL inliner because that ran after builtin expansion. Now with the tree inliner it's too late so we'd have to do something else extra. Anybody have ideas on this? It might also help with PR 24729. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21988
[Bug middle-end/25120] builtin *printf handlers are confused by -fexec-charset
--- Comment #7 from ghazi at gcc dot gnu dot org 2005-11-28 03:36 --- 4.0 patch here: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01918.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25120
[Bug middle-end/20109] printf optimizations and non-ASCII character sets
--- Comment #3 from ghazi at gcc dot gnu dot org 2005-11-29 05:17 --- Subject: Bug 20109 Author: ghazi Date: Tue Nov 29 05:17:20 2005 New Revision: 107652 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107652 Log: PR middle-end/20109 PR middle-end/25120 * builtins.c (init_target_chars): New. (expand_builtin_printf, expand_builtin_fprintf, expand_builtin_sprintf, fold_builtin_sprintf, maybe_emit_sprintf_chk_warning, fold_builtin_sprintf_chk, fold_builtin_snprintf_chk, fold_builtin_printf, fold_builtin_fprintf): Check for matching format strings using the target charset. testsuite: * gcc.dg/charset/builtin2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/charset/builtin2.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20109
[Bug middle-end/25120] builtin *printf handlers are confused by -fexec-charset
--- Comment #8 from ghazi at gcc dot gnu dot org 2005-11-29 05:17 --- Subject: Bug 25120 Author: ghazi Date: Tue Nov 29 05:17:20 2005 New Revision: 107652 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107652 Log: PR middle-end/20109 PR middle-end/25120 * builtins.c (init_target_chars): New. (expand_builtin_printf, expand_builtin_fprintf, expand_builtin_sprintf, fold_builtin_sprintf, maybe_emit_sprintf_chk_warning, fold_builtin_sprintf_chk, fold_builtin_snprintf_chk, fold_builtin_printf, fold_builtin_fprintf): Check for matching format strings using the target charset. testsuite: * gcc.dg/charset/builtin2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/charset/builtin2.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25120
[Bug middle-end/20109] printf optimizations and non-ASCII character sets
--- Comment #4 from ghazi at gcc dot gnu dot org 2005-11-29 05:18 --- Subject: Bug 20109 Author: ghazi Date: Tue Nov 29 05:17:56 2005 New Revision: 107653 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107653 Log: PR middle-end/20109 PR middle-end/25120 * builtins.c (init_target_chars): New. (expand_builtin_printf, expand_builtin_fprintf, expand_builtin_sprintf, fold_builtin_sprintf, maybe_emit_sprintf_chk_warning, fold_builtin_sprintf_chk, fold_builtin_snprintf_chk, fold_builtin_printf, fold_builtin_fprintf): Check for matching format strings using the target charset. testsuite: * gcc.dg/charset/builtin2.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/charset/builtin2.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/builtins.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20109
[Bug middle-end/25120] builtin *printf handlers are confused by -fexec-charset
--- Comment #9 from ghazi at gcc dot gnu dot org 2005-11-29 05:18 --- Subject: Bug 25120 Author: ghazi Date: Tue Nov 29 05:17:56 2005 New Revision: 107653 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107653 Log: PR middle-end/20109 PR middle-end/25120 * builtins.c (init_target_chars): New. (expand_builtin_printf, expand_builtin_fprintf, expand_builtin_sprintf, fold_builtin_sprintf, maybe_emit_sprintf_chk_warning, fold_builtin_sprintf_chk, fold_builtin_snprintf_chk, fold_builtin_printf, fold_builtin_fprintf): Check for matching format strings using the target charset. testsuite: * gcc.dg/charset/builtin2.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/charset/builtin2.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/builtins.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25120
[Bug middle-end/25120] builtin *printf handlers are confused by -fexec-charset
--- Comment #10 from ghazi at gcc dot gnu dot org 2005-11-29 05:18 --- Subject: Bug 25120 Author: ghazi Date: Tue Nov 29 05:18:13 2005 New Revision: 107654 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107654 Log: PR middle-end/20109 PR middle-end/25120 * builtins.c (init_target_chars): New. (expand_builtin_printf, expand_builtin_fprintf, expand_builtin_sprintf, fold_builtin_sprintf): Check for matching format strings using the target charset. testsuite: * gcc.dg/charset/builtin2.c: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/charset/builtin2.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/builtins.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25120
[Bug middle-end/20109] printf optimizations and non-ASCII character sets
--- Comment #5 from ghazi at gcc dot gnu dot org 2005-11-29 05:18 --- Subject: Bug 20109 Author: ghazi Date: Tue Nov 29 05:18:13 2005 New Revision: 107654 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107654 Log: PR middle-end/20109 PR middle-end/25120 * builtins.c (init_target_chars): New. (expand_builtin_printf, expand_builtin_fprintf, expand_builtin_sprintf, fold_builtin_sprintf): Check for matching format strings using the target charset. testsuite: * gcc.dg/charset/builtin2.c: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/charset/builtin2.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/builtins.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20109
[Bug testsuite/19231] Execute failure in gcc.c-torture/execute/builtins/strlen-3.c with -fpic/-fPIC
--- Comment #3 from ghazi at gcc dot gnu dot org 2005-11-29 13:55 --- Fixed by: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01889.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19231
[Bug target/19227] [3.4 only] Error in gcc.c-torture/compile/20000804-1.c when using -fpic/-fPIC on i686-pc-linux-gnu
--- Comment #2 from ghazi at gcc dot gnu dot org 2005-11-29 14:03 --- Fixed in 4.0.3 and later by: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01889.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19227
[Bug testsuite/19275] [3.4/4.0] gcc.dg/20020919-1.c fails with -fpic/-fPIC on i686-pc-linux-gnu
--- Comment #5 from ghazi at gcc dot gnu dot org 2005-11-29 14:25 --- These two patches fixed the problem on mainline/4.1 and need to be backported: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02322.html http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02828.html I'll do it after testing. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ghazi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-11-03 17:09:40 |2005-11-29 14:25:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19275
[Bug middle-end/25158] FAIL: gcc.c-torture/execute/builtins/fprintf.c compilation
--- Comment #2 from ghazi at gcc dot gnu dot org 2005-11-29 21:46 ---
Hmm this is convoluted, but I think I know what's going on:
We're running the builtin fprintf check. I recently added a small sanity check
to ensure that fprintf_unlocked also works. Now we're getting an unresolved
symbol calling fputs_unlocked.
But to ensure that these _unlocked style calls don't result in unresolved
symbols I had only added cases that should have been completely optimized away.
E.g. fprintf_unlocked(stream, "") which should become nothing.
Now hpux defines DONT_HAVE_FPUTC_UNLOCKED, notice that's fputC_unlocked not
fputS_unlocked which is the unresolved symbol we get. But we have this code at
the top of fold_builtin_fputs:
/* If the return value is used, or the replacement _DECL isn't
initialized, don't do the transformation. */
if (!ignore || !fn_fputc || !fn_fwrite)
return 0;
So the solution is to split these checks and move the !fn_fputc || !fn_fwrite
check later on where we actually attempt to use them. That way the path which
eliminates zero-length strings will still be executed.
I'll put together a patch.
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ghazi at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2005-11-29 21:46:13
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25158
[Bug c/25169] New: [4.0 regression] tree checking failures in gcc.dg/20040203-1.c, cast-1.c, cast-2.c, cast-3.c
On i686-unknown-linux-gnu with the 4.0.x branch, I'm getting tree checking
failures in gcc.dg/20040203-1.c, cast-1.c, cast-2.c, cast-3.c. From the
logfile, the errors in 20040203-1.c are of this form:
20040203-1.c:17: internal compiler error: tree check: expected class
'constant', have 'unary' (nop_expr) in build_c_cast, at c-typeck.c:3330
The errors from cast-*.c are of this form:
cast-1.c:25: internal compiler error: tree check: expected class 'constant',
have 'declaration' (var_decl) in build_c_cast, at c-typeck.c:3330
It was clean as of here:
http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg00301.html
It started happening here:
http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg00360.html
To reproduce, configure with --enable-checking=yes,rtl then bootstrap the 4.0
branch and run the testsuite.
The 4.1 branch and mainline are all clean for some reason.
--
Summary: [4.0 regression] tree checking failures in
gcc.dg/20040203-1.c, cast-1.c, cast-2.c, cast-3.c
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Keywords: ice-checking
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25169
[Bug c/25169] [4.0 regression] tree checking failures in gcc.dg/20040203-1.c, cast-1.c, cast-2.c, cast-3.c
--- Comment #1 from ghazi at gcc dot gnu dot org 2005-11-30 00:44 --- Based on the date it started failing, I'm guessing it was this patch that triggered it: 2005-11-07 Paolo Bonzini <[EMAIL PROTECTED]> PR c/24599 * c-typeck.c (build_c_cast): Try using a shared constant, and see if TREE_OVERFLOW or TREE_CONSTANT_OVERFLOW really changed. (readonly_error): Fix formatting error. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25169
[Bug testsuite/19275] [3.4/4.0] gcc.dg/20020919-1.c fails with -fpic/-fPIC on i686-pc-linux-gnu
-- ghazi at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||11/msg02081.html Target Milestone|--- |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19275
[Bug c/25169] [4.0 regression] tree checking failures in gcc.dg/20040203-1.c, cast-1.c, cast-2.c, cast-3.c
-- ghazi at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25169
[Bug testsuite/19275] [3.4/4.0] gcc.dg/20020919-1.c fails with -fpic/-fPIC on i686-pc-linux-gnu
--- Comment #6 from ghazi at gcc dot gnu dot org 2005-11-30 18:04 --- Subject: Bug 19275 Author: ghazi Date: Wed Nov 30 18:04:46 2005 New Revision: 107729 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107729 Log: PR testsuite/19275 Backport from mainline: * gcc.dg/20020919-1.c: Fix for x86 Darwin. * gcc.dg/20020919-1.c: Remove unnecessary conditional. Modified: branches/gcc-3_4-branch/gcc/testsuite/ChangeLog branches/gcc-3_4-branch/gcc/testsuite/gcc.dg/20020919-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19275
[Bug testsuite/19275] [3.4/4.0] gcc.dg/20020919-1.c fails with -fpic/-fPIC on i686-pc-linux-gnu
--- Comment #7 from ghazi at gcc dot gnu dot org 2005-11-30 18:06 --- Subject: Bug 19275 Author: ghazi Date: Wed Nov 30 18:06:01 2005 New Revision: 107730 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107730 Log: PR testsuite/19275 Backport from mainline: * gcc.dg/20020919-1.c: Fix for x86 Darwin. * gcc.dg/20020919-1.c: Remove unnecessary conditional. Modified: branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/20020919-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19275
[Bug testsuite/19275] [3.4/4.0] gcc.dg/20020919-1.c fails with -fpic/-fPIC on i686-pc-linux-gnu
--- Comment #8 from ghazi at gcc dot gnu dot org 2005-11-30 18:41 --- Patch backported to 3.4 and 4.0. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19275
[Bug target/19226] [3.4 only] ICE in g++.old-deja/g++.pt/asm1.C and asm2.C with -fpic/-fPIC
-- ghazi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ghazi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-04-07 06:28:35 |2005-11-30 23:36:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19226
[Bug target/19227] [3.4 only] Error in gcc.c-torture/compile/20000804-1.c when using -fpic/-fPIC on i686-pc-linux-gnu
--- Comment #3 from ghazi at gcc dot gnu dot org 2005-11-30 23:38 --- 3.4 patch here: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg02163.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ghazi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-11-26 01:44:59 |2005-11-30 23:38:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19227
[Bug target/19227] [3.4 only] Error in gcc.c-torture/compile/20000804-1.c when using -fpic/-fPIC on i686-pc-linux-gnu
-- ghazi at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||11/msg02163.html Target Milestone|--- |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19227
[Bug target/19228] [3.4 only] Error in gcc.dg/20011119-1.c when using -fpic/-fPIC
--- Comment #6 from ghazi at gcc dot gnu dot org 2005-11-30 23:40 --- 3.4 patch here: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg02163.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ghazi at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||11/msg02163.html Status|NEW |ASSIGNED Last reconfirmed|2005-04-07 07:55:04 |2005-11-30 23:40:47 date|| Target Milestone|3.4.6 |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19228
[Bug target/19226] ICE in g++.old-deja/g++.pt/asm1.C and asm2.C with -fpic/-fPIC
--- Comment #6 from ghazi at gcc dot gnu dot org 2005-11-30 23:56 --- Patch installed: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg02163.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work|4.0.0 |3.4.5 4.0.0 Resolution||FIXED Summary|[3.4 only] ICE in g++.old- |ICE in g++.old- |deja/g++.pt/asm1.C and |deja/g++.pt/asm1.C and |asm2.C with -fpic/-fPIC |asm2.C with -fpic/-fPIC Target Milestone|3.4.6 |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19226
[Bug target/19227] [3.4 only] Error in gcc.c-torture/compile/20000804-1.c when using -fpic/-fPIC on i686-pc-linux-gnu
--- Comment #4 from ghazi at gcc dot gnu dot org 2005-11-30 23:58 --- Patch installed: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg02163.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- | |patches/2005- | |11/msg02163.html| Status|ASSIGNED|RESOLVED Known to work|4.0.3 |3.4.5 4.0.3 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19227
[Bug target/19228] [3.4 only] Error in gcc.dg/20011119-1.c when using -fpic/-fPIC
--- Comment #7 from ghazi at gcc dot gnu dot org 2005-12-01 00:00 --- Patch installed: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg02163.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- | |patches/2005- | |11/msg02163.html| Status|ASSIGNED|RESOLVED Known to work|4.0.0 |3.4.5 4.0.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19228
[Bug middle-end/25158] FAIL: gcc.c-torture/execute/builtins/fprintf.c compilation
--- Comment #3 from ghazi at gcc dot gnu dot org 2005-12-01 00:05 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg02127.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||11/msg02127.html Known to fail||4.1.0 4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25158
[Bug middle-end/25158] FAIL: gcc.c-torture/execute/builtins/fprintf.c compilation
--- Comment #4 from ghazi at gcc dot gnu dot org 2005-12-01 02:31 --- Subject: Bug 25158 Author: ghazi Date: Thu Dec 1 02:31:49 2005 New Revision: 107762 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107762 Log: PR middle-end/25158 * builtins.c (fold_builtin_fputs): Defer check for missing replacement functions. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25158
[Bug middle-end/25158] FAIL: gcc.c-torture/execute/builtins/fprintf.c compilation
--- Comment #5 from ghazi at gcc dot gnu dot org 2005-12-01 02:33 --- Subject: Bug 25158 Author: ghazi Date: Thu Dec 1 02:32:58 2005 New Revision: 107763 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107763 Log: PR middle-end/25158 * builtins.c (fold_builtin_fputs): Defer check for missing replacement functions. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/builtins.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25158
[Bug c++/25203] New: [4.0] enable checking failure in g++.dg/opt/mmx2.C
On i686-pc-linux-gnu with current gcc-4.0.x, I'm getting a failure in
g++.dg/opt/mmx2.C:
http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg01435.html
I think it's triggered by turning on checking, because I don't see other people
getting the error. I configured with: --enable-checking=yes,rtl
I get an ICE here:
Program received signal SIGSEGV, Segmentation fault.
memory_operand (op=0xabababab, mode=VOIDmode) at
../../egcc-4.0-SVN20051130/gcc/recog.c:1279
1279 if (GET_CODE (inner) == SUBREG)
Here the variable "inner" is set to op which is a parameter to the function
memory_operand(). And memory_operand() is passed operands[2] from
get_attr_memory(). The value is 0xabababab, i.e. uninitialized garbage.
In insn-extract.c, only if checking is enabled, the function insn_extract
memsets recog_data.operand ("operands" is a macro for this) to 0xab so that any
uninitialized areas get this value.
I don't see this failure with 4.1 or mainline.
--
Summary: [4.0] enable checking failure in g++.dg/opt/mmx2.C
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Keywords: ice-checking, ssemmx
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25203
[Bug c++/25203] [4.0] enable checking failure in g++.dg/opt/mmx2.C
-- ghazi at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25203
[Bug c/25169] [4.0 regression] tree checking failures in gcc.dg/20040203-1.c, cast-1.c, cast-2.c, cast-3.c
--- Comment #4 from ghazi at gcc dot gnu dot org 2005-12-01 14:05 --- My results from last night confirm it's fixed now, thanks. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25169
[Bug middle-end/25158] FAIL: gcc.c-torture/execute/builtins/fprintf.c compilation
--- Comment #6 from ghazi at gcc dot gnu dot org 2005-12-01 22:24 --- Fixed, clean test results here: http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00028.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- | |patches/2005- | |11/msg02127.html| Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25158
[Bug middle-end/25022] [3.4/4.0 regression] failure to transform the unlocked stdio calls
--- Comment #6 from ghazi at gcc dot gnu dot org 2005-12-01 22:45 --- Updated 4.0 patch here: http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00089.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2005- |patches/2005- |11/msg01845.html|12/msg00089.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25022
[Bug target/25213] New: [3.4] -fpic/-fPIC testsuite failures in gcc.dg/i386-387-3.c and i386-387-4.c
On i686-pc-linux-gnu with the 3.4 branch, I'm getting failures in the following testcases when running with -fpic or -fPIC: FAIL: gcc.dg/i386-387-3.c scan-assembler fldpi FAIL: gcc.dg/i386-387-4.c scan-assembler fldpi Current testsuite report is here: http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00027.html -- Summary: [3.4] -fpic/-fPIC testsuite failures in gcc.dg/i386-387- 3.c and i386-387-4.c Product: gcc Version: 3.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25213
[Bug target/25213] [3.4] -fpic/-fPIC testsuite failures in gcc.dg/i386-387-3.c and i386-387-4.c
-- ghazi at gcc dot gnu dot org changed: What|Removed |Added Known to fail||3.4.5 Known to work||4.0.3 Target Milestone|--- |3.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25213
[Bug target/25214] New: [3.4/4.0/4.1/4.2] -fpic/-fPIC testsuite failures in gcc.dg/i386-local2.c
-- Summary: [3.4/4.0/4.1/4.2] -fpic/-fPIC testsuite failures in gcc.dg/i386-local2.c Product: gcc Version: 3.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25214
[Bug target/25214] [3.4/4.0/4.1/4.2] -fpic/-fPIC testsuite failures in gcc.dg/i386-local2.c
-- ghazi at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||23224 nThis|| Known to fail||3.4.5 4.0.3 4.1.0 4.2.0 Target Milestone|--- |3.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25214
[Bug target/25215] New: [4.0/4.1/4.2] -fpic/-fPIC failure in gcc.dg/20050503-1.c
On i686-pc-linux-gnu with the 4.0 branch, I'm getting a failure in the following testcase when running with -fpic or -fPIC: FAIL: gcc.dg/20050503-1.c scan-assembler-not call Current testsuite report is here: http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00026.html -- Summary: [4.0/4.1/4.2] -fpic/-fPIC failure in gcc.dg/20050503-1.c Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org GCC target triplet: i686-pc-linux-gnu OtherBugsDependingO 23224 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25215
[Bug target/25214] [3.4/4.0/4.1/4.2] -fpic/-fPIC testsuite failures in gcc.dg/i386-local2.c
--- Comment #1 from ghazi at gcc dot gnu dot org 2005-12-02 00:33 --- On i686-pc-linux-gnu with the 3.4 branch, I'm getting a failure in the following testcase when running with -fpic or -fPIC: FAIL: gcc.dg/i386-local2.c scan-assembler-not sub[^n]*sp Current testsuite report is here: http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00027.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25214
[Bug target/25216] New: [4.0/4.1/4.2] -fpic/-fPIC failure in gcc.target/i386/pr21291.c
On i686-pc-linux-gnu with the 4.0 branch, I'm getting a failure in the following testcase when running with -fpic or -fPIC: FAIL: gcc.target/i386/pr21291.c (test for excess errors) Current testsuite report is here: http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00026.html -- Summary: [4.0/4.1/4.2] -fpic/-fPIC failure in gcc.target/i386/pr21291.c Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org GCC target triplet: i686-pc-linux-gnu OtherBugsDependingO 23224 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25216
[Bug target/25216] [4.0/4.1/4.2] -fpic/-fPIC failure in gcc.target/i386/pr21291.c
-- ghazi at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.0.3 4.1.0 4.2.0 Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25216
[Bug target/25216] [4.0/4.1/4.2] -fpic/-fPIC failure in gcc.target/i386/pr21291.c
--- Comment #1 from ghazi at gcc dot gnu dot org 2005-12-02 00:48 --- Rth thinks it's an actual bug requiring investigation: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01899.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25216
[Bug target/25216] [4.0/4.1/4.2] -fpic/-fPIC failure in gcc.target/i386/pr21291.c
--- Comment #2 from ghazi at gcc dot gnu dot org 2005-12-02 00:50 --- testsuite logfile says: FAIL: gcc.target/i386/pr21291.c (test for excess errors) Excess errors: .../gcc.target/i386/pr21291.c:18: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25216
[Bug testsuite/18491] testsuite failure: WARNING: g++.old-deja/g++.mike/p10769a.C compilation failed to produce executable
--- Comment #10 from ghazi at gcc dot gnu dot org 2005-12-02 02:12 --- Subject: Bug 18491 Author: ghazi Date: Fri Dec 2 02:12:15 2005 New Revision: 107860 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107860 Log: 2005-12-01 Kaveh R. Ghazi <[EMAIL PROTECTED]> Backport: 2005-02-09 Janis Johnson <[EMAIL PROTECTED]> PR C++/18491 * g++.old-deja/g++.mike/p10769a.C: Remove. Removed: branches/gcc-3_4-branch/gcc/testsuite/g++.old-deja/g++.mike/p10769a.C Modified: branches/gcc-3_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18491
[Bug middle-end/25158] FAIL: gcc.c-torture/execute/builtins/fprintf.c compilation
--- Comment #7 from ghazi at gcc dot gnu dot org 2005-12-02 14:05 --- Subject: Bug 25158 Author: ghazi Date: Fri Dec 2 14:05:09 2005 New Revision: 107891 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107891 Log: 2005-11-30 Kaveh R. Ghazi <[EMAIL PROTECTED]> PR middle-end/25022 * builtins.c (expand_builtin_printf, expand_builtin_fprintf, fold_builtin_fputs): Lookup the explicit replacement functions for any unlocked stdio builtin transformations. PR middle-end/25158 * builtins.c (fold_builtin_fputs): Defer check for missing replacement functions. testsuite: * gcc.c-torture/execute/builtins/fprintf.c, gcc.c-torture/execute/builtins/fputs-lib.c, gcc.c-torture/execute/builtins/fputs.c, gcc.c-torture/execute/builtins/lib/fprintf.c, gcc.c-torture/execute/builtins/lib/printf.c, gcc.c-torture/execute/builtins/printf.c: Test the unlocked style. Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/builtins.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/gcc.c-torture/execute/builtins/fprintf.c branches/gcc-4_0-branch/gcc/testsuite/gcc.c-torture/execute/builtins/fputs-lib.c branches/gcc-4_0-branch/gcc/testsuite/gcc.c-torture/execute/builtins/fputs.c branches/gcc-4_0-branch/gcc/testsuite/gcc.c-torture/execute/builtins/lib/fprintf.c branches/gcc-4_0-branch/gcc/testsuite/gcc.c-torture/execute/builtins/lib/printf.c branches/gcc-4_0-branch/gcc/testsuite/gcc.c-torture/execute/builtins/printf.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25158
[Bug middle-end/25022] [3.4/4.0 regression] failure to transform the unlocked stdio calls
--- Comment #7 from ghazi at gcc dot gnu dot org 2005-12-02 14:05 --- Subject: Bug 25022 Author: ghazi Date: Fri Dec 2 14:05:09 2005 New Revision: 107891 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107891 Log: 2005-11-30 Kaveh R. Ghazi <[EMAIL PROTECTED]> PR middle-end/25022 * builtins.c (expand_builtin_printf, expand_builtin_fprintf, fold_builtin_fputs): Lookup the explicit replacement functions for any unlocked stdio builtin transformations. PR middle-end/25158 * builtins.c (fold_builtin_fputs): Defer check for missing replacement functions. testsuite: * gcc.c-torture/execute/builtins/fprintf.c, gcc.c-torture/execute/builtins/fputs-lib.c, gcc.c-torture/execute/builtins/fputs.c, gcc.c-torture/execute/builtins/lib/fprintf.c, gcc.c-torture/execute/builtins/lib/printf.c, gcc.c-torture/execute/builtins/printf.c: Test the unlocked style. Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/builtins.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/gcc.c-torture/execute/builtins/fprintf.c branches/gcc-4_0-branch/gcc/testsuite/gcc.c-torture/execute/builtins/fputs-lib.c branches/gcc-4_0-branch/gcc/testsuite/gcc.c-torture/execute/builtins/fputs.c branches/gcc-4_0-branch/gcc/testsuite/gcc.c-torture/execute/builtins/lib/fprintf.c branches/gcc-4_0-branch/gcc/testsuite/gcc.c-torture/execute/builtins/lib/printf.c branches/gcc-4_0-branch/gcc/testsuite/gcc.c-torture/execute/builtins/printf.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25022
[Bug target/25242] New: [3.4] testsuite failure in i386-sse-2.c on x86_64-unknown-linux-gnu
When running the 3.4 testsuite on x86_64-unknown-linux-gnu, I'm getting the following error: FAIL: gcc.dg/i386-sse-2.c (test for excess errors) as shown here: http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00083.html The logfile says: In file included from gcc/include/xmmintrin.h:1216, from testsuite/gcc.dg/i386-sse-2.c:12: gcc/include/emmintrin.h: In function `_mm_sqrt_sd': gcc/include/emmintrin.h:248: internal compiler error: in instantiate_virtual_regs_lossage, at function.c:3765 Other than comments, the testcase merely has these lines: #define static #define __inline #include -- Summary: [3.4] testsuite failure in i386-sse-2.c on x86_64- unknown-linux-gnu Product: gcc Version: 3.4.6 Status: UNCONFIRMED Keywords: ssemmx Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25242
[Bug target/25242] [3.4] testsuite failure in i386-sse-2.c on x86_64-unknown-linux-gnu
--- Comment #1 from ghazi at gcc dot gnu dot org 2005-12-03 19:39 --- I configured with --enable-checking=yes,rtl however I don't think that's necessary to trigger the error. I see another report without checking here that fails the test. http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00129.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25242
[Bug target/25242] [3.4] testsuite failure in i386-sse-2.c on x86_64-unknown-linux-gnu
--- Comment #2 from ghazi at gcc dot gnu dot org 2005-12-03 19:41 ---
Here's a reduced testcase, compile it with cc1 targetted to
x86_64-unknown-linux-gnu:
cc1 -fpreprocessed i386-sse-2.i -quiet -dumpbase i386-sse-2.c -msse -mtune=k8
-auxbase-strip i386-sse-2.s -O0 -version -o i386-sse-2.s
typedef double __v2df __attribute__ ((mode (V2DF)));
__v2df
_mm_sqrt_sd (__v2df __A, __v2df __B)
{
__v2df __tmp = __builtin_ia32_movsd ((__v2df)__A, (__v2df)__B);
return (__v2df)__builtin_ia32_sqrtsd ((__v2df)__tmp);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25242
