1) This is offtopic.
Yeah, but I want to bring this up because I can tell it is affecting GCC
development.
From http://gcc.gnu.org/ml/gcc/2008-02/msg00523.html:
If someone steps forward, are you allowed to follow the patches list
We can't read the patches nor gcc list.
and give feedback
Off-topic, but I feel this is important, since Apple contributed to gcc,
and it is licensed under GPLv3 now.
The license of GCC does not matter, unless the iPhone includes a copy of
GCC's binaries for a recent-enough version. In which case, of course,
Apple would be violating the GPLv3 and you
Yuhong Bao wrote:
and Apple uses GCC (which is now under GPLv3) and Mac OS X on it.
Unfortunately, the iPhone is incompatible with GPLv3, if you want more see
the link I mentioned.
Apple does not use a GPLv3 version of GCC. All GPL sources used in the
iPhone, are, as far as I know, available
Thanks for all the links. I knew there were people wanting this but I
didn't quite get how big an issue it was.
Brain Dessent wrote:
You're essentially trusting that all
exception specifiers for every function in the program and *all* library
code are always present and always correct which
I agree that it won't be very useful initially due to lots of third
party code like boost neither defining nor adhering exception
restrictions 100% of the time (STL may be guilty also). However, this
is a catch 22. Why not provide the mechanism for verifying exception
specifications so that
I have no gcc 4.1.2 at hand. but I just had a try with gcc-4.1.0 and
gcc-4.2.0 which compiled a simple testcase with no errors or warnings.
additionally, I had a try with some other compiler than gcc to compile
it. a warning issued.
I think it's possibly too strict of gcc raising a error on sch
Peter O'Gorman wrote:
Yuhong Bao wrote:
and Apple uses GCC (which is now under GPLv3) and Mac OS X on it.
Unfortunately, the iPhone is incompatible with GPLv3, if you want more see
the link I mentioned.
Apple does not use a GPLv3 version of GCC.
Ah, actually I think I now see the OP's
Brendon Costa said:
The author of the template class or container can't know
what types of exceptions will be thrown from them, so you must define
them as being able to throw all exceptions (which is how they are
currently).
Ouch, you have a point. But couldn't you put this round the other
On Wed, Sep 24, 2008 at 11:47:18AM +0200, Paolo Bonzini wrote:
Peter O'Gorman wrote:
Yuhong Bao wrote:
and Apple uses GCC (which is now under GPLv3) and Mac OS X on it.
Unfortunately, the iPhone is incompatible with GPLv3, if you want more see
the link I mentioned.
Apple does not use
Yuhong Bao [EMAIL PROTECTED] writes:
1) This is offtopic.
Yeah, but I want to bring this up because I can tell it is affecting GCC
development.
From http://gcc.gnu.org/ml/gcc/2008-02/msg00523.html:
If someone steps forward, are you allowed to follow the patches list
We can't read the
Well at least that explains their total inactivity in the last year. Is Dale
the one still allowed to read the gcc-patches mailing list?
No, that would be Stan just because he's not at Apple.
It must be said also that Mike Stump accepted to review/discuss
Darwin/ObjC patches that he was CCed
Paolo Bonzini [EMAIL PROTECTED] writes:
Ah, actually I think I now see the OP's point. Apple is scared of the
GPLv3 because the iPhone might violate it, so they are not contributing
to anything that falls under the GPLv3.
...
1) does it make sense to keep a maintainer category that is
However if GPLv3 is such a huge issue
at Apple, it does make one wonder if llvm will ever see a gcc front-end
newer
than the current 4.2 one.
The LLVM folks are writing a new frontend anyhow. In the future they
presumably plan to stop using the gcc frontend. gcc's code is so
Ian Lance Taylor wrote:
Paolo Bonzini [EMAIL PROTECTED] writes:
It's sad, but I think that there is need for the SC to take action on this.
I personally don't think there is any need to remove them as
maintainers until the FSF finally produces the GPLv3 version of the
runtime library license.
Basile STARYNKEVITCH [EMAIL PROTECTED] writes:
Is it top secret information only available to some few members of the
Steering Committee, or is some information sharable on this list? Just
knowing that indeed a runtime library license will be finalized before
Christmas (ie in 2008) and that
I'm just not having any luck bootstrapping this thing ...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37639
On Wed, Sep 24, 2008 at 04:33:35PM +0200, Paolo Bonzini wrote:
Well at least that explains their total inactivity in the last year. Is Dale
the one still allowed to read the gcc-patches mailing list?
No, that would be Stan just because he's not at Apple.
It must be said also that Mike
On Wed, Sep 24, 2008 at 11:26 AM, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Basile STARYNKEVITCH [EMAIL PROTECTED] writes:
Is it top secret information only available to some few members of the
Steering Committee, or is some information sharable on this list? Just
knowing that indeed a
On Sep 24, 2008, at 8:51 AM, Jack Howarth wrote:
The SC knows of the issue
Still, after six months it would be nice to have a clearer idea of
what
will happen with respect to Darwin/ObjC, especially since the
previous
statement (which I suppose was as clear as Mike could do) was
buried
On Sep 24, 2008, at 7:06 AM, Ian Lance Taylor wrote:
fix the problem. My understanding of Apple's current position is that
they won't take any action until they see the final version of the gcc
runtime license.
Basically, what happened is that Apple created a Tivoized device
called the
On Sep 24, 2008, at 8:02 AM, Duncan Sands wrote:
However if GPLv3 is such a huge issue
at Apple, it does make one wonder if llvm will ever see a gcc
front-end newer
than the current 4.2 one.
The LLVM folks are writing a new frontend anyhow. In the future they
presumably plan to stop
On Sep 24, 2008, at 10:01 AM, Chris Lattner wrote:
requirements on that code.
I'm not speaking for Apple here, and I am not a lawyer. However,
the last draft of the runtime library exception clause (which is
quite old by now)
I'm sorry, to be clear, I meant the last draft *that I saw*
On Wed, Sep 24, 2008 at 10:05:37AM -0700, Chris Lattner wrote:
On Sep 24, 2008, at 10:01 AM, Chris Lattner wrote:
requirements on that code.
I'm not speaking for Apple here, and I am not a lawyer. However,
the last draft of the runtime library exception clause (which is
quite old
NightStrike [EMAIL PROTECTED] writes:
There is a simple technique which anybody is free to use to make this
happen much faster: make a large donation to the SFLC and/or the FSF,
contingent on this issue being finished. In the absence of that, it
will happen in the time that people have
Chris Lattner [EMAIL PROTECTED] writes:
On Sep 24, 2008, at 7:06 AM, Ian Lance Taylor wrote:
fix the problem. My understanding of Apple's current position is that
they won't take any action until they see the final version of the gcc
runtime license.
Basically, what happened is that Apple
Chris Lattner [EMAIL PROTECTED] writes:
I'm not speaking for Apple here, and I am not a lawyer. However, the
last draft of the runtime library exception clause (which is quite old
by now) imposed licensing restrictions on the executables generated by
GCC (due to linked runtime libraries)
On Sep 24, 2008, at 10:50 AM, Ian Lance Taylor wrote:
I'm not speaking for Apple here, and I am not a lawyer. However, the
last draft of the runtime library exception clause (which is quite
old
by now) imposed licensing restrictions on the executables generated
by
GCC (due to linked runtime
On Wed, Sep 24, 2008 at 11:11:41AM -0700, Chris Lattner wrote:
Right. However, the wording I saw was much broader than just the
plugin model. It was vague and poorly worded, and you could interpret
it as saying that use of a non-GPL assembler or linker was also not
allowed to build or
On Wed, Sep 24, 2008 at 11:22 AM, Joe Buck [EMAIL PROTECTED] wrote:
On Wed, Sep 24, 2008 at 11:11:41AM -0700, Chris Lattner wrote:
Right. However, the wording I saw was much broader than just the
plugin model. It was vague and poorly worded, and you could interpret
it as saying that use of a
Ian Lance Taylor wrote:
NightStrike [EMAIL PROTECTED] writes:
There is a simple technique which anybody is free to use to make this
happen much faster: make a large donation to the SFLC and/or the FSF,
contingent on this issue being finished. In the absence of that, it
will happen in the time
On Sep 24, 2008, at 11:22 AM, Joe Buck wrote:
On Wed, Sep 24, 2008 at 11:11:41AM -0700, Chris Lattner wrote:
Right. However, the wording I saw was much broader than just the
plugin model. It was vague and poorly worded, and you could
interpret
it as saying that use of a non-GPL assembler
On Wed, Sep 24, 2008 at 4:06 PM, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Apple's dislike of GPLv3 is a problem for gcc, yes.
Well, excuse me for being a-political, but I don't see this problem.
The relationship between GCC and Apple has never been really good
AFAIK, but that hasn't hampered
Steven Bosscher wrote:
On Wed, Sep 24, 2008 at 4:06 PM, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Apple's dislike of GPLv3 is a problem for gcc, yes.
Well, excuse me for being a-political, but I don't see this problem.
The relationship between GCC and Apple has never been really good
AFAIK,
Joe Buck wrote:
On Tue, Sep 23, 2008 at 05:51:23PM -0400, Jason Merrill wrote:
Mark Mitchell wrote:
Is that desirable? Type-based alias analysis should be able to take
advantage of the difference between them; a char ** and a signed char
** cannot point at the same thing, for example.
They
BTW, one of the reason I posted this was that I wanted to privately talk about
the politics behind this issue with someone internal to Apple, and forward some
of that to RMS and the FSF. Can this be done or is the politics all under NDA?
Because this issue isn't just limited to GCC, it is
On Wed, Sep 24, 2008 at 2:47 AM, Lijuan Hai [EMAIL PROTECTED] wrote:
I have no gcc 4.1.2 at hand. but I just had a try with gcc-4.1.0 and
gcc-4.2.0 which compiled a simple testcase with no errors or warnings.
additionally, I had a try with some other compiler than gcc to compile
it. a warning
Yuhong Bao [EMAIL PROTECTED] writes:
BTW, one of the reason I posted this was that I wanted to privately
talk about the politics behind this issue with someone internal to
Apple, and forward some of that to RMS and the FSF. Can this be done
or is the politics all under NDA?
Well, good luck.
Chris Lattner [EMAIL PROTECTED] writes:
My personal feeling on the matter is that it seems very strange to
talk about *compiler plugins* in the license for *runtime libraries*.
Considering that there are already widely available alternative
libraries (e.g. the apache stdc++ library and many
On Sep 24, 2008, at 12:57 PM, Ian Lance Taylor wrote:
Chris Lattner [EMAIL PROTECTED] writes:
My personal feeling on the matter is that it seems very strange to
talk about *compiler plugins* in the license for *runtime libraries*.
Considering that there are already widely available
Snapshot gcc-4.2-20080924 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080924/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Simon Hill wrote:
Brendon Costa said:
The author of the template class or container can't know
what types of exceptions will be thrown from them, so you must define
them as being able to throw all exceptions (which is how they are
currently).
Ouch, you have a point. But couldn't you put this
--- Comment #3 from doug dot gregor at gmail dot com 2008-09-24 06:01
---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01667.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37553
See: http://gcc.gnu.org/ml/fortran/2008-09/msg00380.html
and following emails.
The configure script does link tests which cause some kinds of cross
compilations to fail.
Solution (cf. email thread, see above link):
a) Approved patch in the link above
b) Remove AC_LIBTOOL_DLOPEN which does not
--- Comment #3 from burnus at gcc dot gnu dot org 2008-09-24 07:02 ---
Subject: Bug 37626
Author: burnus
Date: Wed Sep 24 07:01:18 2008
New Revision: 140624
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140624
Log:
2008-09-24 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #4 from tim dot vanholder at anubex dot com 2008-09-24 07:03
---
Then perhaps either configure should reject the too-old version, or the
testcase should detect this situation and either skip the tests in question
and/or report that MPFR is too old. The situation as it
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2008-09-24 07:18
---
Then perhaps either configure should reject the too-old version, or the
testcase should detect this situation and either skip the tests in question
and/or report that MPFR is too old. The situation as it
--- Comment #9 from pault at gcc dot gnu dot org 2008-09-24 08:05 ---
Fixed on trunk and 4.3
Thanks for the report
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pault at gcc dot gnu dot org 2008-09-24 08:05 ---
Subject: Bug 37583
Author: pault
Date: Wed Sep 24 08:04:26 2008
New Revision: 140626
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140626
Log:
2008-09-24 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #6 from pault at gcc dot gnu dot org 2008-09-24 08:14 ---
Fixed on trunk and 4.3
Thanks for the report
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pault at gcc dot gnu dot org 2008-09-24 08:14 ---
Subject: Bug 35945
Author: pault
Date: Wed Sep 24 08:12:47 2008
New Revision: 140627
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140627
Log:
2008-09-24 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #7 from pault at gcc dot gnu dot org 2008-09-24 08:14 ---
Subject: Bug 36700
Author: pault
Date: Wed Sep 24 08:12:47 2008
New Revision: 140627
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140627
Log:
2008-09-24 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #4 from pault at gcc dot gnu dot org 2008-09-24 08:14 ---
Fixed on trunk and 4.3
Thanks for the report
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Requested by Richard Townsend at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/1e4130b9720e4f2a
LEADZ and TRAILZ are rather common vendor extensions, e.g. supported by the
Intel compiler (it also allows for logical arguments).
LEADZ (I)
Description. Number of leading
--- Comment #8 from pault at gcc dot gnu dot org 2008-09-24 08:28 ---
Subject: Bug 36700
Author: pault
Date: Wed Sep 24 08:27:27 2008
New Revision: 140628
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140628
Log:
2008-09-24 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #56 from l dot lunak at suse dot cz 2008-09-24 08:50 ---
(In reply to comment #55)
It seems reasonable to me for try { X } catch... to mean X when
-fno-exceptions. We don't need to error except on throw.
It seems unreasonable to me that gcc would silently modify code's
--- Comment #3 from gcc at spatium dot org 2008-09-24 09:37 ---
Subject: Re: [4.4 Regression] gcc-4.4-20080919 ada build failure
pinskia at gcc dot gnu dot org wrote 767 bytes:
Can you try this again?
same thing with latest trunk.
--
--- Comment #84 from aldot at gcc dot gnu dot org 2008-09-24 09:51 ---
The fix doesn't seem to work for me on arm:
$ cat pr-weak.c
/* tell the compiler that the count isn't in the small data section if the arch
* has one (eg: FRV)
*/
extern const unsigned long kallsyms_num_syms
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org
|dot org
seen with 20080923 from the trunk, try running any of the tools:
$ /usr/lib/gcc-snapshot/bin/gjar -help
Exception in thread main java.lang.ExceptionInInitializerError
at java.lang.Class.initializeClass(natClass.cc:792)
at gnu.classpath.tools.common.Messages.getString(Messages.java:60)
at
The build of the Debian gcc-snapshot package, version 20080923, fails to build
with this output from some sort of constraints check. This constraints are arch
specific.
build/genpreds -h ../../src/gcc/config/s390/s390.md tmp-preds.h
../../src/gcc/config/s390/constraints.md:122: constraint letter
--- Comment #57 from mark at codesourcery dot com 2008-09-24 13:03 ---
Subject: Re: exception_defines.h #defines try/catch
jason at gcc dot gnu dot org wrote:
--- Comment #55 from jason at gcc dot gnu dot org 2008-09-23 20:43
---
It seems reasonable to me for try { X }
Current version of gfortran dies with an ICE on the attached invalid code.
- log ---
[EMAIL PROTECTED] F03]$ gfortran -v -c foo-ext.f03
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/usr/local/gnutest
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-09-24 13:51 ---
We need to look at CALL_EXPR_FN's type because the decltype of a call retrieves
the return type of the the function called, which may be a REFERENCE_TYPE. The
type of the expression will have stripped away that
--- Comment #1 from sfilippone at uniroma2 dot it 2008-09-24 13:51 ---
Created an attachment (id=16400)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16400action=view)
test case
ICE-on-invalid
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37638
--- Comment #2 from jkolb at wsi dot com 2008-09-24 14:07 ---
Binutils 2.19.50
Yes I have. The linker switch does not help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37629
--- Comment #2 from domob at gcc dot gnu dot org 2008-09-24 14:39 ---
Thanks for the report Salvatore, I'll take this one on. It seems the new F2003
features are starting to getting used, from the bug-noise :D
--
domob at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from sfilippone at uniroma2 dot it 2008-09-24 14:50 ---
(In reply to comment #2)
Thanks for the report Salvatore, I'll take this one on. It seems the new
F2003
features are starting to getting used, from the bug-noise :D
Unfortunately these features are not going
--- Comment #3 from brian at dessent dot net 2008-09-24 15:24 ---
Subject: Re: auto-import of constant data results in a crash
at runtime
So, is the segment containing the reference to ff_log2_tab writable?
This still sounds like a linker issue not a compiler issue.
--
--
Summary: Bootstrap fails with may be used uninitialized warning
in c-parser.c
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo:
--- Comment #1 from lucier at math dot purdue dot edu 2008-09-24 15:34
---
Created an attachment (id=16401)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16401action=view)
macro-expanded source of c-parser.c
Sorry for hitting return instead of tab in the initial report ...
--- Comment #4 from jkolb at wsi dot com 2008-09-24 15:35 ---
I'm not sure, I don't have access to that machine right now. Kai Tietz (from
the mingw-w64 project) thought it might be the linker as well. How do I hand
the bug off to the linker folks?
--
--- Comment #1 from kargl at gcc dot gnu dot org 2008-09-24 16:19 ---
(In reply to comment #0)
For compile-time simplification, MPFR does not seem to provide a ready-to-use
function; if one cooks up something oneself, one needs to check endian issues
(though there might be none).
I
A gcc build from today (gcc version 4.4.0 20080924) gets an ICE on PowerPC when
building this (admittedly broken) code:
# gcc -m64 -O2 -c test.c
struct foo {
int a;
char lock;
};
struct foo *foo;
void testcase()
{
__sync_lock_test_and_set((foo-lock), 0);
}
It compiles
--- Comment #5 from hp at gcc dot gnu dot org 2008-09-24 16:49 ---
(In reply to comment #4)
I think this was fixed for 4.3.0:
HP,
can you try this again on cris?
At 140627, the problem is still there on the 4.3 branch for CRIS. I'll attach
a diff of the generated assembly of -O2
--- Comment #6 from hp at gcc dot gnu dot org 2008-09-24 16:51 ---
Created an attachment (id=16402)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16402action=view)
Diff of asembly of -O2 vs -O2 -fno-if-conversion at r.140627
See previous comment.
--
--- Comment #7 from hp at gcc dot gnu dot org 2008-09-24 16:57 ---
I guess I should turn the code in the description into a testcase in gcc.dg so
target maintainers can add their xfailed scan-assembler-not and we'd see
xpasses if/when this is magically fixed...
(After the IRA
adaint.c uses a macro for mingw called FILE_WRITE_PROPERTIES. This has long
since been deprecated, and is instead replaced with FILE_WRITE_EA. Both macros
are defined to the same value (0x0010), but one does not exist in current
versions (such as mingw-w64, the 64-bit port). I recommend
I'll submit a testcase that apparently demonstrates that gcc is trying to apply
signed strict overflow rules to an unsigned short type, at least on 32 bit
machines when short is 16 bit.
Here is the output:
arm-elf-gcc -O2 -W -Wall -Wstrict-overflow=5 -c testcase.c
testcase.c: In function
--- Comment #1 from alexandre dot nunes at gmail dot com 2008-09-24 17:29
---
Created an attachment (id=16403)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16403action=view)
This is the first testcase.
compile with gcc -O2 -W -Wall -Wstrict-overflow=5
--
--- Comment #1 from ktietz at gcc dot gnu dot org 2008-09-24 17:32 ---
FILE_WRITE_PROPERTIES is deprecated and even the documentation is removed from
msdn. So I agree that FILE_WRITE_EA should be used instead.
--
ktietz at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from dlenski at gmail dot com 2008-09-24 17:43 ---
Hi Andrew,
It seems to me that these modifiers are quite necessary for flexible x86
assembly. What is the point of the q and Q constraints if there's no way
to specifically refer to the 16-bit or 8-bit components of the
--- Comment #2 from pinskia at gmail dot com 2008-09-24 17:44 ---
Subject: Re: New: GCC applies signed strict-overflow rules to unsigned short
type
When doing addition unsigned short is promoted to an signed int. So
this is not a bug. That is unsigned short + 1 is a signed int
--- Comment #58 from jason at redhat dot com 2008-09-24 19:21 ---
Subject: Re: exception_defines.h #defines try/catch
l dot lunak at suse dot cz wrote:
--- Comment #56 from l dot lunak at suse dot cz 2008-09-24 08:50 ---
(In reply to comment #55)
It seems reasonable to me
When cross-compiling for vax--netbsdelf, fortran doesn't build. I have a
NetBSD/vax 4.99.72 install symlinked, and am using binutils 2.19.50.20080923.
gcc sources are subversion rev 140638. It gets to here and stops:
libtool: compile: /usr/src/gcc/vax/./gcc/xgcc -B/usr/src/gcc/vax/./gcc/
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-24 19:55 ---
How is this broken code?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from anton at samba dot org 2008-09-24 20:07 ---
After reading the gcc documentation I guess it is valid, and the 32bit
lwarx/stwcx will overlap but not change surrounding memory.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37640
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-09-24 20:16 ---
Something like this fixes the issue:
Index: config/rs6000/rs6000.c
===
--- config/rs6000/rs6000.c (revision 140638)
+++ config/rs6000/rs6000.c
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-09-24 20:20 ---
GCC is doing the right thing here. In this constructor:
Thing2(Thing2 o) : Thing(o) { }
the parameter o is treated as an lvalue, because it has a name. Using
std::move(o) to treat it as an rvalue.
Similarly,
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-09-24 20:36 ---
What happens if you don't use profiledbootstrap but instead bootstrap?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37601
--- Comment #3 from alexandre dot nunes at gmail dot com 2008-09-24 20:42
---
(In reply to comment #2)
Subject: Re: New: GCC applies signed strict-overflow rules to unsigned short
type
When doing addition unsigned short is promoted to an signed int. So
this is not a bug. That
--- Comment #5 from hp at gcc dot gnu dot org 2008-09-24 21:10 ---
(In reply to comment #4)
FWIW, this happens inside libtool configure tests,
so I guess it is harmless inside gcc/.
Do you see this in other directories' configure outputs, too,
No.
and if yes, can you post a
--- Comment #6 from hp at gcc dot gnu dot org 2008-09-24 21:15 ---
Created an attachment (id=16404)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16404action=view)
bzip2:ed native x64-64-linux build_log
The build_log from GeoffK's contrib/regression/btest-gcc.sh) of trunk r139963
--- Comment #2 from steven at gcc dot gnu dot org 2008-09-24 22:28 ---
I'll see this weekend if I can take care of this.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from n dot pipenbrinck at cubic dot org 2008-09-24 22:41
---
ROL/ROR on the native integer size is not supported via intrinsics, but the
compiler will fold two shifts into a rotate.
If I want to manipulate only the lower 16 bit of an 32 bit integer (e.g. issue
a rolw)
Open MP directives in conjunction with LAM MPI calls is causing compiler to
fail:
(bash) niwot.pts/3% export
LAMHF77=/z/stoch/home/rlnaff/usr/local/bin/gfortran4.3.2
(bash) niwot.pts/3% mpif77 -g -fopenmp -c reorder_parent.f90
reorder_parent.f90:470: internal compiler error: Segmentation fault
--- Comment #1 from gnu_andrew at member dot fsf dot org 2008-09-25 01:47
---
I'm not sure when 4.3 branched, but David Daney's locale patch (switching from
gcj's locales to Classpath's) might have had an effect (2008-03-04). It's the
only locale change I can see from this year.
The
--- Comment #12 from pinskia at gcc dot gnu dot org 2008-09-25 02:52
---
This happens also for x86_64.
on the trunk:
L2:
movq%rbx, %rdi
call_f0
testl %eax, %eax
jne L2
4.0.1:
L3:
leaq-4(%rbp), %rdi
call_f0
--- Comment #2 from gnu_andrew at member dot fsf dot org 2008-09-25 03:20
---
Interestingly:
$ /home/andrew/build/gcj/bin/gcj --version
gcj (GCC) 4.4.0 20080913 (experimental) [gcj/classpath-098-merge-branch
revision 140651]
$ /home/andrew/build/gcj/bin/gjar --version
jar (GNU
--- Comment #1 from drangon dot mail at gmail dot com 2008-09-25 04:45
---
Created an attachment (id=16405)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16405action=view)
output of gcc -E
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37121
--- Comment #2 from drangon dot mail at gmail dot com 2008-09-25 04:47
---
Created an attachment (id=16406)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16406action=view)
output of nm, the object is build by gcc -O0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37121
1 - 100 of 106 matches
Mail list logo
