Mischa Baars mjbaars1...@gmail.com writes:
Furthermore, since 'fxam' will return a 'non-comparable' during the first
compare, I suppose the function should then enter the first 'else' and
return a '4'.
Non-comparable means that NaN != NaN is always true.
Andreas.
--
Andreas Schwab, SUSE
On 01/16/2013 09:14 AM, Andreas Schwab wrote:
Mischa Baars mjbaars1...@gmail.com writes:
Furthermore, since 'fxam' will return a 'non-comparable' during the first
compare, I suppose the function should then enter the first 'else' and
return a '4'.
Non-comparable means that NaN != NaN is
On 01/16/2013 08:57 AM, Eric Botcazou wrote:
Well, I have an Intel manual here that states that any operation on a
QNaN should return a QNaN, which means that also the compare should
return a QNaN when one or both of the arguments is a QNaN.
No, that isn't how comparisons work. The correct
Mischa Baars mjbaars1...@gmail.com writes:
This means that the first 'if' statement should have been terminated when
There is no such thing as a terminated statement. The first condition
evaluates to true.
Furthermore, the manual states that any operation on a QNaN should return
a QNaN.
On 16 January 2013 08:59, Mischa Baars wrote:
On 01/16/2013 08:57 AM, Eric Botcazou wrote:
Well, I have an Intel manual here that states that any operation on a
QNaN should return a QNaN, which means that also the compare should
return a QNaN when one or both of the arguments is a QNaN.
No,
On 01/16/2013 10:06 AM, Andreas Schwab wrote:
Mischa Baars mjbaars1...@gmail.com writes:
This means that the first 'if' statement should have been terminated when
There is no such thing as a terminated statement. The first condition
evaluates to true.
Whatever you want, although personally I
Hi,
For below simple function from newlib:
static int
is_option (char *argv_element, int only)
{
return ((argv_element == 0)
|| (argv_element[0] == '-') || (only argv_element[0] == '+'));
}
The expanded rtl is like:
9: NOTE_INSN_BASIC_BLOCK 2
2: r113:SI=r0:SI
3:
On 01/16/2013 09:27 AM, Mischa Baars wrote:
On 01/16/2013 10:06 AM, Andreas Schwab wrote:
Mischa Baars mjbaars1...@gmail.com writes:
This means that the first 'if' statement should have been terminated when
There is no such thing as a terminated statement. The first condition
evaluates to
On 01/16/2013 12:07 PM, Andrew Haley wrote:
On 01/16/2013 09:27 AM, Mischa Baars wrote:
On 01/16/2013 10:06 AM, Andreas Schwab wrote:
Mischa Baars mjbaars1...@gmail.com writes:
This means that the first 'if' statement should have been terminated when
There is no such thing as a terminated
On 01/16/2013 12:07 PM, Andrew Haley wrote:
On 01/16/2013 09:27 AM, Mischa Baars wrote:
On 01/16/2013 10:06 AM, Andreas Schwab wrote:
Mischa Baars mjbaars1...@gmail.com writes:
This means that the first 'if' statement should have been terminated when
There is no such thing as a terminated
On 1/16/2013 6:54 AM, Mischa Baars wrote:
]
And indeed apparently the answer then is '2'. However, I don't think
this is correct. If that means that there is an error in the C
specification, then there probably is an error in the specification.
The C specification seems perfectly reasonable to
On 01/16/2013 01:04 PM, Robert Dewar wrote:
On 1/16/2013 6:54 AM, Mischa Baars wrote:
]
And indeed apparently the answer then is '2'. However, I don't think
this is correct. If that means that there is an error in the C
specification, then there probably is an error in the specification.
The
On 1/16/2013 7:10 AM, Mischa Baars wrote:
And as I have said before: if you are satisfied with the answer '2',
then so be it and you keep the compiler the way it is, personally I'm am
not able to accept changes to the sources anyway. I don't think it is
the right answer though.
The fact that
On 01/16/2013 01:28 PM, Robert Dewar wrote:
On 1/16/2013 7:10 AM, Mischa Baars wrote:
And as I have said before: if you are satisfied with the answer '2',
then so be it and you keep the compiler the way it is, personally I'm am
not able to accept changes to the sources anyway. I don't think it
On 01/16/2013 11:54 AM, Mischa Baars wrote:
Here's what Standard C, F.8.3 Relational operators, says:
x != x → false The statement x != x is true if x is a NaN.
x == x → true The statement x == x is false if x is a NaN.
And indeed apparently the answer
On Wed, Jan 16, 2013 at 1:52 PM, Mischa Baars mjbaars1...@gmail.com wrote:
On 01/16/2013 01:28 PM, Robert Dewar wrote:
On 1/16/2013 7:10 AM, Mischa Baars wrote:
And as I have said before: if you are satisfied with the answer '2',
then so be it and you keep the compiler the way it is,
On 1/16/2013 5:00 AM, Andrew Haley wrote:
On 01/16/2013 11:54 AM, Mischa Baars wrote:
Here's what Standard C, F.8.3 Relational operators, says:
x != x → false The statement x != x is true if x is a NaN.
x == x → true The statement x == x is false if x is a
Richard Biener richard.guent...@gmail.com writes:
You can enable FP exceptions via fpsetexceptflag and friends (it's disabled
in the FPU by default) and if you then make sure to compile with
-fsignalling-nans (that's not the default) you will get the desired behavior
(program termination via
On 2013-01-16 12:47:46 +0100, Mischa Baars wrote:
On 01/16/2013 12:07 PM, Andrew Haley wrote:
Comparisons with NaN don't terminate a statement, and they don't
return a NaN. They return a boolean.
They shouldn't return anything, the comparison should be terminated.
This depends on the
On Wed, Jan 16, 2013 at 4:52 AM, Mischa Baars mjbaars1...@gmail.com wrote:
Let me explain again for you. Every 'if' statement in C is translated into a
'fucom' or similar instruction, which sets a number of conditions flags in
the co-processor. Some instructions need you to load these into the
On 2013-01-16 14:53:42 +0100, Richard Biener wrote:
You can enable FP exceptions via fpsetexceptflag and friends (it's
disabled in the FPU by default) and if you then make sure to compile
with -fsignalling-nans (that's not the default) you will get the
desired behavior (program termination via
On 01/16/2013 02:28 AM, Bin.Cheng wrote:
Hi,
For below simple function from newlib:
static int
is_option (char *argv_element, int only)
{
return ((argv_element == 0)
|| (argv_element[0] == '-') || (only argv_element[0] == '+'));
}
The expanded rtl is like:
9:
Basic blocks 8/9/10 are identical and live until pass jump2, which is
after register allocation.
I think these duplicated BBs do not contain additional information and
should be better to be removed ASAP, because they might interfere with
other passes like ifcvt.
So should this issue be
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf
Of Mischa Baars
Sent: 16 January 2013 12:53
To: Robert Dewar; gcc@gcc.gnu.org
Subject: Re: not-a-number's
On 01/16/2013 01:28 PM, Robert Dewar wrote:
On 1/16/2013 7:10 AM, Mischa Baars wrote:
Someone removed isl-0.10.tar.bz2 and cloog-0.17.0.tar.gz from
ftp://gcc.gnu.org/pub/gcc/infrastructure. I'd hoping this was in error and the
files can be restored. If there is some compelling reason, I am interested.
Mike Stump mikest...@comcast.net wrote:
Someone removed isl-0.10.tar.bz2 and cloog-0.17.0.tar.gz from
ftp://gcc.gnu.org/pub/gcc/infrastructure. I'd hoping this was in error
and the files can be restored. If there is some compelling reason, I
am interested.
I removed them in favor of the now
Hi All,
From testing, I found out that the whole width of a MIPS
integer/floating-point register
is saved and restored around a call. This may hurt the performance.
Ex:
fu@debian6:/disk/fu/dev/test$ cat add2.c
void test2(float);
float test(float a, float b)
{
test2(a*b);
return a;
}
Hi,
For x86, shift insn will automatically mask the count to 5 bits in 32
bit mode and to 6 bits in 64 bit mode, so for the testcase below, the
buf_ (-end 63) could be optimized to buf_ -end. But for trunk
compiler, some place in the testcase is not optimized.
typedef unsigned long long
[cc list trimmed]
On Wed, Jan 16, 2013 at 5:44 PM, Wei Mi w...@google.com wrote:
Hi,
For x86, shift insn will automatically mask the count to 5 bits in 32
bit mode and to 6 bits in 64 bit mode, so for the testcase below, the
buf_ (-end 63) could be optimized to buf_ -end. But for trunk
On 01/16/2013 02:53 PM, Richard Biener wrote:
On Wed, Jan 16, 2013 at 1:52 PM, Mischa Baars mjbaars1...@gmail.com wrote:
On 01/16/2013 01:28 PM, Robert Dewar wrote:
On 1/16/2013 7:10 AM, Mischa Baars wrote:
And as I have said before: if you are satisfied with the answer '2',
then so be it
On 01/16/2013 07:23 PM, David Paterson wrote:
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf
Of Mischa Baars
Sent: 16 January 2013 12:53
To: Robert Dewar; gcc@gcc.gnu.org
Subject: Re: not-a-number's
On 01/16/2013 01:28 PM, Robert Dewar wrote:
On
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50229
--- Comment #16 from Ray Donnelly mingw.android at gmail dot com 2013-01-16
07:59:48 UTC ---
Of course, when I wrote '--enable-plugins' I really mean't *not* passing
--disable-plugin (without the 's').
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55940
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55998
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56000
--- Comment #2 from Andreas Schwab sch...@linux-m68k.org 2013-01-16 08:08:33
UTC ---
Does this help?
http://sourceware.org/ml/libffi-discuss/2012/msg00279.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742
--- Comment #23 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16
08:11:42 UTC ---
Merging of target attribute is what gcc/g++ did though, the function would get
then both target attributes (seems later decl's target wins), and the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55301
chrbr at gcc dot gnu.org changed:
What|Removed |Added
CC||chrbr at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55984
--- Comment #5 from janus at gcc dot gnu.org 2013-01-16 08:31:21 UTC ---
The patch in comment 4 fails on:
FAIL: gfortran.dg/select_type_24.f90 -O (test for errors, line 48)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55301
--- Comment #2 from chrbr at gcc dot gnu.org 2013-01-16 08:30:05 UTC ---
Author: chrbr
Date: Wed Jan 16 08:29:54 2013
New Revision: 195230
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195230
Log:
PR target/55301
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55301
chrbr at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55940
--- Comment #15 from Frank Mehnert fm3 at os dot inf.tu-dresden.de 2013-01-16
09:01:02 UTC ---
Great, thank you Jakub!
As it will take some time until the Linux distributions will update their gcc
binaries to include this fix, do you
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52688
Daniel Krügler daniel.kruegler at googlemail dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55940
--- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16
09:16:15 UTC ---
As a workaround, you can use something like
#if __GNUC__ == 4 __GNUC_MINOR__ == 7
__attribute__((__optimize__ (no-shrink-wrap)))
#endif
on the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #22 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-16
09:20:43 UTC ---
Author: redi
Date: Wed Jan 16 09:20:34 2013
New Revision: 195231
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195231
Log:
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55882
--- Comment #16 from Richard Biener rguenth at gcc dot gnu.org 2013-01-16
09:26:11 UTC ---
Author: rguenth
Date: Wed Jan 16 09:26:05 2013
New Revision: 195232
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195232
Log:
2013-01-16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Summary|[4.7/4.8 Regression] issue |[4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
Marc Glisse glisse at gcc dot gnu.org changed:
What|Removed |Added
CC||glisse at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #25 from Daniel Krügler daniel.kruegler at googlemail dot com
2013-01-16 09:43:07 UTC ---
(In reply to comment #24)
That really feels like a hack.
It is also broken, I think. The P/R has the effect that is_copy_constructible
is now
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122
--- Comment #12 from Kai Tietz ktietz at gcc dot gnu.org 2013-01-16 09:51:45
UTC ---
Created attachment 29176
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29176
Patch for using recursive copy for directories.
AFAIU we are talking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55999
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55999
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
Kostya Serebryany kcc at gcc dot gnu.org changed:
What|Removed |Added
CC||bergner
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52865
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56000
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55997
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-01-16
10:07:07 UTC ---
While generating a PCH ... ugh.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55995
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #4 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-16
10:14:03 UTC ---
Btw, the mapping I see on my PPC linux box ends with 0x1000
(with ASLR off)
ffd-1000 rw-p 00:00 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55882
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52865
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #26 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-16
10:25:57 UTC ---
(In reply to comment #24)
That really feels like a hack.
It is a hack, to work around a throwing move ctor that I don't have time to
fix.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56001
Bug #: 56001
Summary: [4.7.3 regression] relocation truncated to fit:
R_PPC_REL24 breaks bootstrap on powerpc64-linux
Classification: Unclassified
Product: gcc
Version:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16
10:38:01 UTC ---
Sounds like a recent change:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff;h=048ee0993ec8360abb0b51bdf8f8721e9ed62ec4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52865
--- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16
10:47:18 UTC ---
BTW, does Fortran have well defined number of iterations if say a do loop goes
from (unknown to compiler):
integer :: i, m, n
m = huge(0) - 7
n
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043
--- Comment #27 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-16
10:52:57 UTC ---
Actually, now that the unordered containers do not inherit from Hashtable it
should be much easier to implement something like comment 17. When Daniel first
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50176
--- Comment #21 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16
11:22:23 UTC ---
Created attachment 29177
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29177
gcc48-pr50176.patch
Are you sure about it? For me on the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55153
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16
11:31:51 UTC ---
Author: vmakarov
Date: Tue Jan 15 16:47:36 2013
New Revision: 195211
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195211
Log:
2013-01-15
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52865
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
Kostya Serebryany kcc at gcc dot gnu.org changed:
What|Removed |Added
Summary|FAIL: |asan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16
11:50:47 UTC ---
I think for 44-46 bits we can still make it constant. But generally, the
constructors of libasan are usually run from the stack of the initial thread,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #8 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-16
11:54:36 UTC ---
Sounds good for both.
Andreas, could you please try replacing
kHighMemEnd = 0x0fffUL
with
kHighMemEnd = 0x3fffUL
and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52865
--- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16
11:59:29 UTC ---
Created attachment 29178
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29178
gcc48-pr52865.patch
This untested patch makes the loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56002
Bug #: 56002
Summary: [mutex] allow generic classes to be used without
requiring plattform support for threads
Classification: Unclassified
Product: gcc
Version: 4.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56002
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
--- Comment #54 from Richard Biener rguenth at gcc dot gnu.org 2013-01-16
12:36:52 UTC ---
Re-confirmed on trunk. The initial GFortran IL is still ... awkward. Apart
from the issue of using a canonicalized IV at all we have
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3713
--- Comment #29 from Michael van der Kolff mvanderkolff at gmail dot com
2013-01-16 12:38:41 UTC ---
Created attachment 29180
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29180
testcase for member function pointer that isn't inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3713
Michael van der Kolff mvanderkolff at gmail dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55273
--- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org 2013-01-16
13:17:30 UTC ---
OK, the problem is that the induction variable here is not normal induction
variable but handed by xor.
PPC target seems to be only that translates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54095
--- Comment #15 from Jan Hubicka hubicka at gcc dot gnu.org 2013-01-16
13:18:51 UTC ---
Well, we slipped the 4.8 window :( But I will make the patch soon so it goes
into early 4.9 at least.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55983
--- Comment #7 from janus at gcc dot gnu.org 2013-01-16 13:30:42 UTC ---
Further reduced test case:
type :: mpdata_t
class(bcd_t), pointer :: bcx, bcy
end type
type(mpdata_t) :: this
call this%bcx%fill_halos()
end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56003
Bug #: 56003
Summary: SCEV should thread flags ^= 0x8000 as an addition
to discover an IV var.
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54767
--- Comment #11 from Richard Biener rguenth at gcc dot gnu.org 2013-01-16
13:57:53 UTC ---
Author: rguenth
Date: Wed Jan 16 13:57:48 2013
New Revision: 195238
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195238
Log:
2013-01-16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53465
--- Comment #10 from Richard Biener rguenth at gcc dot gnu.org 2013-01-16
13:57:54 UTC ---
Author: rguenth
Date: Wed Jan 16 13:57:48 2013
New Revision: 195238
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195238
Log:
2013-01-16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55964
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-01-16
14:07:03 UTC ---
Author: rguenth
Date: Wed Jan 16 14:06:58 2013
New Revision: 195239
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195239
Log:
2013-01-16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3713
--- Comment #31 from Jan Hubicka hubicka at gcc dot gnu.org 2013-01-16
14:20:46 UTC ---
Well, after early optimizations we get:
int main() ()
{
struct Foo x;
void Foo::T392 (const struct Foo *) * iftmp.0;
long int _3;
long int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55964
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Summary|[4.7/4.8 Regression]|[4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3713
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
AssignedTo|jamborm at gcc dot gnu.org |rguenth
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56004
Bug #: 56004
Summary: Possible bug with decltype and access modifer order
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55547
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54767
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Known to work||4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56001
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56005
Bug #: 56005
Summary: [4.8 Regression] FAIL: gcc.target/i386/pr45352.c
(internal compiler error)
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56005
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55153
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56005
Andreas Schwab sch...@linux-m68k.org changed:
What|Removed |Added
Target|x86_64-*-* i686-*-* |x86_64-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742
--- Comment #24 from Jason Merrill jason at gcc dot gnu.org 2013-01-16
15:53:28 UTC ---
(In reply to comment #23)
Merging of target attribute is what gcc/g++ did though, the function would get
then both target attributes (seems later
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742
--- Comment #25 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16
16:02:35 UTC ---
The actual merging of target attribute isn't that important, what would be more
important is that other attributes are merged together in that case and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742
--- Comment #26 from richard.guenther at gmail dot com richard.guenther at
gmail dot com 2013-01-16 16:05:01 UTC ---
On Wed, Jan 16, 2013 at 5:02 PM, jakub at gcc dot gnu.org
gcc-bugzi...@gcc.gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52865
--- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16
16:05:42 UTC ---
Author: jakub
Date: Wed Jan 16 16:05:27 2013
New Revision: 195241
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195241
Log:
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56004
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-16
16:19:33 UTC ---
As was explained on stackoverflow, this has nothing t odo with access
modifiers, as you can easily demonstrate by making everything public.
_t has
1 - 100 of 234 matches
Mail list logo
