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=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=53175
Tobias Burnus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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=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=53225
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
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=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
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #11 from Jonathan Wakel
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=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=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=53225
Thomas W. Lynch changed:
What|Removed |Added
Status|RESOLVED|WAITING
Resolution|INVALID
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
--- 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=37733
Steven Bosscher changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
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=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=36732
Steven Bosscher changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
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=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=29442
Steven Bosscher changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
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=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=53225
Jonathan Wakely 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=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
--- 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=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 #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 #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 #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=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 #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
--- 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=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=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=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=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 #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=53225
Jonathan Wakely 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=53239
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRMED
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=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=53225
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
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=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 #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
Andrew Pinski changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
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=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=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=53225
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
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
Thomas W. Lynch changed:
What|Removed |Added
Status|RESOLVED|WAITING
Resolution|INVALID
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=48493
Andrew Pinski changed:
What|Removed |Added
Target|arm-eabi|arm-eabi mipsisa64-*-*
Summary
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 Milestone|--- |4.6.4
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=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=53242
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
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
--- 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=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=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 #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=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=53209
Igor Zamyatin changed:
What|Removed |Added
CC||izamyatin at gmail dot com
--- Comment #7
101 - 170 of 170 matches
Mail list logo
