http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53209
Igor Zamyatin changed:
What|Removed |Added
CC||izamyatin at gmail dot com
--- Comment #7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53243
Bug #: 53243
Summary: Use vector comparisons for if cascades
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priori
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53242
--- Comment #4 from Rafael 2012-05-05 02:31:22 UTC
---
I did that.
But I never tested the indices because gdb says that the problem is inside
push_back, so I thought it will be a mem leak and went to valgrind.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #43 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53242
--- Comment #3 from Andrew Pinski 2012-05-05
00:54:49 UTC ---
(In reply to comment #2)
> Thanks Andrew,
>
> In fact, the indices are incorrect. I screwed up because I forgot to update
> the
> calculation of the mask.
Next time, please try to d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53242
--- Comment #2 from Rafael 2012-05-05 00:51:43 UTC
---
Thanks Andrew,
In fact, the indices are incorrect. I screwed up because I forgot to update the
calculation of the mask.
Cheers,
Rafael
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #33 from Thomas W. Lynch 2012-05-05
00:48:57 UTC ---
You say accessing type in operator new is illegal by the standard, but the
compiler doesn't give an error though doing so is bloody obvious and I have the
strick checking turned on-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53242
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53242
Bug #: 53242
Summary: Invalid write in push_back
Classification: Unclassified
Product: gcc
Version: 4.4.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27139
glisse at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48493
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |4.6.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #32 from Jonathan Wakely 2012-05-05
00:14:38 UTC ---
(In reply to comment #30)
> Sorry to be thick headed Jon. Perhaps you could boil it down to the essentials
> here, are you saying that assignment is illegal in operator new so it is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48493
Andrew Pinski changed:
What|Removed |Added
Target|arm-eabi|arm-eabi mipsisa64-*-*
Summary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
Thomas W. Lynch changed:
What|Removed |Added
Status|RESOLVED|WAITING
Resolution|INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #30 from Thomas W. Lynch 2012-05-04
23:36:48 UTC ---
Sorry to be thick headed Jon. Perhaps you could boil it down to the essentials
here, are you saying that assignment is illegal in operator new so it is proper
that there be no error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53239
--- Comment #5 from H.J. Lu 2012-05-04 23:20:49
UTC ---
Is there a self-contained run-time testcase?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53241
Bug #: 53241
Summary: Bad pre increment insn for ARM vfp store instructions
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
Thomas W. Lynch changed:
What|Removed |Added
Status|RESOLVED|WAITING
Resolution|INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53240
Andrew Pinski changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #28 from Thomas W. Lynch 2012-05-04
22:31:36 UTC ---
I see that example, I understand it, and I appreciate your writing it.
Though we are going a long way from the original "minor bug".
Had it not been operator new, but another op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53240
--- Comment #2 from felix-gcc at fefe dot de 2012-05-04 22:30:45 UTC ---
I was talking about the second gcc.
Turns out the steps until then broke something.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #27 from Jonathan Wakely 2012-05-04
22:09:10 UTC ---
(In reply to comment #8)
> >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 Ba
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #25 from Daniel Krügler
2012-05-04 22:04:58 UTC ---
(In reply to comment #23)
> You don't even have a B::this_type typedef, how could (this_type*) possibly
> refer to anything except A*? Just by calling it "this_type" doesn't make it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53240
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53239
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
Thomas W. Lynch changed:
What|Removed |Added
Status|RESOLVED|WAITING
Resolution|INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53239
--- Comment #3 from Andrew Pinski 2012-05-04
21:55:04 UTC ---
prephitmp.102_38 = MEM[(struct scm_unused_struct * *)s_6];
D.36424_34 = (long unsigned int) prephitmp.102_38;
D.36423_40 = D.36424_34 & 1;
Is the real place.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53240
Bug #: 53240
Summary: gcc 4.7 cross compiler build fails in libssp; link
test not allowed after GCC_NO_EXECUTABLES
Classification: Unclassified
Product: gcc
Version: 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53239
--- Comment #2 from Andrew Pinski 2012-05-04
21:54:03 UTC ---
s_6 = this_5(D)->children_list_;
x.4_39 = (long unsigned int) s_6;
D.36426_37 = x.4_39 & 6;
I think the code is depending on undefined code dealing with alignment
requirements o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #22 from Jonathan Wakely 2012-05-04
21:51:39 UTC ---
(In reply to comment #19)
> Johnathan, const static members are compile time beasts. There are almost
> macros like #define, but not quite as the compiler will give them storage if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30318
--- Comment #8 from glisse at gcc dot gnu.org 2012-05-04 21:45:49 UTC ---
Created attachment 27311
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27311
Wrap plus/minus
This patch handles combinations of range/anti_range for PLUS_EXPR and
MINU
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53239
--- Comment #1 from proski at gnu dot org 2012-05-04 21:43:11 UTC ---
Created attachment 27310
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27310
Example (made on i386)
This line is miscompiled:
next = min (next, it->pending_moment ());
The
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #21 from Thomas W. Lynch 2012-05-04
21:40:46 UTC ---
So you are not going to say anything about the code in comment 11, which you
say shouldn't work, but does? Due to this, and fact you are now demeaning me,
I request a different set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53239
Bug #: 53239
Summary: [4.7 Regression] -ftree-vrp breaks min()
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #20 from Jonathan Wakely 2012-05-04
21:29:43 UTC ---
(In reply to comment #18)
> This code compiles:
>
> #include
> #include
> typedef unsigned int uint;
>
> class C{ // just here to be faithful to the original code
> int y;
> }
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #19 from Thomas W. Lynch 2012-05-04
21:27:18 UTC ---
Johnathan, const static members are compile time beasts. There are almost
macros like #define, but not quite as the compiler will give them storage if
you take their address. I do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #18 from Thomas W. Lynch 2012-05-04
21:16:18 UTC ---
This code compiles:
#include
#include
typedef unsigned int uint;
class C{ // just here to be faithful to the original code
int y;
};
class A{
public:
typedef A this_type;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #17 from Jonathan Wakely 2012-05-04
21:06:34 UTC ---
Also, see the code I provided at SO:
http://stackoverflow.com/a/10449212/981959
That demonstrates that a base class member function knows nothing about the
derived class.
here's an
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #16 from Jonathan Wakely 2012-05-04
20:58:28 UTC ---
OK, I'm waiting. Please provide some code, as requested, to show exactly what
you're talking about.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238
--- Comment #3 from Jonathan Wakely 2012-05-04
20:57:34 UTC ---
_PTHREADS gets defined immediately above that test:
target_thread_file=`$CXX -v 2>&1 | sed -n 's/^Thread model: //p'`
case $target_thread_file in
posix)
CXXFLAGS="$CXX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
Thomas W. Lynch changed:
What|Removed |Added
Status|RESOLVED|WAITING
Resolution|INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238
--- Comment #2 from Daniel Richard G. 2012-05-04
20:33:46 UTC ---
(In reply to comment #1)
> You'll need to figure out why the configure test passes, most of us who work
> on
> that bit of code don't have access to AIX
Below is the relevant exc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238
--- Comment #1 from Jonathan Wakely 2012-05-04
20:21:32 UTC ---
You'll need to figure out why the configure test passes, most of us who work on
that bit of code don't have access to AIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29442
Steven Bosscher changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #14 from Thomas W. Lynch 2012-05-04
20:18:02 UTC ---
I went through the life time issues in detail in prior comments. The C++ rules
for life time of an instance do not apply to those of the life time of a class.
Or are you saying thes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31603
Steven Bosscher changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36732
Steven Bosscher changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53173
--- Comment #10 from gcc 2012-05-04 20:11:50
UTC ---
I looked into the similar post in boost mailing list
http://lists.boost.org/Archives/boost/2011/07/184266.php and it directed to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49445
The email go
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53238
Bug #: 53238
Summary: Bootstrap failure: error: 'pthread_mutex_timedlock'
was not declared in this scope
Classification: Unclassified
Product: gcc
Version: 4.7.0
Stat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37733
Steven Bosscher changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #13 from Daniel Krügler
2012-05-04 20:09:55 UTC ---
(In reply to comment #11)
> Jonathan, but there is "magical adjustment" as you put it, as the following
> code works correctly:
The difference in your modified example is that the c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29442
--- Comment #13 from Steven Bosscher 2012-05-04
20:04:56 UTC ---
Author: steven
Date: Fri May 4 20:04:47 2012
New Revision: 187181
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187181
Log:
PR other/29442
* read-md.c (fprint_md_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
Thomas W. Lynch changed:
What|Removed |Added
Status|RESOLVED|WAITING
Resolution|INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #11 from Thomas W. Lynch 2012-05-04
19:59:12 UTC ---
Jonathan, but there is "magical adjustment" as you put it, as the following
code works correctly:
#include
#include
typedef unsigned int uint;
class C{ // just here to be faithf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53232
--- Comment #8 from Vincent Lefèvre 2012-05-04
19:58:01 UTC ---
(In reply to comment #6)
> Yes, and in each case some people want it and some don't. I'm pointing out to
> Manu the reasons not everyone wants the warning. Your opinion isn't the o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53226
--- Comment #4 from Mario Baumann 2012-05-04
19:51:24 UTC ---
Correction: -m32 works fine.
1st bi-sect: gcc revision 187054 shows the same problem if compiling with -m64.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52841
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #11 from Jonathan Wakel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53173
--- Comment #9 from Jonathan Wakely 2012-05-04
19:47:09 UTC ---
Bugzilla is not a help forum. Please find somewhere more appropriate to ask
how to solve your problems, such as the boost mailing list or the gcc-help
list.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52841
fabien at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|WAITING
AssignedTo|fab
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53173
gcc changed:
What|Removed |Added
Alias|GCC4.6.3_and_std::a |GCC4.6.3_errors
--- Comment #8 from gcc 2012-05-04
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53173
gcc changed:
What|Removed |Added
Version|4.6.2 |4.6.3
Summary|GCC 4.6.2 errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53175
Tobias Burnus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #9 from Thomas W. Lynch 2012-05-04
19:25:08 UTC ---
I went to take 'this_type' out of the source. You were correct to focus on
that.
As malloc() returns a void * there must be a cast to access the fields in the
instance. We routine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53234
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53237
Bug #: 53237
Summary: Bootstrap fails due to mixed declarations and code
(c-lex.c)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53233
--- Comment #1 from Sean McGovern 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 len)
94 {
95 ve
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=53225
--- Comment #8 from Thomas W. Lynch 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 object is
>a sub-object of anot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53175
--- Comment #3 from Tobias Burnus 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=gcc&view=rev&rev=187175
Log:
2012-05-04 Tobias Burnus
PR fortran/53
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53111
--- Comment #3 from Tobias Burnus 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=gcc&view=rev&rev=187174
Log:
2012-05-04 Tobias Burnus
PR fortran/53
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53220
davidxl changed:
What|Removed |Added
CC||xinliangli at gmail dot com
--- Comment #3 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53228
Uros Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
URL|
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=gcc&view=rev&rev=187172
Log:
Backport from mainline
2012-05-04
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52282
--- Comment #5 from Paolo Carlini 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
remaining issues are more nasty, som
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #7 from Jonathan Wakely 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. and then that parent me
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=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=53225
--- Comment #6 from Thomas W. Lynch 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 doesn't mean anything is co
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=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=gcc&view=rev&rev=187171
Log:
Backport from mainline
2012-05-04 U
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=gcc&view=rev&rev=187169
Log:
Backport from mainline
2012-05-04 U
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53227
--- Comment #4 from Ulrich Weigand 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 to the pseudo, reload is
ha
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=gcc&view=rev&rev=187168
Log:
PR target/53228
* config/i386/i386.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52282
--- Comment #4 from Daniel Krügler
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 compiles and runs successfully under clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53227
--- Comment #3 from Uros Bizjak 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 already expanded in a
split
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 ins
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53128
--- Comment #7 from Manuel López-Ibáñez 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 infer_loop_bounds_from_undefined which make
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53232
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
Severity|minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47659
David Folkner changed:
What|Removed |Added
CC||david.folkner at gmail dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53232
--- Comment #6 from Jonathan Wakely 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,
>
> Only at pro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53227
--- Comment #2 from Ulrich Weigand 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 i+0 S8 A32])) test.i:6 63
{*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53232
--- Comment #5 from Vincent Lefèvre 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 termination (if my interpretatio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53232
--- Comment #4 from Jonathan Wakely 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 this isn't a bug because
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53232
--- Comment #3 from Manuel López-Ibáñez 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 misread the description.
1 - 100 of 170 matches
Mail list logo
