[Bug tree-optimization/34147] internal compiler error: in set_iv, at tree-ssa-loop-ivopts.c:936
--- Comment #3 from ubizjak at gmail dot com 2007-11-20 08:01 --- (In reply to comment #2) > I build the toolchains use buildroot, the gcc version is 4.1.2, the target > platform is arm, host platform is cygwin. The busybox version is 1.1.3 > If i uncomment some configure of busybox, a new error will show as following: Go into directory /home/mahua/opt/test/busybox-1.1.3/editors/ and type: gcc -save-temps vi.c, where is something like arm-elf- or arm-linux-elf- and is complete compile flags, copied from the compile log, since these usually span several lines. Please post _complete_ command how gcc was invoked (so we can use your compile flags) and attach generated vi.i from /home/mahua/opt/test/busybox-1.1.3/editors/ to this report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34147
[Bug fortran/34159] New: Checkbound could warn about unallocated arrays
Hi! I don't seem to get gfortran to warn when assigning to an unallocated array (I've tried '-g -fbounds-check -Wall -pedantic', which I take it should cover it all), it only segfaults at run-time... While this is obviously menial stuff, the Lahey compiler for one nicely warns both at compile- and run-time. Just for the record... Thanks! Philippe PS: a reduced example: ! PROGRAM Test ! INTEGER, ALLOCATABLE :: Array(:) ! Array = 256 ! END PROGRAM Test ! PPS: I've tried with GNU Fortran (GCC) 4.3.0 20071119 (experimental) [trunk revision 130286] -- Summary: Checkbound could warn about unallocated arrays Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: P dot Schaffnit at access dot rwth-aachen dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34159
[Bug tree-optimization/34140] [4.3 Regression] ICE in is_hidden_global_store, at tree-ssa-sink.c:207
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-11-20 09:08 --- (In reply to comment #3) > WTF? tree if-conversion generates this crap. It split up the store to rc.aec[i].fCubeful . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34140
[Bug c/34146] [4.1/4.2/4.3 Regression] Inefficient code with compound literals inside a CONSTRUCTO
--- Comment #2 from jakub at gcc dot gnu dot org 2007-11-20 10:36 --- Subject: Bug 34146 Author: jakub Date: Tue Nov 20 10:36:03 2007 New Revision: 130311 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130311 Log: PR c/34146 * c-gimplify.c (optimize_compound_literals_in_ctor): New function. (c_gimplify_expr): Use it. PR c/34146 * gcc.dg/tree-ssa/pr34146.c: New test. PR testsuite/33978 * gcc.dg/tree-ssa/pr33723.c: Adjust scan pattern to make it less dependent on target settings like move_by_pieces etc. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr34146.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-gimplify.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/pr33723.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34146
[Bug middle-end/32624] [4.3 Regression] r126198 causes tramp3d slowdown w/o leafify
--- Comment #5 from steven at gcc dot gnu dot org 2007-11-20 09:57 --- -ENONEWSFORMONTHS -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32624
[Bug tree-optimization/34140] [4.3 Regression] ICE in is_hidden_global_store, at tree-ssa-sink.c:207
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-11-20 09:13 --- Well I don't think ifcvt is fully to be blamed here: if (D.1542_49 != 0) goto ; else goto ; : # prephitmp.14_44 = PHI <1(13), 0(11)> # rc_45 = PHI Why do we have that last PHI anyways? Unswitch creates it. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34140
[Bug testsuite/33978] FAIL: gcc.dg/tree-ssa/pr33723.c scan-tree-dump-times t.f.f1 = 1 4
--- Comment #4 from jakub at gcc dot gnu dot org 2007-11-20 10:36 --- Subject: Bug 33978 Author: jakub Date: Tue Nov 20 10:36:03 2007 New Revision: 130311 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130311 Log: PR c/34146 * c-gimplify.c (optimize_compound_literals_in_ctor): New function. (c_gimplify_expr): Use it. PR c/34146 * gcc.dg/tree-ssa/pr34146.c: New test. PR testsuite/33978 * gcc.dg/tree-ssa/pr33723.c: Adjust scan pattern to make it less dependent on target settings like move_by_pieces etc. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr34146.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-gimplify.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/pr33723.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33978
[Bug tree-optimization/34123] [4.3 Regression] verify_ssa failed with -ftree-loop-linear
--- Comment #4 from jakub at gcc dot gnu dot org 2007-11-20 10:59 ---
The testcase is wrong, static unsigned char sbox[] = {}; means zero sized
array.
But using sbox[256] makes the testcase valid and the problem is still there.
This looks like a bug in can_convert_to_perfect_nest, this loop (at least
unless
earlier passes don't realize that sbox[i] == 0 for any i) can't be converted
into a perfect nest.
The basic block which is after the inner loop is:
:
# t_30 = PHI
D.1558_19 = (unsigned char) i_39;
t_20 = t_30 + D.1558_19;
i_21 = i_39 + 1;
if (i_21 <= 15)
goto ;
else
goto ;
:
:
# i_39 = PHI <0(2), i_21(6)>
# SMT.4_10 = PHI
# t_29 = PHI <0(2), t_20(6)>
goto ;
can_convert_to_perfect_nest walks the statements of these bbs and is satisfied
with all of them, the first two stmts in bb5 are satisfied by:
2234 tree step = evolution_part_in_loop_num (scev,
loop->num);
2235 if (step && step != chrec_dont_know
2236 && TREE_CODE (step) == INTEGER_CST)
2237continue;
- step is for both integer_one_node, the third stmt is of course correctly a
stmt_is_bumper_for_loop and the last one is exit_condition. But nothing scans
the PHIs which are relevant here. # t_30 = PHI in bb5 sets t_30 to
t_16, which is computed by inner loop. And # t_29 = PHI <0(2), t_20(6)>
in bb7 sets t_29 used in the inner loop to t_20 set in bb5 (i.e. in the bb
which prevents perfect nest). Should the PHIs be walked similarly to how
stmts are walked?
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||dberlin at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34123
[Bug fortran/34133] Bind(c,name="") should be rejected for dummies; F2008: allow bind(c) for internal procs
--- Comment #7 from burnus at gcc dot gnu dot org 2007-11-20 10:55 --- Assign bug to myself. I have a patch, which does: - rejects bind(c) with -std=f2003 for internal function (was missing!) - Allows for -std=gnu bind(c) for internal procedures, but rejects bind(c,name=...) - Rejects binding names for dummy procedures Now I only need to create a bunch of test cases. -- 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-11-20 10:55:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34133
[Bug c/34146] [4.1/4.2 Regression] Inefficient code with compound literals inside a CONSTRUCTO
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-20 11:00 --- Fixed on the trunk. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2/4.3 Regression]|[4.1/4.2 Regression] |Inefficient code with |Inefficient code with |compound literals inside a |compound literals inside a |CONSTRUCTO |CONSTRUCTO http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34146
[Bug testsuite/33978] FAIL: gcc.dg/tree-ssa/pr33723.c scan-tree-dump-times t.f.f1 = 1 4
--- Comment #5 from jakub at gcc dot gnu dot org 2007-11-20 11:00 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33978
Re: [Bug c++/34073] New: overloaded template function resolves differently if one type is included in a namespace
Where are "temp1.cc" and "temp2.cc" so that I correct them? are they part of
the compiler?
Thanks,
pinskia at gcc dot gnu dot org wrote:
>
> Two files are appended at the end of this report: temp1.cc and temp2.cc.
>
> temp1.cc is the only file that causes a problem with recent releases
> of GCC. It contains :
>
> 1. a template definition of Structure
> 2. a template definition of op_is_finite(const Structure*)
> 3. a template definition of algebra::AlphabetSet inheriting from
> Structure
> 4. a template definition of Element
>that calls op_is_finite(const algebra::AlphabetSet*) in its ctor
> 5. a template overloaded definition for
> op_is_finite(const
> algebra::AlphabetSet*)
> 6. a main function that instantiate Element.
>
> Because all definitions but main() are template, I expect the call to
> op_is_finite() in the ctor of Element (#4) to be resolved during the
> instantiation of Element (#6) after the second definition
> of op_is_finite() (#5) has been read. So the call would be bound
> to that second definition and not to the first.
>
> I have tested three GCC versions :
> g++-3.4 (GCC) 3.4.6 (Debian 3.4.6-6)
> g++-4.1 (GCC) 4.1.3 20070718 (prerelease) (Debian 4.1.2-14)
> g++-4.2 (GCC) 4.2.3 20071014 (prerelease) (Debian 4.2.2-3)
>
> Both 4.1 and 4.2 behave identically: they seem to ignore the second
> definition of op_is_finite and try to call the first.
>
> 3.4 does what we expect: it calls the second definition.
>
>
> We have found at least two ways to alter temp1.cc such that 4.2 will
> compile it.
>
> - One is to move the second definition of op_is_finite() (#5) before its
> use in the constructor of Element (#4).
>
> This ordering would make sense to me if the functions were not
> template, but it's not clear why this would change anything in
> the resolution of template overloaded functions. I might be
> missing something.
>
> - Another possibility is to move AlphabetSet struct out of
> the "algebra::" namespace. temp2.cc contains the updated
> code.
>
> I'm really surprized that 4.2 compiles temp2.cc
> without problem and fails on temp1.cc.
>
>
>
>
> //
> temp1.cc starts here
> //
>
> template struct Structure {};
>
> template
> bool op_is_finite (const Structure*)
> {
> // Error on purpose, this function is not expected to be instantiated.
> return Structure();
> }
>
> namespace algebra
> {
> template
> struct AlphabetSet : public Structure > {};
> }
>
> template
> struct Element
> {
> Element()
> {
> op_is_finite(static_cast*>(0));
> }
> };
>
> template
> bool op_is_finite(const algebra::AlphabetSet*)
> {
> // This is the function we want to be called.
> return true;
> }
>
> int main()
> {
> Element alpha;
> }
>
> // % g++-3.4 -Wall -W temp1.cc
> // % g++-4.2 -Wall -W temp1.cc
> // temp1.cc: In function 'bool op_is_finite(const Structure*) [with S =
> algebra::AlphabetSet]':
> // temp1.cc:21: instantiated from 'Element::Element() [with L =
> char]'
> // temp1.cc:34: instantiated from here
> // temp1.cc:7: error: cannot convert 'Structure
> >'
> to 'bool' in return
>
> //
> temp2.cc starts here
> //
>
> template struct Structure {};
>
> template
> bool op_is_finite (const Structure*)
> {
> // Error on purpose, this function is not expected to be instantiated.
> return Structure();
> }
>
> template
> struct AlphabetSet : public Structure > {};
>
> template
> struct Element
> {
> Element()
> {
> op_is_finite(static_cast*>(0));
> }
> };
>
> template
> bool op_is_finite(const AlphabetSet*)
> {
> // This is the function that is called, as we expected.
> return true;
> }
>
> int main()
> {
> Element alpha;
> }
>
> // % g++-3.4 -Wall -W temp2.cc
> // % g++-4.2 -Wall -W temp2.cc
>
>
> --
>Summary: overloaded template function resolves differently if
> one
> type is included in a namespace
>Product: gcc
>Version: 4.2.3
> Status: UNCONFIRMED
> Severity: normal
> Priority: P3
> Component: c++
> AssignedTo: unassigned at gcc dot gnu dot org
> ReportedBy: adl at gnu dot org
> 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=34073
>
>
>
--
View this message in context:
http://www.nabble.com/-Bug-c%2B%2B-34073---New%3A-overloaded-template-function-resolves-differently-if-one-type-is-included-in-a-namespace-tf4791742.html#a13855273
Sent from the gcc - bugs mailing list archive at Nabble.com.
[Bug fortran/34153] Debugging: Cannot set breakpoint in comment lines or "END PROGRAM"
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-20 11:34 --- The problem is that you end up in the wrong file. If you enter "break 3" you are debugging the wrapping program not the Fortran "program test", which is the reason that there is no "i" available. Try: break file.f:line, e.g. (gdb) b b.f:2 However, there is another problem: One cannot set the break point after the assignment: program test! Breakpoint possible i = 1 ! Breakpoint possible ! Breakpoint here ! No breakpoint possible end ! No breakpoint possible Setting a breakpoint in line 2, one can print the value "i" before the assignment; however, doing a "step" one ends in the wrapping main() program and can thus never read the value after the assignment. Using g77 or ifort, one can set a break point in line 3 or 4 and gdb shows then: Breakpoint 1, test () at b.f:4 4 end -- burnus at gcc dot gnu dot org changed: What|Removed |Added GCC host triplet|i386-apple-darwin | Summary|Unable to debug code|Debugging: Cannot set |compiled with gfortran on |breakpoint in comment lines |MacOSX 10.4.11 |or "END PROGRAM" http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34153
[Bug rtl-optimization/34085] ICE with -freorder-blocks-and-partition
--- Comment #18 from patchapp at dberlin dot org 2007-11-20 11:45 --- Subject: Bug number PR rtl-optimization/34085 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-11/msg01050.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34085
[Bug tree-optimization/34029] [4.3 Regression] internal compiler error: verify_stmts failed
--- Comment #5 from jakub at gcc dot gnu dot org 2007-11-20 11:50 ---
While it would be nice if that got folded, I believe the problem is elsewhere.
Consider:
static const char s[] = "ab.cd.efghijk";
static const char t[] = "abcde";
long
foo (const char *x)
{
const char *a;
long b = 0;
a = __builtin_strchr (s, '.');
return ((long) a) + (1 - (long) t);
}
(ok, not really kosher code, because there are two unrelated pointers
involved).
This ICEs the same way, and really fold can't fold &s[2] p+ (1 - (long int)
&t[0]) to anything meaningful (well, perhaps it could avoid creating the
ADDR_EXPR.
The problem is IMHO in is_gimple_min_invariant blindly allowing any ADDR_EXPRs
with TREE_INVARIANT set, yet the checking code in verify_expr insists that also
TREE_OPERAND (addr_ref, 1) is is_gimple_val.
Either the checking code should be made less stricter and allow any
TREE_INVARIANT ADDR_EXPRs (likely very bad idea), or is_gimple_min_invariant
should enforce it:
case ADDR_EXPR:
return TREE_INVARIANT (t) && is_gimple_val (TREE_OPERAND (t, 1));
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||amacleod at redhat dot com,
||dnovillo at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34029
[Bug tree-optimization/34160] New: Useful loop invariant motion missing
int main()
{
static int i, n;
static double a[200], b[200];
... (more variables and control flow)
for (i = 0; i < n; i++)
a[i] = b[i];
...
}
Tree-level optimisations do not pull out loads of i and n and store to i out of
loop. As a result, GCC generates five memory accesses on ia64 for each
iteration (4.3.0 20071112):
.L9:
.mii
nop 0
sxt4 r14 = r16
nop 0
.mmi
ld4 r15 = [r32]
ld4 r58 = [r33]
nop 0
;;
.mii
shladd r14 = r14, 3, r0
adds r16 = 1, r15
;;
add r15 = r35, r14
.mmi
add r14 = r34, r14
st4 [r32] = r16
cmp4.lt p6, p7 = r16, r58
;;
.mmi
nop 0
ldfd f6 = [r15]
nop 0
;;
.mib
stfd [r14] = f6
nop 0
(p6) br.cond.dptk .L9
On x86_64 situation is better (4.3.0 20070930), but not good:
.L13:
movslq %eax,%rdx
movqb.3894(,%rdx,8), %rax
movq%rax, x.3895(,%rdx,8)
leal1(%rcx), %eax
cmpl%eax, %edi
movl%eax, %ecx
movl%eax, i.3912(%rip)
jg .L13
but the optimization happened on RTL level, as final_cleanup dump reads:
:
# MPT.140_429 = VDEF
x[i.265] = b[i.265];
# VUSE
i.23 = i;
i.265 = i.23 + 1;
# MPT.140_430 = VDEF
i = i.265;
# VUSE
n.274 = n;
if (n.274 > i.265)
goto ;
else
goto ;
--
Summary: Useful loop invariant motion missing
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amonakov at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34160
[Bug tree-optimization/34160] Useful loop invariant motion missing
--- Comment #1 from amonakov at gmail dot com 2007-11-20 12:06 --- Created an attachment (id=14584) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14584&action=view) Preprocessed source Testcase attached. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34160
[Bug tree-optimization/34148] [4.3 Regression] Too many VOPs, too deep tree-ssa-sccvn.c recursion
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-11-20 12:20 --- http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01046.html fixes the miscompile of the C++ frontend. -fno-strict-aliasing makes the testcase consume a lot more memory than -fstrict-aliasing. Which is why -O is also a lot worse than -O2. What one can also notice is that we create lots of unpartitionable SFTs for structures with just _one_ SFT -- we should not need to create SFTs for those at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34148
[Bug tree-optimization/34148] [4.3 Regression] Too many VOPs, too deep tree-ssa-sccvn.c recursion
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-11-20 12:21 --- Created an attachment (id=14585) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14585&action=view) worse testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34148
[Bug ada/34118] Please enable stack checking (-fstack-check) by default
--- Comment #4 from ludovic at ludovic-brenta dot org 2007-11-20 12:31 --- Questions: 1) If Targparm.Stack_Check_Probes_On_Target is False (i.e. the "GNAT Stack-limit checking" is in effect), what circumstances would cause the stack check to not detect an overflow (i.e. "unreliable stack checking")? 2) If Targparm.Stack_Check_Probes_On_Target is True (i.e. the "GCC Probing Mechanism" is in effect, using the guard pages), would it take much effort to make it "reliable" on all targets, not just Alpha/Tru64, spu-elf and maybe some others? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34118
[Bug fortran/34143] alloc_comp_constructor.f90 fails with -fdefault-integer-8
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-11-20 13:03 --- The Intel and Sun compilers complain that this code is not legal, because you can't do "x = mytype(yy, bar)" if yy is not allocated. Otherwise, a reduced testcase on x86_64-linux is: type t integer, allocatable :: a(:) end type t type(t) :: x integer(kind=8), allocatable :: yy(:) x = t(yy) if (allocated(x%a)) print *, "bug" end -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-20 13:03:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34143
[Bug target/34081] [4.3 Regression] ICE in s390_function_value, at config/s390/s390.c:7880
--- Comment #9 from jakub at gcc dot gnu dot org 2007-11-20 12:58 ---
Calling middle-end aggregate_value_p on a dependent type certainly is not the
right thing to do. It can't possibly do the right thing for various C++
specific type tree codes anyway.
I wonder if the easiest fix wouldn't be adding a bool argument to
allocate_struct_function, which would prohibit calling aggregate_value_p in
there and setting current_function_returns_{,pcc_}struct.
The C++ frontend would then pass dependent_type_p (restype) as this argument,
all other FEs and middle-end would pass false.
The C++ FE certainly doesn't need current_function_returns_pcc_struct value
in templates and current_function_returns_struct, while used once in the FE,
can't make much sense for dependent types.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34081
[Bug c/34161] New: -Os produces 32-bit load from 16-bit variable
When compiling the following program with -Os, the short member x of struct a
is read using a movl instruction instead of movzwl.
struct a {
int dummy;
short x;
};
struct b {
unsigned short x;
};
extern void dummy(struct b *b);
void f(struct a *a, struct b *b)
{
dummy(b);
if (a) {
asm("/* THIS FIELD IS ONLY 16 BITS */");
b->x = a->x;
}
}
With -O3:
movzwl 4(%ebx), %eax
movw%ax, (%esi)
And -Os:
movl4(%ebx), %eax
movw%ax, (%esi)
--
Summary: -Os produces 32-bit load from 16-bit variable
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vegard at peltkore dot net
GCC build triplet: i386-redhat-linux
GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34161
[Bug fortran/34153] Debugging: Cannot set breakpoint in comment lines or "END PROGRAM"
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-11-20 13:10
---
(In reply to comment #1)
> The problem is that you end up in the wrong file. If you enter "break 3" you
> are debugging the wrapping program not the Fortran "program test", which is
> the
> reason that there is no "i" available.
This part of the bug was fixed by a recent commit of mine (and a gdb patch).
With development versions of gfortran and gdb, breaking by "b 2" will break at
line 2 of the Fortran main program.
> However, there is another problem: One cannot set the break point after the
> assignment:
>
> program test! Breakpoint possible
> i = 1 ! Breakpoint possible
> ! Breakpoint here ! No breakpoint possible
> end ! No breakpoint possible
It's also possible in C with GCC mainline:
(gdb) l
1 int main(void)
2 {
3 int i;
4 i = 1;
5 /* That's all, folks! */
6 }
(gdb) b 5
Breakpoint 1 at 0x400467: file z.c, line 5.
(gdb) r
Starting program: /home/fxcoudert/devel/debug2/irun/a.out
Breakpoint 1, main () at z.c:6
6 }
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
||org
OtherBugsDependingO||24546
nThis||
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||wrong-debug
Last reconfirmed|-00-00 00:00:00 |2007-11-20 13:10:19
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34153
[Bug fortran/34162] New: F2008: Allow internal procedures as actual argument
I actually only fill this to ensure my test case does not get lost.
Fortran 2003 contains ("12.4 Procedure reference"):
"C1229 (R1221) A procedure-name shall be the name of an external procedure, a
dummy procedure, a module procedure, a procedure pointer, or a specific
intrinsic function that is listed in 13.6 and not marked with a bullet(*).
NOTE 12.16 -- This standard does not allow internal procedures to be used as
actual arguments, in part to simplify the problem of ensuring that internal
procedures with recursive hosts access entities from the correct instance
(12.5.2.3) of the host."
In Fortran 2008 (draft 07-007r3) this restriction is gone:
"C1235 (R1223) A procedure-name shall be the name of an external, internal,
module, or dummy procedure, a specific intrinsic function listed in 13.6 and
not marked with a bullet (*), or a procedure pointer."
Test program (initially created for PR 34133):
! { dg-do run }
! PR fortran/34133
!
! Test of using internal bind(C) procedures as
! actual argument. Bind(c) on internal procedures and
! internal procedures are actual argument are
! Fortran 2008 (draft) extension.
!
module test_mod
use iso_c_binding
implicit none
contains
subroutine test_sub(a, arg, res)
interface
subroutine a(x) bind(C)
import
integer(c_int), intent(inout) :: x
end subroutine a
end interface
integer(c_int), intent(inout) :: arg
integer(c_int), intent(in) :: res
call a(arg)
if(arg /= res) call abort()
end subroutine test_sub
subroutine test_func(a, arg, res)
interface
integer(c_int) function a(x) bind(C)
import
integer(c_int), intent(in) :: x
end function a
end interface
integer(c_int), intent(in) :: arg
integer(c_int), intent(in) :: res
if(a(arg) /= res) call abort()
end subroutine test_func
end module test_mod
program main
use test_mod
implicit none
call test_sub (one, 33, 7*33)
call test_func(two, 23, -123*23)
contains
subroutine one(x) bind(c)
integer(c_int),intent(inout) :: x
x = 7*x
end subroutine one
integer(c_int) function two(y) bind(c)
integer(c_int),intent(in) :: y
two = -123*y
end function two
end program main
! { dg-final { cleanup-modules "test_mod" } }
--
Summary: F2008: Allow internal procedures as actual argument
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
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=34162
[Bug fortran/34159] Checkbound could warn about unallocated arrays
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords|ice-on-invalid-code | Last reconfirmed|-00-00 00:00:00 |2007-11-20 13:11:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34159
[Bug fortran/34133] Bind(c,name="") should be rejected for dummies; F2008: allow bind(c) for internal procs
--- Comment #8 from patchapp at dberlin dot org 2007-11-20 14:01 --- Subject: Bug number PR34133 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-11/msg01062.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34133
[Bug tree-optimization/34140] [4.3 Regression] ICE in is_hidden_global_store, at tree-ssa-sink.c:207
--- Comment #6 from rakdver at kam dot mff dot cuni dot cz 2007-11-20 13:56 --- Subject: Re: [4.3 Regression] ICE in is_hidden_global_store, at tree-ssa-sink.c:207 > > > --- Comment #5 from pinskia at gcc dot gnu dot org 2007-11-20 09:13 > --- > Well I don't think ifcvt is fully to be blamed here: > > if (D.1542_49 != 0) > goto ; > else > goto ; > > : > # prephitmp.14_44 = PHI <1(13), 0(11)> > # rc_45 = PHI > > Why do we have that last PHI anyways? Unswitch creates it. I think more important question is why we do not optimize it out (many other optimizations, e.g. copy propagation, may create such phi nodes). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34140
[Bug ada/23487] Assignment from incompatible pointer warning in __gnat_install_handler kills bootstrap
--- Comment #7 from sam at rfc1149 dot net 2007-11-20 13:56 --- This issue can be closed as the code in init.c has changed and those warnings have been taken care of. -- sam at rfc1149 dot net changed: What|Removed |Added CC||sam at rfc1149 dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23487
[Bug ada/34117] Please enable range checks by default (-gnato)
--- Comment #4 from bauhaus at futureapps dot de 2007-11-20 14:49 --- I can't resist pointing out that right now I am seeing an update to widely used free software where once again an integer overflow is creating a security hole in the system. (CVE-2007-4619) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34117
[Bug target/34163] New: 10% performance regression since Nov 1 on Polyhedron's "NF" on AMD64
According to http://www.suse.de/~gcctest/c++bench/polyhedron/, the run time of "NF" increased from 37.70s to 41.57s (+10%) between 071031 and 071101. This is an AMD Opteron system. The same result I obtained at http://physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/ also on an AMD64. Interestingly, while x86-64 (-m64) gets slower, using -m32 I don't see any change (apart of noise) - neither for x87 nor for SSE(3). To boil it down to version numbers, I believe the change must have happened between the following versions: Fast: 4.3.0 20071031 (experimental) [trunk revision 129791] Slow: 4.3.0 20071031 (experimental) [trunk revision 129797] As culpits there are essentially only the following checkins possible: - PR tree-optimization/32377 (compute_overlap_steps_for_affine_univar) Make it work also for unknown number of iterations. [Sebastian Pop] - PR middle-end/33779 fold-const.c (extract_muldiv_1): Make sure to not introduce new undefined integer overflow. [Richard Guenther] - PR fortran/33897 decl.c (gfc_match_entry): Do not make ENTRY name global for contained procedures. parse.c (gfc_fixup_sibling_symbols): Fix code for determining whether a procedure is external. [Paul Thomas] The Polyhedron test case is available from: http://www.polyhedron.co.uk/MFL6VW74649 -- Summary: 10% performance regression since Nov 1 on Polyhedron's "NF" on AMD64 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34163
[Bug c++/34164] New: Inconsistent size used for allocate/deallocate for std::string
Looking at 4.1.1
/data_storage/obj-4.1.1/i686-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc
It looks as though the size is incorrectly figured for the deallocate.
_M_destroy uses sizeof(_Rep_base) where _S_create uses sizeof(_Rep) to
determine the size of the allocation. Based on the header it looks like _Rep is
larger.
I can't say I've had an errror with this, but I was just dumpster diving the
code to figure out a purify error and came across this inconsitency. It doesn't
really do anything when you use the default allocator, since deallocate doesn't
use the size in the default.
template
void
basic_string<_CharT, _Traits, _Alloc>::_Rep::
_M_destroy(const _Alloc& __a) throw ()
{
const size_type __size = sizeof(_Rep_base) +
(this->_M_capacity + 1) * sizeof(_CharT);
_Raw_bytes_alloc(__a).deallocate(reinterpret_cast(this), __size);
}
template
typename basic_string<_CharT, _Traits, _Alloc>::_Rep*
basic_string<_CharT, _Traits, _Alloc>::_Rep::
_S_create(size_type __capacity, size_type __old_capacity,
const _Alloc& __alloc)
{
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// 83. String::npos vs. string::max_size()
if (__capacity > _S_max_size)
__throw_length_error(__N("basic_string::_S_create"));
const size_type __pagesize = 4096;
const size_type __malloc_header_size = 4 * sizeof(void*);
if (__capacity > __old_capacity && __capacity < 2 * __old_capacity)
__capacity = 2 * __old_capacity;
size_type __size = (__capacity + 1) * sizeof(_CharT) + sizeof(_Rep);
const size_type __adj_size = __size + __malloc_header_size;
if (__adj_size > __pagesize && __capacity > __old_capacity)
{
const size_type __extra = __pagesize - __adj_size % __pagesize;
__capacity += __extra / sizeof(_CharT);
// Never allocate a string bigger than _S_max_size.
if (__capacity > _S_max_size)
__capacity = _S_max_size;
__size = (__capacity + 1) * sizeof(_CharT) + sizeof(_Rep);
}
// NB: Might throw, but no worries about a leak, mate: _Rep()
// does not throw.
void* __place = _Raw_bytes_alloc(__alloc).allocate(__size);
_Rep *__p = new (__place) _Rep;
__p->_M_capacity = __capacity;
return __p;
}
--
Summary: Inconsistent size used for allocate/deallocate for
std::string
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Aaron dot m dot camac at boeing dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34164
[Bug middle-end/34154] gcc 4.1.1 bug / case ranges / unsigned long long
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-20 15:36 --- Confirmed. HWI32 problem. The middle-end uses HWI for computing with the case values. Up to 4.1.1, gcc ICEs for me on the testcase, from 4.1.1 on wrong code is emitted. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |middle-end Ever Confirmed|0 |1 GCC host triplet|i686-pc-linux-gnu |hwi32 Keywords||wrong-code Known to fail||4.1.3 4.2.2 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-11-20 15:36:30 date|| Summary| gcc 4.1.1 bug / case ranges|gcc 4.1.1 bug / case ranges |/ unsigned long long|/ unsigned long long http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34154
[Bug c/34161] -Os produces 32-bit load from 16-bit variable
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-20 15:41 --- What's wrong? The x member is properly aligned, so a load beyond it is valid. If you make struct a packed, then the load uses movw. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34161
[Bug tree-optimization/34160] Useful loop invariant motion missing
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-20 15:43 --- Alias got in the way here. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Keywords||alias, missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34160
[Bug ada/34118] Please enable stack checking (-fstack-check) by default
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-11-20 15:37 --- > 1) If Targparm.Stack_Check_Probes_On_Target is False (i.e. the "GNAT > Stack-limit checking" is in effect), what circumstances would cause the > stack check to not detect an overflow (i.e. "unreliable stack checking")? If the static frame size of a function is too large (typically > 4KB). > 2) If Targparm.Stack_Check_Probes_On_Target is True (i.e. the "GCC Probing > Mechanism" is in effect, using the guard pages), would it take much effort > to make it "reliable" on all targets, not just Alpha/Tru64, spu-elf and > maybe some others? It's not difficult, but you have to do it on a per-architecture basis. AdaCore has done it on 7 architectures and is ready to contribute this code, see http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01846.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34118
[Bug c++/34089] [4.1/4.2/4.3 regression] Segfault on specialization using struct instead of template function.
--- Comment #4 from jakub at gcc dot gnu dot org 2007-11-20 16:19 --- Subject: Bug 34089 Author: jakub Date: Tue Nov 20 16:19:40 2007 New Revision: 130316 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130316 Log: PR c++/34089 * parser.c (cp_parser_class_head): Reject function template ids. * g++.dg/template/crash74.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/crash74.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34089
[Bug c++/34089] [4.1/4.2 regression] Segfault on specialization using struct instead of template function.
--- Comment #5 from jakub at gcc dot gnu dot org 2007-11-20 16:20 --- Fixed on the trunk. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2/4.3 regression]|[4.1/4.2 regression] |Segfault on specialization |Segfault on specialization |using struct instead of |using struct instead of |template function. |template function. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34089
[Bug bootstrap/34165] New: gcc directory fails to configure on solaris 8
I am trying to build gcc-4.2.2 using binutils 2.18. binutils seems to build fine. gcc fails when it hits the gcc directory configuration step. It seems the problem is that binutils as version string has changed from the past. I am not sure if it is a gcc or binutils problem. I also wonder if it is more wide spread in other configure scripts. 2.14: GNU assembler 2.14 20030612 2.18: GNU assembler (GNU Binutils) 2.18 There is a sed command in configure that fails because of this + /proj/wdtold/warrend/wdt_try7_tmp/gnu_sun5.8/gcc-4.2.2/bin/as --version + sed 1q as_ver=GNU assembler (GNU Binutils) 2.18 + echo GNU assembler (GNU Binutils) 2.18 + grep GNU + echo GNU assembler (GNU Binutils) 2.18 + sed -e s/GNU assembler \([0-9.][0-9.]*\).*/\1/ as_ver=GNU assembler (GNU Binutils) 2.18 + echo GNU assembler (GNU Binutils) 2.18 + sed s/\..*// as_major=GNU assembler (GNU Binutils) 2 + echo GNU assembler (GNU Binutils) 2.18 + sed s/[^.]*\.\([0-9]*\).*/\1/ as_minor=18 + test GNU assembler (GNU Binutils) 2 -eq 2 /proj/wdtold/warrend/gnusrc_new/30-gcc-4.2.2/gcc-4.2.2/gcc/configure: test: unknown operator assembler This is right after the check for .sleb128 and .uleb128 I am going to change the sed command and try to proceed. If there is a good reason to stop please let me know. -- Summary: gcc directory fails to configure on solaris 8 Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: warren dot l dot dodge at tektronix dot com GCC build triplet: sparc-sun-solaris2.8 GCC host triplet: sparc-sun-solaris2.8 GCC target triplet: sparc-sun-solaris2.8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34165
[Bug libstdc++/34164] Inconsistent size used for allocate/deallocate for std::string
--- Comment #1 from pcarlini at suse dot de 2007-11-20 17:49 --- No, no, don't worry about that, the syntactic difference is an old workaround for a front-end limitation, doesn't matter, _Rep doesn't have any non-static member and the size is the same. By the way, we already received from time to time reports about spurious messages from purify, I would suggest double-checking with valgrind, which, to my best knowledge, is happy with our implementation (not just in the basic_string area) also because includes specific "suppressions" (see the docs about that). -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34164
[Bug fortran/34162] F2008: Allow internal procedures as actual argument
-- fxcoudert 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-11-20 17:49:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34162
[Bug c++/34094] [4.2/4.3 Regression] Undefined static data member in anonymous namespace can acquire a definition anyway
--- Comment #5 from jakub at gcc dot gnu dot org 2007-11-20 18:00 --- Testing a fix. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-11-19 05:22:22 |2007-11-20 18:00:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34094
[Bug fortran/31560] improve error message for using components of later decl. variables in specification expressions
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-11-20 18:03 --- Here is a minimal testcase that reproduces the unclear error message: subroutine prirelval(nobs, dataset) type ped_data integer :: maxsiz end type ped_data integer, dimension(dataset%maxsiz) :: nobs type (ped_data) :: dataset end subroutine prirelval $ gfortran z.f90 z.f90:6.28: integer, dimension(dataset%maxsiz) :: nobs 1 Error: Expected another dimension in array declaration at (1) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2007-05-22 18:01:33 |2007-11-20 18:03:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31560
[Bug libstdc++/34164] Inconsistent size used for allocate/deallocate for std::string
--- Comment #2 from pcarlini at suse dot de 2007-11-20 17:53 --- ... also, I can tell you that at least a couple of times I saw either valgrind or purify stumbling on basic_string where the actual (real) memory leak was in user code, elsewhere, the memory was just unpredictably tainted... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34164
[Bug other/31088] Building cross-compiler with newlib-1.15.0 and binutils-2.17 fails in libssp
--- Comment #1 from rask at gcc dot gnu dot org 2007-11-20 19:30 --- If you don't build in a combined tree, you'll have to build and install binutils and newlib before you can build some of the gcc components, such as libssp. This means building gcc twice; first with --disable-libssp and so on, then build and install newlib and finally build gcc again without --disable-libssp and so on. IOW using a combined tree is much easier, but see also bug 32154, which was only fixed for GCC 4.3. -- rask at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |other Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31088
[Bug middle-end/29749] [4.0/4.1/4.2/4.3 regression] Missing byte swap optimizations
--- Comment #10 from jakub at gcc dot gnu dot org 2007-11-20 19:38 ---
Guess you should ping that on gcc-patches, or better resend after such a long
while. If you are going to do the latter, I think you should move the
testcase into gcc.dg/, add
/* { dg-do run { target { int32plus } } } */
/* { dg-options "-O2" } */
to make embedded folks happy and fix up comment formatting in the patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29749
[Bug bootstrap/32287] gas version style changed causes warnings with configure
--- Comment #7 from rask at gcc dot gnu dot org 2007-11-20 19:46 --- *** Bug 34165 has been marked as a duplicate of this bug. *** -- rask at gcc dot gnu dot org changed: What|Removed |Added CC||warren dot l dot dodge at ||tektronix dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32287
[Bug bootstrap/34165] gcc directory fails to configure on solaris 8
--- Comment #1 from rask at gcc dot gnu dot org 2007-11-20 19:46 --- *** This bug has been marked as a duplicate of 32287 *** -- rask at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34165
[Bug c++/34166] New: -fleading-underscore duplicate underscore in some template cases
we get duplicate underscore prefixes on std::string template function calls
generated when using -fleading-underscore
the .stabs entries are fine ("_ZNSs7reserveEm") but the generated assembler
code calls "__ZNSs7reserveEm" with two underscores instead
so the linker gives us a undefined symbol "__ZNSs7reserveEm" error
we tried with -O2, -O1, and -O0 and get the same result
other templates compile fine
--
Using built-in specs.
Target: i386-unknown-elf
Configured with: ../configure --with-mpfr-dir=../../mpfr-2.2.1/
--target=i386-unknown-elf --prefix=/home/shockenhull/bin/i386-unknown-elf
--enable-targets=all
Thread model: single
gcc version 4.1.1
Linux shockenhull 2.6.16.13-4-smp #1 SMP Wed May 3 04:53:23 UTC 2006 i686
athlon i386 GNU/Linux
---
i386-unknown-elf-g++ -c -fleading-underscore -g -O0 -D__cpluscplus -D__CYGWIN__
-I../externals/include/w32api -D__cdecl= -Ddllimport= -DDECLSPEC_NORETURN=
--save-temps -DTARGET_WIN32 -DTARGET_OS="WIN32" -DPRAY_WINDOWS_DOESNT_CRASH=1
-DTARGET_IA32 -DTARGET_CPU="IA32" -D__cdecl= -D__declspec= -Ddllimport=
-D__INSIDE_CYGWIN__ -Wno-pmf-conversions -I../ -I../../../
-I/home/shockenhull/projects/sqrlen/base
-I/home/shockenhull/projects/sqrlen/base/win32
-I/home/shockenhull/projects/sqrlen/base/ia32 -I../externals/include
-I../../../src -I/home/shockenhull/projects/sqrlen/drivers/video_out
-I/home/shockenhull/projects/sqrlen/drivers/video_out/win32_gl_hack
-I/home/shockenhull/projects/sqrlen/drivers/pc_misc/xml
-I/home/shockenhull/projects/sqrlen/drivers/pc_misc/ministring
-I/home/shockenhull/projects/sqrlen/drivers/fs
-I/home/shockenhull/projects/sqrlen/drivers/fs/win32 -include windef.h -o
pc_misc/xml/test.o
/home/shockenhull/projects/sqrlen/drivers/pc_misc/xml/test.cpp
---
#include
#include
void bob(void)
{
std::string s;
s = "biby";
s.replace(1, 4, "ob");
printf("%s\n", s.c_str());
}
---
I have the the test.ii file but it is 424KiB so I cannot post it here.
please email me for the file, I will email it back.
--
Summary: -fleading-underscore duplicate underscore in some
template cases
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: shockenhull at niceberg dot com
GCC build triplet: i386-linux-elf
GCC host triplet: i386-linux-elf
GCC target triplet: i386-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34166
[Bug middle-end/29749] [4.0/4.1/4.2/4.3 regression] Missing byte swap optimizations
--- Comment #11 from rask at gcc dot gnu dot org 2007-11-20 20:04 ---
> /* { dg-do run { target { int32plus } } } */
Or even better, use types such as uint_least32_t from stdint.h, then use this
dg directive:
/* { dg-do run { target { stdint_types } } } */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29749
[Bug c/34167] New: [4.3 regression] gcc fails to compile Linux kernel
Trying to compile latest linux-2.6.git with gcc 4.3 trunk as of today results in : kernel/built-in.o: In function `getnstimeofday': (.text+0x1c315): undefined reference to `__umoddi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x1c3cd): undefined reference to `__udivdi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x1c3f0): undefined reference to `__umoddi3' kernel/built-in.o: In function `timekeeping_resume': timekeeping.c:(.text+0x1c572): undefined reference to `__udivdi3' timekeeping.c:(.text+0x1c595): undefined reference to `__umoddi3' kernel/built-in.o: In function `update_wall_time': (.text+0x1cb9f): undefined reference to `__udivdi3' kernel/built-in.o: In function `update_wall_time': (.text+0x1cbc2): undefined reference to `__umoddi3' kernel/built-in.o: In function `update_wall_time': (.text+0x1cc5c): undefined reference to `__udivdi3' kernel/built-in.o: In function `update_wall_time': (.text+0x1cc86): undefined reference to `__umoddi3' make: *** [.tmp_vmlinux1] Error 1 It works fine with gcc 4.2, so it seems to be a 4.3 regression. -- Summary: [4.3 regression] gcc fails to compile Linux kernel Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ismail at pardus dot org dot tr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34167
[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use
--- Comment #26 from ismail at pardus dot org dot tr 2007-11-20 21:19 --- *** Bug 34167 has been marked as a duplicate of this bug. *** -- ismail at pardus dot org dot tr changed: What|Removed |Added CC||ismail at pardus dot org dot ||tr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug c/34167] [4.3 regression] gcc fails to compile Linux kernel
--- Comment #1 from ismail at pardus dot org dot tr 2007-11-20 21:19 --- *** This bug has been marked as a duplicate of 32044 *** -- ismail at pardus dot org dot tr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34167
[Bug middle-end/34154] gcc 4.1.1 bug / case ranges / unsigned long long
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-20 21:27 --- One bug is in gimplification which uses signed comparison to detect and discard empty ranges. But then expand breaks it again for the same reason. And then for a different reason, that it segfaults on Program received signal SIGSEGV, Segmentation fault. 0x0848381b in balance_case_nodes (head=0xbfcb4454, parent=0x0) at /home/richard/src/trunk/gcc/stmt.c:2713 2713cost += COST_TABLE (TREE_INT_CST_LOW (np->high)); because np->high is 0x8ac7230489e7 and obviously the cost_table is not that large. Another case of the unsigned failure. And that's enough to fix this PR. -- 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|2007-11-20 15:36:30 |2007-11-20 21:27:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34154
[Bug c/33076] Warning when passing a pointer to a const array to a function that expects a pointer to a non-cast one
--- Comment #10 from m-matti-a dot lehtonen at iki dot fi 2007-11-20 21:53
---
This code piece cannot compiled without warnings or errors.
/*! Presentation of transformation matrix */
typedef coordinate_ttransform_matrix_t[ 4 ][ 4 ];
...
void
transform_concat
(
transform_matrix_ttransform,
transform_matrix_t const transform1,
transform_matrix_t const transform2
);
...
void
transform_rotate
(
transform_matrix_ttransform,
real_t const angles[ 3 ]
)
{
transform_matrix_t
temp;
...
transform_concat( transform, transform, temp );
...
}
Without casts I got two warnings:
warning: passing argument 2 of ‘transform_concat’ from incompatible
pointer type
warning: passing argument 3 of ‘transform_concat’ from incompatible
pointer type
And if arument 2 and 3 are casted as
transform_concat( transform, (const transform_matrix_t) transform, (const
transform_matrix_t) temp );
Then I got two errors:
error: cast specifies array type
error: cast specifies array type
--
m-matti-a dot lehtonen at iki dot fi changed:
What|Removed |Added
CC||m-matti-a dot lehtonen at
||iki dot fi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33076
[Bug libfortran/32770] [Meta-bug] -fdefault-integer-8 issues
--- Comment #32 from tkoenig at gcc dot gnu dot org 2007-11-20 21:57 --- Subject: Bug 32770 Author: tkoenig Date: Tue Nov 20 21:57:04 2007 New Revision: 130322 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130322 Log: 2007-11-20 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/32770 * gfortran.dg/record_marker_1.f90: Explicitly set kinds so test passes with -frecord-marker=8. * gfortran.dg/integer_exponentiation_1.f90: Likewise. * gfortran.dg/integer_exponentiation_2.f90: Likewise. * gfortran.dg/integer_exponentiation_3.F90: Likewise. * gfortran.dg/integer_exponentiation_5.F90: Likewise. * gfortrand.dg/modulo_1.f90: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/integer_exponentiation_1.f90 trunk/gcc/testsuite/gfortran.dg/integer_exponentiation_2.f90 trunk/gcc/testsuite/gfortran.dg/integer_exponentiation_3.F90 trunk/gcc/testsuite/gfortran.dg/integer_exponentiation_5.F90 trunk/gcc/testsuite/gfortran.dg/modulo_1.f90 trunk/gcc/testsuite/gfortran.dg/record_marker_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug testsuite/34168] New: dg-require-effective-target vect_double doesn't work
I get FAIL: gfortran.dg/vect/fast-math-pr33299.f90 execution test Apparently, the check for dg-require-effective-target vect_double doesn't work. This is on my Athlon XP 2600+, which does not have SSE2. The options for that test case do include the -msse2 flag, which is wrong: Executing on host: /home/ig25/gcc-bin/trunk/gcc/testsuite/gfortran/../../gfortran -B/home/ig25/gcc-bin/trunk/gcc/tests uite/gfortran/../../ /home/ig25/gcc/trunk/gcc/testsuite/gfortran.dg/vect/fast-math-pr33299.f90 -O2 -ftree-vectorize -ftree-vectorizer-verbose=4 -fdump-tree-vect-stats -msse2 -ffast-math -L/home/ig25/gcc-bin/trunk/i686-pc-linux-gnu/./ libgfortran/.libs -L/home/ig25/gcc-bin/trunk/i686-pc-linux-gnu/./libgfortran/.libs -L/home/ig25/gcc-bin/trunk/i686-pc- linux-gnu/./libiberty -lm -o ./fast-math-pr33299.exe(timeout = 300) When I run the options by hand, I get an "illegal instruction" error: gfortran -O2 -ftree-vectorize -ftree-vectorizer-verbose=4 -fdump-tree-vect-stats -msse2 -ffast-math fast-math-pr33299.f90 $ ./a.out Illegal instruction $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 8 model name : AMD Athlon(TM) XP 2600+ stepping: 1 cpu MHz : 2083.200 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up ts bogomips: 4170.03 clflush size: 32 -- Summary: dg-require-effective-target vect_double doesn't work Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34168
[Bug middle-end/34154] gcc 4.1.1 bug / case ranges / unsigned long long
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-11-20 22:51 --- Subject: Bug 34154 Author: rguenth Date: Tue Nov 20 22:51:23 2007 New Revision: 130324 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130324 Log: 2007-11-20 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/34154 * gimplify.c (gimplify_switch_expr): Use tree_int_cst_lt instead of the signed INT_CST_LT. * stmt.c (expand_case): Likewise. (estimate_case_costs): Likewise. * testsuite/gcc.c-torture/execute/pr34154.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr34154.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/stmt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34154
[Bug middle-end/34154] gcc 4.1.1 bug / case ranges / unsigned long long
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-11-20 22:52 --- Fixed. Not a regression. 2.95 ICEs for me. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.1.3 4.2.2 4.3.0 |2.95.4 4.1.3 4.2.2 Known to work||4.3.0 Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34154
[Bug ada/34149] GNAT crash - deeply inrerited function
--- Comment #2 from sam at rfc1149 dot net 2007-11-20 23:02 --- Confirmed with current SVN trunk, tentative patch sent to the submitter for testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34149
[Bug tree-optimization/34169] New: Bad code generated with -O2
$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1
--enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug
--enable-mpfr --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
$ gcc -O2 -w p.c -o p ; ./p
Bad
$ gcc -O2 -fno-tree-pre -w p.c -o p ; ./p
$ gcc -O2 -fno-strict-aliasing -w p.c -o p ; ./p
$ cat p.c
int bmemcmp(void *a1, void *a2, unsigned len)
{
int dwlen = len / 4;
while (dwlen)
{
int res = *(int *)a1 - *(int *)a2;
if (res)
return res;
--dwlen;
++*(int **)&a1;
++*(int **)&a2;
}
return 0;
}
int main(int argc, char *argv[])
{
int *p1 = (int*)calloc(sizeof(int), 1024 * 1024 * 4);
int *p2 = (int*)calloc(sizeof(int), 1024 * 1024 * 4);
p1[3] = 1;
if (bmemcmp(p1, p2, 1024 * 1024 * 4) == 0)
printf("Bad\n");
return 0;
}
--
Summary: Bad code generated with -O2
Product: gcc
Version: 4.1.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: unaiur at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34169
[Bug c/34170] New: wrong code: mmx operation changes double to nan
I was working on a little routine to generate random vectors of two doubles,
but it produced nothing but {nan,nan}. It was a simple linear congruential
random number generator, so all it did was operate on a seed (a vector of two
integers) and then convert that to double using an SSE2 intrinsic. The result
was then multiplied by (1.0 / 2147483648.0) to give random numbers between -1
and 1. It was (1.0 / 2147483648.0) that turned out to be converted to nan.
I've reduced it to a minimal test case below. It prints out nan instead of 1.0.
You can compile it with: `cc -O0 -Wall -mmmx -o test test.c`
--- begin test.c ---
#include
#include
static __m64 s;
int main( int argc, char **argv ) {
__m64 a;
double d;
d = 1.0;
s = a + a;
printf( "%e\n", d );
return 0;
}
--- end test.c ---
--
Summary: wrong code: mmx operation changes double to nan
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tijl at ulyssis dot org
GCC build triplet: i386-unknown-freebsd7
GCC host triplet: i386-unknown-freebsd7
GCC target triplet: i386-unknown-freebsd7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34170
[Bug tree-optimization/34169] Bad code generated with -O2
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-21 00:18 --- ++*(int **)&a1; ++*(int **)&a2; you are accessing a void* as an int* which violates C/C++ aliasing rules so you are invoking undefined behavior. *** This bug has been marked as a duplicate of 21920 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34169
[Bug c/21920] aliasing violations
--- Comment #122 from pinskia at gcc dot gnu dot org 2007-11-21 00:18 --- *** Bug 34169 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||unaiur at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug c/34170] wrong code: mmx operation changes double to nan
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-21 00:19 --- Not really a bug since you forgot to flush the mmx/x87 registers for fp usage. -- 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=34170
[Bug tree-optimization/34147] internal compiler error: in set_iv, at tree-ssa-loop-ivopts.c:936
--- Comment #4 from huamama at gmail dot com 2007-11-21 02:01 --- Created an attachment (id=14586) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14586&action=view) the temp vi.c using -save-temps file the temp vi.c using -save-temps file when compile busybox using CONFIG_BUILD_AT_ONCE=y. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34147
[Bug tree-optimization/34147] internal compiler error: in set_iv, at tree-ssa-loop-ivopts.c:936
--- Comment #5 from huamama at gmail dot com 2007-11-21 02:02 --- I found when i compile busybox using CONFIG_BUILD_AT_ONCE=y, the error will happen, but if do not use CONFIG_BUILD_AT_ONCE=y, the compile will success. The temp file using -save-temps is attached with CONFIG_BUILD_AT_ONCE=y. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34147
[Bug tree-optimization/34147] internal compiler error: in set_iv, at tree-ssa-loop-ivopts.c:936
--- Comment #6 from huamama at gmail dot com 2007-11-21 02:08 --- Created an attachment (id=14587) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14587&action=view) the temp vi.c using -save-temps file, using 4.1.2 the temp vi.c using -save-temps file -- huamama at gmail dot com changed: What|Removed |Added Attachment #14586|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34147
[Bug ada/34117] Please enable overflow checks by default (-gnato)
--- Comment #5 from charlet at gcc dot gnu dot org 2007-11-21 06:55 --- This report is confused: range checking is enabled by default. -gnato is about overflow checking, not range checking. Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added Summary|Please enable range checks |Please enable overflow |by default (-gnato) |checks by default (-gnato) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34117
[Bug tree-optimization/34147] internal compiler error: in set_iv, at tree-ssa-loop-ivopts.c:936
--- Comment #7 from ubizjak at gmail dot com 2007-11-21 07:34 --- (In reply to comment #6) > the temp vi.c using -save-temps file Thanks, but we also need flags that were passed to gcc when editors/vi.c was compiled. Probably you have to enable verbose output from your compile scripts. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34147
[Bug testsuite/34168] dg-require-effective-target vect_double doesn't work
--- Comment #1 from ubizjak at gmail dot com 2007-11-21 07:18 --- No, the problem is that vectorizer runtime tests require some special treatment. You can look at gcc.dg/vect/vect-2.c, where check_vect is called to check for SSE2 support (on x86 targets). I think that kind of C glue function that would call check_vect() from gcc.dg/vect/tree-vect.h is needed for fortran runtime vectorizer tests. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-21 07:18:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34168
