[Bug middle-end/52544] compilation fails with -finstrument-functions and sse c code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52544 Andrew Pinski changed: What|Removed |Added Component|c |middle-end Severity|major |normal
[Bug ada/48835] porting GNAT to m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #52 from Thorsten Glaser 2012-03-10 00:52:32 UTC --- Mikael’s patches work fine for me, gnat-4.6 (4.6.3-1+m68k.2) has just made its way to debian-ports.org unreleased, chances are it’ll become part of the stock unstable sources soon. Full three-stage bootstrap passes (with assorted GCC bugfix backports applied by Mikael’s suggestion of course), although I did not run the testsuite due to lack of time. Thanks to everyone involved!
[Bug middle-end/52548] missed PRE optimization when function call follows to-be hoisted variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52548
Steven Bosscher changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-03-10
CC||steven at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Steven Bosscher 2012-03-10
00:15:12 UTC ---
(In reply to comment #0)
> The bark() function call is in the same basic block as "z = hoist + 4". I
> wild
> guess is that "hoist" isn't anticipatable at the *end* of the BB beginning
> with
> "z = hoist + 4". Splitting BB's at function calls may improve PRE. Just a
> guess...
What is anticipated at the end of BB is uninteresting. It is computed but not
stored (only needed to compute ANTIC_IN, see compute_antic_aux).
You can check the ANTIC sets and AVAIL_OUT set with -fdump-tree-pre-details.
The value for the expression "hoist+4" should be in EXP_GEN of the basic block
with the call, and in AVAIL_OUT of the basic block with "y=hoist+4". But this
isn't the case here:
* the value representative for "y=hoist+4" is y.2_3->"{plus_expr,hoist.1_2,4}"
* the value representative for "z=hoist+4" is y.2_5->"{plus_expr,hoist.1_2,4}"
(the name of the representative is y instead of z, probably due to
copyrename)
* SCCVN finds "Value numbers:(...)y.2_5=y.2_3, as expected
* y.2_3 is in AVAIL_OUT of the then-block, as expected
* {plus_expr,hoist.1_2,4} is in EXP_GEN of the block with the call, as expected
* {plus_expr,hoist.1_2,4} is *not* in ANTIC_IN of the block with the call!
This is strange because ANTIC_IN = ANTIC_OUT U EXP_GEN - TMP_GEN
Function foo() at the .084.pre dump:
foo ()
{
int y.2;
int hoist.1;
int flag.0;
:
flag.0_1 = flag;
if (flag.0_1 != 0)
goto ;
else
goto ;
:
hoist.1_2 = hoist;
y.2_3 = hoist.1_2 + 4;
y = y.2_3;
goto ;
:
flag = 888;
:
hoist.1_4 = hoist;
y.2_5 = hoist.1_4 + 4;
z = y.2_5;
bark ();
return;
}
Value numbers:
hoist.1_4 = hoist.1_2
y.2_5 = y.2_3
All the sets that are computed without iterations:
exp_gen[0] := { } // BB0 is ENTRY_BLOCK
phi_gen[0] := { }
tmp_gen[0] := { }
avail_out[0] := { }
exp_gen[2] := { {mem_ref<0B>,addr_expr<&flag>}@.MEM_7(D) (0002) }
phi_gen[2] := { }
tmp_gen[2] := { flag.0_1 (0002) }
avail_out[2] := { flag.0_1 (0002) }
exp_gen[3] := { {mem_ref<0B>,addr_expr<&hoist>}@.MEM_7(D) (0003),
{plus_expr,hoist.1_2,4} (0004) }
phi_gen[3] := { }
tmp_gen[3] := { hoist.1_2 (0003), y.2_3 (0004) }
avail_out[3] := { flag.0_1 (0002), hoist.1_2 (0003), y.2_3 (0004) }
exp_gen[4] := { }
phi_gen[4] := { }
tmp_gen[4] := { }
avail_out[4] := { flag.0_1 (0002) }
exp_gen[5] := { {mem_ref<0B>,addr_expr<&hoist>}@.MEM_7(D) (0003),
{plus_expr,hoist.1_2,4} (0004) }
phi_gen[5] := { }
tmp_gen[5] := { hoist.1_4 (0003), y.2_5 (0004) }
avail_out[5] := { flag.0_1 (0002), hoist.1_4 (0003), y.2_5 (0004) }
exp_gen[1] := { }
phi_gen[1] := { }
tmp_gen[1] := { }
avail_out[1] := { } // BB1 is EXIT_BLOCK
Starting iteration 0
ANTIC_OUT[5] := { }
ANTIC_IN[5] := { }
S[5] := { }
ANTIC_OUT[4] := { }
ANTIC_IN[4] := { }
S[4] := { }
ANTIC_OUT[3] := { }
ANTIC_IN[3] := { {mem_ref<0B>,addr_expr<&hoist>}@.MEM_7(D) (0003),
{plus_expr,hoist.1_2,4} (0004) }
S[3] := { }
ANTIC_OUT[2] := { }
ANTIC_IN[2] := { {mem_ref<0B>,addr_expr<&flag>}@.MEM_7(D) (0002) }
S[2] := { }
Starting iteration 1
ANTIC_OUT[3] := { }
ANTIC_IN[3] := { {mem_ref<0B>,addr_expr<&hoist>}@.MEM_7(D) (0003),
{plus_expr,hoist.1_2,4} (0004) }
S[3] := { }
ANTIC_OUT[2] := { }
ANTIC_IN[2] := { {mem_ref<0B>,addr_expr<&flag>}@.MEM_7(D) (0002) }
S[2] := { }
[Bug libstdc++/51785] gets not anymore declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785 --- Comment #27 from Paolo Carlini 2012-03-09 23:48:17 UTC --- Thanks a lot Joseph, a very good solution.
[Bug c/52546] -fstack-usage not working with __attribute__((naked))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52546 --- Comment #2 from Marek Vasut 2012-03-09 22:53:04 UTC --- (In reply to comment #1) > > Is there any way to tell the compiler how much stack does a naked function > > consume (or that it consumes zero stack)? Is this a GCC bug? > > It's a limitation. We could indeed do better, but if you know how much stack > space the function uses, what's the point in asking the compiler? :-) Ok, that's understandable and it's a really good function. It'd be certainly favorable to avoid using such feature (specify how much the function uses), but exactly for cases like this, it'd be very helpful to have. I'm no GC hacker myself so I have no idea how much work it'd be to write such a thing and if it'd be acceptable at all. Thanks for your quick reply!
[Bug libstdc++/51785] gets not anymore declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785 --- Comment #26 from Joseph S. Myers 2012-03-09 22:13:49 UTC --- The __USE_GNU conditional has now been removed from glibc after further discussion on libc-alpha, so the libstdc++ changes can be reverted (probably after 4.7.0).
[Bug c/52547] Internal compiler Error in create_tmp_var in gimplify.c:465
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52547 --- Comment #1 from Rohit Banga 2012-03-09 21:59:25 UTC --- Removing -fopenmp resolves the problem. That piece of information should be helpful in solving the bug.
[Bug c/52546] -fstack-usage not working with __attribute__((naked))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52546 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-09 CC||ebotcazou at gcc dot ||gnu.org Ever Confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Eric Botcazou 2012-03-09 21:48:46 UTC --- > Is there any way to tell the compiler how much stack does a naked function > consume (or that it consumes zero stack)? Is this a GCC bug? It's a limitation. We could indeed do better, but if you know how much stack space the function uses, what's the point in asking the compiler? :-)
[Bug other/52545] output.h: SECTION_EXCLUDE flag clobbers SECTION_MACH_DEP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52545 --- Comment #5 from Sriraman Tallam 2012-03-09 21:30:54 UTC --- On Fri, Mar 9, 2012 at 12:27 PM, gjl at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52545 > > --- Comment #4 from Georg-Johann Lay 2012-03-09 > 20:27:42 UTC --- > (In reply to comment #3) >> Right, I was not looking at SECTION_MACH_DEP when I defined the macro. Is it >> ok >> to just bump SECTION_MACH_DEP? >> >> The patch I have in mind is: >> >> -#define SECTION_MACH_DEP 0x200 /* subsequent bits reserved for target */ >> -#define SECTION_EXCLUDE 0x400 >> +#define SECTION_EXCLUDE 0x200 >> +#define SECTION_MACH_DEP 0x800 /* subsequent bits reserved for target */ >> >> I can bump SECTION_MACH_DEP even more to reserve more bits. > > The reserved bits start at SECTION_MACH_DEP, with the patch above you just > waste the bit at 0x400. I thought I will leave some bits for future flags but I guess whoever adds a flag can also bump SECTION_MACH_DEP. I will send a patch to fix this. Thanks, -Sri. > > Any bits covered by > SECTION_MACH_DEP * (~0) > are reserved for the machine. The bigger SECTION_MACH_DEP is, the less bits > are > left for machine specific needs. > > Machine specific section flag masks could be, e.g.: > > #define SECTION_FLAG_MACH_1 (SECTION_MACH_DEP) > #define SECTION_FLAG_MACH_2 (SECTION_MACH_DEP << 1) > #define SECTION_FLAG_MACH_3 (SECTION_MACH_DEP << 2) > ... > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are on the CC list for the bug.
[Bug c++/52521] [C++11] user defined literals and order of declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52521
--- Comment #4 from Jakub Jelinek 2012-03-09
21:21:15 UTC ---
Created attachment 26869
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26869
gcc48-pr52521.patch
If ignoring possibility of parameters with default arguments, I guess the fix
could look like this. If operator"" could have default arguments, it would
complicate things a little bit.
[over.literal]/3 lists what argument types are allowed, so IMHO it isn't
possible to have say
int operator"" _w (long double, long double = 2.0L);, but what if there is
say
int operator"" _w (const char *, std::size_t = 0);
? Can it be called for int i = 123_w; ? Though, [over.literal]/4 says that
a raw literal operator contains a single const char * argument and
[lex.ext]/{3,4} says that a raw literal operator is called for integer/floating
udlits, so perhaps it shouldn't call int operator"" _w (const char *,
std::size_t = 0); and the attached patch is sufficient.
Jason, what do you think?
[Bug middle-end/52548] New: missed PRE optimization when function call follows to-be hoisted variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52548
Bug #: 52548
Summary: missed PRE optimization when function call follows
to-be hoisted variable
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: al...@gcc.gnu.org
For the following code (for -O2):
int flag, hoist, y, z;
void
foo (void)
{
if (flag)
y = hoist + 4;
else
flag = 888;
z = hoist + 4;
bark ();
}
...PRE should be moving "hoist + 4" to the else arm, but it fails to do so.
If you remove the call to bark(), [hoist + 4] gets moved appropriately.
The bark() function call is in the same basic block as "z = hoist + 4". I wild
guess is that "hoist" isn't anticipatable at the *end* of the BB beginning with
"z = hoist + 4". Splitting BB's at function calls may improve PRE. Just a
guess...
[Bug c/52547] New: Internal compiler Error in create_tmp_var in gimplify.c:465
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52547 Bug #: 52547 Summary: Internal compiler Error in create_tmp_var in gimplify.c:465 Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: iamrohitba...@gmail.com Created attachment 26868 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26868 Preprocessed Source I get the following error when trying to compile a piece of software. Commenting out the call to qsort in the original source file (the corresponding line number in the attached preprocessed file is 7176) does not produce any error. gcc -std=gnu9x -fopenmp -g -O2 -Iinclude -o main main.c src/stinger.c src/stinger-utils.c src/timer.c src/xmalloc.c \ -lm -lrt src/stinger-utils.c: In function ‘stinger_to_sorted_csr’: src/stinger-utils.c:450:13: internal compiler error: in create_tmp_var, at gimplify.c:465 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Preprocessed source stored into /tmp/ccAzPZP8.out file, please attach this to your bugreport. make: *** [main] Error 1
[Bug libitm/52482] libitm INVALID MNEMONIC in .S (powerpc asm)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52482 --- Comment #4 from David Fang 2012-03-09 20:44:14 UTC --- Also, from my testing, it looks like AS=odas is needed; if I just pass AS_FOR_TARGET=odas, then the wrong assembler is used and sjlj.S fails.
[Bug c/52546] New: -fstack-usage not working with __attribute__((naked))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52546
Bug #: 52546
Summary: -fstack-usage not working with __attribute__((naked))
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marek.va...@gmail.com
Dear GCC hackers,
I get the following output while compiling my code (isolated snippet follows):
spl_mem_init.c: In function 'data_abort_memdetect_handler':
spl_mem_init.c:180:1: warning: -fstack-usage not supported for this target
[enabled by default]
Culprit:
void data_abort_memdetect_handler(void) __attribute__((naked));
void data_abort_memdetect_handler(void)
{
asm volatile("subs pc, r14, #4");
}
gcc --version
arm-linux-gnueabi-gcc (Debian 4.6.2-14) 4.6.2
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Though this is observed also with stock GCC 4.6.
Is there any way to tell the compiler how much stack does a naked function
consume (or that it consumes zero stack)? Is this a GCC bug?
Thanks in advance!
[Bug other/52545] output.h: SECTION_EXCLUDE flag clobbers SECTION_MACH_DEP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52545 --- Comment #4 from Georg-Johann Lay 2012-03-09 20:27:42 UTC --- (In reply to comment #3) > Right, I was not looking at SECTION_MACH_DEP when I defined the macro. Is it > ok > to just bump SECTION_MACH_DEP? > > The patch I have in mind is: > > -#define SECTION_MACH_DEP 0x200 /* subsequent bits reserved for target */ > -#define SECTION_EXCLUDE 0x400 > +#define SECTION_EXCLUDE 0x200 > +#define SECTION_MACH_DEP 0x800 /* subsequent bits reserved for target */ > > I can bump SECTION_MACH_DEP even more to reserve more bits. The reserved bits start at SECTION_MACH_DEP, with the patch above you just waste the bit at 0x400. Any bits covered by SECTION_MACH_DEP * (~0) are reserved for the machine. The bigger SECTION_MACH_DEP is, the less bits are left for machine specific needs. Machine specific section flag masks could be, e.g.: #define SECTION_FLAG_MACH_1 (SECTION_MACH_DEP) #define SECTION_FLAG_MACH_2 (SECTION_MACH_DEP << 1) #define SECTION_FLAG_MACH_3 (SECTION_MACH_DEP << 2) ...
[Bug other/52545] output.h: SECTION_EXCLUDE flag clobbers SECTION_MACH_DEP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52545 --- Comment #3 from Sriraman Tallam 2012-03-09 19:36:21 UTC --- Right, I was not looking at SECTION_MACH_DEP when I defined the macro. Is it ok to just bump SECTION_MACH_DEP? The patch I have in mind is: -#define SECTION_MACH_DEP 0x200 /* subsequent bits reserved for target */ -#define SECTION_EXCLUDE 0x400 +#define SECTION_EXCLUDE 0x200 +#define SECTION_MACH_DEP 0x800 /* subsequent bits reserved for target */ I can bump SECTION_MACH_DEP even more to reserve more bits. -Sri.
[Bug other/52545] output.h: SECTION_EXCLUDE flag clobbers SECTION_MACH_DEP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52545 --- Comment #2 from Georg-Johann Lay 2012-03-09 19:21:09 UTC --- ...and here is the change: http://gcc.gnu.org/viewcvs?view=revision&revision=179288
[Bug other/52545] output.h: SECTION_EXCLUDE flag clobbers SECTION_MACH_DEP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52545 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-09 CC||tmsriram at google dot com Target Milestone|--- |4.7.1 Ever Confirmed|0 |1 --- Comment #1 from Georg-Johann Lay 2012-03-09 19:17:52 UTC --- FYI, this is the wrong line: #define SECTION_EXCLUDE 0x400
[Bug other/52545] New: output.h: SECTION_EXCLUDE flag clobbers SECTION_MACH_DEP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52545 Bug #: 52545 Summary: output.h: SECTION_EXCLUDE flag clobbers SECTION_MACH_DEP Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@gcc.gnu.org All section flags from SECTION_MACH_DEP on are reserved for target specific purposes and must not be allocated/used by any other flags like SECTION_EXCLUDE. Otherwise, setting a machine specific section flag might lead to unintentionally mark a section as SECTION_EXCLUDE. This bug is explicit for the AVR target that uses these flags (4 bits) to encode target specific address spaces. The output.h source comment reads: #define SECTION_MACH_DEP 0x200/* subsequent bits reserved for target */
[Bug libstdc++/52456] FAIL: libstdc++-abi/abi_check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52456 --- Comment #7 from Benjamin Kosnik 2012-03-09 18:46:52 UTC --- Hey all. Undesignated are optionally-added symbols (like tls) that are configure or platform dependant and so are not set into the baselines. This is new. They are not FAIL. It's the incompatible symbols that are making this FAIL. As of the fix for 52191, abi_check assumes that baseline_symbols.txt file is current as per the last release. For the 4.7.0 release, this means: Current in 4.7.0: GLIBCXX_3.4.17, CXXABI_1.3.6, CXXABI_TM_1 It seems as if HPPA-linux baselines are in no way current. Looking back at the repository, the last time this file was updated for hppa was jan 2009. (gcc-4.3/4.4 ish) >From your diff, hppa-linux is adding into: +OBJECT:0:CXXABI_1.3.3 +OBJECT:0:CXXABI_1.3.4 +OBJECT:0:CXXABI_1.3.5 +OBJECT:0:CXXABI_1.3.6 GLIBCXX_3.4.11 GLIBCXX_3.4.12 GLIBCXX_3.4.13 GLIBCXX_3.4.14 GLIBCXX_3.4.15 GLIBCXX_3.4.16 GLIBCXX_3.4.17 Which is every release post 4.3.x, starting with 4.4. So, this could make sense. None of the symbol additions for hppa-linux diverge from x86-linux in name or version, so this seems ok to me if you just want to update the hppa-linux baselines to 4.7.0 exports. Once you update the trunk hppa baselines, abi_check will stop failing.
[Bug target/52530] [4.8 regression] Many 64-bit execution failures on Solaris 10/11 with Sun as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52530
--- Comment #9 from uros at gcc dot gnu.org 2012-03-09 18:01:56 UTC ---
Author: uros
Date: Fri Mar 9 18:01:47 2012
New Revision: 185148
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185148
Log:
PR target/52530
* config/i386/i386.c (ix86_print_operand): Handle 'E' operand modifier.
(ix86_print_operand_address): Handle UNSPEC_LEA_ADDR. Do not fallback
to set code to 'q'.
* config/i386/i386.md (UNSPEC_LEA_ADDR): New unspec.
(*movdi_internal_rex64): Use %E operand modifier for lea.
(*movsi_internal): Ditto.
(*lea_1): Ditto.
(*lea_2): Ditto.
(*lea_{3,4,5,6}_zext): Ditto.
(*tls_global_dynamic_32_gnu): Ditto.
(*tls_global_dynamic_64): Ditto.
(*tls_dynamic_gnu2_lea_32): Ditto.
(*tls_dynamic_gnu2_lea_64): Ditto.
(pro_epilogue_adjust_stack__add): Ditto.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.md
[Bug tree-optimization/52267] a&~N where N has all the bits set up till a specific point can be folded to ((unsigned)a) < N
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52267 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #3 from Jakub Jelinek 2012-03-09 17:52:47 UTC --- Created attachment 26867 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26867 gcc48-pr52267.patch Unfinished, WIP, patch. Will continue working on this next week. On top of the two VRP patches I've posted today to gcc-patches.
[Bug c/52544] New: compilation fails with -finstrument-functions and sse c code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52544
Bug #: 52544
Summary: compilation fails with -finstrument-functions and sse
c code
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jgpiccin...@free.fr
Created attachment 26866
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26866
the src code that reproduce the issue.
Hi,
I'd like to report an issue with gcc versions >= 4.6.x :
when compiling my sse.c code with "gcc -Wall -Wextra -fno-strict-aliasing
-fwrapv sse.c",
all versions of gcc (434, 453, 462, 463, 47 and 480) create a correct
executable,
that will give the correct output at runtime :
* x = [1.25 1.25 1.25 1.25]
BUT
if i add "-finstrument-functions" to the compilation line,
then only version < 4.6.x (versions 434 and 453 in my tests) will compile my
code,
otherwise (= gcc versions 462, 463, 47 and 480), compilation will stop with the
following message :
* /tmp/cckYj6ai.o: In function `main':
* sse.c:(.text+0x2a): undefined reference to `_mm_set1_ps'
* sse.c:(.text+0x50): undefined reference to `_mm_set1_ps'
* sse.c:(.text+0x79): undefined reference to `_mm_store_ps'
* sse.c:(.text+0x95): undefined reference to `_mm_store_ps'
* collect2: ld returned 1 exit status
gcc was compiled with :
configure \
--enable-languages=c \
--enable-threads=posix \
--enable-shared \
--with-mpfr=/apps/rothorn/mpfr/3.0.0/gcc-4.3.4 \
--with-gmp=/apps/rothorn/gmp/4.3.2/gcc-4.3.4 \
--with-mpc=/apps/rothorn/mpc/0.8.2/gcc-4.3.4
gcc/4.7 was compiled with revision 184577 of the svn.
gcc/4.8.0 was compiled with revision 185132 of the svn.
Tested on GNU/Linux with Intel (Ubuntu/11.04) and AMD (SLES/11.1) cpus.
What's wrong please ?
Thanks in advance for your help.
The original src is sse.c :
#include
#include
int main(void)
{
float xf[4];
__m128 x = _mm_set1_ps(1.25f);
_mm_store_ps(&xf[0], x);
printf("x = [%f %f %f %f]\n", xf[0], xf[1], xf[2], xf[3]);
return 0;
}
The preprocessed src (with gcc version 4.6.3) is attached, and the full output
is here :
rothorn:/apps/rothorn/sandbox/jgp/gcc/bugA $ ./463 -v -save-temps -Wall -Wextra
-fno-strict-aliasing -fwrapv sse.c -finstrument-functions
Using built-in specs.
COLLECT_GCC=./463
COLLECT_LTO_WRAPPER=/apps/rothorn/sandbox/jgp/gcc/4.6.3/gnu434/libexec/gcc/x86_64-unknown-linux-gnu/4.6.3/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /apps/rothorn/sandbox/jgp/gcc/src/gcc-4.6.3/configure
--prefix=/apps/rothorn/sandbox/jgp/gcc/4.6.3/gnu434 --enable-languages=c
--enable-threads=posix --enable-shared
--with-mpfr=/apps/rothorn/mpfr/3.0.0/gcc-4.3.4
--with-gmp=/apps/rothorn/gmp/4.3.2/gcc-4.3.4
--with-mpc=/apps/rothorn/mpc/0.8.2/gcc-4.3.4
Thread model: posix
gcc version 4.6.3 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-fno-strict-aliasing'
'-fwrapv' '-finstrument-functions' '-mtune=generic' '-march=x86-64'
/apps/rothorn/sandbox/jgp/gcc/4.6.3/gnu434/libexec/gcc/x86_64-unknown-linux-gnu/4.6.3/cc1
-E -quiet -v sse.c -mtune=generic -march=x86-64 -Wall -Wextra
-fno-strict-aliasing -fwrapv -finstrument-functions -fpch-preprocess -o sse.i
ignoring nonexistent directory
"/apps/rothorn/sandbox/jgp/gcc/4.6.3/gnu434/lib/gcc/x86_64-unknown-linux-gnu/4.6.3/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/apps/rothorn/sandbox/jgp/gcc/4.6.3/gnu434/lib/gcc/x86_64-unknown-linux-gnu/4.6.3/include
/usr/local/include
/apps/rothorn/sandbox/jgp/gcc/4.6.3/gnu434/include
/apps/rothorn/sandbox/jgp/gcc/4.6.3/gnu434/lib/gcc/x86_64-unknown-linux-gnu/4.6.3/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-fno-strict-aliasing'
'-fwrapv' '-finstrument-functions' '-mtune=generic' '-march=x86-64'
/apps/rothorn/sandbox/jgp/gcc/4.6.3/gnu434/libexec/gcc/x86_64-unknown-linux-gnu/4.6.3/cc1
-fpreprocessed sse.i -quiet -dumpbase sse.c -mtune=generic -march=x86-64
-auxbase sse -Wall -Wextra -version -fno-strict-aliasing -fwrapv
-finstrument-functions -o sse.s
GNU C (GCC) version 4.6.3 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.3, GMP version 4.3.2, MPFR version 3.0.0, MPC
version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C (GCC) version 4.6.3 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.3, GMP version 4.3.2, MPFR version 3.0.0, MPC
version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 221f59dff4d036c76c9a0dfc4c602ad0
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall'
[Bug target/52530] [4.8 regression] Many 64-bit execution failures on Solaris 10/11 with Sun as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52530 --- Comment #8 from Uros Bizjak 2012-03-09 17:08:13 UTC --- Created attachment 26865 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26865 Patch that introduces %E modifier Patch in testing.
[Bug target/52530] [4.8 regression] Many 64-bit execution failures on Solaris 10/11 with Sun as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52530
Uros Bizjak changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
--- Comment #7 from Uros Bizjak 2012-03-09 16:50:12
UTC ---
(In reply to comment #6)
> This patch works for me:
>
> ---
> diff --git a/gcc/ChangeLog.addr32 b/gcc/ChangeLog.addr32
> index 066f1ec..a191e47 100644
> --- a/gcc/ChangeLog.addr32
> +++ b/gcc/ChangeLog.addr32
> @@ -1,3 +1,8 @@
> +2012-03-08 H.J. Lu
> +
> +* config/i386/i386.c (ix86_print_operand_address): Only handle
> +zero-extended DImode addresses if Pmode == DImode.
> +
> 2012-03-06 Uros Bizjak
>
> * config/i386/i386.md (*zero_extendsidi2_rex64): Allow loading
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 69cb6ae..c2cad5a 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -14548,7 +14548,7 @@ ix86_print_operand_address (FILE *file, rtx addr)
>
>/* Print SImode registers for zero-extended addresses to force
> addr32 prefix. Otherwise print DImode registers to avoid it. */
> - if (TARGET_64BIT)
> + if (Pmode == DImode)
> code = ((GET_CODE (addr) == ZERO_EXTEND
> || GET_CODE (addr) == AND)
> ? 'l'
> --
You will have addr32 added to all lea(%SImode),%SImode instructions.
I have a patch in testing that emits addresses in their natural mode (SImode or
DImode), forces 'l' override for the above RTXes and 'q' for all LEA insns.
For LEAs, we introduce %E modifier that enables special handling:
+case 'E':
+ /* Wrap address in an UNSPEC to declare special handling. */
+ if (TARGET_64BIT)
+x = gen_rtx_UNSPEC (DImode, gen_rtvec (1, x), UNSPEC_LEA_ADDR);
+
+ output_address (x);
+ return;
And in ix86_print_operand_address:
+ else if (GET_CODE (addr) == UNSPEC && XINT (addr, 1) == UNSPEC_LEA_ADDR)
+{
+ gcc_assert (TARGET_64BIT);
+ ok = ix86_decompose_address (XVECEXP (addr, 0, 0), &parts);
+ code = 'q';
+}
[Bug libstdc++/52104] go1 fails to run on Solaris 10/11 x86 with with gld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52104 Rainer Orth changed: What|Removed |Added Target|i386-pc-solaris2.[89] |i386-pc-solaris2.1[01] Host|i386-pc-solaris2.[89] |i386-pc-solaris2.1[01] Summary|go1 fails to link on|go1 fails to run on Solaris |Solaris 8/9 x86 with native |10/11 x86 with with gld |TLS | Known to fail||4.7.0, 4.8.0 Build|i386-pc-solaris2.[89] |i386-pc-solaris2.1[01] --- Comment #15 from Rainer Orth 2012-03-09 16:15:07 UTC --- The Solaris 8/9 x86 link error is gone, but the go1 failure to run when linked with gld remains on Solaris 10/11 x86, so adapting summary. Rainer
[Bug target/47631] Support native TLS on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47631 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Comment #1 from Rainer Orth 2012-03-09 16:11:41 UTC --- Given that the Tru64 UNIX port is about to be removed in 4.8 and the TLS model differs sufficiently from the ELF one, this won't be fixed anywhere. Rainer
[Bug rtl-optimization/52543] lower-subreg.c: code bloat of 300%-400% for bulti-word memory splits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52543 Georg-Johann Lay changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Keywords||missed-optimization Last reconfirmed||2012-03-09 CC||eric.weddington at atmel ||dot com Ever Confirmed|0 |1 Target Milestone|--- |4.7.1
[Bug rtl-optimization/52543] lower-subreg.c: code bloat of 300%-400% for bulti-word memory splits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52543 --- Comment #3 from Georg-Johann Lay 2012-03-09 15:44:46 UTC --- Created attachment 26864 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26864 lower.s: Assembler output with -fno-split-wide-types Compiled with avr-gcc lower.c -Os -S -dp -mmcu=atmega128 -fno-split-wide-types The code size for this module is 38 bytes whereas with lobreg lowering the code size is 142 bytes, which is a factor of 3.7
[Bug rtl-optimization/52543] lower-subreg.c: code bloat of 300%-400% for bulti-word memory splits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52543 --- Comment #2 from Georg-Johann Lay 2012-03-09 15:40:58 UTC --- Created attachment 26863 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26863 lower.s: Assembler output Compiled with avr-gcc lower.c -Os -S -dp -mmcu=atmega128
[Bug rtl-optimization/52543] lower-subreg.c: code bloat of 300%-400% for bulti-word memory splits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52543 --- Comment #1 from Georg-Johann Lay 2012-03-09 15:39:41 UTC --- Created attachment 26862 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26862 lower.c: C source
[Bug rtl-optimization/52543] New: lower-subreg.c: code bloat of 300%-400% for bulti-word memory splits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52543
Bug #: 52543
Summary: lower-subreg.c: code bloat of 300%-400% for bulti-word
memory splits
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org
Target: avr
lower-subreg.c causes extreme code bloat for some memory accesses because it
does not take into account the additional costs caused by the split.
Example code for AVR address spaces:
long readx (const __memx long *p)
{
return *p;
}
long read1 (const __flash1 long *p)
{
return *p;
}
long read0 (const __flash long *p)
{
return *p;
}
Reason is that read from these address spaces need one preparation sequence
(set up segment register) per read. Thus:
For one 4-byte read there will be one preparation sequence.
For 4 one-byte reads there will be 4 preparation sequences.
For the __flash address space no preparation is needed, but a 32-bit read can
use post-increment addressing whereas a split to 4 byte moves won't use
post-increment because GCC is completely afraid of pre-/post-modify addressing.
The only place to hook in could be mode_dependent_address, however, that hook
just passes the address down to the backend but omits the address space in use.
As all 16-bit address spaces (including generic) use HImode as pointer mode,
the target cannot take a decision based on the address alone.
Configured with: ../../gcc.gnu.org/trunk/configure --target=avr
--prefix=/local/gnu/install/gcc-4.7 --disable-nls --with-dwarf2
--enable-checking=yes,rtl --enable-languages=c,c++
gcc version 4.8.0 20120307 (experimental) (GCC)
[Bug target/52530] [4.8 regression] Many 64-bit execution failures on Solaris 10/11 with Sun as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52530 --- Comment #6 from H.J. Lu 2012-03-09 15:17:07 UTC --- This patch works for me: --- diff --git a/gcc/ChangeLog.addr32 b/gcc/ChangeLog.addr32 index 066f1ec..a191e47 100644 --- a/gcc/ChangeLog.addr32 +++ b/gcc/ChangeLog.addr32 @@ -1,3 +1,8 @@ +2012-03-08 H.J. Lu + +* config/i386/i386.c (ix86_print_operand_address): Only handle +zero-extended DImode addresses if Pmode == DImode. + 2012-03-06 Uros Bizjak * config/i386/i386.md (*zero_extendsidi2_rex64): Allow loading diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index 69cb6ae..c2cad5a 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -14548,7 +14548,7 @@ ix86_print_operand_address (FILE *file, rtx addr) /* Print SImode registers for zero-extended addresses to force addr32 prefix. Otherwise print DImode registers to avoid it. */ - if (TARGET_64BIT) + if (Pmode == DImode) code = ((GET_CODE (addr) == ZERO_EXTEND || GET_CODE (addr) == AND) ? 'l' --
[Bug target/52530] [4.8 regression] Many 64-bit execution failures on Solaris 10/11 with Sun as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52530
Uros Bizjak changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed||2012-03-09
Resolution|FIXED |
Ever Confirmed|0 |1
--- Comment #5 from Uros Bizjak 2012-03-09 14:55:18
UTC ---
However, there is a problem with Pmode != DImode. Consider following test:
struct foo
{
int *f;
int i;
};
void
__attribute__ ((noinline))
bar (struct foo x)
{
*(x.f) = 1;
}
This will compile with -mx32 to:
bar:
movl$1, (%rdi)
ret
which is wrong.
The move is:
#(insn:TI 6 3 13 2 (set (mem:SI (reg:SI 5 di [orig:60 x ] [60]) [4 *D.1704_1+0
S4 A32])
#(const_int 1 [0x1])) ptr.c:11 64 {*movsi_internal}
# (expr_list:REG_DEAD (reg:SI 5 di [orig:60 x ] [60])
#(nil)))
movl$1, (%rdi) # 6 *movsi_internal/2 [length = 6]
So we want to output address in SImode, while avoiding addr32 prefixes for
LEAs.
The patch from H.J. should be applied and LEAs should be fixed.
[Bug fortran/52542] Procedure with a Bind (C) named interface does not inherit the Bind (C)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52542 Tobias Burnus changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-09 CC||burnus at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Tobias Burnus 2012-03-09 13:31:19 UTC --- Confirmed. It's an interesting issue, but fortunately clearly specified in the standard (F2008): C1222 (R1211) If proc-language-binding-spec is specified, the proc-interface shall appear, it shall be an interface-name, and interface-name shall be declared with a proc-language-binding-spec. and then in 12.4.3.6p5 (normative): "A proc-language-binding-spec without a NAME= is allowed, but is redundant with the proc-interface required by C1222." Untested patch: --- a/gcc/fortran/decl.c +++ b/gcc/fortran/decl.c @@ -4857,2 +4857,5 @@ match_procedure_decl (void) + if (proc_if && proc_if->attr.is_bind_c) +sym->attr.is_bind_c = 1; + /* Get procedure symbols. */
[Bug libstdc++/52540] std::use_facet throws bad_cast when compiled with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540 --- Comment #6 from Kai Tietz 2012-03-09 13:00:40 UTC --- Hmm, it seems to be a shared/static issue on Windows. As if I pass to command-line -static with the define, the test passes too.
[Bug libstdc++/52540] std::use_facet throws bad_cast when compiled with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540 --- Comment #5 from Paolo Carlini 2012-03-09 12:55:30 UTC --- I would recommend trying to figure out first when the problem has been introduced, without excluding some sort of compiler issue, because these library facilities are in general pretty old and stable.
[Bug libstdc++/52540] std::use_facet throws bad_cast when compiled with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540
--- Comment #4 from Kai Tietz 2012-03-09 12:00:00
UTC ---
Issue happens in
include/bits/locale_classes.tcc:
template
const _Facet&
use_facet(const locale& __loc)
{
const size_t __i = _Facet::id._M_id();
const locale::facet** __facets = __loc._M_impl->_M_facets;
134if (__i >= __loc._M_impl->_M_facets_size || !__facets[__i])
135 __throw_bad_cast();
#ifdef __GXX_RTTI
return dynamic_cast(*__facets[__i]);
#else
return static_cast(*__facets[__i]);
#endif
}
The variable __i has value 30, but __loc.M_impl->_M_factes_size is just 28.
[Bug fortran/52542] New: Procedure with a Bind (C) named interface does not inherit the Bind (C)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52542 Bug #: 52542 Summary: Procedure with a Bind (C) named interface does not inherit the Bind (C) Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: math...@nag.co.uk $ uname -a Linux stonehenge 3.2.9-1.fc16.x86_64 #1 SMP Thu Mar 1 01:41:10 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux $ gfortran --version GNU Fortran (GCC) 4.8.0 20120309 (experimental) [trunk revision 185121] $ cat bind.f90 interface subroutine s() bind(c) end subroutine s end interface procedure(s) :: t call t end $ gfortran -c bind.f90 ; nm bind.o t MAIN__ U _gfortran_set_args U _gfortran_set_options 000b T main r options.0.1852 U t_ Note: that should be 't', not 't_'.
[Bug tree-optimization/52533] [4.8 Regression] ice in remove_range_assertions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52533 --- Comment #2 from Jakub Jelinek 2012-03-09 11:44:27 UTC --- Created attachment 26861 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26861 gcc47-pr52533.patch Untested fix.
[Bug c++/52541] g++ allows definition of const POD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52541 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Paolo Carlini 2012-03-09 11:29:04 UTC --- This behavior changed on purpose, see testcase: g++.dg/init/const8.C. 2011-09-23 Jason Merrill Core 253 - allow const objects with no initializer or user-provided default constructor if the defaulted constructor initializes all the subobjects. PR c++/20039 PR c++/42844 * class.c (default_init_uninitialized_part): New. * cp-tree.h: Declare it. * decl.c (check_for_uninitialized_const_var): Use it. * init.c (perform_member_init): Likewise. (build_new_1): Likewise. * method.c (walk_field_subobs): Likewise.
[Bug libstdc++/52540] std::use_facet throws bad_cast when compiled with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-09 Ever Confirmed|0 |1 --- Comment #3 from Kai Tietz 2012-03-09 11:21:23 UTC --- Ah, with -g2 -D_GLIBCXX_DEBUG I can confirm it.
[Bug libstdc++/52540] std::use_facet throws bad_cast when compiled with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540 --- Comment #2 from Kai Tietz 2012-03-09 11:19:34 UTC --- Hmm, I tested this testcase on my cygwin-cross-compiler for x64 and I didn't noticed this failure. I get for it by shown samples always proper output (eg '03/09/12 12:18:20'). So it might be related to something else in your crt/header-set? I can't confirm it.
[Bug c++/52541] g++ allows definition of const POD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52541 --- Comment #1 from Konrad Rudolph 2012-03-09 11:09:23 UTC --- Created attachment 26860 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26860 MWE
[Bug c++/52541] New: g++ allows definition of const POD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52541 Bug #: 52541 Summary: g++ allows definition of const POD Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: konrad_rudo...@hotmail.com g++ 4.6.2 compiles the attached code without error. However, it *should* yield an error similar to "uninitialized const ‘a’" (according to §8.5 of the standard). In particular, prior versions of GCC treat this as an error, suggesting a regression. It's also worth noting that the compiler does issue an error once the class `c` contains member variables. System: OS X 10.7.3 Configured with: ../configure --prefix=MASKED --with-gmp=/usr/local/Cellar/gmp/5.0.2/lib/ --with-mpfr=/usr/local/Cellar/mpfr/3.1.0/lib --with-mpc=/usr/local/Cellar/libmpc/0.9/lib --program-suffix=4.6.2 --enable-languages=c,c++,fortran Command line: g++-4.6.2 -pedantic main.cpp Compiler output: none More information: http://stackoverflow.com/q/9632229/1968, in particular the discussion in the comments.
[Bug libstdc++/52540] std::use_facet throws bad_cast when compiled with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540 Paolo Carlini changed: What|Removed |Added CC||dave.korn.cygwin at gmail ||dot com, ktietz at gcc dot ||gnu.org --- Comment #1 from Paolo Carlini 2012-03-09 11:02:37 UTC --- Doesn't happen on Linux, a mingw maintainer is needed.
[Bug libstdc++/52540] New: std::use_facet throws bad_cast when compiled with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540
Bug #: 52540
Summary: std::use_facet throws bad_cast when compiled with
_GLIBCXX_DEBUG
Classification: Unclassified
Product: gcc
Version: 4.6.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl...@agmk.net
Target: x86_64-w64-mingw32
#include
#include
#include
#include
int main()
{
std::tm tm;
std::time_t tt;
std::time( &tt );
tm = *std::localtime( &tt );
std::locale lc( "C" );
std::cout.imbue( lc );
std::time_put< char > const& timeFacet = std::use_facet< std::time_put<
char > >( std::cout.getloc() );
char const pattern[] = "%x %X";
timeFacet.put( std::cout, std::cout, std::cout.fill(), &tm, pattern,
pattern + std::strlen( pattern ) );
}
$ x86_64-w64-mingw32-g++ main.cpp -o main-release.exe -g2
$ x86_64-w64-mingw32-g++ main.cpp -o main-debug.exe -g2 -D_GLIBCXX_DEBUG
release-run:
Starting program: main-release.exe
[New Thread 2776.0xdbc]
Breakpoint 1, main () at main.cpp:7
7 {
(gdb) n
10 std::time( &tt );
(gdb)
11 tm = *std::localtime( &tt );
(gdb)
12 std::locale lc( "C" );
(gdb)
13 std::cout.imbue( lc );
(gdb) p lc
$2 = {static none = 0, static ctype = 1, static numeric = 2, static collate =
4, static time = 8, static monetary = 16,
static messages = 32, static all = 63, _M_impl = 0x626e9460, static
_S_classic = 0x626e9460, static _S_global = 0x626e9460,
static _S_categories = 0x626eadc0, static _S_once = {done = 1, started = 0}}
(gdb) c
Continuing.
03/09/12 11:53:50
Program exited normally.
debug-run:
Starting program: main-debug.exe
[New Thread 2704.0xd4c]
Breakpoint 1, main () at main.cpp:7
7 {
(gdb) l
2 #include
3 #include
4 #include
5
6 int main()
7 {
8 std::tm tm;
9 std::time_t tt;
10 std::time( &tt );
11 tm = *std::localtime( &tt );
(gdb) n
10 std::time( &tt );
(gdb)
11 tm = *std::localtime( &tt );
(gdb)
12 std::locale lc( "C" );
(gdb)
13 std::cout.imbue( lc );
(gdb) p lc
$1 = {static none = 0, static ctype = 1, static numeric = 2, static collate =
4, static time = 8, static monetary = 16,
static messages = 32, static all = 63, _M_impl = 0x626e9460, static
_S_classic = 0x626e9460, static _S_global = 0x626e9460,
static _S_categories = 0x626eadc0, static _S_once = {done = 1, started = 0}}
(gdb) n
14 std::time_put< char > const& timeFacet = std::use_facet<
std::time_put< char > >( std::cout.getloc() );
(gdb)
terminate called after throwing an instance of 'std::bad_cast'
what(): std::bad_cast
[Bug target/51244] SH Target: Inefficient conditional branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #31 from Kazumoto Kojima 2012-03-09 10:36:31 UTC --- Created attachment 26859 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26859 A test result testresult on sh4-unknown-linux-gnu [trunk revision 185088].
[Bug libfortran/52539] New: I/O: Wrong result for UTF-8/UCS-4 list-directed and namelist read and nml write
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52539
Bug #: 52539
Summary: I/O: Wrong result for UTF-8/UCS-4 list-directed and
namelist read and nml write
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: jvdeli...@gcc.gnu.org
Example using UTF-8 string with UCS-4 character variables; the string contains
(a)(ni)(hao)(b) ("a你好").
The following program prints here the following. One sees that list-directed
writing correctly works but namelist writing doesn't. (Also the fort.99
contains the correct string.)
For reading, neither list-directed reading nor namelist reading works.
Looking at list_read.c, UTF-8 seems to be unhandled. (And in nml_get_obj_data,
the "array_loop_spec ind" initialization won't survive the array descriptor
reform unmodified.)
>a你好a你好< ! << OK
&NML
STR="a", ! << WRONG
/
>�XX< ! << WRONG
>�XX< ! << WRONG
&NML
STR="a��",! << WRONG
/
>aä½< ! << WRONG
>aä½< ! << WRONG
character(len=3, kind=4) :: str, str2
namelist /nml/ str
str = 4_'a'//char (int (z'4F60'),4) &
//char (int (z'597D'), 4)//4_'b'
open(6, encoding='utf-8')
write(*, '(a)') 4_'>'//str//4_'<'
write(*, *) 4_'>'//str//4_'<'
write(*,nml=nml)
open(99, encoding='utf-8',form='formatted')
write(99, '(3a)') '&nml str = "', str, '" /'
write(99, '(a)') str
rewind(99)
str = 4_''
str2 = 4_''
read(99,nml=nml)
read(99, *) str2
close(99, status='delete')
write(*, '(a)') 4_'>'//str//4_'<'
write(*, *) 4_'>'//str//4_'<'
write(*,nml=nml)
write(*, *) 4_'>'//str2//4_'<'
write(*, '(a)') 4_'>'//str2//4_'<'
end
[Bug target/51244] SH Target: Inefficient conditional branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #30 from Oleg Endo 2012-03-09 10:02:25 UTC --- (In reply to comment #29) > (In reply to comment #28) > Regtest on sh4-unknown-lunix-gnu has been done successfully. > Oleg, your patch is pre-approved. Thanks a lot! Could you please attach the testsuite summary of your setup? I'd like to compare them to my results (in particular the libstdc++ tests). I'm now getting similar effects as in #comment 9 again, where a bunch of libstdc++ failures disappear and this time one new failure appears: FAIL: 21_strings/basic_string/cons/char/6.cc execution test This is weird...
[Bug c++/52536] internal compiler error: Illegal instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52536 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-03-09 Ever Confirmed|0 |1 --- Comment #2 from Jonathan Wakely 2012-03-09 10:02:14 UTC --- (In reply to comment #0) > See http://gcc.gnu.org/bugs.html> for instructions. But 4.2 is no longer supported anyway
[Bug c++/52538] Extend C++11 UDLs to be compatible with inttypes.h macros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52538 --- Comment #2 from Jonathan Wakely 2012-03-09 09:51:34 UTC --- (In reply to comment #1) > If you want to use C++11, then you have to write C++11 code. That is the way > forward I think we have discussed this before. Yes, in PR 52485, and see also PR 51282 and PR 50917 - this is affecting a lot of large codebases. The committee are discussing whether this is a defect worth addressing in the standard, as the scope of the problems is larger than previously realised. (In reply to comment #0) > It would also be possible to fix the code by inserting a space between the " > and the macro name, but in Google's codebase, this cleanup would be 3-4x as > large as the narrowing conversion cleanup, which you have already made > optional. Ack. When UDL support was added to G++ I also found more problems due to "PRId64" than I had found when narrowing errors where added (in a much smaller codebase, obviously.)
[Bug tree-optimization/51988] value_replacement in PHIOPT should handle even the cases where there are other PHIs even with non equal value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51988 --- Comment #8 from Andrew Pinski 2012-03-09 09:27:35 UTC --- Author: pinskia Date: Fri Mar 9 09:27:29 2012 New Revision: 185131 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185131 Log: 2012-03-09 Andrew Pinski PR middle-end/51988 * tree-ssa-phiopt.c: Include tree-pretty-print.h for print_generic_expr. (tree_ssa_phiopt_worker): Go through all the PHIs for value_replacement instead of just the singleton one. (value_replacement): Change return type to int. Return 0 instead of false. Allow the middle basic block to contain more than just the definings tatement. Handle non empty middle basic blocks. * Makefile.in (tree-ssa-phiopt.o): Add tree-pretty-print.h. 2012-03-09 Andrew Pinski PR middle-end/51988 * gcc.dg/tree-ssa/phi-opt-8.c: New testcase. * gcc.dg/tree-ssa/phi-opt-9.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/phi-opt-8.c trunk/gcc/testsuite/gcc.dg/tree-ssa/phi-opt-9.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-phiopt.c
[Bug libfortran/52537] slow trim function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52537 Tobias Burnus changed: What|Removed |Added Keywords||missed-optimization CC||burnus at gcc dot gnu.org, ||jb at gcc dot gnu.org --- Comment #1 from Tobias Burnus 2012-03-09 09:14:00 UTC --- Some related bugs: PR 47065, PR 50673, PR 38199.
[Bug c++/52538] Extend C++11 UDLs to be compatible with inttypes.h macros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52538 --- Comment #1 from Andrew Pinski 2012-03-09 09:07:10 UTC --- If you want to use C++11, then you have to write C++11 code. That is the way forward I think we have discussed this before.
[Bug c++/52538] New: Extend C++11 UDLs to be compatible with inttypes.h macros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52538
Bug #: 52538
Summary: Extend C++11 UDLs to be compatible with inttypes.h
macros
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org
C++11 defines user-defined literals in a way that breaks compatibility with
some code that uses the formatting macros from :
$ cat test.cc
#define __STDC_FORMAT_MACROS
#include
#include
int main() {
int64_t i64 = 123;
printf("My int64: %"PRId64"\n", i64);
}
$ install_gcc46/bin/g++ -Wall test.cc -o test && ./test
My int64: 123
$ install_gcc46/bin/g++ -std=c++0x -Wall test.cc -o test && ./test
My int64: 123
$ install_gcc47/bin/g++-4.7pre -Wall test.cc -o test && ./test
My int64: 123
$ install_gcc47/bin/g++-4.7pre -Wall -Wc++11-compat test.cc -o test && ./test
My int64: 123
$ install_gcc47/bin/g++-4.7pre -std=c++0x -Wall test.cc -o test && ./test
test.cc: In function ‘int main()’:
test.cc:7:29: error: unable to find string literal operator ‘operator"" PRId64’
Clang is working around this by interpreting literal suffixes that don't start
with underscores as separate tokens, which allows them to expand as macros:
http://llvm.org/viewvc/llvm-project?view=rev&revision=152287
According to [lex.ext]p10 and [usrlit.suffix], these suffixes are ill-formed,
no diagnostic required, so allowing them to expand as macros is a conforming
extension.
It would also be possible to fix the code by inserting a space between the "
and the macro name, but in Google's codebase, this cleanup would be 3-4x as
large as the narrowing conversion cleanup, which you have already made
optional.
[Bug libfortran/52537] New: slow trim function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52537 Bug #: 52537 Summary: slow trim function Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: talebi.hoss...@gmail.com Hello, The trim function in Gfortran seems to be a a lot slower than the intel compiler. Sometimes I have to read some input text files which can very large(1.5GB); Comparing the intel and gfortran, the gfortran takes 150 seconds where intel spends only 50 seconds. I checked, and there seems to a large time spend on the trim function. I am not sure if intel does some other optimization but I never got such huge performance difference between gfortran and ifort. Thank you.
[Bug target/51244] SH Target: Inefficient conditional branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #29 from Kazumoto Kojima 2012-03-09 08:40:32 UTC --- (In reply to comment #28) Regtest on sh4-unknown-lunix-gnu has been done successfully. Oleg, your patch is pre-approved.
