[Bug c/32448] [3.3 / 3.4 / 4.1 / 4.2 / 4.3 Regression] abs / printf bug
--- Comment #12 from rob1weld at aol dot com 2007-06-23 07:51 --- > Send a patch that implements your argflaps Cyclone uses what it calls "thin" and "fat" pointers. We could implement this in GCC. An extra byte per variable could store the type and a bit of code could check it (at run-time) and perform "run-time conversion", use "Syntactic Sugar" or "C overloading" - depending on what you would like to call it.. Investigating: 1): Cyclone is a dialect of C that retains its transparency and control, but adds the benefits of safety (no unchecked runtime errors, for instance). In Cyclone, buffer overflows and related bugs are prevented for all programs, whether written by security experts or by novices. The changes required to achieve safety are pervasive, but Cyclone is still recognizably C. http://www.eecs.harvard.edu/~greg/cyclone/ 2a): CIL (C Intermediate Language) is a high-level representation along with a set of tools that permit easy analysis and source-to-source transformation of C programs. http://hal.cs.berkeley.edu/cil/ . This intermediate language is used to stage both Deputy and CCured. 2b): CCured is a source-to-source translator for C. It analyzes the C program to determine the smallest number of run-time checks that must be inserted in the program to prevent all memory safety violations. The resulting program is memory safe, meaning that it will stop rather than overrun a buffer or scribble over memory that it shouldn't touch. Many programs can be made memory-safe this way while losing only 1060% run-time performance (the performance cost is smaller for cleaner programs, and can be improved further by holding CCured's hand on the parts of the program that it does not understand by itself). Using CCured we have found bugs that Purify misses with an order of magnitude smaller run-time cost. http://hal.cs.berkeley.edu/ccured/index.html 2c): Deputy is a C compiler that is capable of preventing common C programming errors, including out-of-bounds memory accesses as well as many other common type-safety errors. It is designed to work on real-world code, up to and including the Linux kernel itself. Deputy allows C programmers to provide simple type annotations that describe pointer bounds and other important program invariants. Deputy verifies that your program adheres to these invariants through a combination of compile-time and run-time checking. http://deputy.cs.berkeley.edu/ These projects have been operating for many years, come from a reputable source and integrate with gcc (albiet they do not seem to have tried 4.3.0). A paper on Deputy - Static Analysis of C for Hybrid Type Checking http://www.eecs.berkeley.edu/Pubs/TechRpts/2007/EECS-2007-1.pdf The difference between Duputy and CCured (both implemented on top of the CIL framework) is: CCured is a whole program analysis that instruments pointers with bounds information. As in Deputy the bounds information may need to be checked at runtime. The CCured system includes an optimization phase that also attempts to reason about bounds checks, null checks, and others. The Deputy type system presents its optimizer with some different challenges than those seen by the CCured optimizer. The primary challenge is the sheer volume of runtime checks added by the type system. On the benchmarks presented here, deputized code achieves better performance than cured code, however CCured also enforces allocation safety, which Deputy does not. The "license" for these in one case is to simply credit the authors. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32448
[Bug fortran/30792] DATA implied-do substring allowed with -std=f95/f2003
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-23 07:34 ---
R527 data-implied-do
is ( data-i-do-object-list , data-i-do-variable = scalar-int-expr,
scalar-int-expr [ , scalar-int-expr ] )
R528 data-i-do-object is array-element
or scalar-structure-component
or data-implied-do
which does not include substrings.
Related:
character(len=20) :: a = 'xyz'
data a(1:3)/'abc'/
-> Overlapping storage initializations (otherwise valid)
Should be detected with -std=f95.
character(len=3) :: b
integer :: i
data (b(i:i),i=1,3)/3*'x'/
data (b(i:i),i=2,2)/'y'/
print *, b
-> Overlapping storage initializations (substrings are also not standard
conform)
-> Should this be detected or ignored?
(This is not detected by ifort either; both ifort and gfortran print 'xxx'; if
one reverses the data order, both print 'xyx'.)
Observation (should be ok either way):
character(len=20) :: a
data a(1:3)/'abc'/
print '(":",a,":")', a
gfortran prints:
:abc :
g95, NAG f95, ifort print:
:abc:
(for "a = 'abc'" they have the same as gfortran. -> preinitialized by \0 vs. by
' '?)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30792
[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-06-23 08:56 --- The patch looks reasonable and is ok if you add the testcase from comment #2 and it bootstraps®tests. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31541
[Bug c/32448] [3.3 / 3.4 / 4.1 / 4.2 / 4.3 Regression] abs / printf bug
--- Comment #13 from rob1weld at aol dot com 2007-06-23 08:32 --- (In reply to comment #11) > (1) Try -Wformat "-Wall" includes "-Wformat" according to gcc.info. See comment 7 for the command line I used: /* /usr/test/bin/gcc -Wall -Wconversion -o math_test_7 math_test_7.c */ > (3) There is an expectation someone writing C might actually > adhere to the Standard >From time to time that does not always occur. See here: http://gcc.gnu.org/bugzilla/buglist.cgi?emailreporter1=1&emailtype1=substring&[EMAIL PROTECTED] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32448
[Bug tree-optimization/30563] [4.3 Regression] ice for legal code with flags -O2 -fno-unit-at-a-time
--- Comment #10 from tbm at cyrius dot com 2007-06-23 09:16 --- (In reply to comment #8) > > This bug is extremely common (seen while compiling the Debian archive). > > Honza, can you take a look soon? > > I will check it tomorrow. However why users use -fno-unit-at-a-time at > all? Do you have some idea what packages, except for kernel, use it? Haskell -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30563
[Bug middle-end/30537] [4.3 regression] ICE with -fno-unit-at-a-time an inlining
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-06-23 09:13 --- *** Bug 30563 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dcb314 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30537
[Bug tree-optimization/30563] [4.3 Regression] ice for legal code with flags -O2 -fno-unit-at-a-time
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-06-23 09:13 --- It is a dup. *** This bug has been marked as a duplicate of 30537 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30563
[Bug middle-end/29478] [4.2/4.3 Regression] optmization generates warning for casts
--- Comment #13 from rguenth at gcc dot gnu dot org 2007-06-23 09:39 --- Mine, patch posted. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-10-15 15:25:39 |2007-06-23 09:39:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29478
[Bug middle-end/32258] Testsuite reports - FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c
--- Comment #20 from rob1weld at aol dot com 2007-06-23 09:30 --- Created an attachment (id=13766) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13766&action=view) Patch main configure script to use mpfr 2.2.1, also detect mpfr library and header version mismatch - submitted to [EMAIL PROTECTED] -- rob1weld at aol dot com changed: What|Removed |Added Attachment #13702|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32258
[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700
--- Comment #5 from ubizjak at gmail dot com 2007-06-23 10:28 --- (In reply to comment #4) > The reduced testcase does not seem to work on i686-linux. However I > can reproduce the ICE with the original bit_allocate.i file. It crashes on x86_64 host when compiling with -O3 -m32. I didn't test it on i686: gcc -O3 -m32 pr32461.c pr32461.c: In function a52_bit_allocate: pr32461.c:9: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32461
[Bug rtl-optimization/31360] [4.2 Regression] RTL loop invariant is not aggressive enough
--- Comment #26 from rguenth at gcc dot gnu dot org 2007-06-23 10:23 --- I guess its hard to find a fix that does not regress elsewhere, so I'm inclined to WONTFIX this on the 4.2 branch. As it's still P1 this needs RM approval though. Mark? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, mmitchel at gcc dot gnu ||dot org Known to work||4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700
--- Comment #4 from spop at gcc dot gnu dot org 2007-06-23 10:21 --- The reduced testcase does not seem to work on i686-linux. However I can reproduce the ICE with the original bit_allocate.i file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32461
[Bug rtl-optimization/31360] [4.2 Regression] RTL loop invariant is not aggressive enough
--- Comment #25 from ebotcazou at gcc dot gnu dot org 2007-06-23 10:16 --- Any hope of having this fixed on the 4.2 branch too or should it be closed? -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Summary|[4.2 Regression] rtl loop |[4.2 Regression] RTL loop |invariant is broken |invariant is not aggressive ||enough http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
[Bug tree-optimization/31090] Revision 121302 causes 30% performance regression
--- Comment #15 from ubizjak at gmail dot com 2007-06-23 10:00 --- (In reply to comment #14) > Subject: Bug 31090 > > Author: dnovillo > Date: Wed Apr 11 17:14:06 2007 > New Revision: 123719 > HJ, what is the situation w.r.t performance regression after the above patch was committed to SVN? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31090
[Bug fortran/32464] [4.3 regression] ICE: USE in contained subroutine
--- Comment #9 from pault at gcc dot gnu dot org 2007-06-23 10:48 ---
This does the job:
Index: /svn/trunk/gcc/fortran/resolve.c
===
--- /svn/trunk/gcc/fortran/resolve.c(revision 125970)
+++ /svn/trunk/gcc/fortran/resolve.c(working copy)
@@ -3229,7 +3229,8 @@ check_host_association (gfc_expr *e)
return e->expr_type == EXPR_FUNCTION;
old_sym = e->symtree->n.sym;
- if (gfc_current_ns->parent
+ if (!old_sym->attr.use_assoc
+ && gfc_current_ns->parent
&& gfc_current_ns->parent->parent
&& old_sym->ns != gfc_current_ns)
{
and we probably need to exclude intrinsics, I suppose. I'll think about it.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2007-06-22 18:17:45 |2007-06-23 10:48:39
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32464
[Bug c++/32344] Exception handling crash in multi-threaded program
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Severity|major |normal GCC build triplet|sparc-sun-solaris2.10, |sparc-sun-solaris2.* |sparc-sun-solaris2.9, sparc-| |sun-solaris2. | GCC host triplet|sparc-sun-solaris2.10, |sparc-sun-solaris2.* |sparc-sun-solaris2.9, sparc-| |sun-solaris2. | GCC target triplet|sparc-sun-solaris2.10, |sparc-sun-solaris2.* |sparc-sun-solaris2.9, sparc-| |sun-solaris2. | Summary|Exception handling crash on |Exception handling crash in |multi-threaded Solaris/Sparc|multi-threaded program http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32344
[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700
--- Comment #6 from spop at gcc dot gnu dot org 2007-06-23 11:05 --- Subject: Re: [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700 Okay. The fail is because one of the folds is not a constant as expected: MINUS_EXPR (unsigned int) bndstart_108(D) (unsigned int) (bndstart_108(D) + 1) = 0x MINUS_EXPR (unsigned int) i_434 + 1 (unsigned int) i_434 = 1 but when reversed, MINUS_EXPR (unsigned int) i_434 (unsigned int) i_434 + 1 = ~(unsigned int) i_434 + (unsigned int) i_434 the fold result is not an integer_cst, and that lead to the fail. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32461
[Bug libstdc++/32284] empty std::string w/ _GLIBCXX_FULLY_DYNAMIC_STRING faults
--- Comment #3 from pcarlini at suse dot de 2007-06-23 11:32 --- Ok, let's close it... -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32284
[Bug testsuite/32471] New: Testcases which always fail on targets where an int is 16 bits
Starting with revision 122414, we have three testcases which will always fail on targets where an int is 16 bits wide: gcc.dg/torture/pr30364-1.c gcc.dg/torture/pr30364-2.c gcc.dg/torture/pr30364-3.c Additionally, they will test nothing on a target where an int is 64 bits wide. -- Summary: Testcases which always fail on targets where an int is 16 bits Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rask at sygehus dot dk GCC target triplet: m32c-unknown-elf avr-unknown-none h8300-unknown-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32471
[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field
--- Comment #18 from hubicka at gcc dot gnu dot org 2007-06-23 11:58 --- Subject: Bug 31541 Author: hubicka Date: Sat Jun 23 11:58:18 2007 New Revision: 125971 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125971 Log: PR middle-end/31541 * gimplify.c (mark_addressable): New function. (gimplify_modify_expr_rhs, gimplify_addr_expr, gimplify_expr): Use it. * gcc.c-torture/compile/pr31541.c: New. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr31541.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31541
[Bug fortran/32472] New: ICE in trans-const.c:106 for REPEAT initialization expression of non-parameter
r.f90:1: internal compiler error: in gfc_conv_string_init, at
fortran/trans-const.c:106
(4.3.0 20070623, x86_64-unknown-linux-gnu)
This is
gcc_assert (expr->expr_type == EXPR_CONSTANT);
Test case:
CHARACTER(len=1025) :: string2 = repeat('?',1025)
print *, string2
end
If one uses PARAMETER or a separate line (i.e. no initialization expression)
then it works.
--
Summary: ICE in trans-const.c:106 for REPEAT initialization
expression of non-parameter
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32472
[Bug fortran/31298] Uninitialized variable in f951 (in read_module) / renaming operator in USE
--- Comment #8 from burnus at gcc dot gnu dot org 2007-06-23 13:41 --- Issue which could be solved by the fix for this PR: PR 29876. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Summary|Uninitialized variable in |Uninitialized variable in |f951 (in read_module) |f951 (in read_module) / ||renaming operator in USE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31298
[Bug fortran/30792] DATA implied-do substring allowed with -std=f95/f2003
--- Comment #2 from burnus at gcc dot gnu dot org 2007-06-23 13:53 --- Also the following is not allowed: data (string,i=1,1)/'hello'/ or data (string,i=1,2)/'hello','foo'/ For the second, ifort -stand f95: Warning: Overlapping storage initializations encountered with STRING For both: - NAG f95: syntax error - g95: Error: DATA element inside iterator must be an array element or a scalar structure component -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30792
[Bug fortran/32472] ICE in trans-const.c:106 for REPEAT initialization expression of non-parameter
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-06-23 13:47 --- I think this is parsed as a statement function. For something similar, I once got messages as: expected character but got procedure. Couldn't find time to investigate further, though :( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32472
[Bug tree-optimization/30563] [4.3 Regression] ice for legal code with flags -O2 -fno-unit-at-a-time
--- Comment #12 from tbm at cyrius dot com 2007-06-23 12:37 --- No, I don't think anything else important shows this problem, except of the kernel and the Haskell stuff. Thanks for the patch! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30563
[Bug fortran/32136] ICE with transfer in gfc_conv_array_initializer
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-06-23 12:33 --- There is no ICE on i686-pc-linux-gnu (confirmed by gdb and valgrind). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32136
[Bug tree-optimization/30563] [4.3 Regression] ice for legal code with flags -O2 -fno-unit-at-a-time
--- Comment #11 from hubicka at ucw dot cz 2007-06-23 12:33 ---
Subject: Re: [4.3 Regression] ice for legal code with flags -O2
-fno-unit-at-a-time
> > I will check it tomorrow. However why users use -fno-unit-at-a-time at
> > all? Do you have some idea what packages, except for kernel, use it?
>
> Haskell
Hmm, I wonder why they need it:
[Use -fno-strict-aliasing for *all* C files in the runtime
Simon Marlow <[EMAIL PROTECTED]>**20060629082902
as a precautionary measure. It is definitely required for GC.c,
but it may well become necessary for other files in the future due to
our (mis-)use of the C "type system".
]
Are there any other packages or the "important portion" referred to
haskell?
Anyway, I am testing the attached fix, it was simple ordering problem
triggering hack checking analyzed flag someone added into tree-inline.
extern __inline double
strtod (void)
{
}
strtol (void)
{
return strtod ();
}
PR middle-end/30563
* cgraphunit.c (cgraph_analyze_function): Fix ordering problem.
Index: cgraphunit.c
===
--- cgraphunit.c(revision 125970)
+++ cgraphunit.c(working copy)
@@ -760,6 +760,7 @@ cgraph_analyze_function (struct cgraph_n
current_function_decl = decl;
push_cfun (DECL_STRUCT_FUNCTION (decl));
cgraph_lower_function (node);
+ node->analyzed = true;
if (!flag_unit_at_a_time)
{
@@ -771,7 +772,6 @@ cgraph_analyze_function (struct cgraph_n
bitmap_obstack_release (NULL);
}
- node->analyzed = true;
pop_cfun ();
current_function_decl = NULL;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30563
[Bug target/32437] [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
--- Comment #8 from zadeck at naturalbridge dot com 2007-06-23 15:55
---
Subject: Re: [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
This patch changes dce:deletable_insn_p so that it looks at all of the
top level
clauses in a parallel to make it's decision. It was not keeping insns
that had a top level USE or UNSPEC if they were inside of parallels.
This should fix pr32437 and perhaps other things.
The patch has only been tested on ppc and x86-64. It is harmless on
those platforms.
It is likely to make a difference on pa-risc and mips where there are
parallels that contain top level unspecs.
Ok to commit?
Kenny
2007-06-23 Kenneth Zadeck <[EMAIL PROTECTED]>
PR middle-end/32437
*dce.c (deletable_insn_p): Add extra parameter and recurse if insn
is a PARALLEL.
(prescan_insns_for_dce): Add extra parameter.
Index: dce.c
===
--- dce.c (revision 125971)
+++ dce.c (working copy)
@@ -58,15 +58,14 @@ static bitmap_obstack dce_tmp_bitmap_obs
static sbitmap marked = NULL;
-/* Return true if INSN a normal instruction that can be deleted by the
- DCE pass. */
+/* Return true if INSN with BODY is a normal instruction that can be
+ deleted by the DCE pass. */
static bool
-deletable_insn_p (rtx insn, bool fast)
+deletable_insn_p (rtx insn, rtx body, bool fast)
{
rtx x;
-
- switch (GET_CODE (PATTERN (insn)))
+ switch (GET_CODE (body))
{
case USE:
case PREFETCH:
@@ -86,7 +85,7 @@ deletable_insn_p (rtx insn, bool fast)
/* A CLOBBER of a dead pseudo register serves no purpose.
That is not necessarily true for hard registers until
after reload. */
- x = XEXP (PATTERN (insn), 0);
+ x = XEXP (body, 0);
return REG_P (x) && (!HARD_REGISTER_P (x) || reload_completed);
}
else
@@ -95,14 +94,23 @@ deletable_insn_p (rtx insn, bool fast)
never be the target of a use-def chain. */
return false;
+case PARALLEL:
+ {
+ int i;
+ for (i = XVECLEN (body, 0) - 1; i >= 0; i--)
+ if (!deletable_insn_p (insn, XVECEXP (body, 0, i), fast))
+ return false;
+ return true;
+ }
+
default:
if (!NONJUMP_INSN_P (insn))
return false;
- if (volatile_insn_p (PATTERN (insn)))
+ if (volatile_insn_p (body))
return false;
- if (flag_non_call_exceptions && may_trap_p (PATTERN (insn)))
+ if (flag_non_call_exceptions && may_trap_p (body))
return false;
return true;
@@ -361,7 +369,7 @@ prescan_insns_for_dce (bool fast)
rtx note = find_reg_note (insn, REG_LIBCALL_ID, NULL_RTX);
if (note)
mark_libcall (insn, fast);
-else if (deletable_insn_p (insn, fast))
+else if (deletable_insn_p (insn, PATTERN (insn), fast))
mark_nonreg_stores (PATTERN (insn), insn, fast);
else
mark_insn (insn, fast);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32437
[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field
--- Comment #20 from rguenther at suse dot de 2007-06-23 15:42 ---
Subject: Re: [4.3 Regression] cannot take address of
bit field
On Sat, 23 Jun 2007, malitzke at metronets dot com wrote:
> Question is it the policy of the gcc community to render all 32-bit machines
> obsolete for later versions of gcc-4.{3-9}.x? just like certain C constructs
> are first marked as disparaged and subsequently rendered unacceptable.
No, what get's you to this thought?
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31541
[Bug target/32437] [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
--- Comment #13 from daney at gcc dot gnu dot org 2007-06-23 16:47 --- Thanks for the patch. I just started a mipsel-linux bootstrap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32437
[Bug target/32437] [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
--- Comment #12 from zadeck at naturalbridge dot com 2007-06-23 16:23
---
Subject: Re: [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
Richard Guenther wrote:
> On 6/23/07, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
>> This patch changes dce:deletable_insn_p so that it looks at all of the
>> top level
>> clauses in a parallel to make it's decision. It was not keeping insns
>> that had a top level USE or UNSPEC if they were inside of parallels.
>>
>> This should fix pr32437 and perhaps other things.
>>
>> The patch has only been tested on ppc and x86-64. It is harmless on
>> those platforms.
>> It is likely to make a difference on pa-risc and mips where there are
>> parallels that contain top level unspecs.
>>
>> Ok to commit?
>
> This is ok for mainline.
>
> Thanks,
> Richard.
>
>>
>> 2007-06-23 Kenneth Zadeck <[EMAIL PROTECTED]>
>>
>> PR middle-end/32437
>> *dce.c (deletable_insn_p): Add extra parameter and recurse if insn
>> is a PARALLEL.
>> (prescan_insns_for_dce): Add extra parameter.
>>
>>
>>
>>
committed as revision 125972.
2007-06-23 Kenneth Zadeck <[EMAIL PROTECTED]>
PR middle-end/32437
*dce.c (deletable_insn_p): Add extra parameter and recurse if insn
is a PARALLEL.
(prescan_insns_for_dce): Add extra parameter.
Index: dce.c
===
--- dce.c (revision 125971)
+++ dce.c (working copy)
@@ -58,15 +58,14 @@ static bitmap_obstack dce_tmp_bitmap_obs
static sbitmap marked = NULL;
-/* Return true if INSN a normal instruction that can be deleted by the
- DCE pass. */
+/* Return true if INSN with BODY is a normal instruction that can be
+ deleted by the DCE pass. */
static bool
-deletable_insn_p (rtx insn, bool fast)
+deletable_insn_p (rtx insn, rtx body, bool fast)
{
rtx x;
-
- switch (GET_CODE (PATTERN (insn)))
+ switch (GET_CODE (body))
{
case USE:
case PREFETCH:
@@ -86,7 +85,7 @@ deletable_insn_p (rtx insn, bool fast)
/* A CLOBBER of a dead pseudo register serves no purpose.
That is not necessarily true for hard registers until
after reload. */
- x = XEXP (PATTERN (insn), 0);
+ x = XEXP (body, 0);
return REG_P (x) && (!HARD_REGISTER_P (x) || reload_completed);
}
else
@@ -95,14 +94,23 @@ deletable_insn_p (rtx insn, bool fast)
never be the target of a use-def chain. */
return false;
+case PARALLEL:
+ {
+ int i;
+ for (i = XVECLEN (body, 0) - 1; i >= 0; i--)
+ if (!deletable_insn_p (insn, XVECEXP (body, 0, i), fast))
+ return false;
+ return true;
+ }
+
default:
if (!NONJUMP_INSN_P (insn))
return false;
- if (volatile_insn_p (PATTERN (insn)))
+ if (volatile_insn_p (body))
return false;
- if (flag_non_call_exceptions && may_trap_p (PATTERN (insn)))
+ if (flag_non_call_exceptions && may_trap_p (body))
return false;
return true;
@@ -361,7 +369,7 @@ prescan_insns_for_dce (bool fast)
rtx note = find_reg_note (insn, REG_LIBCALL_ID, NULL_RTX);
if (note)
mark_libcall (insn, fast);
-else if (deletable_insn_p (insn, fast))
+else if (deletable_insn_p (insn, PATTERN (insn), fast))
mark_nonreg_stores (PATTERN (insn), insn, fast);
else
mark_insn (insn, fast);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32437
[Bug target/32437] [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
--- Comment #11 from zadeck at gcc dot gnu dot org 2007-06-23 16:21 --- Subject: Bug 32437 Author: zadeck Date: Sat Jun 23 16:21:43 2007 New Revision: 125972 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125972 Log: 2007-06-23 Kenneth Zadeck <[EMAIL PROTECTED]> PR middle-end/32437 *dce.c (deletable_insn_p): Add extra parameter and recurse if insn is a PARALLEL. (prescan_insns_for_dce): Add extra parameter. Modified: trunk/gcc/ChangeLog trunk/gcc/dce.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32437
[Bug fortran/29962] Initialization expressions checking in gfc_intrinsic_func_interface
--- Comment #7 from burnus at gcc dot gnu dot org 2007-06-23 16:13 --- TRANSFER is rejected at initialization expression (w/ -std=f95 & f2003) but it is allowed per 7.1.6.1 Constant expression / initialization expression (F95 standard): "(5) A reference to one of the transformational functions REPEAT, RESHAPE, SELECTED_INT_KIND, SELECTED_REAL_KIND, TRANSFER, or TRIM, where each argument is an initialization expression," gfortran -std=f95 rejects it with: Evaluation of nonstandard initialization expression -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962
[Bug target/32437] [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
--- Comment #10 from richard dot guenther at gmail dot com 2007-06-23 16:12 --- Subject: Re: [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c On 6/23/07, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: > This patch changes dce:deletable_insn_p so that it looks at all of the > top level > clauses in a parallel to make it's decision. It was not keeping insns > that had a top level USE or UNSPEC if they were inside of parallels. > > This should fix pr32437 and perhaps other things. > > The patch has only been tested on ppc and x86-64. It is harmless on > those platforms. > It is likely to make a difference on pa-risc and mips where there are > parallels that contain top level unspecs. > > Ok to commit? This is ok for mainline. Thanks, Richard. > > 2007-06-23 Kenneth Zadeck <[EMAIL PROTECTED]> > > PR middle-end/32437 > *dce.c (deletable_insn_p): Add extra parameter and recurse if insn > is a PARALLEL. > (prescan_insns_for_dce): Add extra parameter. > > > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32437
[Bug fortran/32460] structure constructor not allowed if a USEd type has private components
--- Comment #2 from patchapp at dberlin dot org 2007-06-23 16:10 --- Subject: Bug number PR 32460 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01702.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32460
[Bug target/32437] [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
--- Comment #9 from paolo dot bonzini at lu dot unisi dot ch 2007-06-23 16:03 --- Subject: Re: [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c Kenneth Zadeck wrote: > This patch changes dce:deletable_insn_p so that it looks at all of the > top level > clauses in a parallel to make it's decision. It was not keeping insns > that had a top level USE or UNSPEC if they were inside of parallels. > > This should fix pr32437 and perhaps other things. > > The patch has only been tested on ppc and x86-64. It is harmless on > those platforms. > It is likely to make a difference on pa-risc and mips where there are > parallels that contain top level unspecs. > > Ok to commit? ok -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32437
[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field
--- Comment #21 from rguenth at gcc dot gnu dot org 2007-06-23 15:59 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31541
[Bug fortran/32460] structure constructor not allowed if a USEd type has private components
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-23 14:55 --- Mine. Note that type :: bar integer, private :: x end type has the same problem, esp. "b%x = 5" is also possible. -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-23 14:55:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32460
[Bug tree-optimization/31090] Revision 121302 causes 30% performance regression
--- Comment #16 from hjl at lucon dot org 2007-06-23 14:46 --- > HJ, what is the situation w.r.t performance regression after the above patch > was committed to SVN? > I think it still needs tuning. I got the following on Linux/Intel64: (r125740 - r121297)/r121297 410.bwaves -0.869565% 416.gamess -0.574713% 433.milc -0.840336% 434.zeusmp 3.37838% 435.gromacs -0.214823% 436.cactusADM-0.917431% 437.leslie3d -11.9048% 444.namd -0.671141% 447.dealII -2.33463% 450.soplex -0.675676% 453.povray 2.51256% 454.calculix 25.8675% 459.GemsFDTD 0% 465.tonto2.14286% 470.lbm -2.75862% 481.wrf 5.94059% 482.sphinx3 0.510204% SPECfp_base2006 0.757576% -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31090
[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88
--- Comment #2 from eweddington at cso dot atmel dot com 2007-06-23 15:39 --- Works for me with gcc 4.2.0 and binutils 2.17. Andreas, what version of binutils are you using? -- eweddington at cso dot atmel dot com changed: What|Removed |Added Known to work||4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30417
[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field
--- Comment #19 from malitzke at metronets dot com 2007-06-23 15:39 ---
Thank you Mr Hubicka for solving this. I had earlier used your patch from
comment 16 but i had to apply it by hand as my patch-2.5.9 (Larry Wall) would
take that published patch even after html2text; changing --- gimplify.c to
gimplify.c.old; deleting all text after the second @@. Maybe what is published
on bugzilla is no intended for outsiders like myself and works only with CVS,
subversion. However, doing it by hand enabled me to compile cdrutils
(Schilling) and erase an CD-RW.
Could you or somebody else clarify what patch program to use or state that
original reporters of PR's should refrain from using the posted patches.
Now to comments 7, 10, 11, 13, 15 the vital difference is that _dcb_ and
apparently Mr Guenther used a 64-bit machine while I am using a 32-bit.
Question is it the policy of the gcc community to render all 32-bit machines
obsolete for later versions of gcc-4.{3-9}.x? just like certain C constructs
are first marked as disparaged and subsequently rendered unacceptable.
I believe that the requested clarification should be made available to users at
large. Thanks again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31541
[Bug middle-end/29478] [4.2 Regression] optmization generates warning for casts
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-06-23 18:18 --- Fixed on the mainline. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.1.1 4.1.2 |4.1.1 4.1.2 4.3.0 Summary|[4.2/4.3 Regression]|[4.2 Regression] optmization |optmization generates |generates warning for casts |warning for casts | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29478
[Bug middle-end/29478] [4.2/4.3 Regression] optmization generates warning for casts
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-06-23 18:18 --- Subject: Bug 29478 Author: rguenth Date: Sat Jun 23 18:17:57 2007 New Revision: 125974 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125974 Log: 2007-06-23 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/16876 PR middle-end/29478 * tree.h (CALL_CANNOT_INLINE_P): New macro to access static_flag for CALL_EXPRs. * tree-inline.c (initialize_inlined_parameters): Do not call lang_hooks.tree_inlining.convert_parm_for_inlining. * cgraphbuild.c (initialize_inline_failed): Set inline failed reason for mismatched types. * gimplify.c (gimplify_call_expr): Verify the call expression arguments match the called function type signature. Otherwise mark the call expression to be not considered for inlining using CALL_CANNOT_INLINE_P flag. * ipa-inline.c (cgraph_mark_inline): Honor CALL_CANNOT_INLINE_P on the edges call expression. (cgraph_decide_inlining_of_small_function): Likewise. (cgraph_decide_inlining): Likewise. * c-objc-common.h (LANG_HOOKS_TREE_INLINING_CONVERT_PARM_FOR_INLINING): Remove define. * c-tree.h (c_convert_parm_for_inlining): Remove declaration. * c-typeck.c (c_convert_parm_for_inlining): Remove. * langhooks-def.h (lhd_tree_inlining_convert_parm_for_inlining): Remove declaration. (LANG_HOOKS_TREE_INLINING_CONVERT_PARM_FOR_INLINING): Remove define. * langhooks.c (lhd_tree_inlining_convert_parm_for_inlining): Remove. * langhooks.h (struct lang_hooks_for_tree_inlining): Remove convert_parm_for_inlining member. * gcc.dg/pr29254.c: The warning is bogus. * gcc.dg/warn-1.c: Likewise. * gcc.dg/assign-warn-3.c: Likewise. * gcc.dg/noncompile/pr16876.c: The testcase is bogus, remove. Removed: trunk/gcc/testsuite/gcc.dg/noncompile/pr16876.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-objc-common.h trunk/gcc/c-tree.h trunk/gcc/c-typeck.c trunk/gcc/cgraphbuild.c trunk/gcc/gimplify.c trunk/gcc/ipa-inline.c trunk/gcc/langhooks-def.h trunk/gcc/langhooks.c trunk/gcc/langhooks.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/assign-warn-3.c trunk/gcc/testsuite/gcc.dg/pr29254.c trunk/gcc/testsuite/gcc.dg/warn-1.c trunk/gcc/tree-inline.c trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29478
[Bug c/32448] [3.3 / 3.4 / 4.1 / 4.2 / 4.3 Regression] abs / printf bug
--- Comment #14 from kargl at gcc dot gnu dot org 2007-06-23 17:56 --- (In reply to comment #13) > (In reply to comment #11) > > (1) Try -Wformat > > "-Wall" includes "-Wformat" according to gcc.info. See comment 7 for the > command line I used: > /* /usr/test/bin/gcc -Wall -Wconversion -o math_test_7 math_test_7.c */ mobile:kargl[204] cc -o z -Wformat m.c -lm m.c: In function 'main': m.c:21: warning: format '%d' expects type 'int', but argument 2 has type 'double' m.c:21: warning: format '%d' expects type 'int', but argument 3 has type 'double' m.c:21: warning: format '%d' expects type 'int', but argument 4 has type 'double' m.c:21: warning: format '%d' expects type 'int', but argument 5 has type 'double' m.c:21: warning: format '%d' expects type 'int', but argument 6 has type 'double' m.c:22: warning: format '%d' expects type 'int', but argument 2 has type 'double' m.c:22: warning: format '%d' expects type 'int', but argument 3 has type 'double' m.c:22: warning: format '%d' expects type 'int', but argument 4 has type 'double' m.c:22: warning: format '%d' expects type 'int', but argument 5 has type 'double' m.c:22: warning: format '%d' expects type 'int', but argument 6 has type 'double' mobile:kargl[205] cc -o z -Wall m.c -lm m.c: In function 'main': m.c:9: warning: implicit declaration of function 'abs' m.c:21: warning: format '%d' expects type 'int', but argument 2 has type 'double' m.c:21: warning: format '%d' expects type 'int', but argument 3 has type 'double' m.c:21: warning: format '%d' expects type 'int', but argument 4 has type 'double' m.c:21: warning: format '%d' expects type 'int', but argument 5 has type 'double' m.c:21: warning: format '%d' expects type 'int', but argument 6 has type 'double' m.c:22: warning: format '%d' expects type 'int', but argument 2 has type 'double' m.c:22: warning: format '%d' expects type 'int', but argument 3 has type 'double' m.c:22: warning: format '%d' expects type 'int', but argument 4 has type 'double' m.c:22: warning: format '%d' expects type 'int', but argument 5 has type 'double' m.c:22: warning: format '%d' expects type 'int', but argument 6 has type 'double' m.c is your code in comment #7 > > > > (3) There is an expectation someone writing C might actually > > adhere to the Standard > > From time to time that does not always occur. See here: >http://gcc.gnu.org/bugzilla/buglist.cgi?emailreporter1=1&emailtype1=substring&[EMAIL > PROTECTED] I'm not sure what you're trying to demonstate. Bug reports associated with me are related to Fortran not C. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32448
[Bug target/31152] -(x>y) generates wrong code
--- Comment #6 from rearnsha at gcc dot gnu dot org 2007-06-23 18:11 --- Fixed on trunk. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31152
[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700
--- Comment #7 from spop at gcc dot gnu dot org 2007-06-23 18:10 --- Subject: Re: [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700 Hi, In data dependence analysis, when the dependence distance is lexicographically negative, we recompute the dependence by inverting the source and the sink memory accesses, and thus we compute the dependence again but in the opposite direction. In one way we compute: MINUS_EXPR (unsigned int) i_434 + 1 (unsigned int) i_434 = 1 but when going the other way, backwards, we have to compute: MINUS_EXPR (unsigned int) i_434 (unsigned int) i_434 + 1 = ~(unsigned int) i_434 + (unsigned int) i_434 and instead of getting an integer_cst, we get that ugly expression from fold, the dependence test fails, and everything goes wrong from that point. With this patch we get the expected 0x for the above case. The patch teaches fold how to compute the minus expression for unsigned int and pointer expressions. Bootstrapped and tested on i686-linux. Okay for trunk? Sebastian --- Comment #8 from spop at gcc dot gnu dot org 2007-06-23 18:10 --- Created an attachment (id=13768) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13768&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32461
[Bug target/31152] -(x>y) generates wrong code
--- Comment #5 from rearnsha at gcc dot gnu dot org 2007-06-23 18:07 --- Subject: Bug 31152 Author: rearnsha Date: Sat Jun 23 18:07:04 2007 New Revision: 125973 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125973 Log: PR target/31152 * arm.md (negscc): Match the correct operand for optimized LT0 test. Remove optimization for GT. *gcc.c-torture/execute/20070623-1.c: New. Added: trunk/gcc/testsuite/gcc.c-torture/execute/20070623-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31152
[Bug tree-optimization/16876] [4.0/4.1 Regression] ICE on testcase with -O3 in fold-const
--- Comment #19 from rguenth at gcc dot gnu dot org 2007-06-23 18:18 --- Subject: Bug 16876 Author: rguenth Date: Sat Jun 23 18:17:57 2007 New Revision: 125974 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125974 Log: 2007-06-23 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/16876 PR middle-end/29478 * tree.h (CALL_CANNOT_INLINE_P): New macro to access static_flag for CALL_EXPRs. * tree-inline.c (initialize_inlined_parameters): Do not call lang_hooks.tree_inlining.convert_parm_for_inlining. * cgraphbuild.c (initialize_inline_failed): Set inline failed reason for mismatched types. * gimplify.c (gimplify_call_expr): Verify the call expression arguments match the called function type signature. Otherwise mark the call expression to be not considered for inlining using CALL_CANNOT_INLINE_P flag. * ipa-inline.c (cgraph_mark_inline): Honor CALL_CANNOT_INLINE_P on the edges call expression. (cgraph_decide_inlining_of_small_function): Likewise. (cgraph_decide_inlining): Likewise. * c-objc-common.h (LANG_HOOKS_TREE_INLINING_CONVERT_PARM_FOR_INLINING): Remove define. * c-tree.h (c_convert_parm_for_inlining): Remove declaration. * c-typeck.c (c_convert_parm_for_inlining): Remove. * langhooks-def.h (lhd_tree_inlining_convert_parm_for_inlining): Remove declaration. (LANG_HOOKS_TREE_INLINING_CONVERT_PARM_FOR_INLINING): Remove define. * langhooks.c (lhd_tree_inlining_convert_parm_for_inlining): Remove. * langhooks.h (struct lang_hooks_for_tree_inlining): Remove convert_parm_for_inlining member. * gcc.dg/pr29254.c: The warning is bogus. * gcc.dg/warn-1.c: Likewise. * gcc.dg/assign-warn-3.c: Likewise. * gcc.dg/noncompile/pr16876.c: The testcase is bogus, remove. Removed: trunk/gcc/testsuite/gcc.dg/noncompile/pr16876.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-objc-common.h trunk/gcc/c-tree.h trunk/gcc/c-typeck.c trunk/gcc/cgraphbuild.c trunk/gcc/gimplify.c trunk/gcc/ipa-inline.c trunk/gcc/langhooks-def.h trunk/gcc/langhooks.c trunk/gcc/langhooks.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/assign-warn-3.c trunk/gcc/testsuite/gcc.dg/pr29254.c trunk/gcc/testsuite/gcc.dg/warn-1.c trunk/gcc/tree-inline.c trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16876
[Bug target/32437] [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
--- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-23 18:40 --- Subject: Re: [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c > Thanks for the patch. I just started a mipsel-linux bootstrap. Same here for hppa-linux. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32437
[Bug target/31152] -(x>y) generates wrong code
--- Comment #7 from tbm at cyrius dot com 2007-06-23 19:07 --- Are you not going to apply this to 4.1 and 4.2? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31152
[Bug target/31152] -(x>y) generates wrong code
--- Comment #8 from tbm at cyrius dot com 2007-06-23 19:07 --- Richard, I think this patch should also be added to the 4.1 and 4.2 branches. -- tbm at cyrius dot com changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31152
[Bug bootstrap/32474] New: struct timeval collision in include files for MinGW cross compile
When building for target i686-pc-mingw32 on host (Debian) i686-pc-linux-gnu
I find the file /opt/build/gcc-4.1.2/libiberty/pex-win32.c uses both
#include "pex-common.h" and "#include " thus we get this:
In file included from
/opt/mingw32/i686-pc-mingw32/sys-include/bits/resource.h:151,
from
/opt/mingw32/i686-pc-mingw32/sys-include/sys/resource.h:26,
from /opt/mingw32/i686-pc-mingw32/sys-include/sys/wait.h:32,
from /opt/build/gcc-4.1.2/libiberty/pex-win32.c:37:
/opt/mingw32/i686-pc-mingw32/sys-include/bits/time.h:70: error: redefinition of
'struct timeval'
Creating an ".i" file I see this:
# 181 "/opt/build/gcc-4.1.2/libiberty/../include/libiberty.h"
/* Get the current time. */
/* Prototypes vary from system to system, so we only provide a
prototype on systems where we know that we need it. */
#ifdef __MINGW32__
/* Forward declaration to avoid #include . */
struct timeval;
extern int gettimeofday (struct timeval *, void *);
#endif
# 109 "/opt/mingw32/i686-pc-mingw32/include/winsock2.h" 3
struct timeval {
long tv_sec;
long tv_usec;
};
# 69 "/opt/mingw32/i686-pc-mingw32/sys-include/bits/time.h"
struct timeval
{
__time_t tv_sec;
__suseconds_t tv_usec;
};
The file "sys/resource.h" includes "bits/resource.h", which then includes
"bits/time.h" _directly_.
The file "sys/time.h" has an ifdef system like this:
#ifndef _TIMEVAL_DEFINED /* also in winsock[2].h */
#define _TIMEVAL_DEFINED
struct timeval {
long tv_sec;
long tv_usec;
};
...
#endif /* _TIMEVAL_DEFINED */
The file "bits/time.h" has an ifdef system like this:
/* Never include this file directly; use instead. */
#ifdef __need_timeval
# undef __need_timeval
# ifndef _STRUCT_TIMEVAL
# define _STRUCT_TIMEVAL
# include
/* A time value that is accurate to the nearest
microsecond but also has a range of years. */
struct timeval
{
__time_t tv_sec;/* Seconds. */
__suseconds_t tv_usec; /* Microseconds. */
};
# endif /* struct timeval */
#endif /* need timeval */
Since we are compiling for --target=i686-pc-mingw32 I imagine we prefer the
winsock2.h version of struct timeval.
To achieve that do this:
/opt/build/gcc-4.1.2/libiberty/pex-win32.c
- OLD
#include "pex-common.h"
#include
#ifdef HAVE_STDLIB_H
-
- NEW
#include "pex-common.h"
#include
#ifdef __MINGW32__ /* avoid redefinition of 'struct timeval' */
#define _STRUCT_TIMEVAL
#endif
#ifdef HAVE_STDLIB_H
-
Alternately we could do this:
/opt/build/gcc-4.1.2/include/libiberty.h
- OLD
/* Get the current time. */
/* Prototypes vary from system to system, so we only provide a
prototype on systems where we know that we need it. */
#ifdef __MINGW32__
/* Forward declaration to avoid #include . */
struct timeval;
extern int gettimeofday (struct timeval *, void *);
#endif
-
- NEW
/* Get the current time. */
/* Prototypes vary from system to system, so we only provide a
prototype on systems where we know that we need it. */
#ifdef __MINGW32__
/* Forward declaration to avoid #include . */
struct timeval;
extern int gettimeofday (struct timeval *, void *);
#define _STRUCT_TIMEVAL /* use winsock2.h timeval structure instead of
bits/time.h version */
#endif
-
Which do the maintainers prefer ? Either way pex-win32.c compiles without
error.
I chose to modify /opt/build/gcc-4.1.2/include/libiberty.h for _my_ build since
there was already a "#ifdef __MINGW32__" in that file.
I don't know that "sys/resource.h" which includes "bits/resource.h" should
include "bits/time.h" _directly_.
I don't know why the "bits/time.h" says this: "/* Never include this file
directly; use instead. */" since "time.h" does not include
"bits/time.h" - so "bits/resource.h" needs to if it wants bits/time.h.
The files "bits/resource.h" and "sys/select.h" are the only ones that include
"bits/time.h", that may not be GCC's fault but I am using GNU/Linux.
# grep -r bits\/time.h /opt/mingw32/i686-pc-mingw32/sys-include/*
/opt/mingw32/i686-pc-mingw32/sys-include/bits/resource.h:#include
/* For `struct timeval'. */
Binary file
/opt/mingw32/i686-pc-mingw32/sys-include/c++/4.2/bits/stdc++.h.gch/O0g.gch
matches
Binary file
/opt/mingw32/i686-pc-mingw32/sys-include/c++/4.2/bits/stdc++.h.gch/O2g.gch
matches
Binary file
/opt/mingw32/i686-pc-mingw32/sys-include/c++/4.2/bits/stdtr1c++.h.gch/O2g.gch
matches
/opt/mingw32/i686-pc-mingw32/sys-include/sys/select.h:#include
If it is agreed that this is a bug then you will want to update
http://ftp.gnu.org/gnu/gcc/gcc-4.1.2/gcc-core-4.1.2.tar.bz2
--
Summary: struct timeval collision in include files for MinGW
cross compile
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1we
[Bug bootstrap/32474] struct timeval collision in include files for MinGW cross compile
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-23 19:26 --- This looks more like a mingw header problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32474
[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700
--- Comment #10 from richard dot guenther at gmail dot com 2007-06-23 19:24 --- Subject: Re: [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700 On 6/23/07, Richard Guenther <[EMAIL PROTECTED]> wrote: > On 6/23/07, Sebastian Pop <[EMAIL PROTECTED]> wrote: > > Hi, > > > > In data dependence analysis, when the dependence distance is > > lexicographically negative, we recompute the dependence by inverting > > the source and the sink memory accesses, and thus we compute the > > dependence again but in the opposite direction. In one way we > > compute: > > > > MINUS_EXPR > > (unsigned int) i_434 + 1 > > (unsigned int) i_434 > > = > > 1 > > > > but when going the other way, backwards, we have to compute: > > > > MINUS_EXPR > > (unsigned int) i_434 > > (unsigned int) i_434 + 1 > > = > > ~(unsigned int) i_434 + (unsigned int) i_434 > > > > and instead of getting an integer_cst, we get that ugly expression > > from fold, the dependence test fails, and everything goes wrong from > > that point. > > > > With this patch we get the expected 0x for the above > > case. The patch teaches fold how to compute the minus expression for > > unsigned int and pointer expressions. > > > > Bootstrapped and tested on i686-linux. Okay for trunk? > > First - can you check why the asociate: case in fold_binary does not do > the transformation and maybe fix that instead if possible? > > Then there is a ChangeLog missing. Further... > > + && integer_zerop (fold_build2 (MINUS_EXPR, type, arg0, > +TREE_OPERAND (arg1, 0 > > to avoid creating trees and just throwing them away you should use > operand_equal_p (arg0, TREE_OPERAND (arg1, 0)) instead. You > similarly may want to check operand 1 for A - (B + A)? > > + && TYPE_UNSIGNED (type) > > you should check TYPE_OVERFLOW_WRAPS (type) instead. Oh - and there is omit_two_operands which you should use to omit the two As. This takes care of side-effects. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32461
[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700
--- Comment #9 from richard dot guenther at gmail dot com 2007-06-23 18:36 --- Subject: Re: [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700 On 6/23/07, Sebastian Pop <[EMAIL PROTECTED]> wrote: > Hi, > > In data dependence analysis, when the dependence distance is > lexicographically negative, we recompute the dependence by inverting > the source and the sink memory accesses, and thus we compute the > dependence again but in the opposite direction. In one way we > compute: > > MINUS_EXPR > (unsigned int) i_434 + 1 > (unsigned int) i_434 > = > 1 > > but when going the other way, backwards, we have to compute: > > MINUS_EXPR > (unsigned int) i_434 > (unsigned int) i_434 + 1 > = > ~(unsigned int) i_434 + (unsigned int) i_434 > > and instead of getting an integer_cst, we get that ugly expression > from fold, the dependence test fails, and everything goes wrong from > that point. > > With this patch we get the expected 0x for the above > case. The patch teaches fold how to compute the minus expression for > unsigned int and pointer expressions. > > Bootstrapped and tested on i686-linux. Okay for trunk? First - can you check why the asociate: case in fold_binary does not do the transformation and maybe fix that instead if possible? Then there is a ChangeLog missing. Further... + && integer_zerop (fold_build2 (MINUS_EXPR, type, arg0, +TREE_OPERAND (arg1, 0 to avoid creating trees and just throwing them away you should use operand_equal_p (arg0, TREE_OPERAND (arg1, 0)) instead. You similarly may want to check operand 1 for A - (B + A)? + && TYPE_UNSIGNED (type) you should check TYPE_OVERFLOW_WRAPS (type) instead. Thanks, Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32461
[Bug bootstrap/32473] New: fopen_unlocked.c missing include file for MinGW cross compile
gcc version 4.1.2 from http://ftp.gnu.org/gnu/gcc/gcc-4.1.2/gcc-core-4.1.2.tar.bz2 when compiled with --target=i686-pc-mingw32 on host i686-pc-linux-gnu has trouble when it compiles /gcc-4.1.2/libiberty/fopen_unlocked.c under certain conditions. Here is where the error occurs: /opt/build/gcc-i686-pc-mingw32/./gcc/xgcc -B/opt/build/gcc-i686-pc-mingw32/./gcc/ -B/opt/mingw32/i686-pc-mingw32/bin/ -B/opt/mingw32/i686-pc-mingw32/lib/ -isystem /opt/mingw32/i686-pc-mingw32/include -isystem /opt/mingw32/i686-pc-mingw32/sys-include -c -DHAVE_CONFIG_H -O2 -g -O2 -I. -I/opt/build/gcc-4.1.2/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes /opt/build/gcc-4.1.2/libiberty/fopen_unlocked.c -o fopen_unlocked.o In file included from /opt/build/gcc-4.1.2/libiberty/fopen_unlocked.c:73: /opt/mingw32/i686-pc-mingw32/sys-include/stdio_ext.h:47: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'extern' /opt/mingw32/i686-pc-mingw32/sys-include/stdio_ext.h: In function '__freading': /opt/mingw32/i686-pc-mingw32/sys-include/stdio_ext.h:52: error: expected declaration specifiers before '__THROW' /opt/mingw32/i686-pc-mingw32/sys-include/stdio_ext.h:57: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__THROW' ... This problems is caused by these lines in fopen_unlocked.c: - #ifdef HAVE_CONFIG_H #include "config.h" #endif #include #ifdef HAVE_STDIO_EXT_H #include #endif #include "libiberty.h" - They need to be: - #ifdef HAVE_CONFIG_H #include "config.h" #endif #include #ifdef HAVE_STDIO_EXT_H #include /* Added - need sys/cdefs.h (or features.h) before stdio_ext.h - for *_DECLS */ #include #endif #include "libiberty.h" - Lines 43 and 85 of /opt/mingw32/i686-pc-mingw32/sys-include/stdio_ext.h (which is placed there with the fixincludes code) have __BEGIN_DECLS and __END_DECLS but looking at the -save-temps ".i" file they are not defined prior. The file /usr/include/sys/cdefs.h is where "__BEGIN_DECLS" and "__END_DECLS" is defined. File "cdefs.h" does mention that it could be included by way of features.h but that is unneccesary. Anytime we use "#include " we must first use "#include " on host Debian GNU/Linux version 2.6.17 --target=i686-pc-mingw32 cross-compiled from i686-pc-linux-gnu. # /lib/libc.so.6 GNU C Library stable release version 2.6, by Roland McGrath et al. # /opt/build/gcc-i686-pc-mingw32/gcc/xgcc -v Using built-in specs. Target: i686-pc-mingw32 Configured with: /opt/colinux/build/gcc-4.1.2/configure -v --prefix=/opt/colinux/mingw32 --target=i686-pc-mingw32 --with-headers=/opt/colinux/mingw32/i686-pc-mingw32/include --with-gnu-as --with-gnu-ld --disable-nls --without-newlib --disable-multilib --enable-languages=c,c++ Thread model: win32 gcc version 4.1.2 If it is agreed that this is a bug then you will want to update http://ftp.gnu.org/gnu/gcc/gcc-4.1.2/gcc-core-4.1.2.tar.bz2 -- Summary: fopen_unlocked.c missing include file for MinGW cross compile Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32473
[Bug c++/31923] g++ accepts a storage-class-specifier on a template explicit specialization
--- Comment #4 from mmitchel at gcc dot gnu dot org 2007-06-23 19:52 --- As this patch has been checked in, can this PR be closed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31923
[Bug bootstrap/32473] fopen_unlocked.c missing include file for MinGW cross compile
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-23 19:49 --- /opt/mingw32/i686-pc-mingw32/sys-include/stdio_ext.h:47: error: expected '=', That is a bug in mingw header files and not in GCC, report this bug to mingw instead of here. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32473
[Bug c/32448] [3.3 / 3.4 / 4.1 / 4.2 / 4.3 Regression] abs / printf bug
--- Comment #16 from ubizjak at gmail dot com 2007-06-23 19:41 --- (In reply to comment #14) > m.c: In function 'main': > m.c:9: warning: implicit declaration of function 'abs' Also, add a prototype for integer abs(), like "int abs(int);". Then everything will work as "expected". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32448
[Bug bootstrap/32474] struct timeval collision in include files for MinGW cross compile
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-23 19:48 --- # 109 "/opt/mingw32/i686-pc-mingw32/include/winsock2.h" 3 # 69 "/opt/mingw32/i686-pc-mingw32/sys-include/bits/time.h" These two headers don't come from GCC at all so closing as invalid. Please report this bug to mingw instead. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32474
[Bug c/32448] [3.3 / 3.4 / 4.1 / 4.2 / 4.3 Regression] abs / printf bug
--- Comment #15 from rob1weld at aol dot com 2007-06-23 18:49 ---
>Andrew Pinski
>abs converts the float/double to an integer type so this is not a bug.
>Uros Bizjak
>The non-problem you are going after is in printf(). It takes variable arguments
>from the stack and interprets them according to the format string. Argument are
>pushed to the stack by the caller without any other communication with callee,
>so it is obvious that format string _must_ reflect the type of values on stack.
>Also note, that %f inherently converts float type to double, so your values on
>the stack are FUBAR as far as printf is concerned.
So what we end up with is something like this:
main(){
printf("%f %f %f %f\n", abs(1234.5678), fabs(1234.5678),
abs((int)1234.5678), abs((int)(1234.5678)));
}
and here is the incorrect output:
639356954161190327651780598819979664641251888147947213308332781758079574424033219293612810237966089410023577192498425554519097800758249636139201808050627475876578945300496861358730667076856621948936720606078976728760320.00
0.00 -0.007810 -0.00
The first and third values are obviously wrong.
The second and fourth values agree - so (in theory) that is the "correct"
answer - according to the way that GCC is intended to operate (as per what
Andrew says).
If the "correct" answer is zero (without concerning ourselves if it is plus
zero or minus zero) then why are the _third_ and _fourth_ answer different!
abs((int)1234.5678) = -0.007810
abs((int)(1234.5678)) = -0.00
Should the cast work without the extra parentheses.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32448
[Bug c/32448] [3.3 / 3.4 / 4.1 / 4.2 / 4.3 Regression] abs / printf bug
--- Comment #17 from ubizjak at gmail dot com 2007-06-23 19:51 ---
(In reply to comment #15)
> and here is the incorrect output:
Here is the correct input:
--cut here--
#include
int abs(int);
double fabs(double);
int main()
{
printf("%i %f %i %i\n", abs(1234.5678), fabs(1234.5678),
abs((int)1234.5678), abs((int)(1234.5678)));
return 0;
}
--cut here--
OK, have fun, I'll stop wasting electrons here...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32448
[Bug c++/29077] Incorrect error message for destructor in wrong namespace
--- Comment #5 from mmitchel at gcc dot gnu dot org 2007-06-23 20:15 --- Can this issue be closed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29077
[Bug rtl-optimization/31360] [4.2 Regression] RTL loop invariant is not aggressive enough
--- Comment #27 from mmitchel at gcc dot gnu dot org 2007-06-23 20:45 --- Richard G., by: "I guess its hard to find a fix that does not regress elsewhere, so I'm inclined to WONTFIX this on the 4.2 branch." are you referring to functional problems or to Richard E's comments regarding code size? The followup PR 31676 patch looks very small; couldn't we backport this patch plus that one to 4.2, if we wanted to do so? As for the code size regression, Richard E., have you had a chance to identify a specific CSiBE file that expands, so that Zdenek can look at that? Meanwhile, I would prefer to leave this regression open. I really do feel that it's a severe optimization regression. After all, this is basically a variant on bzero. Thanks, -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
[Bug bootstrap/32474] struct timeval collision in include files for MinGW cross compile
--- Comment #3 from rob1weld at aol dot com 2007-06-23 21:04 --- OK. I thought since GCC had a number of "#ifdef __MINGW32__" lines in it's source that the fixes were done on GCC to accommodate the OS (especially on a cross-compile) in preference to altering system header files to work for GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32474
[Bug bootstrap/32473] fopen_unlocked.c missing include file for MinGW cross compile
--- Comment #2 from rob1weld at aol dot com 2007-06-23 21:05 --- OK. I thought since GCC had a number of "#ifdef __MINGW32__" lines in it's source that the fixes were done on GCC to accommodate the OS (especially on a cross-compile) in preference to altering system header files to work for GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32473
[Bug c/32475] New: function with asm() does not setup stack frame
the following function does not setup a stackframe. It is only visible in the generated assembler code. good: 0: 55 push %ebp 1: 89 e5 mov%esp,%ebp 3: 83 ec 10sub$0x10,%esp 6: 8b 45 08mov0x8(%ebp),%eax 9: 8d 55 fclea0xfffc(%ebp),%edx ... currently: 0: 55 push %ebp 1: 89 e5 mov%esp,%ebp 3: 8b 45 08mov0x8(%ebp),%eax 6: 8d 55 fclea0xfffc(%ebp),%edx 9: 89 45 fcmov%eax,0xfffc(%ebp) ... Note the lack of the sub $0x10,$esp This seems to have been caused by the dataflow merge, my regression hunt against TRUNK is currently between 125600 and 125612. -- Summary: function with asm() does not setup stack frame Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: marcus at jet dot franken dot de GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32475
[Bug c/32475] function with asm() does not setup stack frame
--- Comment #1 from marcus at jet dot franken dot de 2007-06-23 21:12 --- Created an attachment (id=13769) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13769&action=view) preloader.i gcc -O2 -c preloader.i (on i*86), then disassemble. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32475
[Bug fortran/32472] ICE in trans-const.c:106 for REPEAT initialization expression of non-parameter
--- Comment #2 from pault at gcc dot gnu dot org 2007-06-23 21:13 --- (In reply to comment #1) It's wierd - this works fine: Character(1), parameter :: query = "?" CHARACTER(len=1025) :: string2 = repeat(query,1025) print *, string2 end Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32472
[Bug rtl-optimization/32475] [4.3 Regression] function with asm() does not setup stack frame
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, spark at gcc dot gnu ||dot org Component|c |rtl-optimization Keywords||wrong-code Summary|function with asm() does not|[4.3 Regression] function |setup stack frame |with asm() does not setup ||stack frame Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32475
[Bug rtl-optimization/32475] [4.3 Regression] function with asm() does not setup stack frame
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-23 22:31 --- The target might have forgot a barrior. the RTL is correct after pro_epilogue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32475
[Bug rtl-optimization/32475] [4.3 Regression] function with asm() does not setup stack frame
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-23 22:32 --- dse2 removes the decrement: (insn/f 24 23 25 2 t2.c:2 (parallel [ (set (reg/f:SI 7 sp) (plus:SI (reg/f:SI 7 sp) (const_int -16 [0xfff0]))) (clobber (reg:CC 17 flags)) (clobber (mem:BLK (scratch) [0 A8])) ]) -1 (nil)) Even though it is frame related. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-23 22:32:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32475
[Bug c++/32470] fvisibility=hidden without effect in some casses
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-24 00:53 --- I can reproduce this, I am in the middle of reducing it, it is an interaction between friends, extern templates and visibility attribute on namespaces. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32470
[Bug rtl-optimization/32475] [4.3 Regression] function with asm() does not setup stack frame
--- Comment #4 from spark at gcc dot gnu dot org 2007-06-24 01:05 --- I think Kenny's last patch for PR32437 fixes this as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32475
[Bug rtl-optimization/32475] [4.3 Regression] function with asm() does not setup stack frame
--- Comment #5 from zadeck at naturalbridge dot com 2007-06-24 01:10 --- Subject: Re: [4.3 Regression] function with asm() does not setup stack frame spark at gcc dot gnu dot org wrote: > --- Comment #4 from spark at gcc dot gnu dot org 2007-06-24 01:05 --- > I think Kenny's last patch for PR32437 fixes this as well. > > > I have not had a chance to play with this. i lost my last x86-32 system and i have been futzing around with richi trying to build one on my x86-64 machines. So far without success. it would be good if it went away. if it has not, i was going to try -fno-dse. Kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32475
[Bug rtl-optimization/32475] [4.3 Regression] function with asm() does not setup stack frame
--- Comment #6 from spark at gcc dot gnu dot org 2007-06-24 02:01 --- (In reply to comment #5) > Subject: Re: [4.3 Regression] function with asm() > does not setup stack frame > > spark at gcc dot gnu dot org wrote: > > --- Comment #4 from spark at gcc dot gnu dot org 2007-06-24 01:05 > > --- > > I think Kenny's last patch for PR32437 fixes this as well. > > > > > > > I have not had a chance to play with this. i lost my last x86-32 system > and i have been futzing around with richi trying to build one on my > x86-64 machines. So far without success. > > it would be good if it went away. if it has not, i was going to try > -fno-dse. > > Kenny I'm positive your patch fixes this, as the latest trunk doesn't have this problem, and I've checked out the revision just before your last patch, and it showed the problem (on i686-unknown-linux-gnu). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32475
[Bug bootstrap/32024] ICE - libgcc2.c:557: internal compiler error: in fold_checksum_tree, at fold-const.c:12652
--- Comment #15 from rob1weld at aol dot com 2007-06-24 02:17 --- I origonally reported "The bootstrap hardly runs for a few minutes and then I get an ICE." That is no longer the case. I am making gcc version 4.3.0 20070623. I'm 4 hours into the make (my build is made using "--enable-stage1-checking=assert,df,fold,gc,misc,rtl,rtlflag,runtime,tree"), it is passed all the stages and into the libraries now. _This_ bug report was marked as "RESOLVED DUPLICATE" of 20623 (which is filed against 4.1.0 for HTB x86_64-unknown-linux-gnu, while _this_ report is for 4.3.0 HTB i686-pc-linux-gnu - the kind of errors are different too). Since _this_ report is marked "RESOLVED DUPLICATE" _I_ can not change it to "RESOLVED FIXED", if someone else who is able would wish to do so that is OK by me. I do not know that 20623 is fixed and no one has marked it as such. -- rob1weld at aol dot com changed: What|Removed |Added CC|rob1weld at aol dot com | Known to work||4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32024
[Bug middle-end/20623] ICE: fold check: original tree changed by fold with --enable-checking=fold
--- Comment #31 from rob1weld at aol dot com 2007-06-24 02:22 --- (In reply to comment #14) > *** Bug 32024 has been marked as a duplicate of this bug. *** 32024 is fixed. I would add 4.3.0 to _this_ "Known to work" list if I was able. -- rob1weld at aol dot com changed: What|Removed |Added CC|rob1weld at aol dot com | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20623
[Bug rtl-optimization/32475] [4.3 Regression] function with asm() does not setup stack frame
--- Comment #7 from zadeck at naturalbridge dot com 2007-06-24 02:48 --- Subject: Re: [4.3 Regression] function with asm() does not setup stack frame spark at gcc dot gnu dot org wrote: > --- Comment #6 from spark at gcc dot gnu dot org 2007-06-24 02:01 --- > (In reply to comment #5) > >> Subject: Re: [4.3 Regression] function with asm() >> does not setup stack frame >> >> spark at gcc dot gnu dot org wrote: >> >>> --- Comment #4 from spark at gcc dot gnu dot org 2007-06-24 01:05 >>> --- >>> I think Kenny's last patch for PR32437 fixes this as well. >>> >>> >>> >>> >> I have not had a chance to play with this. i lost my last x86-32 system >> and i have been futzing around with richi trying to build one on my >> x86-64 machines. So far without success. >> >> it would be good if it went away. if it has not, i was going to try >> -fno-dse. >> >> Kenny >> > > I'm positive your patch fixes this, > as the latest trunk doesn't have this problem, > and I've checked out the revision just before your last patch, > and it showed the problem (on i686-unknown-linux-gnu). > > > great, then close it and be done with it. kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32475
[Bug c/32448] abs / printf bug
--- Comment #18 from rob1weld at aol dot com 2007-06-24 03:21 ---
(In reply to comment #16)
> (In reply to comment #14)
> > m.c: In function 'main':
> > m.c:9: warning: implicit declaration of function 'abs'
> Also, add a prototype for integer abs(), like "int abs(int);". Then everything
> will work as "expected".
> Rob
> ...why are the _third_ and _fourth_ answers different!
>Should the cast work without the extra parentheses.
#include
int abs(int);
double fabs(double);
int main()
{
printf("%f %f %f %f\n", abs(1234.5678), fabs(1234.5678),
abs((int)1234.5678), abs((int)(1234.5678)));
return 0;
}
63935681034496338248683601597699265113107384544848778287582042881171854556760809962494834238640539694738043963701847575050181760552125660054155932857305858816958002965674142423095065121202781270370782793943786455040.00
0.00 -0.422029 -0.00
If I re-write and swap the 3rd and fourth abs'es I get:
#include
int abs(int);
double fabs(double);
int main()
{
printf("%f %f %f %f\n", abs(1234.5678), fabs(1234.5678),
abs((int)(1234.5678)), abs((int)1234.5678));
return 0;
}
63935681034496338248683601597699265113107384544848778287582042881171854556760809962494834238640539694738043963701847575050181760552125660054155932857305858816958002965674142423095065121202781270370782793943786455040.00
0.00 -1.333046 -0.00
The same sort of output, so the parentheses are not at fault.
Printf does not cast it's "%i" / "%f" 's even with constants know at compile
time, let alone run-time. It is like you said in comment 2 "Especially with
%f."
So if you wanted to call functions by way of a pointer and they might return
int or float (or double) you would need code to test the type prior to
attempting to send it to multiple types of printf statement.
Using one printf for each possible combination with only 2 vars we would need 4
printf's. At least all the extra trouble buys us that it doesn't matter if they
are const or var :( here goes (there is no need for "_someone_" to post that
I'm missing a main() statement!):
...
switch (TYPE_TEST_FOR_2_VARS(x,y)) {
case TTF2V_I_I:
printf("X= %i Y=%i\n", x, y);
goto done;
case TTF2V_I_F:
printf("X= %i Y=%f\n", x, y);
goto done;
case TTF2V_F_I:
printf("X= %f Y=%i\n", x, y);
goto done;
case TTF2V_F_F:
printf("X= %f Y=%f\n", x, y);
goto done;
}
done:;
...
Same idea for 4 variables, just a lot more code ...
Gotcha, thanks Uros.
--
rob1weld at aol dot com changed:
What|Removed |Added
Summary|[3.3 / 3.4 / 4.1 / 4.2 / 4.3|abs / printf bug
|Regression] abs / printf bug|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32448
[Bug objc++/32320] [4.1 regression] ICE with invalid template parameter
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-24 03:37 --- *** This bug has been marked as a duplicate of 27668 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Version|new-ra |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32320
[Bug c++/27668] [4.1 regression] ICE with invalid template parameter
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-06-24 03:37 --- *** Bug 32320 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||uhle1982 at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27668
[Bug tree-optimization/32273] 'restrict' is forgotten after loop unrolling
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32273
[Bug c/31871] C99 failure to diagnose non-integer cast
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-24 03:46 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-24 03:46:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31871
[Bug c/31924] gcc accepts invalid suffixes for decimal float constants
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-24 03:49 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31924
[Bug tree-optimization/19590] IVs with the same evolution not eliminated
--- Comment #17 from pinskia at gcc dot gnu dot org 2007-06-24 03:53 --- Fixed. Note I think the proposed patch attached here will fix PR 32200. That testcase was not fixed the VRP patch. The VRP patch fixes the case where we have IV - IV inside the loop. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19590
[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32461
[Bug debug/32444] missing debug information for structure components with optimized code
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-24 04:04 --- http://gcc.gnu.org/ml/gcc/2005-01/msg00016.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32444
[Bug debug/32445] no debug information for loop counters
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-24 04:07 --- On the mainline, we have ivtmp.33 going from 1 to 101 so it does not equal the same as what i is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32445
[Bug tree-optimization/32075] can't determine dependence between p->a[x+i] and p->a[x+i+1] where x is invariant but defined in the function
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-06-24 04:07 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32075
[Bug c/32448] abs / printf bug
--- Comment #19 from rob1weld at aol dot com 2007-06-24 05:01 ---
So here we have it:
#include
int abs(int);
double fabs(double);
int main()
{
printf("%f %f %f %f\n", abs(1234.5678), fabs(1234.5678),
abs((int)1234.5678), abs((int)(1234.5678)));
printf("%f %f %f %f\n", (float)abs(1234.5678), (float)fabs(1234.5678),
(float)abs((int)1234.5678), (float)abs((int)(1234.5678)));
return 0;
}
# /opt/gcc-4_3-build-2/gcc/xgcc -Wall -B/opt/gcc-4_3-build-2/gcc/ -o
math_test_11 math_test_11.c
math_test_11.c: In function 'main':
math_test_11.c:9: warning: format '%f' expects type 'double', but argument 2
has type 'int'
math_test_11.c:9: warning: format '%f' expects type 'double', but argument 4
has type 'int'
math_test_11.c:9: warning: format '%f' expects type 'double', but argument 5
has type 'int'
# ./math_test_11
63935681034496338248683601597699265113107384544848778287582042881171854556760809962494834238640539694738043963701847575050181760552125660054155932857305858816958002965674142423095065121202781270370782793943786455040.00
0.00 -0.008386 -0.00
1234.00 1234.567749 1234.00 1234.00
Conclusion:
Printf can't figure out it's own casts (even for consts) and you _must_ use the
cast (float) before any variables that are to be printed with format "%f".
Since GCC can 'see' the "%f" at compile time, _If_ gcc put in the "(float)"
cast (fix all other types too) for you then the printf statement would produce
the correct result and provide the missing piece to what Andrew claims in
comment 4 "abs converts the float/double to an integer type".
A simple modification to GCC could read the format and cast the variable. This
could be integrated with ssp to avoid reading and writing (sprintf()) to the
stack. This does not seem like an expensive mod.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32448
[Bug c/32448] abs / printf bug
--- Comment #20 from pinskia at gcc dot gnu dot org 2007-06-24 05:08 --- > Since GCC can 'see' the "%f" at compile time Yes it can but that does not mean the behavior is the correct to cast it to float. In fact the behavior is undefined at runtime so you are just running into the runtime undefined behavior which is really normal with C/C++ now adays. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32448
[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700
--- Comment #11 from spop at gcc dot gnu dot org 2007-06-24 06:48 --- Subject: Re: [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700 Hi, On 6/23/07, Richard Guenther <[EMAIL PROTECTED]> wrote: > > First - can you check why the asociate: case in fold_binary does not do > > the transformation and maybe fix that instead if possible? > > The associate case is the last case for MINUS_EXPR, but the case /* A - B -> A + (-B) if B is easily negatable. */ applies, and returns ~(unsigned int) i_434 + (unsigned int) i_434 before going to execute the associate code. Unfortunately I haven't seen the suggestion of Håkan Hjort to also implement the fold of ~a + a ==> ~0. I could add a new patch for this one too in the next bootstrap if the current patch still has issues. > > + && integer_zerop (fold_build2 (MINUS_EXPR, type, arg0, > > +TREE_OPERAND (arg1, 0 > > > > to avoid creating trees and just throwing them away you should use > > operand_equal_p (arg0, TREE_OPERAND (arg1, 0)) instead. Hmm, this was my first implementation, as I just mimicked the code just before, that is using operand_equal_p. However in my case I have 'A' and 'nop(unsigned int, A)' so they are not exactly the same trees, but the difference is zero. > > You similarly may want to check operand 1 for A - (B + A)? > > yes, okay. > > + && TYPE_UNSIGNED (type) > > > > you should check TYPE_OVERFLOW_WRAPS (type) instead. > > Oh - and there is omit_two_operands which you should use to > omit the two As. This takes care of side-effects. > done. The attached patch bootstrapped and passed test on i686-linux. Sebastian --- Comment #12 from spop at gcc dot gnu dot org 2007-06-24 06:48 --- Created an attachment (id=13770) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13770&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32461
