http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51300
Bug #: 51300
Summary: Internal error when using -flto with -O0 in the linker
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51256
--- Comment #1 from Andrew Macleod 2011-11-25
03:00:44 UTC ---
Author: amacleod
Date: Fri Nov 25 03:00:38 2011
New Revision: 181709
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181709
Log:
2011-11-24 Andrew MacLeod
PR c/51256
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51299
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51184
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51299
Bug #: 51299
Summary: [C++11] erroneous nullptr warning on dynamic cast
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51134
H.J. Lu changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51227
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51227
--- Comment #2 from paolo at gcc dot gnu.org
2011-11-25 01:00:51 UTC ---
Author: paolo
Date: Fri Nov 25 01:00:44 2011
New Revision: 181707
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181707
Log:
/cp
2011-11-24 Paolo Carlini
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50797
--- Comment #1 from H.J. Lu 2011-11-25 00:58:51
UTC ---
It is implemented on hjl/x32/addr32 branch at
http://gcc.gnu.org/git/?p=gcc.git;a=summary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297
--- Comment #9 from Eric Botcazou 2011-11-24
23:31:06 UTC ---
> Hm, can you try the attached patch? It avoids passing a null pointer, which
> is
> not permitted. Passing zero as nmemb is permitted (7.20.5 para 1 of c99).
> So
> I'm a littl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51298
Bug #: 51298
Summary: libgomp team_barrier locking failures
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51250
--- Comment #5 from Harald Anlauf 2011-11-24 22:39:10
UTC ---
(In reply to comment #4)
The patch in comment #4 works for me without regressions!
Thanks,
Harald
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50408
--- Comment #4 from Tobias Burnus 2011-11-24
22:20:55 UTC ---
Patch for this issue - note that there are more places which have to be checked
and potentially fixed. The second part is just a performance/algorithmic
optimization, which occurs in r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297
--- Comment #8 from Nathan Sidwell 2011-11-24 22:12:11
UTC ---
On 11/24/11 21:54, ebotcazou at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297
>
> --- Comment #7 from Eric Botcazou 2011-11-24
> 21:54:15 UTC ---
>> d'o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50408
--- Comment #3 from Tobias Burnus 2011-11-24
22:13:06 UTC ---
That a -fwhole-file regression, which became the default in 4.6. The work
around is -fno-whole-file.
The problem is in gfc_get_extern_function_decl:
gfc_find_symbol (sym->name,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51134
--- Comment #13 from hjl at gcc dot gnu.org 2011-11-24
22:11:16 UTC ---
Author: hjl
Date: Thu Nov 24 22:11:12 2011
New Revision: 181701
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181701
Log:
Revert revision 181357.
gcc/
2011-11-24
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43745
--- Comment #5 from Tomasz Francuz 2011-11-24 21:56:17
UTC ---
Ok, here is the code:
class test
{
public:
test() {};
virtual void vfunction();
};
void test::vfunction()
{
}
int main()
{
}
After compilation 6 bytes of SRAM is occupied by
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297
--- Comment #7 from Eric Botcazou 2011-11-24
21:54:15 UTC ---
> d'oh! A fix will be right up.
Thanks. I confirm that adding if (n_names > 0) in the right places works fine.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297
--- Comment #6 from Nathan Sidwell 2011-11-24 21:36:20
UTC ---
On 11/24/11 19:46, ebotcazou at gcc dot gnu.org wrote:
> In fact the array is empty:
>
> (gdb) p n_names
> $1 = 0
> (gdb) p names
> $2 = (name_map_t *) 0x0
d'oh! A fix will be righ
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51218
Tobias Burnus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51218
--- Comment #22 from Tobias Burnus 2011-11-24
20:44:32 UTC ---
Author: burnus
Date: Thu Nov 24 20:44:28 2011
New Revision: 181699
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181699
Log:
2011-11-24 Tobias Burnus
PR fortran/5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #3 from Jonathan Wakely 2011-11-24
20:30:43 UTC ---
What does this program do, compiled with -std=c++11 -pthread ?
#include
#include
#include
#define VERIFY assert
int main()
{
typedef std::mutex mutex_type;
typedef std::uniq
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297
--- Comment #5 from Eric Botcazou 2011-11-24
19:46:20 UTC ---
> the names being entered into the array are unique, so there is a total
> ordering
> -- I think that's a red herring. I think the problem is the string read from
> the data file is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51279
--- Comment #5 from Jack Howarth 2011-11-24
19:32:52 UTC ---
This ICE also can be reproduced at r181697 on x86_64-unknown-linux-gnu (x86_64
Fedora 15).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #2 from Jonathan Wakely 2011-11-24
19:26:23 UTC ---
(In reply to comment #0)
> FAIL: 30_threads/thread/native_handle/typesizes.cc execution test
This one should definitely not run on Tru64, disabling that is pre-approved.
Is -pthrea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51285
--- Comment #4 from Joost VandeVondele
2011-11-24 19:25:06 UTC ---
Simplified testcase showing Tobias patch is unrelated. Is this still triggered
by the same range ?
SUBROUTINE smm_dnn_4_10_10_1_1_2_1(A,B,C)
REAL :: C(4,10), B(10,10),
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297
--- Comment #4 from Nathan Sidwell 2011-11-24
19:08:24 UTC ---
the names being entered into the array are unique, so there is a total ordering
-- I think that's a red herring. I think the problem is the string read from
the data file is corrupte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297
--- Comment #3 from Eric Botcazou 2011-11-24
18:40:43 UTC ---
> What are the values being passed to the bsearch call?
Very likely the problem indeed. qsort is known to be very picky on Solaris 8
and 9, in the sense that the comparer function mu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51294
--- Comment #5 from Jonathan Wakely 2011-11-24
18:37:31 UTC ---
(In reply to comment #4)
> Shouldn't integral conversion rules apply if the types of the second and third
> arguments to a conditional expression differ.
Yes.
> So zero should be c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297
Eric Botcazou changed:
What|Removed |Added
Target|alpha-dec-osf5.1b, |alpha-dec-osf5.1b,
|*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297
--- Comment #1 from Nathan Sidwell 2011-11-24
18:30:40 UTC ---
The line numbers in the backtrace don't seem to correspond to current sources.
for instance line 866 is the definition of find_source, not the location of one
of the two bsearch call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51297
Bug #: 51297
Summary: [4.7 regressions] Many gcov tests FAIL on Tru64 UNIX,
Solaris 8
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51285
--- Comment #3 from Tobias Burnus 2011-11-24
18:07:14 UTC ---
(In reply to comment #2)
> In that range there is the following commit
> http://gcc.gnu.org/viewcvs/trunk/gcc/fortran/trans-decl.c?r1=172307&r2=172604&pathrev=172604
> It could be a co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51218
--- Comment #21 from Tobias Burnus 2011-11-24
17:57:45 UTC ---
Author: burnus
Date: Thu Nov 24 17:57:41 2011
New Revision: 181698
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181698
Log:
2011-11-24 Tobias Burnus
PR fortran/5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
Bug #: 51296
Summary: Several 30_threads tests FAIL on Tru64 UNIX
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priori
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
--- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-24 17:44:03 UTC ---
> This test uses the run-time test to check if .ctors and .init_array
> input sections can be mixed. Separate tests don't make much sense.
Would you care to elab
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51294
--- Comment #4 from Bruce Adams 2011-11-24
17:09:56 UTC ---
Shouldn't integral conversion rules apply if the types of the second and third
arguments to a conditional expression differ.
So zero should be converted from the default int to a char as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49865
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46371
--- Comment #3 from Tobias Burnus 2011-11-24
16:41:54 UTC ---
Polymorphic array example: Todo check for validity and fix.
program p
use m
class(foo), allocatable :: o_bar(:)[:]
integer :: j
allocate(foo :: o_bar(5)[*])
select type(o_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51258
--- Comment #10 from Rainer Orth 2011-11-24 16:34:16
UTC ---
Author: ro
Date: Thu Nov 24 16:34:09 2011
New Revision: 181697
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181697
Log:
Fix several atomic tests on 32-bit x86 (PR testsuite/51
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50885
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51009
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51268
--- Comment #8 from Sebastien Bardeau 2011-11-24
15:58:31 UTC ---
(In reply to comment #7)
> (In reply to comment #6)
>
> > "Within a scoping unit, identifiers of entities in the following classes:
> > (1) ..., abstract interfaces, generic inter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51294
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||diagnostic
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51058
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51248
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50290
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50290
--- Comment #6 from Jakub Jelinek 2011-11-24
15:23:22 UTC ---
Author: jakub
Date: Thu Nov 24 15:23:18 2011
New Revision: 181694
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181694
Log:
PR rtl-optimization/50290
* gcc.dg/pr50290.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51295
Bug #: 51295
Summary: [C++11][noexcept] Wrong c'tor exception-specification
with non-trivial d'tor
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48150
--- Comment #7 from Jakub Jelinek 2011-11-24
14:58:30 UTC ---
Perhaps we could use as value of a$j SIGN_EXTRACT from the provided VALUE,
i.e. when a$j is 12-bit, assume
(debug_insn 14 13 15 2 (var_location:HI a$j (plus:HI (sign_extract:HI (reg/v:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50709
--- Comment #8 from Diego Novillo 2011-11-24
14:51:02 UTC ---
Author: dnovillo
Date: Thu Nov 24 14:50:56 2011
New Revision: 181692
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181692
Log:
Revert
PR bootstrap/50709
* ipa-inl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48150
--- Comment #6 from Jakub Jelinek 2011-11-24
14:44:57 UTC ---
Yeah, can't reproduce -O2/-O3/-Os issues, but can reproduce
FAIL: gcc.dg/guality/sra-1.c -O1 line 43 a.i == 4
FAIL: gcc.dg/guality/sra-1.c -O1 line 43 a.j == 14
with gdb-7.3.50.201
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51162
Sameera changed:
What|Removed |Added
CC||sameera.deshpande at arm
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51293
--- Comment #1 from Tobias Burnus 2011-11-24
14:13:39 UTC ---
This usage requires support for polymorphic arrays - or at least the scalarizer
needs to be able to handle this, which is part of the work Paul did.
Latest publicly available version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51268
--- Comment #7 from Tobias Burnus 2011-11-24
14:04:20 UTC ---
(In reply to comment #6)
> "Within a scoping unit, identifiers of entities in the following classes:
> (1) ..., abstract interfaces, generic interfaces, ...
> are local identifiers in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51292
Tobias Burnus changed:
What|Removed |Added
Keywords||rejects-valid
--- Comment #1 from Tobias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51268
--- Comment #6 from Sebastien Bardeau 2011-11-24
13:23:18 UTC ---
(In reply to comment #5)
> It should be buried in "16 Scope, association, and definition", but I need
> some
> time to extract it.
Ok, so did I. Here is what I can read section
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50290
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50628
--- Comment #12 from Martin Jambor 2011-11-24
12:18:46 UTC ---
Created attachment 25909
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25909
Fix
This is the fix I wrote about yesterday. It bootstraps and tests fine
on x86_64 and we should
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51290
--- Comment #4 from Udo Steinberg 2011-11-24
12:04:58 UTC ---
Confirmed to be fixed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51294
--- Comment #2 from Jonathan Wakely 2011-11-24
12:01:49 UTC ---
(In reply to comment #0)
> 0 is a const so the compiler should be able to choose the correct type.
0 is an int, so the compiler is required by the standard to make the
conditional e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51227
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48665
Paolo Carlini changed:
What|Removed |Added
CC||daniel.kruegler at
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51210
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51294
--- Comment #1 from Bruce Adams 2011-11-24
11:35:24 UTC ---
Probably unncessary but the OS is RHEL5 on a 32bit machine.
brucea@:home/brucea/spurious>lsb_release -a
LSB Version:
:core-4.0-ia32:core-4.0-noarch:graphics-4.0-ia32:graphics-4.0-noa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51294
Bug #: 51294
Summary: spurious warning from -Wconversion in C and C++
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51293
Bug #: 51293
Summary: [OOP] ICE on ANY with overloaded == operator
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Prior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48941
--- Comment #6 from Richard Earnshaw 2011-11-24
11:00:46 UTC ---
(In reply to comment #5)
> How strongly do you object? I think the benefits are
> worth any compatibility drawbacks in this case.
It would be a nice to have, but I'm not going to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51292
Bug #: 51292
Summary: RESULT var with -finit-local-zero -fno-automatic
results in error
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51247
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51290
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51290
--- Comment #2 from paolo at gcc dot gnu.org
2011-11-24 10:20:49 UTC ---
Author: paolo
Date: Thu Nov 24 10:20:43 2011
New Revision: 181690
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181690
Log:
/cp
2011-11-24 Paolo Carlini
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51291
Tobias Burnus changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43491
--- Comment #3 from amker.cheng 2011-11-24
09:24:37 UTC ---
(In reply to comment #1)
>
> I'm thinking that this is perfectly normal thing to do, and that the redundant
> move is meant to disappear in a later pass. My guess is that IRA is choos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51247
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51247
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Target Milesto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50888
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51246
--- Comment #2 from Jakub Jelinek 2011-11-24
08:25:40 UTC ---
Created attachment 25907
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25907
gcc47-pr51246.patch
I wonder whether we can't just adjust the assert here to also allow clobber on
t
79 matches
Mail list logo
