[Bug target/31167] ICE wnen using __int128_t on x86_64
--- Comment #6 from uros at gcc dot gnu dot org 2007-03-15 07:25 --- Subject: Bug 31167 Author: uros Date: Thu Mar 15 07:25:22 2007 New Revision: 122945 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122945 Log: PR target/31167 * config/i386/i386.md (*addti3_1, *addti3_1 splitter): Use x86_64_general_operand as operand[2] predicate. Remove iF from operand constraints and use e constraint instead. (*subti3_1, *subti3_1 splitter): Ditto. (*negti2_1, *negti2_1 splitter): Use nonimmediate_operand as operand[1] predicate. testsuite/ChangeLog PR target/31167 * gcc.target/i386/pr31167.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr31167.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31167
[Bug fortran/31120] ICE with integer_exponentiation_1.f90 and -ffast-math
--- Comment #7 from dominiq at lps dot ens dot fr 2007-03-15 08:24 --- And Dominique, I would appreciate if you could test the patch on ppc-darwin7. So far all the tests passed. I am doing a full regtesting of gfortran, but I do not expect any new failure. Thanks for the fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31120
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #5 from dominiq at lps dot ens dot fr 2007-03-15 08:34 ---
Can you check if the attached patch gives a more reasonable error?
I now get:
failure_v2.c: In function 'main':
failure_v2.c:15: sorry, unimplemented: no way to expand a call to 'cexpi'
but would not it be more natural to get the behavior I see with gcc version
4.2.0 20070221?
/usr/bin/ld: Undefined symbols:
___builtin_cexpi
collect2: ld returned 1 exit status
Now from this, am I right to conclude that TARGET_C99_FUNCTIONS is not set in
my build?
If yes, how does it come that g++ and gfortran use __builtin_cexpi when a code
use
cos(phi) and sin(phi) with -O1:
;; Function int main() (main)
Analyzing Edge Insertions.
int main() ()
{
complex double sincostmp.18;
bb 2:
sincostmp.18 = __builtin_cexpi (IMAGPART_EXPR __builtin_clog (__complex__
(-1.0e+0, 0.0)) * 5.0e-1);
printf (%g %g\n[0], REALPART_EXPR sincostmp.18, IMAGPART_EXPR
sincostmp.18);
return 0;
}
where __builtin_cexpi seems to be used and returning a wrong result, thus
leading to PR30980?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug middle-end/30835] ICE with -O2 -ftree-loop-linear
--- Comment #4 from burnus at gcc dot gnu dot org 2007-03-15 08:47 --- (In reply to comment #3) this issue now seems fixed on trunk for me as well, so I guess this could be closed. Mark FIXED based on this comment and on the fact that it works with gfortran 4.3, 4.2, 4.1. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30835
[Bug fortran/31120] ICE with integer_exponentiation_1.f90 and -ffast-math
--- Comment #8 from dominiq at lps dot ens dot fr 2007-03-15 08:52 --- regtest results: ... Running /Users/dominiq/test/gcc-4.3-20070309/gcc/testsuite/gfortran.dg/dg.exp ... FAIL: gfortran.dg/large_real_kind_2.F90 -O0 execution test ... FAIL: gfortran.dg/large_real_kind_2.F90 -Os execution test FAIL: gfortran.dg/large_real_kind_form_io_2.f90 -O0 execution test ... FAIL: gfortran.dg/large_real_kind_form_io_2.f90 -Os execution test FAIL: gfortran.dg/secnds-1.f -Os execution test Running /Users/dominiq/test/gcc-4.3-20070309/gcc/testsuite/gfortran.dg/gomp/gomp.exp ... ... === gfortran Summary === # of expected passes16445 # of unexpected failures17 # of expected failures 7 # of unsupported tests 58 /sw/lib/gcc4/bin/gfortran version 4.3.0 20070309 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31120
[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
--- Comment #14 from pcarlini at suse dot de 2007-03-15 09:38 --- Thanks Craig for all your additional info, I'll try to make further progress myself over the next days... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-03-15 09:40 ---
Yes, I'll restore 4.2.0 behavior here. Though maybe falling back to a function
call to cexp would be more natural...
The Problem with Fortran and C++ is that they assume a C99 runtime and so they
effectively set TARGET_C99_FUNCTIONS and provide fallback implementations. For
example libgfortran contains
#if !defined(HAVE_CEXP)
#define HAVE_CEXP 1
double complex
cexp (double complex z)
{
double a, b;
double complex v;
a = REALPART (z);
b = IMAGPART (z);
COMPLEX_ASSIGN (v, cos (b), sin (b));
return exp (a) * v;
}
#endif
and C++ simply relies on the target cexp() functioning correctly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-03-15 09:46 --- Now find the file that was miscompiled to produce the differing assembly... (at which point do the dumps start to look different, then exchange affected object files for the stage1 variant and see if the difference vanishes) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #7 from dominiq at lps dot ens dot fr 2007-03-15 10:11 --- Subject: Re: __builtin_cexpi is broken on Darwin Yes, I'll restore 4.2.0 behavior here. Though maybe falling back to a function call to cexp would be more natural... I agree (see below). The Problem with Fortran and C++ is that they assume a C99 runtime and so they effectively set TARGET_C99_FUNCTIONS and provide fallback implementations. For example libgfortran contains ... and C++ simply relies on the target cexp() functioning correctly. As far as I can tell this assumption is correct (see my comment #2), so why the fallback not working properly? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-03-15 10:40 --- I have no idea why it is not working properly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #9 from dominiq at lps dot ens dot fr 2007-03-15 11:33 --- Subject: Re: __builtin_cexpi is broken on Darwin I have no idea why it is not working properly. Who could? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-03-15 11:37 --- Darwin people. Or at least someone with enough knowledge of ppc asm... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug c++/31183] New: ICE in int_cst_value, at tree.c:7684 with -O3 -ftree-loop-linear
cat bug.cc
int buf[256 * 9];
void f() {
for (int i = 0; i 256; ++i) {
for (int j = 0; j 8; ++j) {
buf[j + 1] = 0;
}
}
}
g++ -O3 -ftree-loop-linear bug.cc
bug.cc: In function 'void f()':
bug.cc:2: internal compiler error: in int_cst_value, at tree.c:7684
I'm using SVN revision 122952
--
Summary: ICE in int_cst_value, at tree.c:7684 with -O3 -ftree-
loop-linear
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wouter dot vermaelen at pi dot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31183
[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
--- Comment #15 from pcarlini at suse dot de 2007-03-15 12:05 --- (In reply to comment #13) Exactly which CPP symbol: On this platform, to select the errno function, /usr/include/errno.h requires defined(_REENTRANT) || defined(_TS_ERRNO) || _POSIX_C_SOURCE - 0 = 199506L Actually, I would concentrate on _TS_ERRNO (thread-safe errno, that is?) Strikes me as the most minimal and safe change, we could simply add the define to config/os/solaris/solaris2.7/os_defines.h. Can you try this change? Then, if everything goes well, we have to find out something similar for the other problematic targets... Index: config/os/solaris/solaris2.7/os_defines.h === --- config/os/solaris/solaris2.7/os_defines.h (revision 122953) +++ config/os/solaris/solaris2.7/os_defines.h (working copy) @@ -33,5 +33,8 @@ // System-specific #define, typedefs, corrections, etc, go here. This // file will come before all others. +// See libstdc++/31117 for details +#define _TS_ERRNO + #endif -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
[Bug preprocessor/31182] preprocessor doubles up digits in token pasting
--- Comment #2 from dsb at boyski dot com 2007-03-15 12:42 --- This is because the default behavior is to preprocess in C mode but as I mentioned it happens in assembler mode. If you add the flag '-x assembler-with-cpp' you should see the reported result. My test case was in a file with a .s extension which causes cpp/gcc to infer '-x assembler-with-cpp'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31182
[Bug preprocessor/31182] preprocessor doubles up digits in token pasting
--- Comment #3 from dsb at boyski dot com 2007-03-15 12:44 --- (when I said this I meant to refer to the invalid token warnings) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31182
[Bug fortran/31184] New: gfortran option description wrong.
In the man page for gfortran, the option -fd-lines-as-comments is misspelled as -fd-lines-as-comment (note the missing final s). This can also be seen in the web documentation at page http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gfortran/Fortran-Dialect-Options.html#Fortran-Dialect-Options -- Summary: gfortran option description wrong. Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gustav dot larsson at honeywell-tsi dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31184
[Bug libfortran/30498] Support traceback (backtrace) on errors
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2007-03-15 12:57 --- Commited to 4.3, closing. -- fxcoudert 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=30498
[Bug fortran/30964] optional arguments to random_seed
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-03-15 12:59 --- (In reply to comment #1) I have a patch to permit gfc_check_random_seed to deal with arguments with the optional attribute set. I was waiting on pault's size0/size1 patch to hit the tree to see if it does the right thing. I think it was commited. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30964
[Bug c++/31183] ICE in int_cst_value, at tree.c:7684 with -O3 -ftree-loop-linear
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-15 13:05 --- Seems to work for me. Any details on the architecture you tested on? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31183
[Bug c++/31183] ICE in int_cst_value, at tree.c:7684 with -O3 -ftree-loop-linear
--- Comment #2 from ubizjak at gmail dot com 2007-03-15 13:13 --- (In reply to comment #1) Seems to work for me. Any details on the architecture you tested on? Target: i686-pc-linux-gnu gcc version 4.3.0 20070315 (experimental) g++ -O2 -S -ftree-loop-linear pr31183.cc pr31183.cc: In function âvoid f()â: pr31183.cc:2: internal compiler error: in int_cst_value, at tree.c:7684 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Confirmed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-15 13:13:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31183
[Bug target/31022] [4.1/4.2/4.3 Regression] [SH4] internal compiler error with inline
--- Comment #1 from kkojima at gcc dot gnu dot org 2007-03-15 13:16 ---
I've confirmed that the trunk and 4.2 compilers ice on the testcase
and 4.0 doesn't fail. So this is a 4.1/4.2/4.3 regression.
In the problematic case, sh_adjust_cost takes SET_DEST (PATTERN (dep_insn))
where dep_insn is
(insn:HI 8 7 47 2 (parallel [
(set (reg:SF 2 r2 [orig:160 num ] [160])
(mem/c/i:SF (reg/f:SI 1 r1 [162]) [2 f+0 S4 A32]))
(use (reg/v:PSI 151 ))
(clobber (scratch:SI))
]) 202 {movsf_ie} (nil)
(nil))
and calls reg_overlap_mentioned_p with it as the first argument.
We can't use SET_DEST for parallel patterns directly. Now I'm
testing the patch below on the trunk.
--- ORIG/trunk/gcc/config/sh/sh.c 2007-03-10 16:04:12.0 +0900
+++ LOCAL/trunk/gcc/config/sh/sh.c 2007-03-15 08:43:32.0 +0900
@@ -8966,7 +8966,7 @@ sh_adjust_cost (rtx insn, rtx link ATTRI
by 1 cycle. */
if (get_attr_type (insn) == TYPE_DYN_SHIFT
get_attr_any_int_load (dep_insn) == ANY_INT_LOAD_YES
- reg_overlap_mentioned_p (SET_DEST (PATTERN (dep_insn)),
+ reg_overlap_mentioned_p (SET_DEST (dep_set),
XEXP (SET_SRC (single_set (insn)),
1)))
cost++;
For the 4.1-branch, the patch will be
--- ORIG/gcc-4_1-branch/gcc/config/sh/sh.c 2006-10-23 20:35:45.0
+0900
+++ LOCAL/gcc-4_1-branch/gcc/config/sh/sh.c 2007-03-15 09:06:26.0
+0900
@@ -8477,7 +8477,7 @@ sh_adjust_cost (rtx insn, rtx link ATTRI
else if (TARGET_SH4
get_attr_type (insn) == TYPE_DYN_SHIFT
get_attr_any_int_load (dep_insn) == ANY_INT_LOAD_YES
- reg_overlap_mentioned_p (SET_DEST (PATTERN (dep_insn)),
+ reg_overlap_mentioned_p (SET_DEST (single_set (dep_insn)),
XEXP (SET_SRC (single_set (insn)),
1)))
cost++;
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
CC||kkojima at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to fail||4.1.2 4.2.0 4.3.0
Known to work||4.0.4
Last reconfirmed|-00-00 00:00:00 |2007-03-15 13:16:57
date||
Summary|[SH4] internal compiler |[4.1/4.2/4.3 Regression]
|error with inline |[SH4] internal compiler
||error with inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31022
[Bug bootstrap/29482] libcpp/configure - no usable dependency style found
--- Comment #5 from aschorr at telemetry-investments dot com 2007-03-15 13:22 --- FYI, I had this same problem trying to build gcc-4.1.2 on Solaris 8. After a lot of experimentation, I found that it could be solved by changing my PATH so that any invocations of 'make' will actually result in the execution of gnu make, and not the bundled solaris make. It seems that just running the toplevel 'gmake bootstrap' with gnu make is not sufficient: there are embedded calls to 'make' down below, and you need to have your PATH configured in such a way that these calls to 'make' will end up running gnu make. Once I made this change, I was able to complete 'make bootstrap' with no problems at all. However, for some reason I was unable to chase down, 'make install' still failed with gcc-4.1.2. But this bug must have been fixed shortly after the release of gcc-4.1.2, because I was able to build and install a gcc-4.1.3 prerelease snapshot from 20070312 with no problems at all (given that 'make' is now resolving to gnu make). I hope this helps. Regards, Andy -- aschorr at telemetry-investments dot com changed: What|Removed |Added CC||aschorr at telemetry- ||investments dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29482
[Bug c++/31183] ICE in int_cst_value, at tree.c:7684 with -O3 -ftree-loop-linear
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-03-15 13:40 --- Ok, it's a HWI 32 issue then. The caller should use host_integerp () on the tree before calling int_cst_value. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31183
[Bug c++/31183] ICE in int_cst_value, at tree.c:7684 with -O3 -ftree-loop-linear
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-03-15 13:44 ---
Uh:
static void
gather_interchange_stats (VEC (ddr_p, heap) *dependence_relations,
VEC (data_reference_p, heap) *datarefs,
struct loop *loop,
struct loop *first_loop,
unsigned int *dependence_steps,
unsigned int *nb_deps_not_carried_by_loop,
unsigned int *access_strides)
{
...
(*access_strides) +=
int_cst_value (array_size) * int_cst_value (tstride);
nonono, int_cst_value returns a HOST_WIDE_INT, you cannot store that into
an unsigned int. Also int_cst_value does ICE if array_size's type doesn't
fit a HOST_WIDE_INT. There is host_integerp () to verify if a tree int
fits HOST_WIDE_INT.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||sebastian dot pop at cri dot
||ensmp dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31183
[Bug c++/31185] New: Bus Error in Solaris Sparc
I'm using gcc compiler v3.4.3 to compile our custom product in Solaris Sparc processor. While executing in release mode, i'm receiving Bus Error where as in debug mode i'm receiving signal SIGSECV. I'm assuming that this could be a issue with data alignment issues with sparc processor. Can you please let me know how to handle data alignment issues with gcc compiler in Solaris Sparc processor ? Any help is greatly appreciated.. FYI, This the gcc version, i'm using.. Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs Configured with: /gates/sfw10/builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable-shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) Regards, Kishore. -- Summary: Bus Error in Solaris Sparc Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kkumar dot pdtr at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31185
[Bug c++/31185] Bus Error in Solaris Sparc
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-15 13:59 --- You need to ask your vendor about issues with such old gcc. If you are not actively breaking alignment rules gcc should do fine by default. -- 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=31185
[Bug preprocessor/31186] New: -I/usr/include not taken into account
When C_INCLUDE_PATH is defined and -I/usr/include is used, /usr/include should have the precedence, but examples show that it is not taken into account. vin:~ cat test.c #include mpfr.h vin:~ C_INCLUDE_PATH=/home/vlefevre/include gcc -E -I/usr/include test.c | grep mpfr.h # 1 /home/vlefevre/include/mpfr.h 1 3 [...] vin:~ gcc -E -I/usr/include test.c | grep mpfr.h # 1 /usr/include/mpfr.h 1 3 4 [...] vin:~ C_INCLUDE_PATH=/home/vlefevre/include gcc -E -I/usr/milip-local/stow/mpfr-2.2.0/mpfr/include test.c | grep mpfr.h # 1 /usr/milip-local/stow/mpfr-2.2.0/mpfr/include/mpfr.h 1 [...] The gcc man page says: -isystem dir Search dir for header files, after all directories specified by -I but before the standard system directories. Mark it as a system directory, so that it gets the same special treatment as is applied to the standard system directories. so that in the first case, the search path should be: /usr/include /home/vlefevre/include /usr/include equivalent to: /usr/include /home/vlefevre/include Note: this introduces an inconsistency when both -I/usr/include and -L/usr/lib are used, since the header file is taken from C_INCLUDE_PATH and the library file is taken from /usr/lib. -- Summary: -I/usr/include not taken into account Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vincent at vinc17 dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31186
[Bug c++/31187] New: [4.2 regression] extern declaration of variable in anonymous namespace prevents use of its address as template argument
The following code, which compiles fine on gcc 4.1.2 and I believe is valid,
fails on an up-to-date checkout from the 4.2 branch:
--
class foo { };
namespace
{
extern foo foo1;
foo foo1;
}
template foo *
class bar { };
bar foo1 bar1;
---
giving the error:
test.cc:12: error: 'unnamed::foo1' is not a valid template argument of type
'foo*' because 'unnamed::foo1' does not have external linkage
test.cc:12: error: invalid type in declaration before ';' token
... which I would only expect if foo1 were declared static.
If I remove the line with the extern declaration, the code compiles again on
4.2.
--
Summary: [4.2 regression] extern declaration of variable in
anonymous namespace prevents use of its address as
template argument
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zak at transversal dot com
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31187
[Bug fortran/31188] New: ICE on vector subscript of a parameter array
The following code triggers the gcc_assert (begin-expr_type == EXPR_ARRAY) assertion in find_array_section (in expr.c): module foo_mod implicit none character (len=1), parameter :: letters(2) = (/a,b/) contains subroutine concat(ivec) integer, intent(in) :: ivec(:) write (*,*) a // letters(ivec) end subroutine concat end module foo_mod I'm not sure it should end up in that function, however, and I'm not sure why we end up here. -- Summary: ICE on vector subscript of a parameter array 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: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31188
[Bug fortran/31188] ICE on vector subscript of a parameter array
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.2.0 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-03-15 14:28:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31188
[Bug tree-optimization/31178] VRP can infer a range for b in a b and a b
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-15 14:43 ---
This is blocked by the same fact as PR30317 in that ASSERT_EXPRs can only
assert half-ranges or single valued ranges. This makes the following prototype
not assert [0, prec) but [-INF, prec) instead :(
Index: tree-vrp.c
===
*** tree-vrp.c (revision 122953)
--- tree-vrp.c (working copy)
*** infer_value_range (tree stmt, tree op, e
*** 3113,3118
--- 3113,3134
}
}
+ /* We can assume that the shift argument of a left or right shift
+ is within zero and the type precision of the shifted operand. */
+ if (TREE_CODE (stmt) == GIMPLE_MODIFY_STMT
+(TREE_CODE (GIMPLE_STMT_OPERAND (stmt, 1)) == RSHIFT_EXPR
+ || TREE_CODE (GIMPLE_STMT_OPERAND (stmt, 1)) == LSHIFT_EXPR)
+TREE_OPERAND (GIMPLE_STMT_OPERAND (stmt, 1), 1) == op)
+ {
+ tree lop = TREE_OPERAND (GIMPLE_STMT_OPERAND (stmt, 1), 0);
+ tree lop_type = TREE_TYPE (lop);
+
+ /* Unfortunately we only can infer half-ranges here. */
+ *val_p = build_int_cst (lop_type, TYPE_PRECISION (lop_type) - 1);
+ *comp_code_p = LE_EXPR;
+ return true;
+ }
+
return false;
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||30317
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31178
[Bug tree-optimization/30927] tree-nested creates pointless static chains and trampolines when the callgraph is non-trivial
--- Comment #2 from baldrick at gcc dot gnu dot org 2007-03-15 14:49 --- Created an attachment (id=13208) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13208action=view) Proposed fix Bootstraps with all languages including Ada. Does not introduce any new testsuite failures. I'd appreciate it if the ACT people could pass it through their regression test suite. I don't know if this interacts correctly with OMP because I don't understand OMP. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30927
[Bug tree-optimization/30927] tree-nested creates pointless static chains and trampolines when the callgraph is non-trivial
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-03-15 15:12 --- Bootstraps with all languages including Ada. Does not introduce any new testsuite failures. I'd appreciate it if the ACT people could pass it through their regression test suite. I don't know if this interacts correctly with OMP because I don't understand OMP. What would it buy us over the patch I previously posted? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30927
[Bug tree-optimization/30927] tree-nested creates pointless static chains and trampolines when the callgraph is non-trivial
--- Comment #4 from baldrick at free dot fr 2007-03-15 15:16 --- Subject: Re: tree-nested creates pointless static chains and trampolines when the callgraph is non-trivial Bootstraps with all languages including Ada. Does not introduce any new testsuite failures. I'd appreciate it if the ACT people could pass it through their regression test suite. I don't know if this interacts correctly with OMP because I don't understand OMP. What would it buy us over the patch I previously posted? I didn't receive your previous comment - my bugzilla email settings were wrong. I am now reading your patch - thanks for pointing it out! Ciao, Duncan. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30927
[Bug c++/31185] Bus Error in Solaris Sparc
--- Comment #2 from kkumar dot pdtr at gmail dot com 2007-03-15 15:27 --- (In reply to comment #1) You need to ask your vendor about issues with such old gcc. If you are not actively breaking alignment rules gcc should do fine by default. So does the version 3.4.3 actually has the data alignment issues handled ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31185
[Bug tree-optimization/30927] tree-nested creates pointless static chains and trampolines when the callgraph is non-trivial
--- Comment #5 from baldrick at free dot fr 2007-03-15 15:34 ---
Subject: Re: tree-nested creates pointless static chains and trampolines when
the callgraph is non-trivial
Bootstraps with all languages including Ada. Does not introduce any new
testsuite failures. I'd appreciate it if the ACT people could pass it
through their regression test suite. I don't know if this interacts
correctly with OMP because I don't understand OMP.
What would it buy us over the patch I previously posted?
If I understand right the two patches do different things. Consider
the following example:
void X(void) {
void D(void) { D(); };
D();
}
The nested function is reachable, so presumably your patch doesn't
change the behaviour of tree-nested in this case, i.e. D gets a
static chain even though it doesn't need one. My patch makes sure
that D doesn't get a static chain. It doesn't try to do anything
about unreachable functions. In fact I noticed that unreachable
functions can generate a pointless nonlocal frame structure, but
decided not to attempt a fix because it seemed much more complicated
to do!
By the way, I see that you added a hash table for going from the
context to the nesting_info. I was too lazy to do that, instead
I do a linear list walk to find it. Do you think it matters?
Ciao,
Duncan.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30927
[Bug preprocessor/31186] -I/usr/include not taken into account
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-15 15:48 --- I don't think this is a bug, you need to read the other part of the document which says if you supply -I DEFAULT_DIR, it is ignored. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31186
[Bug c++/31187] [4.2/4.3 regression] extern declaration of variable in anonymous namespace prevents use of its address as template argument
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org, mmitchel at gcc dot gnu ||dot org Severity|normal |blocker GCC build triplet|x86_64-pc-linux-gnu | GCC host triplet|x86_64-pc-linux-gnu | Summary|[4.2 regression] extern |[4.2/4.3 regression] extern |declaration of variable in |declaration of variable in |anonymous namespace prevents|anonymous namespace prevents |use of its address as |use of its address as |template argument |template argument Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31187
[Bug c++/31187] [4.2/4.3 regression] extern declaration of variable in anonymous namespace prevents use of its address as template argument
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-15 16:07 --- Confirmed. -- 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-03-15 16:07:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31187
[Bug preprocessor/31182] preprocessor doubles up digits in token pasting
--- Comment #4 from tromey at gcc dot gnu dot org 2007-03-15 16:28 --- I think this is probably the same thing as bug #28709, and most likely fixed by the same patch. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31182
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- Comment #5 from steven at gcc dot gnu dot org 2007-03-15 16:45 --- Just to make sure: Did revision 122820 bootstrap without problems? I.e. is it certain that the patch for r122821 caused the bootstrap comparison failure? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
[Bug preprocessor/31186] -I/usr/include not taken into account
--- Comment #2 from vincent at vinc17 dot org 2007-03-15 16:51 --- (In reply to comment #1) I don't think this is a bug, you need to read the other part of the document which says if you supply -I DEFAULT_DIR, it is ignored. OK, but this isn't very clear, as the description under -isystem says *all* directories specified by -I. I'd replace all by non-ignored. The behavior w.r.t symbolic links to such directories should also be specified. Now, this behavior, if it is intentional, leads to 2 questions: 1. Shouldn't -L have a similar behavior to ensure consistency between library search paths and include search paths? 2. Software is often compiled with configure, make, make install. How can one force the compiler to look in /usr/include /usr/lib first (i.e. override the user's environment)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31186
[Bug fortran/31189] New: Support backtracing for non-library errors
Since PR 30498 is fixed, gfortran supports backtraces. However, they are only displayed for library errors not for, e.g., SEGV or signalling IEEE signals. A support for these can be found embedded in the patch at http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00747.html -- Summary: Support backtracing for non-library errors Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic 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=31189
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- Comment #6 from sje at cup dot hp dot com 2007-03-15 16:52 --- Yes, I did a successful bootstrap on PA with 122820, updated to 122821, did a new bootstrap (after removing the object directory) and got the comparision failure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- Comment #7 from sje at cup dot hp dot com 2007-03-15 16:56 --- Created an attachment (id=13209) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13209action=view) output of stage1 compiler from ivopts -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- Comment #8 from sje at cup dot hp dot com 2007-03-15 16:56 --- Created an attachment (id=13210) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13210action=view) output of stage2 compiler from ivopts -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- Comment #9 from sje at cup dot hp dot com 2007-03-15 16:58 --- I created two attachments, one is the output of ivopts from the stage1 compiler and the other is from the stage2 compiler. This is the first place the two compilers divirge in their output when compiling the test case in comment #3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
[Bug rtl-optimization/31025] [dataflow] Crash in caller-save.c due to x87 math
--- Comment #1 from bonzini at gnu dot org 2007-03-15 17:03 --- Created an attachment (id=13211) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13211action=view) patch that fixes the bug, untested REG_N_CALLS_CROSSED is computed using live, not urec. caller_save uses it to decide what to save (in advance), and urec to decide whether to save something (while scanning the insns). reg 58 is not in live but it is in urec. So, caller_save thinks that reg 58 doesn't have to be saved (using live) and yet it tries to save it (using urec). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31025
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-03-15 17:19 --- Now what is interesting despite of being wrong or not is that we use an index only for the MEM ref: L11:; D.1641_16 = D.1589_4 + -1; D.1642_15 = regexp_3(D)-regexp.oneof.regexps[D.1641_16]; ivtmp___31_21 = (long unsigned int) D.1642_15; # ivtmp___31_1 = PHI ivtmp___31_12(5), ivtmp___31_21(7) # i_18 = PHI i_11(5), i_5(7) L2:; D.1592_10 = MEM[index: ivtmp___31_1]; process_alts_for_forming_states (D.1592_10); i_11 = i_18 + -1; if (i_11 = 0) goto L0; else goto L4; the stage2 compiler then derives a loop trip count based on the size of the regexp-regexp.oneof.regexps[] array it seems (a size of 3 actually) and replaces the induction variable by the MEM index. This doesn't look like a wrong transformation, but I fail to see how this could be different from the stage1 and stage2 compiler. Zdenek, are we supposed to get a index-only mem-ref? -- rguenth 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=31169
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-03-15 17:28 --- Note that either SCEV or ivopts derives a loop trip count of 1 wrongly out of the [1] sized array as it is a tail array. Why this happens in stage2 and not stage1 is of course a mystery if not (what is probably the case) tree-scalar-evolution.c, tree-chrec.c or tree-ssa-loop-ivopts.c is miscompiled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-03-15 17:57 --- It would be interesting to know why tree-ssa-loop-niter.c:array_at_struct_end_p () returns a different value for the stage1/stage2 compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
[Bug middle-end/30364] [4.1 Regression] Wrong variable ranges due to constant folding
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-03-15 18:09 --- Subject: Bug 30364 Author: rguenth Date: Thu Mar 15 18:09:26 2007 New Revision: 122956 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122956 Log: 2007-03-15 Richard Guenther [EMAIL PROTECTED] Backport from mainline 2007-02-28 Richard Guenther [EMAIL PROTECTED] PR middle-end/30364 * fold-const.c (fold_binary): Do not associate expressions with more than one variable for integer types that do not wrap. * gcc.dg/torture/pr30364-1.c: New testcase. * gcc.dg/torture/pr30364-2.c: Likewise. * gcc.dg/torture/pr30364-3.c: Likewise. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/torture/pr30364-1.c - copied unchanged from r122548, branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/torture/pr30364-1.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/torture/pr30364-2.c - copied unchanged from r122548, branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/torture/pr30364-2.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/torture/pr30364-3.c - copied unchanged from r122548, branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/torture/pr30364-3.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/fold-const.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30364
[Bug middle-end/30364] [4.1 Regression] Wrong variable ranges due to constant folding
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-03-15 18:10 --- 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=30364
[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
--- Comment #16 from craig dot lawson at centrify dot com 2007-03-15 18:15 --- (In reply to comment #15) Tried it. Did not work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
--- Comment #17 from pcarlini at suse dot de 2007-03-15 18:27 --- (In reply to comment #16) Tried it. Did not work. Why? -- pcarlini at suse dot de changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
--- Comment #18 from craig dot lawson at centrify dot com 2007-03-15 18:39 --- (In reply to comment #17) Why? Don't know. The file and change were included as expected. Without fully understanding how CPP is evaluating these files, we're shooting in the dark. gcc's -E and -CC options provide only a limited view: they show everything except the # statements evaluated. Is there a way to see exactly what CPP has evaluated? Either an environment variable, an option, or another tool? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
--- Comment #19 from pinskia at gcc dot gnu dot org 2007-03-15 18:40 --- Try adding -dD which causes the preprocessor to also emit all #defines. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
--- Comment #20 from pcarlini at suse dot de 2007-03-15 18:45 ---
Thanks Andrew. I'd like to know what happens if you just compile a small
snippet like:
#define _TS_ERRNO
#include cerrno
int main()
{
return errno;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
[Bug fortran/31190] New: minimum field width list-directed output
A feature of g95 I find convenient is that list-directed output is printed in the minimum amount of space required, making it more readable IMO. For example, for print*,(i,i=1,6) end g95 gives 1 2 3 4 5 6 and gfortran gives 1 2 3 4 5 6 A compiler option that used a minimal width for output for list directed WRITEs would be convenient. I know that for fine control of output I should use explicit formats such as i0 or f0.6, but for quick-and-dirty output it's nice to have list-directed WRITEs give very readable output. Vivek Rao -- Summary: minimum field width list-directed output Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vivekrao4 at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31190
[Bug middle-end/31159] [4.3 regression] ICE in gcc.c-torture/execute/20030323-1.c
--- Comment #2 from hp at gcc dot gnu dot org 2007-03-15 19:04 --- The patch in comment #1 fixes the regression for cris-axis-elf (regtested with revision r122955). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31159
[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
--- Comment #21 from craig dot lawson at centrify dot com 2007-03-15 19:07 --- (In reply to comment #17) Why? OK, now I know why. Reason is that os_defines.h is included after errno.h. Here's the include sequence: c++locale.cc cerrno /usr/include/errno.h-- extern int errno cmath bits/c++config.h os_defines.h-- _TS_ERRNO -- too late I also now know why basic_file.cc gets the errno function: /usr/include/sys/feature_tests.h defines _POSIX_C_SOURCE to 199506L, and that's what errno.h needs. When compiling c++locale.cc, _POSIX_C_SOURCE is also set to the same value, but it happens after errno.h is processed. Thanks Andrew for -dD. That's a good one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
--- Comment #22 from pcarlini at suse dot de 2007-03-15 19:17 --- (In reply to comment #21) (In reply to comment #17) Why? OK, now I know why. Reason is that os_defines.h is included after errno.h. Oh yes, you are totally right. The problem is that cerrno is one of the very few c headers not including bits/c++config.h first. We can easily fix that. I also now know why basic_file.cc gets the errno function: /usr/include/sys/feature_tests.h defines _POSIX_C_SOURCE to 199506L, Ok, but on other targets I don't think we can trust locale.h to always include something similar and enable the thread safe errno. Thus, my preference goes for the plan of adding that define in os_defines.h (+ adjusting cerrno of course). Are you positive about figuring out something similar to _TS_ERRNO for the other targets? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
--- Comment #23 from craig dot lawson at centrify dot com 2007-03-15 19:26 --- (In reply to comment #22) Oh yes, you are totally right. The problem is that cerrno is one of the very few c headers not including bits/c++config.h first. We can easily fix that. Why did cerrno not include bits/c++config.h? Was this intentional? Ok, but on other targets I don't think we can trust locale.h to always include something similar and enable the thread safe errno. I agree. They're all going to be different. But the evidence from basic_file.o indicates that they all do something. Thus, my preference goes for the plan of adding that define in os_defines.h (+ adjusting cerrno of course). Are you positive about figuring out something similar to _TS_ERRNO for the other targets? Instead of _TS_ERRNO and equivalent, how about including bits/c++config.h in cerrno? That appears sufficient for basic_file.o to be compiled correctly, and it appears to work on the platforms I investigated. What do you mean by are you positive? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- Comment #13 from sje at cup dot hp dot com 2007-03-15 19:26 --- With respect to comment #12. It looks like array_at_struct_end_p is returning true in both compilers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
[Bug fortran/31188] ICE on vector subscript of a parameter array
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-15 19:31 ---
If one comments out the if block in gfc_simplify_expr (expr.c):
--
case EXPR_VARIABLE:
/* Only substitute array parameter variables if we are in an
initialization expression, or we want a subsection. */
if (p-symtree-n.sym-attr.flavor == FL_PARAMETER
(gfc_init_expr || p-ref
|| p-symtree-n.sym-value-expr_type != EXPR_ARRAY))
{
if (simplify_parameter_variable (p, type) == FAILURE)
return FAILURE;
break;
}
--
The program works as expected. n.sym-name is ivec. I don't understand why ivec
is FL_PARAMETER and not FL_VARIABLE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31188
[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
--- Comment #24 from pcarlini at suse dot de 2007-03-15 19:37 --- (In reply to comment #23) (In reply to comment #22) Oh yes, you are totally right. The problem is that cerrno is one of the very few c headers not including bits/c++config.h first. We can easily fix that. Why did cerrno not include bits/c++config.h? Was this intentional? No need, so far. Ok, but on other targets I don't think we can trust locale.h to always include something similar and enable the thread safe errno. I agree. They're all going to be different. But the evidence from basic_file.o indicates that they all do something. Probably including clocale very early would fix most in practice, but in general we don't want to have a behavior depending on such order, that's ugly and will fire back sooner or later. Thus, my preference goes for the plan of adding that define in os_defines.h (+ adjusting cerrno of course). Are you positive about figuring out something similar to _TS_ERRNO for the other targets? Instead of _TS_ERRNO and equivalent, how about including bits/c++config.h in cerrno? That appears sufficient for basic_file.o to be compiled correctly, and it appears to work on the platforms I investigated. Oh, that's excellent news, because we have to include bits/c++config.h first in cerrno anyway... But now you make me curious!!! If you look at c++config.h it doesn't appear do much related to this issue. Before doing just that and closing the PR, *please* investigate a bit which specific defines get included by c++config.h and from where! What do you mean by are you positive? Ok, my english is still weak ;) Confident? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
[Bug tree-optimization/30927] tree-nested creates pointless static chains and trampolines when the callgraph is non-trivial
--- Comment #6 from baldrick at gcc dot gnu dot org 2007-03-15 19:45 --- (In reply to comment #1) Try this: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01201.html I don't think you need to consider FDESC_EXPR when constructing the callgraph. It seems only to be used for vtables; and since none of the rest of tree-nested checks for it, I guess either the rest of tree-nested is wrong or it's not needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30927
[Bug c++/31176] reorder class data members to minimize space waste
--- Comment #6 from sebor at roguewave dot com 2007-03-15 19:54 --- (In reply to comment #5) I've checked all three but none of them seems to achieve an optimal layout in a modified template case. Let me attach my test program. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176
[Bug c++/31176] reorder class data members to minimize space waste
--- Comment #7 from sebor at roguewave dot com 2007-03-15 19:55 --- Created an attachment (id=13212) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13212action=view) test case for data member reordering -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-03-15 20:15 --- Subject: Bug 31161 Author: rguenth Date: Thu Mar 15 20:14:49 2007 New Revision: 122958 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122958 Log: 2007-03-15 Richard Guenther [EMAIL PROTECTED] PR middle-end/29719 PR middle-end/31161 * builtins.c (expand_builtin_int_roundingfn): Always fall back to floor/ceil and its variants even if they may be not available. (expand_builtin_cexpi): As a fallback if we don't have builtins for sincos or cexp create a function declaration for cexp and expand to a call to that. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug middle-end/29719] newlib targets ICEs in expand_builtin_int_roundingfn
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-03-15 20:15 --- Subject: Bug 29719 Author: rguenth Date: Thu Mar 15 20:14:49 2007 New Revision: 122958 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122958 Log: 2007-03-15 Richard Guenther [EMAIL PROTECTED] PR middle-end/29719 PR middle-end/31161 * builtins.c (expand_builtin_int_roundingfn): Always fall back to floor/ceil and its variants even if they may be not available. (expand_builtin_cexpi): As a fallback if we don't have builtins for sincos or cexp create a function declaration for cexp and expand to a call to that. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29719
[Bug middle-end/29719] newlib targets ICEs in expand_builtin_int_roundingfn
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-03-15 20:16 --- Fixed. -- rguenth 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=29719
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-03-15 20:17 --- Fixed. (The ICE, the wrong-code is tracked by the other PR) -- rguenth 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=31161
[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
--- Comment #25 from craig dot lawson at centrify dot com 2007-03-15 20:28 --- (In reply to comment #24) Oh, that's excellent news, because we have to include bits/c++config.h first in cerrno anyway... But now you make me curious!!! If you look at c++config.h it doesn't appear do much related to this issue Sorry, that news was too excellent. It's not true. The reason I suggested also including clocale in comment #10 was because I found bits/c++config.h was not enough. I agree that clocale is perhaps a poor choice. I think it needs further investigation as to what would be a good choice. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
[Bug fortran/31188] ICE on vector subscript of a parameter array
--- Comment #3 from pault at gcc dot gnu dot org 2007-03-15 20:36 ---
(In reply to comment #2)
(In reply to comment #1)
The program works as expected. n.sym-name is ivec. I don't understand why
ivec
is FL_PARAMETER and not FL_VARIABLE.
It is not correct to have the line gcc_assert (begin-expr_type == EXPR_ARRAY).
This section was somebody else's (no names!) contribution to this function:)
This expression is not simplifiable and should return on finding that the
vector index is a variabe. This works correctly:
Index: gcc/fortran/expr.c
===
*** gcc/fortran/expr.c (revision 122847)
--- gcc/fortran/expr.c (working copy)
*** find_array_section (gfc_expr *expr, gfc_
*** 1062,1069
if (ref-u.ar.dimen_type[d] == DIMEN_VECTOR) /* Vector subscript. */
{
! gcc_assert (begin);
! gcc_assert (begin-expr_type == EXPR_ARRAY);
gcc_assert (begin-rank == 1);
gcc_assert (begin-shape);
--- 1062,1075
if (ref-u.ar.dimen_type[d] == DIMEN_VECTOR) /* Vector subscript. */
{
! gcc_assert (begin);
!
! if (begin-expr_type == EXPR_ARRAY);
! {
! t = FAILURE;
! goto cleanup;
! }
!
gcc_assert (begin-rank == 1);
gcc_assert (begin-shape);
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31188
[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
--- Comment #26 from pcarlini at suse dot de 2007-03-15 20:44 --- (In reply to comment #25) Sorry, that news was too excellent. It's not true. Ok. The reason I suggested also including clocale in comment #10 was because I found bits/c++config.h was not enough. I agree that clocale is perhaps a poor choice. I think it needs further investigation as to what would be a good choice. No, we are done. We have only to include bits/c++config.h in cerrno, that's fine, no problem, + defining appropriate macros in the various os_defines.h. For Solaris, will be _TS_ERRNO, fine, I was asking whether you can figure out macros appropriate for the various targets you are interested in: basically you should simply open those errno.h and see what is protecting the declaration of the thread-safe variant. I'd like to take care one shoot of as many as possible, instead of fixing only Solaris. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
[Bug tree-optimization/31191] New: [4.3 Regression] 1000% Runtime regression for FreeFEM navier-stokes example
The regression was introduced between r120825 (10s runtime) and r120846 (110s runtime). The obvious candidate is: +2007-01-16 Jan Hubicka [EMAIL PROTECTED] + + * cgraph.h (cgraph_decide_inlining_incrementally): Kill. + * tree-pass.h: Reorder to make IPA passes appear toegher. + (pass_early_inline, pass_inline_parameters, pass_apply_inline): Declare.+ * cgraphunit.c (cgraph_finalize_function): Do not compute inling + parameters, do not call early inliner. + * ipa-inline.c: Update comments. Include tree-flow.h + (cgraph_decide_inlining): Do not compute inlining parameters. + (cgraph_decide_inlining_incrementally): Return TODOs; assume to + be called with function context set up. + (pass_ipa_inline): Remove unreachable functions before pass. + (cgraph_early_inlining): Simplify assuming to be called from the + PM as local pass. + (pass_early_inline): New pass. + (cgraph_gate_ipa_early_inlining): New gate. + (pass_ipa_early_inline): Turn into simple wrapper. + (compute_inline_parameters): New function. + (gate_inline_passes): New gate. + (pass_inline_parameters): New pass. + (apply_inline): Move here from tree-optimize.c + (pass_apply_inline): New pass. + * ipa.c (cgraph_remove_unreachable_nodes): Verify cgraph after + transforming. + * tree-inline.c (optimize_inline_calls): Return TODOs rather than + doing them by hand. + (tree_function_versioning): Do not allocate dummy struct function. + * tree-inline.h (optimize_inline_calls): Update prototype. + * tree-optimize.c (execute_fixup_cfg): Export. + (pass_fixup_cfg): Remove + (tree_rest_of_compilation): Do not apply inlines. + * tree-flow.h (execute_fixup_cfg): Declare. + * Makefile.in (gt-passes.c): New. + * passes.c: Include gt-passes.h + (init_optimization_passes): New passes. + (nnodes, order): New static vars. + (do_per_function_toporder): New function. + (execute_one_pass): Dump current pass here. + (execute_ipa_pass_list): Don't dump current pass here. -- Summary: [4.3 Regression] 1000% Runtime regression for FreeFEM navier-stokes example Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization 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=31191
[Bug tree-optimization/31191] [4.3 Regression] 1000% Runtime regression for FreeFEM navier-stokes example
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-15 20:55 --- http://www.suse.de/~gcctest/c++bench/freefem/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31191
[Bug tree-optimization/31191] [4.3 Regression] 1000% Runtime regression for FreeFEM navier-stokes example
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31191
[Bug fortran/31188] ICE on vector subscript of a parameter array
--- Comment #4 from patchapp at dberlin dot org 2007-03-15 20:55 --- Subject: Bug number PR31188 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-03/msg01045.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31188
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca 2007-03-15 20:59 --- Subject: Re: Bootstrap comparison error at revision 122821g Just to make sure: Did revision 122820 bootstrap without problems? I.e. is it certain that the patch for r122821 caused the bootstrap comparison failure? Yes, I did a regression search. See http://gcc.gnu.org/ml/gcc-testresults/2007-03/msg00674.html for r122820 linux results. I did a full bootstrap of C with r122820 on hppa2.0w-hp-hpux11.11. Didn't run testsuite. The same error occurs on both hpux and linux. Removal of the middle hunk of Richard's change does not fix the problem. I had thought the issue might be related to negative ashifts. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
[Bug fortran/31190] minimum field width list-directed output
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-15 21:03 --- A compiler option that used a minimal width for output for list directed WRITEs would be convenient. There are pros and cons for both. Assume: print *,(huge(0),i=1,6) print*,(i,i=1,6) print*,(i,i=1,6,1) end I would argue that 2147483647 2147483647 2147483647 2147483647 2147483647 2147483647 1 2 3 4 5 6 1 2 3 4 5 6 is more readable than: 2147483647 2147483647 2147483647 2147483647 2147483647 2147483647 1 2 3 4 5 6 1 2 3 4 5 6 Whereas for your example, the second format looks better. On my system, the minimal-width version is used by g95, NAG f95 and sunf95 whereas gfortran and ifort use the wide-spaced version. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31190
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-03-15 21:06
---
Did you try reverting the last hunk:
@@ -1816,7 +1833,8 @@
the new range. */
/* Divisions by zero result in a VARYING value. */
- if (code != MULT_EXPR
+ if ((code != MULT_EXPR
+ code != RSHIFT_EXPR)
(vr0.type == VR_ANTI_RANGE || range_includes_zero_p (vr1)))
{
set_value_range_to_varying (vr);
that should be the only one that increases the amount of optimization done.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- Comment #16 from dave at hiauly1 dot hia dot nrc dot ca 2007-03-15 21:12 --- Subject: Re: Bootstrap comparison error at revision 122821 Did you try reverting the last hunk: No. I'll give it a try shortly. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
--- Comment #27 from craig dot lawson at centrify dot com 2007-03-15 21:17 --- (In reply to comment #26) I understand. I'll collect this information from the systems I have, and then post it here ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
[Bug c/25509] can't voidify __attribute__((warn_unused_result))
--- Comment #15 from fche at redhat dot com 2007-03-15 21:41 --- This still seems fishy to me FWIW: both gcc's implementation and documentation appear to be needlessly aggressive. -- fche at redhat dot com changed: What|Removed |Added CC||fche at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509
[Bug tree-optimization/31191] [4.3 Regression] 1000% Runtime regression for FreeFEM navier-stokes example
--- Comment #2 from hubicka at ucw dot cz 2007-03-15 22:01 --- Subject: Re: New: [4.3 Regression] 1000% Runtime regression for FreeFEM navier-stokes example The regression was introduced between r120825 (10s runtime) and r120846 (110s runtime). The obvious candidate is: +2007-01-16 Jan Hubicka [EMAIL PROTECTED] + + * cgraph.h (cgraph_decide_inlining_incrementally): Kill. + * tree-pass.h: Reorder to make IPA passes appear toegher. + (pass_early_inline, pass_inline_parameters, pass_apply_inline): Declare.+ * cgraphunit.c (cgraph_finalize_function): Do not compute inling + parameters, do not call early inliner. This patch enabled more inlining on many of C++ testcases with overall win on C++ benchmark suite. I know this regression goes away with http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00318.html (see Feb 4 results) From brief analysis I did some time ago, there are number of functions in freefem hitting aliasing grouping limits that didn't hit it before the patch in January, I believe the way it gets solved by simple DSE is the just fact that we never build function with so many memory references to lose track with at first place by elliminating these references early. This seems to be quite common on other C++ testcases too, so I hope we will find way to do this in 4.3. Hopefully Diego will get time to implement the AA before IPA so we can get this without the extra pass. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31191
[Bug c++/24924] front end and preprocessor pedantic_errors settings should agree
--- Comment #3 from manu at gcc dot gnu dot org 2007-03-15 22:24 --- Subject: Bug 24924 Author: manu Date: Thu Mar 15 22:24:42 2007 New Revision: 122961 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122961 Log: 2007-03-15 Manuel Lopez-Ibanez [EMAIL PROTECTED] PR c++/24924 * c-opts.c (c_common_post_options): Handle C++ post-processing here. Set also -pedantic-errors by default for the preprocessor unless -fpermissive is given. cp/ * decl.c (cxx_init_decl_processing): Move command-line options processing to c-opts.c. testsuite/ * g++.dg/cpp/pedantic-errors.C: New. * g++.dg/cpp/permissive.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp/pedantic-errors.C trunk/gcc/testsuite/g++.dg/cpp/permissive.C Modified: trunk/gcc/ChangeLog trunk/gcc/c-opts.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24924
[Bug c++/30891] poor diagnostic with namespace in the function scope
--- Comment #2 from manu at gcc dot gnu dot org 2007-03-15 22:45 --- Subject: Bug 30891 Author: manu Date: Thu Mar 15 22:45:17 2007 New Revision: 122962 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122962 Log: 2007-03-15 Manuel Lopez-Ibanez [EMAIL PROTECTED] PR c++/30891 cp/ * parser.c (cp_parser_statement): If 'namespace' is found, this only can be a namespace alias definition, so parse it now. (cp_parser_namespace_alias_definition): if we find an open brace instead of '=', then this is actually a misplaced namespace definition. testsuite/ * g++.dg/parse/namespace-definition.C: New. Added: trunk/gcc/testsuite/g++.dg/parse/namespace-definition.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30891
[Bug c++/30891] poor diagnostic with namespace in the function scope
--- Comment #3 from manu at gcc dot gnu dot org 2007-03-15 22:47 --- Fixed for GCC 4.3 -- manu 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=30891
[Bug c++/24924] front end and preprocessor pedantic_errors settings should agree
--- Comment #4 from manu at gcc dot gnu dot org 2007-03-15 22:49 --- Fixed for GCC 4.3 -- manu 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=24924
[Bug middle-end/31192] New: functions with __attribute__((externelly_visible)) becomes static when -O -fwhole-program
Problem could be easy reproduced by gcc412 -O1 -fwhole-program -S gcc-4.1.2/gcc/testsuite/gcc.gd/tree-ssa/wholeprogram-2.c. The output file wholeprogram-2.s contains: .file wholeprogram-2.c .text .type externally_visible_function, @function externally_visible_function: pushl %ebp movl%esp, %ebp popl%ebp ret .size externally_visible_function, .-externally_visible_function .ident GCC: (GNU) 4.1.2 .section.note.GNU-stack,,@progbits Can see the line .globl externally_visible_function is absent, so externally_visible_function() become local, but not public. It is may be other solution, but my patch is really simple: diff -Nrcpad gcc-4.1.2-ori/gcc/cgraphunit.c gcc-4.1.2/gcc/cgraphunit.c *** gcc-4.1.2-ori/gcc/cgraphunit.c Fri Jan 5 22:44:10 2007 --- gcc-4.1.2/gcc/cgraphunit.c Fri Mar 16 01:11:24 2007 *** process_function_and_variable_attributes *** 937,942 --- 937,943 if (node-local.finalized) cgraph_mark_needed_node (node); node-externally_visible = true; + node-local.externally_visible = true; } } for (vnode = cgraph_varpool_nodes; vnode != first_var; vnode = vnode-next) -- Summary: functions with __attribute__((externelly_visible)) becomes static when -O -fwhole-program Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: leo at yuriev dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31192
[Bug tree-optimization/30590] [4.1/4.2/4.3 Regression] tree-nrv optimization clobbers return variable
--- Comment #13 from spark at gcc dot gnu dot org 2007-03-15 23:48 --- Subject: Bug 30590 Author: spark Date: Thu Mar 15 23:48:13 2007 New Revision: 122964 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122964 Log: 2007-03-15 Seongbae Park [EMAIL PROTECTED] PR tree-optimization/30590 * tree-nrv.c (tree_nrv): Check for the partial update of the return value. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/tree-nrv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590
[Bug c++/31176] reorder class data members to minimize space waste
--- Comment #8 from sebor at roguewave dot com 2007-03-15 23:51 ---
Some additional comments on the request precipitated by a discussion with the
implementers of another compiler:
The rationale for allowing the attribute on individual members is to provide
fine-grained control over which members the compiler should be allowed to
reorder and which it shouldn't.
For instance, I might want to define an aggregate struct that's optimally laid
out for space except for the first member which needs to be aligned at a
specific boundary:
template class T, class U
struct S __attribute ((aligned (16))) {
size_t refcount;
public: T first __attribute ((reorder));
public: U second __attribute ((reorder));
};
I know I could put T and U in a nested struct but I shouldn't need to do that.
Btw., since today's compiles are allowed to reorder first and second (but not
refcount), I think it's important that the the __attribute ((reorder)) be
considered in conjunction with the access specifier(s) so that when the
compiler implements reordering by default (i.e., w/o the attribute), the layout
of structs with members marked up with the attribute will stay the same even
after removing it. I.e., when gcc 5 comes out in 201X, it would be useful if
struct S below were laid out exactly the same as the struct S above generated
by gcc 4:
template class T, class U
struct S __attribute ((aligned (16)) {
size_t refcount;
public: T first;// no attribute
public: U second; // no attribute
};
Declaring S members with __attribute((reorder)) but without the access
specifiers otherwise necessary to allow the members to be reordered should have
no effect and give a diagnostic (warning or remark):
template class T, class U
struct S __attribute ((aligned (16)) {
size_t refcount;
public:
T first __attribute ((reorder));
U second __attribute ((reorder));
};
Ditto if only first or only second (and not both) had an access specifier.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176
[Bug libfortran/31099] [4.3/4.2 regression] Runtime error on legal code using RECL
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2007-03-16 00:04 --- Reopening - missed part of this. Patch submitted for approval -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31099
gcc bug WRT warning that should not be displayed
Hello
Gcc 3.4.2 on WinXP seems to generate a warning that it should not.
$ gcc -v
Reading specs from C:/msys/mingw/bin/../lib/gcc/mingw32/3.4.2/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as
--host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads
--disable-nls --enable-languages=c,c++,f77,ada,objc,java
--disable-win32-registry --disable-shared --enable-sjlj-exceptions
--enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm
--disable-libgcj-debug --enable-interpreter
--enable-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.2 (mingw-special)
The following C code shows the problem.
int foo() {
long long val1 = 1; /* No warn when val1 is a long long */
int c1 = (
((long long) val1)
((long long)(-2147483647L - 1))
);
long val2 = 1; /* incorrect warn when val2 is a long */
int c2 = (
((long long) val2)
((long long)(-2147483647L - 1))
);
return (c1 || c2);
}
$ gcc -c test.c
test.c: In function `foo':
test.c:11: warning: comparison is always false due to limited range of
data type
Both of the tests in the code above should compile without a warning,
but the second one does not.
thanks much
Mo DeJong
[Bug libfortran/31099] [4.3/4.2 regression] Runtime error on legal code using RECL
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2007-03-16 00:41 --- Subject: Bug 31099 Author: jvdelisle Date: Fri Mar 16 00:41:36 2007 New Revision: 122970 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122970 Log: 2007-03-15 Jerry DeLisle [EMAIL PROTECTED] PR libgfortran/31099 * io/file_pos.c (st_rewind): Don't set bytes_left to zero. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/file_pos.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31099
[Bug c++/30891] poor diagnostic with namespace in the function scope
--- Comment #4 from patchapp at dberlin dot org 2007-03-16 00:45 --- Subject: Bug number PR30891 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-03/msg00698.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30891
[Bug middle-end/31159] [4.3 regression] ICE in gcc.c-torture/execute/20030323-1.c
--- Comment #3 from hp at gcc dot gnu dot org 2007-03-16 00:56 --- There was no PR/31159 on the ChangeLog entry for the committed fix (hi steven), but the patch was sent to gcc-patches and committed a few hours ago, so I'm closing this. -- hp at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31159
