[Bug tree-optimization/65826] mark ifn_va_arg as ECF_LEAF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65826 --- Comment #1 from vries at gcc dot gnu.org --- Author: vries Date: Sun Apr 26 07:13:13 2015 New Revision: 222446 URL: https://gcc.gnu.org/viewcvs?rev=222446&root=gcc&view=rev Log: Mark ifn_va_arg as ECF_LEAF 2015-04-26 Tom de Vries PR tree-optimization/65826 * internal-fn.def: Mark VA_ARG with ECF_LEAF. Modified: trunk/gcc/ChangeLog trunk/gcc/internal-fn.def
[Bug tree-optimization/65826] mark ifn_va_arg as ECF_LEAF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65826 vries at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |vries at gcc dot gnu.org --- Comment #2 from vries at gcc dot gnu.org --- patch committed, marking resolved fixed.
[Bug tree-optimization/65824] [6 Regression] execution failures for stdarg/va-arg testcases for aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65824 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-26 Ever confirmed|0 |1 --- Comment #1 from vries at gcc dot gnu.org --- Reproduced stdarg-1.c failure
[Bug tree-optimization/65824] [6 Regression] execution failures for stdarg/va-arg testcases for aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65824
--- Comment #2 from vries at gcc dot gnu.org ---
minimal version of stdarg-1.c, returns 14 if correct, but 12 for current
failure, indicating that the the first and resultless va_arg has been ignored:
...
include
extern void exit (int);
int
f6 (int i, ...)
{
int res;
va_list ap;
va_start (ap, i);
va_arg (ap, long);
res = va_arg (ap, long);
va_end (ap);
return res;
}
int
main (void)
{
int res = f6 (7, 12L, 14L);
exit (res);
}
...
The expression returned by gimpify_va_arg_internal is:
...
(gdb) call debug_generic_expr ($1)
*D.2689 >= 0 ? ap.__stack = (void *) ((long int) D.2690 + 15 & -8);, (long int
*) D.2690; : ap.__gr_offs = D.2689 + 8;, ap.__gr_offs > 0 ? ap.__stack = (void
*) ((long int) D.2690 + 15 & -8);, (long int *) D.2690; : (long int *)
ap.__gr_top + (sizetype) D.2689;
...
Indeed, not side-effect free.
This is most likely a duplicate of PR65818.
[Bug tree-optimization/65824] [6 Regression] execution failures for stdarg/va-arg testcases for aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65824 vries at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from vries at gcc dot gnu.org --- I've done a clean build for aarch64 with the proposed patch for PR65818, and the two test-cases listed in this bug report are passing. *** This bug has been marked as a duplicate of bug 65818 ***
[Bug tree-optimization/65818] [6 Regression] libiberty/vprintf-support.c:41:1: ICE: in expand_i fn_va_arg_1, at tree-stdarg.c:1095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65818 --- Comment #13 from vries at gcc dot gnu.org --- *** Bug 65824 has been marked as a duplicate of this bug. ***
[Bug target/65836] [6 Regression] gnat fails to build on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65836 vries at gcc dot gnu.org changed: What|Removed |Added CC||vries at gcc dot gnu.org --- Comment #6 from vries at gcc dot gnu.org --- Possibly a duplicate of(In reply to Andrew Pinski from comment #2) > This might be the same bug as 65824. For now I'm assuming this is a duplicate of PR65824, which I just marked as a duplicate of PR65818 (for which a patch has been proposed).
[Bug tree-optimization/65893] New: ifcombine not done anymore on expansion of va_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65893
Bug ID: 65893
Summary: ifcombine not done anymore on expansion of va_arg
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
I observed the following when investigating the effect of the introduction of
ifn_va_arg for aarch64 on stdarg-1.c.
At optimized dump, before introduction of ifn_va_arg we have a single
comparison (_4 >= -7):
...
foo (int v, struct va_list ap)
{
int * iftmp.0_1;
int _4;
void * _5;
void * _7;
sizetype _8;
int * iftmp.1_9;
int foo_arg.2_10;
:
switch (v_2(D)) , case 5: >
:
_4 = ap.__gr_offs;
_5 = ap.__stack;
if (_4 >= -7)
goto ;
else
goto ;
:
_7 = ap.__gr_top;
_8 = (sizetype) _4;
iftmp.1_9 = _7 + _8;
:
# iftmp.0_1 = PHI <_5(3), iftmp.1_9(4)>
foo_arg.2_10 = *iftmp.0_1;
foo_arg = foo_arg.2_10;
return;
:
abort ();
}
...
After introduction of ifn_va_arg, we have two comparisons (ap$__gr_offs_20 >=
0, ap$__gr_offs_20 >= -7):
...
foo (int v, struct va_list ap)
{
int ap$__gr_offs;
void * ap$__stack;
int * iftmp.28;
int * iftmp.29;
void * D.2827;
sizetype D.2828;
int foo_arg.0_4;
:
switch (v_1(D)) , case 5: >
:
ap$__stack_26 = MEM[(struct *)&ap];
ap$__gr_offs_20 = MEM[(struct *)&ap + 24B];
if (ap$__gr_offs_20 >= 0)
goto ;
else
goto ;
:
if (ap$__gr_offs_20 >= -7)
goto ;
else
goto ;
:
_28 = ap.__gr_top;
_29 = (sizetype) ap$__gr_offs_20;
iftmp.29_30 = _28 + _29;
:
# iftmp.29_10 = PHI
:
# iftmp.28_9 = PHI
foo_arg.0_4 = *iftmp.28_9;
foo_arg = foo_arg.0_4;
return;
:
abort ();
}
...
The tree optimization ifcombine can combine the two comparisons, so:
1. Before the introduction of ifn_va_arg, the va_arg is expanded at
gimplification, and ifcombine manages to combine the two comparisons.
2. After the introduction of ifn_va_arg, the va_arg is expanded at pass_starg,
a few steps after the ifcombine pass, and the optimization does not happen:
...
NEXT_PASS (pass_tree_ifcombine);
NEXT_PASS (pass_phiopt);
NEXT_PASS (pass_tail_recursion);
NEXT_PASS (pass_ch);
NEXT_PASS (pass_stdarg);
...
[Bug c++/65890] [C++03]sizeof(qualified-id) accepted when the operand denotes a non-static member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65890 --- Comment #3 from Jonathan Wakely --- This was changed by http://open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#613 It was a defect in the original standard. What possible advantage is there in rejecting it in C++03 mode but accepting it in C++11 mode? i.e. why do you consider this a bug?
[Bug c++/65890] [C++03]sizeof(qualified-id) accepted when the operand denotes a non-static member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65890 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Jonathan Wakely --- Implemented by https://gcc.gnu.org/r145375 which applies to all language modes, which I'm sure is what was intended.
[Bug fortran/65894] New: severe regression in gfortran 6.0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894 Bug ID: 65894 Summary: severe regression in gfortran 6.0.0 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Target Milestone: --- Between the commits r222305 and r222439 a severe regression has been introducing segfaults in our code: http://whizard.hepforge.org/versions/unofficial/whizard-2.2.6_alpha-20150426.tar.gz A tarball can be accessed here, which can be compiled with ./configure FC= F77= --disable-ocaml make In build/tests the test beams.run e.g. (and ca. 170 others) triggers the runtime error. Up to now, I was not able to produce a smaller test case. Do make beams.run in tests, and then ./beams.run.
[Bug fortran/65894] severe regression in gfortran 6.0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894 --- Comment #1 from Jürgen Reuter --- Ok, here is a bit shorter test case, untar the attached file, do ./make. This produces an executable seg_prod. With r222305 I get the desired result: $ ./seg_prod | | Running self-test: beams | Running test: beam_1 ... success. Running test: beam_2 ... success. Running test: beam_3 ... success. with r222439 I get: $ ./seg_prod | | Running self-test: beams | Running test: beam_1 Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7F4C166B4B57 #1 0x7F4C166B3D50 #2 0x7F4C15C9322F #3 0x447141 in __model_data_MOD_field_data_get_pdg #4 0x43B51D in __model_data_MOD_model_data_get_field_ptr_pdg #5 0x45C647 in __flavors_MOD_flavor_init0_model #6 0x4D5FAF in __beams_MOD_beam_1 at beams.f90:0 #7 0x40C775 in __unit_tests_MOD_test #8 0x4D7978 in __beams_MOD_beam_test #9 0x4E17A0 in MAIN__ at whizard_test.f90:0 Segmentation fault
[Bug fortran/65894] severe regression in gfortran 6.0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894 --- Comment #2 from Jürgen Reuter --- Created attachment 35401 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35401&action=edit Code that triggers the segmentation fault.
[Bug fortran/65894] severe regression in gfortran 6.0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-26 CC||trippels at gcc dot gnu.org, ||vehre at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Markus Trippelsdorf --- Started with r222361.
[Bug target/65895] New: Segfault building cross GCC 5.1.0 for Target AVR on Mac OSX 10.10.3 (using Apple LLVM version 6.1.0 (clang-602.0.49))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65895 Bug ID: 65895 Summary: Segfault building cross GCC 5.1.0 for Target AVR on Mac OSX 10.10.3 (using Apple LLVM version 6.1.0 (clang-602.0.49)) Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hdusel at macbay dot de Target Milestone: --- Host: Mac OS X 10.10.3 Target: AVR Build: Mac OS X 10.10.3 Using Apple LLVM version 6.1.0 (clang-602.0.49) to build released version 5.1.0 leads into a segfault: --- g++ /tmp/build_cross_gcc/gcc-5.1.0_arch/gcc-5.1.0/gcc/config/avr/gen-avr-mmcu-specs.c -o gen-avr-mmcu-specs -I. -I. -I/tmp/build_cross_gcc/gcc-5.1.0_arch/gcc-5.1.0/gcc -I/tmp/build_cross_gcc/gcc-5.1.0_arch/gcc-5.1.0/gcc/. -I/tmp/build_cross_gcc/gcc-5.1.0_arch/gcc-5.1.0/gcc/../include -I/tmp/build_cross_gcc/gcc-5.1.0_arch/gcc-5.1.0/gcc/../libcpp/include -I/tmp/build_cross_gcc/gcc-5.1.0_build_avr/./gmp -I/tmp/build_cross_gcc/gcc-5.1.0_arch/gcc-5.1.0/gmp -I/tmp/build_cross_gcc/gcc-5.1.0_build_avr/./mpfr -I/tmp/build_cross_gcc/gcc-5.1.0_arch/gcc-5.1.0/mpfr -I/tmp/build_cross_gcc/gcc-5.1.0_arch/gcc-5.1.0/mpc/src -I/tmp/build_cross_gcc/gcc-5.1.0_arch/gcc-5.1.0/gcc/../libdecnumber -I/tmp/build_cross_gcc/gcc-5.1.0_arch/gcc-5.1.0/gcc/../libdecnumber/dpd -I../libdecnumber -I/tmp/build_cross_gcc/gcc-5.1.0_arch/gcc-5.1.0/gcc/../libbacktrace clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated rm -rf device-specs mkdir device-specs && cd device-specs && ../gen-avr-mmcu-specs /bin/sh: line 1: 62583 Segmentation fault: 11 ../gen-avr-mmcu-specs make[2]: *** [s-device-specs] Error 139 make[1]: *** [all-gcc] Error 2 make: *** [all] Error 2 --- I finally found the reason for the segfault! It is located within gcc/config/avr/gen-avr-mmcu-specs.c In the function print_mcu(const avr_mcu_t *mcu) For every spec file that is about to be generated by gen-avr-mmcu-specs a file handle is created but this handle is __not__ closed when the function leaves. On OS X 10.10.3 (haven't tried other versions of Mac OS X) the total number of opened files per process is apparently lower than the files processed by this tool. Hence after this count of opened handles has exceeded the OS will return NULL for any further attempt to open a new file. -> So accessing a NULL Pointer for the file handler leads to the segfault. The solution is simple: Simply call fclose(f) when the function leaves. In addition it would be fine if a returning file handle of NULL will be checked and acknowledged by the tool by an appropriate error message either. At least the code should not attempt to proceed with a NULL for the file handle though. I verified this proposed changes on my system -> build proceeds.
[Bug c++/65896] New: Erroneous uninitialized variable access error in constexpr function with temporary variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65896
Bug ID: 65896
Summary: Erroneous uninitialized variable access error in
constexpr function with temporary variables
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david at doublewise dot net
Target Milestone: ---
file.cpp
==
struct base{};
struct derived : base {
constexpr derived():
base{},
m_value(0) {
}
constexpr derived(derived & other):
base{},
m_value(other) {
}
constexpr explicit operator int() const {
return m_value;
}
int m_value;
};
constexpr int by_ref(derived && value) {
return (derived(value), 0);
}
constexpr int value = by_ref(derived{});
==
c++ -std=c++11 -o /dev/null file.cpp -c
gcc 4.8.3 and 4.9.3 and clang 3.5.0 successfully compile this program. gcc
5.1.1 fails with:
file.cpp:22:29: in constexpr expansion of ‘by_ref(derived())’
file.cpp:22:39: in constexpr expansion of ‘derived((* & value))’
file.cpp:10:16: in constexpr expansion of ‘(& other)->derived::operator
int()’
file.cpp:22:39: error: accessing uninitialized member ‘derived::m_value’
constexpr int value = by_ref(derived{});
^
Changing to C++1y / C++14 does not change this.
[Bug c/65892] gcc fails to implement N685 aliasing of union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 Martin Sebor changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE |--- --- Comment #4 from Martin Sebor --- Thanks for the pointer! I had looked for a related bug report but couldn't find it. There's an important difference between the test cases in pr14319 and the one here that's easy to overlook. The rule only applies to structs defined in unions, not those defined at file scope and only used to declare union members, and to translation units in which the union definition is visible. I would recommend closing pr14319 as NOTABUG. I have reopened this bug.
[Bug c/65892] gcc fails to implement N685 aliasing of union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 --- Comment #5 from Andrew Pinski --- (In reply to Martin Sebor from comment #4) > Thanks for the pointer! I had looked for a related bug report but couldn't > find it. > > There's an important difference between the test cases in pr14319 and the > one here that's easy to overlook. The rule only applies to structs defined > in unions, not those defined at file scope and only used to declare union > members, and to translation units in which the union definition is visible. No that is not the rule. If I read the section: [#5] One special guarantee is made in order to simplify the use of unions: if a union contains several structures that share a common initial sequence (see below), and if the union object currently contains one of these structures, it is permitted to inspect the common initial part of any of them anywhere that a declaration of the complete type of the union is visible. Two structures share a common initial sequence if corresponding members have compatible types (and, for bit-fields, the same widths) for a sequence of one or more initial members. --- CUT I don't see anywhere the standard says about where the struct is defined in the statement above.
[Bug c/65892] gcc fails to implement N685 aliasing of union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 --- Comment #6 from Martin Sebor --- I agree it's subtle and could be clearer but I believe the key phrase is "a union contains several structures." Here, the term "union" refers to the type, not the object. This is supported by the use of the term "union object" in the second part of the sentence. This interpretation is in line with Derek Jones' excellent The New C Standard -- An Economic and Cultural Commentary: http://www.coding-guidelines.com/cbook But if there's doubt that this interpretation is intended I'd be happy to raise an interpretation request on the WG14 mailing list.
[Bug inline-asm/65897] New: GAS named variable of extended asm (::"m" or "g") is in wrong code style, variable stays still in ".att_syntax" -32(%ebp) not ".intel_syntax noprefix" DWORD PTR [ebp-0x20]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65897
Bug ID: 65897
Summary: GAS named variable of extended asm (::"m" or "g") is
in wrong code style, variable stays still in
".att_syntax" -32(%ebp) not ".intel_syntax noprefix"
DWORD PTR [ebp-0x20] while rest of the code is
switched on corectly
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: sstsoft at wp dot pl
Target Milestone: ---
GNU Asembler version 2.32.2
GCC 4.8.1
QT Creator 5.3.1
"g++ -c -fno-keep-inline-dllexport -save-temps -Wattributes
-fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -v
-momit-leaf-frame-pointer -os -Wno-write-strings -Wno-unused-variable
-Wno-unused-parameter -Wno-unused-label -Wno-unused-value -Wunknown-pragmas
-std=gnu++0x -pthread -fopenmp -fverbose-asm -g -std=c++0x -frtti -Wall -Wextra
-fexceptions -mthreads -DUNICODE -DQT_QML_DEBUG -DQT_DECLARATIVE_DEBUG
-DQT_GUI_LIB -DQT_CORE_LIB ..."
simple code as below:
int val;
asm volatile (".INTEL_SYNTAX noprefix\n mov eax,%[val]\n" :: [val] "g" [&val]
asm volatile (".ATT_SYNTAX\n");
is compiled into-> mov eax,-32(%ebp)
rather than correct version for Intel syntax:
-> mov eax,DWORD PTR[ebp-0x20]
First of all i thunk it was capital problem (INTEL not .intel) but it's not.
BTW. Why generated /APP /NO_APP rather than #APP #NO_APP?
When i switch on -masm=intel globally and disable .intel_syntax in my inline
asm() it compiles whole code correctly(as above).
When I make ATT code after asm(".att_syntax\n movl -32(%ebp),%eax\n" :: [val]
"g" (&val)); + .intel switched globaly ON, code generated for val stays in
"att" so, no error produced, compilation successed. It's happens either when
syntax is double changed into one asm() statement, 2 statements(as posted), or
three .intel + code + .att, Code .s for named variable is always formated wrong
(as default in ATT mode). Any other code even with global variables is produced
okey, asembler code is working but not when i add named variable (extended
assembly). Even if gcc optimizes val into registry, produces %eax rather than
eax output so it must be a bug not a feature.
I know there is =r, r mode. But for me it's bad that GCC don't know what
register names im using in inline asembly, GAS it's not. Named variables it's
only way to force asm for using locals, "g" mode,
#__VA_ARGS__ myasm() = myasm_vars() defs is the only way for simpler ported
code.
Bug is well known by others:
http://gotoanswer.com/?q=GCC+inline+assembly+error%3A+Error%3A+junk+%60%28%25esp%29%27+after+expression
https://www.c-plusplus.net/forum/106506-full
http://stackoverflow.com/questions/13856792/gcc-inline-assembly-error-error-junk-esp-after-expression
Sorry, english is not my primary language.
[Bug inline-asm/65897] GAS(asm) "named variable" of extended asm (type ::"m" or "g") generated in wrong code style, variable stays still in ".att_syntax" -32(%ebp) not ".intel_syntax noprefix" DWORD P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65897 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- You changed the syntax but did not notify gcc. Gcc has no way of notifying of the syntax change though. You can change it on the whole file though.
[Bug inline-asm/65898] New: GCC puts auto generated code between two asm volatile(".intel_syntax"); and asm volatile(".att_syntax"); globally syntaxed rather than not put or change it's syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65898
Bug ID: 65898
Summary: GCC puts auto generated code between two asm
volatile(".intel_syntax"); and asm
volatile(".att_syntax"); globally syntaxed rather than
not put or change it's syntax
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: sstsoft at wp dot pl
Target Milestone: ---
GCC put's code between asm volatile statements ended by new line
asm(".intel_syntax noprefix\n");
asm("mov eax,eax\n");
asm(".att_syntax\n");
so it's "auto generated" code is not well recognized by linker(?)
/APP
# 515 "../../../some.cpp" 1
.intel_syntax noprefix
# 0 "" 2
.loc 2 519 0
/NO_APP
leal-44(%ebp), %eax #, tmp80
/APP
# 519 "../../../some.cpp" 1
mov eax,%eax;# tmp80
# 0 "" 2
# 519 "../../../some.cpp" 1
.att_syntax
/NO_APP
When i write code without "\n" it's the same. I need to write in one asm();
1. GCC/GAS is not intuitive as could it be.
Think it's little bug but then it's some kind of blocker!
2. When im forced to add .intel_syntax + code + .att_syntax at end there is a
problem with global flag -masm=intel and mixed syntaxes.
When .att code is mixed with intel asembly code global compiler flag could be
easy detected by #ifdef __INTEL_ASM and preprocessor so make decision of #ifdef
my .intel_syntaxed code with or without pre .intel statements. But if code is
mixed and pre stetemented i can't undef (change back to default syntax) because
rest of the auto generated GCC code would be ruined and not recognized.
If those statements are in one line asm() i must undef whole code either, and
this is specially when asm is in #define macro() because i can't put # in macro
body. When i wrote asm volatile("att_syntax"); GCC sometimes put's some code
before it formated with global syntax flag and... you know what next:
"no such instruction: "
[Bug inline-asm/65898] GCC puts auto generated code between two asm volatile(".intel_syntax"); and asm volatile(".att_syntax"); globally syntaxed rather than not put or change it's syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65898 --- Comment #1 from stanley --- You could see another bug there "mov eax,%eax" -> %eax is generated from named value [val] "g" (val). I see there is my bug, to do such code without clobber "eax" so GCC put's optimized local value into my asm inline() and almost nop -> mov eax,eax produced.. i can fix that, but can someone fix bugs in GCC?
[Bug inline-asm/65898] GCC puts auto generated code between two asm volatile(".intel_syntax"); and asm volatile(".att_syntax"); globally syntaxed rather than not put or change it's syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65898 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- There is no GCC bug here. You change the syntax without notifying GCC. And GCC is free to insert instructions between two inline-asms.
[Bug c++/65896] Erroneous uninitialized variable access error in constexpr function with temporary variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65896
David Stone changed:
What|Removed |Added
CC||david at doublewise dot net
--- Comment #1 from David Stone ---
I have simplified the test case further:
struct base {};
struct derived : base {
constexpr derived():
base{},
m_value(0) {
}
int m_value;
};
constexpr int by_ref(derived && value) {
return value.m_value;
}
constexpr int value = by_ref(derived{});
[Bug tree-optimization/65893] ifcombine not done anymore on expansion of va_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65893 --- Comment #1 from vries at gcc dot gnu.org --- (In reply to vries from comment #0) > I observed the following when investigating the effect of the introduction > of ifn_va_arg for aarch64 on stdarg-1.c. That's ./gcc/testsuite/gcc.c-torture/execute/stdarg-1.c, btw.
[Bug fortran/64230] [4.9/5 Regression] Invalid memory reference in a compiler-generated finalizer for allocatable component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64230 Mat Cross changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Mat Cross --- I've restored the closure status and I'll keep an eye on how PR64921 goes.
