--- Comment #2 from burnus at gcc dot gnu dot org 2008-07-17 05:55 ---
Subject: Bug 36824
Author: burnus
Date: Thu Jul 17 05:54:42 2008
New Revision: 137910
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137910
Log:
2008-07-17 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- Comment #3 from burnus at gcc dot gnu dot org 2008-07-17 05:55 ---
Subject: Bug 36825
Author: burnus
Date: Thu Jul 17 05:54:42 2008
New Revision: 137910
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137910
Log:
2008-07-17 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- Comment #1 from hjl dot tools at gmail dot com 2008-07-17 05:25 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg01247.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #1 from hjl dot tools at gmail dot com 2008-07-17 05:19 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg01241.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #28 from hjl at gcc dot gnu dot org 2008-07-17 05:14 ---
Subject: Bug 36443
Author: hjl
Date: Thu Jul 17 05:13:27 2008
New Revision: 137909
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137909
Log:
2008-07-17 H.J. Lu <[EMAIL PROTECTED]>
PR testsuite/36443
--- Comment #13 from kkojima at gcc dot gnu dot org 2008-07-17 02:08
---
> Try changing the "reloaded != 1" condition in find_reloads_subreg_address
> to "reloaded == 0" (as a replacement for my m32c patch, and probably for
> the SH patch as well). I hope that should avoid these prob
--- Comment #3 from jeff at jeffunit dot com 2008-07-17 02:07 ---
Created an attachment (id=15920)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15920&action=view)
Here is the subroutine, run throuh the preprocessor using gcc-3.4.3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #2 from jeff at jeffunit dot com 2008-07-17 01:59 ---
In order to run the entire program, you will need a fair amount of code.
All needed code can be found at the above URL, along with test data.
--
jeff at jeffunit dot com changed:
What|Removed
--- Comment #1 from jeff at jeffunit dot com 2008-07-17 01:57 ---
Created an attachment (id=15919)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15919&action=view)
this is the preprocessed subroutine that is poorly optimized
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36860
I have a subroutine that is heavily used by a program I frequently run called
UKKA_Dist_With_Max. I had benchmarked it using mandriva linux 2005LE. When I
ran it using mandriva 2008.1, it ran much slower. Using the compiler from
mandriva linux 2005LE (gcc-3.4.3) and mandriva 2008.1, I was able to r
--- Comment #8 from dodji at gcc dot gnu dot org 2008-07-16 23:52 ---
fixed in trunk.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #7 from dodji at gcc dot gnu dot org 2008-07-16 23:44 ---
Subject: Bug 13699
Author: dodji
Date: Wed Jul 16 23:44:02 2008
New Revision: 137904
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137904
Log:
2008-07-16 Dodji Seketeli <[EMAIL PROTECTED]>
PR c++/1
--- Comment #3 from hubicka at gcc dot gnu dot org 2008-07-16 23:14 ---
Fix comitted.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
Status|UN
locate_and_pad_parm never align parameters on stack for
callers. It only caps parameter alignment to
PREFERRED_STACK_BOUNDARY. But std_gimplify_va_arg_expr
tries to align stack for callee:
/* va_list pointer is aligned to PARM_BOUNDARY. If argument actually
requires greater alignment, we
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-07-16 21:24 ---
Created an attachment (id=15918)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15918&action=view)
better patch
This one actually works for eoshift and passes
all zero* and *shift* tests in gfortran.dg.
--
locate_and_pad_parm has
where_pad = FUNCTION_ARG_PADDING (passed_mode, type);
boundary = FUNCTION_ARG_BOUNDARY (passed_mode, type);
locate->where_pad = where_pad;
locate->boundary = boundary;
/* Remember if the outgoing parameter requires extra alignment on the
calling function sid
--- Comment #1 from burnus at gcc dot gnu dot org 2008-07-16 20:45 ---
> program main
> CALL badlocale()
> WRITE(*,'(G2.4)') 1.2345
> end program main
>
> If the code executed correctly, the expected output would be
> 1,235
No, the expected output would be "1.235" according
--- Comment #2 from burnus at gcc dot gnu dot org 2008-07-16 20:36 ---
Jerry, you know libgfortran better than me. Can one simply change in
libgfortran.h:
#define GFC_DTYPE_RANK_MASK 0x07
to 0x0F (= 15) or does this cause some problems with the gcc 4.3
compatibility or ... ? Actually
--- Comment #12 from joseph at codesourcery dot com 2008-07-16 20:25
---
Subject: Re: [4.3/4.4 Regression] newlib:libm/math/k_rem_pio2.c
fails in reload
On Wed, 16 Jul 2008, dj at redhat dot com wrote:
> Last night's builds showed a flaw in the patch. The "++rii" address
> created
GFortran float printing breaks when a non-English locale is selected. Instead,
"Internal error: printf is broken" appears. The failing part is a sanity check
in libgfortran, where it was forgotten that in some non-English locales,
sprintf will format floats using a comma instead of a period as the
--- Comment #6 from paolo dot carlini at oracle dot com 2008-07-16 19:30
---
Of course, but really doesn't make sense trying now implementing that, simply
there is no infrastructure in the front-end for C++0x POD-ness, sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36856
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-07-16 19:30 ---
(In reply to comment #4)
> We're using -std=gnu++0x, so we're expecting the implementation to follow
> C++ 0x rules.
Except the ABI says something different from C++0x ...
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #4 from sebor at roguewave dot com 2008-07-16 19:26 ---
We're using -std=gnu++0x, so we're expecting the implementation to follow
C++ 0x rules.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36856
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-07-16 19:10 ---
derived_pod_t is still a non POD type according to the C++98/C++03 standard.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from dj at redhat dot com 2008-07-16 19:08 ---
Subject: Re: [4.3/4.4 Regression] newlib:libm/math/k_rem_pio2.c fails in
reload
Last night's builds showed a flaw in the patch. The "++rii" address
created by m32c_legitimize_reload_address is *not* legitimate, it's
used
--- Comment #2 from paolo dot carlini at oracle dot com 2008-07-16 19:00
---
Note, I'm going to suspend this, because, besides the traits "builtins" we are
not implementing anything in the front-end having to do with the new
characterization in C++0x of POD.
--
paolo dot carlini at
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
The __is_pod() built-in returns false for pod class types that have base
classes, which is allowed by c++0x.
Environment:
System: Linux cranium 2.6.18-8.el5xen #1 SMP Fri Jan 26 14:29:35 EST 2007
x86_64 x86_64 x86_64 GNU/Linux
Architecture: x86_64
host: x86_64-unknown-linux-gnu
build: x
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-07-16 18:51 ---
(In reply to comment #1)
> Created an attachment (id=15917)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15917&action=view) [edit]
> proposed patch
... which doesn't work in all cases. Still investigating.
__has_trivial_destructor() returns false for all reference types, but
should return true according to documentation. The documented behavior
is consistent with what is required by the c++0x draft.
Environment:
System: Linux cranium 2.6.18-8.el5xen #1 SMP Fri Jan 26 14:29:35 EST 2007
x
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-07-16 18:43 ---
Created an attachment (id=15917)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15917&action=view)
proposed patch
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |
This is just a collector of optimizations that the
front end could do before generating tree codes.
--
Summary: [meta] fortran front-end optimization
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: meta-bug
Severity: enha
Compiling gcc 4.3.1 on my machine fails with the following error message:
--
make profiledbootstrap
...
/tmp/bitti/gccobj/./prev-gcc/xgcc -B/tmp/bitti/gccobj/./prev-gcc/
-B/share/gcc/gcc-4.3.1/i686-pc-linux-gnu/bin/ -c -g -O2 -fomit-frame-pointer
-fprofile-generate -gnat
--- Comment #1 from paolo dot carlini at oracle dot com 2008-07-16 16:37
---
We badly need a self-contained testcase (per our general guidelines) because
something trivial inspired by your PR, like the below compiles just fine.
template
T A::determinant3(T matrix[3][3])
{
// NB: no
We have a class more or less like this: (please bear with me, this is only an
approximation.
class A
{
template static T determinant4(T matrix[4][4]);
template static T determinant3(T matrix[3][3]);
template static T determinant2(T matrix[2][2]);
};
template
T A::determinant3(T mat
Bootstrapping mainline on Tru64 UNIX V5.1B fails as of 20080613:
libtool: compile: /vol/gccsrc/obj/gcc-4.4.0-20080613/5.1b-gcc/./gcc/xgcc
-shared-libgcc -B/vol/gccsrc/obj/gcc-4.4.0-20080613/5.1b-gcc/./gcc -nostdinc++
-L/vol/gccsrc/obj/gcc-4.4.0-20080613/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/src
http://gcc.gnu.org/onlinedocs/
only carries docs for 4.3.0 but not for the current 4.3.1-release.
Generating the onlinedocs is rumored to be the person's duty who rolled the
release (apparently jakub for 4.3.1).
--
Summary: missing onlinedocs for 4.3.1
Product: gcc
--- Comment #6 from dodji at gcc dot gnu dot org 2008-07-16 15:02 ---
Reproced on trunk. I'd like to look into this bug, if nobody is working on it
already.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from aldot at gcc dot gnu dot org 2008-07-16 14:35 ---
The target milestone does not matter in this case.
The fix will be in the next 4.3.x release which will be 4.3.2, from the looks.
--
aldot at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from aldot at gcc dot gnu dot org 2008-07-16 14:33 ---
Will be in the next 4.3.x release which will be 4.3.2, from the looks.
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from cnstar9988 at gmail dot com 2008-07-16 14:24 ---
Target Milestone is 4.3.3?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36657
--- Comment #9 from cnstar9988 at gmail dot com 2008-07-16 14:24 ---
Target Milestone is 4.3.3?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36546
--- Comment #3 from mmokrejs at ribosome dot natur dot cuni dot cz
2008-07-16 13:59 ---
This gave me a working bootstrapped compiler:
AS=/usr/ccs/bin/as LD=/usr/ccs/bin/ld NM=/usr/local/bin/nm
RANLIB=/usr/local/bin/ranlib STRIP=/usr/local/bin/strip BOOT_CFLAGS="-pipe
-fno-strict-aliasi
--- Comment #6 from dodji at gcc dot gnu dot org 2008-07-16 13:39 ---
Created an attachment (id=15916)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15916&action=view)
more work in the matter
This patch performs a more accurate lookup of the extern C functions to be able
to emit p
--- Comment #1 from Joey dot ye at intel dot com 2008-07-16 13:14 ---
Fixed by revision 137859
--
Joey dot ye at intel dot com changed:
What|Removed |Added
St
$ cat > m.h <<-EOF
typedef long unsigned int size_t;
#define __THROW
/* Remap pages mapped by the range [ADDR,ADDR+OLD_LEN) to new length
NEW_LEN. If MREMAP_MAYMOVE is set in FLAGS the returned address
may differ from ADDR. If MREMAP_FIXED is set in FLAGS the function
takes another para
--- Comment #15 from aldot at gcc dot gnu dot org 2008-07-16 12:48 ---
Fixed on trunk, thanks!
Can we have the testcase in the testsuite and the fix applied to the
4_3-branch, too?
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #10 from jsm28 at gcc dot gnu dot org 2008-07-16 10:47 ---
Subject: Bug 36827
Author: jsm28
Date: Wed Jul 16 10:46:32 2008
New Revision: 137876
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137876
Log:
PR target/36827
* config/m32c/m32c.c (BIG_FB_ADJ
--- Comment #9 from jsm28 at gcc dot gnu dot org 2008-07-16 10:46 ---
Subject: Bug 36827
Author: jsm28
Date: Wed Jul 16 10:45:57 2008
New Revision: 137875
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137875
Log:
PR target/36827
* config/m32c/m32c.c (BIG_FB_ADJ)
--- Comment #2 from andreasmeier80 at gmx dot de 2008-07-16 09:52 ---
For me it was working in revision 137687
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36830
51 matches
Mail list logo
