[Bug tree-optimization/21485] [4.0/4.1/4.2/4.3 Regression] codegen regression due to PRE increasing register pressure (missing load PRE really)
--- Comment #21 from pinskia at gcc dot gnu dot org 2007-05-28 07:06
---
The missed load PRE for the testcase below is fixed on the pointer plus banch
as the addition is done in "unsigned int" for both the "++k" and the
array[k+1]. If we change "++k" into "k+=2" and array[k+1] into array[k+2], we
run into another missed PRE issue which can be shown by the following testcase
which we don't optimize currently:
int f(int a, int b)
{
int c = a+2;
int d = c*2;
int e = a*2;
int f = e+2;
return d == f;
}
Which I will file seperately.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
[Bug tree-optimization/32120] New: missed PRE/FRE of a*2+4 and (a+2)*2
A testcase which we should optimize all the way to return true:
int f(int a, int b)
{
int c = a+2;
int d = c*2;
int e = a*2;
int f = e+4;
return d == f;
}
--
Summary: missed PRE/FRE of a*2+4 and (a+2)*2
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32120
[Bug c++/32121] New: [4.1/4.2/4.3 Regression] C++ front-end accepts invalid __label__ declarations
According to our documentation, __label__ declarations have to come first but
the C++ accepts code where they don't which can be shown to be a bit weird with
two labels with the same name.
Here is a testcase which shows that the C++ front-end can accept a case where
we have two labels with the same name:
int f(void)
{
a:;
__label__ a;
int b;
__label__ c;
a:;
c:;
}
This should be rejected, the C front-end rejects this code with the following
errors:
t56.c: In function 'f':
t56.c:4: error: expected expression before '__label__'
t56.c:6: error: expected expression before '__label__'
t56.c:7: error: duplicate label 'a'
t56.c:3: error: previous definition of 'a' was here
This bug was originally found by Chris Lattner.
--
Summary: [4.1/4.2/4.3 Regression] C++ front-end accepts invalid
__label__ declarations
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32121
[Bug c++/32121] [4.1/4.2/4.3 Regression] C++ front-end accepts invalid __label__ declarations
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.0.1 4.1.0 4.2.0 4.3.0 Known to work||3.3.3 Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32121
[Bug c/32122] New: invalid indirect goto accepted
GCC accepts this:
void foo() { goto *1; }
The "Labels as Values" section of the doc states that indirect gotos take "Any
expression of type void *". 1 is not of type void*.
it looks like gcc accepts anything convertible to a pointer type. Trying to
jump to a structure yields:
t.c:15: error: cannot convert to a pointer type
-Chris
--
Summary: invalid indirect goto accepted
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32122
[Bug c++/32121] [4.1/4.2/4.3 Regression] C++ front-end accepts invalid __label__ declarations
--- Comment #1 from sabre at nondot dot org 2007-05-28 07:36 --- isn't this also likely a 3.4 regression? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32121
[Bug rtl-optimization/32123] New: gcc.target/i386/sse2-vec-6.c fails for -mtune=k8
This testcase fails for: gcc -O2 -msse2 -mtune=k8 sse2-vec-6.c Analyzing compilation unit Performing interprocedural optimizations Assembling functions: i386_cpuid_ecx i386_cpuid_edx i386_extended_cpuid_ecx i386_extended_cpuid_edx sse2_test sse2-vec-6.c: In function âsse2_testâ: sse2-vec-6.c:69: internal compiler error: in expand_simple_binop, at optabs.c:1214 Please submit a full bug report, Backtrace: #0 fancy_abort (file=0x8701de4 "../../gcc-svn/trunk/gcc/optabs.c", line=1214, function=0x87022f2 "expand_simple_binop") at ../../gcc-svn/trunk/gcc/diagnostic.c:656 #1 0x082706e7 in expand_simple_binop (mode=V2SFmode, code=VEC_SELECT, op0=0xb795a57c, op1=0xb792c938, target=0xb795c350, unsignedp=1, methods=OPTAB_LIB_WIDEN) at ../../gcc-svn/trunk/gcc/optabs.c:1214 #2 0x081a5edb in force_operand (value=0xb795a5ac, target=0xb795c350) at ../../gcc-svn/trunk/gcc/expr.c:6084 #3 0x086144ab in move_invariant_reg (loop=0xb794ef74, invno=0) at ../../gcc-svn/trunk/gcc/loop-invariant.c:1178 #4 0x0861580d in move_loop_invariants () at ../../gcc-svn/trunk/gcc/loop-invariant.c:1240 #5 0x086137d5 in rtl_move_loop_invariants () at ../../gcc-svn/trunk/gcc/loop-init.c:239 #6 0x08276976 in execute_one_pass (pass=0x87c7280) at ../../gcc-svn/trunk/gcc/passes.c:1067 The problem is that we enter force_operand() with: (gdb) p debug_rtx (value) (vec_select:V2SF (subreg:V4SF (reg:V2DI 91 [ pretmp.201 ]) 0) (parallel [ (const_int 0 [0x0]) (const_int 1 [0x1]) ])) There is no optab for vec_select, and we crash later in assert in expand_simple_optab() on uninitialized optab. The failure is actually the same as in PR26449, however the solution [1] looks rather suspicious to me, as force_operand() won't return NULL, but would crash via expand_simple_optab() for RTXs without optab. [1] http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00313.html -- Summary: gcc.target/i386/sse2-vec-6.c fails for -mtune=k8 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ubizjak at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32123
[Bug c++/32121] [4.1/4.2/4.3 Regression] C++ front-end accepts invalid __label__ declarations
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-28 07:54 --- (In reply to comment #1) > isn't this also likely a 3.4 regression? Yes but I don't have 3.4 to test with right now. Also the summary only includes information about the currently maintained branches. The known to work/fail contain the full information about what versions this worked in and failed in. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32121
[Bug tree-optimization/31756] Doesn't optimize the following (obvious) sequence
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-28 07:58 --- I think the problem now is related to data-ref and I think this might get fixed after I fix PR 32075. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||32075 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31756
[Bug rtl-optimization/32123] gcc.target/i386/sse2-vec-6.c fails for -mtune=k8
--- Comment #1 from ubizjak at gmail dot com 2007-05-28 08:35 ---
Standalone testcase, compile with -O2 -msse2 -mtune=k8:
--cut here--
typedef short __v8hi __attribute__ ((__vector_size__ (16)));
typedef long long __m128i __attribute__ ((__vector_size__ (16)));
void sse2_test (void)
{
union
{
__m128i x;
} val1, res[8], tmp;
short ins[8] = { 8, 5, 9, 4, 2, 6, 1, 20 };
int i;
for (i = 0; i < 8; i++)
{
tmp.x = val1.x;
if (memcmp (&tmp, &res[i], sizeof (tmp)))
(__m128i) __builtin_ia32_vec_set_v8hi ((__v8hi) val1.x, ins[i], 0);
}
}
--cut here--
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32123
[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"
--- Comment #16 from rob1weld at aol dot com 2007-05-28 08:35 --- >> Comment #11 From [EMAIL PROTECTED] 2007-05-27 07:24 >> Getting stuck at ?: >> libtool: compile: mv -f "process-Posix.o" "java/.libs/process-Posix.o" > ... >This isn't a fix. Actually I tought if you had got that far that I had sent the "cheat" to work around the problem. I noticed that it was not included at the end of post eight. Sorry. I compose my messages in an editor and then paste them into the puny "Additional Comments:" box offline. I wish the box was wider and longer then I would compose online ... I looked at your attachment from post twelve. While I did not go that particular route it un-does someone else's work which could well be correct. I have you HUGE patch from http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01824.html and will review it. I also had a look at: http://gcc.gnu.org/viewcvs/trunk/libjava/configure?r1=125125&r2=125124&pathrev=125125 Thanks Paolo ... --- Here is what I found. I made a _one_ line patch that I am testing against 125123. The problem is that between revision 125031 and 125032 the ac_configure_args added (on _my_ system, might be different for you) this extra section: 'CXXFLAGS=-g -O2 -D_GNU_SOURCE' 'CXX= /opt/gcc-4_3-build/./gcc/xgcc -shared-libgcc -B/opt/gcc-4_3-build/./gcc -nostdinc++ -L/opt/gcc-4_3-build/i686-pc-linux-gnu/libstdc++-v3/src -L/opt/gcc-4_3-build/i686-pc-linux-gnu/libstdc++-v3/src/.libs -B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -isystem /usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include' 'LDFLAGS=' Go to libjava/configure and alter after the section with this text "# Remove --cache-file and --srcdir arguments so they do not pile up." to add a "echo "ac_sub_configure = $ac_sub_configure" command and it prints this: ac_sub_configure = '--cache-file=./config.cache' ... --cache-file= --srcdir= Later the un-modified section of the script prints: configure: configuring in classpath configure: running /bin/sh '/root/downloads/gcc-4_3-trunk/libjava/classpath/configure' --prefix=/usr '--cache-file=./config.cache' ... --cache-file=.././config.cache --srcdir=/root/downloads/gcc-4_3-trunk/libjava/classpath The second "--cache-file=.././config.cache" is a "neat idea" since it would make configuring quicker by using an already decided "config.cache" file. I _do_ like the idea but it would be better to use the "build-root"/"config.cache" instead of the "build-root"/libjava/"config.cache" file. Just two problems. First (it is said that) it wrecks using "Make -j", second, which is relevant to us, is that it uses a "config.cache" that was formed from section of the make that used `"CXXFLAGS_FOR_TARGET=-g -O2 -D_GNU_SOURCE"'. Why the two spaces? Anytime you see "junk" like ".//xyzdir" or, in this case " " it means that a variable was blank. (and the junk should be cleaned). Grep these examples: SYSROOT_CFLAGS_FOR_TARGET="--sysroot=$withval" CXXFLAGS_FOR_TARGET = $(CXXFLAGS) $(SYSROOT_CFLAGS_FOR_TARGET) LIBCXXFLAGS_FOR_TARGET = $(CXXFLAGS_FOR_TARGET) -fno-implicit-templates CFLAGS_FOR_TARGET = -O2 $(CFLAGS) $(SYSROOT_CFLAGS_FOR_TARGET) SYSROOT_CFLAGS_FOR_TARGET = @SYSROOT_CFLAGS_FOR_TARGET@ CXXFLAGS_FOR_TARGET = $(CXXFLAGS) $(SYSROOT_CFLAGS_FOR_TARGET) CXXFLAGS=$$(CXXFLAGS_FOR_TARGET) See? CXXFLAGS = CXXFLAGS_FOR_TARGET = "CXXFLAGS SYSROOT_CFLAGS_FOR_TARGET" If "SYSROOT_CFLAGS_FOR_TARGET" is blank you end up with this happening: `"CXXFLAGS_FOR_TARGET=-g -O2 -D_GNU_SOURCE"' Other trouble is some un-substituted "AT"'s ... # grep -B 9 -A 18 --color=always GNU_SOURCE /root/downloads/gcc-4_3-trunk/libjava/Makefile.in AM_CXXFLAGS = \ -fno-rtti \ -fnon-call-exceptions \ $(THREADCXXFLAGS) \ -fdollars-in-identifiers \ -Wswitch-enum \ -D_FILE_OFFSET_BITS=64 \ @LIBGCJ_CXXFLAGS@ \ $(WARNINGS) \ -D_GNU_SOURCE \ -DPREFIX="\"$(prefix)\"" \ -DTOOLEXECLIBDIR="\"$(toolexeclibdir)\"" \ -DJAVA_HOME="\"$(JAVA_HOME_DIR)\"" \ -DBOOT_CLASS_PATH="\"$(BOOT_CLASS_PATH_DIR)\"" \ -DJAVA_EXT_DIRS="\"$(jardir)/ext\"" \ -DGCJ_ENDORSED_DIRS="\"$(jardir)/gcj-endorsed\"" \ -DGCJ_VERSIONED_LIBDIR="\"$(dbexecdir)\"" \ -DPATH_SEPARATOR="\"$(CLASSPATH_SEPARATOR)\"" \ -DECJ_JAR_FILE="\"$(ECJ_JAR)\"" \ -DLIBGCJ_DEFAULT_DATABASE="\"$(dbexecdir)/$(db_name)\"" \ -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL="\"$(db_pathtail)\"" AM_GCJFLAGS = \ @LIBGCJ_JAVAFLAGS@ \ -fclasspath= -fbootclasspath=$(BOOTCLASSPATH) \ --encoding=UTF-8 \ Combine all those problems and try to share cache files while calling individual configure scripts with arguments that conflict with the cache and what happens - this bug and more to come. To fix _this_ bug and IGNORE the perils that await use this diff on revision 125123: --- libjava/configure 2007-05-28 01:00:43.0 -0700 +++ libjava/confi
[Bug fortran/32124] New: Execution stops with stat= in ALLOCATE
The attached program never reaches the error message printout, contrary to the fact that stat= is specified in the allocate statement (if the runtime aborts, what's the point of stat= ?) [EMAIL PROTECTED] bugtest]$ gfortran -o tryalloc tryalloc.f90 [EMAIL PROTECTED] bugtest]$ ./tryalloc Fortran runtime error: Attempt to allocate negative amount of memory. Possible integer overflow [EMAIL PROTECTED] bugtest]$ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.2.0/configure --prefix=/usr/local/gcc42 --with-mpfr=/home/travel/GCC/BUILDS/mpfr --with-gmp-lib=/home/travel/GCC/BUILDS/gmp/lib/ --with-gmp=/home/travel/GCC/BUILDS/gmp Thread model: posix gcc version 4.2.0 -- Summary: Execution stops with stat= in ALLOCATE Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sfilippone at uniroma2 dot it GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32124
[Bug fortran/32124] Execution stops with stat= in ALLOCATE
--- Comment #1 from sfilippone at uniroma2 dot it 2007-05-28 09:35 --- Created an attachment (id=13620) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13620&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32124
[Bug tree-optimization/32120] missed PRE/FRE of a*2+4 and (a+2)*2
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-28 10:27 --- Confirmed. Maybe fixed by sccvn. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org, rguenth at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-28 10:27:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32120
[Bug c++/32118] ICE in c++ code
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-28 10:29 --- Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32118
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #161 from rguenther at suse dot de 2007-05-28 11:14 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
Btw, it could save us many bugs (or bug reports) if if PTA says must-alias
we'd trust it, instead of using TBAA to say "but it shouldn't". Like for
the (invalid)
int foo(void *p)
{
double *q = p;
int *r = p;
*q = 1.0;
return *r;
}
where we correctly figure that
Points-to sets
q_2 = same as p
r_3 = same as p
but still we get (with -fstrict-aliasing)
:
q_2 = (double *) p_1(D);
r_3 = (int *) p_1(D);
# SMT.4_7 = VDEF
*q_2 = 1.0e+0;
# VUSE
D.1641_4 = *r_3;
which just for the point to make the invalid input produce unexpected
output is possibly creating many of the hard-to-fix issues like this one.
Danny, how easy is it to "fix" the above? It looks like another
attractive solution to this problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #162 from dberlin at gcc dot gnu dot org 2007-05-28 11:24
---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
On 28 May 2007 11:14:20 -, rguenther at suse dot de
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #161 from rguenther at suse dot de 2007-05-28 11:14 ---
> Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
> new does not change the dynamic type as it should
>
> Btw, it could save us many bugs (or bug reports) if if PTA says must-alias
> we'd trust it, instead of using TBAA to say "but it shouldn't". Like for
> the (invalid)
>
> int foo(void *p)
> {
> double *q = p;
> int *r = p;
> *q = 1.0;
> return *r;
> }
>
> where we correctly figure that
>
> Points-to sets
> q_2 = same as p
> r_3 = same as p
>
These are just collapsed because of pointer equivalences.
There is no guarantee that we will discover all pointer equivalences,
and their are in fact cases where we won't.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #107 from simon dot strandman at telia dot com 2007-05-28 11:49 --- (In reply to comment #106) > I haven't tried the fix in 20218. surprisingly, moving to binutils > 2.17.50.0.16.20070511 got rid of that problem. Do you know what exactly is > going on? how did the latest binutils bypass the bug 20218? > Probably because this bug is fixed in the prerelase binutils: http://sourceware.org/bugzilla/show_bug.cgi?id=3666 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug fortran/32124] Execution stops with stat= in ALLOCATE
--- Comment #2 from burnus at gcc dot gnu dot org 2007-05-28 12:07 --- I had to change huge(1_4) to huge(1_8) as the former was not enough to trigger an allocation error on my system. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords||rejects-valid Known to fail||4.3.0 4.2.0 4.1.3 Last reconfirmed|-00-00 00:00:00 |2007-05-28 12:07:05 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32124
[Bug c++/32118] ICE in c++ code
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-05-28 12:23 --- Created an attachment (id=13621) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13621&action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32118
[Bug c++/32118] ICE in c++ code
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-05-28 12:28 ---
Confirmed. Another mangling problem:
Program received signal SIGSEGV, Segmentation fault.
0x0827e9b8 in write_expression (expr=0xb7cdd870)
at /home/richard/src/trunk2/gcc/cp/mangle.c:2175
warning: Source file is more recent than executable.
2175 write_string (operator_name_info[(int) code].mangled_name);
(gdb) print operator_name_info[(int) code]
$1 = {identifier = 0x0, name = 0x0, mangled_name = 0x0, arity = 0}
(gdb) print code
$2 = 214
(gdb)
#2 0x08280a16 in write_template_arg (node=0xb7daf540)
at /home/richard/src/trunk2/gcc/cp/mangle.c:2363
2363 write_expression (node);
(gdb) call debug_tree(node)
VOID
align 1 symtab 0 alias set -1 canonical type 0xb7d61d80
pointer_to_this
reference_to_this >
arg 0
function >
arg 1 >>>
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Known to fail||4.1.2 4.2.0 4.3.0
Last reconfirmed|-00-00 00:00:00 |2007-05-28 12:28:24
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32118
[Bug c/32099] a constant value is said to be not constant
--- Comment #3 from manu at gcc dot gnu dot org 2007-05-28 12:54 --- Worse, with __builtin_sin(M_PI), I get an error: test.c:2: error: initializer element is not constant Maybe this is fixed now in GCC 4.3 by using MPFR. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32099
[Bug fortran/32124] Execution stops with stat= in ALLOCATE
--- Comment #3 from patchapp at dberlin dot org 2007-05-28 13:15 --- Subject: Bug number PR32124 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-05/msg01870.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32124
[Bug fortran/31564] Error: Type/rank mismatch in argument
--- Comment #3 from eedelman at gcc dot gnu dot org 2007-05-28 15:41 --- (In reply to comment #2) > Created an attachment (id=13618) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13618&action=view) [edit] > decl.c patch (not check-gfortran tested) > > Erik, are you still working on this? Officially, yes :-) I.e., I began, but now I haven't had time to look at it for a couple of weeks. Just go ahead and fix it if you are interested. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31564
[Bug fortran/31243] truncating strings longer than 2**32 characters
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31243
[Bug fortran/31974] [4.2]: array allocation multiplication of mismatched types
--- Comment #15 from fxcoudert at gcc dot gnu dot org 2007-05-28 16:17 --- Removing the wrong-code keyword until we manage to find if it actually happens on 4.2, or if it's just not exposed. I'm reluctant to backport the patch unless we have a proof of it happening on 4.2 (and if it happens, it's probably not a regression). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|SUSPENDED Keywords|wrong-code | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31974
[Bug preprocessor/14331] please add option to suppress warning message "no newline at end of file"
--- Comment #18 from fxcoudert at gcc dot gnu dot org 2007-05-28 16:38 --- Patch was approved... -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14331
[Bug fortran/32124] Execution stops with stat= in ALLOCATE
--- Comment #4 from burnus at gcc dot gnu dot org 2007-05-28 16:39 --- Subject: Bug 32124 Author: burnus Date: Mon May 28 16:39:35 2007 New Revision: 125133 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125133 Log: 2007-05-28 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/32124 * runtime/memory.c (allocate_size): Use ERROR_ALLOCATION. (allocate,allocate64): Use stat variable if present. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/runtime/memory.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32124
[Bug fortran/32124] Execution stops with stat= in ALLOCATE
--- Comment #5 from burnus at gcc dot gnu dot org 2007-05-28 16:41 --- Fixed in GCC 4.3.0, won't backport to 4.2.0 (no regression) -- 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=32124
[Bug libstdc++/31717] libstdc++-v3 - Make fails with: ./c++locale.h:69: error: '__locale_t' does not name a type
--- Comment #7 from bkoz at gcc dot gnu dot org 2007-05-28 16:56 --- Created an attachment (id=13622) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13622&action=view) patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31717
[Bug libstdc++/31717] libstdc++-v3 - Make fails with: ./c++locale.h:69: error: '__locale_t' does not name a type
-- bkoz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-04-27 09:54:18 |2007-05-28 16:55:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31717
[Bug c++/32125] New: [4.3 regression] ICE with invalid specialization of variadic template
The following invalid code snippet triggers an ICE on mainline:
template struct A;
template struct A
{
A();
A(T);
};
bug.cc:3: error: parameter packs not expanded with `...':
bug.cc:3: note: 'T'
bug.cc:4: error: parameter packs not expanded with `...':
bug.cc:4: note: 'T'
bug.cc:5: error: parameter packs not expanded with `...':
bug.cc:5: note: 'T'
bug.cc:6: error: parameter packs not expanded with `...':
bug.cc:6: note: 'T'
bug.cc:6: error: parameter packs not expanded with `...':
bug.cc:6: note: 'T'
bug.cc:6: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in add_method, at cp/class.c:1029
Please submit a full bug report, [etc.]
Just one nit: Do we have to emit an error message for every line
(sometimes even twice)?
Btw, the quotation should also be fixed like in the patch below
(I haven't time to test the patch, though):
=
--- gcc/gcc/cp/pt.c 2007-05-25 22:27:32 +0200
+++ gcc/gcc/cp/pt.c 2007-05-27 19:23:23 +0200
@@ -2622,7 +2622,7 @@ check_for_bare_parameter_packs (tree t)
if (parameter_packs)
{
- error ("parameter packs not expanded with `...':");
+ error ("parameter packs not expanded with %<...%>:");
while (parameter_packs)
{
tree pack = TREE_VALUE (parameter_packs);
=
--
Summary: [4.3 regression] ICE with invalid specialization of
variadic template
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32125
[Bug c++/32125] [4.3 regression] ICE with invalid specialization of variadic template
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32125
[Bug c++/32125] [4.3 regression] ICE with invalid specialization of variadic template
--- Comment #1 from reichelt at gcc dot gnu dot org 2007-05-28 16:53
---
A similar testcase crashes in a different place:
template struct A;
template struct A
{
A() {}
};
bug.cc:3: error: parameter packs not expanded with `...':
bug.cc:3: note: 'T'
bug.cc:4: error: parameter packs not expanded with `...':
bug.cc:4: note: 'T'
bug.cc:5: error: parameter packs not expanded with `...':
bug.cc:5: note: 'T'
Internal compiler error: Error reporting routines re-entered.
Please submit a full bug report, [etc.]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32125
[Bug libstdc++/31717] libstdc++-v3 - Make fails with: ./c++locale.h:69: error: '__locale_t' does not name a type
--- Comment #8 from bkoz at gcc dot gnu dot org 2007-05-28 16:57 --- This should do it. I'll put it on 4.2.x branch after some testing on mainline. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31717
[Bug libstdc++/32092] Can't create directory link when build libstdc++ (gcc-4.2.0)
--- Comment #1 from bkoz at gcc dot gnu dot org 2007-05-28 16:58 --- This path: $GCC_SRC_ROOT\mingw_build\mingw32\libstdc++-v3\include\ext\pb_ds\detail Looks wrong. Are you building in the source directory? -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32092
[Bug c++/32126] New: [4.3 regression] ICE with invalid definition of variadic template
The following invalid code snippet triggers an ICE on mainline:
template struct A;
template struct A
{
static int i;
};
A a;
A b;
bug.cc:3: error: parameter packs not expanded with `...':
bug.cc:3: note: 'T'
bug.cc:4: error: parameter packs not expanded with `...':
bug.cc:4: note: 'T'
bug.cc: In instantiation of 'A':
bug.cc:9: instantiated from here
bug.cc:5: internal compiler error: in finish_member_declaration, at
cp/semantics.c:2270
Please submit a full bug report, [etc.]
--
Summary: [4.3 regression] ICE with invalid definition of variadic
template
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32126
[Bug c++/32126] [4.3 regression] ICE with invalid definition of variadic template
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32126
[Bug libstdc++/31717] libstdc++-v3 - Make fails with: ./c++locale.h:69: error: '__locale_t' does not name a type
--- Comment #9 from bkoz at gcc dot gnu dot org 2007-05-28 17:02 --- Subject: Bug 31717 Author: bkoz Date: Mon May 28 17:02:30 2007 New Revision: 125134 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125134 Log: 2007-05-28 Benjamin Kosnik <[EMAIL PROTECTED]> PR libstdc++/31717 * acinclude.m4 (GLIBCXX_ENABLE_CLOCALE): Re-organize. Sanity check gnu locale model requests to make sure it will work for the requested target. Add checks for strxfrm_l, strerror_l when in gnu locale, and strerror_r everywhere. * aclocal.m4: Regenerated. * configure: Regenerated. * config.h.in: Regenerated. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/aclocal.m4 trunk/libstdc++-v3/config.h.in trunk/libstdc++-v3/configure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31717
[Bug c++/32127] New: [4.3 regression] ICE with invalid static member in variadic template
The following invalid code snippet triggers an ICE on mainline:
template struct A
{
static T i;
};
int j = A::i;
bug.cc:3: error: parameter packs not expanded with `...':
bug.cc:3: note: 'T'
bug.cc:6: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have template_type_parm in lookup_conversions,
at cp/search.c:2432
Please submit a full bug report, [etc.]
--
Summary: [4.3 regression] ICE with invalid static member in
variadic template
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32127
[Bug c++/32127] [4.3 regression] ICE with invalid static member in variadic template
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32127
[Bug c++/32128] New: [4.3 regression] ICE on variadic template with two parameter packs
The following invalid code snippet triggers an ICE on mainline:
template struct A;
template struct A {};
A a;
bug.cc:3: error: parameter pack argument 'T ...' must be at the end of the
template argument list
bug.cc:5: internal compiler error: in unify, at cp/pt.c:12654
Please submit a full bug report, [etc.]
--
Summary: [4.3 regression] ICE on variadic template with two
parameter packs
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32128
[Bug c++/32128] [4.3 regression] ICE on variadic template with two parameter packs
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32128
[Bug fortran/32129] New: ICE: Procedure call with array-section-actual to scalar dummy
This is kind of a split up of PR31564, which is unrelated. The program is invalid as we pass an array as actual argument to the scalar dummy argument; somehow gfortran does not detect this. Interestingly, compare_actual_formal is never called if the actual argument is an array section with non-expr-constant bounds. If it is a single element, or the whole array or has e.g. bounds "1:1" or "1:2" everything is caught and goes through compare_actual_formal, except for ":which", "1:which" etc. The ICE is: x.f90: In function 'cdf_beta': x.f90:16: internal compiler error: in gfc_trans_call, at fortran/trans-stmt.c:321 Testcase, from PR 31564 modified to produce invalid code. MODULE cdf_aux_mod TYPE :: the_distribution INTEGER :: parameters(1) END TYPE the_distribution TYPE (the_distribution), PARAMETER :: the_beta = the_distribution((/0/)) CONTAINS SUBROUTINE set_bound(arg_name) INTEGER, INTENT (IN) :: arg_name END SUBROUTINE set_bound END MODULE cdf_aux_mod MODULE cdf_beta_mod CONTAINS SUBROUTINE cdf_beta() USE cdf_aux_mod INTEGER :: which which = 1 CALL set_bound(the_beta%parameters(1:which)) END SUBROUTINE cdf_beta END MODULE cdf_beta_mod -- Summary: ICE: Procedure call with array-section-actual to scalar dummy Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32129
[Bug target/32130] New: linking problems: multiple definition of `__DTOR_END__'
Starting with the patch http://gcc.gnu.org/ml/gcc-patches/2006-02/msg02031.html>, committed as revision 12, linking fails. From libffi/configure.log: configure:2261: checking for C compiler default output file name configure:2264: /home/rask/build/gcc-ppc/./gcc/xgcc -B/home/rask/build/gcc-ppc/./gcc/ -nostdinc -B/home/rask/build/gcc-ppc/powerpc-eabisim/newlib/ -isystem /home/rask/build/gcc-ppc/powerpc-eabisim/newlib/targ-include -isystem /n/08/rask/src/gcc/newlib/libc/include -B/usr/local/powerpc-eabisim/bin/ -B/usr/local/powerpc-eabisim/lib/ -isystem /usr/local/powerpc-eabisim/include -isystem /usr/local/powerpc-eabisim/sys-include -L/home/rask/build/gcc-ppc/./ld -O2 -g -O2conftest.c >&5 /home/rask/build/gcc-ppc/./gcc/ecrtn.o:(.dtors+0x0): multiple definition of `__DTOR_END__' /home/rask/build/gcc-ppc/./gcc/crtend.o:(.dtors+0x0): first defined here collect2: ld returned 1 exit status -- Summary: linking problems: multiple definition of `__DTOR_END__' Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rask at sygehus dot dk GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: powerpc-unknown-eabisim http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32130
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #163 from ian at airs dot com 2007-05-28 17:30 --- Richi, I tested my patch on every test case I saved. Can you just point me at the one I missed? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug fortran/32103] Module with equivalence draws "unsatisfied reference"
--- Comment #3 from pault at gcc dot gnu dot org 2007-05-28 17:42 --- I know what the trouble is: Since the variable 'a' is not used, the equivalence is scrubbed and the compiler goes off to look for a module variable, rather than a member of an external union. I have tried one or two attempts at fixes but none have touched the problem yet. I notice that the attribute 'in_equivalence' is not handled in modules. It probably has to be so that equivalence variables that are not used can be loaded using the unique symtree mechanism. If they are not loaded, the offset information in the equivalence is not retained because the expression cannot be used. It's not low hanging fruit but it's amenable to being picked. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-05-27 16:37:22 |2007-05-28 17:42:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32103
[Bug c/31128] __builtin_stack_restore/__builtin_stack_save should not be exposed to the user
--- Comment #6 from sabre at nondot dot org 2007-05-28 17:44 --- This is very useful for compilers generating C code (e.g. LLVM, and various other source -> C compilers). Why remove it? These compilers are generating partially structured code, that don't have syntactic blocks required for VLAs. -- sabre at nondot dot org changed: What|Removed |Added CC||sabre at nondot dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31128
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #108 from funtoos at yahoo dot com 2007-05-28 17:47 --- but comments in bug 20218 say that its fixed in mainline, which means there was a fix put into gcc for hidden visibility. So, are both the fix from prerelease binutils and gcc mainline needed to fix this completely? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug fortran/32129] ICE: Procedure call with array-section-actual to scalar dummy
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-28 18:13 ---
Some debugging shows:
resolve_call calls resolve_actual_arglist, which fails.
resolve_call propagates the failure to resolve_where, which does not check for
errors.
In resolve_actual_arglist it fails here:
if (e->ts.type != BT_PROCEDURE)
{
if (gfc_resolve_expr (e) != SUCCESS)
return FAILURE;
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32129
[Bug fortran/31564] Error: Type/rank mismatch in argument
--- Comment #4 from eedelman at gcc dot gnu dot org 2007-05-28 18:51 --- (In reply to comment #3) > (In reply to comment #2) > > Created an attachment (id=13618) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13618&action=view) [edit] > > decl.c patch (not check-gfortran tested) > > > > Erik, are you still working on this? > > Officially, yes :-) > I.e., I began, but now I haven't had time to look at it for a couple of > weeks. > Just go ahead and fix it if you are interested. Just to add one more data point: It's not just procedure arguments that are problematic; it's expression like foo%array(variable) in general, where foo is a PARAMETER. E.g. this piece of code is also rejected: SUBROUTINE cdf_beta() TYPE :: the_distribution INTEGER :: parameters(1) END TYPE the_distribution TYPE (the_distribution), PARAMETER :: the_beta = the_distribution((/0/)) INTEGER :: which, pooh which = 1 pooh = the_beta%parameters(which) END SUBROUTINE cdf_beta erik:~/gcc$ gfortran pr31564.f90 pr31564.f90:12.8: pooh = the_beta%parameters(which) 1 Error: Incompatible ranks 0 and 1 in assignment at (1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31564
[Bug c/31128] __builtin_stack_restore/__builtin_stack_save should not be exposed to the user
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-05-28 19:08 ---
(In reply to comment #6)
> This is very useful for compilers generating C code (e.g. LLVM, and various
> other source -> C compilers). Why remove it? These compilers are generating
> partially structured code, that don't have syntactic blocks required for VLAs.
Because there are better ways of implementing that in the generated C code.
You can create a fake VLA (that is of size 0).
Like:
int f(int t1)
{
{
int t = 0;
int a[t];
int *b = __builtin_alloca(t1);
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31128
gfortran internal compiler error
Hopefully this is everything you need: output from the gfortran command, the source file, and the .mod and .s files that were generated. GFORTRAN was installed from binary using fink a day or so ago. Since this was my first use of fink, I'm not sure why it got the experimental version. $ uname -a Darwin Jacks-Computer.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power Macintosh powerpc $ gfortran -v -save-temps -c casechange_mod.f90 Using built-in specs. Target: powerpc-apple-darwin7.8.0 Configured with: ../gcc/configure --prefix=/usr/local/gfortran --enable-languages=c,f95 Thread model: posix gcc version 4.1.0 20050325 (experimental) /usr/local/gfortran/libexec/gcc/powerpc-apple-darwin7.8.0/4.1.0/f951 casechange_mod.f90 -fPIC -quiet -dumpbase casechange_mod.f90 -auxbase casechange_mod -version -o casechange_mod.s GNU F95 version 4.1.0 20050325 (experimental) (powerpc-apple-darwin7.8.0) compiled by GNU C version 3.3 20030304 (Apple Computer, Inc. build 1640). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 casechange_mod.f90: In function 'toupper_vector': casechange_mod.f90:6: internal compiler error: in gfc_conv_function_call, at fortran/trans-expr.c:1103 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. casechange_mod.f90 Description: Binary data casechange_mod.mod Description: Binary data casechange_mod.s Description: Binary data
[Bug tree-optimization/32100] [4.2/4.3 Regression] vrp bitfield miscompilation
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-05-28 19:43 --- Subject: Bug 32100 Author: pinskia Date: Mon May 28 19:43:10 2007 New Revision: 125139 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125139 Log: 2007-05-28 Andrew Pinski <[EMAIL PROTECTED]> PR tree-opt/32100 * fold-const.c (tree_expr_nonnegative_warnv_p): Don't return true when truth_value_p is true and the type is of signed:1. 2007-05-28 Andrew Pinski <[EMAIL PROTECTED]> PR tree-opt/32100 * gcc.c-torture/execute/vrp-7.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/vrp-7.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32100
[Bug tree-optimization/32100] [4.2/4.3 Regression] vrp bitfield miscompilation
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-05-28 19:48 --- Subject: Bug 32100 Author: pinskia Date: Mon May 28 19:47:53 2007 New Revision: 125140 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125140 Log: 2007-05-28 Andrew Pinski <[EMAIL PROTECTED]> PR tree-opt/32100 * fold-const.c (tree_expr_nonnegative_warnv_p): Don't return true when truth_value_p is true and the type is of signed:1. 2007-05-28 Andrew Pinski <[EMAIL PROTECTED]> PR tree-opt/32100 * gcc.c-torture/execute/vrp-7.c: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/execute/vrp-7.c - copied unchanged from r125139, trunk/gcc/testsuite/gcc.c-torture/execute/vrp-7.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/fold-const.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32100
[Bug tree-optimization/32100] [4.2/4.3 Regression] vrp bitfield miscompilation
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-05-28 19:48 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32100
[Bug testsuite/32057] Random failure on gfortran.dg/secnds.f
--- Comment #3 from dominiq at lps dot ens dot fr 2007-05-28 19:52 --- A partial fix can be found at http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01873.html Some discussions can be found by following the thread. -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||dominiq at lps dot ens dot ||fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32057
[Bug c++/32121] [4.1/4.2/4.3 Regression] C++ front-end accepts invalid __label__ declarations
--- Comment #3 from fang at csl dot cornell dot edu 2007-05-28 19:53 --- Yup, also fails with 3.4.0 (accepts-invalid). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32121
[Bug fortran/32131] New: knowing that stride==1 when using allocated arrays
Look at this: $ cat allocate-loop.f90 program main implicit none real, allocatable, dimension(:) :: a, b, c real, dimension(10) :: d, e, f real :: s allocate (a(10), b(10), c(10)) call random_number(a) call random_number(b) c = a+b s = sum(c) print *,s call random_number(d) call random_number(e) f = d+e s = sum(f) print *,f end program main $ gfortran -march=athlon-xp -O3 -ftree-vectorize -ftree-vectorizer-verbose=4 allocate-loop.f90 allocate-loop.f90:15: note: not vectorized: unsupported use in stmt. allocate-loop.f90:14: note: LOOP VECTORIZED. allocate-loop.f90:10: note: not vectorized: unsupported use in stmt. allocate-loop.f90:9: note: not vectorized: unhandled data-ref allocate-loop.f90:1: note: vectorized 1 loops in function. The loop at line 9 (c=a+b) could be vectorized if the stride was known to be 1 (which isn't made known to the middle end in this case). -- Summary: knowing that stride==1 when using allocated arrays Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32131
[Bug c++/32132] New: bogus warning at -O3 ( 'r' may be used uninitialized in this function ).
attached testcase produces unexpected warning at -O3: $ g++ -Wall -Woverloaded-virtual -Werror -O3 -gdwarf-2 -g1 -fPIE \ -Wno-error -c auHexCastTest.ii ../../au/h/auHexCast.hpp: In function ‘R au::hex_cast(const stlp_std::string&) [with R = int]’: ../../au/h/auHexCast.hpp:50: warning: ‘r’ may be used uninitialized in this function -- Summary: bogus warning at -O3 ( 'r' may be used uninitialized in this function ). Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net GCC target triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32132
[Bug c++/32132] bogus warning at -O3 ( 'r' may be used uninitialized in this function ).
--- Comment #1 from pluto at agmk dot net 2007-05-28 20:08 --- Created an attachment (id=13623) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13623&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32132
[Bug c++/32132] bogus warning at -O3 ( 'r' may be used uninitialized in this function ).
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-28 20:13 --- This might not be a bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32132
[Bug c++/32132] bogus warning at -O3 ( 'r' may be used uninitialized in this function ).
--- Comment #3 from pluto at agmk dot net 2007-05-28 20:16 ---
(In reply to comment #2)
> This might not be a bug
>
so, how 'r' can be used uninitialized in this case?
template
R hex_cast ( const std::string & s )
{
if ( s.empty () )
throw bad_hex_cast ();
R r;
std::istringstream str ( s );
str >> std::hex >> r;
return r;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32132
[Bug c++/32132] bogus warning at -O3 ( 'r' may be used uninitialized in this function ).
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-28 20:26 --- so, how 'r' can be used uninitialized in this case? Because istringstream >> r could have caused an error. so you need to check if there is an error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32132
[Bug fortran/30964] optional arguments to random_seed
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-05-28 20:48 --- The following two codes are handled differently: $ cat u.f90 call foo() contains subroutine foo(x) integer, dimension(:), optional :: x interface subroutine bar(x) integer, dimension(:), optional :: x end subroutine bar end interface call bar(x) end subroutine foo end $ cat v.f90 call foo() contains subroutine foo(x) integer, dimension(:), optional :: x call random_seed(get=x) end subroutine foo end For the first one, gfc_conv_missing_dummy() is called, which leads to correct code. For the second one, gfc_conv_missing_dummy() is not called, leading to wrong-code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30964
[Bug fortran/31972] [4.3 regression] Internal Error occurs when TRANSFER contains hollerith argument
--- Comment #7 from brooks at gcc dot gnu dot org 2007-05-28 20:53 --- Subject: Bug 31972 Author: brooks Date: Mon May 28 20:53:09 2007 New Revision: 125141 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125141 Log: PR 31972/fortran * target-memory.c (gfc_target_expr_size): Add handling for size of BT_HOLLERITH variables. * check.c (gfc_check_transfer): Reject BT_HOLLERITH variables in MOLD argument of TRANSFER. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/target-memory.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31972
[Bug fortran/31198] wrong code: Max() with optional arguments
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-05-28 20:54 --- Created an attachment (id=13624) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13624&action=view) Patch for this issue This patch builds on top of Lee Millward's patch to trans-intrinsic: http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01827.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31198
[Bug fortran/31972] [4.3 regression] Internal Error occurs when TRANSFER contains hollerith argument
--- Comment #8 from brooks at gcc dot gnu dot org 2007-05-28 20:54 --- Subject: Bug 31972 Author: brooks Date: Mon May 28 20:54:49 2007 New Revision: 125142 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125142 Log: PR fortran/31972 * transfer_hollerith_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/transfer_hollerith_1.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31972
[Bug fortran/32131] knowing that stride==1 when using allocated arrays and escaping allocatable arrays
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-28 20:56 --- This is an aliasing issue. The reason why we don't optimize this is because we think a/b and escape except in Fortran that is not the case. I think there is another bug about this case somewhere too. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||alias Last reconfirmed|-00-00 00:00:00 |2007-05-28 20:56:12 date|| Summary|knowing that stride==1 when |knowing that stride==1 when |using allocated arrays |using allocated arrays and ||escaping allocatable arrays http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32131
[Bug fortran/31972] [4.3 regression] Internal Error occurs when TRANSFER contains hollerith argument
--- Comment #9 from brooks at gcc dot gnu dot org 2007-05-28 20:57 --- Fixed, as per above commits. -- brooks at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31972
[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor
--- Comment #3 from brooks at gcc dot gnu dot org 2007-05-28 21:09 ---
Paul, I don't think that's solving the right problem. The code is legal; the
inner TRANSFER creates an array of CHARACTER with len=1 and size=20, which
conforms with a CHARACTER scalar of len=20.
In reducing this, I discovered that gfortran currently hangs on the following
much simpler code. I suspect that if we fix this, it'll fix the original code
too.
write(*,*) transfer("A", "x", 20)
end
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2007-04-18 07:03:32 |2007-05-28 21:09:17
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
[Bug middle-end/12086] memcmp(i,j,4) should use word (SI) subtraction
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-05-28 21:07 --- I am no longer working on this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12086
[Bug tree-optimization/19719] missed optimization on boolean operation with boolean arguments
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-05-28 21:21 --- No longer working on this one. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19719
[Bug tree-optimization/14442] missed sib if conversion optimization on the tree level (PHI-OPT misses that !(a == 0) is just a != 0)
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-05-28 21:22 --- I am no longer working on this one. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14442
[Bug libobjc/23680] @synchronized support is not in GNU runtime
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-28 21:24 --- (In reply to comment #0) > Just a bug report to remind me to add support for @synchronized for 4.2. 4.3 ... (maybe once I finish pointer plus I can get back to fixing libobjc issues). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23680
[Bug c++/32132] bogus warning at -O3 ( 'r' may be used uninitialized in this function ).
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-28 21:48 --- The warning is correct you need to check if str had an error after reading the integer. This is not a GCC bug. The IR looks like: : __comp_ctor (&str, s, 8); this.104 = (struct ios_base *) &str.D.25711; __s = this.104 + *(int *) (str.D.25711._vptr.basic_istream + -12); D.40158 = __s->_M_fmtflags; __s->_M_fmtflags = D.40158 & -57 | 16; _M_get_num (&str.D.25711, &__lval); : if (((this.104 + *(int *) (str.D.25711._vptr.basic_istream + -12))->_M_iostate & 5) != 0) goto ; else goto ; : __lval.107 = __lval; r = __lval.107; : __comp_dtor (&str); return r; Which shows for sure r may be used unitialized. Note using libstdc++ does not warn about this because we made >> out of line only which means you will not see the warning (even though the warning is correct). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32132
[Bug objc/29197] [4.0/4.1/4.2/4.3 Regression] ICE after error with array type with undefined variable
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-28 21:53 --- I am no longer working on this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29197
[Bug fortran/32124] Execution stops with stat= in ALLOCATE
--- Comment #6 from burnus at gcc dot gnu dot org 2007-05-28 22:07 --- Subject: Bug 32124 Author: burnus Date: Mon May 28 22:07:23 2007 New Revision: 125148 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125148 Log: 2007-05-28 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/32124 * gfortran.dg/allocate_stat_1.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/allocate_stat_1.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32124
[Bug testsuite/32057] Random failure on gfortran.dg/secnds.f
-- tkoenig 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-05-28 22:15:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32057
[Bug c++/32133] New: Post-increment gained unintuitive behaviour
I noticed a change in the implementation of the post-increment (i++) operator in gcc 4.0.1 (Apple build 5367). The behaviour can be seen with the following code: --- i += i++; --- In older versions (< 4) of g++ the 'original' variable is returned by ++, meaning that the statement given has the effect of doubling the value of i. The new version of ++ seems to return the 'copy', leading to i just being incremented by one in the end. The situation I think of as the most intuitive would be something like this: --- (i += i)++ --- I realise though that operator precedence prohibits such behaviour. The following two lines demonstrate, however, why I think the old behaviour is desired over the new one: --- (i++ < i); //Used to be true, now false (i > i++); //Idem --- Modern versions even make this true: --- i++ == i++ --- Which, I think, is not what one wants. Regards, - Jouke -- Summary: Post-increment gained unintuitive behaviour Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: j dot witteveen at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32133
[Bug c++/32116] Relocation error with -O3, recent CVS
--- Comment #1 from mckelvey at maskull dot com 2007-05-28 22:45 --- I refetched from svn and rebuilt and it works OK now. -- mckelvey at maskull dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32116
[Bug c++/32133] Post-increment gained unintuitive behaviour
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-28 22:47 --- You obviously did not read the bugs.html page which lists this as a nonbug: http://gcc.gnu.org/bugs.html#nonbugs_c Increment/decrement operator (++/--) not working as expected - a problem with many variations. The following expressions have unpredictable results: x[i]=++i foo(i,++i) i*(++i) /* special case with foo=="operator*" */ std::cout << i << ++i /* foo(foo(std::cout,i),++i) */ since the i without increment can be evaluated before or after ++i. The C and C++ standards have the notion of "sequence points". Everything that happens between two sequence points happens in an unspecified order, but it has to happen after the first and before the second sequence point. The end of a statement and a function call are examples for sequence points, whereas assignments and the comma between function arguments are not. Modifying a value twice between two sequence points as shown in the following examples is even worse: i=++i foo(++i,++i) (++i)*(++i) /* special case with foo=="operator*" */ std::cout << ++i << ++i /* foo(foo(std::cout,++i),++i)*/ This leads to undefined behavior (i.e. the compiler can do anything). *** This bug has been marked as a duplicate of 11751 *** -- 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=32133
[Bug c/11751] wrong evaluation order of an expression
--- Comment #76 from pinskia at gcc dot gnu dot org 2007-05-28 22:47 --- *** Bug 32133 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||j dot witteveen at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11751
[Bug c/32134] New: Configuring stage 2 in ./intl fails checking for C compiler default output file name - C compiler cannot create executables
$ cat /cygdrive/C/makecygwin/gcc-4_3-trunk/LAST_UPDATED Mon May 28 16:39:01 UTC 2007 (revision 125132) $ prev-gcc/xgcc -v Using built-in specs. Target: i686-pc-cygwin Configured with: /cygdrive/C/makecygwin/gcc-4_3-trunk/configure --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/4.3 --verbose --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --with-tune=athlon-xp --with-cpu=athlon-xp --with-arch=athlon-xp --enable-stage1-checking=assert,gc,misc,rtl,rtlflag,runtime,tree Thread model: single gcc version 4.3.0 20070528 (experimental) Using minimal configure parameters _or_ trying "--disable-initfini-array --disable-__cxa_atexit" was to no avail. I did search gcc-patches and bugzilla. The intl/configure script for 4.3.0 is the same as for 4.2.0/1 and it does not fail there. The test is trivial, the problem might be in libgcc2. This is my first try at 4.3.0 for Cygwin. I'm going to look into this more to see if I can find the trouble. Here is the screen output: make[3]: Leaving directory `/cygdrive/c/gcc-4_3-trunk-build/i686-pc-cygwin/libgcc' make[2]: Leaving directory `/cygdrive/c/gcc-4_3-trunk-build' make[2]: Entering directory `/cygdrive/c/gcc-4_3-trunk-build' make[3]: Entering directory `/cygdrive/c/gcc-4_3-trunk-build' rm -f stage_current make[3]: Leaving directory `/cygdrive/c/gcc-4_3-trunk-build' make[2]: Leaving directory `/cygdrive/c/gcc-4_3-trunk-build' make[2]: Entering directory `/cygdrive/c/gcc-4_3-trunk-build' Configuring stage 2 in ./intl configure: creating cache ./config.cache checking whether make sets $(MAKE)... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether NLS is requested... yes checking for msgfmt... /usr/bin/msgfmt checking for gmsgfmt... /usr/bin/msgfmt checking for xgettext... /usr/bin/xgettext checking for msgmerge... /usr/bin/msgmerge checking for i686-pc-cygwin-gcc... /cygdrive/c/gcc-4_3-trunk-build/./prev-gcc/xgcc -B/cygdrive/c/gcc-4_3-trunk-build/./prev-gcc/ -B/usr/i686-pc-cygwin/bin/ checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. make[2]: *** [configure-stage2-intl] Error 77 make[2]: Leaving directory `/cygdrive/c/gcc-4_3-trunk-build' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/cygdrive/c/gcc-4_3-trunk-build' make: *** [all] Error 2 Here is the file: /gcc-4_3-trunk-build/intl/config.log configure:1658: result: /usr/bin/xgettext configure:1698: checking for msgmerge configure:1728: result: /usr/bin/msgmerge configure:1771: checking for i686-pc-cygwin-gcc configure:1797: result: /cygdrive/c/gcc-4_3-trunk-build/./prev-gcc/xgcc -B/cygdrive/c/gcc-4_3-trunk-build/./prev-gcc/ -B/usr/i686-pc-cygwin/bin/ configure:2079: checking for C compiler version configure:2082: /cygdrive/c/gcc-4_3-trunk-build/./prev-gcc/xgcc -B/cygdrive/c/gcc-4_3-trunk-build/./prev-gcc/ -B/usr/i686-pc-cygwin/bin/ --version &5 xgcc (GCC) 4.3.0 20070528 (experimental) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:2085: $? = 0 configure:2087: /cygdrive/c/gcc-4_3-trunk-build/./prev-gcc/xgcc -B/cygdrive/c/gcc-4_3-trunk-build/./prev-gcc/ -B/usr/i686-pc-cygwin/bin/ -v &5 Reading specs from /cygdrive/c/gcc-4_3-trunk-build/./prev-gcc/specs Target: i686-pc-cygwin Configured with: /cygdrive/C/makecygwin/gcc-4_3-trunk/configure --verbose --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --with-tune=athlon-xp --prefix=/usr --enable-objc-gc --enable-concept-checks --disable-multilib --with-gxx-include-dir=/usr/include/c++/4.3 --enable-libstdcxx-debug --enable-static --enable-shared --enable-initfini-array --enable-__cxa_atexit --enable-threads=posix --enable-version-specific-runtime-libs --enable-libssp --enable-libmudflap --enable-libgomp --disable-werror --enable-nls --with-included-gettext --enable-decimal-float --with-long-double-128 --enable-debug --enable-java-gc=boehm --with-x --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-java-awt=gtk,xlib --enable-gtk-cairo --enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-tool-wrappers --enable-portable-native-sync --enable-examples --enable-libgcj-multifile --with-stabs --enable-hash-synchronization --enable-gc-debug --enable-interpreter --with-system-zlib --enable-libada --with-tls --with-cpu=athlon-xp --with-arch=athlon-xp --enable-stage1-checking=assert,gc,misc,rtl,rtlflag,runtime,tree Thread model: posix gcc version 4.3.0 20070528 (experimental) configure:2090: $? = 0 configure:2092: /cygdrive/c/gcc-4_3-trunk-build/./prev-gcc/xgcc -B/cygdrive/c/gcc-4_3-trunk-build/./prev-gcc/ -B/usr/i686-pc-cygwin/bin/ -
[Bug target/32134] Configuring stage 2 in ./intl fails checking for C compiler default output file name - C compiler cannot create executables
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-28 23:57 --- *** This bug has been marked as a duplicate of 31039 *** -- 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=32134
[Bug bootstrap/31039] Latest CVS-stage 2-Cannot create executables
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-05-28 23:57 --- *** Bug 32134 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rob1weld at aol dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31039
[Bug bootstrap/31039] [4.3 Regression] Latest CVS-stage 2-Cannot create executables
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||build Summary|Latest CVS-stage 2-Cannot |[4.3 Regression] Latest CVS- |create executables |stage 2-Cannot create ||executables Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31039
[Bug bootstrap/31039] [4.3 Regression] Latest CVS-stage 2-Cannot create executables
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-05-29 00:00 --- This was a newlib bug which was fixed already so closing as such. You need to update your cygwin libc. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31039
[Bug c/32135] New: bogus array-ref fold triggering array overflow warning
Hi,
-O2 Warray-bounds:
=== Cut ===
struct PhaseEntryType
{
char raw_field[50 + 1];
};
int
ParsePhase (char in_cols[15][250], struct PhaseEntryType *P)
{
__builtin_strncpy (P->raw_field, in_cols[2], 50);
}
~
=== Cut ===
triggered by
__builtin_strncpy ((char *) &P->raw_field, (const char *) (char *) in_cols +
500B, 50);
being gimplified to:
D.1970 = &(*in_cols)[500];
D.1971 = &P->raw_field[0];
__builtin_strncpy (D.1971, D.1970, 50)
--
Summary: bogus array-ref fold triggering array overflow warning
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mueller at gcc dot gnu dot org
GCC host triplet: i686-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32135
[Bug target/32134] Configuring stage 2 in ./intl fails checking for C compiler default output file name - C compiler cannot create executables
--- Comment #2 from rob1weld at aol dot com 2007-05-29 00:06 --- Wow Andrew, you were sure on top of that fast... I _did_ search for various words to attempt to find a similar complaint before posting. I found none. I agree that this bug report is a dupe of 31039 . Do you have some sort of dupe check script running or is it just your magic powers? Thanks. -- rob1weld at aol dot com changed: What|Removed |Added Known to fail||4.3.0 Known to work||4.2.0 4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32134
[Bug target/32134] Configuring stage 2 in ./intl fails checking for C compiler default output file name - C compiler cannot create executables
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-29 00:08 --- (In reply to comment #2) > Do you have some sort of dupe check script running or is it just your magic > powers? I just searched for __sgetc_r. Nothing special for finding the dup. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32134
[Bug middle-end/32135] [4.3 Regression] bogus array-ref fold triggering array overflow warning
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-29 00:10 --- The bug is in maybe_fold_offset_to_array_ref. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end Summary|bogus array-ref fold|[4.3 Regression] bogus |triggering array overflow |array-ref fold triggering |warning |array overflow warning Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32135
[Bug c/31339] [4.3 regression] ICE on invalid use of complex constant
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-29 00:25 --- Subject: Bug 31339 Author: pinskia Date: Tue May 29 00:25:25 2007 New Revision: 125156 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125156 Log: 2007-05-28 Andrew Pinski <[EMAIL PROTECTED]> PR c/31339 * c-typeck.c (build_unary_op ): Return the error_mark_node if either the real or imaginary parts would an error_mark_node. 2007-05-28 Andrew Pinski <[EMAIL PROTECTED]> PR c++/31339 * typeck.c (build_unary_op ): Return the error_mark_node if either the real or imaginary parts would an error_mark_node. 2007-05-28 Andrew Pinski <[EMAIL PROTECTED]> PR c/31339 * gcc.dg/boolcomplex-1.c: New test. PR c++/31339 * g++.dg/ext/boolcomplex-1.c: New test Added: trunk/gcc/testsuite/g++.dg/ext/boolcomplex-1.c trunk/gcc/testsuite/gcc.dg/boolcomplex-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31339
[Bug c/31339] [4.3 regression] ICE on invalid use of complex constant
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-05-29 00:25 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31339
[Bug other/32078] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes "libltdl: No such file or directory"
--- Comment #17 from rob1weld at aol dot com 2007-05-29 00:28 --- # cat /root/downloads/gcc-4_3-trunk/LAST_UPDATED Mon May 28 08:39:31 UTC 2007 (revision 125125M) Results for 4.3.0 20070528 (experimental) testsuite on i686-pc-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg01375.html Again, Java passed 100%, and I enabled a lot of options. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078
[Bug target/32134] Configuring stage 2 in ./intl fails checking for C compiler default output file name - C compiler cannot create executables
--- Comment #4 from rob1weld at aol dot com 2007-05-29 03:52 --- I got the reply "Zarro Boogs found." when I searched for: ungetc http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=ungetc&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= "C compiler cannot create executables" http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=%22C+compiler+cannot+create+executables%22&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= __sgetc_r http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=__sgetc_r&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32134
[Bug middle-end/32024] ICE - libgcc2.c:557: internal compiler error: in fold_checksum_tree, at fold-const.c:12652
--- Comment #8 from rob1weld at aol dot com 2007-05-29 03:57 --- For target i686-pc-linux-gnu it breaks at: /root/downloads/gcc-4_3-trunk/libgcc/../gcc/libgcc2.c: In function '__muldi3': /root/downloads/gcc-4_3-trunk/libgcc/../gcc/libgcc2.c:557: internal compiler error: in fold_checksum_tree, at fold-const.c:12652 For target i686-pc-cygwin it breaks at: $ cat /cygdrive/C/makecygwin/gcc-4_3-trunk/LAST_UPDATED Mon May 28 16:39:01 UTC 2007 (revision 125132) /cygdrive/C/makecygwin/gcc-4_3-trunk/configure --verbose --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --with-tune=athlon-xp --prefix=/usr --enable-objc-gc --enable-concept-checks --disable-multilib --with-gxx-include-dir=/usr/include/c++/4.3 --enable-libstdcxx-debug --enable-static --enable-shared --enable-initfini-array --enable-__cxa_atexit --enable-threads=posix --enable-version-specific-runtime-libs --enable-libssp --enable-libmudflap --enable-libgomp --disable-werror --enable-nls --with-included-gettext --enable-decimal-float --with-long-double-128 --enable-debug --enable-java-gc=boehm --with-x --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-java-awt=gtk,xlib --enable-gtk-cairo --enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-tool-wrappers --enable-portable-native-sync --enable-examples --enable-libgcj-multifile --with-stabs --enable-hash-synchronization --enable-gc-debug --enable-interpreter --with-system-zlib --enable-libada --with-tls --with-cpu=athlon-xp --with-arch=athlon-xp --enable-stage1-checking=assert,fold,gc,misc,rtl,rtlflag,runtime,tree /cygdrive/C/makecygwin/gcc-4_3-trunk/libgcc/../gcc/libgcc2.c: In function '__sgetc_r': /cygdrive/C/makecygwin/gcc-4_3-trunk/libgcc/../gcc/libgcc2.c:566: internal compiler error: in fold_checksum_tree, at fold-const.c:12652 I hope the two different spots help narrow down the one place where "fold" is broken (if that is what the problem is). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32024
[Bug bootstrap/31039] [4.3 Regression] Latest CVS-stage 2-Cannot create executables
--- Comment #8 from rob1weld at aol dot com 2007-05-29 04:15 --- I did just run Cygwin's setup.exe and tried a few sites - even kernel.org . You can't get an update that way. It will either be by SVN/CVS or apply the patches listed in the links above to your /cygwin directory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31039
[Bug target/32134] Configuring stage 2 in ./intl fails checking for C compiler default output file name - C compiler cannot create executables
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-29 04:22 --- (In reply to comment #4) > I got the reply "Zarro Boogs found." when I searched for: You are searching the summary, try the comment section instead. You get three bugs: PR 32134 PR 32024 PR 31039 The middle one if the ICE with fold checking (which I have not looked into yet). The first one is this bug, and the last one is the dup. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32134
[Bug libstdc++/31717] libstdc++-v3 - Make fails with: ./c++locale.h:69: error: '__locale_t' does not name a type
--- Comment #10 from rob1weld at aol dot com 2007-05-29 04:25 --- Thank you Benjamin. The next few days I am working to get 4.3.0 to compile on target Cygwin but I did update my 4.2.1 SVN and will check this out soon. I'll probably try to hack something so I don't have to run make for a few hours just to see if it fails momemts before the build is complete. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31717
