http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53176
Uros Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Summary|[4.8 Regression]|[4.8 Regression]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53226
Bug #: 53226
Summary: memory consumption for heavy template instantiations
increased massively
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53227
Bug #: 53227
Summary: [4.8 Regression] FAIL: gcc.target/i386/movbe-2.c
scan-assembler-times movbe[ \t] 4
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53226
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53219
--- Comment #2 from Martin Husemann martin at netbsd dot org 2012-05-04
07:56:48 UTC ---
I double checked: the sigsetjmp/siglonjmp function prototypes are properly
marked as returns_twice and noreturn, so I claim this to be abug in gcc ;-)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602
--- Comment #18 from rguenther at suse dot de rguenther at suse dot de
2012-05-04 08:17:57 UTC ---
On Thu, 3 May 2012, andi-gcc at firstfloor dot org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602
--- Comment #17 from Andi Kleen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53176
--- Comment #17 from Uros Bizjak ubizjak at gmail dot com 2012-05-04 08:20:27
UTC ---
(In reply to comment #16)
The x86 failure:
FAIL: gcc.target/i386/movbe-2.c scan-assembler-times movbe[ \t] 4
is a register allocator/reload problem. I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53228
Bug #: 53228
Summary: [4.6/4.7/4.8 Regression] target attributes in
libcpp/lex.c cause illegal instructions to be used
elsewhere
Classification: Unclassified
Product:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53228
--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-04
08:33:53 UTC ---
Created attachment 27304
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27304
preprocessed source
Preprocessed lex.c from the 4.6 branch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53228
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target||i?86-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53228
--- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-05-04
08:43:09 UTC ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49104 ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51564
--- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-04
08:42:31 UTC ---
I'm always relucant in backporting this kind of fixes as the LTO state is
so different on branches. Can you confirm that backporting this fix fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53219
--- Comment #3 from Mikael Pettersson mikpe at it dot uu.se 2012-05-04
08:48:08 UTC ---
Please provide a test case. See http://gcc.gnu.org/bugs/#report.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
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=53228
--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-04
08:57:44 UTC ---
The revision that supposedly fixed the issue is in reporters sources
(for reference: https://bugzilla.novell.com/show_bug.cgi?id=760210).
Note that I see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53227
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53213
lbl2007 at gmx dot net changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53226
--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-04
09:01:32 UTC ---
Can you bi-sect to an exact revision causing the regression?
What compile options do you use?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53220
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53216
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53195
--- Comment #1 from vincenzo Innocente vincenzo.innocente at cern dot ch
2012-05-04 09:22:30 UTC ---
does not happen with latest version of
gcc version 4.7.1 20120504 (prerelease) (GCC)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53226
--- Comment #3 from Mario Baumann mario-baumann at web dot de 2012-05-04
09:33:07 UTC ---
Hi Richard,
compile options are: -m32 -msse -msse2 -mfpmath=sse -fPIC -pipe -Wall -Wunused
-Werror -O2 -g
bi-sect: in progress ...
Mario.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2012-05-04
09:44:13 UTC ---
(In reply to comment #3)
I don't think this is valid as the memory which is done after the operator
new
is considered as unitialized.
The code does
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53214
--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-04
10:05:02 UTC ---
Reduced C testcase:
double a(double) __attribute__ ((optimize(3), used));
double a(double r)
{
return r;
}
int main () { }
ICEs this way with
gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53214
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53195
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52908
Venkataramanan venkataramanan.kumar at amd dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53152
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602
--- Comment #19 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-04
11:00:36 UTC ---
Patch I am testing:
Index: gcc/lto-wrapper.c
===
--- gcc/lto-wrapper.c (revision
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496
--- Comment #24 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-05-04
11:01:39 UTC ---
Author: ebotcazou
Date: Fri May 4 11:01:34 2012
New Revision: 187150
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187150
Log:
PR target/48496
='-O2 -fPIC -ftree-vectorize -fvisibility-inlines-hidden -march=native'
-enable-libitm -disable-multilib
Thread model: posix
gcc version 4.8.0 20120504 (experimental) [trunk revision 187149] (GCC)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496
--- Comment #25 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-05-04
11:13:26 UTC ---
Author: ebotcazou
Date: Fri May 4 11:13:20 2012
New Revision: 187152
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187152
Log:
PR target/48496
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53152
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC|lopezibanez at gmail dot|manu at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53168
--- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-04
11:30:39 UTC ---
Author: rguenth
Date: Fri May 4 11:30:35 2012
New Revision: 187153
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187153
Log:
2012-05-04 Richard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53214
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53168
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53228
Uros Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53229
Bug #: 53229
Summary: macro unwinder for preprocessing errors
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53228
--- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-04
11:44:02 UTC ---
I can confirm the patch works though I don't trivially see how it fixes the
interaction with the option save/restore code ;)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602
--- Comment #20 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-04
11:47:10 UTC ---
Author: rguenth
Date: Fri May 4 11:47:06 2012
New Revision: 187155
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187155
Log:
2012-05-04 Richard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53230
Bug #: 53230
Summary: s-fileio.adb:308:10: warning: ‘Errno’ may be used
uninitialized in this function
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53231
Bug #: 53231
Summary: libatomic/tas_n.c:100:10: error: 'ret' undeclared
(first use in this function)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53231
--- Comment #1 from John David Anglin danglin at gcc dot gnu.org 2012-05-04
12:10:17 UTC ---
Also occurs on hppa64-hp-hpux11.11.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53152
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53152
--- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2012-05-04
12:31:23 UTC ---
Created attachment 27306
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27306
POC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53228
--- Comment #6 from Uros Bizjak ubizjak at gmail dot com 2012-05-04 12:46:24
UTC ---
(In reply to comment #5)
I can confirm the patch works though I don't trivially see how it fixes the
interaction with the option save/restore code ;)
It
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52633
--- Comment #3 from Ulrich Weigand uweigand at gcc dot gnu.org 2012-05-04
12:46:14 UTC ---
Author: uweigand
Date: Fri May 4 12:46:04 2012
New Revision: 187158
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187158
Log:
gcc/
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52633
Ulrich Weigand uweigand at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52908
--- Comment #5 from Uros Bizjak ubizjak at gmail dot com 2012-05-04 12:51:49
UTC ---
(In reply to comment #4)
A Quick make check on i386.exp result is shown below:
Tests that now fail, but worked before:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53232
Bug #: 53232
Summary: No warning for main() without a return statement with
-std=c99
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42613
--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-04
13:07:05 UTC ---
-save-temps will only send files to /tmp if you do not provide a linker output
name. Otherwise the ltrans files are named after that output.
So I belive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52633
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53128
--- Comment #6 from Igor Zamyatin izamyatin at gmail dot com 2012-05-04
13:19:07 UTC ---
Compiler does not simply see such code, it happens after some analysis, right?
For example, after work of infer_loop_bounds_from_undefined which makes some
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53219
--- Comment #4 from Martin Husemann martin at netbsd dot org 2012-05-04
13:27:37 UTC ---
Created attachment 27307
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27307
intermediate file when compiling regcomp.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53219
--- Comment #5 from Martin Husemann martin at netbsd dot org 2012-05-04
13:29:45 UTC ---
Using built-in specs.
COLLECT_GCC=cc
Target: sparc64--netbsd
Configured with: /usr/src/tools/gcc/../../external/gpl3/gcc/dist/configure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53217
William J. Schmidt wschmidt at gcc dot gnu.org changed:
What|Removed |Added
CC||wschmidt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53195
vincenzo Innocente vincenzo.innocente at cern dot ch changed:
What|Removed |Added
Attachment #27289|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53232
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||manu at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53214
--- Comment #5 from vincenzo Innocente vincenzo.innocente at cern dot ch
2012-05-04 14:12:39 UTC ---
confirmed solved.
for the records:
gcc version 4.7.1 20120504 (prerelease) [gcc-4_7-branch revision 187154] (GCC)
with lto
we are left now
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53209
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Target|i686-pc-linux-gnu |
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53232
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-05-04
14:33:53 UTC ---
(In reply to comment #1)
Neither -Wmain warns about this... I think it is a bug, at least in the case
of
-Wmain.
Why? -Wmain checks the type of main, not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53209
--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-05-04
14:38:17 UTC ---
Hey HJ, is your regression hunting machine back to life?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53209
--- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2012-05-04 14:42:08
UTC ---
(In reply to comment #4)
Hey HJ, is your regression hunting machine back to life?
Yes.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53209
--- Comment #6 from Martin Jambor jamborm at gcc dot gnu.org 2012-05-04
14:55:49 UTC ---
It seems to me that Alexandre has posted a patch to address this
issue:
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00280.html
Hm, it does seem far more
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52633
--- Comment #6 from Ulrich Weigand uweigand at gcc dot gnu.org 2012-05-04
14:56:52 UTC ---
Author: uweigand
Date: Fri May 4 14:56:48 2012
New Revision: 187162
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187162
Log:
2012-05-04 Ulrich
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52870
--- Comment #6 from Ulrich Weigand uweigand at gcc dot gnu.org 2012-05-04
14:56:52 UTC ---
Author: uweigand
Date: Fri May 4 14:56:48 2012
New Revision: 187162
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187162
Log:
2012-05-04 Ulrich
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52633
Ulrich Weigand uweigand at gcc dot gnu.org changed:
What|Removed |Added
Status|REOPENED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53166
--- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org
2012-05-04 15:02:10 UTC ---
Author: paolo
Date: Fri May 4 15:02:05 2012
New Revision: 187165
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187165
Log:
/cp
2012-05-04
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53166
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53232
--- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-05-04
15:28:55 UTC ---
(In reply to comment #2)
Why? -Wmain checks the type of main, not whether it has a redundant 'return
0;'
as the last statement.
You are right, I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53232
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-05-04
15:38:22 UTC ---
I think -Wreturn-type says in C++ it doesn't warn about declaring:
main() {}
with no return type. That only applies to C++, so isn't relevant here.
IMHO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53232
--- Comment #5 from Vincent Lefèvre vincent-gcc at vinc17 dot net 2012-05-04
15:44:04 UTC ---
(In reply to comment #4)
IMHO this isn't a bug because in C99 it's well-defined what happens if you
fall
off the end of main,
Only at program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53227
--- Comment #2 from Ulrich Weigand uweigand at gcc dot gnu.org 2012-05-04
16:03:35 UTC ---
Why do you consider this a reload/RA problem? Code before ira looks like:
(insn 2 4 3 2 (set (reg/v:DI 62 [ i ])
(mem/c:DI (reg/f:SI 16 argp) [2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53232
--- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2012-05-04
16:09:40 UTC ---
(In reply to comment #5)
(In reply to comment #4)
IMHO this isn't a bug because in C99 it's well-defined what happens if you
fall
off the end of main,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47659
David Folkner david.folkner at gmail dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53232
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53128
--- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-05-04
16:15:09 UTC ---
(In reply to comment #6)
Compiler does not simply see such code, it happens after some analysis, right?
For example, after work of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52282
--- Comment #3 from andyg1001 at hotmail dot co.uk 2012-05-04 16:22:21 UTC ---
This ICE still occurs in the release version of gcc 4.7.0.
Here is the output from compiling the attached test-case as is:
$ g++-4.7 -std=c++11 ice.cpp
ice.cpp: In
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53227
--- Comment #3 from Uros Bizjak ubizjak at gmail dot com 2012-05-04 16:22:57
UTC ---
(In reply to comment #2)
Why do you consider this a reload/RA problem? Code before ira looks like:
Indeed. The bar case works OK since access to memory is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52282
--- Comment #4 from Daniel Krügler daniel.kruegler at googlemail dot com
2012-05-04 16:42:39 UTC ---
(In reply to comment #3)
This ICE still occurs in the release version of gcc 4.7.0.
And also in 4.8.0 HEAD btw.
The attached test-case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53228
--- Comment #7 from uros at gcc dot gnu.org 2012-05-04 16:42:32 UTC ---
Author: uros
Date: Fri May 4 16:42:23 2012
New Revision: 187168
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187168
Log:
PR target/53228
* config/i386/i386.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53227
--- Comment #4 from Ulrich Weigand uweigand at gcc dot gnu.org 2012-05-04
16:56:59 UTC ---
(In reply to comment #3)
However, reload should notice that memory could be propagated into bswap.
Since register allocation already assigned a hard reg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53228
--- Comment #8 from uros at gcc dot gnu.org 2012-05-04 16:58:21 UTC ---
Author: uros
Date: Fri May 4 16:58:16 2012
New Revision: 187169
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187169
Log:
Backport from mainline
2012-05-04
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53228
--- Comment #9 from uros at gcc dot gnu.org 2012-05-04 17:49:00 UTC ---
Author: uros
Date: Fri May 4 17:48:56 2012
New Revision: 187171
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187171
Log:
Backport from mainline
2012-05-04
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53233
Bug #: 53233
Summary: ICE in extract_insn, at recog.c:2103
Classification: Unclassified
Product: gcc
Version: 4.5.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #6 from Thomas W. Lynch dimitrisdad at gmail dot com 2012-05-04
18:12:10 UTC ---
Part of the type information is the layout inside the class. The operator,
which has been copied into the child via inheritance,
No, inheritance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53234
Bug #: 53234
Summary: [c++0x] unfriendly error message for missing move
constructor
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53235
Bug #: 53235
Summary: [4.8 Regression] 20120504 broke -fdebug-types-section
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2012-05-04
18:31:31 UTC ---
(In reply to comment #6)
So for example, if an parent class has a method, say increment(), that affects
a value to be found in a field at offset, say, 4.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52282
--- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2012-05-04
18:40:51 UTC ---
The ICEs, all of them, in the extended testcase too, seem easy to fix,
apparently it's just that finish_decltype_type doesn't handle ADDR_EXPR. The
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53228
--- Comment #10 from uros at gcc dot gnu.org 2012-05-04 18:43:16 UTC ---
Author: uros
Date: Fri May 4 18:43:10 2012
New Revision: 187172
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187172
Log:
Backport from mainline
2012-05-04
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53228
Uros Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53220
davidxl xinliangli at gmail dot com changed:
What|Removed |Added
CC||xinliangli at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53111
--- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-05-04
18:53:23 UTC ---
Author: burnus
Date: Fri May 4 18:53:17 2012
New Revision: 187174
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187174
Log:
2012-05-04 Tobias Burnus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53175
--- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-05-04
18:54:33 UTC ---
Author: burnus
Date: Fri May 4 18:54:25 2012
New Revision: 187175
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187175
Log:
2012-05-04 Tobias Burnus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #8 from Thomas W. Lynch dimitrisdad at gmail dot com 2012-05-04
18:57:40 UTC ---
No, that's not how it works. If Base::increment() writes to Base::field then it
is always at the same offset into the Base object. Whether that Base
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53236
Bug #: 53236
Summary: using declaration and base function template
overloading
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53233
--- Comment #1 from Sean McGovern gseanmcg at gmail dot com 2012-05-04
19:00:05 UTC ---
The code in question (with line numbers):
93 static void vector_fmul_window_altivec(float *dst, const float *src0,
const float *src1, const float *win, int
1 - 100 of 170 matches
Mail list logo
