http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53583
--- Comment #3 from ravish 2012-06-06
06:31:16 UTC ---
(In reply to comment #2)
> Dup of bug 42750. Related to PR 39747
> *** This bug has been marked as a duplicate of bug 42750 ***
Hi,
In Bug-ID 42750 user was requested for how to build gmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53586
--- Comment #1 from Andrew Pinski 2012-06-06
05:58:39 UTC ---
What happens if you use decltype instead of typeof ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53586
Bug #: 53586
Summary: Internal compiler errors on cp/pt.c:12077 and
expr.c:9147
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53585
Bug #: 53585
Summary: template value parameter of pointer-to-member type
incorrectly rejects non-direct values
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53511
--- Comment #11 from Kazumoto Kojima 2012-06-05
23:49:48 UTC ---
(In reply to comment #10)
> Yeah, probably. I also don't care that much which option is on/off by
> default.
> I just wanted it to be aligned with the other targets and the overa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53511
--- Comment #10 from Oleg Endo 2012-06-05
23:06:33 UTC ---
(In reply to comment #9)
> Yes. -mfused-madd is for a micro optimization after all. It would
> be tolerable even if it can't generate fmac insns in the case like (*).
> OTOH deleting th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53511
--- Comment #9 from Kazumoto Kojima 2012-06-05
22:35:28 UTC ---
(In reply to comment #7)
> Making -mfused-madd a no-op with special handling will only differ in the (*)
> marked case. Is this what you had in mind?
Yes. -mfused-madd is for a mi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53571
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53584
--- Comment #2 from Ling Li 2012-06-05 20:59:24 UTC
---
You are right. My bad. I thought having a user-declared destructor would be
different than having a user-declared constructor, and the fact that GCC 4.6
accepted the code doubled my belief
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53584
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53584
Bug #: 53584
Summary: [4.7 Regression] [C++0x] deleted function
unique_ptr::operator=(const unique_ptr &)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Sta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53511
--- Comment #8 from Oleg Endo 2012-06-05 20:12:51
UTC ---
(In reply to comment #6)
> Looking into the __builtin_sh_media_FMAC_S implementation, it takes
> 2 floating arguments and one return float value. It looks that
> "a = __builtin_sh_media_F
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53511
--- Comment #7 from Oleg Endo 2012-06-05 20:08:08
UTC ---
> (In reply to comment #4)
>
> Make -mfused-madd no-op instead to remove for the backward
> compatibility.
Sorry, I don't quite follow. According to my understanding we have
something l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42750
Andrew Pinski changed:
What|Removed |Added
CC||ravish_nayak2003 at yahoo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53583
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #2 from Andrew Pins
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53487
--- Comment #4 from Michael Meissner 2012-06-05
19:40:39 UTC ---
Author: meissner
Date: Tue Jun 5 19:40:34 2012
New Revision: 188248
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188248
Log:
[gcc]
2012-06-04 Michael Meissner
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53583
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53583
Bug #: 53583
Summary: gcc 4.6.2 build issue..
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: critical
Priority: P3
Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53270
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52680
--- Comment #10 from Jonathan Wakely 2012-06-05
18:15:28 UTC ---
some ideas at http://gcc.gnu.org/ml/libstdc++/2012-05/msg00085.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53470
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #7 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53582
Bug #: 53582
Summary: [4.6 regression, fixed in 4.7, I think] ICE on valid
code
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #22 from Jonathan Wakely 2012-06-05
17:30:18 UTC ---
(In reply to comment #21)
> Is there any chance this 'feature' of GCC could be kept as a g++ specific
> extension in 'gnu++11' mode, as I think the old behaviour is an improvement
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #21 from Keean Schupke 2012-06-05 17:01:01 UTC
---
(In reply to comment #20)
Yes, once again sorry. Obviously not GCC's problem for implementing the
standard correctly, but this causes problems producing elegant datatype generic
code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #20 from Paolo Carlini 2012-06-05
16:31:21 UTC ---
I'm under the impression that the bug reports using the word 'broken' are the
ones most likely broken, err invalid. Maybe just another manifestation of the
illusion of confidence, wel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50679
--- Comment #3 from Markus Trippelsdorf
2012-06-05 16:11:05 UTC ---
(In reply to comment #2)
> I've seen a few strange segfaults while testing the LTO kernel however.
>
> For example:
> screen[1608]: segfault at 7fff42d73e98 ip 0040600a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50620
Markus Trippelsdorf changed:
What|Removed |Added
Status|NEW |RESOLVED
Version|4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53581
--- Comment #1 from Jan Rüegg 2012-06-05 13:19:58 UTC
---
Might have to do something with:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53498
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53575
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53575
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53575
--- Comment #2 from hjl at gcc dot gnu.org 2012-06-05
13:13:01 UTC ---
Author: hjl
Date: Tue Jun 5 13:12:52 2012
New Revision: 188240
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188240
Log:
Select x32 run-time library for --with-abi={
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53581
Bug #: 53581
Summary: Segmentation fault when enabling -std=c++0x on
template code
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50619
--- Comment #7 from Tobias Burnus 2012-06-05
13:05:38 UTC ---
Author: burnus
Date: Tue Jun 5 13:05:31 2012
New Revision: 188237
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188237
Log:
2012-06-05 Tobias Burnus
PR fortran/50
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #19 from Keean Schupke 2012-06-05 12:55:06 UTC
---
(In reply to comment #18)
Sorry about that. It does indeed seem that the combination of [temp.dep.res]
and [basic.lookup.argdep] imply this behaviour. I think my point was more about
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30442
--- Comment #9 from Richard Guenther 2012-06-05
12:39:29 UTC ---
So, $summary is still true but we now at least vectorize the initialization.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30442
--- Comment #8 from Richard Guenther 2012-06-05
12:38:30 UTC ---
Author: rguenth
Date: Tue Jun 5 12:38:26 2012
New Revision: 188235
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188235
Log:
2012-06-05 Richard Guenther
PR tree-op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #18 from Jonathan Wakely 2012-06-05
11:57:20 UTC ---
(In reply to comment #16)
> why does ADL work here if [basic.lookup.argdep] means what you imply?
That's not ADL, so I don't know what you're asking.
Bugzilla is not the right pla
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50619
--- Comment #6 from Stephan Weller
2012-06-05 11:56:59 UTC ---
Great, this fixes the problem for me. In current svn revision, -finit-real=NAN
works as expected. Thanks for keeping up the good work!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #16 from Keean Schupke 2012-06-05 11:53:32 UTC
---
(In reply to comment #14)
Basic.lookup.argdep is not specific to templates, so why does the dependent
lookup work outside of templates?
int g(int x) {
return x - 1;
}
double g(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #16 from Keean Schupke 2012-06-05 11:53:32 UTC
---
(In reply to comment #14)
Basic.lookup.argdep is not specific to templates, so why does the dependent
lookup work outside of templates?
int g(int x) {
return x - 1;
}
double g(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #15 from Jonathan Wakely 2012-06-05
11:33:59 UTC ---
(In reply to comment #12)
> (In reply to comment #10)
>
> although -fpermissive allows the code to compile (in some circumstances) it
> does not in all, and it also produces incorr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #14 from Jonathan Wakely 2012-06-05
11:31:07 UTC ---
[temp.dep.res] says dependent name resolution considers declarations visible at
the point of definition, and declarations from associated namespaces from the
instantiation context a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #13 from Keean Schupke 2012-06-05 11:25:40 UTC
---
(In reply to comment #9)
>From ISO14882 14.6 - Name resolution [temp.res]
-8- When looking for the declaration of a name used in a template definition,
the usual lookup rules (basic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #12 from Keean Schupke 2012-06-05 11:14:00 UTC
---
(In reply to comment #10)
although -fpermissive allows the code to compile (in some circumstances) it
does not in all, and it also produces incorrect output, for example:
#include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53580
Fernando G. Tinetti changed:
What|Removed |Added
CC||fernando at info dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #11 from Keean Schupke 2012-06-05 11:07:14 UTC
---
(In reply to comment #9)
Can you point me at where in the specification this is defined?
> (In reply to comment #2)
> > The function called in the template definition is clearly d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
Jonathan Wakely changed:
What|Removed |Added
Severity|major |normal
--- Comment #9 from Jonathan Wak
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53572
--- Comment #6 from Yuri Gribov 2012-06-05
10:53:56 UTC ---
Jan's suggestion indeed fixed the bug, thanks!
Regarding Richard's suggestion: should we ask binutils guys to detect situation
when LTO plugin fails to deliver symbols which it promised
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30442
--- Comment #7 from Richard Guenther 2012-06-05
10:50:22 UTC ---
The
long long test2(void)
{
long long a[32];
int i;
for (i = 0; i < 32; i++)
a[i] = 0;
return foo(a);
}
loop is transformed to memset at -O3. The unrolled version i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #8 from Keean Schupke 2012-06-05 10:15:18 UTC ---
(In reply to comment #7)
Have a read of the C++ standard, the example given in:
N3242=11-0012 14.6 Name Resolution: paragraph 10
Which I have pasted above into comment #4 and the extr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081
--- Comment #9 from Richard Guenther 2012-06-05
09:24:48 UTC ---
Author: rguenth
Date: Tue Jun 5 09:24:43 2012
New Revision: 188232
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188232
Log:
2012-06-05 Richard Guenther
PR tree-op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53511
--- Comment #6 from Kazumoto Kojima 2012-06-05
09:21:49 UTC ---
> It seems that __builtin_sh_media_FMAC_S is broken on trunk
> in the first place, though I can test it only on sh64-elf
> environment now. Anyway the patch should OK in this regard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #6 from Keean Schupke 2012-06-05 09:06:01 UTC ---
The suggested work around in the error message 'adding -fpermissive' to
gcc-4.7.0 does not fix the problem as suggested by the error message. This
would suggest the compiler is not disp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53463
Hans-Peter Nilsson changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
56 matches
Mail list logo
