[Bug middle-end/19020] libcalls are removed (-ftrapv does not work)
--- Comment #12 from bonzini at gnu dot org 2008-05-31 07:25 --- *** Bug 36398 has been marked as a duplicate of this bug. *** -- bonzini at gnu dot org changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19020
[Bug middle-end/36398] [4.4 Regression]: gcc.dg/pr30286.c
--- Comment #3 from bonzini at gnu dot org 2008-05-31 07:25 --- I think this was expected, the test should probably be XFAILed. *** This bug has been marked as a duplicate of 19020 *** -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36398
[Bug c/36399] New: FSF GCC ABI bug on darwin/x86-32
This testcase:
#include
__m128i r(__m128 d1, __m128 d2, __m128 d3, __m128i r, int t, __m128i s) {return
r+s;}
compiles to:
_r:
subl$12, %esp
movdqa %xmm3, %xmm0
paddq 32(%esp), %xmm0
addl$12, %esp
ret
with apple gcc 4.0 and 4.2.
It compiles to this with FSF 4.2:
_r:
subl$12, %esp
movdqa 48(%esp), %xmm0
paddq 16(%esp), %xmm0
addl$12, %esp
ret
Since apple GCC defines the ABI on darwin, this is an FSF GCC ABI bug for that
platform.
--
Summary: FSF GCC ABI bug on darwin/x86-32
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36399
[Bug fortran/35830] ICE with PROCEDURE() containing array formal arguments
--- Comment #9 from janus at gcc dot gnu dot org 2008-05-31 09:17 --- Ok, apparently rev. 136130 *did* in fact also fix the test case in comment #1 (although I somehow assumed otherwise), and therefore this whole PR is fixed. Should I add another test case with an assumed shape array (or simply change proc_decl_12.f90 to have an assumed shape instead of an explicit shape array)? Or is proc_decl_12.f90 enough as it is? -- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-04-06 12:44:34 |2008-05-31 09:17:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35830
[Bug middle-end/35412] [4.4 Regression] Correctness with -ftrapv depended on libcall notes
--- Comment #3 from bonzini at gnu dot org 2008-05-31 09:18 --- Well, regression is a big word because -ftrapv is broken in general. I guess the RM will lower the priority. -- bonzini at gnu dot org changed: What|Removed |Added Status|NEW |SUSPENDED Known to fail||4.4.0 Known to work||4.3.1 Summary|Correctness with -ftrapv|[4.4 Regression] Correctness |depends on libcall notes|with -ftrapv depended on ||libcall notes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35412
[Bug tree-optimization/36400] New: points-to results wrong
In
struct barstruct { char const* some_string; };
void changethepointer(struct barstruct***);
void baz()
{
struct barstruct bar1;
struct barstruct* barptr = &bar1;
struct barstruct** barptr2 = &barptr;
changethepointer(&barptr2);
barptr->some_string = "Everything OK";
}
the store to barptr->some_string is removed because points-to figures that
barptr points to bar1, which it doesn't necessarily do after the call to
changethepointer - it should point to anything.
--
Summary: points-to results wrong
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Keywords: wrong-code, alias
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36400
[Bug tree-optimization/36387] points-to variables not transitively clobbered
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-31 10:23 --- Wrong points-to result is split out to PR36400. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36387
[Bug tree-optimization/36400] points-to results wrong
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-31 10:33 --- The patch from http://gcc.gnu.org/ml/gcc-patches/2008-05/msg02060.html seems to work. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-31 10:33:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36400
[Bug target/36399] FSF GCC ABI bug on darwin/x86-32
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-31 10:58 --- As apple implements the darwin ABI in the FSF gcc it's apples turn to fix it. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c |target GCC target triplet||i?86-apple-darwin Keywords||ABI, wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36399
[Bug fortran/36322] ICE with PROCEDURE using a complicated interface
--- Comment #1 from janus at gcc dot gnu dot org 2008-05-31 11:03 --- I tried to reduce this as far as I could, and ended up with: subroutine sub(x) abstract interface character function abs_fun() end function end interface procedure(abs_fun):: x end subroutine So, contrary to my expectations, this ICE does not seem to be about ISO_C_BINDING, nor assumed-shape arrays. Instead it seems to be connected to CHARACTER and DUMMY, since it only happens if x is a dummy argument, and abs_fun is character-valued. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36322
[Bug fortran/36322] ICE with PROCEDURE using a complicated interface
--- Comment #2 from janus at gcc dot gnu dot org 2008-05-31 11:18 --- valgrind gives the following backtrace: ==19018== Invalid read of size 4 ==19018==at 0x80E71EA: gfc_conv_const_charlen (trans-const.c:179) ==19018==by 0x811B61A: gfc_get_function_type (trans-types.c:2077) ==19018==by 0x80EB30D: build_function_decl (trans-decl.c:1263) ==19018==by 0x80EDEB6: gfc_create_function_decl (trans-decl.c:1820) ==19018==by 0x80EF80C: gfc_generate_function_code (trans-decl.c:3206) ==19018==by 0x80A44DC: gfc_parse_file (parse.c:3601) ==19018==by 0x80D030C: gfc_be_parse_file (f95-lang.c:259) ==19018==by 0x8372C7D: toplev_main (toplev.c:965) ==19018==by 0x811DE11: main (main.c:35) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36322
[Bug fortran/36322] ICE with PROCEDURE using a complicated interface
--- Comment #3 from janus at gcc dot gnu dot org 2008-05-31 11:45 ---
The fix:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 136234)
+++ gcc/fortran/resolve.c (working copy)
@@ -7751,6 +7751,7 @@ resolve_symbol (gfc_symbol *sym)
{
sym->ts.type = sym->ts.interface->ts.type;
sym->ts.kind = sym->ts.interface->ts.kind;
+ sym->ts.cl = sym->ts.interface->ts.cl;
sym->attr.function = sym->ts.interface->attr.function;
sym->attr.subroutine = sym->ts.interface->attr.subroutine;
copy_formal_args (sym, sym->ts.interface);
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2008-05-28 12:38:21 |2008-05-31 11:45:04
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36322
[Bug middle-end/36262] [4.3 Regression] Extreme memory usage of VRP compared to older versions
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-05-31 13:01 --- Fixed for 4.4.0. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.2.3 |4.2.3 4.4.0 Summary|[4.3/4.4 Regression] Extreme|[4.3 Regression] Extreme |memory usage of VRP compared|memory usage of VRP compared |to older versions |to older versions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36262
[Bug middle-end/36262] [4.3 Regression] Extreme memory usage of VRP compared to older versions
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-05-31 13:01 --- Subject: Bug 36262 Author: rguenth Date: Sat May 31 13:01:10 2008 New Revision: 136237 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136237 Log: 2008-05-31 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/34244 * fold-const.c (tree_expr_nonnegative_warnv_p): Do not ask VRP. (tree_expr_nonzero_warnv_p): Likewise. * tree-vrp.c (vrp_expr_computes_nonnegative): Call ssa_name_nonnegative_p. (vrp_expr_computes_nonzero): Call ssa_name_nonzero_p. (extract_range_from_unary_expr): Use vrp_expr_computes_nonzero, not tree_expr_nonzero_warnv_p. PR tree-optimization/36262 Revert 2007-11-29 Zdenek Dvorak <[EMAIL PROTECTED]> PR tree-optimization/34244 * tree-vrp.c (adjust_range_with_scev): Clear scev cache. (record_numbers_of_iterations): New function. (execute_vrp): Cache the numbers of iterations of loops. * tree-scalar-evolution.c (scev_reset_except_niters): New function. (scev_reset): Use scev_reset_except_niters. * tree-scalar-evolution.h (scev_reset_except_niters): Declare. Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/tree-scalar-evolution.c trunk/gcc/tree-scalar-evolution.h trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36262
[Bug tree-optimization/34244] [4.3 Regression] VRP/SCEV miscompiles Firefox
--- Comment #14 from rguenth at gcc dot gnu dot org 2008-05-31 13:01 --- Subject: Bug 34244 Author: rguenth Date: Sat May 31 13:01:10 2008 New Revision: 136237 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136237 Log: 2008-05-31 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/34244 * fold-const.c (tree_expr_nonnegative_warnv_p): Do not ask VRP. (tree_expr_nonzero_warnv_p): Likewise. * tree-vrp.c (vrp_expr_computes_nonnegative): Call ssa_name_nonnegative_p. (vrp_expr_computes_nonzero): Call ssa_name_nonzero_p. (extract_range_from_unary_expr): Use vrp_expr_computes_nonzero, not tree_expr_nonzero_warnv_p. PR tree-optimization/36262 Revert 2007-11-29 Zdenek Dvorak <[EMAIL PROTECTED]> PR tree-optimization/34244 * tree-vrp.c (adjust_range_with_scev): Clear scev cache. (record_numbers_of_iterations): New function. (execute_vrp): Cache the numbers of iterations of loops. * tree-scalar-evolution.c (scev_reset_except_niters): New function. (scev_reset): Use scev_reset_except_niters. * tree-scalar-evolution.h (scev_reset_except_niters): Declare. Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/tree-scalar-evolution.c trunk/gcc/tree-scalar-evolution.h trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34244
[Bug tree-optimization/36401] New: [4.4 Regression] 164.gzip miscompares
At -O3 -funroll-loops -fpeel-loops -ffast-math revision 136224, last known good 136189. -- Summary: [4.4 Regression] 164.gzip miscompares Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org GCC target triplet: x64_86-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36401
[Bug tree-optimization/36401] [4.4 Regression] 164.gzip miscompares
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-31 13:56 --- Two likely changes: +2008-05-30 Richard Guenther <[EMAIL PROTECTED]> + + * builtins.c (build_string_literal): Avoid generating + a non-gimple_val result. +2008-05-30 Steven Bosscher <[EMAIL PROTECTED]> + + * optabs.c (maybe_encapsulate_block): Remove. + (emit_libcall_block): Adjust accordingly. + * optabs.h (maybe_encapsulate_block): Remove prototype. + + * config/rs6000/rs6000.c (rs6000_legitimize_tls_address): + Don't use maybe_encapsulate_block. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||stevenb dot gcc at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36401
[Bug c/36359] [Regression] compile error in linux-kernel 2.6.26-rc4 with -O2
--- Comment #5 from mt-ml at gmx dot de 2008-05-31 13:58 --- Created an attachment (id=15707) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15707&action=view) preprocessed sources of urb.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36359
[Bug c/36359] [Regression] compile error in linux-kernel 2.6.26-rc4 with -O2
--- Comment #6 from mt-ml at gmx dot de 2008-05-31 13:59 --- I was able to find the function in which the error occurs. It's usb_submit_urb in drivers/usb/core/urb.c I think. The command: $ gcc -c -save-temps drivers/usb/core/urb.c -I include executed in the linux-kernel main directory gives me the attached urb.i. Is that what you need? Executing this gives me the following errors, though: In file included from /home/mirco/source/kernel/linux.git/include/asm/bitops.h:421, from /home/mirco/source/kernel/linux.git/include/linux/bitops.h:17, from /home/mirco/source/kernel/linux.git/include/linux/bitmap.h:7, from /home/mirco/source/kernel/linux.git/include/linux/cpumask.h:90, from /home/mirco/source/kernel/linux.git/include/asm/processor.h:25, from /home/mirco/source/kernel/linux.git/include/linux/prefetch.h:14, from /home/mirco/source/kernel/linux.git/include/linux/list.h:6, from /home/mirco/source/kernel/linux.git/include/linux/module.h:9, from urb.c:1: /home/mirco/source/kernel/linux.git/include/asm-generic/bitops/fls64.h:33:2: error: #error BITS_PER_LONG not 32 or 64 In file included from /home/mirco/source/kernel/linux.git/include/linux/prefetch.h:14, from /home/mirco/source/kernel/linux.git/include/linux/list.h:6, from /home/mirco/source/kernel/linux.git/include/linux/module.h:9, from urb.c:1: /home/mirco/source/kernel/linux.git/include/asm/processor.h:152:1: warning: "cache_line_size" redefined In file included from /home/mirco/source/kernel/linux.git/include/asm/pda.h:7, from /home/mirco/source/kernel/linux.git/include/asm/current_64.h:7, from /home/mirco/source/kernel/linux.git/include/asm/current.h:4, from /home/mirco/source/kernel/linux.git/include/asm/processor.h:15, from /home/mirco/source/kernel/linux.git/include/linux/prefetch.h:14, from /home/mirco/source/kernel/linux.git/include/linux/list.h:6, from /home/mirco/source/kernel/linux.git/include/linux/module.h:9, from urb.c:1: /home/mirco/source/kernel/linux.git/include/linux/cache.h:64:1: warning: this is the location of the previous definition In file included from /home/mirco/source/kernel/linux.git/include/linux/module.h:21, from urb.c:1: /home/mirco/source/kernel/linux.git/include/asm/module.h:70:2: error: #error unknown processor family -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36359
[Bug c/36359] [Regression] compile error in linux-kernel 2.6.26-rc4 with -O2
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-05-31 15:45 --- Looking at http://www.readcode.org/code/linux-2.6.20/include/linux/log2.h it seems that either the argument to ilog _is_ zero or the compiler thinks so. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-31 15:45:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36359
[Bug c/36402] New: -0x80000000 (INT_MIN) erroneously treated as unsigned
GCC seems to treat the 32-bit integer constant -0x8000 (INT_MIN) as an
unsigned value, when it should be signed. (I don't think this is a duplicate
of bug 25329, since I'm not trying to negate the constant.) For example:
int a = 1;
int foo(void)
{
return -0x8000 < a;
}
improperly returns 0, even though -0x8000 is less than any positive value.
>From the assembly output, it seems as though GCC is treating -0x8000 as an
unsigned value (using the unsigned "seta" instruction to interpret the
comparison result):
movla, %eax
cmpl$-2147483648, %eax
seta%al
Changing the comparison to:
return (int)-0x8000 < a; // Cast to signed
succeeds, as expected (interestingly using "setne" rather than "setg", though
certainly either works).
--
Summary: -0x8000 (INT_MIN) erroneously treated as unsigned
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcczilla at achurch dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36402
[Bug c/36402] -0x80000000 (INT_MIN) erroneously treated as unsigned
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2008-05-31 19:50 --- > GCC seems to treat the 32-bit integer constant -0x8000 (INT_MIN) as an > unsigned value, when it should be signed. Incorrect. -0x8000 is not an integer constant, it's the negation of the integer constant 0x8000, which is unsigned (C99 6.4.4.1). -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36402
[Bug libstdc++/36338] heap_sort effectively hangs with -D_GLIBCXX_DEBUG
--- Comment #2 from paolo at gcc dot gnu dot org 2008-05-31 23:01 --- Subject: Bug 36338 Author: paolo Date: Sat May 31 23:01:09 2008 New Revision: 136242 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136242 Log: 2008-05-31 Paolo Carlini <[EMAIL PROTECTED]> Chris Jefferson <[EMAIL PROTECTED]> PR libstdc++/36338 * include/bits/stl_heap.h (sort_heap): Use __pop_heap directly. (pop_heap): Slightly tweak. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_heap.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36338
[Bug libstdc++/36338] heap_sort effectively hangs with -D_GLIBCXX_DEBUG
--- Comment #3 from paolo dot carlini at oracle dot com 2008-05-31 23:02 --- Fixed for 4.4.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36338
[Bug fortran/36403] New: [4.4 Regression] Some fortran tests using eoshift fail on SH
Several fortran tests using eoshift fail for SH. The typical one is
gfortran.dg/char_length_8.f90 -O0 execution test
and its reduced testcase is
CHARACTER(LEN=3), DIMENSION(10) :: Z
call test_eoshift
contains
subroutine test_eoshift
CHARACTER(LEN=1), DIMENSION(10) :: chk
chk(1:8) = "5"
chk(9:10) = " "
Z(:)="456"
if (any (EOSHIFT(Z(:)(2:2),2) .ne. chk)) call abort
END subroutine
END
It seems that a variable on stack is clobbered by the call of
_gfortran_eoshift0_4_char and it's resulting a segfault.
In .003t.original tree dump, that call
_gfortran_eoshift0_4_char (&atmp.8, 1, &atmp.4, &C.651, 0B, 0B, 1);
has 7 arguments, but it doesn't match with the prototype of
void\
eoshift0_##N##_char (gfc_array_char *ret, \
GFC_INTEGER_4 ret_length __attribute__((unused)), \
const gfc_array_char *array, \
const GFC_INTEGER_##N *pshift, \
const char *pbound,\
const GFC_INTEGER_##N *pdim, \
GFC_INTEGER_4 array_length,\
GFC_INTEGER_4 bound_length __attribute__((unused)))\
{ \
eoshift0 (ret, array, *pshift, pbound, pdim ? *pdim : 1, \
array_length, " ", 1); \
} \
in libgfortran/intrinsics/eoshift0.c which has 8 arguments.
Then the caller gives the stack area only for 7 arguments, but
the callee assumes the stack area is reserved for 8 arguments
and uses them for temporary purpose in the failing case.
--
Summary: [4.4 Regression] Some fortran tests using eoshift fail
on SH
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kkojima at gcc dot gnu dot org
GCC target triplet: sh4-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36403
[Bug testsuite/36285] gcc.dg/compat/struct-by-value-xxx improper test for AVR target
--- Comment #1 from hutchinsonandy at aim dot com 2008-06-01 01:02 ---
I have reduced number of failures slightly by setting higher optimisation and
skipping complex int using
set COMPAT_SKIPS [list {VA} {COMPLEX_INT}]
set COMPAT_OPTIONS [list [list {-Os -mcall-prologues} {-Os -mcall-prologues}]]
But complex float, double and long double are not avoidable and taking way too
much code size to link.
Additionally, there appears to be no way of Skipping these test or even marking
xfail for the link/run stages.
--
hutchinsonandy at aim dot com changed:
What|Removed |Added
CC||janis187 at us dot ibm dot
||com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36285
[Bug target/27386] AVR: wrong code generated when passing three uint64_t arguments to function
--- Comment #13 from hutchinsonandy at aim dot com 2008-06-01 02:40 ---
expr.c appears all messed up on emit_single_push_insn.
This bad code gets executed when there is no push instruction available.
As well as getting address of the mem created completely wrong, it does not
account for any offset between SP and Top/Bottom of Stack aka
STACK_POINTER_OFFSET
Any comment before I try and fix this mess?
First example, ironically without the warning mentioned in latter code.
else if (FUNCTION_ARG_PADDING (mode, type) == downward)
{
unsigned padding_size = rounded_size - GET_MODE_SIZE (mode);
HOST_WIDE_INT offset;
emit_move_insn (stack_pointer_rtx,
expand_binop (Pmode,
#ifdef STACK_GROWS_DOWNWARD
sub_optab,
#else
add_optab,
#endif
stack_pointer_rtx,
GEN_INT (rounded_size),
NULL_RTX, 0, OPTAB_LIB_WIDEN));
offset = (HOST_WIDE_INT) padding_size;
#ifdef STACK_GROWS_DOWNWARD
if (STACK_PUSH_CODE == POST_DEC)
/* We have already decremented the stack pointer, so get the
previous value. */
///NEXT LINE IS WRONG We are pointing just below value so we need SP +
STACK_POINTER_OFFSET
offset += (HOST_WIDE_INT) rounded_size;
//For PRE_DEC we already point directly to mem so code OK
#else
if (STACK_PUSH_CODE == POST_INC)
/* We have already incremented the stack pointer, so get the
previous value. */
//NEXT LINE IS CORRECT
offset -= (HOST_WIDE_INT) rounded_size;
//For PRE_INC we now add STACK_POINTER_OFFSET or SP will be one lower than mem
address
#endif
dest_addr = gen_rtx_PLUS (Pmode, stack_pointer_rtx, GEN_INT (offset));
}
else
The rest of code is even worse!
--
hutchinsonandy at aim dot com changed:
What|Removed |Added
CC||hutchinsonandy at aim dot
||com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27386
[Bug c/36402] -0x80000000 (INT_MIN) erroneously treated as unsigned
--- Comment #2 from gcczilla at achurch dot org 2008-06-01 04:17 --- Fair enough, but GCC's documentation explicitly says (gcc.info section 4.5): * `Whether signed integer types are represented using sign and magnitude, two's complement, or one's complement, and whether the extraordinary value is a trap representation or an ordinary value (C99 6.2.6.2).' GCC supports only two's complement integer types, and all bit patterns are ordinary values. Given that, I think a typical user would assume (as I have) that GCC would treat -0x8000 as the signed value -2^31; otherwise there would seem to be no way to write a single constant to represent that valid value. So I'm going to have to argue that this is still a bug, whether in the documentation or in the compiler itself. -- gcczilla at achurch dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36402
