http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48009
Paolo Carlini changed:
What|Removed |Added
CC||dje at gcc dot gnu.org
--- Comment #4 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887
--- Comment #9 from Paolo Carlini 2012-05-12
08:35:05 UTC ---
AIX used to be even more special about this...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315
--- Comment #11 from Jakub Jelinek 2012-05-12
09:14:53 UTC ---
Created attachment 27385
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27385
gcc48-pr53315.patch
That is because the patch is buggy. Fixed thusly, though haven't tested it on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49110
--- Comment #14 from Tobias Burnus 2012-05-12
09:54:00 UTC ---
Author: burnus
Date: Sat May 12 09:53:53 2012
New Revision: 187427
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187427
Log:
2012-05-12 Tobias Burnus
PR fortran/4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52843
--- Comment #1 from Tobias Burnus 2012-05-12
09:54:00 UTC ---
Author: burnus
Date: Sat May 12 09:53:53 2012
New Revision: 187427
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187427
Log:
2012-05-12 Tobias Burnus
PR fortran/49
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52843
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49110
--- Comment #15 from Tobias Burnus 2012-05-12
09:59:10 UTC ---
The commit of comment 13 fixes the issue with the bogus PURE diagnostic.
Sorry that it took one year to get it fixed - and thanks for the bug report.
* * *
Regarding the REPEAT is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49162
--- Comment #1 from Pawel Sikora 2012-05-12 10:26:56
UTC ---
could someone confirm this finally and set target milestone to 4.5.4?
i'd like to drop this old problem from 'my bugs' list with 4.5 termination.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53329
Bug #: 53329
Summary: ICE with deferred-length module variables
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53330
Bug #: 53330
Summary: new() operator can return NULL on a zero-length
allocation
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53330
--- Comment #1 from Adam Borowski 2012-05-12
11:01:23 UTC ---
Correction: after testing with valgrind, the return value is indeed
uninitialized; the pointer in contructor-but-no-fields case happens to be
non-zero but is junk and will cause a cras
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53321
--- Comment #5 from Jan Hubicka 2012-05-12
11:03:01 UTC ---
I need to add disable-werror otherwise we fail on extra warnings, but with that
my bootstrap works. Is it still failing for you? The unreferenced nodes
removal is very basic thing so wh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52700
Pawel Sikora changed:
What|Removed |Added
CC||bkoz at redhat dot com,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315
--- Comment #12 from Uros Bizjak 2012-05-12 11:29:53
UTC ---
(In reply to comment #11)
> Created attachment 27385 [details]
> gcc48-pr53315.patch
Please introduce check-rtm.h header for use in runtime testcases, as is the
case with i.e. check-ss
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50847
Pawel Sikora changed:
What|Removed |Added
CC||lopezibanez at gmail dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50847
--- Comment #2 from Paolo Carlini 2012-05-12
11:56:45 UTC ---
Related to PR46476?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52054
--- Comment #5 from Richard Guenther 2012-05-12
11:57:41 UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> > PR53125 has a testcase where we spend time in redundant store removal in
> > eliminate() which does vn_reference_lookup with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50847
--- Comment #3 from Pawel Sikora 2012-05-12 12:07:06
UTC ---
(In reply to comment #2)
> Related to PR46476?
similar (return vs. throw statment).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50221
--- Comment #2 from Tobias Burnus 2012-05-12
12:10:33 UTC ---
The following program illustrates some of the problems:
a) If the comment lines are removed (i.e. a module is used), there is no
valgrind failure and the result is correct. (Note: It
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50847
Manuel López-Ibáñez changed:
What|Removed |Added
CC|lopezibanez at gmail dot|manu at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46476
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=53315
Jakub Jelinek changed:
What|Removed |Added
Attachment #27385|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53331
Bug #: 53331
Summary: [4.8 Regression] AIX bootstrap failure in
tree-vect-data-ref compiling matmul_i4
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53331
David Edelsohn changed:
What|Removed |Added
Target||powerpc64-*-*
Status|UNCONFI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53331
--- Comment #2 from Dominique d'Humieres 2012-05-12
14:27:07 UTC ---
On powerpc-apple-darwin9 I get a similar failure:
../../../work/libgfortran/generated/matmul_i8.c: In function 'matmul_i8':
../../../work/libgfortran/generated/matmul_i8.c:79:1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48009
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #130 from Jan Hubicka 2012-05-12
14:44:47 UTC ---
After fixing one linker error, I can now build Mozilla with
-flto-partition=none. It takes 11GB and 40 minutes, so there is space for
improvement ;)
There are some obvious questions,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53323
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53319
--- Comment #5 from Fred J. Tydeman 2012-05-12
15:37:54 UTC ---
Another failure:
_Decimal32 val, lo;
val = 0.e-40DF;
lo = 9.e-1DF;
val += lo; /* raises FE_INEXACT */
This is with gcc 4.5.1 on Linux Fedora Core 14 on Intel Core 2 in 32-bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
Steven Bosscher changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315
--- Comment #14 from Andi Kleen 2012-05-12
16:04:27 UTC ---
I can confirm the simple test program works correctly with Jakub's patch.
I'll leave full bootstrap to HJ.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315
--- Comment #15 from Andi Kleen 2012-05-12
16:06:00 UTC ---
Oh yes and it would be really nice to have those peepholes for xbegin Jakub.
I normally use my own macros with asm goto to avoid the ugly code.
Do you think machine reorg could be done
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53332
Bug #: 53332
Summary: #pragma STDC FLOAT_CONST_DECIMAL64 ONdone wrong
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315
--- Comment #16 from Uros Bizjak 2012-05-12 16:31:21
UTC ---
(In reply to comment #13)
> Like this?
Yes, this is OK, after someone confirms that the testcase works as expected on
HW or simulator.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315
--- Comment #17 from Uros Bizjak 2012-05-12 16:36:39
UTC ---
(In reply to comment #15)
> Do you think machine reorg could be done without slowing down the compiler?
Yes, xbegin RTM pattern can raise a flag that triggers machine reorg (so it
won
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
Bug #: 5
Summary: Initializer lists in std=c++03 mode must be an error
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
Paolo Carlini changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #1 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53334
Bug #: 53334
Summary: ICE in extract_insn, at recog.c:2131
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53328
--- Comment #2 from Tobias Burnus 2012-05-12
17:59:36 UTC ---
Extended examples: http://gcc.gnu.org/ml/fortran/2012-05/msg00060.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53334
--- Comment #1 from Bernhard Rosenkränzer 2012-05-12 18:06:12 UTC ---
Created attachment 27388
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27388
Preprocessed source (not yet reduced)
$ /opt/android-toolchain-trunk/bin/arm-linux-androideab
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51294
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|NEW
AssignedTo|paolo.carlini at o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53334
Bernhard Rosenkränzer changed:
What|Removed |Added
Attachment #27388|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #132 from Jan Hubicka 2012-05-12 18:32:14
UTC ---
> > tree VRP: 65.88 ( 2%) usr 0.73 ( 2%) sys 66.71
> >( 2%) wall 862879 kB (24%) ggc
>
> Is it possible to do this again with gathering statistics enabled? The
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51294
--- Comment #10 from Manuel López-Ibáñez 2012-05-12
18:38:33 UTC ---
Latest patch by Paolo, who run out of time:
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00861.html
BTW, I think the patch is not wrong, and if fixes some cases, then it is a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #133 from Jan Hubicka 2012-05-12 19:07:32
UTC ---
Another thing to observe is that GGC memory is "just" 4GB. I am not sure where
the other 8GB goes when our IL is believed
to be major memory consumer and it resists almost completely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #2 from Marc Glisse 2012-05-12 19:46:08
UTC ---
There is -pedantic-errors if you want an error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #134 from Jan Hubicka 2012-05-12
20:22:27 UTC ---
I tracked down the LTO/WHOPR code size difference. It is EH handling. EH frame
is empty for LTO build and quite large for WHOPR. Probably -fno-exceptions
getting lots on way to ltrans
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #4 from Fernando Pelliccioni
2012-05-12 20:59:58 UTC ---
For other features of C++11 don't need -pedantic-errors to emit an error.
See..
#include
void foo( std::string && str ) {}
int main( /* int argc, char* argv[] */ )
{
fo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53292
--- Comment #9 from FH 2012-05-12 21:27:31 UTC ---
Well...
I tested an OpenMP benchmarch (design to demonstrate OpenMP performances) found
on the web : multi-threaded (OpenMP) is again slower than single-threaded. I
looked at coding with pthreads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #135 from Jan Hubicka 2012-05-12
21:33:36 UTC ---
... and mem reports on WPA stage:
toplev.c:964 (realloc_for_line_map) 0: 0.0% 89473168:
9.4% 268435472:10.3%160: 0.0% 8
cgraph.c:359 (cgraph_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263
--- Comment #12 from Paolo Carlini 2012-05-12
21:41:15 UTC ---
Francois, please double check that now you are ok, thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #5 from Marc Glisse 2012-05-12 21:57:05
UTC ---
(In reply to comment #4)
> For other features of C++11 don't need -pedantic-errors to emit an error.
[...]
> It doesn't seem consistent.
> What is the criteria?
Allowing {} is a rather
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53181
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51829
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52767
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53308
Paolo Carlini changed:
What|Removed |Added
CC||dje at gcc dot gnu.org
--- Comment #1 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53055
--- Comment #4 from Marc Glisse 2012-05-12 23:33:16
UTC ---
Created attachment 27390
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27390
patch 1
ice.cc:2:15: error: pointer to member must be on the right side of '->*'
int i = p ->* p ;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #6 from Fernando Pelliccioni
2012-05-12 23:53:30 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > For other features of C++11 don't need -pedantic-errors to emit an error.
> [...]
> > It doesn't seem consistent.
> > Wha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53308
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51829
--- Comment #5 from Seth Heeren 2012-05-13 00:05:00 UTC
---
On 13-05-12 00:46, paolo.carlini at oracle dot com wrote:
> Still waiting.
Really. Well, to be honest, I can't afford to spend even more time
minimizing that any further. I have to pick
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53235
--- Comment #5 from Jason Merrill 2012-05-13
03:37:42 UTC ---
Author: jason
Date: Sun May 13 03:37:38 2012
New Revision: 187435
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187435
Log:
PR debug/53235
* dwarf2out.c (build_local_s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48009
--- Comment #6 from Daniel Richard G. 2012-05-13
05:11:32 UTC ---
(In reply to comment #5)
> AIX 4.3 is extremely old and support was withdrawn a while ago. I am surprised
> that anyone is trying to build recent versions of GCC for it. If someone
64 matches
Mail list logo
