[Bug c++/53930] bug in linker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53930 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Andrew Pinski 2012-07-12 07:13:56 UTC --- You have two different definitions of A::A. Since you have two, only one is going to be picked up which one is depends on the link order in the case of the GNU LD but it could be any random one.
[Bug fortran/53934] New: Better CPP macro diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53934
Bug #: 53934
Summary: Better CPP macro diagnostics
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
Depends on: 44054, 53552
GCC has (now) for the following C program the nice warning:
foo.c:1:23: error: invalid operands to binary << (have ‘int’ and ‘double’)
#define MOVE(a,b) (a << (b))
^
foo.c:4:7: note: in expansion of macro 'MOVE'
i = MOVE(12,2.2);
^
/* -- */
#define MOVE(a,b) (a << (b))
foo(){
int i;
i = MOVE(12,2.2);
}
While for Fortran one just gets:
foo.F90:2.14:
i = lshift(1, 1.1)
1
Error: 'shift' argument of 'lshift' intrinsic at (1) must be INTEGER
which is less helpful.
#define MOVE(a,b) lshift(a,b)
integer :: i
i = MOVE(1, 1.1)
end
Expected: Something similar. Possibly related to PR44054 and PR53552
[Bug c++/53930] bug in linker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53930 Dmitry Bespalov changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #4 from Dmitry Bespalov 2012-07-12 07:59:03 UTC --- Andrew, Yes, I have two different definitions of "A" struct. But they are defined in different cpp files, so actually linker should not have ambiguity, which one to pick up, since the names of these structs for linker should be something like "file1.A" and "file2.A". If this rule is broken, then result should be completely anarchy. Suppose we have 1000 files in the project - there is no guarantee that all the structs defined in cpps have unique names. And rule "which one to puck up is depend on link order" or "it could be any random one" are sounds scary to me.
[Bug target/53935] New: [avr][c++] missing warning for non-const data in progmem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53935
Bug #: 53935
Summary: [avr][c++] missing warning for non-const data in
progmem
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org
CC: eric.wedding...@atmel.com
Target: avr
#define PROGMEM __attribute__((progmem))
const char* PROGMEM arr[] = { "c" };
char foo (void)
{
arr[0] = "x";
}
This C++ mudule puts arr[] in progmem as requested. However, the compiler does
not complain that arr[] needs to be read-only like the C compiler does:
error: variable 'arr' must be const in order to be put into read-only section
by means of '__attribute__((progmem))'
[Bug target/53935] [avr][c++] missing warning for non-const data in progmem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53935 Georg-Johann Lay changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-12 Ever Confirmed|0 |1 Severity|normal |minor
[Bug c/53933] Register choosing error when inline assembly used at inline function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53933 jaewon ha changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #2 from jaewon ha 2012-07-12 08:21:56 UTC --- Reason I removed the clobber list it, when the clip_int32 function become mixed in main function, the register 'r0, r1, r2' is not used. another register according to the register context of main function will be used. and actually, when i turn on the clobber list 'r0, r1, r2', it result in segmentation fault. hope you review this carefully. thanks.
[Bug target/53859] ICE when calculate insn latency for armv7e-m arch in O2 level
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53859 Ramana Radhakrishnan changed: What|Removed |Added CC||ramana at gcc dot gnu.org Target Milestone|--- |4.8.0
[Bug c++/53930] bug in linker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53930 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Severity|critical|normal --- Comment #5 from Jonathan Wakely 2012-07-12 09:51:59 UTC --- (In reply to comment #4) > Yes, I have two different definitions of "A" struct. But they are defined in > different cpp files, so actually linker should not have ambiguity, which one > to > pick up, since the names of these structs for linker should be something like > "file1.A" and "file2.A". Nonsense, that's not how C++ works. If that was the case how would you ever use any type (e.g. std::string) in more than one file, it would be a different type in every file. > If this rule is broken, then result should be completely anarchy. Suppose we > have 1000 files in the project - there is no guarantee that all the structs > defined in cpps have unique names. And rule "which one to puck up is depend on > link order" or "it could be any random one" are sounds scary to me. Sorry you find it scary, but that's how it works. That's why namespaces exist.
[Bug c++/53930] bug in linker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53930 --- Comment #6 from Dmitry Bespalov 2012-07-12 10:03:14 UTC --- It really works as expected if put A into some namespace, but it really as well that implementation differs in Microsoft's VC and GCC. Under VC you always gets right result, there is no dependency on order of cpp placement for linker. I was surprised that GCC-guys have another opinion on that. You were noticed that it's how C++ works. Could you please provide proof-link? Thank you in advance!
[Bug c++/53936] New: Adding a PRETTY_ARGUMENT and ARGUMENT_COUNT macro/variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53936
Bug #: 53936
Summary: Adding a PRETTY_ARGUMENT and ARGUMENT_COUNT
macro/variable
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mail.pou...@laposte.net
Since GCC has a __PRETTY_FUNCTION__ variable, it would be very useful to have a
__PRETTY_ARGUMENT__ variable that would output the example below.
Ideally a __ARGUMENT_COUNT__ macro and a __ARGUMENT__ array would be very
useful indeed, like this pseudo code:
struct A { int c; };
void myFunc(int a, A b)
{
printf("Func: %s\n", __PRETTY_FUNCTION__); // Outputs: "Func: void
myFunc(int, struct A)"
printf("Args: %s\n", __PRETTY_ARGUMENTS__); // Outputs: "Args: int, struct
A"
printf("ArgsCount: %d\n", __ARGUMENT_COUNT__); // Outputs: "ArgsCount: 2"
for (int i = 0; i < __ARGUMENT_COUNT__; i++)
{
printf("Arg[%d]: Type '%s', RelativePos %d\n", __ARGUMENT__[i],
__ARGUMENT__OFFSET__[i]);
} // Outputs: "Arg[0]: Type 'int', RelativePos -4"
// Outputs: "Arg[1]: Type 'struct A', RelativePos -8"
}
The reason for this is that extracting the arguments from the
__PRETTY_FUNCTION__ can be complex (think of function pointers passed as
argument, taking themselves arguments), and the compiler already has this
information.
__ARGUMENT_COUNT__ contains the equivalent of sizeof(argumentList)
__ARGUMENT__ is the equivalent of const char * argumentType[__ARGUMENT_COUNT__]
__ARGUMENT__OFFSET__ is the equivalent of size_t
offsetFromFrameAddressToArgument[__ARGUMENT_COUNT__]
We could then print the argument of a function in an assert for example,
provided we know how to convert from the type "name" and the right printf's
statement, and using the builtin frame address.
What do you think ?
[Bug c++/53930] bug in linker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53930 --- Comment #7 from Jonathan Wakely 2012-07-12 10:09:10 UTC --- ISO 14882:2011 3.2 "There can be more than one definition of a class type (Clause 9), [...] in a program provided that each definition appears in a different translation unit, and provided the definitions satisfy the following requirements. Given such an entity named D defined in more than one translation unit, then — each definition of D shall consist of the same sequence of tokens; [...]" So you can have A defined in two different files, but it must be defined identically, because it refers to the same class.
[Bug c/53937] New: Pack'ing struct causes gcc to not recognize that an field's address is aligned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53937
Bug #: 53937
Summary: Pack'ing struct causes gcc to not recognize that an
field's address is aligned
Classification: Unclassified
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: don.del...@gmail.com
Created attachment 27779
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27779
Example C code
Hello,
When I pack my structure (use #pragma pack(1)), gcc compiler seems to not
recognize that an field in that structure is aligned.
This causes reading of aligned 32-bit fields, as 4 separate bytes. Apart from
this is very not optimal code, this resets my PowerPC. This is because 32-bit
registers can be accessed only as 32-bit words.
Example code:
test.c
#pragma pack(1)
typedef struct BasicStructPacked
{
int field;
}BasicStructPacked;
#pragma pack()
typedef struct BasicStruct
{
int field;
}BasicStruct;
#define ADDRESS(0x1000)
#define STRUCT_REGULAR (*((BasicStruct*)(ADDRESS)))
#define STRUCT_PACKED (*((BasicStructPacked*)(ADDRESS)))
void test_1()
{
STRUCT_PACKED.field = 0;
}
void test_2()
{
STRUCT_REGULAR.field = 0;
}
===
This code generates the following assembler:
test.s
(...)
test_1:
li 9,4096
li 0,0
stb 0,0(9)
stb 0,1(9)
stb 0,2(9)
stb 0,3(9)
blr
(...)
test_2:
li 0,0
li 9,4096
stw 0,0(9)
blr
(...)
===
As you can see access to the aligned 32-bit field is done as 4 reads of one
byte (function test_1) instead of reading of one 32-bit word as it is done in
function test_2.
Used compilation command:
...GCC/powerpc-eabispe/4_6_0/bin/powerpc-eabispe-gcc-4.6.0.exe -mstrict-align
-Wall -Wextra -Os -c -S test.c
Regards, Krzysiek
[Bug c/53937] Pack'ing struct causes gcc to not recognize that an field's address is aligned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53937 --- Comment #1 from Krzysztof Gongolewski 2012-07-12 10:49:57 UTC --- Created attachment 27780 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27780 Compiled example code Assembler
[Bug c++/53930] bug in linker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53930 --- Comment #8 from Dmitry Bespalov 2012-07-12 10:51:51 UTC --- Jonathan, I'm not sure if we're talking about the same thing. You've asked: << If that was the case how would you ever use any type (e.g. std::string) in more << than one file, it would be a different type in every file. std::string is a rigid type defined in , and if I refer it in some cpp I should include the file where this type is defined, right? So I actually do not redefine std::string again, I just the type defined in third file. The my case is another. I define different types in different cpps. Functions from one cpp can't reference types defined in other cpp, right? (note, I do not use "extern" or something else). So struct A defined in file2.cpp should not became an instance in file1.cpp. I'm not a guru in ISO standards, but this particular case is one of basic things that knows everybody. Types defined in one cpp should not appear as instance in another one.
[Bug c++/53930] bug in linker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53930 --- Comment #9 from Dmitry Bespalov 2012-07-12 10:54:31 UTC --- Correction of typo: ...So I actually do not redefine std::string again, I just USE the type defined in third file. Sorry
[Bug target/53938] New: ARM target generates sub-optimal code (extra instructions) on load from memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53938 Bug #: 53938 Summary: ARM target generates sub-optimal code (extra instructions) on load from memory Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: gregpsm...@live.co.uk Created attachment 27781 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27781 Example C source code We are targetting an embedded device and we do a lot of work accessing an FPGA (but this applies just as well to memory access). It has annoyed me for years that the GCC compiler emits unncessary code, wasting memory and cycles when reading 8 and 16-bit values. The attached script shows opportunities to generate better code. when compiled with: gcc -c -O3 -mcpu=arm946e-s codegen.c It compiles to (I have added comments): mov r2, #0xE000 // base address of the device ldrb r1, [r2] // load an unsigned byte, 0 extend ldrb r12, [r2]// load signed byte - WHY NOT ldrsb? and r1, r1, #0xFF// WHAT IS THIS FOR ldrh r3, [r2] // load unsigned short tst r1, #0x80// if (i & 0x80) movne r1, #0 // i = 0 lsl r12, r12, #24// sign extend j (but could be avoided) tst r3, #0x80// if (k & 0x80) ldrh r0, [r2] // load signed short - WHY NOT ldrsh? movne r3, #0 // k = 0 add r1, r1, r12, asr #24 // add sign extended add r3, r1, r3 lsl r0, r0, #16 // sign extend l add r0, r3, r0, asr #16 bx lr There are two issues: 1) There is a completely redundant and r1,r1,#0xff. This does not occur when loading the unsigned short (which is why I have the similar code for loading an unsigned short). 2) There is unneccesary sign extension taking place. ARM has allowed signed loads of 8 and 16-bit values since v4. Spotting this has to be opportunistic as there are offset restrictions. Ideally the code would look like: mov r2, #0xE000 // base address of the device ldrb r1, [r2]// load an unsigned byte, 0 extend ldrsb r12, [r2] // load signed byte ldrh r3, [r2]// load unsigned short tst r1, #0x80 // if (i & 0x80) movne r1, #0 // i = 0 tst r3, #0x80 // if (k & 0x80) ldrsh r0, [r2]// load signed short, extend to 32-bits movne r3, #0 // k = 0 add r1, r1, r12 // add sign extended add r3, r1, r3 add r0, r3, r0 bx lr
[Bug target/53659] ARM: Using -mcpu=cortex-a9 option results in bad performance for Cortex-A9 processor in C-Ray phoronix benchmark
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53659 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-07-12 CC||ramana at gcc dot gnu.org Ever Confirmed|0 |1
[Bug c/53937] Pack'ing struct causes gcc to not recognize that an field's address is aligned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53937 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Richard Guenther 2012-07-12 11:21:23 UTC --- Works as designed. The packed attribute tells GCC that the start of the struct and all members might not be naturally aligned.
[Bug target/53938] ARM target generates sub-optimal code (extra instructions) on load from memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53938 Richard Guenther changed: What|Removed |Added Target||arm*-*-* Status|UNCONFIRMED |WAITING Last reconfirmed||2012-07-12 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2012-07-12 11:27:07 UTC --- Can you verify if the situation improves with GCC 4.7 or current development trunk?
[Bug c++/53930] bug in linker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53930 --- Comment #10 from Richard Guenther 2012-07-12 12:18:11 UTC --- (In reply to comment #9) > Correction of typo: > ...So I actually do not redefine std::string again, I just USE the type > defined > in third file. Preprocessing makes the std::string definition from part of your compilation unit, so you _do_ redefine it.
[Bug c/53937] Pack'ing struct causes gcc to not recognize that an field's address is aligned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53937
--- Comment #3 from Krzysztof Gongolewski
2012-07-12 12:24:42 UTC ---
But the compiler knows address of the struct at compilation time, it's
hard-coded. So gcc knows that both struct and member are perfectly aligned.
If you access only the struct, You can see that compiler uses knowledge that he
knows the exact address, and fact that the structure is aligned and reads
32-bits in one instruction.
To prove it, I compiled two additional functions:
extern BasicStructPacked aa;
void test_3()
{
*((int*)&STRUCT_REGULAR) = 0;
}
void test_4()
{
*((int*)&aa) = 0;
}
And compiler optimized the first function (test_3) as he knew the address and
knew it is aligned. The second function (test_4) was not optimized as compiler
didn't know address at compilation time.
Output of compiler:
(...)
test_3:
li 0,0
li 9,4096
stw 0,0(9)
blr
(...)
test_4:
lis 11,aa@ha
li 0,0
la 9,aa@l(11)
stb 0,aa@l(11)
stb 0,1(9)
stb 0,2(9)
stb 0,3(9)
blr
(...)
[Bug fortran/53939] New: allows assignment to INTENT(IN) nested component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53939 Bug #: 53939 Summary: allows assignment to INTENT(IN) nested component Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bil.k...@nasa.gov I cannot get gfortran to complain when I assign something to an INTENT(IN) variable, viz, $ gfortran --version | head -1 GNU Fortran (GCC) 4.6.2 20111019 (prerelease) $ cat > intent.f90 << EOF module types type elem_type integer:: ncell integer, dimension(:), pointer :: cl2g end type type grid_type integer:: nelem type(elem_type), dimension(:), pointer :: elem end type end module module nested_intents use types, only: grid_type contains subroutine pass_through( grid ) type(grid_type), intent(in) :: grid call intent_inout( grid ) end subroutine subroutine intent_inout( grid ) type(grid_type), intent(in) :: grid ! should produce error: grid changed integer :: i, j do i = 1,grid%nelem do j = 1, grid%elem(i)%ncell grid%elem(i)%cl2g(j) = grid%elem(i)%cl2g(j) + 1 end do end do end subroutine end module EOF % gfortran -c -W -Wall -Wextra -pedantic-errors intent.f90 % The old DEC compiler complains, alpha% % fort -what Compaq Fortran V1.2.0-1882 Compaq Fortran Compiler V1.2.0-1882-48BBF alpha% fort -c intent.f90 f90: Error: intent.f90, line 24: There is an assignment to a dummy symbol with the explicit INTENT(IN) attribute [GRID] grid%elem(i)%cl2g(j) = grid%elem(i)%cl2g(j) + 1 ^
[Bug c/53937] Pack'ing struct causes gcc to not recognize that an field's address is aligned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53937 Richard Guenther changed: What|Removed |Added Keywords||missed-optimization Status|RESOLVED|ASSIGNED Last reconfirmed||2012-07-12 Resolution|INVALID | AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #4 from Richard Guenther 2012-07-12 12:30:17 UTC --- Ok, let me investigate on current trunk. It might be that seeing 'packed' makes us needlessly conservative here.
[Bug fortran/53940] New: warn about duplicate USE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53940 Bug #: 53940 Summary: warn about duplicate USE Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bil.k...@nasa.gov Hi, I'd like to see the GFortran compiler at least give a warning if a USE is duplicated, viz, $ cat > duplicate_use.f90 << EOF module mod integer :: var = 0 end module program duplicate_use use mod, only: var use mod, only: var ! should produce error print*, var end program EOF $ gfortran --version | head -1 GNU Fortran (GCC) 4.6.2 20111019 (prerelease) $ gfortran -W -Wall -Wextra -pedantic-errors duplicate_use.f90 [no complaints] The old DEC Alpha compiler does: alpha% fort -what Compaq Fortran V1.2.0-1882 Compaq Fortran Compiler V1.2.0-1882-48BBF alpha% fort -c duplicate_use.f90 f90: Warning: duplicate_use.f90, line 6: Conflicting attributes or multiple declaration of name. [VAR] use mod, only: var -^ f90: Error: duplicate_use.f90, line 8: The same named entity from different modules and/or program units cannot be referenced. [VAR] print*, var --^ Thanks for consideration, -- Bil
[Bug c/53937] Pack'ing struct causes gcc to not recognize that an field's address is aligned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53937 Krzysztof Gongolewski changed: What|Removed |Added Keywords|missed-optimization | Status|ASSIGNED|RESOLVED Resolution||INVALID --- Comment #5 from Krzysztof Gongolewski 2012-07-12 12:46:31 UTC --- I added __attribute__((aligned(4))) to my packed structure, and this convinced gcc compiler that my struct and also the member IS aligned. All mentioned functions was optimized. For me it is enough workaround, but I think it is bug in gcc, because hard-coded address convince compiler that the struct is aligned but doesn't convince that the member is aligned. And using align attribute convince compiler that both the structure and the member are aligned. In my opinion both options (hard-coding address and adding align attribute) should convince that both struct and member are aligned and result in the same optimized outputs.
[Bug libstdc++/53941] New: "Range-based for" feature is not implemented for std::pair<>.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53941
Bug #: 53941
Summary: "Range-based for" feature is not implemented for
std::pair<>.
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: maxim.yegorush...@gmail.com
gcc-4.7.1 seems to be missing std::begin() and std::end() overloads for
std::pair<> class template as required by
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2930.html
[max@otlonlin050:~/src/test] $ cat test.cc
#include
#include
#include
int main() {
char const arr[] = "abc";
std::pair range(
std::begin(arr)
, std::end(arr)
);
for(char c : range)
std::cout << c << '\n';
}
[max@otlonlin050:~/src/test] $ g++ -v -o test -std=gnu++11 -Wall -Wextra -g
-march=native -fmessage-length=0 test.cc
Using built-in specs.
COLLECT_GCC=/usr/local/ots/gcc/bin/g++47
COLLECT_LTO_WRAPPER=/usr/local/ots/gcc/libexec/gcc/x86_64-unknown-linux-gnu/4.7.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.7.1-src/configure --prefix=/usr/local/ots/gcc
--program-suffix=47 --disable-libunwind-exceptions --with-system-zlib
--enable-__cxa_atexit --enable-checking=release --disable-multilib
--with-gmp-include=/usr/local/ots/gcc/include
--with-mpfr-include=/usr/local/ots/gcc/include
--with-mpc-include=/usr/local/ots/gcc/include
--with-ppl-include=/usr/local/ots/gcc/include
--with-cloog-include=/usr/local/ots/gcc/include
--with-binutils-include=/usr/local/ots/gcc/include
--with-gmp-lib=/usr/local/ots/gcc/lib64
--with-mpfr-lib=/usr/local/ots/gcc/lib64
--with-mpc-lib=/usr/local/ots/gcc/lib64 --with-ppl-lib=/usr/local/ots/gcc/lib64
--with-cloog-lib=/usr/local/ots/gcc/lib64
--with-binutils-lib=/usr/local/ots/gcc/lib64
--enable-languages=c,c++,fortran,lto --enable-plugin --enable-initfini-array
--enable-gold=default
Thread model: posix
gcc version 4.7.1 (GCC)
COLLECT_GCC_OPTIONS='-v' '-o' 'test' '-std=gnu++11' '-Wall' '-Wextra' '-g'
'-march=native' '-fmessage-length=0' '-shared-libgcc'
/usr/local/ots/gcc/libexec/gcc/x86_64-unknown-linux-gnu/4.7.1/cc1plus -quiet
-v -D_GNU_SOURCE test.cc -march=corei7 -mcx16 -msahf -mno-movbe -mno-aes
-mno-pclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi
-mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rdrnd
-mno-f16c -mno-fsgsbase --param l1-cache-size=32 --param l1-cache-line-size=64
--param l2-cache-size=8192 -mtune=corei7 -quiet -dumpbase test.cc -auxbase test
-g -Wall -Wextra -std=gnu++11 -version -fmessage-length=0 -o /tmp/cc3Kix8x.s
GNU C++ (GCC) version 4.7.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.1, GMP version 4.3.2, MPFR version 2.4.2, MPC
version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/local/ots/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/ots/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1
/usr/local/ots/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/x86_64-unknown-linux-gnu
/usr/local/ots/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/backward
/usr/local/ots/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/include
/usr/local/include
/usr/local/ots/gcc/include
/usr/local/ots/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/include-fixed
/usr/include
End of search list.
GNU C++ (GCC) version 4.7.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.1, GMP version 4.3.2, MPFR version 2.4.2, MPC
version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 509ff8363214570b3e6eef60c53bc426
test.cc: In function ‘int main()’:
test.cc:11:18: error: no matching function for call to ‘begin(std::pair&)’
test.cc:11:18: note: candidates are:
In file included from
/usr/local/ots/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/string:53:0,
from
/usr/local/ots/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/locale_classes.h:42,
from
/usr/local/ots/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/ios_base.h:43,
from
/usr/local/ots/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/ios:43,
from
/usr/local/ots/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/ostream:40,
from
/usr/local/ots/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/iterator:64,
from test.cc:2:
/usr/local/ots/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.7.
[Bug c/53937] Pack'ing struct causes gcc to not recognize that an field's address is aligned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53937 Krzysztof Gongolewski changed: What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|INVALID | --- Comment #6 from Krzysztof Gongolewski 2012-07-12 12:50:01 UTC --- Restore of status which I destroyed my last comment.
[Bug c/53937] Pack'ing struct causes gcc to not recognize that an field's address is aligned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53937 Krzysztof Gongolewski changed: What|Removed |Added Keywords||missed-optimization --- Comment #7 from Krzysztof Gongolewski 2012-07-12 12:53:33 UTC --- Restore of destroyed status. Sorry, It is my first submition :)
[Bug fortran/53940] warn about duplicate USE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53940 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus 2012-07-12 13:08:51 UTC --- (In reply to comment #0) > The old DEC Alpha compiler does: [...] > f90: Error: duplicate_use.f90, line 8: The same named entity from different > modules and/or program units cannot be referenced. [VAR] > print*, var > --^ That that one is completely bogus. The standard allows multiple inclusion of the same variable; and your variable is - contrary to the error message - from the same module. For instance, the following is valid: use mod use mod, var2 => var That way one has use-associated the variable "var" under the name "var" and under the name "var2". The Fortran standard (here: Fortran 2008, "11.2.2 The USE statement and use association") has: "More than one USE statement for a given module may appear in a specification part. If one of the USE statements is without an ONLY option, all public entities in the module are accessible. If all the USE statements have ONLY options, only those entities in one or more of the only-lists are accessible. "An accessible entity in the referenced module has one or more local identifiers. [...]" (Cf. http://gcc.gnu.org/wiki/GFortranStandards) Hence, I am inclined to reject the warning proposal. (The request to print an error is simply invalid.) However, if you can give a good argument why you want to have a special warning and when it exactly should be triggered, one could consider it. However, I currently fail to see a real use case for that. Note: module entities which have been explicitly use associated but aren't used are warned for. Thus, one could consider to warn if the same entity under the same name is multiple times use associated. However, that's not only valid but seems to be also harmless and a rather special case.
[Bug fortran/53939] allows assignment to INTENT(IN) nested component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53939 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||burnus at gcc dot gnu.org Resolution||INVALID --- Comment #1 from Tobias Burnus 2012-07-12 13:23:53 UTC --- Congratulation, you found another bug in the Compaq compiler. [Sorry for the slight sarcasm. gfortran like any piece of software has bugs and we are happy if users report them. I also won't rule out that the my first analysis is wrong, but your example seems to be a pretty clear cut case.] You change: grid%elem(i)%cl2g(j) = grid%elem(i)%cl2g(j) + 1 where type(grid_type), intent(in) :: grid However, both "elem" and "cl2g" are pointers - thus the "intent(in)" doesn't apply. [Or more precisely, for "cl2g" the intent doesn't apply at all (as it is underneath a pointer component) while for "elem" it only applies to pointer-association changes: Namely, pointer assignment and allocate/deallocate/nullify of "cl2g" is prohibited due to intent(in), changing its value is allowed.] I think in the normative text of the Fortran standard it is a bit hidden, hence I quote the following nonnormative note from the Fortran 2008 standard: "NOTE 5.16 If a dummy argument is a derived-type object with a pointer component, then the pointer as a pointer is a subobject of the dummy argument, but the target of the pointer is not. Therefore, the restrictions on subobjects of the dummy argument apply to the pointer in contexts where it is used as a pointer, but not in contexts where it is dereferenced to indicate its target. For example, if X is a dummy argument of derived type with an integer pointer component P, and X is INTENT (IN), then the statement X%P => NEW_TARGET is prohibited, but X%P = 0 is allowed (provided that X%P is associated with a definable target)."
[Bug fortran/53940] warn about duplicate USE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53940 --- Comment #2 from Bil Kleb 2012-07-12 13:25:29 UTC --- I guess I see the USE ONLY as similar to a declaration, and to have two of the same declarations in a program is an error, e.g., $ cat duplicate_declaration.f90 << EOF program duplicate_declaration integer :: var integer :: var ! should produce at least a warning? var = 1 print*, var end program EOF % gfortran duplicate_declaration.f90 duplicate_declaration.f90:3.16: integer :: var ! should produce at least a warning? 1 Error: Symbol 'var' at (1) already has basic type of INTEGER While the error is mostly harmless, we find it useful to know about to keep our code clean.
[Bug fortran/53939] allows assignment to INTENT(IN) nested component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53939 --- Comment #2 from Tobias Burnus 2012-07-12 13:29:08 UTC --- (In reply to comment #1) > However, both "elem" and "cl2g" are pointers - thus the "intent(in)" doesn't > apply. [Or more precisely, for "cl2g" the intent doesn't apply at all (as it > is underneath a pointer component) while for "elem" it only applies to > pointer-association changes: Namely, pointer assignment and > allocate/deallocate/nullify of "cl2g" is prohibited due to intent(in), That "cl2g" should have been "elem" - sorry for the typo. > changing its value is allowed.]
[Bug fortran/53939] allows assignment to INTENT(IN) nested component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53939 --- Comment #3 from Bil Kleb 2012-07-12 13:32:07 UTC --- OK, fair enough (and sincere thanks for taking the time to explain it). I see that if I change to the more modern ALLOCATABLE declarations, then I get a warning about assigning to an INTENT(IN). Thanks again, and sorry for the trouble.
[Bug fortran/53940] Optionally warn about multiple explicit USE-association of the same symbol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53940 Tobias Burnus changed: What|Removed |Added Keywords||diagnostic Summary|warn about duplicate USE|Optionally warn about ||multiple explicit ||USE-association of the same ||symbol --- Comment #3 from Tobias Burnus 2012-07-12 13:44:55 UTC --- (In reply to comment #2) > I guess I see the USE ONLY as similar to a declaration, and to have two of the > same declarations in a program is an error, e.g., > $ cat duplicate_declaration.f90 << EOF > program duplicate_declaration > integer :: var > integer :: var Well, here you declare two different variables with the same name. In the original example, you use associate the same variable under the same name. Thus, technically, this example is invalid while the first one is valid. (At least that's how I understand the Fortran standard.) However, I concur that one could warn if the same variable appears multiple times in a "USE ..., ONLY:" either as you had: use mod, only: var use mod, only: var or as in use mod, only: var, var Both are perfectly valid, but I concur that (in well written code) it should not occur. I don't think we want to warn for: use mod use mod, only: var which also (kind of) use-associates "var" multiple times. The warning implementation should be doable somewhere in the depths of module.c as we only set "sym->attr.use_only" for explicitly use-associated symbols.
[Bug libstdc++/53941] "Range-based for" feature is not implemented for std::pair<>.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53941 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Jonathan Wakely 2012-07-12 14:28:32 UTC --- The standard doesn't require them. N3126 removed those functions, as pairs do not make good ranges: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2995.pdf
[Bug libstdc++/53941] "Range-based for" feature is not implemented for std::pair<>.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53941 --- Comment #2 from Maxim Yegorushkin 2012-07-12 14:36:52 UTC --- Fair enough. I wasn't sure whether std::pair<> should work as a range, so I went to http://gcc.gnu.org/gcc-4.7/cxx0x_status.html which refers to http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2930.html, which says that std::pair<> is a range.
[Bug web/53919] Version-specific install instructions not available
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53919 Erik Schnetter changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Comment #8 from Erik Schnetter 2012-07-12 14:43:59 UTC --- I disagree with this assessment that this report is invalid. This is not a complaint that I couldn't find the right instructions, this is a suggestion for improving the web site. Since I mentioned several possibilities, I would appreciate some guidance as to which way you want things to look, and may then even come up with a patch. The instructions on the web speak of "Installing GCC", and do not even mention that they are not version-specific nor for the current release branch. They also do not point to the install instructions in the tarball. This is misleading at best. In particular, the web instructions speak of "old instructions", but refer only to "really old instructions", not to instructions for previous releases. Another issue is that the web instructions refer to released versions when downloading (suggesting that one should install released versions), and at the same time list prerequisites that are not applicable to any released version.
[Bug target/39423] [4.6/4.7/4.8 Regression] [SH] performance regression: lost mov @(disp,Rn)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39423
--- Comment #20 from chrbr at gcc dot gnu.org 2012-07-12 15:36:59 UTC ---
> I'm having a look at your implementation to see how they compare and
> > possibly combined together. Both approaches look interesting.
>
> I guess folding the mul-add sequences like you did should be more useful than
> just
> handling one mem:SI pattern. In any case, if you find my impl useful please
> let me know,
> because then I'd also pop in patterns for mem:QI and mem:HI patterns.
Finally, I think both combine pattern are not exclusive and rather independent,
even if interacting each other due to combine orders.
I like your mem,plus,plus combine that look better than my folding. just there
are 2 little details that I tried while playing with it: there was a
lost of generality with the hardcoding of the shift constant, and I'm not sure
if there was a risk of clobbering a live operands[1]. For those reasons I
modified it a bit as followed.
(define_insn_and_split "*movsi_disp"
[(set (match_operand:SI 0 "arith_reg_dest" "=r")
(mem:SI (plus:SI
(plus:SI (mult:SI (match_operand:SI 1 "arith_reg_operand" "r")
(match_operand:SI 2 "const_int_operand" "i"))
(match_operand:SI 3 "arith_reg_operand" "K06"))
(match_operand:SI 4 "const_int_operand" "i"]
"TARGET_SH1 && satisfies_constraint_K06 (operands[4]) && exact_log2 (INTVAL
(operands[2])) > 0"
{
gcc_unreachable ();
return "#";
}
"&& 1"
[(set (match_dup 1) (ashift:SI (match_dup 1) (match_dup 2)))
(set (match_dup 1) (plus:SI (match_dup 1) (match_dup 3)))
(set (match_dup 0) (mem:SI (plus:SI (match_dup 1) (match_dup 4]
"{
int n = exact_log2 (INTVAL (operands[2]));
rtx res = gen_reg_rtx (SImode);
emit_move_insn (res, operands[1]);
operands[1] = res;
operands[2] = GEN_INT (n);
}"
)
(define_insn "ashlsi3_k"
[(set (match_operand:SI 0 "arith_reg_dest" "=r,r,r")
(ashift:SI (match_operand:SI 1 "arith_reg_operand" "0,0,0")
(match_operand:SI 2 "const_int_operand" "M,P27,r")))]
"TARGET_SH1"
"@
add%0,%0
shll%O2%0
shld%2,%0"
[(set_attr "type" "arith")])
Using those changes, a snipet like
int
foo4 (long long tab[], int index)
{
return (int)tab [index+4];
}
not compiles as:
mov #3,r1
shldr1,r5
add r4,r5
rts
mov.l @(32,r5),r0
2)plus_mulsi
I see some interactions with the movsi_disp pattern, due to different ordering
on the matching in the combiner. I'll need to play more this them activated
together.
So I think you can go ahead with your combiner movsi_disp pattern and propose
to Kaz when ready to close this defect. Feel free to take or not my
suggestions.
I'll then go with my plus_mulsi combiner in a second time, making clear that
it's provide additional optimization opportunities without mixing the impacts.
On a related thread, for further work, I'm thinking on adding support for the
MAC instruction, now that was have the multiply and add. But this requires
exposing the MACLH registers to reload. Had anyone had a thought on this ? I'd
like to give this a try pretty soon.
Cheers
[Bug c/53933] Register choosing error when inline assembly used at inline function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53933 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Andrew Pinski 2012-07-12 16:08:08 UTC --- >Reason I removed the clobber list it, Clobber list is different from the earlier clobber.
[Bug target/53938] ARM target generates sub-optimal code (extra instructions) on load from memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53938 --- Comment #2 from Andrew Pinski 2012-07-12 16:10:09 UTC --- I think this is the standard volatile vs combine issue.
[Bug web/53919] Version-specific install instructions not available
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53919 --- Comment #9 from Andrew Pinski 2012-07-12 16:12:50 UTC --- I think the install instructions for released versions should never be on the website and only in the release itself.
[Bug rtl-optimization/53942] New: unable to find a register to spill in class 'CREG'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53942
Bug #: 53942
Summary: unable to find a register to spill in class 'CREG'
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ncahill_...@yahoo.com
This command:
gcc -O2 -mtune=pentium2 -fno-inline -x c++ -std=gnu++98 -c a.c -o a.o
gives this output:
### output ###
a.c: In function 'unsigned char _ZL1fP2S_h.isra.0(UINT16, UINT16, UINT16,
unsigned char)':
a.c:25:1: error: unable to find a register to spill in class 'CREG'
a.c:25:1: error: this is the insn:
(insn 11 7 12 2 (parallel [
(set (reg:SI 1 dx [85])
(ashiftrt:SI (reg:SI 1 dx [85])
(reg/v:QI 81 [ i ])))
(clobber (reg:CC 17 flags))
]) a.c:20 409 {*ashrsi3_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
a.c:25: confused by earlier errors, bailing out
### end output ###
when compiling this testcase:
### a.c ###
typedef unsigned short UINT16;
typedef unsigned int UINT32;
typedef struct S_ S;
struct S_ {
UINT16 data[3];
UINT32 x;
UINT32 y;
};
static inline S *get_S() {}
static unsigned char f(S *s, unsigned char i)
{
unsigned char c=0;
unsigned char v;
v = s->data[0];
c|=v;
v=((s->data[1])&(1y=f(s,7);
}
### end a.c ###
Using -mtune=i686 works. I'm using gcc 4.7.1, i686-pc-linux-gnu, 32-bit.
Thank you.
Neil.
[Bug objc/53943] New: Compiler ICE with -fobjc-direct-dispatch flag on Linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53943
Bug #: 53943
Summary: Compiler ICE with -fobjc-direct-dispatch flag on Linux
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kostja.osi...@gmail.com
GCC Objective C compiler fails with an ICE when flag -fobjc-direct-dispatch is
set on Linux. I am aware that this flag is for Darwin, however, ICE is never a
good idea. Better to ignore the flag with a warning.
kostja@atlas:~$ cat foo.m
#include
#include
@interface Interface: Object
+ (id) new;
@end
@implementation Interface
+ (id) new
{
return class_createInstance(self, 0);
}
@end
int main()
{
@throw [Interface new];
}
kostja@atlas:~$ gcc -fobjc-direct-dispatch foo.m -lobjc
foo.m: In function ‘main’:
foo.m:14:2: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Preprocessed source stored into /tmp/ccjDs0Y7.out file, please attach this to
your bugreport.
[Bug libobjc/53944] New: Can't catch C++ exception in Objective C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53944
Bug #: 53944
Summary: Can't catch C++ exception in Objective C
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libobjc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kostja.osi...@gmail.com
There is no way with GCC runtime to catch a C++ exception in Objective C code.
The catch-all clause doesn't work.
At some point this limitation was documented, but later removed from the
manual.
Right now the code compiles, but fails to produce expected results.
kostja@atlas:~$ cat bar.cc
extern "C" int bar()
{
throw "exception";
}
kostja@atlas:~$ cat foo.m
#include
extern int bar();
int main()
{
@try {
bar();
} @catch (...) {
printf("caught\n");
} @finally {
printf("finally\n");
}
}
kostja@atlas:~$ g++ -c -fexceptions bar.cc
kostja@atlas:~$ g++ -c -fexceptions -fobjc-exceptions foo.m
kostja@atlas:~$ g++ foo.o bar.o -lobjc
kostja@atlas:~$ ./a.out
terminate called after throwing an instance of 'char const*'
[1]20822 abort (core dumped) ./a.out
[Bug libobjc/53944] Can't catch C++ exception in Objective C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53944 Konstantin Osipov changed: What|Removed |Added Host||Linux atlas ||3.2.0-26-generic #41-Ubuntu ||SMP Thu Jun 14 17:49:24 UTC ||2012 x86_64 x86_64 x86_64 ||GNU/Linux Version|unknown |4.6.3 Severity|normal |major
[Bug libobjc/53944] Can't catch C++ exception in Objective C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53944 --- Comment #1 from Steven Bosscher 2012-07-12 18:23:33 UTC --- Try obj-c++
[Bug debug/37237] Debug information for virtual destructors omits DW_AT_vtable_elem_location
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237 --- Comment #8 from Tom Tromey 2012-07-12 18:34:08 UTC --- I'd like to ping this again. I've been working on adding support for new and delete to gdb. The missing debuginfo here is a barrier to this. I think gdb would generally like to call the deleting destructor when it is available. Right now there is no way to find this destructor from the debuginfo. I agree this would require a DWARF extension. I think something like DW_AT_destructor with values DW_DESTRUCTOR_complete_object, DW_DESTRUCTOR_deleting, and DW_DESTRUCTOR_base_object. I can file a bug on dwarfstd.org if you think this makes sense.
[Bug target/53938] ARM target generates sub-optimal code (extra instructions) on load from memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53938 --- Comment #3 from Greg Smith 2012-07-12 19:09:41 UTC --- (In reply to comment #1) > Can you verify if the situation improves with GCC 4.7 or current development > trunk? I am an end user of the Rowley CrossWorks system and they are not on to 4.7 yet. I am not really set up to conveniently build my own ARM cross compiler (from Windows)... though this is not impossible. However, I see nothing in the 4.7.0 and 4.7.1 release notes to suggest that any changes have been made in this area. I recall seeing this type of code generation for several years...
[Bug fortran/53945] New: Scalar element of assumed-shape dummy array not recognized as C interoperable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53945 Bug #: 53945 Summary: Scalar element of assumed-shape dummy array not recognized as C interoperable Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: towns...@astro.wisc.edu (Reposting from an initial question in comp.lang.fortran): I'm having trouble getting the following to compile with gfortran 4.7.2: --SNIP-- program foo USE ISO_C_BINDING implicit none contains subroutine bar (a) real, intent(in), target :: a(:,:) type(C_PTR) :: a_ptr a_ptr = C_LOC(a(1,1)) end subroutine bar end program foo --SNIP-- The error message is: Error: Assumed-shape array 'a' at (1) cannot be an argument to the procedure 'c_loc' because it is not C interoperable This isn't right; although the array 'a' is not interoperable because it is assumed-shape (but not allocatable), the *element* a(1,1) is a scalar and thus should be interoperable. Looks like the same problem as 50269, in a slightly different context.
[Bug rtl-optimization/53176] [4.8 Regression] gcc.dg/lower-subreg-1.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53176 --- Comment #25 from Hans-Peter Nilsson 2012-07-12 21:14:19 UTC --- Author: hp Date: Thu Jul 12 21:14:14 2012 New Revision: 189441 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189441 Log: PR rtl-optimization/53176 * rtlanal.c (rtx_cost): Adjust default cost for X with a UNITS_PER_WORD factor for all X according to the size of its mode, not just for SUBREGs with untieable modes. Handle SET. Use factor * factor for MULT, DIV, UDIV, MOD, UMOD. Modified: trunk/gcc/ChangeLog trunk/gcc/rtlanal.c
[Bug c/53946] New: gcc emits warning when intmax_t is long long and format string %jd is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53946
Bug #: 53946
Summary: gcc emits warning when intmax_t is long long and
format string %jd is used
Classification: Unclassified
Product: gcc
Version: 4.5.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lxl...@yopmail.com
/* compile with -Wall -Werror */
typedef long long intmax_t;
#include
int main() {
char x = 42;
printf("%jd\n", (intmax_t) x);
return 0;
}
$ gcc t.c -Wall -Werror
cc1: warnings being treated as errors
t.c: In function ‘main’:
t.c:7:2: error: format ‘%jd’ expects type ‘intmax_t’, but argument 2 has type
‘long long int’
[Bug c/53946] gcc emits warning when intmax_t is long long and format string %jd is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53946 --- Comment #1 from Andrew Pinski 2012-07-12 23:43:17 UTC --- Looks like you are using the wrong definition for intmax_t .
[Bug c/53946] gcc emits warning when intmax_t is long long and format string %jd is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53946 --- Comment #2 from Roger Meyer 2012-07-12 23:44:40 UTC --- reproducable at least on: X86_64 using gcc 4.5.1 and 4.5.3
[Bug c/53946] gcc emits warning when intmax_t is long long and format string %jd is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53946 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Andrew Pinski 2012-07-12 23:46:07 UTC --- In fact for x86_64, intmax_t is defined as long rather than long long. Use stdint.h instead of defining your own intmax_t.
[Bug c/53946] gcc emits warning when intmax_t is long long and format string %jd is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53946 Roger Meyer changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #4 from Roger Meyer 2012-07-12 23:46:36 UTC --- @Andrew Pinski: what's wrong with that definition on x86_64 ? this is how musl libc defines it.
[Bug c/53946] gcc emits warning when intmax_t is long long and format string %jd is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53946 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #5 from Andrew Pinski 2012-07-12 23:48:57 UTC --- >this is how musl libc defines it. Then there is a mismatch between musl libc and GCC. GCC and glibc define it to be long on x86_64. Also musl libc is not currently supported as a target for GCC, there are some changes needed to be made to GCC to support it fully.
[Bug c/53946] gcc emits warning when intmax_t is long long and format string %jd is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53946 Roger Meyer changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #6 from Roger Meyer 2012-07-12 23:55:15 UTC --- @Andrew Pinski, shouldn't the compiler just look at the typedef instead of hardcoding assumptions ?
[Bug c/53946] gcc emits warning when intmax_t is long long and format string %jd is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53946 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #7 from Andrew Pinski 2012-07-12 23:56:48 UTC --- No because the assumptions are part of the ABI.
[Bug c++/53845] Another "error reporting routines re-entered" issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53845 davidxl changed: What|Removed |Added CC||xinliangli at gmail dot com --- Comment #2 from davidxl 2012-07-13 00:10:07 UTC --- (In reply to comment #1) > push_tinst_level tries to error out even when called (during diagnostics) by a > deduction_tsubst_fntype which is passed a complain not including tf_error. Similar ICE can also be triggered in many cases with -fdump-tree-all option. The dumper tries to print template parameters which triggers template instantiation (odd). The instantiation may fail for unknown reason causing the ICE. David
[Bug other/51678] 'make pdf' is broken in libiberty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51678 --- Comment #3 from Gavin Lambert 2012-07-13 01:36:52 UTC --- Created attachment 27782 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27782 Proposed fix Confirmed on mingw32 with MiKTeX. I've attached a patch which fixes this; basically TeX didn't like having a heading in the middle of a numbered list (which seems fair enough to me). The patch breaks the numbered list into two sections. This does of course change the numbering of the actual items; possibly someone more familiar with TeX than I can correct this (but the previous numbering seems wrong anyway).
[Bug rtl-optimization/53908] [4.6/4.7 Regression] csa removes needed memory load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53908 --- Comment #10 from Hans-Peter Nilsson 2012-07-13 06:53:30 UTC --- Created attachment 27783 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27783 patch from Richard Sandiford Updated patch, from http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00463.html (which wasn't in patch form).
