--- Comment #3 from jb at gcc dot gnu dot org 2009-05-19 06:42 ---
Assigning to myself.
HJL is right, we should use the _r functions if available, if not we must
protect the calls with a mutex.
--
jb at gcc dot gnu dot org changed:
What|Removed |A
--- Comment #1 from ludovic at ludovic-brenta dot org 2009-05-19 06:30
---
There was a typo in the original program that I mistakenly corrected. This
typo is the trigger for the bug:
with Ada.Unchecked_Conversion;
package Essai is
type Attributed_Chararcter is record -- line 3
--- Comment #2 from pault at gcc dot gnu dot org 2009-05-19 05:06 ---
(In reply to comment #1)
> Can you attach a working example? I failed to apply your patch and figure out
> which diffed file is what.
>
Hi Tobias,
It's a reversed diff!
Hi Thomas,
Works for me on FC9/x86_64 - what
--- Comment #24 from hjl dot tools at gmail dot com 2009-05-19 02:37
---
(In reply to comment #23)
> Subject: Re: [4.5 Regression] Revision 147596 breaks bootstrap
>
> I still feel that if this patch is put in, we eventually will have the same
> discussion, as the compiler gets smar
--- Comment #23 from meissner at linux dot vnet dot ibm dot com 2009-05-19
02:33 ---
Subject: Re: [4.5 Regression] Revision 147596 breaks bootstrap
On Tue, May 19, 2009 at 12:38:08AM -, hjl dot tools at gmail dot com wrote:
>
>
> --- Comment #22 from hjl dot tools at gmail
--- Comment #11 from aoliva at gcc dot gnu dot org 2009-05-19 01:32 ---
Subject: Bug 40159
Author: aoliva
Date: Tue May 19 01:32:09 2009
New Revision: 147697
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147697
Log:
PR other/40159
* Makefile.tpl (all): Don't assume gcc-bootstra
--- Comment #10 from aoliva at gcc dot gnu dot org 2009-05-19 01:31 ---
Subject: Bug 40159
Author: aoliva
Date: Tue May 19 01:31:12 2009
New Revision: 147696
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147696
Log:
PR other/40159
* Makefile.tpl (all): Don't assume gcc-bootstra
--- Comment #9 from aoliva at gcc dot gnu dot org 2009-05-19 01:30 ---
Subject: Bug 40159
Author: aoliva
Date: Tue May 19 01:30:35 2009
New Revision: 147695
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147695
Log:
PR other/40159
* Makefile.tpl (all): Don't assume gcc-bootstrap
--- Comment #22 from hjl dot tools at gmail dot com 2009-05-19 00:38
---
Another patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01187.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40172
--- Comment #8 from aoliva at gcc dot gnu dot org 2009-05-19 00:07 ---
Fixed.
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from aoliva at gcc dot gnu dot org 2009-05-19 00:05 ---
Subject: Bug 40159
Author: aoliva
Date: Tue May 19 00:04:57 2009
New Revision: 147685
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147685
Log:
PR other/40159
* Makefile.tpl (all): Don't end with uncondition
--- Comment #6 from aoliva at gcc dot gnu dot org 2009-05-19 00:04 ---
Subject: Bug 40159
Author: aoliva
Date: Tue May 19 00:04:17 2009
New Revision: 147684
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147684
Log:
PR other/40159
* Makefile.tpl (all): Don't end with uncondition
--- Comment #21 from pinskia at gcc dot gnu dot org 2009-05-19 00:02
---
(In reply to comment #16)
> Just to chime in, the warning is a useful warning, but the way rs6000 and mips
> define FRAME_GROWS_DOWNWARD, the test in toplev.c will never succeed.
Yes and that is correct because
--- Comment #5 from aoliva at gcc dot gnu dot org 2009-05-19 00:01 ---
Subject: Bug 40159
Author: aoliva
Date: Tue May 19 00:01:17 2009
New Revision: 147683
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147683
Log:
PR other/40159
* Makefile.tpl (all): Don't end with uncondition
--- Comment #20 from meissner at linux dot vnet dot ibm dot com 2009-05-18
23:48 ---
David, as I said in my message, this patch is just papering over the problem.
While we might want to install this patch temporarily, to get the mips and
rs6000 building again, I think a better solution
--- Comment #7 from kkojima at gcc dot gnu dot org 2009-05-18 23:41 ---
Thanks for confirmation! I'll ask if the r146829 patch is safe
to backport for 4.[34] branches in the gcc list, after the tests
on x86 and powerpc.
--
kkojima at gcc dot gnu dot org changed:
What
--- Comment #19 from daney at gcc dot gnu dot org 2009-05-18 23:32 ---
Created an attachment (id=17890)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17890&action=view)
Proposed fix.
I am testing this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40172
--- Comment #4 from paolo dot carlini at oracle dot com 2009-05-18 23:18
---
Fixed for 4.4.1.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from paolo at gcc dot gnu dot org 2009-05-18 23:17 ---
Subject: Bug 40192
Author: paolo
Date: Mon May 18 23:16:48 2009
New Revision: 147681
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147681
Log:
2009-05-18 Paolo Carlini
PR libstdc++/40192
*
--- Comment #2 from paolo at gcc dot gnu dot org 2009-05-18 23:16 ---
Subject: Bug 40192
Author: paolo
Date: Mon May 18 23:16:20 2009
New Revision: 147680
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147680
Log:
2009-05-18 Paolo Carlini
PR libstdc++/40192
*
--- Comment #18 from manu at gcc dot gnu dot org 2009-05-18 23:13 ---
The following patch moves the warning out of Wextra. I haven't tested it,
though.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 14767
--- Comment #17 from hjl dot tools at gmail dot com 2009-05-18 23:03
---
(In reply to comment #16)
> Just to chime in, the warning is a useful warning, but the way rs6000 and mips
> define FRAME_GROWS_DOWNWARD, the test in toplev.c will never succeed.
>
> 5) Move FRAME_GROWS_DOWNWAR
--- Comment #16 from meissner at linux dot vnet dot ibm dot com 2009-05-18
22:56 ---
Just to chime in, the warning is a useful warning, but the way rs6000 and mips
define FRAME_GROWS_DOWNWARD, the test in toplev.c will never succeed.
I can see a couple of ways to fix this:
1) Revert
--- Comment #15 from daney at gcc dot gnu dot org 2009-05-18 22:35 ---
And yet another place:
../../trunk/gcc/config/mips/sb1.md:159: error: logical or of collectively
exhaustive tests is always true
../../trunk/gcc/config/mips/sb1.md:159: error: logical or of collectively
exhaustiv
--- Comment #1 from paolo dot carlini at oracle dot com 2009-05-18 22:34
---
I'll fix it momentarily.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from paolo dot carlini at oracle dot com 2009-05-18 22:12
---
*** Bug 40193 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2009-05-18 22:12
---
*** This bug has been marked as a duplicate of 38064 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #2 from hjl dot tools at gmail dot com 2009-05-18 22:11 ---
date_and_time isn't thread-safe. It should use gmtime_r and
localtime_r if they are available.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
On trunk (also seen in gcc-4.4.0), gcc doesn't compile this snippet:
enum class E { A };
bool foo() { return E::A == E::A; }
in C++0x mode (cc1plus -quiet -std=c++0x enumtest.cpp -o /tmp/enumtest.s),
giving this erro
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-18 21:20 ---
Can you attach a working example? I failed to apply your patch and figure out
which diffed file is what.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40187
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-18 21:12 ---
Confirm. I looked at the source code, but I don't see why it can happen, but it
does.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #14 from daney at gcc dot gnu dot org 2009-05-18 21:10 ---
For the record: This affects mips64-linux as well.
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
The following code will not compile in gcc 4.3.2 on Ubuntu 8.10
#include
typedef float float4[4];
int main()
{
std::vector vals;
}
I get the following compilation error:
/usr/include/c++/4.3/bits/stl_construct.h: In function void
std::_Destroy(_Tp*) [with _Tp = float [4]]:
/usr/include/c++
--- Comment #3 from mat at lcs dot mit dot edu 2009-05-18 20:53 ---
Fair enough, thanks (this came up running a compiler test suite that checks
even undefined edge cases).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40189
--- Comment #2 from rmh at gcc dot gnu dot org 2009-05-18 20:45 ---
Created an attachment (id=17889)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17889&action=view)
patch
2009-05-18 Robert Millan
* acx.m4: Fix ${host_subdir} initialization for libgcc.
--
http://gcc.gnu.or
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-18 20:43 ---
I don't know that many folks who build in the source directory :).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
I found this when building a i586-mingw32 cross-compiler directly in srcdir.
Build fails with:
make[2]: Entering directory `/tmp/trunk/i586-mingw32msvc/libgcc'
Makefile:143: ../.././gcc/libgcc.mvars: No such file or directory
make[2]: *** No rule to make target `../.././gcc/libgcc.mvars'. Stop.
Test case:
program testhour
use omp_lib
integer :: h(1000), h1(1000), bins(0:23), v(8)
call omp_set_num_threads(4)
print *, "Running on",omp_get_max_threads(),"threads
and",omp_get_num_procs(),"procs."
!$omp parallel do schedule(STATIC,250)
do i=1,1000
call date_and_time(values=v)
h(i) = v
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-18 19:48 ---
INT_MIN + any number is never going to be zero because INT_MIN = - INT_MAX -1.
Also signed integer overflow is undefined which gives that the above.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40189
--- Comment #1 from schwab at linux-m68k dot org 2009-05-18 19:47 ---
Not a bug. If arg0 is negative you get undefined behavior due to overflow.
Use -fwrapv to get wrapping semantics.
--
schwab at linux-m68k dot org changed:
What|Removed |Added
-
This code:
int
foo(int arg0)
{
if ((-2147483647 - 1) + arg0)
return 20;
else
return 11;
}
when compiled with gcc-4.4.0 at -O2 or higher, simply returns 20
unconditionally:
$ ~/x86-gcc4/bin/gcc -m32 -O2 -S ~/baz.c -o /dev/tty
.file "baz.c"
.text
.p2align 4,,1
--- Comment #6 from dodji at gcc dot gnu dot org 2009-05-18 19:29 ---
Fixed in 4.5, 4.4 and 4.3.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from dodji at gcc dot gnu dot org 2009-05-18 19:26 ---
Subject: Bug 40109
Author: dodji
Date: Mon May 18 19:26:41 2009
New Revision: 147676
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147676
Log:
Fix for PR debug/40109
gcc/ChangeLog:
PR debug/40109
* dwarf2out
--- Comment #4 from dodji at gcc dot gnu dot org 2009-05-18 19:24 ---
Subject: Bug 40109
Author: dodji
Date: Mon May 18 19:24:17 2009
New Revision: 147675
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147675
Log:
Candidate Fix for PR debug/40109
gcc/ChangeLog:
PR debug/40109
*
--- Comment #3 from dodji at gcc dot gnu dot org 2009-05-18 19:20 ---
Subject: Bug 40109
Author: dodji
Date: Mon May 18 19:19:52 2009
New Revision: 147674
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147674
Log:
Fix for PR debug/40109
gcc/ChangeLog:
PR debug/40109
* dwarf2out
--- Comment #4 from dj at redhat dot com 2009-05-18 19:16 ---
Yes, those two changes are the fix you need. However, those fixes were over
three years ago, so I consider this bug "already fixed". If you agree, please
close this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40
--
pthaugen at gcc dot gnu dot org changed:
What|Removed |Added
CC||pthaugen at gcc dot gnu dot
|
Using a SHAPE with stride doesn't work with c_f_pointer doesn't work
(modified test case from the testsuite):
$ diff -u c_f_pointer_shape_tests_4.f03
~/gcc/trunk/gcc/testsuite/gfortran.dg/c_f_pointer_shape_tests_2.f03
--- c_f_pointer_shape_tests_4.f03 2009-05-18 19:55:36.0 +0200
+++
--- Comment #1 from daney at gcc dot gnu dot org 2009-05-18 17:39 ---
I am working on a patch.
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
Assign
--- Comment #2 from rob1weld at aol dot com 2009-05-18 17:36 ---
(In reply to comment #1)
> Yes GPU libraries would be nice but this needs a lot of work to begin with.
> First you have to support the GPUs. This also amounts to doubling the
> support. If you really want them, since this
--- Comment #48 from hjl at gcc dot gnu dot org 2009-05-18 17:21 ---
Subject: Bug 39942
Author: hjl
Date: Mon May 18 17:21:13 2009
New Revision: 147671
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147671
Log:
2009-05-18 H.J. Lu
PR target/39942
* config/i386
--- Comment #3 from janus at gcc dot gnu dot org 2009-05-18 16:59 ---
Comment #0 is fixed by the following one-liner patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 147663)
+++ gcc/fortran/
--- Comment #9 from hjl dot tools at gmail dot com 2009-05-18 16:58 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #8 from hjl at gcc dot gnu dot org 2009-05-18 16:56 ---
Subject: Bug 39907
Author: hjl
Date: Mon May 18 16:56:42 2009
New Revision: 147669
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147669
Log:
2009-05-18 H.J. Lu
PR testsuite/39907
* gcc.targe
--- Comment #7 from hjl at gcc dot gnu dot org 2009-05-18 16:54 ---
Subject: Bug 39907
Author: hjl
Date: Mon May 18 16:54:31 2009
New Revision: 147668
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147668
Log:
2009-05-18 H.J. Lu
Backport from mainline:
2009-0
--- Comment #6 from hjl at gcc dot gnu dot org 2009-05-18 16:53 ---
Subject: Bug 39907
Author: hjl
Date: Mon May 18 16:53:25 2009
New Revision: 147667
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147667
Log:
2009-05-18 H.J. Lu
PR testsuite/39907
* gcc.targe
--- Comment #7 from burnus at gcc dot gnu dot org 2009-05-18 16:52 ---
Issue brought up by Jakub:
do you require all equivalenced vars to be either threadprivate
or non-threadprivate?
or, does a single threadprivate var make all vars equivalenced somehow to
it threadprivate?
Is
--- Comment #5 from hjl dot tools at gmail dot com 2009-05-18 16:39 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01156.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #9 from ubizjak at gmail dot com 2009-05-18 16:37 ---
(In reply to comment #8)
> No, it's just i686-pc-linux-gnu. Without --target_board "etc." it
> works; with I got this spurious failure.
>
> But it's not a wrong code, so I think we can close as invalid.
BTW: Since you
--- Comment #6 from armin76 at gentoo dot org 2009-05-18 16:29 ---
Sorry for taking a while, but i'm pretty sure you know sh machines are kinda of
slow :)
Yes! it works!
Thank you for investigating it
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40105
--- Comment #4 from schwab at linux-m68k dot org 2009-05-18 15:48 ---
GNU make does not use sh -e.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40159
--- Comment #3 from schwab at linux-m68k dot org 2009-05-18 15:40 ---
The same problem existed in output_iorsi3 and output_xorsi3. Fixed in 4.5.
--
schwab at linux-m68k dot org changed:
What|Removed |Added
-
--- Comment #8 from w6ws at earthlink dot net 2009-05-18 15:36 ---
Subject: Re: Attributes not fully checked comparing actual
vs dummy procedure
Janus,
janus at gcc dot gnu dot org wrote:
> --- Comment #7 from janus at gcc dot gnu dot org 2009-05-18 09:36 ---
> The commit in
--- Comment #2 from schwab at gcc dot gnu dot org 2009-05-18 15:36 ---
Subject: Bug 39531
Author: schwab
Date: Mon May 18 15:36:18 2009
New Revision: 147664
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147664
Log:
PR target/39531
* config/m68k/m68k.c (output_andsi3): Mask off
--- Comment #3 from aoliva at gcc dot gnu dot org 2009-05-18 15:34 ---
Uhh... This shouldn't matter when commands are run in a shell with set -e,
like make does, no?
Anyhow, thanks for the analysis. I suppose replacing the final : for exit $$?
should fix this, right?
--
http://g
--- Comment #3 from paolo dot carlini at oracle dot com 2009-05-18 15:03
---
Ok, thanks.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #8 from vincent at vinc17 dot org 2009-05-18 14:56 ---
Are you sure that this comes from the extended precision? This would mean that
GCC does implicit extended -> double conversions in an asymmetric way, and
IIRC, I've never seen that.
I can't reproduce the problem with g++
--- Comment #7 from sliwa at cft dot edu dot pl 2009-05-18 14:52 ---
The case (a < b) && (b < a) shows that not discarding the extra precision
before performing a comparison leads to serious problems.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40186
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-05-18 14:49 ---
Either use -ffloat-store or -mfpmath=sse . The issue comes from excessive
precision. It is not < or > which is causing the problem but keeping one of a
or b in the fp stack register but putting the other one on the
--- Comment #4 from janus at gcc dot gnu dot org 2009-05-18 14:47 ---
Fixed with r147663. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from janus at gcc dot gnu dot org 2009-05-18 14:45 ---
Subject: Bug 40164
Author: janus
Date: Mon May 18 14:44:55 2009
New Revision: 147663
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147663
Log:
2009-05-18 Janus Weil
PR fortran/40164
* prim
--- Comment #2 from tsyvarev at ispras dot ru 2009-05-18 14:37 ---
Yes, this seems reasonably. I also thought about smth. similar to this. Only it
is need to take into account using mbsrtowcs for other locale properties(if
they exist in others categories).
Anyway, checking of mbsrtowcs
--- Comment #129 from ich at az2000 dot de 2009-05-18 14:24 ---
I am a bit wondering if this bug is also for the case (a < b) && (b < a) ==
true. Is it?
Because if so, this becomes way more serious, as for example std::set
is broken then (and depending on the STL implementation, it will
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-05-18 14:25 ---
(In reply to comment #3)
> The bug is that
>
> snapshot_ret:
> movq%rdi, rdi(%rip)
> call*callthis(%rip)
>
> does not preserve stack alignment. But we assume that correct alignment
> is pre
--- Comment #128 from pinskia at gcc dot gnu dot org 2009-05-18 14:11
---
*** Bug 40186 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-05-18 14:11 ---
*** This bug has been marked as a duplicate of 323 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ramana at gcc dot gnu dot org 2009-05-18 14:10 ---
I can't see this with 4.3, 4.4 or trunk today. Can you provide a more recent
reference to this problem ?
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from ich at az2000 dot de 2009-05-18 13:38 ---
Created an attachment (id=17888)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17888&action=view)
simpler test case (now for wrong ordering case 1)
I was able to reproduce the first case now ("wrong ordering 1"). I also
Hi,
I'm trying to install gcc to get gcj on a mac. I found that I have to put in
an excessive amount of flags to even get a start on compiling gcc. For
example:
export CC='gcc -arch x86_64';export GXX='g++ -arch x86_64';CFLAGS='-arch
x86_64';export CXXFLAGS='-arch x86_64';export CPPFLAGS='-arch x
--- Comment #3 from ich at az2000 dot de 2009-05-18 13:17 ---
Some compiler information:
a...@acompneu ~/Programmierung $ g++ -Os -v -ggdb test_order.cpp -o test_order
&&
./test_order
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.4.0/
--- Comment #2 from ich at az2000 dot de 2009-05-18 13:16 ---
This is a real problem, because in my real application, I tried to use a very
similar order in a std::set, defined like this:
struct CustomOrder {
bool operator()(const Tmp* a, const Tmp* b) const {
re
--- Comment #1 from ich at az2000 dot de 2009-05-18 13:11 ---
Created an attachment (id=17887)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17887&action=view)
testcase (c++)
This is the test code. I am hitting the "wrong ordering 2" code.
--
http://gcc.gnu.org/bugzilla/show_
When comparing the return value of two functions (which both return double and
do always return the same value), I have the case that (a < b) && (b < a)
(whereby they should be equal) in a real world application.
I tried to reproduce it, though in the test case, I have a slightly different
case, w
--- Comment #1 from paolo dot carlini at oracle dot com 2009-05-18 12:40
---
Ok. Then, what do you think, would it be at least an improvement, constructing
on the fly a uniform locale corresponding to the LC_MONETARY category and
switching to it instead, before calling mbsrtowcs? Perfor
(Debian bug #519336)
The following illegal program causes gnat1 to crash with a segmentation fault:
with Ada.Unchecked_Conversion;
package Essai is
type Attributed_Character is record
I : Integer;
end record;
type Video_Array is array (Integer range 0 .. 1) of Attributed_Character;
--- Comment #2 from janus at gcc dot gnu dot org 2009-05-18 12:28 ---
This test case with 'dynamic' array size produces a gimplification error:
PROGRAM test_prog
ABSTRACT INTERFACE
FUNCTION fn_template(n,x) RESULT(y)
INTEGER, INTENT(in) :: n
REAL, INTENT(in) :: x(n)
REAL ::
--- Comment #14 from jv244 at cam dot ac dot uk 2009-05-18 12:19 ---
Created an attachment (id=17886)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17886&action=view)
simplified testcase for common subexpressions.
Richard,
thanks very much for the first patch. I tried to get a be
Constructor locale(const char* std_name), when called with name of nonuniform
locale (like "LC_CTYPE=...;LC_COLLATE=...;..."), can create locale with
incorrect content of some its facets: these facets differ from facets of
locale, created via locale(const locale& other, const char* std_name, catego
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-05-18 10:24
---
Subject: Bug 40168
Author: rguenth
Date: Mon May 18 10:24:34 2009
New Revision: 147659
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147659
Log:
2009-05-18 Richard Guenther
PR fortran/40168
--- Comment #1 from hailijuan at gmail dot com 2009-05-18 10:07 ---
Created an attachment (id=17885)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17885&action=view)
static-1.C and static-1a.cc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40183
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-05-18 10:14
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-05-18 10:13
---
Subject: Bug 3
Author: rguenth
Date: Mon May 18 10:13:43 2009
New Revision: 147657
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147657
Log:
2009-05-18 Richard Guenther
PR tree-optimizatio
# g++ static-1.C static-1a.cc -O2
# export LD_LIBRARY_PATH=/import/dr3/s10/gcc-4.4.0/lib/
# ./a.out
Abort (core dumped)
The error would be gone if /usr/sfw/lib/libstdc++.so.6 is linked. so I assume
the error lives in the library libstdc++.so.6 that gcc 4.4 provides. Any
information that you need,
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-18 10:03 ---
The bug is that
snapshot_ret:
movq%rdi, rdi(%rip)
call*callthis(%rip)
does not preserve stack alignment. But we assume that correct alignment
is preserved over the indirect function call(?)
--- Comment #8 from jay dot foad at gmail dot com 2009-05-18 09:46 ---
Thanks Paolo!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40160
--- Comment #2 from schwab at linux-m68k dot org 2009-05-18 09:37 ---
The last command in the "all" rule is : which is always successfull:
# The target built for a native non-bootstrap build.
.PHONY: all
all:
@if gcc-bootstrap
[ -f stage_final ] || echo stage3 > stage_final
--- Comment #7 from janus at gcc dot gnu dot org 2009-05-18 09:36 ---
The commit in comment #6 implements the checking for intents.
ToDo:
* check for OPTIONAL
* better error messages
* recursive check (see comment #2)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36947
--- Comment #5 from janus at gcc dot gnu dot org 2009-05-18 09:28 ---
The commit in comment #4 implements the basic checking of the intents.
ToDo:
* Improve the error message, which is currently just "Type/rank mismatch in
argument ...". Should specify exactly what is not matching, and
--- Comment #4 from janus at gcc dot gnu dot org 2009-05-18 09:19 ---
Subject: Bug 40039
Author: janus
Date: Mon May 18 09:19:20 2009
New Revision: 147655
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147655
Log:
2009-05-18 Janus Weil
PR fortran/36947
PR for
--- Comment #6 from janus at gcc dot gnu dot org 2009-05-18 09:19 ---
Subject: Bug 36947
Author: janus
Date: Mon May 18 09:19:20 2009
New Revision: 147655
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147655
Log:
2009-05-18 Janus Weil
PR fortran/36947
PR for
1 - 100 of 115 matches
Mail list logo
