--- Comment #7 from pinskia at gcc dot gnu dot org 2007-04-29 08:01 ---
Can you try this again, I think this was related to PR 30567 which was just
fixed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30252
(This is similar to PR 27371)
When a function or method has attribute warn_unused_result, and the return type
has a destructor, gcc does not emit a warning. gcc 4.0.3 emitted a warning;
gcc 4.1.2 does not; gcc 4.3-20070427 does not.
[EMAIL PROTECTED]:~/exp-warn-unused-result$ cat warn.cc
int Alp
--- Comment #8 from belyshev at depni dot sinp dot msu dot ru 2007-04-29
09:58 ---
Created an attachment (id=13461)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13461&action=view)
self contained preprocessed testcase
(In reply to comment #7)
> Can you try this again, I think thi
--- Comment #11 from steven at gcc dot gnu dot org 2007-04-29 10:07 ---
This will not be backported to GCC 4.1.
Thanks for catching this, it's very helpful to find bugs that won't be resolved
in released compilers. There are already enough bugs in Bugzilla that do have
to be fixed, so
--- Comment #2 from rob1weld at aol dot com 2007-04-29 10:51 ---
Prevously I posted: "I will post the build-log shortly and put a link on this
page ..."
I finally got it compiled (using an enormous number of features) and got my
best results yet for Java:
=== libjava Su
--- Comment #2 from rob1weld at aol dot com 2007-04-29 11:05 ---
Dear Andrew: I am sorry I did not include my "gcc -v" in the report.
Judging from the date I _MIGHT_ have used one of these configure lines:
/cygdrive/C/makecygwin/gcc-4_2-branch/configure --disable-werror --verbose
--tar
--- Comment #3 from rob1weld at aol dot com 2007-04-29 11:13 ---
I am going to change the resolution to "WORKSFORME". This does not mean that
whatever problem that occurred at _that_ particular time was actually fixed,
only that I am not able to reproduce it with the __current__ SVN (nor
--- Comment #1 from rob1weld at aol dot com 2007-04-29 11:25 ---
I completed all tests. Current SVN builds on Linux "OK", but has "internal
compiler error" when build with "_similar_" (but not "same") options on Cygwin
platform (when it gets to libstdc++-v3).
Full results at this link:
The following invalid code snippet triggers an ICE since GCC 4.0.0:
===
typedef int A[];
A* p = new A;
===
bug.cc:2: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in extract_muldiv_1, at fold-const.c:5661
Please submit
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31743
I recall Ada compiling with very few warnings on the Cygwin platform. I
recently added Linux to my list of platforms (did not notice these warnings
when compiling for Linux - may or may not be present on Linux platform):
I compiled this on Cygwin with this GCC:
$ gcc -v
Reading specs from /usr/li
The following invalid code snippet triggers an ICE on mainline:
===
void foo()
{
namespace N {
===
bug.cc: In function 'void foo()':
bug.cc:3: error: 'namespace' definition is not allowed here
bug.cc:3: internal compiler error: in cp_lexer_consume_token, at
cp/pa
--
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=31745
This occurs on platforms i686-pc-linux-gnu _AND_ i686-pc-cygwin but I can only
choose to report for a single platform at a time. I will not file a second
identical report for i686-pc-cygwin, just this one report.
The file gcc/configargs.h does not get made properly. That causes the compiler
to not
--- Comment #4 from jb at gcc dot gnu dot org 2007-04-29 11:46 ---
I don't think you can use memset for populating real arrays except when the
value is 0.0; the bit patterns would be different, as memset takes an int
argument which is actually converted to unsigned char.
AFAIK the libc
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-04-29 11:46
---
Subject: Bug 31645
Author: fxcoudert
Date: Sun Apr 29 11:45:57 2007
New Revision: 124274
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124274
Log:
PR fortran/31645
* scanner.c (load_file
The following invalid code snippet triggers an ICE on mainline and the
4.2 branch::
static extern int i;
bug.cc:1: error: conflicting specifiers in declaration of 'i'
bug.cc:1: internal compiler error: in start_decl, at cp/decl.c:3985
Please submi
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31747
A bad diagnostic is issued on mainline and the 4.2 branch for the following
code snippet (compile with -fopenmp):
struct A;
void foo()
{
#pragma omp parallel private(A)
;
}
bug.cc: In function 'void foo()':
bug.cc:5: error: '#'type_decl' not su
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31748
The following invalid code snippet triggers a segfault since GCC 3.1:
namespace std
{
union abort;
}
void abort();
using std::abort;
bug.cc:8: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
Compiling the c
On the fatigue benchmark of the polyhedron benchmark suite, gfortran spends ~8%
of the total runtime on the line
40215 7.8856 : generalized_constitutive_tensor(:,:) = 0.0_LONGreal
(The numbers are oprofile data)
generalized_constitutive tensor is a local 6x6 double precision array. No
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31749
--- Comment #1 from jb at gcc dot gnu dot org 2007-04-29 12:14 ---
Jakub made a related patch a while ago:
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg01134.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31750
The following invalid code snippet triggers an ICE since GCC 4.0.0:
==
struct A
{
int i;
};
template int A::foo(int T::*) { return 0; }
int j = A::foo(&A::i);
==
bug.cc:6: error: no
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31751
The following invalid code snippet triggers an ICE since at least GCC 2.95.3:
==
void foo()
{
struct { int bar(); } x;
asm("" : "=m" (x.bar));
}
==
bug.cc: In function 'void foo()':
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-04-29 12:31
---
Fixed
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
$gcc -Wall -O1 -g -fno-strict-aliasing -mpreferred-stack-boundary=2
-fomit-frame-pointer -falign-functions=0 -fno-gcse -fno-reorder-blocks
-fno-optimize-sibling-calls -I. -I..
-I/usr/src/ark/BUILD/qemu-0.9.0/target-i386 -I/usr/src/ark/BUILD/qemu-0.9.0
-I/usr/src/ark/BUILD/qemu-0.9.0/linux-user
-I/
--- Comment #1 from bero at arklinux dot org 2007-04-29 12:40 ---
Created an attachment (id=13462)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13462&action=view)
Preprocessed source
Attaching preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31753
--- Comment #3 from tbm at cyrius dot com 2007-04-29 13:36 ---
Janis, can you do a regression hunt on this one?
--
tbm at cyrius dot com changed:
What|Removed |Added
--- Comment #7 from kkojima at gcc dot gnu dot org 2007-04-29 13:41 ---
Fixed.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
Often we have compile errors on long lines of code, it is time-consuming to
find the actual character offset on the long line which is causing the error.
Sometimes it is even necessary to separate out long if(..) statements, so we
can figure out which part of the long line has the problem in the er
Could the warning message below be revised to include a warning that NULL will
evaluate to false or zero?
In addition, is there a way to add the member name which is being initialised
to the warning? The line numbers are not accurate too, so it needs some
inspection to figure out the members conce
Given the following Fortran source:
SUBROUTINE SUB(A, B, N, M)
DIMENSION A(N, M), B(N, M)
DO I = 1, N
DO J = 1, M
A(I, J) = B(I, J)
ENDDO
ENDDO
END
It should be vectorized using the following compile time options:
-O2 -ftree-vectorize -
Could argument names be included in warning messages when they are available?
This is the present output:
$ g++ -Wall -o t main.cpp
main.cpp: In function int main():
main.cpp:12: warning: passing NULL to non-pointer argument 2 of void f(int,
bool, bool, int, unsigned int)
main.cpp:12: warning:
GCC presently does not issue a warning for missing include directories
specified. Could one be added? Or perhaps there is a reason it is not being
checked at present that I am not aware of
This compiles fine:
g++ -Wall -I./MissingIncludeDir main.cpp
--
Summary: Issue warning about mi
--- Comment #8 from reichelt at gcc dot gnu dot org 2007-04-29 15:54
---
This bug is already fixed on the 4.1 branch since GCC 4.1.2,
whereas PR 20103 is still open on the 4.1 branch, so this is not quite a
duplicate of PR 20103.
--
reichelt at gcc dot gnu dot org changed:
--- Comment #9 from reichelt at gcc dot gnu dot org 2007-04-29 15:55
---
Closing as fixed in GCC 4.1.2.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from dberlin at gcc dot gnu dot org 2007-04-29 16:05 ---
PRE optimized the "offset" and "stride" variables.
SCEV doesn't know how to create an offset or step out of these optimized
operations. We used to at some point, but I believe these are "peeled_chrec's"
that we remo
The following testcase (similar to PR26913) triggers an ICE on mainline:
=
struct A
{
~A() throw();
};
void foo(A);
void bar()
{
#pragma omp parallel
{
A a;
foo(a);
}
}
=
bug.cc: In function 'void _Z3barv.omp_fn
--- Comment #2 from spop at gcc dot gnu dot org 2007-04-29 16:21 ---
Subject: Re: Doesn't optimize the following (obvious) sequence
> PRE optimized the "offset" and "stride" variables.
> SCEV doesn't know how to create an offset or step out of these optimized
> operations.
I remember
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
|
--
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=31759
--- Comment #2 from reichelt at gcc dot gnu dot org 2007-04-29 16:31
---
Expanding the testcase a little one can also trigger ICEs, e.g.:
==
template struct A
{
template struct A
{
template void foo() {}
};
};
==
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Summary|Include character count |Include c
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-29 16:47 ---
There is already an option for this which was added in 4.0.0:
-Wmissing-include-dirs
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-04-29 16:55 ---
A reduced testcase not from the attached testcase but from understanding where
the array type is being created:
struct ac {ac();};
ac spline_rep1(void)
{
typedef ac at[2];
ac * b = new ac[2];
at *a = (at*)b;
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-04-29 16:56 ---
I have a fix:
Index: init.c
===
--- init.c (revision 124182)
+++ init.c (working copy)
@@ -1624,6 +1624,7 @@
if (nelts)
{
tree
The gfortran intrinsics ERF,BESXX cannot be used as elemental.
--
Summary: missing elemental applicability
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
Assigne
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-29 16:59 ---
What version of sed do you have? I don't have this issue on i686-linux-gnu or
powerpc64-linux-gnu boxes at all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31746
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2007-04-29 17:04
---
Subject: Bug 31591
Author: fxcoudert
Date: Sun Apr 29 17:03:58 2007
New Revision: 124281
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124281
Log:
PR fortran/31591
* simplify.c (simplif
--- Comment #2 from rob1weld at aol dot com 2007-04-29 17:12 ---
# sed --version
GNU sed version 4.1.5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31746
Make fails near the end of a three stage build with an internal compiler error.
$ gcc/xgcc -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ../gcc-4_2-branch/configure --verbose
--enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --with-tune=athlon-xp
--prefix=/usr --enable-objc
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2007-04-29 17:36
---
Fixed on mainline.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from steven at gcc dot gnu dot org 2007-04-29 17:50 ---
Why is this a bug in your opinion? ERF and the Bessel functions are MIL/GNU
extensions. I don't think there's a standard that requires these functions to
be elemental. Do you think this is a bug because the functio
--- Comment #2 from highegg at gmail dot com 2007-04-29 18:03 ---
(In reply to comment #1)
> Why is this a bug in your opinion? ERF and the Bessel functions are MIL/GNU
> extensions. I don't think there's a standard that requires these functions to
> be elemental. Do you think this is
--
highegg at gmail dot com changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31760
--- Comment #3 from kargl at gcc dot gnu dot org 2007-04-29 18:12 ---
This falls into the enhancement request category, and I agree that
these functions should be elemental. I'll also note that the gfortran
documentation claims that these functions are already elemental.
--
kargl at
--- Comment #3 from rob1weld at aol dot com 2007-04-29 18:19 ---
The problem seems to be that the ./configure script is including
"--enable-languages" TWO times and the second time it is NOT quoting it - thus
breaking sed.
# grep _configargs ../gcc-4_2-build/config.log
build_configargs
jmin = jmin + NPY(i) + 1
ENDDO
ENDDO
END
Compiler version: gcc version 4.3.0 20070429 (experimental)
--
Summary: ICE in tree-dfa.c:791 with -ftree-loop-linear (and -O1 -
ffast-math)
Product: gcc
Version: 4.3
--- Comment #4 from schwab at suse dot de 2007-04-29 19:06 ---
It looks like you have modified configure. Please try again with an unmodified
configure.
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #1 from pcarlini at suse dot de 2007-04-29 19:13 ---
Being an ICE, cannot be a library issue.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #2 from schwab at suse dot de 2007-04-29 19:20 ---
Confirmed. Only happens with -Os.
--
schwab at suse dot de changed:
What|Removed |Added
Status
--- Comment #2 from dannysmith at users dot sourceforge dot net 2007-04-29
19:43 ---
Your configure options may be at fault. In particular you
'--disable-sjlj-exceptions'. Well, sjlj is the only kind of exceptions that
cygwin supports, unless you modified gcc sources.
Danny
--
h
--- Comment #2 from ajrobb at bigfoot dot com 2007-04-29 19:51 ---
Thanks,
I'd forgotten that you can only alias through char* (or types related to the
operand).
Given that "A character type may alias any other type.",
I suppose I should be able to use (it works):
memcpy(&out->fraction
--- Comment #3 from schwab at suse dot de 2007-04-29 19:56 ---
Created an attachment (id=13463)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13463&action=view)
Reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30663
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-04-29 19:58
---
> Given that "A character type may alias any other type.",
> I suppose I should be able to use (it works):
>
> memcpy(&out->fraction, &value, 4);
> memcpy(&out->mantissa, 4+(char*)&value, 4);
> out->mantissa &= 0
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-04-29 19:58 ---
Do you have a testcase that shows this behavior gcc vs. other?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31750
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-04-29 20:06 ---
Confirmed. That ICE is from the TODO of .
-ftree-loop-linear
doesn't change any code ("Won't transform loop. Optimal transform is the
identity transform"), but still seems to have this side-effect.
--
rguenth at
when compiling this program with gcc 4.3 snapshot 2007/04/27,
#include
int main(){
std::cout << "Hello world!" << std::endl;
}
cc1plus failed to locate the headers stddef.h and stdargs.h:
Using built-in specs.
Target: x86_64-linux
Configured with: ../gcc-4.3-20070427/configure --prefix
--- Comment #3 from jb at gcc dot gnu dot org 2007-04-29 20:19 ---
Hmm, try e.g. the following (with gfortran the fixed sized arrays can use
builtin_memset whereas the allocatable arrays are done with a loop. Save as
.F90 (capital F) to force preprocessing to set the SZ macro.
! Test pe
--- Comment #8 from mstein at phenix dot rootshell dot be 2007-04-29 20:19
---
(In reply to comment #6)
> Fixed on mainline and 4.2 branch.
Hi Ian,
I still get this bug on the mainline(124261) for the avr,frv,h8300,m32c,m68hc11
and mips.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-04-29 20:23 ---
I think I know what causes this, and I'll take this on.
An expedition into the front-end :-)
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from dberlin at gcc dot gnu dot org 2007-04-29 20:31 ---
Subject: Re: Doesn't optimize the following (obvious) sequence
On 29 Apr 2007 15:21:40 -, spop at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #2 from spop at gcc dot gnu dot org 2007-0
--- Comment #4 from schwab at suse dot de 2007-04-29 20:37 ---
This is no longer reproducible with current mainline.
--
schwab at suse dot de changed:
What|Removed |Added
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
CC||dfranke at gcc dot gnu dot
|
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-04-29
21:45 ---
Subject: Re: FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and
above
> This failure was introduced between revisions 123512 and 123536.
See report of similar failures spu-elf:
http://gcc.gnu.o
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2007-04-29
21:46 ---
Subject: Re: New: FAIL: gcc.c-torture/execute/bf64-1.c execution at -Os and
-O3
See report of similar failures spu-elf:
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01036.html
Dave
--
http://gcc.gnu
--- Comment #5 from tkoenig at gcc dot gnu dot org 2007-04-29 21:59 ---
Created an attachment (id=13464)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13464&action=view)
Proposed patch
This fixes the test case.
Currently regtesting.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-04-29 22:21 ---
These functions are correctly marked as ELEMENTAL, but the assigned check
functions make sure that only scalars are passed. The patch is simple and
currently regtesting.
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #5 from schwab at suse dot de 2007-04-29 23:17 ---
That was fixed in mainline at revision 122520.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30663
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-04-29 23:41
---
I am not getting a segfault on this. Maybe it fixed itself? :)
[EMAIL PROTECTED] test]$ gfc pr31251.f90
pr31251.f90:1.16:
character(len=2.3) :: s
1
Error: Expression at (1) must be of INTEGER t
--- Comment #1 from bangerth at dealii dot org 2007-04-30 00:01 ---
I believe the current approach is pretty much the only thing that
can be implemented reliably, because you could write code like this:
---
int f(int i, int j);
int f(int j, int i);
int g = f(1,2);
--
--- Comment #3 from rob1weld at aol dot com 2007-04-30 00:14 ---
Did some more testing. The results that follow are from the output of a shell
script to catch each error and defeat it. I have edited it down for this
report.
There is a bug in gcc-4_2 in that it won't let you make a new A
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
CC||dfranke at gcc dot gnu dot
|
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-04-30 00:53
---
I see why we are getting two error messages. There is a recursive call going
on here, Probably not a good idea. I will see if I can sort this out.
--
jvdelisle at gcc dot gnu dot org changed:
W
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-04-30 01:11 ---
Pierre, using your example from comment #2, would you consider
subroutine abc()
1
Error: MODULE attribute of 'abc' conflicts with PROCEDURE attribute at (1)
an improvem
--- Comment #9 from bangerth at dealii dot org 2007-04-30 03:25 ---
I can't reproduce this with neither r124272 nor r124284. What flags exactly do
you use?
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-30 06:09 ---
C_INCLUDE_PATH="$GCC_PATH/include:$GCC_PATH/lib/gcc/x86_64-linux/4.3.0/include"
CPLUS_INCLUDE_PATH="$C_INCLUDE_PATH"
This is a bad idea, they are automatically included already.
--
http://gcc.gnu.org/bugzilla/s
--- Comment #4 from anglade at gmail dot com 2007-04-30 07:37 ---
>
> subroutine abc()
> 1
> Error: MODULE attribute of 'abc' conflicts with PROCEDURE attribute at (1)
Hi,
Yes this is already much more clear. Yet I wonder if "MODULE attribute of
'abc'" could be changed in
91 matches
Mail list logo
