--- Comment #9 from ubizjak at gmail dot com 2007-09-20 06:51 ---
Created an attachment (id=14226)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14226&action=view)
Preprocessed inffast.c. Compile with -O2 -msse2 -ftree-vectorize
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
--- Comment #8 from ubizjak at gmail dot com 2007-09-20 06:49 ---
I can't confirm the failure (make check from zlib works OK for me), but there
is some suspicious code in inflate_fast(). When compiling (to be attached)
preprocessed testcase (using -O2 -msse2 -ftree-vectorize on i686), I
--- Comment #1 from eric dot paire at st dot com 2007-09-20 06:49 ---
Created an attachment (id=14225)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14225&action=view)
A simple source file showing the problem
Compile it with "gcc -c foo.c" and the warning is displayed.
--
htt
A function declared with __attribute__((noreturn)) ending with __asm__
statement should not warn "'noreturn' funtion does return", as the parser can
not understand what is within the last __asm__ statement.
--
Summary: Erroneous warning with __attribute__((noreturn))
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-09-20 03:36
---
I will have a look.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
As
--- Comment #1 from bangerth at dealii dot org 2007-09-20 03:35 ---
Confirmed. We use to error out but don't do any more with gcc4.1.2. icc
does produce an error, but Sun Studio doesn't (though I have other beef
with that latter compiler as well...)
W.
--
bangerth at dealii dot org
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-09-20 03:33
---
I am investigating.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
As
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-09-20 03:25
---
Un-assigning myself. No time at the moment
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2007-09-20
02:24 ---
Subject: Re: fallback scalbn doesn't handle denormals correctly
> For some reason, I had completely forgotten about ldexp(). But as it is C89,
> it
> should be available, and as all GCC supported targets
--- Comment #3 from rswan at signetic dot ca 2007-09-20 01:10 ---
(In reply to comment #2)
> I think this is a dup of bug 14933.
>
I agree. Sorry. Should I mark it as a duplicate?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33473
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-09-20 00:46 ---
I think this is a dup of bug 14933.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33473
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #5 from yuri at tsoft dot com 2007-09-19 23:37 ---
I would like to note that this isn't a clear-cut suggestion for the following
reasons:
* It's impossible to enforce such warning in all cases, only in case of virtual
functions immediately called from constructor/destructor.
--- Comment #3 from janis at gcc dot gnu dot org 2007-09-19 23:20 ---
A regression hunt on powerpc-linux using the submitter's test case identified
the following patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=115800
r115800 | lmillward | 2006-07-28 17:01:19 + (Fri, 28 Jul 2
extern int foo (char *) __attribute__ ((warn_unused_result));
extern int bar (char *) throw () __attribute__ ((warn_unused_result));
extern int bar (char *) throw ();
fails to compile with 4.2/4.3 (instead of warn_unused_result
any other attribute that has type_required set can be used, like nonnu
--- Comment #2 from patchapp at dberlin dot org 2007-09-19 23:15 ---
Subject: Bug number PR 33497
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-09/msg01583.html
--
http://gcc.gnu.org/bugzilla/s
As reported in http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01505.html
The spu target builtins are not GC safe.
--
Summary: Vectorizer (or spu target builtins) and PCH don't get
along
Product: gcc
Version: 4.3.0
Status: UNCONFIRME
--- Comment #6 from dannysmith at users dot sourceforge dot net 2007-09-19
21:52 ---
With 4.1, 4.2 and trunk, there is still no diagnosis of change in calling
convention in decl, but the bug in generated code is exposed only with
-fno-unit-at-time.
Danny
--
dannysmith at users dot
looks like there is an ugly bug in g++ front-end.
the problem can be demonstrated by the existing testcase:
ext/pb_ds/regression/trie_data_map_rand.cc
if you apply the following diff:
.../libstdc++-v3/testsuite/util/regression/rand/assoc/detail/ $ svn di
Index: insert_fn_imps.hpp
--- Comment #4 from dgregor at gcc dot gnu dot org 2007-09-19 21:45 ---
Here is the real fix:
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01544.html
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from dgregor at gcc dot gnu dot org 2007-09-19 21:45 ---
Here is the real fix:
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01544.html
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from gjunk at sapience dot com 2007-09-19 21:34 ---
Thanks for feedback - not exactly sure where this leaves things - but if gcc
can deliver the same kind of floating point performance as icc it would be a
really good thing.
The 2005 article - wasn't clear to me what that
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|other |bootstrap
ht
snapshot gcc-4.3-20070914
When i try to build gcc the process falls when it tries to use just created
binutils or gas. Investigating the problem I've found that libtool creates
"normal" binutils in binutils/.libs directory and creates a wrapper in binutils
directory for each util. The wrapper shoul
--- Comment #5 from joseph at codesourcery dot com 2007-09-19 19:54 ---
Subject: Re: Warning when passing a pointer to a const array
to a function that expects a pointer to a non-cast one
On Wed, 19 Sep 2007, jbeulich at novell dot com wrote:
> Isn't this the same as 16602 (which I d
--- Comment #2 from bangerth at dealii dot org 2007-09-19 19:11 ---
(In reply to comment #1)
> That this is missing in the requirement lists in 24.1.1 and 24.1.2 is probably
> due to the fact that it does not concern the Iterator class itself, but
> iterator_traits.
I disagree with thi
--- Comment #2 from william dot mitchell at nist dot gov 2007-09-19 19:07
---
If it helps, this bug was not in GNU Fortran (GCC) 4.3.0 20070531
(experimental)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33500
--- Comment #2 from bangerth at dealii dot org 2007-09-19 19:04 ---
As I've said in the other report, I believe you shouldn't rely on the
existence of iterator_traits for the iterator type. You should use the
return type of dereferencing the iterator.
W.
--
http://gcc.gnu.org/bugzi
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-19 18:58 ---
#define have to be understood by the front-end with -g3
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
~> gfortran -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /projects/tob/gcc/configure --enable-languages=c,fortran
--prefix=/projects/tob/gcc-trunk
Thread model: posix
gcc version 4.3.0 20070919 (experimental) [trunk revision 128597] (GCC)
~> cat fm.F
--- Comment #6 from kargl at gcc dot gnu dot org 2007-09-19 18:48 ---
I have a patch that in theory allows the repeat count
to be unlimited. I'll note that having a large repeat
count is a rather illogical thing to do, based on my
previous posts about compile time and size of executable
--- Comment #1 from singler at ira dot uka dot de 2007-09-19 18:42 ---
The standard states clearly (24.3.1):
"Accordingly, it is required that if Iterator is the type of an iterator, the
types
iterator_traits::difference_type
iterator_traits::value_type
iterator_traits::iterator_catego
--- Comment #1 from singler at ira dot uka dot de 2007-09-19 18:34 ---
Instead of std::plus, a functor should be used that accepts two different types
for LHS and RHS, Result and
std::iterator_traits::value_type, respectively.
--
singler at ira dot uka dot de changed:
Wha
--- Comment #13 from andreast at gcc dot gnu dot org 2007-09-19 18:09
---
Fixed
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #8 from andreast at gcc dot gnu dot org 2007-09-19 18:08
---
Fixed
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #2 from pcarlini at suse dot de 2007-09-19 17:59 ---
Hi again... A regression hunt would be useful for this one too...
--
pcarlini at suse dot de changed:
What|Removed |Added
-
--- Comment #27 from eweddington at cso dot atmel dot com 2007-09-19 17:57
---
Created an attachment (id=14224)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14224&action=view)
Rask's patch modified from comments.
Here is Rask's patch again, but slightly modified from the comment
--- Comment #1 from sfilippone at uniroma2 dot it 2007-09-19 17:29 ---
A version with an inner pointer to a derived type instead of allocatable array
fails as well.
-
module c_vhandle_mod
use iso_c_binding
type foo
integer :: i
end type foo
type foo_item
GCC 4.2.1 assumes that undefined classes have public copy constructors (at
least when they are used in template classes), as evidenced in the code below.
GCC 4.1.0 generates a compiler error for the same code.
begin gcc_error2.cpp
class A;
template
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-09-19 17:46
---
Confirmed on x86_64-linux.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2007-09-19 17:33
---
Don't we/can't we issue a warning here?
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jakub at gcc dot gnu dot org 2007-09-19 17:30 ---
I think the standard is very vague here.
First consider:
!$omp parallel default(none)
call something
!$omp do schedule(static, chunksize)
do i=1,100
call somethingelse
done
!$omp end do
!$omp end parallel
Do
--- Comment #4 from raeburn at raeburn dot org 2007-09-19 17:27 ---
(In reply to comment #3)
> I'm not convinced by the explanation in the comment. A pointer to array *is*
> compatible with the corresponding const pointer type; -Wcast-qual may apply
> too, but that's not exhibited in th
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-09-19 17:08 ---
(In reply to comment #3)
> Awesome: thanks for doing these PR's Wolfgang.
>
> Andrew, you mean the attribute?
No.
I mean something like:
int f(int n)
{
__extension__ int h[n];
h[n-1] = 0;
return h[n-1];
}
Wh
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
CC||bkoz at redhat dot com
Status|UNCONFIRMED |N
--- Comment #1 from bkoz at gcc dot gnu dot org 2007-09-19 17:07 ---
Wolfgang means "parallel mode" instead of debug mode.
This is confirmed.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirme
--- Comment #1 from bkoz at gcc dot gnu dot org 2007-09-19 17:06 ---
Mine.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at g
--- Comment #1 from bkoz at gcc dot gnu dot org 2007-09-19 17:05 ---
Mine.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at g
--- Comment #3 from bkoz at gcc dot gnu dot org 2007-09-19 17:05 ---
Awesome: thanks for doing these PR's Wolfgang.
Andrew, you mean the attribute?
It's my preference to use #pagma GCC system header for this. It does the least
amount of molestation.
However, it doesn't currently wor
[EMAIL PROTECTED]> cat bug070919.f90
subroutine whatever()
logical(kind=1) :: l1, l2, l3
if ((l1 .and. l2) .neqv. l3) then
l1 = .true.
endif
end
[EMAIL PROTECTED]> gfortran -c bug070919.f90
bug070919.f90: In function ‘whatever’:
bug070919.f90:1: internal compiler error: in copy_to_mode_reg, at
--- Comment #2 from bkoz at gcc dot gnu dot org 2007-09-19 16:59 ---
Also, this one.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
--- Comment #2 from bkoz at gcc dot gnu dot org 2007-09-19 16:59 ---
Hey Chalathip, thanks for your comments. I've fixed all of these except for:
> Suggestion: null_probe_fn class is missing.
As that file has no corresponding .svg file and thus I cannot edit it.
best,
benjamin
--
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
CC||bkoz at redhat dot com
Status|UNCONFIRMED |N
--- Comment #8 from rakdver at gcc dot gnu dot org 2007-09-19 16:56 ---
t #2)
> Technically the testcase invokes undefined behavior because 'val' overflows
> during loop execution. Practically from a QOI point of view the undefinedness
> should not propagate to the loop exit test (thoug
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-09-19 16:50 ---
And the code here is undefined as val does overflow.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rakdver at gcc dot gnu dot org 2007-09-19 16:45 ---
Mine.
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #5 from rask at gcc dot gnu dot org 2007-09-19 16:39 ---
table_init:
pushl %ebp# 51*pushsi2[length = 1]
movl$117835012, %eax# 20*movsi_1/1 [length = 5]
movl%esp, %ebp # 52*movsi_1/1 [length = 2]
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-09-19 16:35 ---
what happens when val is turned into unsgned?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
When I compile the module listed below I get the following messages:
c.f90:9.28:
MODULE PROCEDURE cx_cadr, cx_radc
1
Error: FUNCTION result cx_cadr can't be of type TYPE(cx) in FUNCTION cx_cadr at
(1)
c.f90:19.18:
END MODULE complex
1
Error: Containe
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-19 15:53 ---
Confirmed. IVOPTs chooses to replace the exit test by one that is true
only after signed overflow. SCEV/VRP happily optimizes this away.
:
ivtmp.52_2 = (long unsigned int) value_8;
# ivtmp.52_16 = PHI ;
# v
--- Comment #3 from rask at gcc dot gnu dot org 2007-09-19 16:12 ---
Technically, the code is undefined (overflow of signed integer val). Using -O2
-fno-strict-overflow results in a loop test, but the code looks dubious:
table_init:
pushl %ebp# 51*pushsi2[lengt
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-09-19 15:59 ---
Technically the testcase invokes undefined behavior because 'val' overflows
during loop execution. Practically from a QOI point of view the undefinedness
should not propagate to the loop exit test (though GCCs behav
--- Comment #4 from pcarlini at suse dot de 2007-09-19 15:17 ---
On it.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot g
gcc-4.2.0 and gcc-4.2.1 cannot compile properly this function if -O2 is
selected
It generates an infinite loop :(
No problem for previous version (gcc-4.1.2 is OK)
$ cat bug.c
void table_init(int *value)
{
int i;
int val = 0x03020100;
for (i = 0; i < 256/4; i++) {
--- Comment #3 from pcarlini at suse dot de 2007-09-19 14:43 ---
Thanks a lot!
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #13 from alex dot d at bugmenot dot com 2007-09-19 14:43
---
Created an attachment (id=14223)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14223&action=view)
consumes all memory when compiled with -O3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32199
--- Comment #12 from alex dot d at bugmenot dot com 2007-09-19 14:38
---
I've a similar problem when building SDL library (1.2.12), when using -O3
compilation flag. I'll try to attach an .i file that triggers the bug. After
starting the compilation, the memory starts getting consumed se
--- Comment #9 from jakub at gcc dot gnu dot org 2007-09-19 14:11 ---
Well, it is the Fortran standard that says free form comments start with !
And then OpenMP2.5 2.1.2 goes on and says certain forms of comments are not
to be treated as comments, but OpenMP directives etc.
One of them i
--- Comment #7 from dorit at gcc dot gnu dot org 2007-09-19 14:28 ---
(In reply to comment #6)
> It looks like
> zlib compiled w/ -O -msse -ftree-vectorize (built with fedora's rpm package
> gcc-4.1.2-17)
> has same problem.
> In my environment, rpm-4.4.2.1-7.fc8 and seamonkey-1.1.3-6.
--- Comment #10 from dir at lanl dot gov 2007-09-19 13:55 ---
It looks like it is now only a Macintosh PowerPC version problem. It also works
Ok on the Intel Macintosh and on the MSYS versions of gfortran.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33408
--- Comment #2 from janis at gcc dot gnu dot org 2007-09-19 14:15 ---
A regression hunt on powerpc-linux using the submitter's test case identified
the following patch where the test starts failing:
http://gcc.gnu.org/viewcvs?view=rev&rev=126399
r126399 | mmitchel | 2007-07-06
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #8 from burnus at gcc dot gnu dot org 2007-09-19 13:46 ---
(In reply to comment #6)
> > Pedantically this is not a bug. If an omp sentinel doesn't have the desired
> > form, it should be handled as a normal comment.
I cannot find anything about this in the OpenMP spec; I thi
--- Comment #9 from dir at lanl dot gov 2007-09-19 13:39 ---
It works Ok on my version of linux, but it still is crashing on today's
Macintosh PowerPC version (20070919) -
[dranta:~/fe/dyna3d96/source] dir% gfortran -g -c -O0 -fcray-pointer
-fno-automatic out.f
outt.F:31
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-09-19 13:18
---
(In reply to comment #6)
> As this PR shows, this user error happens easily, if one converts a fixed-form
> into a free-form code. Thus I'm in favour of printing a warning or - as ifort
> and sunf95 do - an error.
--- Comment #4 from dominiq at lps dot ens dot fr 2007-09-19 12:38 ---
Subject: Re: Add one digit to the default formatted output
> Dominique, what is the output of your test program on ppc-darwin?
real(4)
default 808
1PG20.61881
1PG20.7 808
1PG20.8
--- Comment #7 from jakub at gcc dot gnu dot org 2007-09-19 12:55 ---
This no longer reproduces on the trunk since
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128272
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33140
--- Comment #8 from dir at lanl dot gov 2007-09-19 12:47 ---
Still Crashing on the 20070917 version -
[dranta:~/fe/dyna3d96/source] dir% gfortran -fcray-pointer -fno-automatic -g
-O0 -c -DSGI -DWKSTN -DUNIX -DVECLEN=32 -DDP out.f
outt.F:3155.19:
common/aux14/
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
See http://gcc.gnu.org/ml/fortran/2007-09/msg00301.html
for the initial bug report by Salvatore Filippone (thanks for finding the bug!)
and a longer example.
Assume the following code:
type double_vector_item
real(c_double), allocatable :: v(:)
end type double_vector_item
type(double_ve
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-09-19 11:52
---
Mine. A straightforward patch following the idea laid in my previous comment
fixes it.
Index: arith.c
===
--- arith.c (revision 128540)
+++ ari
--- Comment #3 from bonzini at gnu dot org 2007-09-19 11:46 ---
I'm not convinced by the explanation in the comment. A pointer to array *is*
compatible with the corresponding const pointer type; -Wcast-qual may apply
too, but that's not exhibited in the test case.
--
bonzini at gnu
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Severity|enhancement |normal
Component|fortran |libfortran
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-09-19 09:54
---
(In reply to comment #0)
> Following a discussion on IRC with FX Coudert, I think the number of digits
> printed by default in formatted output should be increased by one.
Dominique, what is the output of your te
--- Comment #4 from schwab at suse dot de 2007-09-19 09:47 ---
*** This bug has been marked as a duplicate of 16602 ***
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #2 from schwab at suse dot de 2007-09-19 09:47 ---
*** Bug 33076 has been marked as a duplicate of this bug. ***
--
schwab at suse dot de changed:
What|Removed |Added
-
--- Comment #2 from E dot Kuemmerle at fz-juelich dot de 2007-09-19 09:40
---
Here is a self-contained example:
template
class Vector {
public:
explicit Vector() {}
~Vector() {}
private:
T m_data[Sz];
};
int main() {
Vector a[10];
--- Comment #3 from jbeulich at novell dot com 2007-09-19 09:39 ---
Isn't this the same as 16602 (which I don't really understand why it was
rejected as invalid)? Also, if this *is* invalid, then what proper mechanism
does one have to express what is intended here? And why does similar c
--- Comment #3 from tbm at cyrius dot com 2007-09-19 09:21 ---
Still there as of trunk 20070916.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33133
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-09-19 09:16
---
For some reason, I had completely forgotten about ldexp(). But as it is C89, it
should be available, and as all GCC supported targets now have (FLT_RADIX ==
2), it should fix the problem. John, could you confirm t
--
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=33496
The following invalid code snippet triggers an ICE on mainline:
==
template void foo()
{
sizeof...N();
}
void bar()
{
foo<0>();
}
==
bug1.cc: In function 'void foo()':
bug1.cc:3: error: 'N' cannot be used
95 matches
Mail list logo
