Hi,
In a build of GCC 4.7.0-RC-20120302 with --enable-languages=c,c++ [0],
I’m seeing C++-mangled name for common functions, like:
$ objdump -T cc1 | grep build1_stat_loc
00640a00 gDF .text 007a Base
_Z20fold_build1_stat_locj9tree_codeP9tree_nodeS1_
Indeed,
2012/3/9 Ludovic Courtès ludovic.cour...@inria.fr:
I believe this is not intentional, right?
No, this is intentional. We bootstrap the compiler using the C++
front-end now. We build stage1 with the C compiler and then build
stages 2 and 3 with the C++ compiler.
This is a documented change
On Fri, Mar 09, 2012 at 01:53:52AM -0800, Andrew Pinski wrote:
2012/3/9 Ludovic Courtès ludovic.cour...@inria.fr:
I believe this is not intentional, right?
No, this is intentional. We bootstrap the compiler using the C++
front-end now. We build stage1 with the C compiler and then build
Hi,
It seems there is an issue around subreg:HI of PSI hardware register,
which occurs either during expand or reload (GCC 4.6.1).
For my big endian target,
(subreg:HI (reg:PSI A0_REGNO) 0) is not representable but
(subreg:HI (reg:PSI A0_REGNO) 2) is (reg:HI A0_REGNO).
The issue occurs when
Hi,
Andrew Pinski pins...@gmail.com skribis:
2012/3/9 Ludovic Courtès ludovic.cour...@inria.fr:
I believe this is not intentional, right?
No, this is intentional. We bootstrap the compiler using the C++
front-end now. We build stage1 with the C compiler and then build
stages 2 and 3
Hi,
ludovic.cour...@inria.fr (Ludovic Courtès) skribis:
Andrew Pinski pins...@gmail.com skribis:
2012/3/9 Ludovic Courtès ludovic.cour...@inria.fr:
I believe this is not intentional, right?
No, this is intentional. We bootstrap the compiler using the C++
front-end now. We build stage1
Hi
I'm testing __attribute__((nonnull)) and -Wnonnull.
It seems like it does warn before constant/vrp propagations.
Example code does not warn for first 2 calls to f(NULL),
but warns for last 2 calls to f(NULL).
Couldn't this checker be improved/extended to do checks also after some basic
On 03/09/2012 11:20 AM, Aurelien Buhrig wrote:
Hi,
It seems there is an issue around subreg:HI of PSI hardware register,
which occurs either during expand or reload (GCC 4.6.1).
For my big endian target,
(subreg:HI (reg:PSI A0_REGNO) 0) is not representable but
(subreg:HI (reg:PSI
Hi,
I believe this is not intentional, right?
No, this is intentional. We bootstrap the compiler using the C++
front-end now. We build stage1 with the C compiler and then build
stages 2 and 3 with the C++ compiler.
OK.
However, this means that plug-ins must now be built with g++, except
ludovic.cour...@inria.fr (Ludovic Courtès) writes:
However, this means that plug-ins must now be built with g++, except
when GCC was configured with --disable-build-poststage1-with-cxx. This
seems difficult to deal with, for plug-in writers.
This is an unfortunate truth during our transition
09/03/2012 15:08, Bernd Schmidt :
On 03/09/2012 11:20 AM, Aurelien Buhrig wrote:
Hi,
It seems there is an issue around subreg:HI of PSI hardware register,
which occurs either during expand or reload (GCC 4.6.1).
For my big endian target,
(subreg:HI (reg:PSI A0_REGNO) 0) is not
Ian Lance Taylor i...@google.com skribis:
ludovic.cour...@inria.fr (Ludovic Courtès) writes:
However, this means that plug-ins must now be built with g++, except
when GCC was configured with --disable-build-poststage1-with-cxx. This
seems difficult to deal with, for plug-in writers.
This
ludovic.cour...@inria.fr (Ludovic Courtès) writes:
Ian Lance Taylor i...@google.com skribis:
ludovic.cour...@inria.fr (Ludovic Courtès) writes:
However, this means that plug-ins must now be built with g++, except
when GCC was configured with --disable-build-poststage1-with-cxx. This
seems
On 03/09/2012 04:20 PM, Aurelien Buhrig wrote:
I'm not used to work at tree level for now and it is unclear for me what
part of the code should be tweaked. Can you tell me which part of the
code you are fixing/looking at, so that I can have a better
understanding of ptr_mode vs Pmode before
Le 09/03/2012 17:10, Bernd Schmidt a écrit :
On 03/09/2012 04:20 PM, Aurelien Buhrig wrote:
I'm not used to work at tree level for now and it is unclear for me what
part of the code should be tweaked. Can you tell me which part of the
code you are fixing/looking at, so that I can have a better
Ian Lance Taylor i...@google.com skribis:
ludovic.cour...@inria.fr (Ludovic Courtès) writes:
Ian Lance Taylor i...@google.com skribis:
ludovic.cour...@inria.fr (Ludovic Courtès) writes:
However, this means that plug-ins must now be built with g++, except
when GCC was configured with
ludovic.cour...@inria.fr (Ludovic Courtès) writes:
Ian Lance Taylor i...@google.com skribis:
ludovic.cour...@inria.fr (Ludovic Courtès) writes:
Ian Lance Taylor i...@google.com skribis:
ludovic.cour...@inria.fr (Ludovic Courtès) writes:
However, this means that plug-ins must now be built
The answer from the Austin Group list was that the POSIX requirement
*does* mean all symbols from time.h are to be defined by pthread.h and
it's a bug in the change history that it refers to allowing rather
than requiring the symbols to be made visible. Thus, I propose this
patch to make
The change seems fine. But I think the log entry should have an explicit
pointer to the POSIX interpretation citation by way of rationale.
Thanks,
Roland
On Fri, 9 Mar 2012, Roland McGrath wrote:
The change seems fine. But I think the log entry should have an explicit
pointer to the POSIX interpretation citation by way of rationale.
I've committed it with references in the log to
Snapshot gcc-4.6-20120309 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120309/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Fri, 2012-03-09 at 11:41 +0100, Ludovic Courtès wrote:
Hi,
Andrew Pinski pins...@gmail.com skribis:
2012/3/9 Ludovic Courtès ludovic.cour...@inria.fr:
I believe this is not intentional, right?
No, this is intentional. We bootstrap the compiler using the C++
front-end now. We
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #29 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-09
08:40:32 UTC ---
(In reply to comment #28)
Regtest on sh4-unknown-lunix-gnu has been done successfully.
Oleg, your patch is pre-approved.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52537
Bug #: 52537
Summary: slow trim function
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52538
Bug #: 52538
Summary: Extend C++11 UDLs to be compatible with inttypes.h
macros
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52538
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-03-09
09:07:10 UTC ---
If you want to use C++11, then you have to write C++11 code. That is the way
forward I think we have discussed this before.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52537
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Keywords|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51988
--- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org 2012-03-09
09:27:35 UTC ---
Author: pinskia
Date: Fri Mar 9 09:27:29 2012
New Revision: 185131
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185131
Log:
2012-03-09 Andrew
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52538
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-03-09
09:51:34 UTC ---
(In reply to comment #1)
If you want to use C++11, then you have to write C++11 code. That is the way
forward I think we have discussed this before.
Yes,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52536
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #30 from Oleg Endo olegendo at gcc dot gnu.org 2012-03-09
10:02:25 UTC ---
(In reply to comment #29)
(In reply to comment #28)
Regtest on sh4-unknown-lunix-gnu has been done successfully.
Oleg, your patch is pre-approved.
Thanks a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52539
Bug #: 52539
Summary: I/O: Wrong result for UTF-8/UCS-4 list-directed and
namelist read and nml write
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #31 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-09
10:36:31 UTC ---
Created attachment 26859
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26859
A test result
testresult on sh4-unknown-linux-gnu [trunk revision
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540
Bug #: 52540
Summary: std::use_facet throws bad_cast when compiled with
_GLIBCXX_DEBUG
Classification: Unclassified
Product: gcc
Version: 4.6.4
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52541
Bug #: 52541
Summary: g++ allows definition of const POD
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52541
--- Comment #1 from Konrad Rudolph konrad_rudolph at hotmail dot com
2012-03-09 11:09:23 UTC ---
Created attachment 26860
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26860
MWE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540
--- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org 2012-03-09 11:19:34
UTC ---
Hmm, I tested this testcase on my cygwin-cross-compiler for x64 and
I didn't noticed this failure.
I get for it by shown samples always proper output (eg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540
Kai Tietz ktietz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52541
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52533
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-09
11:44:27 UTC ---
Created attachment 26861
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26861
gcc47-pr52533.patch
Untested fix.
--version
GNU Fortran (GCC) 4.8.0 20120309 (experimental) [trunk revision 185121]
$ cat bind.f90
interface
subroutine s() bind(c)
end subroutine s
end interface
procedure(s) :: t
call t
end
$ gfortran -c bind.f90 ; nm bind.o
t MAIN__
U _gfortran_set_args
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540
--- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org 2012-03-09 12:00:00
UTC ---
Issue happens in
include/bits/locale_classes.tcc:
templatetypename _Facet
const _Facet
use_facet(const locale __loc)
{
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540
--- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2012-03-09
12:55:30 UTC ---
I would recommend trying to figure out first when the problem has been
introduced, without excluding some sort of compiler issue, because these
library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540
--- Comment #6 from Kai Tietz ktietz at gcc dot gnu.org 2012-03-09 13:00:40
UTC ---
Hmm, it seems to be a shared/static issue on Windows.
As if I pass to command-line -static with the define, the test passes too.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52542
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52530
Uros Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52530
--- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2012-03-09 15:17:07
UTC ---
This patch works for me:
---
diff --git a/gcc/ChangeLog.addr32 b/gcc/ChangeLog.addr32
index 066f1ec..a191e47 100644
--- a/gcc/ChangeLog.addr32
+++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52543
Bug #: 52543
Summary: lower-subreg.c: code bloat of 300%-400% for bulti-word
memory splits
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52543
--- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-09
15:39:41 UTC ---
Created attachment 26862
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26862
lower.c: C source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52543
--- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-09
15:40:58 UTC ---
Created attachment 26863
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26863
lower.s: Assembler output
Compiled with
avr-gcc lower.c -Os -S -dp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52543
--- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-09
15:44:46 UTC ---
Created attachment 26864
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26864
lower.s: Assembler output with -fno-split-wide-types
Compiled with
avr-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52543
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47631
Rainer Orth ro at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52104
Rainer Orth ro at gcc dot gnu.org changed:
What|Removed |Added
Target|i386-pc-solaris2.[89] |i386-pc-solaris2.1[01]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52530
Uros Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52530
--- Comment #8 from Uros Bizjak ubizjak at gmail dot com 2012-03-09 17:08:13
UTC ---
Created attachment 26865
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26865
Patch that introduces %E modifier
Patch in testing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52544
Bug #: 52544
Summary: compilation fails with -finstrument-functions and sse
c code
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52267
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52530
--- Comment #9 from uros at gcc dot gnu.org 2012-03-09 18:01:56 UTC ---
Author: uros
Date: Fri Mar 9 18:01:47 2012
New Revision: 185148
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185148
Log:
PR target/52530
* config/i386/i386.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52456
--- Comment #7 from Benjamin Kosnik bkoz at gcc dot gnu.org 2012-03-09
18:46:52 UTC ---
Hey all. Undesignated are optionally-added symbols (like tls) that are
configure or platform dependant and so are not set into the baselines. This is
new.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52545
Bug #: 52545
Summary: output.h: SECTION_EXCLUDE flag clobbers
SECTION_MACH_DEP
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52545
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52545
--- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-09
19:21:09 UTC ---
...and here is the change:
http://gcc.gnu.org/viewcvs?view=revisionrevision=179288
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52545
--- Comment #3 from Sriraman Tallam tmsriram at google dot com 2012-03-09
19:36:21 UTC ---
Right, I was not looking at SECTION_MACH_DEP when I defined the macro. Is it ok
to just bump SECTION_MACH_DEP?
The patch I have in mind is:
-#define
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52545
--- Comment #4 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-09
20:27:42 UTC ---
(In reply to comment #3)
Right, I was not looking at SECTION_MACH_DEP when I defined the macro. Is it
ok
to just bump SECTION_MACH_DEP?
The patch I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52546
Bug #: 52546
Summary: -fstack-usage not working with __attribute__((naked))
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52482
--- Comment #4 from David Fang fang at csl dot cornell.edu 2012-03-09
20:44:14 UTC ---
Also, from my testing, it looks like AS=odas is needed; if I just pass
AS_FOR_TARGET=odas, then the wrong assembler is used and sjlj.S fails.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52547
Bug #: 52547
Summary: Internal compiler Error in create_tmp_var in
gimplify.c:465
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52548
Bug #: 52548
Summary: missed PRE optimization when function call follows
to-be hoisted variable
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52521
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-09
21:21:15 UTC ---
Created attachment 26869
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26869
gcc48-pr52521.patch
If ignoring possibility of parameters with default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52545
--- Comment #5 from Sriraman Tallam tmsriram at google dot com 2012-03-09
21:30:54 UTC ---
On Fri, Mar 9, 2012 at 12:27 PM, gjl at gcc dot gnu.org
gcc-bugzi...@gcc.gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52545
--- Comment #4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52546
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52547
--- Comment #1 from Rohit Banga iamrohitbanga at gmail dot com 2012-03-09
21:59:25 UTC ---
Removing -fopenmp resolves the problem. That piece of information should be
helpful in solving the bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785
--- Comment #26 from Joseph S. Myers jsm28 at gcc dot gnu.org 2012-03-09
22:13:49 UTC ---
The __USE_GNU conditional has now been removed from glibc after further
discussion on libc-alpha, so the libstdc++ changes can be reverted (probably
after
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52546
--- Comment #2 from Marek Vasut marek.vasut at gmail dot com 2012-03-09
22:53:04 UTC ---
(In reply to comment #1)
Is there any way to tell the compiler how much stack does a naked function
consume (or that it consumes zero stack)? Is this a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785
--- Comment #27 from Paolo Carlini paolo.carlini at oracle dot com 2012-03-09
23:48:17 UTC ---
Thanks a lot Joseph, a very good solution.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52548
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835
--- Comment #52 from Thorsten Glaser tg at mirbsd dot org 2012-03-10 00:52:32
UTC ---
Mikael’s patches work fine for me, gnat-4.6 (4.6.3-1+m68k.2) has just made its
way to debian-ports.org unreleased, chances are it’ll become part of the stock
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52544
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Component|c |middle-end
The Go frontend can create multiple instances of unnamed types that are,
in the Go language, the same type. This can lead to using different
tree types when generating GENERIC. This normally does no harm because
the differences are usually pointer types. However, it is possible in
some cases to
Hi,
please have a look at the attached patch. Test suite results for GCC 4.7
http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg00986.html
--
Sebastian Huber, embedded brains GmbH
Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone : +49 89 18 90 80 79-6
Fax : +49 89 18 90 80
This patch also completely replaces get_bit_range (which is where
PR52097 ICEs) by a trivial implementation.
How does it short-circuit the decision made by get_best_mode exactly? By
making get_bit_range return non-zero in more cases?
There is PR52134 which will make this patch cause 1 gnat
This is in preparation for the upcoming implementation change. This removes
useless code, modernizes obsolete idioms and makes things more explicit.
Tested on i586-suse-linux, applied on the mainline.
2012-03-09 Eric Botcazou ebotca...@adacore.com
* gcc-interface/ada-tree.h
On Mar 8, 2012, at 7:10 PM, Mike Stump wrote:
On Mar 8, 2012, at 5:49 AM, Tristan Gingold wrote:
Argh, that's an issue. We don't run the gcc test suite natively on VMS
because there is no port of Dejagnu (if ever doable) to VMS. We haven't
tried
to test a cross-compiler (and running the
On Fri, Mar 9, 2012 at 00:40, Janne Blomqvist blomqvist.ja...@gmail.com wrote:
Note that GFortran previously did roundTiesToAway, whereas at least
glibc snprintf() does roundTiesToEven, so some change in behavior is
expected. Anyway, this is IMHO for the better, as it avoids biasing
the
Hi,
on VMS systems, the systems headers are in text archives. We require that
these headers are unarchived, but we also need to follow more closely the
naming rules.
In particular, directories and suffixes are stripped when DEC-C looks in
archives, and the archives are case insensitive.
To
Well. I suppose fixing that negative DECL_FIELD_OFFSET thing should
be #1 priority.
Tentative patch attached (you need an up-to-date tree). We cannot really get
rid of the negative offsets for thin pointers, so the patch pulls them out of
record types and uses pointer arithmetics instead.
Hello Anthony,
On 4 Mar 2012, at 21:20, Anthony Green wrote:
The attached patch includes changes that have been reviewed,
approved and merged into the stand-alone libffi release tree**.
This hunk (and an identical change in src/powerpc/darwin.S) ..
Index: src/powerpc/darwin_closure.S
On Mar 8, 2012, at 4:18 PM, Joseph S. Myers wrote:
On Thu, 8 Mar 2012, Tristan Gingold wrote:
Argh, that's an issue. We don't run the gcc test suite natively on VMS
because there is no port of Dejagnu (if ever doable) to VMS. We haven't
tried
to test a cross-compiler (and running the
I have merged trunk revision 185128 to the gccgo branch.
Ian
Hi,
this patch adds new entries to vms-crtlmap.map.
I hope this is the last such patch before I extract by a script all the entries.
Committed on trunk.
Tristan.
2012-03-09 Tristan Gingold ging...@adacore.com
* config/vms/vms-crtlmap.map: Add comments.
Add entries needed to
This patch adjusts the behavior of the wavefront to incorporate frontend
inlining support when compiling on AMMP or VM targets. This new support
is temporarily available using -gnatd.k
These are the rules:
* At -O0, or compiling on AAMP or VM targets, use fe inlining when
inline_always is
Current_Directory incorrectly returned the path of the form X:
instead of X:\
Manually tested on i686-pc-mingw32.
Tested on x86_64-pc-linux-gnu, committed on trunk
2012-03-09 Vasiliy Fofanov fofa...@adacore.com
* a-direct.adb: Do not strip the trailing directory separator
from
This change adds the front-end support for new representation attribute/aspect
Scalar_Storage_Order.
Tested on x86_64-pc-linux-gnu, committed on trunk
2012-03-09 Thomas Quinot qui...@adacore.com
* exp_attr.adb, freeze.adb, sem_attr.adb, aspects.adb, aspects.ads,
sem_ch13.adb,
This patch implements the expansion of the so-called of iterator over
multidimensional arrays (for Element of Array loop).
Tested on x86_64-pc-linux-gnu, committed on trunk
2012-03-09 Vincent Pucci pu...@adacore.com
* exp_ch5.adb (Expand_Iterator_Loop):
Call to
Hi!
My recent commit to tree-vrp.c on the trunk caused the following
testcase to fail, the problem is that we would insert = 255
assertion for unsigned char expression (which doesn't say anything)
and VRP insist that such ASSERT_EXPRs aren't added.
Fixed thusly, in addition the patch cleans the
On Thu, Mar 08, 2012 at 04:54:31PM +0100, Jakub Jelinek wrote:
This patch adds ASSERT_EXPRs for
if ((int) var cmp CST)
(for cmp , =, , =). As the testcase shows, various different tests
are folded into that form.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
This
On Thu, Mar 8, 2012 at 7:20 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Sun, Mar 4, 2012 at 9:13 PM, Uros Bizjak ubiz...@gmail.com wrote:
We only need to handle zero-extended addresses in DImode.
OK for trunk?
2012-03-02 H.J. Lu hongjiu...@intel.com
* config/i386/i386.c
Hi,
This patch changes ‘generate_option’ to not insert any white spaces
after ‘-l’.
This fixes a problem introduced in GCC 4.6 (r163459) whereby
‘gfortran -v’ would emit erroneous strings like this:
Driving: […] -l gfortran -l m -shared-libgcc […]
Note the space after ‘-l’.
(In turn, that
1 - 100 of 134 matches
Mail list logo
