The run-time library has:
static const GFC_INTEGER_4 kiss_size =
sizeof(kiss_seed)/sizeof(kiss_seed[0]);
if (((put->dim[0].ubound + 1 - put->dim[0].lbound)) < kiss_size)
runtime_error ("Array size of PUT is too small.");
It would be great if the size could already be checked at co
--- Comment #12 from jv244 at cam dot ac dot uk 2008-08-19 06:11 ---
Created an attachment (id=16096)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16096&action=view)
ifort's asm for PR31079_11.f90 at -O3 -xT -S
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31079
--- Comment #11 from jv244 at cam dot ac dot uk 2008-08-19 06:09 ---
Created an attachment (id=16095)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16095&action=view)
new testcase
This (PR31079_11.f90) should be a replacement for comment #4, and illustrates
the vectorizer issue.
--- Comment #13 from burnus at gcc dot gnu dot org 2008-08-19 06:02 ---
Subject: Bug 35863
Author: burnus
Date: Tue Aug 19 06:00:51 2008
New Revision: 139223
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139223
Log:
2008-08-19 Tobias Burnus <[EMAIL PROTECTED]>
PR libf
--- Comment #10 from jv244 at cam dot ac dot uk 2008-08-19 05:45 ---
Created an attachment (id=16094)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16094&action=view)
comment #0 intel's assembly (ifort 9.1 at -O2 -xT)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31079
--- Comment #9 from jv244 at cam dot ac dot uk 2008-08-19 05:44 ---
Created an attachment (id=16093)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16093&action=view)
comment #0 source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31079
--- Comment #8 from jv244 at cam dot ac dot uk 2008-08-19 05:43 ---
(In reply to comment #7)
> That is, GCCs inner loop is
>
> .L6:
> addl$1, %eax
> addsd %xmm12, %xmm11
> cmpl$1, %eax
> addsd %xmm14, %xmm3
> addsd %xmm15, %x
[EMAIL PROTECTED] i386]$ cat x.c
/* { dg-do run } */
/* { dg-options "-O2 -msse2" } */
#include
int
test (__m128d s1, __m128d s2)
{
return _mm_comieq_sd (s1, s2);
}
[EMAIL PROTECTED] i386]$ ./usr/gcc-4.4/bin/gcc -S -O2 x.c
[EMAIL PROTECTED] i386]$ cat x.s
.file "x.c"
.text
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-08-19 02:40
---
Closing as invalid. If anyone sees a reason to re-open, please let me know.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #12 from manu at gcc dot gnu dot org 2008-08-19 02:33 ---
The key difference is -ftree-vrp (which is enabled at -O2). With INIT=2, it is
missing the obvious optimization that it detects with INIT=1. I wonder if this
is expected (after all, it is value-RANGE-propagation) or th
--- Comment #11 from vincent at vinc17 dot org 2008-08-19 01:31 ---
(In reply to comment #10)
> If I replace the value 2 by 1 I still get the warning in GCC 4.4, so that
> really sounds strange. Are you sure about that?
Yes and here Debian's GCC 4.4 snapshot has the same behavior as GCC
--- Comment #1 from hjl dot tools at gmail dot com 2008-08-19 01:25 ---
It may be caused by revision 138553.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
[EMAIL PROTECTED] i386]$ cat x.c
/* { dg-do run } */
/* { dg-options "-O2 -msse2" } */
#include
__m128i
__attribute__((noinline, unused))
test (__m128i s1, __m128i s2)
{
return _mm_unpackhi_epi64 (s1, s2);
}
[EMAIL PROTECTED] i386]$
/export/build/gnu/gcc-stack-internal/build-x86_64-linux/gcc/
--- Comment #5 from cw at f00f dot org 2008-08-19 00:42 ---
(From update of attachment 16091)
doesn't show the hang as __attribute__ is missing
--
cw at f00f dot org changed:
What|Removed |Added
-
--- Comment #4 from cw at f00f dot org 2008-08-19 00:41 ---
Created an attachment (id=16092)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16092&action=view)
updated test case that actually shows the hang
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37156
--- Comment #3 from cw at f00f dot org 2008-08-19 00:38 ---
Someone was able to reproduce the hang and pointed out the first attachment I
put up as edited without the __attribute__
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/us
--- Comment #10 from manu at gcc dot gnu dot org 2008-08-18 23:38 ---
(In reply to comment #9)
> (In reply to comment #8)
> > Please provide a preprocessed reduced testcase as similar to the original as
> > possible.
>
> Here's a similar testcase.
Thanks.
This is the optimized SSA du
--- Comment #2 from hjl dot tools at gmail dot com 2008-08-18 23:24 ---
The particular insn is
(insn 72 70 73 8 x.i:17 (set (reg:SI 386)
(minus:SI (subreg:SI (reg/f:DI 376 [ ivtmp.14 ]) 0)
(subreg:SI (reg/f:DI 335 virtual-stack-vars) 0))) 165 {subsi3}
(nil))
(gdb) f
--- Comment #1 from hjl dot tools at gmail dot com 2008-08-18 23:07 ---
Revision 139207:
http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg00769.html
is the cause.
[EMAIL PROTECTED] gcc]$ cat x.i
extern int printf (__const char *__restrict __format, ...);
extern void dw2_asm_output_data_raw (i
--- Comment #9 from vincent at vinc17 dot org 2008-08-18 22:58 ---
(In reply to comment #8)
> Please provide a preprocessed reduced testcase as similar to the original as
> possible.
Here's a similar testcase.
$ cat tst.c
void *foo (void);
void bar (void *);
void f (void)
{
int ini
--- Comment #5 from wrobell at pld-linux dot org 2008-08-18 22:40 ---
(In reply to comment #4)
> >gdb claims that problem is at line 2285, variable "accumulator" is 0x0,
>
> well with optimization, debugging info is not always fully correct.
>
i've changed function declaration again t
--- Comment #2 from cw at f00f dot org 2008-08-18 22:37 ---
(sorry, this should have been clarified earlier)
-O1 -g is fine
-O2 is fine
-O2 -g HANGS
dropping __attribute__((warning...) also makes the hang go away --- so
interaction with that an debugging?
gcc 4.1 is fine
gcc 4.2 is fi
--- Comment #1 from cw at f00f dot org 2008-08-18 22:34 ---
Created an attachment (id=16091)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16091&action=view)
malloc.i hangs with -O2 -g on gcc 4.3.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37156
[EMAIL PROTECTED]:~/wk/sqlite-cvs-git/build$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.1-2'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-sha
Gcc 4.4 revision 139215 failed to bootstrap on Linux/ia64:
/export/gnu/import/svn/gcc-test/bld/./prev-gcc/xgcc
-B/export/gnu/import/svn/gcc-test/bld/./prev-gcc/
-B/usr/local/ia64-unknown-linux-gnu/bin/ -c -DUSE_LIBUNWIND_EXCEPTIONS -g -O2
-DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -W
--- Comment #9 from sje at cup dot hp dot com 2008-08-18 21:51 ---
Kevin, I can no longer reproduce this bug. I think it was fixed by the same
patch that fixed PR 35659. Are you able to reproduce this or can we close it
as fixed?
--
sje at cup dot hp dot com changed:
Wh
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-08-18 21:11 ---
>gdb claims that problem is at line 2285, variable "accumulator" is 0x0,
well with optimization, debugging info is not always fully correct.
--
pinskia at gcc dot gnu dot org changed:
What|Remove
--- Comment #3 from wrobell at pld-linux dot org 2008-08-18 21:06 ---
Created an attachment (id=16090)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16090&action=view)
gsignal.s file after 'inline' keyword removal
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37154
--- Comment #2 from wrobell at pld-linux dot org 2008-08-18 21:05 ---
Created an attachment (id=16089)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16089&action=view)
gsignal.s file created by gcc before 'inline' keyword removal
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #1 from wrobell at pld-linux dot org 2008-08-18 21:05 ---
Created an attachment (id=16088)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16088&action=view)
gsignal.i file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37154
i am getting SIGSEGV while starting two glib2 applications.
please take a look at glib2/gogject/gsignal.c code:
-
2280 gboolean continue_emission;
2281
2282 if (!accumulator)
2283return TRUE;
2284
2285 continue_emission = accumulator->func (ihint, return_accu
--- Comment #5 from dfranke at gcc dot gnu dot org 2008-08-18 20:56 ---
Reminder: libbackend.a(cpp_include_defaults) seems to be the place where
standard include paths for targets are available -- including, but not limited
to, /usr/include.
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #10 from dfranke at gcc dot gnu dot org 2008-08-18 20:51
---
Closing as WONTFIX.
Reference:
http://gcc.gnu.org/ml/fortran/2008-08/msg00071.html
(and following).
(Updated) Documentation about gfortran's behaviour with preprocessing can be
found in sections 1.3 and 2.3 o
--- Comment #9 from dfranke at gcc dot gnu dot org 2008-08-18 20:47 ---
Subject: Bug 37032
Author: dfranke
Date: Mon Aug 18 20:46:08 2008
New Revision: 139215
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139215
Log:
2008-08-18 Daniel Franke <[EMAIL PROTECTED]>
PR fo
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36998
--- Comment #2 from hjl dot tools at gmail dot com 2008-08-18 20:15 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #1 from dorit at gcc dot gnu dot org 2008-08-18 20:11 ---
(In reply to comment #0)
> I just tried to compile GNU CC version 4.4 snapshot 20080815 with the
> Intel C compiler and it said
> gcc/tree-vect-transform.c(2488): warning #187: use of "=" where "==" may have
> been int
--- Comment #1 from hjl at gcc dot gnu dot org 2008-08-18 19:50 ---
Subject: Bug 37153
Author: hjl
Date: Mon Aug 18 19:48:41 2008
New Revision: 139211
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139211
Log:
2008-08-18 H.J. Lu <[EMAIL PROTECTED]>
PR bootstrap/37153
On Linux/x86-64, I got
cc1: warnings being treated as errors
../../src-trunk/gcc/value-prof.c: In function ‘check_counter’:
../../src-trunk/gcc/value-prof.c:469: error: cast from pointer to integer of
different size
../../src-trunk/gcc/value-prof.c:478: error: cast from pointer to integer of
diffe
--- Comment #20 from manu at gcc dot gnu dot org 2008-08-18 18:56 ---
*** Bug 36814 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from manu at gcc dot gnu dot org 2008-08-18 18:56 ---
possible_bug.cc:1: error: `cMyClass' has not been declared
possible_bug.cc: In function `bool Init()':
possible_bug.cc:5: error: `some_function' was not declared in this scope
possible_bug.cc:5: warning: unused variable
I just tried to compile GNU CC version 4.4 snapshot 20080815 with the
Intel C compiler and it said
gcc/tree-vect-transform.c(2488): warning #187: use of "=" where "==" may have
been intended
The source code is
gcc_assert (ncopies = 1);
Perhaps
gcc_assert (ncopies == 1);
was intended ?
--- Comment #3 from manu at gcc dot gnu dot org 2008-08-18 18:28 ---
This is hard. Even the simple cases are hard since the error is detected very
very late. There are far too many ways to declare anything. Perhaps using a
slightly different code patch for C99 would help with -std=c99.
--- Comment #4 from jellegeerts at gmail dot com 2008-08-18 18:16 ---
Please see the attachments I created for more information.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36814
--- Comment #3 from jellegeerts at gmail dot com 2008-08-18 18:15 ---
Created an attachment (id=16087)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16087&action=view)
the `.ii' file that G++ created
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36814
--- Comment #2 from jellegeerts at gmail dot com 2008-08-18 18:14 ---
Created an attachment (id=16086)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16086&action=view)
output of G++ with the `-v -save-temps' flags
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36814
--- Comment #13 from manu at gcc dot gnu dot org 2008-08-18 17:51 ---
Let's give meaningful short descriptions to the bugs, please.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from paolo dot carlini at oracle dot com 2008-08-18 17:50
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Target Mileston
--- Comment #5 from paolo at gcc dot gnu dot org 2008-08-18 17:49 ---
Subject: Bug 37149
Author: paolo
Date: Mon Aug 18 17:48:15 2008
New Revision: 139206
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139206
Log:
2008-08-18 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #5 from manu at gcc dot gnu dot org 2008-08-18 17:48 ---
These are two different bugs.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from manu at gcc dot gnu dot org 2008-08-18 17:35 ---
We need a preprocessed self-contained, preferably small, testcase. Otherwise we
cannot reproduce the bug ourselves.
See http://gcc.gnu.org/bugs.html
Thanks.
--
manu at gcc dot gnu dot org changed:
What
--- Comment #4 from paolo dot carlini at oracle dot com 2008-08-18 17:35
---
Don't worry, I'm handling it together with a few other missing ...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirme
--- Comment #8 from manu at gcc dot gnu dot org 2008-08-18 17:24 ---
Please provide a preprocessed reduced testcase as similar to the original as
possible.
I think this is not only predicated PHI but our representation of loops may
also have something to do.
--
manu at gcc dot gnu
--- Comment #5 from manu at gcc dot gnu dot org 2008-08-18 17:14 ---
There is no support for this in the middle-end anyway. Not even for Fortran.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #9 from manu at gcc dot gnu dot org 2008-08-18 16:53 ---
To assess whether this is a middle-end issue, the alias dump (with VOPS and
linenumbers) would be relevant.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from manu at gcc dot gnu dot org 2008-08-18 16:50 ---
This would need to be a GCC extension and those need some high-level approval,
so still unconfirmed, however I am marking as waiting until a decision is
taken.
You should seek opinions/support in the gcc mailing list.
--- Comment #7 from manu at gcc dot gnu dot org 2008-08-18 16:42 ---
Alias Wuninitialized
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Alias|
--- Comment #2 from manu at gcc dot gnu dot org 2008-08-18 16:32 ---
The code is correct in -std=c89 (the default). Use -Wall or -std=c99 if you
want to be warned about implicit declarations.
See http://c-faq.com/decl/implfdecl.html
--
manu at gcc dot gnu dot org changed:
--- Comment #1 from burnus at gcc dot gnu dot org 2008-08-18 16:24 ---
Presumably working was 2008-08-15-r139121; failing is 2008-08-18-r139184
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37151
--- Comment #5 from erik dot moller at cycos dot com 2008-08-18 16:22
---
the printf("shouldn't happen: %d\n", pAR[0]) happens when debug flags -O2 or
-O3 and -msse2 are set.
the printf("nz: %d\n", nZ); seems to do something awful...
void fun(short *pAR)
{
const short tmp = Tr
Polyhedron benchmark's mdbx (http://www.polyhedron.co.uk/MFL6VW74649)
gfortran -fprofile-generate -ffast-math -march=opteron -ftree-loop-linear -O3
mdbx.f90
./a.out
gfortran -fprofile-use -ffast-math -march=opteron -ftree-loop-linear -O3
mdbx.f90
gives an segmentation fault. No segfault without -
--- Comment #4 from erik dot moller at cycos dot com 2008-08-18 16:20
---
Created an attachment (id=16085)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16085&action=view)
the test case
it's as minimal I could get it...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37096
--- Comment #3 from erik dot moller at cycos dot com 2008-08-18 16:20
---
Created an attachment (id=16084)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16084&action=view)
main() for the testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37096
--- Comment #6 from sylvain dot pion at sophia dot inria dot fr 2008-08-18
16:12 ---
Maybe my comment is going to be out of scope, but the question is also
to know what the "primary question" is here, that is, what usage is supposed
to be supported by -frounding-math.
g++ currently acc
--- Comment #3 from burnus at gcc dot gnu dot org 2008-08-18 16:09 ---
Same trend with "ifort -O3" (ifort 11beta) and "gfortran -O3 --fast-math
-march=native" on AMD Athlon64 X2 4800+ / openSUSE 11. [same mulsd/mulpd
numbers]
ifort 2.452s, gfortran 3.848s -> 57% slower.
With Richard's p
--- Comment #9 from manu at gcc dot gnu dot org 2008-08-18 16:03 ---
(In reply to comment #7)
>
> I am stacking these here to not loose them, but at the same time, I am not
> sure
> if they are solid enough for submission to gcc-patches. I am still working on
> them.
s/loose/lose/
OK
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-08-18 15:55 ---
Note that there is no loop left on the trunk for the testcase, but after
the vectorizer it is all unrolled completely (unvectorized, of course).
Again this looks like missing vectorization of scalar code.
Note that
--- Comment #8 from dodji at gcc dot gnu dot org 2008-08-18 15:52 ---
Created an attachment (id=16083)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16083&action=view)
Fourth fix candidate
The previous patch was broken for say cross-compilers addressing a 64 target on
a 32 bits ho
--- Comment #7 from dodji at gcc dot gnu dot org 2008-08-18 15:47 ---
Manuel, yes I know that patches go to gcc-patches@ :-)
I am stacking these here to not loose them, but at the same time, I am not sure
if they are solid enough for submission to gcc-patches. I am still working on
them
--- Comment #3 from paolo dot carlini at oracle dot com 2008-08-18 15:41
---
Well, for 4_3-branch too, because the testcase is buggy anyway, you cannot
assume any of the existing includes to bring in .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37149
--- Comment #2 from paolo dot carlini at oracle dot com 2008-08-18 15:37
---
Ok, thanks, patch to include preapproved for mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37149
--- Comment #27 from rguenth at gcc dot gnu dot org 2008-08-18 15:34
---
This should be fixed by disabling the asserts in question.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36998
--- Comment #1 from jv244 at cam dot ac dot uk 2008-08-18 15:33 ---
Created an attachment (id=16082)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16082&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37150
As pointed out :
http://gcc.gnu.org/ml/gcc/2008-08/msg00290.html
The attached testcase yields (on a core2 duo, gcc trunk):
gfortran -O3 -ftree-vectorize -ffast-math -march=native test.f90
time ./a.out
real 0m3.414s
ifort -xT -O3 test.f90
time ./a.out
real 0m1.556s
The assemb
--- Comment #1 from hp at gcc dot gnu dot org 2008-08-18 15:24 ---
Trivial enough not to bother others...
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-08-18 15:22 ---
That is, GCCs inner loop is
.L6:
addl$1, %eax
addsd %xmm12, %xmm11
cmpl$1, %eax
addsd %xmm14, %xmm3
addsd %xmm15, %xmm2
addsd %xmm13, %xmm1
Worked with: 138952
Known to fail with: 138966 (and up to at least 139189)
Running /x/gcc/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ...
...
FAIL: 27_io/basic_ostream/inserters_other/char/error_code.cc (test for excess
errors)
WARNING: 27_io/basic_ostream/inserters_other/char/error_code.c
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-08-18 15:20 ---
The problem for the GCC vectorizer is that there are no loads or stores left
in the loop and it doesn't handle vectorizing "registers" only. This is a
case where real vectorization of straight-line code would be nec
--- Comment #5 from paul at epcc dot ed dot ac dot uk 2008-08-18 15:09
---
Hi,
Just to add, I too have seen this bug (using gcc 4.2.0, not tried other
versions yet) on a powerpc-ibm-aix5.3.0.0, so I'd be keen to hear of any
resolution.
Regards,
Paul Graham
--
http://gcc.gnu.org/b
--- Comment #8 from paolo dot carlini at oracle dot com 2008-08-18 15:05
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Statu
--- Comment #7 from paolo at gcc dot gnu dot org 2008-08-18 15:03 ---
Subject: Bug 37147
Author: paolo
Date: Mon Aug 18 15:02:10 2008
New Revision: 139200
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139200
Log:
2008-08-18 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #6 from hp at gcc dot gnu dot org 2008-08-18 14:49 ---
(In reply to comment #5)
> If you want, you can try to compile ** as a C++ program, this
> is important ** the below. If my analysis is correct, should not compile,
> meaning we can't really assume a C99-conforming for y
--- Comment #5 from paolo dot carlini at oracle dot com 2008-08-18 14:11
---
Thanks Hans-Peter, probably I don't need further information. I'm already
testing the fix. If you want, you can try to compile ** as a C++ program, this
is important ** the below. If my analysis is correct, sho
--- Comment #19 from manu at gcc dot gnu dot org 2008-08-18 14:09 ---
(In reply to comment #18)
> This defect has been open nearly 4 years. Any hope of
> actually getting a fix commited?
To be bluntly honest. No, do not expect a fix in the near/medium future. Not
for GCC 4.4 for sure.
--- Comment #4 from hp at gcc dot gnu dot org 2008-08-18 14:05 ---
(In reply to comment #1)
> Something you should also immediately check is whether those tests actually
> were run before the changes and not skipped,
You're right, all of
20_util/ratio/comparisons/comp2.cc
20_util/ratio/
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36817
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37142
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37125
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37102
--- Comment #18 from thutt at vmware dot com 2008-08-18 13:55 ---
This defect has been open nearly 4 years. Any hope of
actually getting a fix commited?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
--- Comment #16 from manu at gcc dot gnu dot org 2008-08-18 13:55 ---
__extension__ now works for CPP warnings in the C front-end.
The issue with system headers is more difficult since it depends on having two
locations.
C++ lexes everything up front before parsing anything, so the war
--- Comment #17 from manu at gcc dot gnu dot org 2008-08-18 13:46 ---
*** Bug 37148 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from manu at gcc dot gnu dot org 2008-08-18 13:46 ---
CCP removes the uninitialized use.
*** This bug has been marked as a duplicate of 18501 ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--
Although I demonstrated this using 4.1.2 on my host, it probably affects
other versions as well.
As the following code shows:
gcc -c -O1 -Wall -Werror uninitialized-warning.c
extern void called_function(unsigned p);
extern unsigned g;
void
f0(unsigned parm)
{
unsi
--- Comment #3 from paolo dot carlini at oracle dot com 2008-08-18 13:22
---
Yes, just to confirm that the first paragraph in my Comment #1 is a red
herring, sorry. Luckily we are debugging comp2.cc which includes very little,
does not include postypes.h. We should concentrate on the te
--- Comment #2 from paolo dot carlini at oracle dot com 2008-08-18 13:16
---
Actually, correctly, in the compilation of comp2.cc, bits/postypes.h doesn't
end up be included, at least on x86_64-linux. Please confirm that, is the most
important thing now. The preprocessed comp2.cc is very
--- Comment #1 from paolo dot carlini at oracle dot com 2008-08-18 13:03
---
Therefore, are *all* the errors cause by INTMAX_MAX not being defined? That may
have only to do with the macros on top of bits/postypes.h. Thus you should
check what happens with _GLIBCXX_HAVE_INT64_T, _GLIBCXX
--- Comment #12 from vda dot linux at googlemail dot com 2008-08-18 13:02
---
Bootstrap with -O2 on current svn fails. Bootstrap with -Os works.
Bootstrap with -O2 on 4.3.1 works.
Instrumented patch emits C code which can be used to test for incorrect VRP
predictions.
I ran such tests
1 - 100 of 114 matches
Mail list logo
