[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48459 --- Comment #13 from Anitha Boyapati 2011-06-13 07:13:41 UTC --- (In reply to comment #12) > function returns true. As a result, dwarf_debug_frame_expr() is always called! Typo - dwarf2out_frame_debug_expr() is always called. Georg: Can you change the state to NEW and raise the severity to blocker? I don't have required privileges.
[Bug libstdc++/49386] New: #undef min/max is dependent on order if #include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49386 Summary: #undef min/max is dependent on order if #include Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: gintensub...@gmail.com testsuite ( bug.cc ) : #include // any C++ header not including #define max( a, b ) bad_macro #include output: In file included from /usr/local/gcc47-20110604/lib/gcc/i686-pc-cygwin/4.7.0/../../../../include/c++/4.7.0/bits/stl_algo.h:62:0, from /usr/local/gcc47-20110604/lib/gcc/i686-pc-cygwin/4.7.0/../../../../include/c++/4.7.0/algorithm:63, from bug.cc:4: /usr/local/gcc47-20110604/lib/gcc/i686-pc-cygwin/4.7.0/../../../../include/c++/4.7.0/bits/algorithmfwd.h:358:41: error: macro "max" passed 3 arguments, but takes just 2 /usr/local/gcc47-20110604/lib/gcc/i686-pc-cygwin/4.7.0/../../../../include/c++/4.7.0/bits/algorithmfwd.h:354:5: error: template declaration of 'const _Tp& std::bad_macro' /usr/local/gcc47-20110604/lib/gcc/i686-pc-cygwin/4.7.0/../../../../include/c++/4.7.0/bits/algorithmfwd.h:358:5: error: template declaration of 'const _Tp& std::max' note: The same error occurs in case of including .
[Bug c++/49387] New: t.cxx:140: error: too many initializers for ‘const __class_type_info_pseudo’
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49387 Summary: t.cxx:140: error: too many initializers for ‘const __class_type_info_pseudo’ Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: mathieu.malate...@gmail.com I am getting this weird compilation error which I am not able to understand what it means: $ g++ t.cxx t.cxx:140: error: too many initializers for ‘const __class_type_info_pseudo’ See attached cxx file.
[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48459 Eric Weddington changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|2011-04-20 00:00:00 |2011.06.13 07:30:05 Ever Confirmed|0 |1 Severity|normal |major --- Comment #14 from Eric Weddington 2011-06-13 07:30:05 UTC --- (In reply to comment #13) > Can you change the state to NEW and raise the severity to blocker? I don't > have > required privileges. I've set state to NEW, but raised the severity to MAJOR. You need to understand that the severity is for the entire GCC project and the AVR target is not even a "secondary" target, even though it might be critical for Atmel.
[Bug libstdc++/49386] #undef min/max is dependent on order if #include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49386 Chris Jefferson changed: What|Removed |Added CC||chris at bubblescope dot ||net --- Comment #1 from Chris Jefferson 2011-06-13 07:55:33 UTC --- max is a term defiend in the standard library. It is undefined behaviour if you #define it to something else when you are using standard library headers. Don't do that :)
[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48459 --- Comment #15 from Anitha Boyapati 2011-06-13 07:55:19 UTC --- (In reply to comment #14) > (In reply to comment #13) > > > Can you change the state to NEW and raise the severity to blocker? I don't > > have > > required privileges. > > I've set state to NEW, but raised the severity to MAJOR. You need to > understand > that the severity is for the entire GCC project and the AVR target is not even > a "secondary" target, even though it might be critical for Atmel. Correction: Not for Atmel and I am definitely not representing it. I am going by the definition given in bug's life cycle. A blocker is described as some bug which blocks development and/or testing work. The current bug does when DWARF2 is enabled. But as you said, if more parameters are to be considered, yes, I need to understand them.
[Bug libstdc++/49386] #undef min/max is dependent on order if #include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49386 --- Comment #2 from Takaya Saito 2011-06-13 08:09:17 UTC --- (In reply to comment #1) > max is a term defiend in the standard library. It is undefined behaviour if > you > #define it to something else when you are using standard library headers. > Don't > do that :) Yes, that's right. But does it.
[Bug libstdc++/49386] #undef min/max is dependent on order if #include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49386 --- Comment #3 from Chris Jefferson 2011-06-13 08:15:39 UTC --- Ah yes. This is unfortunate, and I believe tricky to fix at the gcc end. We could in principle add '#undef min, #undef max', but I worry that might break something else. If you '#define NOMINMAX' before including windows.h, that should stop the declarations, although it can break some windows libraries. The other option is to do: #include #ifdef min #undef min #endif #ifdef max #undef max #endif
[Bug libstdc++/49386] #undef min/max is dependent on order if #include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49386 --- Comment #4 from Takaya Saito 2011-06-13 08:29:15 UTC --- (In reply to comment #3) > Ah yes. This is unfortunate, and I believe tricky to fix at the gcc end. We > could in principle add '#undef min, #undef max', but I worry that might break > something else. > > If you '#define NOMINMAX' before including windows.h, that should stop the > declarations, although it can break some windows libraries. The other option > is > to do: > > #include > #ifdef min > #undef min > #endif > #ifdef max > #undef max > #endif Well, this code: // #include #define max( a, b ) bad_macro #include // OK does not raise errors, because there exist "#undef min" and "#undef max" in file . So I think it should be a bug.
[Bug fortran/49103] [4.6/4.7 Regression] local variables exchange values / wrong code with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49103 --- Comment #13 from Tobias Burnus 2011-06-13 08:41:35 UTC --- (In reply to comment #12) > This untested hack is an attempt to avoid reverting my patch Submitted version of the workaround patch 4.6: http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00480.html
[Bug c++/49388] New: Template class can extend private nested class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49388
Summary: Template class can extend private nested class
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: matthew_ea...@hotmail.com
GCC 4.4.5 will happily compile the following where the templated class extends
a private nested class.
#include
class A {
private:
class B {
protected:
void doSomething() {
std::cout << "Here\n";
}
};
};
template
class C : public A::B {
public:
C() {
this->doSomething();
}
};
int main(void)
{
C c;
}
Access to A::B is private and compilation should fail rather than succeed.
Although I have not personally tried this on a later compiler than 4.4.5, I
have been told that this same bug is present in 4.6.
Note. I originally raised this as a question here
(http://stackoverflow.com/questions/6325291/why-can-i-extend-a-private-nested-class-by-a-template-class)
[Bug c++/49387] t.cxx:140: error: too many initializers for ‘const __class_type_info_pseudo’
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49387 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.06.13 09:07:08 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely 2011-06-13 09:07:08 UTC --- the attachment is missing
[Bug c++/49387] t.cxx:140: error: too many initializers for ‘const __class_type_info_pseudo’
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49387 --- Comment #2 from Mathieu Malaterre 2011-06-13 09:09:15 UTC --- Created attachment 24505 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24505 Test case
[Bug target/48454] gfortran.dg/char_result_13.f90 fails with -O3 -funroll-loops -mvectorize-with-neon-quad
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48454 --- Comment #6 from Ramana Radhakrishnan 2011-06-13 09:09:19 UTC --- Author: ramana Date: Mon Jun 13 09:09:14 2011 New Revision: 174984 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174984 Log: PR target/48454 Fix vmovn lengths. 2011-06-13 Ramana Radhakrishnan PR target/48454 * config/arm/neon.md (vec_pack_trunc): Set the lengths correctly for the case with Quad vectors. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/neon.md
[Bug c++/47346] access control for nested type is ignored in class template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47346 Jonathan Wakely changed: What|Removed |Added CC||matthew_eanor at hotmail ||dot com --- Comment #1 from Jonathan Wakely 2011-06-13 09:10:59 UTC --- *** Bug 49388 has been marked as a duplicate of this bug. ***
[Bug c++/49388] Template class can extend private nested class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49388 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Jonathan Wakely 2011-06-13 09:10:59 UTC --- dup *** This bug has been marked as a duplicate of bug 47346 ***
[Bug libstdc++/49386] #undef min/max is dependent on order if #include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49386 --- Comment #5 from Paolo Carlini 2011-06-13 09:25:33 UTC --- Note that , before anything else, does #include , thus there is something weird going on. If you can spot it, just tell me and let's resolve this stupid M$ thing.
[Bug libstdc++/49386] #undef min/max is dependent on order if #include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49386 --- Comment #6 from Paolo Carlini 2011-06-13 09:29:07 UTC --- Oh yes, the issue of course is that the #undef themselves are inside the include guards of c++config, thus happen only once. We can take them out and "solve" the issue.
[Bug libstdc++/49386] #undef min/max is dependent on order if #include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49386 --- Comment #7 from Paolo Carlini 2011-06-13 09:34:52 UTC --- Created attachment 24506 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24506 Draft patch This is what I mean. It works of course, but in my opinion is even more ugly than what we had already place for this M$ insanity. Before applying I'm going to post it to the mailing list and see if there are no objections.
[Bug libstdc++/49386] #undef min/max is dependent on order if #include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49386 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.06.13 09:43:36 CC||dave.korn.cygwin at gmail ||dot com Ever Confirmed|0 |1 --- Comment #8 from Paolo Carlini 2011-06-13 09:43:36 UTC --- Let's ask Dave's opinion on this. A possibility I can see is doing the dirty undefs only when _WIN32, __MINGW32__ & co are defined.
[Bug c++/49387] t.cxx:140: error: too many initializers for ‘const __class_type_info_pseudo’
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49387 Jonathan Wakely changed: What|Removed |Added Status|WAITING |NEW --- Comment #3 from Jonathan Wakely 2011-06-13 09:45:51 UTC --- I can confirm this ... it's a strange one but in future please provide the information requested: http://gcc.gnu.org/bugs/ You haven't even said what version of the compiler you're using
[Bug c++/49387] t.cxx:140: error: too many initializers for ‘const __class_type_info_pseudo’
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49387 --- Comment #4 from Mathieu Malaterre 2011-06-13 09:49:41 UTC --- Test was done a on a debian/squeeze system: $ g++ --version g++ (Debian 4.4.5-8) 4.4.5 $ apt-cache policy libboost1.42-dev libboost1.42-dev: Installed: 1.42.0-4 Candidate: 1.42.0-4 Version table: 1.42.0-4+b1 0 200 http://ftp.fr.debian.org/debian/ testing/main amd64 Packages 100 http://ftp.fr.debian.org/debian/ unstable/main amd64 Packages *** 1.42.0-4 0 500 http://ftp.fr.debian.org/debian/ squeeze/main amd64 Packages 100 /var/lib/dpkg/status
[Bug libstdc++/49386] #undef min/max is dependent on order if #include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49386 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek 2011-06-13 10:57:46 UTC --- Even better insert it into the c++config.h header on the broken targets. The problem with undefining etc. anything outside of the guards means that for this very often used header suddenly the guards won't be usable by the preprocessor, so it will have to read and parse the header again and again. And the header is quite largish (> 40KB), so it will make a difference.
[Bug c++/49389] New: [C++0x] Wrong value category for pointer-to-member expression with rvalue object expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49389
Summary: [C++0x] Wrong value category for pointer-to-member
expression with rvalue object expression
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
CC: ja...@redhat.com
gcc 4.7.0 20110611 (experimental) in C++0x mode rejects the following program
at the line marked with #:
//
template
T&& val();
struct A {};
typedef decltype(val().*val()) type;
template
struct assert_type;
template<>
struct assert_type {};
assert_type test; // #
//
"error: aggregate 'assert_type test' has incomplete type and cannot be
defined"
Further testing reveals that the deduced type is 'int&' instead of 'int&&'.
According to my reading of 5.5 [expr.mptr.oper] p6:
"The result of a .* expression whose second operand is a pointer to a data
member is of the same value category (3.10) as its first operand."
we have an xvalue expression val() as the first operand, which should result
in an xvalue expression category for the complete pointer-to-member expression.
Referring to 7.1.6.2 [dcl.type.simple] p4, we should fall into bullet 2:
"otherwise, if e is an xvalue, decltype(e) is T&&, where T is the type of e;"
which should have the effect of returning int&&, not int&. Therefore gcc should
accept this program.
[Bug target/49385] Invalid RTL intstruction for ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49385 --- Comment #1 from Mikael Pettersson 2011-06-13 11:20:23 UTC --- I get no ICE on this with 4.7 r174986, even with --enable-checking, and the assembler doesn't complain about the generated code. So what is the problem?
[Bug c++/49380] [4.6/4.7 Regression] Several packages fail to link when building with GCC4.6 (amarok 1.4, FreeCAD)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49380
Richard Guenther changed:
What|Removed |Added
Status|WAITING |NEW
Known to work||4.5.3
Summary|[4.6 Regression] Several|[4.6/4.7 Regression]
|packages fail to link when |Several packages fail to
|building with GCC4.6|link when building with
|(amarok 1.4, FreeCAD) |GCC4.6 (amarok 1.4,
||FreeCAD)
--- Comment #13 from Richard Guenther 2011-06-13
11:24:30 UTC ---
You can obtain preprocessed source by appending -save-temps to the GCC
command-line that builds a file.
Compared to 4.5, 4.6 creates a reference to Bar::foo instead of ::foo for
void foo (int);
namespace Bar {
void bar (int);
};
void Bar::bar(int i)
{
extern void foo (int);
foo (i);
}
Not sure if that is what is expected (thus, wrong in 4.5 and good in 4.6)
or not. It doesn't seem possible to qualify the local extern decl so that
::foo is picked up. Supposedly one should use 'using ::foo' instad of a
local extern declaration.
[Bug rtl-optimization/49390] New: [4.6/4.7 Regression] GCSE miscompilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49390 Summary: [4.6/4.7 Regression] GCSE miscompilation Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org Target: x86_64-linux Created attachment 24507 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24507 rh712480.c The attached testcase is miscompiled, starting with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161534 at -O2, -O2 -fno-gcse fixes it.
[Bug rtl-optimization/49390] [4.6/4.7 Regression] GCSE miscompilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49390 Jakub Jelinek changed: What|Removed |Added Known to work||4.4.6, 4.5.2 Target Milestone|--- |4.6.1 Known to fail||4.6.0, 4.7.0
[Bug target/49385] Invalid RTL intstruction for ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49385 --- Comment #2 from revital.eres at linaro dot org 2011-06-13 11:26:44 UTC --- (In reply to comment #1) > I get no ICE on this with 4.7 r174986, even with --enable-checking, and the > assembler doesn't complain about the generated code. > So what is the problem? The generated code does not produce ICE. However the RTL instruction is not valid as far as I understand so it should not be generated at any stage of the compilation.
[Bug libstdc++/49386] #undef min/max is dependent on order if #include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49386 --- Comment #10 from Paolo Carlini 2011-06-13 11:36:50 UTC --- I agree in principle about the "c++config.h" (aka os_defines.h) header of the broken targets (which would be, I suppose, djgpp and mingw32) and considered using it earlier today, but at the moment it's included inside the guards of c++config itself (and has its own guards). What shall we do about that?
[Bug c++/49387] t.cxx:140: error: too many initializers for ‘const __class_type_info_pseudo’
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49387 --- Comment #5 from Jonathan Wakely 2011-06-13 11:53:52 UTC --- Created attachment 24508 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24508 reduced testcase
[Bug libstdc++/49386] #undef min/max is dependent on order if #include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49386 --- Comment #11 from Paolo Carlini 2011-06-13 11:54:27 UTC --- To be clear: if we want to close this as WONTFIX, I'm not objecting. I'd like only to ear from Dave, though, because I'm not in touch with anybody seriously using GCC on the affected targets.
[Bug c++/49380] [4.6/4.7 Regression] Several packages fail to link when building with GCC4.6 (amarok 1.4, FreeCAD)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49380 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #14 from Jakub Jelinek 2011-06-13 12:06:41 UTC --- http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00305.html http://gcc.gnu.org/viewcvs?view=revision&revision=158074 Thus invalid.
[Bug c++/49380] [4.6/4.7 Regression] Several packages fail to link when building with GCC4.6 (amarok 1.4, FreeCAD)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49380 --- Comment #15 from Ilya Chernykh 2011-06-13 12:17:47 UTC --- I think this is fixed already?
[Bug tree-optimization/49343] [4.7 regression] ICE on field with variable offset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49343 --- Comment #5 from Eric Botcazou 2011-06-13 12:30:02 UTC --- > This is a proposed (fully tested) fix. How do you want me to add a testcase? > Should I just add the test-case attached to this bug to gcc/testsuite/gnat.dg? Yes, you can add it unmodified to the gnat.dg testsuite, thanks in advance.
[Bug rtl-optimization/49390] [4.6/4.7 Regression] GCSE miscompilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49390 --- Comment #1 from Jakub Jelinek 2011-06-13 12:36:58 UTC --- Blindly ignoring MEM_EXPR or other attributes looks very wrong to me. Guess in some cases it could return true even when MEM_ATTRS aren't identical, but they'd need to have the same behavior during alias analysis at least, or one of the attrs would need to be a superset of the other ones (but then it would need to be ensured that the callers pick up the superset instead of the other MEM_ATTRS). On this particular testcase, exp_equiv_p returns 1 for_gcse on MEM_EXPRs c_4(D)->s1+0 and c_1->s1+0 (other attributes are the same). c_1 is: # c_1 = PHI <[rh712480.i : 41:7] [rh712480.i : 41] &e(2), c_4(D)(4), c_4(D)(5)> and e is an automatic variable. If GCSE thinks those two MEMs are equivalent (one, c_4(D) based is present e.g. in the else branch of the if (c == 0) stmt, c_1 based afterwards) and merges those two into the one that has c_4(D)->s1 in it instead of c_1->s1, then aliasing oracle will see c_4(D)->s1 MEM_EXPR and e.s1 MEM_EXPR and will say that they can't alias (while for c_1->s1 and e.s1 they could and do). I think such a change was ok in 4.4 and earlier era, where alias oracle hasn't been used to disambiguate RTL MEMs, but there also it would be NULL -> s1 rather than c_1 -> s1 etc.
[Bug c++/49387] t.cxx:140: error: too many initializers for ‘const __class_type_info_pseudo’
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49387
--- Comment #6 from Jonathan Wakely 2011-06-13
12:39:59 UTC ---
further reduced
#include
struct ResourceMonitorClient { };
template struct ResourcePool : public ResourceMonitorClient {
virtual ~ResourcePool() { }
};
template struct BaseWriter {
BaseWriter() {
typeid(ResourcePool*);
}
virtual void run() {
ResourcePool pool;
}
};
BaseWriter b;
[Bug rtl-optimization/25130] [4.1/4.2 Regression] miscompilation in GCSE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25130 Jakub Jelinek changed: What|Removed |Added Status|RESOLVED|REOPENED CC||jakub at gcc dot gnu.org Resolution|FIXED | Known to fail|| --- Comment #23 from Jakub Jelinek 2011-06-13 12:47:14 UTC --- (In reply to comment #21) > The patch that was committed (especially the cse.c exp_equiv_p part) seems > like > a big hammer, and it does cause missed optimization opportunities. > > Reverting it on gcc-4.1-branch, and instead applying the patch for PR41033, > also gives a compiler that correctly compiles this testcase. > > PR41033 adds a test for flag_strict_aliasing to > nonverlapping_component_refs_p, > which corrects the return value for canon_true_dependence mentioned in comment > #9. > > Steven, are you certain that this patch is necessary in light of this? As PR49390 shows, yes.
[Bug target/49391] New: [arm] sp not accepted as input for alu operation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49391
Summary: [arm] sp not accepted as input for alu operation
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ph...@gnu.org
Target: arm-linux
$ cat t.c
#define THREAD_SIZE8192
static inline struct thread_info *current_thread_info(void)
{
register unsigned long sp asm ("sp");
return (struct thread_info *)(sp & ~(THREAD_SIZE - 1));
}
int f()
{
return (int)current_thread_info();
}
$ arm-linux-gnueabi-gcc -O2 -S t.c
$ cat t.s
.cpu arm10tdmi
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 2
.eabi_attribute 30, 2
.eabi_attribute 18, 4
.file "t.c"
.text
.align 2
.global f
.type f, %function
f:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mov r3, sp
bic r0, r3, #8128
bic r0, r0, #63
bx lr
.size f, .-f
.ident "GCC: (GNU) 4.6.0"
.section.note.GNU-stack,"",%progbits
The "mov r3, sp" is redundant since sp could be used directly as the second
operand to BIC. It wasn't immediately obvious to me from the predicates on
arm_andsi3_insn why combine wouldn't be accepting sp as an input operand to
that pattern, but apparently it isn't.
(This particular idiom of calculating from sp is used quite frequently in the
Linux kernel.)
[Bug driver/49371] xgcc: error: unrecognized option '-pie' on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49371 Iain Sandoe changed: What|Removed |Added Attachment #24501|0 |1 is obsolete|| --- Comment #23 from Iain Sandoe 2011-06-13 12:57:54 UTC --- Created attachment 24509 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24509 v3: corrects a typo and reduces the number of options identified in the compiler warning OK. So this corrects a typo (overides) and also removes '-pie' from the compiler warning (since this is a linker option, it should not be mentioned there). The linker warning does identify pie, fpie and fPIE - since, for compatibility with system tools, we make fpie/PIE imply -pie. The 'engineering' is mostly done; However, what is still needed is adjustment of test-cases, I don't have time to do that this week - but if Dominique would be willing - I'd be happy to test a combined patch on Darwin8/i686-Darwin9.
[Bug tree-optimization/48613] [4.6/4.7 Regression] ICE: vector VEC(ipa_node_params_t,base) index domain error with -O0 -flto -findirect-inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48613 Martin Jambor changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #4 from Martin Jambor 2011-06-13 12:59:09 UTC --- Confirmed. I'll take care of this.
[Bug driver/49371] xgcc: error: unrecognized option '-pie' on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49371 --- Comment #24 from Dominique d'Humieres 2011-06-13 13:12:36 UTC --- > However, what is still needed is adjustment of test-cases ... Which test cases? on x86_64-apple-darwin10 the testsuite passes with only the known failures (for ppc I only tested the tls tests: the full test takes ~20 hours!-).
[Bug driver/49371] xgcc: error: unrecognized option '-pie' on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49371 --- Comment #25 from Iain Sandoe 2011-06-13 13:27:22 UTC --- (In reply to comment #24) > > However, what is still needed is adjustment of test-cases ... > > Which test cases? on x86_64-apple-darwin10 the testsuite passes with only the > known failures (for ppc I only tested the tls tests: the full test takes ~20 > hours!-). I had assumed that the cases noted in comment #15 were test fails - if they were just examples, then we are probably 'there' modulo a re-test on darwin8.
[Bug driver/49371] xgcc: error: unrecognized option '-pie' on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49371 --- Comment #26 from Dominique d'Humieres 2011-06-13 13:46:33 UTC --- (In reply to comment #25) > I had assumed that the cases noted in comment #15 were test fails - if they > were just examples, then we are probably 'there' modulo a re-test on darwin8. They were just extra tests motivated by some doubts you expressed in the thread (BTW on powerpc-apple-darwin9 I get the cc1/f951 warning for both -m32 and -m64).
[Bug rtl-optimization/49390] [4.6/4.7 Regression] GCSE miscompilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49390 --- Comment #2 from Jakub Jelinek 2011-06-13 13:53:23 UTC --- Perhaps we should have some exceptions where we allow different MEM_ATTRS, but they need to be carefully chosen. E.g. if both refs are indirect refs and are similar, with the same points-to info, it would be ok. if (MEM_VOLATILE_P (x) || MEM_VOLATILE_P (y)) return 0; if (MEM_ATTRS (x) != MEM_ATTRS (y) && mem_attrs_equiv_p (x, y)) return 0; where mem_attrs_equiv_p would call ao_ref_from_mem on both x and y, if at least one of them returns false, fail, compare all integer fields for equality (alias sets using ao_ref_base_alias_set/ao_ref_alias_set) and compare base kinds, for indirect we could check for same type and same points-to info (couldn't find a points-to set comparison function, e.g. for pt->vars can just pointer equality be tested or does it need bitmap_equal_p?).
[Bug driver/49371] xgcc: error: unrecognized option '-pie' on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49371 --- Comment #27 from Iain Sandoe 2011-06-13 14:18:58 UTC --- (In reply to comment #26) > (In reply to comment #25) > > I had assumed that the cases noted in comment #15 were test fails - if they > > were just examples, then we are probably 'there' modulo a re-test on > > darwin8. > > They were just extra tests motivated by some doubts you expressed in the > thread OK, my misunderstanding ;-) > (BTW on powerpc-apple-darwin9 I get the cc1/f951 warning for both -m32 and > -m64). that's correct - mdynamic-no-pic is active for m64/powerpc (but not for m64/x86). so .. I'll retest on darwin8 .. and apply to trunk if all is OK there.
[Bug rtl-optimization/49390] [4.6/4.7 Regression] GCSE miscompilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49390 --- Comment #3 from Jakub Jelinek 2011-06-13 14:28:31 UTC --- Perhaps, if the tests are more expensive, case MEM: if (for_gcse) could first do the cheap tests, then if (!exp_equiv_p (XEXP (x, 0), XEXP (y, 0), validate, 1)) return 0; then do the more expensive tests and then just return 1; instead of falling through into the generic code. Case which I agree would be nice to say exp_equiv_p is true is e.g.: if (c->s1 == 0) c++; else foo (1, 0, c->s1, c->s2); foo (2, 0, c->s1, c->s2); Here e.g. c_4(D)->s1 and c_1->s1 aren't equal MEM_EXPRs, but they have the same SSA_VAR_NAME (not sure if we need to check it, perhaps for restrict?), pt->vars and all other pt members are the same too, so I think both MEM_ATTRS should behave the same in the alias oracle.
[Bug target/49392] New: [arm] spurious EABI version mismatches when LTO enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49392
Summary: [arm] spurious EABI version mismatches when LTO
enabled
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ph...@gnu.org
Target: arm-linux
Attempting to build even a trivial executable with -flto yields:
pb@lander:~$ cat t.c
#include
int main() { printf("Hello world"); }
pb@lander:~$ arm-oe-linux-gnueabi-gcc -flto t.c
/home/pb/oe/build-giga/tmp-eglibc/sysroots/x86_64-linux/libexec/armv6-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/4.6.0/arm-oe-linux-gnueabi-ld:
error: Source object /tmp/cc60ozAJ.o.ironly has EABI version 0, but target
a.out has EABI version 5
/home/pb/oe/build-giga/tmp-eglibc/sysroots/x86_64-linux/libexec/armv6-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/4.6.0/arm-oe-linux-gnueabi-ld:
failed to merge target specific data of file /tmp/cc60ozAJ.o.ironly
collect2: ld returned 1 exit status
pb@lander:~$
[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48459 Jason Merrill changed: What|Removed |Added CC|jason at redhat dot com |rth at gcc dot gnu.org --- Comment #16 from Jason Merrill 2011-06-13 14:44:16 UTC --- rth, this was broken by your change, do do you think it ought to work in the new hookified world?
[Bug rtl-optimization/49390] [4.6/4.7 Regression] GCSE miscompilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49390 --- Comment #4 from Jakub Jelinek 2011-06-13 15:35:13 UTC --- Created attachment 24510 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24510 gcc46-pr49390.patch Untested patch. Richard, what do you think about it? Bernd, do you still have some testcases around which got suboptimal code generated before your reversion?
[Bug c/49368] __builtin_constant_p is unable to determine if a union is constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49368 --- Comment #2 from David Meggy 2011-06-13 16:03:01 UTC --- Both those versions are newer than what I'm using. Looks like time to upgrade Thanks for looking into this
[Bug target/43052] Inline memcmp is *much* slower than glibc's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052 Justin Lebar changed: What|Removed |Added CC||justin.lebar+bug at gmail ||dot com --- Comment #8 from Justin Lebar 2011-06-13 18:09:07 UTC --- I just did some tests, and on my machine, glibc's memcmp is faster even when the size of the thing we're comparing is 4 bytes. I can't point to a case that this optimization speeds up on my machine.
[Bug lto/49393] New: [4.7 Regression] LTO testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49393 Summary: [4.7 Regression] LTO testsuite failures Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: hubi...@gcc.gnu.org On Linux/ia32, revision 174993 gave FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto line 12 arg1 == 1 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto line 14 arg1 == 1 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -flto-partition=none line 12 arg1 == 1 FAIL: gcc.dg/guality/pr36728-1.c -O2 -flto -flto-partition=none line 14 arg1 == 1 FAIL: gcc.dg/guality/vla-1.c -O2 -flto line 17 i == 5 FAIL: gcc.dg/guality/vla-1.c -O2 -flto line 17 sizeof (a) == 6 FAIL: gcc.dg/guality/vla-1.c -O2 -flto -flto-partition=none line 17 i == 5 FAIL: gcc.dg/guality/vla-1.c -O2 -flto -flto-partition=none line 17 sizeof (a) == 6 Revision 174989 is OK.
[Bug tree-optimization/49367] missed optimization with __restrict field
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49367
--- Comment #2 from Jason Merrill 2011-06-13
18:11:04 UTC ---
(In reply to comment #1)
> As a1 and a2 are not restrict qualified they may point to the same object
> and thus the "two" restrict pointers are based on each other.
Marking them with restrict doesn't help:
typedef struct A
{
int *__restrict p;
} A;
void g();
void f (A*__restrict a1, A*__restrict a2)
{
*a1->p = 0;
*a2->p = 1;
if (*a1->p != 0)
g();
}
int main()
{
A a,b;
f (&a,&b);
}
Saving the inside pointers into __restrict-qualified temporaries doesn't make
it work, either:
typedef struct A
{
int *__restrict p;
} A;
void g();
void f (A* a1, A* a2)
{
if (a1 == a2)
return;
int *__restrict a1p = a1->p;
int *__restrict a2p = a2->p;
*a1p = 0;
*a2p = 1;
if (*a1p != 0)
g();
}
int main()
{
A a,b;
f (&a,&b);
}
But at this point, if I remove the __restrict from the declaration of p, it
works.
typedef struct A
{
int * p;
} A;
void g();
void f (A* a1, A* a2)
{
if (a1 == a2)
return;
int *__restrict a1p = a1->p;
int *__restrict a2p = a2->p;
*a1p = 0;
*a2p = 1;
if (*a1p != 0)
g();
}
int main()
{
A a,b;
f (&a,&b);
}
It seems rather odd that the __restrict on p would prevent the optimization...
[Bug target/43052] Inline memcmp is *much* slower than glibc's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052 H.J. Lu changed: What|Removed |Added CC|Serge.Pavlov.at.gnu at |sergos.gnu at gmail dot com |gmail dot com | --- Comment #9 from H.J. Lu 2011-06-13 18:14:26 UTC --- The basic string/memory functions in glibc 2.13 or above are super faster in all cases. GCC can't beat glibc if function call overhead is low.
[Bug target/43052] Inline memcmp is *much* slower than glibc's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052 --- Comment #10 from Justin Lebar 2011-06-13 18:18:13 UTC --- Can I force gcc not to use its inlined version?
[Bug lto/49393] [4.7 Regression] LTO testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49393 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from H.J. Lu 2011-06-13 18:29:02 UTC --- I think they are GDB related.
[Bug middle-end/45307] Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45307 Michael Meissner changed: What|Removed |Added CC||meissner at gcc dot gnu.org Severity|normal |blocker
[Bug bootstrap/49383] [4.7 regression] powerpc64-linux bootstrap failure due to ice in cgraph_only_called_directly_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49383 Michael Meissner changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.13 18:36:20 CC||meissner at gcc dot gnu.org Ever Confirmed|0 |1 Severity|normal |blocker
[Bug middle-end/45307] Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45307 Michael Meissner changed: What|Removed |Added Severity|blocker |normal
[Bug middle-end/49394] New: [4.7 Regression] libstdc++-v3/testsuite/30_threads/lock_guard/cons/1.cc FAILs with -fipa-pta -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49394 Summary: [4.7 Regression] libstdc++-v3/testsuite/30_threads/lock_guard/cons/1.cc FAILs with -fipa-pta -fnon-call-exceptions Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz CC: rgue...@gcc.gnu.org Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 24511 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24511 reduced testcase (from libstdc++-v3/testsuite/30_threads/lock_guard/cons/1.cc) Output: $ g++ -O -fipa-pta -fnon-call-exceptions testcase.C $ gdb ./a.out (gdb) r Starting program: /home/smatz/gcc-bug/951/a.out terminate called after throwing an instance of 'int' Program received signal SIGABRT, Aborted. 0x772e1a05 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x772e1a05 in raise () from /lib64/libc.so.6 #1 0x772e308f in abort () from /lib64/libc.so.6 #2 0x77b95fd5 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libstdc++.so.6 #3 0x77b94406 in ?? () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libstdc++.so.6 #4 0x77b94433 in std::terminate() () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libstdc++.so.6 #5 0x77b9451e in __cxa_throw () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libstdc++.so.6 #6 0x004007bf in ~Mutex () at testcase.C:7 #7 main () at testcase.C:36 Tested revisions: r174979 - fail r173150 - OK 4.6.0 - OK
[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48459 Richard Henderson changed: What|Removed |Added Attachment #24478|0 |1 is obsolete|| --- Comment #17 from Richard Henderson 2011-06-13 19:28:33 UTC --- Created attachment 24512 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24512 loosen constraints on register elimination This seems to fix the problem. At least for this small test case. A full build for AVR fails, but that seems to be related to other open bugs.
[Bug target/49349] gfortran.dg/char_result_3.f90 fails with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49349 --- Comment #2 from Steve Ellcey 2011-06-13 19:29:56 UTC --- I tested the patch from comment #1 and it fixed gfortran.dg/char_result_3.f90. I got one regression on IA64 Linux but I can't reproduce it so I think it was just a fluke. There were no regressions on HP-UX.
[Bug debug/49382] -O2 -g: DW_AT_location at the very first PC is already modified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49382 Jakub Jelinek changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #1 from Jakub Jelinek 2011-06-13 19:27:51 UTC --- I'm afraid that without statement frontiers there is nothing that can be done about it, and it is a question whether to call it a bug at all. The side effect (which has been optimized away) just happens so early that there are no real insns left before it. x_2 = x_1(D); # DEBUG x => x_1(D) + 1 clobber (x_2); i = 1; return; simply becomes: # DEBUG x => x_1(D) + 1 clobber (x_1(D)); i = 1; return; Claiming the side effect happens after the call wouldn't be correct, the side effect really happens before the call and the call is the first insn. With statement frontiers you could step through the zero-length insn between start of the function (where x would be live in DW_OP_reg5) to the location before the first call (where x would be already DW_OP_breg5 <1> DW_OP_stack_value).
[Bug debug/49382] -O2 -g: DW_AT_location at the very first PC is already modified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49382 --- Comment #2 from Jakub Jelinek 2011-06-13 19:36:42 UTC --- Alternatively, even before statement frontiers we could special case parameters (PARM_DECLs and vars with PARM_DECL DECL_ABSTRACT_ORIGIN) before the first insn in a function and just emit a zero-length location range for those. So you would get: .LLST0: .quad .LVL1 # Location list begin address (*.LLST0) .quad .LVL1 # Location list end address (*.LLST0) .value 0x1 # Location expression size .byte 0x55# DW_OP_reg5 .quad .LVL1 # Location list begin address (*.LLST0) .quad .LVL2-1 # Location list end address (*.LLST0) .value 0x3 # Location expression size .byte 0x75# DW_OP_breg5 .sleb128 1 .byte 0x9f# DW_OP_stack_value .quad .LVL2-1 # Location list begin address (*.LLST0) .quad .LFE1 # Location list end address (*.LLST0) .value 0x6 # Location expression size .byte 0xf3# DW_OP_GNU_entry_value .uleb128 0x1 .byte 0x55# DW_OP_reg5 .byte 0x23# DW_OP_plus_uconst .uleb128 0x1 .byte 0x9f# DW_OP_stack_value .quad 0 # Location list terminator begin (*.LLST0) .quad 0 # Location list terminator end (*.LLST0) Wonder how many dwarflints etc. would complain about it loudly though.
[Bug debug/49382] -O2 -g: DW_AT_location at the very first PC is already modified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49382 --- Comment #3 from Jan Kratochvil 2011-06-13 19:52:45 UTC --- (In reply to comment #2) > we could special case parameters (PARM_DECLs and vars with PARM_DECL > DECL_ABSTRACT_ORIGIN) before the first insn At least temporarily it would be needed to get the entry values working in more cases. While some dwarflints may complain re-stating it is allowed by DWARF-4: # A location list entry (but not a base address selection or end of list entry) # whose beginning and ending addresses are equal has no effect because the size # of the range covered by such an entry is zero.
[Bug c/49362] Arm Neon intrinsic types not correctly interpreted by compiler.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49362
--- Comment #2 from mark.pupilli at dyson dot com 2011-06-13 19:56:43 UTC ---
The vld2q version should actually be 15 instructions (not 17!) as follows:
vld2.32{d20-d23}, [r0]
vld2.32{d26-d29}, [r1]
veor q12, q11, q14
veor q3, q10, q13
vcnt.8 q8, q3
vcnt.8 q2, q12
vadd.i8q1, q2, q8
vpaddl.u8 q9, q1
vpaddl.u16 q9, q9
vorr d0, d18, d18
vorr d18, d19, d19
vpadd.i32 d16, d18, d0
vpadd.i32 d16, d16, d16
vmov.32r0, d16[0]
bx lr
[Bug libstdc++/49384] istringstream::tellg at the end of string gives a wrong result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49384 --- Comment #2 from Paul Pogonyshev 2011-06-13 20:09:49 UTC --- So, changing in a way incompatible to what the standard says is intended? Or am I (and pre-4.6 libstdc++) misreading the standard?
[Bug c++/49395] New: Non-class prvalues seem to have cv-qualification with GCC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49395
Summary: Non-class prvalues seem to have cv-qualification with
GCC
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hst...@ca.ibm.com
CC: micha...@ca.ibm.com
Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu
C++03 subclause 3.10 [basic.lval] paragraph 9 says that "non-class rvalues
always have cv-unqualified types". When compiling with GCC, some forms of
expressions producing non-class rvalues still act as if they have cv-qualified
type. The test case below is meant to compile clean.
### Self-contained source (a.cpp):
volatile int foo();
struct A { volatile int i; };
typedef volatile int vi;
volatile int i;
const int& ir1 = foo();
const int& ir2 = A().i; // line 8
const int& ir3 = static_cast(i);
const int& ir4 = vi(); // line 10
### Compiler Invocation:
g++-4.6.0 -c a.cpp -o a.o
### Compiler output:
a.cpp:8:22: error: invalid initialization of reference of type 'const int&'
from expression of type 'volatile int'
a.cpp:10:21: error: invalid initialization of reference of type 'const int&'
from expression of type 'vi'
### g++ -v output:
Using built-in specs.
Target: powerpc64-unknown-linux-gnu
Configured with: ./configure --prefix=/data/gcc --program-suffix=-4.6.0
--disable-libssp --disable-libgcj --enable-version-specific-runtime-libs
--with-cpu=default32 --enable-secureplt --with-long-double-128 --enable-shared
--enable-__cxa_atexit --enable-threads=posix --enable-languages=c,c++,fortran
--with-gmp=/usr/local
Thread model: posix
gcc version 4.6.0 (GCC)
[Bug c/49396] New: c-family/c-cppbuiltin.c: duplicate if expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49396
Summary: c-family/c-cppbuiltin.c: duplicate if expressions
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dcb...@hotmail.com
I just ran the static analysis tool cppcheck-1.49 over the source code
of snapshot 20110611 on a Fedora Linux x86_64 box.
The tool said
[gcc/c-family/c-cppbuiltin.c:562] -> [gcc/c-family/c-cppbuiltin.c:557]: (style)
Found duplicate if expressions.
The source code is
if (!prev->x_flag_finite_math_only && cur->x_flag_finite_math_only)
{
cpp_undef (pfile, "__FINITE_MATH_ONLY__");
cpp_define (pfile, "__FINITE_MATH_ONLY__=1");
}
else if (!prev->x_flag_finite_math_only && cur->x_flag_finite_math_only)
I agree with the tool. This looks like a possible cut'n'paste error.
Suggest code rework.
[Bug target/20049] __builtin_ia32_loadsss is still documented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20049 Ian Lance Taylor changed: What|Removed |Added CC||jengelh at medozas dot de --- Comment #7 from Ian Lance Taylor 2011-06-13 21:02:30 UTC --- *** Bug 45718 has been marked as a duplicate of this bug. ***
[Bug inline-asm/45718] unresolved reference to __builtin_ia32_loadaps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45718 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ian at airs dot com Resolution||DUPLICATE --- Comment #1 from Ian Lance Taylor 2011-06-13 21:02:30 UTC --- The documentation is out of date. *** This bug has been marked as a duplicate of bug 20049 ***
[Bug libstdc++/49384] istringstream::tellg at the end of string gives a wrong result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49384 --- Comment #3 from Paolo Carlini 2011-06-13 21:11:57 UTC --- The published C++ Standard has DEFECTS, as any other Standard. With time, defects are analyzed, fixes found (which then become part of the Standard actually in force) and then implemented by the implementors, like GCC.
[Bug ada/48835] Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org --- Comment #9 from Eric Botcazou 2011-06-13 21:16:20 UTC --- > - __gnat_malloc is defined in Ada to return Address (integer, so in d0), but > it's called from a couple of places via fake "extern" declarations that > pretend > it returns void* (pointer, so in a0). The attached patch fixes the two call > sites affected (in Interfaces.C.Strings and build_call_alloc_dealloc), as well > as the internal fake prototype (init_gigi_decls). > - Source code inspection showed that get_jmpbuf_address probably suffers from > the same issue (mismatching decl and use via wrong intermediate fake > prototype) > so I fixed that too. I don't think that we want __gnat_malloc to return anything else than a pointer in the GCC representation. Its DECL node is DECL_IS_MALLOC and had better mimic a canonical malloc as much as possible. Andreas mentioned a compatibility trick in comment #6. How is it implemented?
[Bug fortran/49397] New: ICE with proc pointer assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49397 Summary: ICE with proc pointer assignment Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: ja...@gcc.gnu.org Let's claim the following code is valid. Cf. Intepretation Request J3/11-198 at http://j3-fortran.org/doc/meeting/195/11-198.txt Without the "print *, f()" line, it is rejected with: p => f ! (1) 1 Error: Invalid procedure pointer assignment at (1) But with the line, one gets: test.f90: In function 's': test.f90:2:0: internal compiler error: in build_function_decl, at fortran/trans-decl.c:1778 Program m5 Print *,f() !Call s Contains Subroutine s Procedure(Real),Pointer :: p ! Print *,g() p => f ! (1) ! Print *,p() ! p => g ! (2) ! Print *,p() End Subroutine End Program Function f() f = 1 End Function Function g() g = 2 End Function
[Bug target/49398] New: [4.7 ] bootstrap broken for arm-linux-gnueabi with thumb mode.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49398 Summary: [4.7 ] bootstrap broken for arm-linux-gnueabi with thumb mode. Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: ram...@gcc.gnu.org CC: rearn...@arm.com, ram...@gcc.gnu.org, car...@gcc.gnu.org, michael.h...@linaro.org Created attachment 24513 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24513 Original test case. Originally found by Michael Hope's bootstrap builds . Rev 174940 appears to break bootstrap for --target=arm-linux-gnueabi --with-cpu=cortex-a9 --with-fpu=neon --with-float=softfp --with-mode=thumb. Bootstrap fails during the build of libiberty - from Michaels' logs here. http://builds.linaro.org/toolchain/gcc-4.7~svn174981/logs/armv7l-maverick-cbuild130-ursa4-cortexa9r1/gcc-build.txt Bisecting using a cross-compiler lead me to this revision. The cross-compiler was configured as follows : /home/ramrad01/sources/fsf/trunk/configure --target=arm-linux-gnueabi --with-cpu=cortex-a9 --with-fpu=neon --with-float=softfp --enable-languages=c ramrad01@e102742:/work/cross-build/build-174940/gcc$ !./xgcc ./xgcc -B`pwd` -mthumb -g -O2 ~/Downloads/regex.i -S ../../../gcc-4.7~/libiberty/regex.c: In function ‘xre_search_2’: ../../../gcc-4.7~/libiberty/regex.c:4961:1: internal compiler error: in cselib_record_set, at cselib.c:2224 Please submit a full bug report, with preprocessed source if appropriate. ramrad01@e102742:/work/cross-build/build-174938/gcc$ !./xgcc ./xgcc -B`pwd` -mthumb -g -O2 ~/Downloads/regex.i -S ICE disappears without -g - (So not sure if 174940 is the cause or it just appears to trigger it) . cheers Ramana
[Bug target/49398] [4.7 ] bootstrap broken for arm-linux-gnueabi with thumb mode.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49398 --- Comment #1 from Ramana Radhakrishnan 2011-06-14 00:23:33 UTC --- Created attachment 24514 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24514 Reduced testcase.
[Bug target/49398] [4.7 ] bootstrap broken for arm-linux-gnueabi with thumb mode.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49398
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.06.14 00:37:35
Ever Confirmed|0 |1
--- Comment #2 from Ramana Radhakrishnan 2011-06-14
00:37:35 UTC ---
Hmmm the *ldrd pattern appears to allow this which is just unpredictable
behaviour.
(insn:TI 42 38 43 2 (parallel [
(set (reg/v/f:SI 4 r4 [orig:143 regs ] [143])
(mem/f/c/i:SI (plus:SI (reg/f:SI 26 afp)
(const_int 12 [0xc])) [3 regs+0 S4 A32]))
(set (reg/v:SI 4 r4 [orig:144 stop ] [144])
(mem/c/i:SI (plus:SI (reg/f:SI 26 afp)
(const_int 16 [0x10])) [2 stop+0 S4 A32]))
]) ../../../gcc-4.7~/libiberty/regex.c:4959 396 {*ldrd}
(expr_list:REG_UNUSED (reg/v/f:SI 4 r4 [orig:143 regs ] [143])
(nil)))
You can't have Rt == Rt2 in Thumb2 - that is just broken behaviour.
at the very least you need the following patch to get builds going further.
Index: arm.c
===
--- arm.c(revision 174940)
+++ arm.c(working copy)
@@ -23865,6 +23865,9 @@
if (TARGET_ARM)
max_offset = 255;
+
+ if (regno1 == regno2)
+return false;
if (off1 != NULL_RTX)
offset1 = INTVAL (off1);
