[Bug libstdc++/36505] New: C++ inludes do not work
I have upgraded from gcc 4.2.2 to gcc 4.3.1 and it seems like the install
procedure does not work. When compiling the simple program:
#include
int main()
{
return 1;
}
I get the following output:
mises syde/MAIN/test $ gcc -v -save-temps gcc431_test.cc
[12 Jun
10:46]
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /home/pa01/ws/syde/MAIN/ext/src/gcc-4.3.1/configure
--prefix=/home/pa01/ws/syde/MAIN/ext
Thread model: posix
gcc version 4.3.1 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic'
/home/pa01/ws/syde/MAIN/ext/libexec/gcc/i686-pc-linux-gnu/4.3.1/cc1plus -E
-quiet -v -D_GNU_SOURCE gcc431_test.cc -mtune=generic -fpch-preprocess -o
gcc431_test.ii
ignoring duplicate directory "/usr/local/include"
ignoring duplicate directory "/home/pa01/ws/syde/MAIN/ext/include"
ignoring nonexistent directory
"/home/pa01/ws/syde/MAIN/ext/lib/gcc/i686-pc-linux-gnu/4.3.1/../../../../i686-pc-linux-gnu/include"
ignoring duplicate directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
/home/pa01/ws/syde/MAIN/ext/include
/usr/local/include
/usr/include
/usr/X11/include
/home/pa01/ws/syde/MAIN/ext/lib/gcc/i686-pc-linux-gnu/4.3.1/../../../../include/c++/4.3.1
/home/pa01/ws/syde/MAIN/ext/lib/gcc/i686-pc-linux-gnu/4.3.1/../../../../include/c++/4.3.1/i686-pc-linux-gnu
/home/pa01/ws/syde/MAIN/ext/lib/gcc/i686-pc-linux-gnu/4.3.1/../../../../include/c++/4.3.1/backward
/home/pa01/ws/syde/MAIN/ext/lib/gcc/i686-pc-linux-gnu/4.3.1/include
/home/pa01/ws/syde/MAIN/ext/lib/gcc/i686-pc-linux-gnu/4.3.1/include-fixed
End of search list.
In file included from gcc431_test.cc:8:
/home/pa01/ws/syde/MAIN/ext/lib/gcc/i686-pc-linux-gnu/4.3.1/../../../../include/c++/4.3.1/cstdlib:73:25:
error: stdlib.h: No such file or directory
When checking my install the directory /i686-pc-linux-gnu/include is
missing.
gcc431_test.ii
# 1 "gcc431_test.cc"
# 1 ""
# 1 ""
# 1 "gcc431_test.cc"
# 1
"/home/pa01/ws/syde/MAIN/ext/lib/gcc/i686-pc-linux-gnu/4.3.1/../../../../include/c++/4.3.1/cstdlib"
1 3
# 46
"/home/pa01/ws/syde/MAIN/ext/lib/gcc/i686-pc-linux-gnu/4.3.1/../../../../include/c++/4.3.1/cstdlib"
3
# 47
"/home/pa01/ws/syde/MAIN/ext/lib/gcc/i686-pc-linux-gnu/4.3.1/../../../../include/c++/4.3.1/cstdlib"
3
# 1
"/home/pa01/ws/syde/MAIN/ext/lib/gcc/i686-pc-linux-gnu/4.3.1/../../../../include/c++/4.3.1/i686-pc-linux-gnu/bits/c++config.h"
1 3
# 40
"/home/pa01/ws/syde/MAIN/ext/lib/gcc/i686-pc-linux-gnu/4.3.1/../../../../include/c++/4.3.1/i686-pc-linux-gnu/bits/c++config.h"
3
# 1
"/home/pa01/ws/syde/MAIN/ext/lib/gcc/i686-pc-linux-gnu/4.3.1/../../../../include/c++/4.3.1/i686-pc-linux-gnu/bits/os_defines.h"
1 3
# 44
"/home/pa01/ws/syde/MAIN/ext/lib/gcc/i686-pc-linux-gnu/4.3.1/../../../../include/c++/4.3.1/i686-pc-linux-gnu/bits/os_defines.h"
3
# 1 "/usr/include/features.h" 1 3
# 308 "/usr/include/features.h" 3
# 1 "/usr/include/sys/cdefs.h" 1 3
# 309 "/usr/include/features.h" 2 3
# 331 "/usr/include/features.h" 3
# 1 "/usr/include/gnu/stubs.h" 1 3
# 332 "/usr/include/features.h" 2 3
# 45
"/home/pa01/ws/syde/MAIN/ext/lib/gcc/i686-pc-linux-gnu/4.3.1/../../../../include/c++/4.3.1/i686-pc-linux-gnu/bits/os_defines.h"
2 3
# 41
"/home/pa01/ws/syde/MAIN/ext/lib/gcc/i686-pc-linux-gnu/4.3.1/../../../../include/c++/4.3.1/i686-pc-linux-gnu/bits/c++config.h"
2 3
# 1
"/home/pa01/ws/syde/MAIN/ext/lib/gcc/i686-pc-linux-gnu/4.3.1/../../../../include/c++/4.3.1/i686-pc-linux-gnu/bits/cpu_defines.h"
1 3
# 44
"/home/pa01/ws/syde/MAIN/ext/lib/gcc/i686-pc-linux-gnu/4.3.1/../../../../include/c++/4.3.1/i686-pc-linux-gnu/bits/c++config.h"
2 3
# 233
"/home/pa01/ws/syde/MAIN/ext/lib/gcc/i686-pc-linux-gnu/4.3.1/../../../../include/c++/4.3.1/i686-pc-linux-gnu/bits/c++config.h"
3
namespace std __attribute__ ((__visibility__ ("default"))) {
# 245
"/home/pa01/ws/syde/MAIN/ext/lib/gcc/i686-pc-linux-gnu/4.3.1/../../../../include/c++/4.3.1/i686-pc-linux-gnu/bits/c++config.h"
3
}
# 49
"/home/pa01/ws/syde/MAIN/ext/lib/gcc/i686-pc-linux-gnu/4.3.1/../../../../include/c++/4.3.1/cstdlib"
2 3
# 1
"/home/pa01/ws/syde/MAIN/ext/lib/gcc/i686-pc-linux-gnu/4.3.1/../../../../include/c++/4.3.1/cstddef"
1 3
# 45
"/home/pa01/ws/syde/MAIN/ext/lib/gcc/i686-pc-linux-gnu/4.3.1/../../../../include/c++/4.3.1/cstddef"
3
# 46
"/home/pa01/ws/syde/MAIN/ext/lib/gcc/i686-pc-linux-gnu/4.3.1/../../../../include/c++/4.3.1/cstddef"
3
# 1
"/home/pa01/ws/syde/MAIN/ext/lib/gcc/i686-pc-linux-gnu/4.3.1/include/stddef.h"
1 3 4
# 152
"/home/pa01/ws/syde/MAIN/ext/lib/gcc/i686-pc-linux-gnu/4.3.1/include/stddef.h"
3 4
typedef int ptrdiff_t;
# 214
"/home/pa01/ws/syde/MAIN/ext/lib/gcc/i686-pc-linux-gnu/4.3.1/include/stddef.h"
[Bug libstdc++/36505] C++ inludes do not work
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-12 09:11 --- >error: stdlib.h: No such file or directory It should have been in: > /usr/include Which is included in the include path. Are you sure you have the includes installed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36505
[Bug target/36494] Char arrays gets corrupted in avr programs.
--- Comment #5 from martin at kfib dot org 2008-06-12 09:13 --- Never mind, I will do it. I'm a total klutz and I apologize. This is very, very embarrassing. If someone ever have a similar problem, make sure they're not running avr-objcopy with the flag -j .text... -- martin at kfib dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36494
[Bug libstdc++/36505] C++ inludes do not work
--- Comment #2 from pontus dot astrom at csr dot com 2008-06-12 09:16 --- Created an attachment (id=15752) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15752&action=view) Log of the install output. This is a log of "make install" with all references to java installs cut out too keep file within limits. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36505
[Bug target/36503] x86 can use x >> -y for x >> 32-y
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-12 09:25 --- We have the SHIFT_COUNT_TRUNCATED macro for this (though I'm not sure if that says negative values are ok). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2008-06-12 09:25:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36503
[Bug tree-optimization/36504] [4.3/4.4 regression] ICE when building xorg-server with -O3 -fprefetch-loop-arrays
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-12 09:29 --- Program received signal SIGSEGV, Segmentation fault. 0x008be25d in dr_analyze_alias (dr=0x1424660) at /space/rguenther/src/svn/gcc-4_3-branch/gcc/tree-data-ref.c:769 769 if (DECL_P (base)) (gdb) print base $1 = (tree) 0x0 (gdb) call debug_generic_expr (dr->ref) VIEW_CONVERT_EXPR(0) eventually the DR code should be more robust here. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||spop at gcc dot gnu dot org Status|UNCONFIRMED |NEW Component|target |tree-optimization Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail|4.3.1 |4.3.1 4.4.0 Last reconfirmed|-00-00 00:00:00 |2008-06-12 09:29:19 date|| Summary|[4.3 regression] ICE when |[4.3/4.4 regression] ICE |building xorg-server with - |when building xorg-server |O3 -fprefetch-loop-arrays |with -O3 -fprefetch-loop- ||arrays Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36504
[Bug libstdc++/36505] C++ inludes do not work
--- Comment #3 from pontus dot astrom at csr dot com 2008-06-12 09:29 --- Subject: RE: C++ inludes do not work Yes I am completely sure it is there. I just double-checked. In addition, my gcc-4.2.2 install, compiled and installed with identical options, does not have the problem. Best regards, Pontus -Original Message- From: pinskia at gcc dot gnu dot org [mailto:[EMAIL PROTECTED] Sent: den 12 juni 2008 11:12 To: Pontus Åström Subject: [Bug libstdc++/36505] C++ inludes do not work --- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-12 09:11 --- >error: stdlib.h: No such file or directory It should have been in: > /usr/include Which is included in the include path. Are you sure you have the includes installed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36505
[Bug c++/36405] [4.3/4.4 regression] ICE with typeid of member function
--- Comment #4 from jakub at gcc dot gnu dot org 2008-06-12 10:05 --- Created an attachment (id=15754) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15754&action=view) gcc44-pr36405.patch I think the right fix is to ensure the type is complete in all cases but VOID_TYPE. For ARRAY_TYPEs just make sure the element type is complete. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36405
[Bug c++/36408] [4.3/4.4 regression] ICE with statement expression in template
--- Comment #4 from jakub at gcc dot gnu dot org 2008-06-12 10:13 --- Only partly fixed so far - we don't ICE anymore, but no warning is generated. See http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00474.html Doug, any ideas how to differentiate between pack expansion resulting in no tsubsted code and statement expressions containing no statements (possibly nested)? -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||dgregor at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36408
[Bug rtl-optimization/35542] [4.3 Regression] fwprop only propagates one operand
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35542
[Bug target/35860] [4.3/4.4 Regression] [avr] code bloat caused by -fsplit-wide-types
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35860
[Bug c++/36405] [4.3/4.4 regression] ICE with typeid of member function
--- Comment #5 from paolo dot carlini at oracle dot com 2008-06-12 10:19 --- Sure, please go ahead with submitting your patch. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu |dot com |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36405
[Bug middle-end/36506] New: [4.3/4.4 Regression] Broken #pragma omp sections reduction (+:x)
int
main (void)
{
int sum = 0;
#pragma omp parallel
#pragma omp sections reduction (+:sum)
{
#pragma omp section
sum += 2;
#pragma omp section
sum += 2;
#pragma omp section
sum += 2;
}
return sum != 6;
}
ICEs with -fopenmp since
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127121
--
Summary: [4.3/4.4 Regression] Broken #pragma omp sections
reduction (+:x)
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: jakub at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36506
[Bug tree-optimization/36345] TBAA-pruning of points-to sets ineffective
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-12 10:22 --- Subject: Bug 36345 Author: rguenth Date: Thu Jun 12 10:21:45 2008 New Revision: 136695 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136695 Log: 2008-06-12 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/36345 * tree-flow.h (struct ptr_info_def): Align escape_mask, add memory_tag_needed flag. (may_alias_p): Declare. * tree-ssa-alias.c (may_alias_p): Export. (set_initial_properties): Use memory_tag_needed flag. (update_reference_counts): Likewise. (reset_alias_info): Reset memory_tag_needed flag. (create_name_tags): Check memory_tag_needed flag. (dump_points_to_info_for): Dump it. * tree-ssa-structalias.c (struct variable_info): Remove directly_dereferenced flag. (new_var_info): Do not initialize it. (process_constraint_1): Do not set it. (update_alias_info): Set is_dereferenced flag. (set_uids_in_ptset): Use may_alias_p. (set_used_smts): Check memory_tag_needed flag. (find_what_p_points_to): Likewise. Pass is_dereferenced flag. * tree-ssa-alias.c (verify_flow_sensitive_alias_info): Check memory_tag_needed flag. * tree-ssa-alias-warnings.c (dsa_named_for): Try to recover from broken design. * gcc.c-torture/execute/20020619-1.c: Remove broken part of the testcase. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/execute/20020619-1.c trunk/gcc/tree-flow.h trunk/gcc/tree-ssa-alias-warnings.c trunk/gcc/tree-ssa-alias.c trunk/gcc/tree-ssa-structalias.c trunk/gcc/tree-ssa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36345
[Bug tree-optimization/36345] TBAA-pruning of points-to sets ineffective
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-06-12 10:23 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36345
[Bug tree-optimization/36400] points-to results wrong
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-12 10:24 --- The patch that rewrites call-clobbering deals with this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|dberlin at gcc dot gnu dot |rguenth at gcc dot gnu dot |org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36400
[Bug target/36503] x86 can use x >> -y for x >> 32-y
--- Comment #3 from ubizjak at gmail dot com 2008-06-12 10:43 ---
(In reply to comment #2)
> We have the SHIFT_COUNT_TRUNCATED macro for this (though I'm not sure if
> that says negative values are ok).
They are, but there is a comment in the documentation:
-- Macro: SHIFT_COUNT_TRUNCATED
...
However, on some machines, such as the 80386 and the 680x0,
truncation only applies to shift operations and not the (real or
pretended) bit-field operations. Define `SHIFT_COUNT_TRUNCATED'
to be zero on such machines. Instead, add patterns to the `md'
file that include the implied truncation of the shift instructions.
I don't know which "real or pretended" bit-field operations are referred here,
since bt insn also truncate its bit-offset operand. OTOH, {SI,HI,QI}mode shifts
all truncate to 0x1f, not to GET_MODE_SIZE(mode) - 1.
I have a patch:
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 136692)
+++ config/i386/i386.c (working copy)
@@ -24681,6 +24681,22 @@
emit_insn (fn (dest, tmp2, tmp3));
}
+/* Target hook for target_shift_trucnation_mask. */
+static unsigned HOST_WIDE_INT
+ix86_shift_truncation_mask (enum machine_mode mode)
+{
+ if (TARGET_64BIT
+ && mode == DImode)
+return 0x3f;
+
+ if (mode == SImode
+ || mode == HImode
+ || mode == QImode)
+return 0x1f;
+
+ return 0;
+}
+
/* Target hook for scalar_mode_supported_p. */
static bool
ix86_scalar_mode_supported_p (enum machine_mode mode)
@@ -26039,6 +26055,9 @@
#undef TARGET_GIMPLIFY_VA_ARG_EXPR
#define TARGET_GIMPLIFY_VA_ARG_EXPR ix86_gimplify_va_arg
+#undef TARGET_SHIFT_TRUNCATION_MASK
+#define TARGET_SHIFT_TRUNCATION_MASK ix86_shift_truncation_mask
+
#undef TARGET_SCALAR_MODE_SUPPORTED_P
#define TARGET_SCALAR_MODE_SUPPORTED_P ix86_scalar_mode_supported_p
But it does nothing for this optimization. I guess middle-end should be kicked
to handle this optimization.
BTW: Why does ffmpeg need inline asm for this optimization? Following code
snipped also produces expected code:
int shift32 (int i, int n)
{
return i >> (-n);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36503
[Bug middle-end/36506] [4.3/4.4 Regression] Broken #pragma omp sections reduction (+:x)
--- Comment #1 from jakub at gcc dot gnu dot org 2008-06-12 11:04 --- Subject: Bug 36506 Author: jakub Date: Thu Jun 12 11:03:50 2008 New Revision: 136696 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136696 Log: PR middle-end/36506 * omp-low.c (expand_omp_sections): Handle #pragma omp sections with reductions. * testsuite/libgomp.c/reduction-5.c: New test. Added: trunk/libgomp/testsuite/libgomp.c/reduction-5.c Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/libgomp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36506
[Bug middle-end/36506] [4.3/4.4 Regression] Broken #pragma omp sections reduction (+:x)
--- Comment #2 from jakub at gcc dot gnu dot org 2008-06-12 11:08 --- Subject: Bug 36506 Author: jakub Date: Thu Jun 12 11:07:20 2008 New Revision: 136697 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136697 Log: PR middle-end/36506 * omp-low.c (expand_omp_sections): Handle #pragma omp sections with reductions. * testsuite/libgomp.c/reduction-5.c: New test. Added: branches/gcc-4_3-branch/libgomp/testsuite/libgomp.c/reduction-5.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/omp-low.c branches/gcc-4_3-branch/libgomp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36506
[Bug middle-end/36506] [4.3/4.4 Regression] Broken #pragma omp sections reduction (+:x)
--- Comment #3 from jakub at gcc dot gnu dot org 2008-06-12 11:13 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36506
[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc
--- Comment #23 from jakub at gcc dot gnu dot org 2008-06-12 11:17 --- Subject: Bug 36443 Author: jakub Date: Thu Jun 12 11:17:05 2008 New Revision: 136698 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136698 Log: PR testsuite/36443 * gcc.dg/compat/struct-layout-1.exp: Temporarily unset GCC_EXEC_PREFIX from environment when running $HOSTCC. * g++.dg/compat/struct-layout-1.exp: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/compat/struct-layout-1.exp trunk/gcc/testsuite/gcc.dg/compat/struct-layout-1.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc
--- Comment #24 from jakub at gcc dot gnu dot org 2008-06-12 11:39 --- Subject: Bug 36443 Author: jakub Date: Thu Jun 12 11:38:55 2008 New Revision: 136700 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136700 Log: PR testsuite/36443 * gcc.dg/compat/struct-layout-1.exp: Temporarily unset GCC_EXEC_PREFIX from environment when running $HOSTCC. * g++.dg/compat/struct-layout-1.exp: Likewise. Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/g++.dg/compat/struct-layout-1.exp branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/compat/struct-layout-1.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc
--- Comment #25 from jakub at gcc dot gnu dot org 2008-06-12 11:41 --- Committed patch Janis approved as temporary solution. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc
--- Comment #26 from hjl dot tools at gmail dot com 2008-06-12 12:33 --- Don't we need the same workaround in ./objc.dg/gnu-encoding/gnu-encoding.exp:set status [remote_exec host "$HOSTCC $HOSTCFLAGS $generator_cmd"] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug middle-end/36506] [4.3/4.4 Regression] Broken #pragma omp sections reduction (+:x)
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36506
[Bug fortran/36495] libgfortran should be build with FCFLAGS -fimplicit-none
--- Comment #1 from linuxl4 at sohu dot com 2008-06-12 12:50 --- definitely should. a simple wrong typing can lead to an error even without compiler's warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36495
[Bug c/36507] New: [4.3/4.4 Regression] ISO C99 inline semantics doesn't play together with nested functions
int main (void)
{
int i = 2;
inline int bar (void)
{
return i;
}
return bar () - 2;
}
doesn't link with -O0 -std=gnu99, works with -O0 -std=gnu99 -fgnu89-inline,
or -O1 -std=gnu99, or -O0 -std=gnu89. As extern inline for nested function
is rejected, I believe we need to avoid clearing DECL_EXTERNAL for nested
inline functions.
--
Summary: [4.3/4.4 Regression] ISO C99 inline semantics doesn't
play together with nested functions
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36507
[Bug c/36507] [4.3/4.4 Regression] ISO C99 inline semantics doesn't play together with nested functions
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36507
[Bug c/36507] [4.3/4.4 Regression] ISO C99 inline semantics doesn't play together with nested functions
--- Comment #1 from jakub at gcc dot gnu dot org 2008-06-12 13:01 --- I wonder if we shouldn't automatically assume gnu_inline semantics for nested functions (given that extern inline is forbidden in nested contexts and relying on other CUs defining the external definition can't work, as nested functions are inherently static). -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||roland at redhat dot com, ||jsm28 at gcc dot gnu dot org Target Milestone|4.3.2 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36507
[Bug c/36507] [4.3/4.4 Regression] ISO C99 inline semantics doesn't play together with nested functions
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36507
[Bug fortran/36492] incorrect error when compiling
--- Comment #2 from clerman at fuse dot net 2008-06-12 13:11 --- Subject: Re: incorrect error when compiling Hello, Thank you for your quick reply. Attached is an archive, bug2.tar. Unpack it and invoke the shell script bug2.sh. You should be able to reproduce the problem. The file bug2.out in the archive shows the results I see. Thank you very much for your attention. Yours truly, Norm Clerman burnus at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #1 from burnus at gcc dot gnu dot org 2008-06-11 05:36 > --- > Can you post a *complete* example? I tried to create a program based on your > single line, but here it simply works. > > I tried both (gfortran -v) 4.4.0 20080609 [trunk revision 136577] > and 4.4.0 20080610 [trunk revision 136611] (my x86_64-unknown-linux-gnu > builds). > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36492 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. --- Comment #3 from clerman at fuse dot net 2008-06-12 13:11 --- Created an attachment (id=15755) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15755&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36492
[Bug c/36507] [4.3/4.4 Regression] ISO C99 inline semantics doesn't play together with nested functions
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-12 13:18 --- I think that makes sense. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2008-06-12 13:18:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36507
[Bug tree-optimization/36400] [4.2/4.3/4.4 Regression] points-to results wrong
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-06-12 13:31 --- Actually this is a regression. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.2.4 4.3.1 4.4.0 Known to work||4.1.2 Priority|P3 |P2 Summary|points-to results wrong |[4.2/4.3/4.4 Regression] ||points-to results wrong Target Milestone|--- |4.2.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36400
[Bug tree-optimization/36387] [4.2/4.3/4.4 Regression] points-to variables not transitively clobbered
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-06-12 13:34 --- This is a regression with -O2 -fno-tree-sra and the testcase from the initial description. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.2.4 4.3.1 4.4.0 Known to work||4.1.2 Priority|P3 |P2 Summary|points-to variables not |[4.2/4.3/4.4 Regression] |transitively clobbered |points-to variables not ||transitively clobbered Target Milestone|--- |4.2.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36387
[Bug middle-end/36506] [4.3/4.4 Regression] Broken #pragma omp sections reduction (+:x)
--- Comment #4 from jakub at gcc dot gnu dot org 2008-06-12 13:50 --- Subject: Bug 36506 Author: jakub Date: Thu Jun 12 13:49:18 2008 New Revision: 136708 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136708 Log: PR middle-end/36506 * omp-low.c (expand_omp_sections): Initialize l2 to avoid bogus warning. Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36506
[Bug c/36507] [4.3/4.4 Regression] ISO C99 inline semantics doesn't play together with nested functions
--- Comment #3 from joseph at codesourcery dot com 2008-06-12 13:54 --- Subject: Re: [4.3/4.4 Regression] ISO C99 inline semantics doesn't play together with nested functions On Thu, 12 Jun 2008, jakub at gcc dot gnu dot org wrote: > I wonder if we shouldn't automatically assume gnu_inline semantics for > nested functions (given that extern inline is forbidden in nested > contexts and relying on other CUs defining the external definition can't > work, as nested functions are inherently static). Seems sane to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36507
[Bug middle-end/36506] [4.3/4.4 Regression] Broken #pragma omp sections reduction (+:x)
--- Comment #5 from jakub at gcc dot gnu dot org 2008-06-12 13:54 --- Subject: Bug 36506 Author: jakub Date: Thu Jun 12 13:53:45 2008 New Revision: 136709 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136709 Log: PR middle-end/36506 * omp-low.c (expand_omp_sections): Initialize l2 to avoid bogus warning. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/omp-low.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36506
[Bug tree-optimization/36508] New: [4.3 Regression] ICE in compute_attic
The attached testcase ICEs on ppc*-linux with -O2 -m32 and -O2 -m64: internal compiler error: in compute_antic, at tree-ssa-pre.c:2020 2019 /* Theoretically possible, but *highly* unlikely. */ 2020 gcc_assert (num_iterations < 50); num_iterations is 50. The code is distilled from staden-io_lib, see http://bugzilla.redhat.com/450889 -- Summary: [4.3 Regression] ICE in compute_attic Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org GCC target triplet: ppc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36508
[Bug tree-optimization/36508] [4.3 Regression] ICE in compute_attic
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36508
[Bug tree-optimization/36508] [4.3 Regression] ICE in compute_attic
--- Comment #1 from jakub at gcc dot gnu dot org 2008-06-12 13:58 --- Created an attachment (id=15756) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15756&action=view) rh450889.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36508
[Bug tree-optimization/36508] [4.3 Regression] ICE in compute_antic
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-12 14:00 --- Probably related to PR36439. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Keywords||compile-time-hog, ice-on- ||valid-code Summary|[4.3 Regression] ICE in |[4.3 Regression] ICE in |compute_attic |compute_antic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36508
[Bug tree-optimization/36508] [4.3 Regression] ICE in compute_antic
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-06-12 14:04 --- It works for me on x86_64. Confirmed on ppc. -- 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-06-12 14:04:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36508
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #110 from pepalogik at seznam dot cz 2008-06-12 14:14 --- I used an old version of GCC documentation so I omitted some new processors with SSE: core2, k8-sse3, opteron-sse3, athlon64-sse3, amdfam10 and barcelona. I think you can use -march=pentium3 for all Intel's CPUs (of course, starting with P3). I'm unsure about AMD. (Maybe you know it better.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug c/36507] [4.3/4.4 Regression] ISO C99 inline semantics doesn't play together with nested functions
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-06-12 13:18:10 |2008-06-12 14:15:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36507
[Bug tree-optimization/36508] [4.3 Regression] ICE in compute_antic
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-06-12 14:15 ---
We get different gimplification on x86_64 and ppc due to branch-cost
differences
(appearantly):
- :;
- D.1604 = i <= 125;
- D.1605 = k <= 11;
- D.1606 = D.1604 && D.1605;
- if (D.1606)
+ :;
+ if (i > 125)
{
- goto ;
+ goto ;
}
else
{
- goto ;
+
}
- :;
+ if (k <= 11)
+{
+ goto ;
+}
+ else
+{
+ goto ;
+}
+ :;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36508
[Bug tree-optimization/36508] [4.3 Regression] ICE in compute_antic
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-06-12 14:20 --- Well not branch cost differences but LOGICAL_OP_NON_SHORT_CIRCUIT is 0. Now LOGICAL_OP_NON_SHORT_CIRCUIT should be 1 on PPC but there needs some expand support for getting the bools using crand/crand instructions (which is faster than branches and such) (this is really only true on some PowerPCs though). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36508
[Bug tree-optimization/36508] [4.3 Regression] ICE in compute_antic
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-06-12 14:21 --- Created an attachment (id=15757) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15757&action=view) testcase that fails on x86_64 as well -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36508
[Bug target/36133] GCC creates suboptimal ASM : Code includes unneeded TST instructions
--- Comment #6 from gunnar at greyhound-data dot com 2008-06-12 14:26 --- Andreas, Could you have a look at this? Cheers Gunnar -- gunnar at greyhound-data dot com changed: What|Removed |Added CC||schwab at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36133
[Bug target/36134] GCC creates suboptimal ASM : usage of ADDA.L where LEA could be used
--- Comment #6 from gunnar at greyhound-data dot com 2008-06-12 14:27 --- Andreas, could you please have a look at this? Cheers Gunnar -- gunnar at greyhound-data dot com changed: What|Removed |Added CC||schwab at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36134
[Bug middle-end/36509] New: [4.4 Regression]: gcc.dg/Wstrict-aliasing-float-ptr-int-obj.c
On Linux/ia32 and Linux/Intel64, revision 136695 gives: FAIL: gcc.dg/Wstrict-aliasing-float-ptr-int-obj.c (test for warnings, line 14) FAIL: gcc.dg/Wstrict-aliasing-float-ptr-int-obj.c (test for warnings, line 16) Revision 136693 is OK. It may be caused by revision 136695: http://gcc.gnu.org/ml/gcc-cvs/2008-06/msg00453.html -- Summary: [4.4 Regression]: gcc.dg/Wstrict-aliasing-float-ptr-int- obj.c Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36509
[Bug target/36135] GCC creates suboptimal ASM : suboptimal Adressing-Modes used
--- Comment #3 from gunnar at greyhound-data dot com 2008-06-12 14:34
---
Andreas,
What is your opinion to this?
GCC 2.9 used to combine the move with increment in the combine step to
something like this:
***
(insn 32 30 33 (set (reg/v:SI 32)
(mem:SI (post_inc:SI (reg/v:SI 34)) 0)) 42 {movsi+1} (nil)
(expr_list:REG_INC (reg/v:SI 34)
(nil)))
***
So problem is that now GCC seems not to be able to do this anymore by itself
With GCC 4.4 the output is:
**
(insn 34 33 35 4 example2.c:11 (set (reg/v:SI 54 [ value ])
(mem:SI (reg/v/f:SI 52 [ src ]) [2 S4 A16])) 37 {*movsi_cf} (nil))
(insn 35 34 36 4 example2.c:12 (set (reg/v:SI 53 [ value2 ])
(mem:SI (plus:SI (reg/v/f:SI 52 [ src ])
(const_int 4 [0x4])) [2 S4 A16])) 37 {*movsi_cf} (nil))
(insn 36 35 38 4 example2.c:5 (set (reg/v/f:SI 52 [ src ])
(plus:SI (reg/v/f:SI 52 [ src ])
(const_int 8 [0x8]))) 133 {*addsi3_5200} (nil))
(insn 38 36 40 4 example2.c:10 (set (reg/v:SI 50 [ size.21 ])
(plus:SI (reg/v:SI 50 [ size.21 ])
(const_int -1 [0x]))) 133 {*addsi3_5200} (nil))
***
Any ideas about this?
Kind regards
Gunnar von Boehn
--
gunnar at greyhound-data dot com changed:
What|Removed |Added
CC||schwab at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36135
[Bug target/36135] GCC creates suboptimal ASM : suboptimal Adressing-Modes used
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-06-12 14:38 ---
This comes down to IV-OPTs not understanding {post,pre}_{dec,inc} at all.
There is another bug about this somewhere I think for arm. PowerPC has the
same issue too ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36135
[Bug tree-optimization/36508] [4.3 Regression] ICE in compute_antic
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-06-12 14:39 ---
The following fails with -O -ftree-pre:
void
foo (short *sp)
{
int k;
k = 1;
#define SP0 *sp++ = 1;
while (1)
{
if (k > 6)
break;
SP0
k++;
}
k = 1;
while (1)
{
if (k > 6)
break;
SP0
k++;
}
#define SP1 SP0 SP0 SP0 SP0 SP0 SP0 SP0 SP0 SP0 SP0 SP0
#define SP2 SP1 SP1 SP1 SP1 SP1 SP1 SP1 SP1 SP1 SP1 SP1
SP2
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36508
[Bug tree-optimization/36508] [4.3 Regression] ICE in compute_antic
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-06-12 14:41 --- I guess the assert is just bogus. But of course maybe Danny wants to have a look? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org GCC target triplet|ppc-linux | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36508
[Bug middle-end/36509] [4.4 Regression]: gcc.dg/Wstrict-aliasing-float-ptr-int-obj.c
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-12 14:46:01 date|| Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36509
[Bug middle-end/36509] [4.4 Regression]: gcc.dg/Wstrict-aliasing-float-ptr-int-obj.c
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-06-12 14:46 --- This is basically PR34386 -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||34386 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36509
[Bug tree-optimization/36508] [4.3 Regression] ICE in compute_antic
--- Comment #9 from dberlin at gcc dot gnu dot org 2008-06-12 14:51 --- Subject: Re: [4.3 Regression] ICE in compute_antic The assert is there because often when people break PRE, it goes into infinite loops due to non-convergence, and eats all memory and CPU very very very quickly. It is much easier to debug the assert and see the assert than have your system become unusable until OOM happens. :) It is bogus in the sense that the number of iterations should be some factor of the loop depth, rather than 50. I'm torn as to whether we should set it to whatever our reasonable maximum of loop depth is, or remove it or comment it out. On Thu, Jun 12, 2008 at 10:41 AM, rguenth at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #8 from rguenth at gcc dot gnu dot org 2008-06-12 14:41 > --- > I guess the assert is just bogus. But of course maybe Danny wants to have a > look? > > > -- > > rguenth at gcc dot gnu dot org changed: > > What|Removed |Added > > CC||dberlin at gcc dot gnu dot > ||org > GCC target triplet|ppc-linux | > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36508 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36508
[Bug tree-optimization/36508] [4.3 Regression] ICE in compute_antic
--- Comment #10 from dberlin at gcc dot gnu dot org 2008-06-12 14:52 --- FWIW, the comment right above the assert has proven to be true. In a few years and releases, this is only the second time anyone has ever hit it :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36508
[Bug target/36510] New: gcc.dg/vect/costmodel/ppc failures
FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-31d.c scan-tree-dump-times vect "vectorization not profitable" 1 FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-31d.c scan-tree-dump-times vect "vectorized 1 loops" 0 FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-68d.c scan-tree-dump-times vect "vectorization not profitable" 1 FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-68d.c scan-tree-dump-times vect "vectorized 1 loops" 0 appear on trunk on powerpc-linux-gnu, and gcc-testresults indicates these have been failing since September 2007. FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-76c.c scan-tree-dump-times vect "vectorized 1 loops" 1 also appears on trunk - this failure appeared more recently, April 2008. -- Summary: gcc.dg/vect/costmodel/ppc failures Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org GCC target triplet: powerpc*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36510
[Bug fortran/36462] KIND argument in INDEX results in wrong code
--- Comment #2 from burnus at gcc dot gnu dot org 2008-06-12 16:16 --- Fixed for INDEX and SCAN, but leaving open as reminder for the following: > Will need auditing other intrinsics that were added a KIND argument in F2003. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36462
[Bug fortran/36462] KIND argument in INDEX results in wrong code
--- Comment #3 from burnus at gcc dot gnu dot org 2008-06-12 16:17 --- Subject: Bug 36462 Author: burnus Date: Thu Jun 12 16:16:39 2008 New Revision: 136712 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136712 Log: 2008-06-12 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/36462 * trans-intrinsic.c (gfc_conv_intrinsic_index_scan_verify): Fix passing of the BACK= argument. 2008-06-12 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/36462 * gfortran.dg/index_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/index_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36462
[Bug target/36503] x86 can use x >> -y for x >> 32-y
--- Comment #4 from astrange at ithinksw dot com 2008-06-12 16:48 --- Maybe it seemed likely to cause a warning - I haven't checked that yet, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36503
[Bug c++/36511] New: ice for legal code with -O2
For the following C++ source code
typedef void * FILE;
FILE *fp;
extern int fprintf (FILE *__restrict __stream, __const char *__restrict
__format, ...);
int
bert(void)
{
const char * fred = "\n";
fprintf( fp, "%s", fred);
return 0;
}
The GNU C++ compiler version 4.4 snapshot 20080606 says
[EMAIL PROTECTED]:~/gcc/20080606/bugs> ../results/bin/g++ -g -O2 bug14.cc
bug14.cc: In function 'int bert()':
bug14.cc:15: internal compiler error: in set_rhs, at tree-ssa-propagate.c:750
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
--
Summary: ice for legal code with -O2
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
GCC host triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36511
[Bug preprocessor/36479] Short buffer in libcpp
--- Comment #8 from hjl at gcc dot gnu dot org 2008-06-12 17:04 --- Subject: Bug 36479 Author: hjl Date: Thu Jun 12 17:03:41 2008 New Revision: 136714 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136714 Log: 2008-06-12 H.J. Lu <[EMAIL PROTECTED]> PR preprocessor/36479 * charset.c (cpp_interpret_string_notranslate): Also set narrow_cset_desc.width. Modified: trunk/libcpp/ChangeLog trunk/libcpp/charset.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36479
[Bug fortran/36495] libgfortran should be build with FCFLAGS -fimplicit-none
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-06-12 18:16 --- (In reply to comment #0) > As PR 36471 shows, building libgfortran's Fortran parts with -fimplicit-none > can help detecting programming errors in the Fortran written parts of > libgfortran. > > I suggest to use such a patch: OK if regression-tested. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36495
[Bug fortran/36341] MATMUL: Bounds check missing (run time & compile time)
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-06-12 18:20 --- This is an instance of PR 34670. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO|34670 | nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-12 18:20:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36341
[Bug bootstrap/36512] New: [4.3.0/4.3.1 regression] relocation overflow
Bootstrap compiler is # gcc -v Using built-in specs. Target: powerpc-apple-darwin8.11.0 Configured with: /usr/local/gcc-4.3.0/src/gcc-4.3.0/configure --enable-languages=c --with-gmp=/usr/local/gmp-4.2.2/G5-Darwin-gcc-4.2.3-abi32 --with-mpfr=/usr/local/mpfr-2.3.1/G5-Darwin-gmp-4.2.2-gcc-4.2.3-abi32 --prefix=/usr/local/gcc-4.3.0/G5-Darwin Thread model: posix gcc version 4.3.0 (GCC) # # env | grep LD LD_LIBRARY_PATH=/usr/local/gcc-4.3.0/G5-Darwin/lib:/usr/local/gmp-4.2.2/G5-Darwin-gcc-4.2.3-abi32/lib:/usr/local/mpfr-2.3.1/G5-Darwin-gmp-4.2.2-gcc-4.2.3-abi32/lib # # /usr/bin/ld -v Apple Computer, Inc. version cctools-622.9~2 During bootstrap of 4.3.1, get /usr/bin/ld: warning multiple definitions of symbol _locale_charset ./../intl/libintl.a(localcharset.o) definition of _locale_charset in section (__TEXT,__text) /usr/lib/libiconv.dylib(localcharset.o) definition of _locale_charset /usr/bin/ld: c-lang.o relocation overflow for relocation entry 221 in section (__TEXT,__text) (displacement too large) /usr/bin/ld: c-lang.o relocation overflow for relocation entry 241 in section (__TEXT,__text) (displacement too large) -- Summary: [4.3.0/4.3.1 regression] relocation overflow Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kate01123 at gmail dot com GCC build triplet: powerpc-apple-darwin8.11.0 GCC host triplet: powerpc-apple-darwin8.11.0 GCC target triplet: powerpc-apple-darwin8.11.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36512
[Bug fortran/36476] ICE: len=* CHARACTER array with separate PARAMETER statement
--- Comment #3 from burnus at gcc dot gnu dot org 2008-06-12 18:32 --- Created an attachment (id=15758) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15758&action=view) Patch; TODO: Create test cases (incl. for kind=4) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36476
[Bug bootstrap/36512] relocation overflow
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-12 18:34 --- I build GCC all the time on powerpc-darwin with no issues. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Summary|[4.3.0/4.3.1 regression]|relocation overflow |relocation overflow | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36512
[Bug preprocessor/36479] Short buffer in libcpp
--- Comment #9 from hjl dot tools at gmail dot com 2008-06-12 18:39 --- Fixed as of revision 136717: http://gcc.gnu.org/ml/gcc-testresults/2008-06/msg00994.html Revision 136712: http://gcc.gnu.org/ml/gcc-testresults/2008-06/msg00993.html FAIL: gcc.dg/pch/save-temps-1.c -O0 -g assembly comparison FAIL: gcc.dg/pch/save-temps-1.c -O0 assembly comparison FAIL: gcc.dg/pch/save-temps-1.c -O1 assembly comparison FAIL: gcc.dg/pch/save-temps-1.c -O2 assembly comparison FAIL: gcc.dg/pch/save-temps-1.c -O3 -fomit-frame-pointer assembly comparison FAIL: gcc.dg/pch/save-temps-1.c -O3 -g assembly comparison FAIL: gcc.dg/pch/save-temps-1.c -Os assembly comparison -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36479
[Bug c/36513] New: -Wlogical-op warns about strchr
Compiling the following code with gcc-4.3 -Wlogical-op -O1
int main ()
{
char *s, t;
strchr (s, t);
}
leads to this warning:
test2.c: In function main:
test2.c:7: warning: logical && with non-zero constant will always evaluate as
true
This is because libc defines strchr to a macro in bits/string.h. It looks to me
like gcc should not warn about optimizations like __builtin_constant_p
optimizations as those are diectly targeted at being optimized out.
--
Summary: -Wlogical-op warns about strchr
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: otte at gnome dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36513
[Bug c/36513] -Wlogical-op warns about strchr
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-12 19:08 --- Well also I think glibc should not need to optimise strchr really and let the compiler do it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36513
[Bug fortran/36476] ICE: len=* CHARACTER array with separate PARAMETER statement
--- Comment #4 from burnus at gcc dot gnu dot org 2008-06-12 19:26 --- > TODO: Create test cases (incl. for kind=4) And with -std=f95: checking for equal string lengths. Also the initialization by an other parameter should be checked. I will work on a test case in the next days. -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-06-09 16:40:32 |2008-06-12 19:26:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36476
[Bug tree-optimization/36508] [4.3 Regression] ICE in compute_antic
--- Comment #11 from rguenther at suse dot de 2008-06-12 20:17 --- Subject: Re: [4.3 Regression] ICE in compute_antic On Thu, 12 Jun 2008, dberlin at gcc dot gnu dot org wrote: > --- Comment #10 from dberlin at gcc dot gnu dot org 2008-06-12 14:52 > --- > FWIW, the comment right above the assert has proven to be true. > In a few years and releases, this is only the second time anyone has ever hit > it :) We can wrap it inside ENABLE_CHECKING to not hit it on released compilers. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36508
[Bug inline-asm/36514] New: inline assembly generates wrong code
The inline assembly I use in one function generates code which the assembler
does not understand (it generates a non existant cpu register).
This is the commandline output:
Using built-in specs.
Target: i586-elf
Configured with: ../gcc-4.3.1/configure --target=i586-elf --prefix=/usr/cross
--
disable-nls --enable-languages=c,c++ --without-headers --with-newlib
Thread model: single
gcc version 4.3.1 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-S' '-O2' '-mtune=pentium'
/usr/cross/libexec/gcc/i586-elf/4.3.1/cc1.exe -E -quiet -v gzip.c
-mtune=pentiu
m -O2 -fpch-preprocess -o gzip.i
ignoring nonexistent directory
"/usr/cross/lib/gcc/i586-elf/4.3.1/../../../../i5
86-elf/sys-include"
ignoring nonexistent directory
"/usr/cross/lib/gcc/i586-elf/4.3.1/../../../../i5
86-elf/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/cross/lib/gcc/i586-elf/4.3.1/include
/usr/cross/lib/gcc/i586-elf/4.3.1/include-fixed
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-S' '-O2' '-mtune=pentium'
/usr/cross/libexec/gcc/i586-elf/4.3.1/cc1.exe -fpreprocessed gzip.i -quiet
-dum
pbase gzip.c -mtune=pentium -auxbase gzip -O2 -version -o gzip.s
GNU C (GCC) version 4.3.1 (i586-elf)
compiled by GNU C version 3.4.4 (cygming special, gdc 0.12, using dmd
0.
125), GMP version 4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 51cdd6038f6ef46be90f22b7598c4d3c
In file included from gzip.c:4:
printf.h:9: warning: conflicting types for built-in function 'printf'
printf.h:11: warning: conflicting types for built-in function 'putchar'
COMPILER_PATH=/usr/cross/libexec/gcc/i586-elf/4.3.1/:/usr/cross/libexec/gcc/i586
-elf/4.3.1/:/usr/cross/libexec/gcc/i586-elf/:/usr/cross/lib/gcc/i586-elf/4.3.1/:
/usr/cross/lib/gcc/i586-elf/:/usr/cross/lib/gcc/i586-elf/4.3.1/../../../../i586-
elf/bin/
LIBRARY_PATH=/usr/cross/lib/gcc/i586-elf/4.3.1/:/usr/cross/lib/gcc/i586-elf/4.3.
1/../../../../i586-elf/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-S' '-O2' '-mtune=pentium'
=
This is the .i file:
# 1 "gzip.c"
# 1 ""
# 1 ""
# 1 "gzip.c"
# 1 "gzip.h" 1
# 1 "typedef.h" 1
typedef unsigned char uint8t;
typedef unsigned short uint16t;
typedef unsigned int uint32t;
typedef unsigned long long int uint64t;
# 5 "gzip.h" 2
# 22 "gzip.h"
#pragma pack(1)
struct gzip_hdr_t {
uint8t id1;
uint8t id2;
uint8t cm;
uint8t flg;
uint32t mtime;
uint8t xfl;
uint8t os;
};
#pragma pack()
uint32t gzipIsGZip(uint8t *file);
uint32t gzipUnzip(uint8t *file, void *dest);
uint8t getNextBit(uint8t *ptr, uint32t *posByte, uint8t *posBit);
# 2 "gzip.c" 2
# 1 "printf.h" 1
# 9 "printf.h"
void printf(char *format, ...);
void printfTrace(char *format, ...);
void putchar(char c);
void putcharTrace(char c);
void itoa(char *str, int num, uint32t base, uint32t flags);
void strreverse(char *begin, char *end);
uint32t getxy();
void setxy(uint32t x, uint32t y);
void scroll_down();
# 4 "gzip.c" 2
uint32t gzipIsGZip(uint8t *file) {
struct gzip_hdr_t *gzip= (struct gzip_hdr_t *)file;
if(gzip->id1 != 0x1f)
return 0;
if(gzip->id2 != 0x8b)
return 0;
if(gzip->cm != 8)
return 0;
return 1;
}
uint32t gzipUnzip(uint8t *file, void *dest) {
struct gzip_hdr_t *gzip= (struct gzip_hdr_t *)file;
uint8t *ptr, final, type, posBit;
uint16t crc16, len, *help;
uint32t posByte;
if(!gzipIsGZip(file))
return 0;
ptr= file + sizeof(struct gzip_hdr_t);
if(gzip->flg & 0x4) {
ptr+= (uint16t)*ptr;
}
if(gzip->flg & 0x8) {
while(*ptr != '\0') {
ptr++;
}
}
if(gzip->flg & 0x10) {
while(*ptr != '\0') {
ptr++;
}
}
if(gzip->flg & 0x2) {
crc16= *ptr;
ptr++;
}
posByte= 0;
posBit= 0;
do {
final= getNextBit(ptr,&posByte,&posBit);
type= (getNextBit(ptr,&posByte,&posBit) << 1) |
getNextBit(ptr,&posByte,&posBit);
if(type == 0x3)
return 0;
if(type == 0x0) {
if(posBit != 0) {
posBit= 0;
posByte++;
}
help= (uint16t *)((uint32t)ptr + posByte);
len= *help;
} else {
if(type == 0x2) {
}
}
}while(!final);
return 1;
}
uint8t getNextBit(uint8t *ptr, uint32t *posByte, uint8t *posBit) {
uint8t *help= ptr + *posByte, res;
asm volatile("testb %2,%1\n\t"
"setne %0"
:"=r"(res)
:"r"(*help),"r"((uint8t)(1 << *posBit)));
if(*posBit == 7) {
*posBit= 0;
(*posByte)++;
} else {
(*posBit)++;
}
return res;
}
--
Summary: inline assembly generates wrong code
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: codemasterhs at yahoo dot de
GCC host triplet: cygwin
GCC target triplet: i586-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36514
[Bug inline-asm/36514] inline assembly generates wrong code
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-12 21:22 --- It is wrong to use "r" constraint here really. *** This bug has been marked as a duplicate of 23242 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36514
[Bug inline-asm/23242] Invalid %sil register chosen when dereferenced pointer used in inline asm with -O0
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-06-12 21:22 --- *** Bug 36514 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||codemasterhs at yahoo dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23242
[Bug bootstrap/33781] [4.3/4.4 Regression] "Arg list too long" building libgcc.a
--- Comment #20 from roger at eyesopen dot com 2008-06-12 21:31 --- Hi Ralf, Thanks for your patch. Sorry for the delay in replying, I needed to check out mainline on my IRIX box and rebuild a baseline, and once that had completed "make -k check", I tried with "--enable-fixed-point" first without, and then with your patch. The good news is that this allows the libgcc build to get further, but unfortunately the bad news is that we die just a little further on with a similar "execvp: /bin/sh: Arg list too long". This second failure is where we run nm on all of the objects and pipe the results through mkmap-flat.awk to create tmp-libgcc.map. This looks to be in the same libgcc/Makefile.in in the libgcc.map rule (when SHLIB_MKMAP is defined). I do like your PR33781.diff patch which moves us in the right direction. Is it possible/safe to apply similar voodoo to the libgcc.map rule? Many thanks again for your help. I've no personal interest in using fixed point arithmetic on the MIPS, but resolving this issue on IRIX helps keep the build machinery portable. If it's not IRIX now, it'll be some other platform with a low MAXARGS limit in the near future. Roger -- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug bootstrap/33781] [4.3/4.4 Regression] "Arg list too long" building libgcc.a
--- Comment #21 from Ralf dot Wildenhues at gmx dot de 2008-06-12 21:46 --- Subject: Re: [4.3/4.4 Regression] "Arg list too long" building libgcc.a * roger at eyesopen dot com wrote on Thu, Jun 12, 2008 at 11:31:02PM CEST: > that we die just a little further on with > a similar "execvp: /bin/sh: Arg list too long". > > This second failure is where we run nm on all of the objects and pipe the > results through mkmap-flat.awk to create tmp-libgcc.map. This should be fixable likewise. I will prepare a patch this weekend. (I can't test it reliably as the only IRIX system I have access to has its command line length limit lifted higher, and thus does not fail.) Cheers, Ralf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug fortran/36515] New: Integer read from stdin yields a value overflow for a valid integer.
Integer read from stdin yields a value overflow for a valid integer. Here's
the example program:
{{{
program int_range
integer*4 smallest
100 format(1i11)
read(5,100) smallest
print 100,smallest
end
}}}
If compiled and invoked as
{{{
echo -2147483648 | ./int_range
}}}
it yields
{{{
Fortran runtime error: Value overflowed during integer read
}}}
but using -2147483647 works. Shouldn't the most negative integer*4 be
-2^(31-1) = -2147483648 and the largest integer*4 be 2^(32-1)-1 = 2147483647?
Just a note, the largest integer works with this code.
--
Summary: Integer read from stdin yields a value overflow for a
valid integer.
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: szeliga at colorado dot edu
GCC build triplet: powerpc-apple-darwin8
GCC host triplet: powerpc-apple-darwin8
GCC target triplet: powerpc-apple-darwin8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36515
[Bug fortran/36515] Integer read from stdin yields a value overflow for a valid integer.
--- Comment #1 from kargl at gcc dot gnu dot org 2008-06-12 22:14 --- Sigh. This has been beaten to death. -2147483648 is a unary minus operating on the operand 2147483648. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36515
[Bug fortran/36515] Integer read from stdin yields a value overflow for a valid integer.
--- Comment #2 from Walter dot Szeliga at Colorado dot EDU 2008-06-12 22:21 --- Subject: Re: Integer read from stdin yields a value overflow for a valid integer. Sorry, I googled the crap out of it, but didn't find that explanation. Maybe this should be in the one of the FAQs. What is the "proper" way to read in -2147483648 the negative number? Thanks, Walter -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36515
[Bug java/35923] gcj: error trying to exec 'ecj1': execvp: No such file or directory
--- Comment #6 from sebasmagri at gmail dot com 2008-06-13 01:28 --- I'm getting the same message on a Gentoo/amd64 box... It's reported on gentoo bugzilla http://bugs.gentoo.org/show_bug.cgi?id=225605 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35923
[Bug fortran/36515] Integer read from stdin yields a value overflow for a valid integer.
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-06-13 03:04 --- There is no "proper" way. Use -2147483647 which is the most negative integer representable in 32 bits. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36515
[Bug fortran/36515] Integer read from stdin yields a value overflow for a valid integer.
--- Comment #4 from Walter dot Szeliga at Colorado dot EDU 2008-06-13 03:09 --- Subject: Re: Integer read from stdin yields a value overflow for a valid integer. OK, thanks. Not that this is something to strive for, but I have some legacy software that works with G77 (ugh). One of the issues with porting to gfortran was reading input files that often contain "the forbidden integer", that's all. Walter -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36515
[Bug fortran/36515] Integer read from stdin yields a value overflow for a valid integer.
--- Comment #5 from kargl at gcc dot gnu dot org 2008-06-13 03:25 --- (In reply to comment #3) > There is no "proper" way. > > Use -2147483647 which is the most negative integer representable in 32 bits. > This isn't necessarily true. :) There are a few options. 1) Add -fno-range-check to the options that are provided to the runtime library. Then in io/read.c (as well as other files), we could change line 397 from if (value > maxv_10) goto overflow; to if (value > maxv_10 && !compile_option.range_check) goto overflow; 2) The other option would be to special case the -huge()-1 case in the runtime library. I haven't looked closely enough to see if it would work, but the above could be changed to /* Catch values larger than huge(). */ if (!negative && value > maxv_10) goto overflow; /* Catch values less than -huge()-1 */ if (negative && value > maxv_10 + PLUS_WHATEVER_IS_NEEDED_HERE) goto overflow; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36515
[Bug fortran/36515] Integer read from stdin yields a value overflow for a valid integer.
--- Comment #6 from kargl at gcc dot gnu dot org 2008-06-13 03:30 --- As much as I hate -huge()-1, I think this needs to be fix in some manner. So, I'm re-opening the bug. Jerry et al, if you feel this should be closed, then please re-close the bug. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36515
[Bug fortran/36515] Integer read from stdin yields a value overflow for a valid integer.
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-06-13 04:19 --- Actually, I was just checking what g77 does and noticed that -fno-range-check did not do the trick with gfortran as I expected, so Steve beat me to the punch. For legacy compatibility with g77 I think we should enable the option. I will take care of it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36515
[Bug fortran/36515] Integer read from stdin yields a value overflow for a valid integer.
-- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-13 04:20:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36515
[Bug c/36516] New: Gcc fails on huge C source files.
Gcc 4.3 crashes on the 38 megabyte file generated with: #!/usr/bin/perl -w print < test.c gcc-4.3 -c test.c Gcc-4.2 was able to handle a file 4 time bigger (4M entries), eating only about 2 gigabytes or RAM. I was not able to confirm that it could survive 6M, because ot the limited ram and trashing swap. Was comfirmed to work wint at least 10M by others. The tests were run on Debian-patched gcc, but were confirmed with vanilla gcc by others. -- Summary: Gcc fails on huge C source files. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: alexey dot zaytsev at gmail dot com GCC build triplet: i486-pc-linux-gnu GCC host triplet: i486-pc-linux-gnu GCC target triplet: i486-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36516
[Bug fortran/36515] Integer read from stdin yields a value overflow for a valid integer.
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-06-13 04:37 --- So people don't understand that in Fortran types are symmetric? Hasn't they been symmetric for 20 years now? How can this be for latency programs really? Maybe gfortran is just the first compiler which enforces this :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36515
[Bug c/36516] Gcc fails on huge C source files.
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-13 04:57 --- This is the same issue as PR 14179. *** This bug has been marked as a duplicate of 14179 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36516
[Bug c++/14179] [4.1/4.2/4.3/4.4 Regression] out of memory while parsing array with many initializers
--- Comment #47 from pinskia at gcc dot gnu dot org 2008-06-13 04:57 --- *** Bug 36516 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||alexey dot zaytsev at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14179
[Bug fortran/36515] Integer read from stdin yields a value overflow for a valid integer.
--- Comment #9 from kargl at gcc dot gnu dot org 2008-06-13 05:31 --- (In reply to comment #8) > So people don't understand that in Fortran types are symmetric? Hasn't they > been symmetric for 20 years now? How can this be for latency programs > really? > Maybe gfortran is just the first compiler which enforces this :). It's more complicated than the above. The standard does not require symmetry in the range of integers. One can maintain (and I'll use integer*1) that -128 is the minimum integer*1 value given the "model number" representation for integer*1. Unfortunately, the parser always sees -128 as a unary minus and an operand of 128. The 128 overflows the range of [-128:127]. Here's where programmers run into problems: program a integer*1 i i = -128 ! Unary minus and overflow of 128 i = - huge(i) - 1 ! (Almost) guaranteed to be legal given base 2. i = iabs(i) ! THIS IS ILLEGAL Fortran. end program a To allow the "i = -128" line of code, gfortran has introduced the -fno-range-check option, and it lets the middle and back end deal with possibly out of range values (ie, -129). Note, you can force gfortran to use a symmetric range for the integers with the -pedantic options. From fortran/arith.c /* See PRs 13490 and 17912, related to integer ranges. The pedantic_min_int exists for range checking when a program is compiled with -pedantic, and reflects the belief that Standard Fortran requires integers to be symmetrical, i.e. every negative integer must have a representable positive absolute value, and vice versa. */ mpz_init (int_info->pedantic_min_int); mpz_neg (int_info->pedantic_min_int, int_info->huge); I was involved in the discussion long ago, and I now think I may have been wrong and the pedantic_min_int stuff should be removed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36515
[Bug fortran/36517] New: Type-spec in array constructor ignored for PARAMETER
Type spec support for constructors was implemented in PR27997, however, it is not honored for the -std=f* checking for PARAMETERs. The following program works with default options, however, using -std=f2003 one gets the follow error message: Error: The CHARACTER elements of the array constructor at (1) must have the same length (1/3) (To compile the first two lines, the patch of PR36476 is needed.) CHARACTER (len=*) MY_STRING(1:3) PARAMETER ( MY_STRING = (/CHARACTER (len=3) :: "AC" , "B", "C" /) ) character(len=*), parameter :: str(2) = [character(len=3):: 'A','cc'] end -- Summary: Type-spec in array constructor ignored for PARAMETER Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36517
